One Side Drives Faster than the Other.

[Craig1989]

It appears I have the classic one side drives faster than the other problem (right side is faster). I believe this problem is caused because the motors spin faster one way then the other (correct me if I'm wrong). We are using 2 small cims on each side. How is the best way to resolve this problem, put a limit in the program maybe?

Appreciate suggestions.
Thanks

[billbo911]

There are so many answers to your question that it would be much simpler to answer if you gave us a little more information.

1) Are you using a mixing function to drive from one joy stick?
2) Are you using two joy sticks to drive.
3) Are you using a different control system, if so, what?
4) Do you have some sort of velocity feedback, like, gear tooth sensors installed?


With out that info, I would only be able to guess that you have a trim pot on a joy stick out of position.

[Craig1989]

We are using the two flight sticks, both are identical. We don't have any feedback atm, we may install that later.

Additionally we have tried replacing the slower of the two with a different stick, this does not change the problem.

[billbo911]

Originally Posted by Craig1989

We are using the two flight sticks, both are identical. We don't have any feedback atm, we may install that later.

Additionally we have tried replacing the slower of the two with a different stick, this does not change the problem.

Now that sounds like classic motor BIAS issues. Of course, binding may also be contributing.

Adding velocity feedback or as kaszeta suggested, a gyro would give you a single input to sample. GTS on each side would be a little more complex, but would give you more accurate control. It's your choice, but it sounds like some sort of feedback is in your future.

[kaszeta]

Originally Posted by Craig1989

It appears I have the classic one side drives faster than the other problem (right side is faster). I believe this problem is caused because the motors spin faster one way then the other (correct me if I'm wrong). We are using 2 small cims on each side. How is the best way to resolve this problem, put a limit in the program maybe?

The best way is a feedback loop.

I've found that the easiest way is a gyro-based feedback loop that corrects for undesired yaw. Almost as easy is a speed-based feedback loop with shaft encoders that keeps the robot's wheels moving the same speed.

[AdamHeard]

Originally Posted by kaszeta

The best way is a feedback loop.

I've found that the easiest way is a gyro-based feedback loop that corrects for undesired yaw. Almost as easy is a speed-based feedback loop with shaft encoders that keeps the robot's wheels moving the same speed.

How difficult is this.

How did you determine if the driver wanted a straight line or not? did you look at the difference between the two sticks?

Any feedback would be appreciated.

[kaszeta]

Originally Posted by AdamHeard

How difficult is this.

How did you determine if the driver wanted a straight line or not? did you look at the difference between the two sticks?

Typically we use a single joystick drive (y-axis commands speed, and x-axis commands the turning rate), but the difference between the two sticks should work as well.

I've posted sample PID code for the gyro in some other threads, just look at some of my recent posts. Nothing terribly difficult to implement, although it helps to have an understanding of how feedback loops work.

[kiettyyyy]

One way you can slightly correct this issue is by putting your robot up on blocks and calibrating your speed controllers, if that doesnt work, you can try to do a more simple P function to correct for the difference between the two motor outputs.

Cheers!

[Alex Cormier]

do you have all 4 motors facing the same way?

http://www.chiefdelphi.com/media/photos/26744?

you can see how the motors have a identical position. one of them has a extra chain and sprocket to reach the wheels.

this could solve your solution also.

[Andrew Blair]

Although, as posted before, the CIM's exhibit very little bias as produced, small factors such as slight mounting shifts, small binds in the motor itself, and other minor variables will affect the performance of different motors slightly. If the issue is not as simple or noticeable as a bind in one side or the other, you may want to try a different motor pair.

As far as software compensation, as also stated before, try adding a constant in front of you problem motor's output to adjust.

I would not recommend calibrating the Victors however. If the problem is not a static one, you will run into problems during autonomous, and it can create other unforeseen, mysterious issues. I speak from experience here...

[Justin M.]

Originally Posted by kaszeta

Typically we use a single joystick drive (y-axis commands speed, and x-axis commands the turning rate), but the difference between the two sticks should work as well.

I've posted sample PID code for the gyro in some other threads, just look at some of my recent posts. Nothing terribly difficult to implement, although it helps to have an understanding of how feedback loops work.

Today we tried doing uploading a single-stick control, just so I could try it out (I was curious as to how it would drive). We had the same exact problem, one side was going faster than the other. This is why we ruled out one-stick driving, it's very hard to get the joystick perfectly in the y-axis to have even power, however, this probably can be fixed with better programming. If the joystick travels slightly diagonal, then a certain amount of power is applied more to the left motor, less to the right, and vice versa.

Once we switched back to our original tank drive (two joysticks), the robot drives like a dream. I prefer driving this way as well - try using two-stick control and see how your robot handles.

Otherwise it's mechanical. Test the gearboxes and poke around to see if theres any issues. Make sure the wheels are aligned perfectly with the chain, and the drive sprockets are properly mounted to the output shaft of the gearbox. Also if your chains are really tight, try slacking them up a bit, so they can be a bit more flexible.

[sparkydp]

try calibrating your speed controllers. This a lot of times can be the problem.

[Al Skierkiewicz]

Craig,
All of the above suggestions are great but no one mentioned that wiring might be an issue. If you have desigened the robot with all of your electrical on one side and there is significant length of wire feeding the side that is slow, you may be experiencing current reduction in that motor set. If you are using #12 wire there could be a significant drop in the wire.

[Brandon Holley]

On a side note....

We received our 2 kit small CIMs...We looked at them, saw they were CIMs and put them in the locked cabinet until we needed them.

We took them out to mount em up, and I gave each motor shaft a quick twist. The 1st one was perfect, teh 2nd one, was horribly bound up. About half of the rotation was flawless, the other half required a bit of effort to turn. We figured we'd put it in the drive train to see if it would work itself out, but it appears that it may be getting worse. Any comments to this??

[Al Skierkiewicz]

Originally Posted by Brandon Holley

We took them out to mount em up, and I gave each motor shaft a quick twist. The 1st one was perfect, teh 2nd one, was horribly bound up. About half of the rotation was flawless, the other half required a bit of effort to turn. We figured we'd put it in the drive train to see if it would work itself out, but it appears that it may be getting worse. Any comments to this??

Brandon,
What you describe is usually the armature contacting the magnet structure. There are a variety of causes for this. The most common is dropping the motor which puts a small bend in the motor shaft or shifts the magnet structure a little. Check for obvious signs of external damage. Replacement is the only real fix on this. A good check is to power the motor up outside of your gearbox and then let it spin down by itself. If there is any rubbing of the internal structure it will be evident at this time with noise and intermittant braking.