Preventing drift

[Salik Syed]

anyone having problems with the robot drifting severely ? probably due to different chain tensions or something... how do you prevent this...

i am running watsons PID code on each wheel but it doesn't really work fast enough to cause the robot to go straight?
Gyro perhaps?
or do you just ask the mechanical team to tension the freakin' wheels

[Joel J]

You can run both sides 2/3'rds full speed, and then record the speed of the left and right wheels. get the ratio of the two speeds, and use it to constantly descrease the output of the faster wheel.

For example, lets say the output of the right side is always about 80% of the left side when they are both commanded to the same speed. You'd then always scale the left side's output by 4/5'ths.

That's a rough scaling that teams did back in the days of the drill motors, and their winding bias. You said you are running some PID code, so that should account for the errors you didn't catch.

And again with that PID. If its not responding fast enough, then perhaps that's because you haven't limited the magnitude of the error before tuning? If you are using the PID to control velocity, then limiting the error may not do much good (you are already limited by the max speed of the robot).

[Mike]

You could over-complicate things and mount encoders on each side.

Or you could record each side's RPMs and do

Faster Side RPM / Slower Side RPM

Multiply that value by the speed you would normally output to the faster motor and you are done. This theoretically will vary with battery voltage and the like, but it comes to the point where it is not noticable.

Sample code:

#define SPEED_COMP .95 // This is Faster Side RPM / Slower Side RPM

// Assuming your left side is faster
RIGHT_SIDE = p1_y;
LEFT_SIDE = p2_y * SPEED_COMP;

KISS.

EDIT: Happy 700th post to me =)

[Salik Syed]

we already have encoders mounted on both sides,
it should be fairly easy to do what you have described (measure RPM differences) , only thing i'm worried is that it is a non-linear change and simply putting a ratio of one wheel to the other may not work in all situations but I'm sure I can come up with some kind of simple algorithm based on 2-3 data points or someting.

For PID i am actually not doing velocity on each wheel, what I'm doing is just positional both wheels are to come to a target distance of 1000 encoder clicks.
what bugs me is that the drift is only when i drive forward and not backwards ! (?!)

EDIT: We are only running PID during autonomous, during regular driving drift is not a problem because our driver can compensate (its not bad in that the robot drives a half circle or anything, but enough that over 10 ft it goes 3 ft to the right during autonomous)

[Mike]

Originally Posted by Salik Syed

we already have encoders mounted on both sides,
it should be fairly easy to do what you have described (measure RPM differences) , only thing i'm worried is that it is a non-linear change and simply putting a ratio of one wheel to the other may not work in all situations but I'm sure I can come up with some kind of simple algorithm based on 2-3 data points or someting.

For PID i am actually not doing velocity on each wheel, what I'm doing is just positional both wheels are to come to a target distance of 1000 encoder clicks.
what bugs me is that the drift is only when i drive forward and not backwards ! (?!)

EDIT: We are only running PID during autonomous, during regular driving drift is not a problem because our driver can compensate (its not bad in that the robot drives a half circle or anything, but enough that over 10 ft it goes 3 ft to the right during autonomous)

I think that that with a simple system that I described, you would maybe accumulate at most... 5 inches of drift error. This depends on the accuracy of your RPM measurements.

Another level of complexity is another point at which your programming could not work.