Robot doesn't drive straight

[bush]

Our robot has a 2 speed transmission. 2 CIMs turn the wheels on the left side (1 engages in low-speed, 1 engages in high-speed), and 2 CIMs turn the wheels on the right side (1 engages in low-speed, 1 engages in high-speed).

1) While in high-speed, when maximum voltage is supplied to the motors on both sides, the robot veers slightly to the left.
2) Still in high speed, if we set the motors back to neutral, the robot stops, and then it turns slightly to the left (the right wheels have a little extra turn at the end).
3) In low speed, when maximum voltage is supplied to the motors on both sides, the robot veers greatly to the left. With testing, we needed to apply about 60% less voltage to the right wheels just to get the bot to head on a somewhat straight path.

I am not sure, but I think my the solution to my problem lies within the calibration settings on the Victor. If this actually is the problem, what would I specifically need to do? If the solutions is something else, what is it?

[Tom Bottiglieri]

Check the trims on your joysticks.

I HATE those things!

[bush]

Ah I probably should have mentioned... the PWM output values are hard-coded. I am working on autonomous mode.

This would lead me to believe that there is a hardware problem somewhere between the RC, Victors, and motors.

[Donut]

We've run into a similar problem; when runnning forward, the left side of our robot started before the right side, and we believe attained a higher speed. The same problem occurred in reverse, only with the sides switched. I'm thinking their is either a problem with the victors' calibration or that the CIMs have some kind of motor bias (this could have to do with the fact that motors on opposite sides spin opposite directions to drive the robot the same direction). Is there any way to correct this through hardware, since we believe we already know a few potential software fixes?

[sanddrag]

First, ditch those right handed kit-provided joysticks if you are using them. Second, calibrate the Victors with some other joysticks (preferable the old CH flightsticks). Third, perhaps try making your program such that the maximum PWM value is attained before the joystick reaches full travel. Fourth, check for binding, friction, and misalignment in your drive system. Noise/sound is often a good indicator.

[KenWittlief]

definately reset the victor calibration if its off by 40%. The proceedure is simple, you push the little recessed button until the LED blinks, then you apply full forward, full reverse, then back to neutral. The exact sequence is in the manual - best to look it up and get it right the first time.

Its also possible your drive train on one side is not spinning freely. One way to check this is with a clamp-on amp meter (DC version). The current draw at full speed with the wheels up is a good indication of the friction in the drive system

but you also need to make sure something is not loading up a bearing when the robot is on the floor.

The motors do spin at slightly different speeds in forward vs reverse. If you want the robot to go perfectly straight you will need to tweak the numbers drive one motor more than the other - but it should not be off by 40%.

[Alan Anderson]

This is sounding more like a mechanical problem than a programming or electrical one. I'd look to see whether the left side of the drive train has more friction than the right side, or the wheels are not mounted perfectly straight.

[kaszeta]

Originally Posted by Donut

We've run into a similar problem; when runnning forward, the left side of our robot started before the right side, and we believe attained a higher speed. The same problem occurred in reverse, only with the sides switched. I'm thinking their is either a problem with the victors' calibration or that the CIMs have some kind of motor bias (this could have to do with the fact that motors on opposite sides spin opposite directions to drive the robot the same direction).

Bingo, this is probably a combination of motor bias combined with differences in each CIM motor. Are you sure about the 40%?

There are a couple of ways team 95 has handled motor bias like this in the past:

1. Calibration. If you have shaft encoders on each CIM or transmission, you can make a correction map that maps a "desired" pwm value to an actual one. You can also linearize the motor response like this.

2. Rotation feedback. You have a gyro, consider using it to stabilize undesired yaw with a feedback loop. I can probably give you some sample code if you have the gyro working already. I've seen this work well for bots that *really* can't drive straight without it (including a bot with a noticeably assymetric drivetrain last year, I don't recall the team number). You can also do PID rotation rate control on the motors, too, but this is more tuning.

3. Adhoc correction factors. Basically, trim your joystick so that the undesired yaw is offset.

4. Driver training.

From our team's experience, #2 is the easiest and most reliable way to go (although #1 and #2 in combination works better). I don't recommend #3 or #4.

Plus, whatever you can do mechanically to fix it makes the programming simpler. Programming can correct a lot of mechanical ills, but you're generally better off if you fix the mechanical problems mechanically.

[Greg Needel]

Another common problem i have seen like this is wheel size.

If you are using pneumatic tires make sure the outside diameter of the tire is the same.

If you are using solid tires make sure the wear is the same.

When tires have difference sizes from side to side then the robot will travel a bit farther causing a turn regardless of the output speed from you reduction being the same and your pwm value.

[Richsgt]

Check the current going through to each side as well, significantly more current draw to one side would seem to indicate a mechanical alignment problem somewhere within the system, especially if using any sort of chain drive.

Also when the Robot is not on the ground, eg up on blocks of some sort, are the wheels/drivetrain spinning at the same rate?

[Elgin Clock]

Originally Posted by Donut

We've run into a similar problem; when runnning forward, the left side of our robot started before the right side, and we believe attained a higher speed. The same problem occurred in reverse, only with the sides switched.

That's the key. When your motors are mounted in opposite directions on 2 sides, 2 are in the forward direction, and 2 are in the reverse direction.

Most, if not all, motors usually have a max rotation value (RPM) in the forward direction that is higher than that of a reverse direction.

The drill motors are the biggest culprits of this. The speed is almost (guessing) 25% less in reverse than in forward.

You will have to either:

A) Find the difference and fix it in programming. - Don't ask me how, I just know it can be done.

(If you are using tank driving with 2 joysticks - 1 for each side)

B) Learn how to drive the robot with a touch more pressure on the left joystick than the right while moving forward and the opposite going in reverse. (Smooth ride)

C) Learn to drive with both sticks completely forward and then let off occasionally on the left to compensate. (Possible jumpy ride)


Of course, unless I am misunderstanding this, you are using tank drive, and this is the cause of the problem.

B is the best human way to compensate unless you know what you are doing in programming and trust it.

Maybe a combination of A & B is needed.

edit: Oops, kaszeta kind of beat me.
http://www.chiefdelphi.com/forums/sh...49&postcount=8

[Donut]

Well, we found part of the problem at least. We were using last year's drive code, and missed a part of the code that added 5 to the joystick value before it was given to the motors for no documented reason. We are using a one-joystick mixing system, and when the x-axis values were fed through, this caused one pwm value to decrease by 5 while the other increased by 5, throwing our motors out of sync by 10 pwm values at all times.

We've also reversed the wires from the victors to the motors on one side, so that we are sending the same pwm to all 4 motors, in case the victors or motors respond better to certain pwm values (high rather than low or vice versa).

We have not tested the motors yet since we made the programming fix, hopefully the problem should be solved tommorow. We have been testing our robot off the ground on a crate. I don't know about the 40%, that's what bush was having a problem with.

[bush]

And that was just an estimation. I know that the problem was significant when we were engaged in low-speed, and noticable when engaged in high-speed.

[Paul Copioli]

First, the CIM motors do NOT have bias. The windings are perfectly symmetric. There still may be slight differences in each direction due to other factors, but at loaded conditions this difference should be unnoticeable. I did significant testing on the kit base and kit transmissions (2 CIMS mounted in opposite directions) and the robot would only drift 6 inches sideways in 54 feet.

Second, the phenomenon you described when stopping is that one side kept going and one side stopped could be due to the brake setting on the victors. There is a little plastic jumper between pins on the victors. The three pins are A, B, and C. If the jumper is between A and B (Always Brake), then the Victors will come to a sudden stop. If the jumper is between B and C (Better Coast), then the victors will come to a slow stop. If the jumper is missing, then the victors will also brake. We have found that if you are doing a PID loop on the drive base (via encoders, etc.) you may want to put the victors in brake mode to help with oscillation.

-Paul

[bush]

Just read over some documentation.
I have a couple guesses for my problems...
The problem where the robot turns left when stopped could be due to the left Victor having brake mode enabled, and the right one has coast mode enabled.
The problem where the robot veers one direction with the same value applied to each Victor could be due to miscalibration.