I just got a GoPiGo yesterday for Christmas. After putting it together and running basic_test_all.py, one motor seems to run slower than the other and sometimes stalls out and doesn’t move at all. I can also sometimes see the motor speed “pulse” (it’ll speed up and then slow down) as if its trying to catch up.
Looking at the GoPiGo from the top, it is the left motor. I have tried switching the connections of the left and right motors and the problem moves to the right motor so it doesn’t look like a motor problem. In addition, I only see the problem when moving forward or backwards and not when turning. This might imply a power issue?
I even see the problem when if I disconnect the right motor and just have the “slower” motor running.
I’ve seen the problem from the first time I ran basic_test_all and I’m using fresh batteries.
Any other suggestions on things to try or possible causes?
I have the exact same problem. Both motors seems to be powerful when run individually but when running at the same time one of them is much weaker. This causes to GoPiGo to turn around instead of going straight.
To me this sounds like a issue with the supply of power to the motors. Any ideas anyone ?
Have applied the updates on the Dexter desktop and it made no changes. Interestingly, I swapped the wire pairs from right to left and the “weak” motor moved to the other side - so this rules out the motor and any drivetrain issues.
I have the same problem. When I use basic_test_all.py and go forward it does not go straigth. It goes in waves. Onw wheel is changing speed. One whell goes in a constant speed.
I had this probelm, but updating the firmware and using the battery pack as a power supply seemed to make a big difference. I was running it off of a 1 amp AC adapter through the raspberry pi for the initial setup and testing, but this likely was not enough power.
Put my sons together last night and ran into the same problem. Downloaded Dexter Industries image of raspian and performed the update per their instructions.
i put some more time into this problem.
I am running firmware 1.1.
Regardless of the speed i am running my gopigo on it will not run straight. (running from the basic scratch example)
I tried to remove the encoders and then both the motors run at full speed. Indicating that this is not a power problem but rather a problem with the encoders or the software handling the impulses from them.
Ideas anyone ?
Is it possible that the encoders are broken ?
Or is it just the encoding wheels that are not correctly aligned somehow ?
Hi, I have exactly the same problem. Updating the firmware did not help. I checked the power from the battery pack and I getting a 9.5V , so this cannot be the problem. I also checked the voltage on the motor jumpers(pins) with the motors disconnected and with the test prog running. Results below;
Input- Right jumpers -Left Jumpers
w- 7.25 - 6.51
t- 7.33 - 6.72
t- 7.40 - 6.96
x- 0 - 0
s- 7.45 - 7.02
t- 7.55 - 7.27
t- 7.60 - 7.48
x- 0 - 0
a- 7.36 - 0
x- 0 - 0
d- 0 - 7.41
As you can see one of the motors is always getting a higher voltage than the other when they are both running at the same time. But they both get the same voltage when they are on individually. To me this indicates a software issue, but I’m not sure. Please help, I really want to use my GoPiGo!
We have a Christmas GoPiGo as well that is having the same trouble listed here. Our encoder wheels still have paper on them. We’ve secured the encoders in place with a dab of hot glue. We’ve updated the firmware using both the icon on desktop and the other instructions. Switching leads causes the issue to switch sides… Looking forward to trying new ideas to resolve this issue.
Hey Guys,
Sorry about the issue with the motors. What the GoPiGo does when you give a forward command is it tries to match the speed of one of the motors to the other one. One of the motor runs at a constant speed and the other one tries to tune to it’s speed with a PID algorithm. I think this is what is failing for you guys.
Hi Karan, so when using ‘k’ and ‘i’ the wheels do turn at the same speed and the GoPiGo travels in a straight line. Which is great!
Just 2 questions. 1. Does this mean we should only use ‘motor_fwd’ and ‘motor_bwd’ functions when coding?(2) Are there any other function effected by the PID algorithm?
Thanks!
Also, just to hop in here for everyone: DO NOT run the GoPiGo motors off the USB cord. Every GoPiGo comes with a power pack. The Pi power supply is not enough to support the motors in any meaningful way; you run the risk of damaging the Pi if you run it off the Pi power supply.
I did more tests and believe this is the encoder problem. For example, I noticed that the wheel controlled by PID algorithm in general stops when the solid part falls within the sensor. This is confirmed by blocking the sensor with a credit card. (BTW, as I understand, you are using an infrared optical incremental encoder. So the outside plastic or paper layer should not matter.)
Karan, could you please provide us with a script or function so that we can program/test the encoder, e.g., read the encoder counts? Thanks!
@fdboy, as you can see from the above forum, we’re working on it. We think it will be a firmware fix, so as soon as we have it, we’ll be putting it out for everyone!
