Motor turns at different rates, sometimes stalls


#1

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?


#2

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 ?


#3

Hi,

I have the same behaviour with my gopigo.

Please help, thanks.


#4

Same here.

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.

Love the idea of the product - please help.


#5

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.


#6

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.

I did not use the DI card image, so used these instructions to update the firmware:
http://www.dexterindustries.com/forum/?topic=software-update-problems/#post-3277


#7

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.


#8

Hi again.

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 ?


#9

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!


#10

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.


#11

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.

Can you try out the basic_test_all.py example in the main python folder https://github.com/DexterInd/GoPiGo/blob/master/Software/Python/basic_test_all.py .

Use i to move forward , k to move back and x to stop. This command let’s you control the GoPiGo without the PID algorithm.

We had this problem earlier, but the last time when tested it, the problem was solved. Make sure that the firmware is the latest version.

Let us know if you find that to be better. We’ll make that default then or give an option to switch between them.

-Karan


#12

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!


#13

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.

If you’re using the motors, use the batteries.


#14

Karan,

I just executed the the basic_test_all.py and the w (forward) still has inconsistent speeds between the two wheels in the same way.

Other thoughts?

Thanks…Ryan


#15

Hey Ryan,
Use i to move forward , k to move back and x to stop instead of w and s.

Let us know if it’s any better.

-Karan


#16

I have this problem too. Using ‘i’ and ‘k’ indeed runs better. But do you have a fix to bring the PID back?


#17

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!


#18

Hey,
Thanks a lot for looking into this in depth.

Sadly there is no good way right now to test the encoder counts.

The only way that works is to either upload this firmware https://github.com/DexterInd/GoPiGo/blob/master/Firmware/old/encoder_interrupt/encoder_interrupt.ino on the GoPiGo and watch the Serial port for incoming triggers for each of the Motors or modify the firmware itself https://github.com/DexterInd/GoPiGo/blob/master/Firmware/fw_ver_11/fw_ver_11.ino#L695 by adding a debug statement in the Encoder ISR.
I’ll recommend the first method but just make sure that the CPU clock is down to 2Mhz https://github.com/DexterInd/GoPiGo/blob/master/Firmware/fw_ver_11/fw_ver_11.ino#L26 . Also, disconnect the motors before uploading the firmware.

Also, do check if 115200 baud works for you. You might have to lower it.

Let us know if you find anything useful.

-Karan


#19

@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!


#20

Just received my sons GoPiGo after waiting 6 weeks for delivery, and it has the same problems as described above :frowning:

I have done all updates as well