Robot won't go straight

Our robot has 2 cim motors attached to wheels via chain and sproket. We have used the default code and the robot will not go straight, it turns in one direction weather we go forward or backwards! Is anyone else having this problem? It could be the transmission between the motors and the chain, and the chains on each side are almost the same. We will continue to troubleshoot.
Thanks,

      **Quantum Ninjas******

we found that the motor have a directional preferance and that they spin at different rates in either foward or backwards. just an idea

also

make sure that one of your trasmissions is not binding or anything like that. just curous are you using the Banebots transmissins?

are you using a 1 joystick drive or 2?
if it is 1 joystick it could be that “forward” on your robot actual requires one side to turn backwards while the other turns forward.

Try reversing the polarity for the motors on one side of the robot, then reverse that motors output in code. This sometimes helps.

Other than that, I know you can correct it with a gyro and some programming. It’s a good project for new programmers since it’s a pretty easy introduction to doing control loops. This late in the build season though it’s probably not feasible.

last ditch effort, try calibrating your victors.

Is is most likely caused by the way motors are built. They are optimized to turn one way (the brushes inside are slightly angled). If you mount both motors with the body pointing towards the inside and the output pointing away from the robot, one will be turning the opposite way than the other. The one that is turning “backwards” will turn slower than the other one.

The only way (that I know of) to correct this is programming: Scale the faster side down a little bit. You will loose a little bit of speed though. So it’s up to you, easier to drive vs. performance.

The CIM motors have neutral timing, so they don’t favor one direction with slightly less RPM’s.

You always have to reverse the polarity of one side of the motors driving the thing, either in the programming or by just simply physically reversing the polarity from the Victor. That would explain why your robot wont go straight. If the left side motors are turning left, the right side motors will turn left as well, but turning left on the left side motors means that turning left on the right side motors (which are inverted), will actually appear to be turning right, due to how it’s mounted on your chassis.

Well, I can’t tell what your problem is, but I can tell you what our problem was when we discovered our robot was listing slightly. It turned out to be what we termed “victor bias,” though we never really discovered whether the victor or the robot controller was the problem. The problem turned out to be that for equal and opposite PWM values (such as 100 and 154) the victors were not outputting the same amount of power. We ended up fixing it with a lookup table so that the victors would output the same power for opposite PWM values (mirrored at 127), but it took us a few days to work out all the problems.

For more discussion, see this thread
http://www.chiefdelphi.com/forums/showthread.php?t=40258&page=2&highlight=victor+bias

In particular, read Mike Betts’ post and check out his graph
http://www.chiefdelphi.com/forums/attachment.php?attachmentid=3100

We collected our own data and got a graph that looked a lot like his. What’s interesting about that graph is that the center of the “flat zone” is NOT symetric about 127, but more like 130-132. So adding 25 to 127 will give a power value (and hence an rpm) that is substantially different from what you get by subtracting 25. The curve is very steep along there, and a couple PWM values change will really change the power.

So if you push the joystick straight forward and give the identical values to the PWMs on both sides, the robot will curve (say) left going forward, and right in reverse.

Whether the motors “prefer” to go more easily one direction than another, you have different friction to overcome in the drive mechanisms on each side of the robot, or there is ‘Victor bias’, you have to do SOMETHING!

We have used this test:

Record the PWM output values required to start the left side wheels moving, in both forward and backward directions. Ours are something like 127+8 and 127-15.

Repeat on the right side. We found 127-8 and 127+15.

Allowing for the sign, it looks symmetrical doesn’t it?

To solve this problem simply, just add a constant of 15-8 = 7 to the PWM on the slower side to make the motors spin the same. When going forward, add the constant to one wheel, in reverse add the constant to the other one.

Or center whatever function you use the scale the joysticks to PWMs on 131 and not 127. The loss at the ends doesn’t really matter, the difference between a command of 250 and 254 is negligable.

The solution we took is to have a Set_Left_Motor() and Set_Right_Motor() function where if you pass in x, it sets (for example) **pwm01 **to pwm01_min_forward+x if x > 0 or pwm_min_reverse-x if x < 0, where pwm01_min_forward and _reverse are around 127+15 and 127-8. I don’t have the actual values in front of me but we adjusted this to make min_forward and min_reverse the values that actually make the robot itself move, not just the wheels turn under no load.

Robinson Levin

According to IFI (http://www.ifirobotics.com/forum/viewtopic.php?p=883), the difference between Victor outputs for pwm inputs of 250 and 254 is actually nonexistent. It hits 100% output at about 232. That Q&A response also seems to confirm that the forward/reverse response is asymmetric.

It’s not a last ditch effort at all. We calibrated our victors using the method in this thread and it solved basically all our driving issues without any need for adjustments in the code or lookup tables.