Robot won't go straight

[svanderlugt]

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,

[b]Quantum Ninjas[b]

[GBIT]

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?

[AV_guy007]

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.

[Donut]

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.

[efoote868]

last ditch effort, try calibrating your victors.

[tdlrali]

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.

[Justin M.]

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.

[kmcclary]

Originally Posted by svanderlugt

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,

[b]Quantum Ninjas[b]

Is it SPINNING, or just making a gentle "arc" to one side?

(A) IF spinning: Reverse the polarity on one motor. Remember that one runs forward and one runs backwards on a standard outward facing differential drive, so one will have the red lead on the Victor's M+, whereas the other will have the black lead on it (and vice versa for the M- connection).

(B) IF arcing in a gentle "S" curve (arc one way forward, the other backward): You have "motor timing" issues, where the motor favors one direction over the other. Others have posted that the CIMs are not SUPPOSED to be "timed" (favor one direction), but in reality they always seem to favor one way or the other slightly.

This can be compensated for via several methods: a power factor lookup table to balance the power to each side based on command, closed loop steering control with the gyro (slave one motor's speed to the other via integrating the gyro data - see the Whitepapers or kevin.org for more information), mechanical coupling of the two sides (tough to do without designing a clutch), or a different drivetrain geometry, like skid steer 4WD or 6WD (also tough to change now, since we're in week six!)

(C) If it is favoring the SAME side both forward and backward: You either have one motor more powerful than the other (CIM output is rated +/- 10 percent per copy), or the drivetrain is BINDING more on one side than the other. Check for binding first. That is the most common reason when this occurs. Check for: binding in the CIM-Transmission coupling (VERY common source!), for misalignment in gear and/or sprocket-chain sets, binding wheel bearings, and if live shafts are used, defective/dry pillow blocks or a misaligned/bent shaft.

Also be sure that the far end of the motor/gearbox shaft is supported with a pillow block! If it's not, chain tension can bind up a gearbox.

If you suspect motor-to-motor variance, try a different combination of CIMs.

(D) It COULD be a programming problem, but that's unlikely. You can easily disprove ANY variance in the control system & programming is responsible, by simply switching which side each Victor controls (IOW, swap motor wiring to the Victors, keeping everything else identical). This is an easy test to do. If the symptom shifts sides, then you actually have a programming or electrical problem! If not, then it's a motor, transmission, drivetrain, wheel, or other mechanical problem.


I hope this helps you diagnose your problem.

- Keith McClary
Chief Engineer, Team 1502 "Technical Difficulties"

[Fritztopher]

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/sh...=victor+bia s

In particular, read Mike Betts' post and check out his graph
http://www.chiefdelphi.com/forums/at...achmentid=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.

[mluckham]

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.

[gnirts]

Originally Posted by mluckham

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.

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

[Alan Anderson]

Originally Posted by gnirts

...the difference between a command of 250 and 254 is negligable.

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.

[Bio]

Originally Posted by efoote868

last ditch effort, try calibrating your victors.

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.