In need of assistance

[Railbots]

We need some help regarding our robot. What are some possible causes of one side of the robot to move slower than the other.
I appreciate your time in answering our question.

[EricLeifermann]

You could have misalignment in your drive

You could be powering your motors differently

If you have more than 1 motor on each side they might be fighting eachother

You could have different gearing on each side.

Pictures/video are always helpful

[Jimmy Nichols]

You could have the chain or belts over-tensioned on one side.

[MrForbes]

It might help to know how much slower the other side is going. Maybe you could put some video of it driving, on youtube, and link here? There is usually a slight difference in speed, resulting in the robot steering slightly when commanded to go straight...simply because the motors are made to turn one direction, and they are a bit slower going backwards (forward is the side that has positive power on the red wire, negative on the black wire).

We don't know if what you are seeing is normal, because you didn't describe it in detail. It might be normal, it might be abnormal.

Some things to check...see if all the motors are mounted tightly, they should not wiggle in the gearbox. Check to see if it's harder to turn the wheels by hand (with the robot power OFF) on one side than the other.

[angelah]

Can you tell us more about your robot? You could post a picture if that is easier.

[Steph342]

If using 4 motors to drive the drive train check to make sure each motor is receiving power and that the motors are working.

[bEdhEd]

I'm gonna have to ask for a better description of what's happening. We don't know how many motors, which kinds, how you are transferring power to each wheel, the width of your robot, etc.

A video with plenty of pictures and a description of any of your troubleshooting will be most helpful.

[Zebra_Fact_Man]

Originally Posted by Railbots

We need some help regarding our robot. What are some possible causes of one side of the robot to move slower than the other.
I appreciate your time in answering our question.

Based on nothing else other than helping rookies before, and having MANY rookie students go through my teams, chances are your problem is due to motor optimal rotation direction. All motors have a preferred way to rotate, and when rotating the opposite direction they rotate slower. The math isn't so simple, but it averages out to about 85% speed of the optimal direction. When you build a robot, normally motors on one side spin optimally, and the other side spins in the opposite direction, non-optimally, causing you to veer off in one direction consistently.

A few ways to fix this:
a) make all motors spin in the same direction. Not so easy if using the KOP drive train, direct drive a wheel to the gearbox axle, or like symmetrical chassis designs.
b) use some sort of autocorrect system, like a gyro or encoders.
c) quick and dirty fix - reduce the optimal speed side limit to 85% max speed in the code. You can play around with the number until you are happy and the robot is driving straight.

[ThaddeusMaximus]

Originally Posted by Zebra_Fact_Man

Based on nothing else other than helping rookies before, and having MANY rookie students go through my teams, chances are your problem is due to motor optimal rotation direction. All motors have a preferred way to rotate, and when rotating the opposite direction they rotate slower. The math isn't so simple, but it averages out to about 85% speed of the optimal direction. When you build a robot, normally motors on one side spin optimally, and the other side spins in the opposite direction, non-optimally, causing you to veer off in one direction consistently.

A few ways to fix this:
a) make all motors spin in the same direction. Not so easy if using the KOP drive train, direct drive a wheel to the gearbox axle, or like symmetrical chassis designs.
b) use some sort of autocorrect system, like a gyro or encoders.
c) quick and dirty fix - reduce the optimal speed side limit to 85% max speed in the code. You can play around with the number until you are happy and the robot is driving straight.

I have never seen this phenomenon play out with CIM motors in an FRC application.

[joelg236]

Originally Posted by ThaddeusMaximus

I have never seen this phenomenon play out with CIM motors in an FRC application.

Right? 85%? I'm not crazy to think that's a really big number that I've never even contemplated before.

[philso]

Check your electrical connections from the PDP through the motor controllers to the motors.

If you are using PWM control of the motor controllers, disconnect all PWM cables except for one motor controller on each side. Verify that both sides run. Disconnect those two PWM's and connect the PWM cables for another controller on each side and repeat. Verify that both sides run.

Reconnect all PWM cables. Command the robot to drive straight for some fixed distance, say 10 ft. measure how much the robot has deviated from a straight line. Repeat this measurement another 4 times. Swap the connections between motors and the controllers so that the controllers for the left are now driving the motors on the right. Don't change the software. Command the robot to drive straight for the same distance and measure the deviation from the straight line. Repeat this measurement another 4 times. You should then be able to tell if the problem is in the motors or mechanical system or if it is in your software or motor controllers. If the problem appears to be in the motors or mechanical system, swap the motors from one side to the other and repeat the measurements.

[mklinker]

If using an AM14U3 KOP drive base check to see if the dead axles are over tightened on one side of the drive. The wheels should move freely.

different gears

motor/s not working

motor controller needed calibration

[JPBlacksmiths]

Originally Posted by Zebra_Fact_Man

Based on nothing else other than helping rookies before, and having MANY rookie students go through my teams, chances are your problem is due to motor optimal rotation direction. All motors have a preferred way to rotate, and when rotating the opposite direction they rotate slower. The math isn't so simple, but it averages out to about 85% speed of the optimal direction. When you build a robot, normally motors on one side spin optimally, and the other side spins in the opposite direction, non-optimally, causing you to veer off in one direction consistently.

A few ways to fix this:
a) make all motors spin in the same direction. Not so easy if using the KOP drive train, direct drive a wheel to the gearbox axle, or like symmetrical chassis designs.
b) use some sort of autocorrect system, like a gyro or encoders.
c) quick and dirty fix - reduce the optimal speed side limit to 85% max speed in the code. You can play around with the number until you are happy and the robot is driving straight.

Um is this actually a thing? I'm pretty sure that when just flashing cims to a battery, that they have the same rotational speed even when we flip the leads and it goes backwards. I feel like I would have noticed a 15% drop in speed, but maybe not, I'm not sure. I would love to hear more about this though.

[scca229]

It was mentioned above but might get lost.


Make sure that you have gone through the calibration routine on each motor controller to make sure that they each know the full bands from the joystick/gamepad inputs in your setup.

[Zebra_Fact_Man]

CIM motors are brushed motors. Brushed motors have the tendency for this to occur (thread regarding phenomenon: http://forums.overclockers.com.au/sh...php?t=1063875; sorry I couldn't find better source, I'm tired/long day at work).

You can actually hear the motor sound differently free-spinning in opposite directions if you directly connect it to a battery. One direction has a higher pitch whine than the other.

Admittedly, most motors I've used are a couple years old, so that may (?) have something to do with why my observed difference is so high (brushes are no longer perfectly distributed?), but yeah, common occurrence. Even last year when we built w/ KOP chassis, had to account for it in code for auto programming. Our 2014 robot had a pretty bad arc before our programmer added the correction.

Also, I'm generally more mechanical in thinking, so hopefully someone more electronically intelligent can fill in the gaps to my explanation.