Autonomous using encoders

[Mr.G]

I have a question on how other teams use encoders to control the motion of there robot in autonomous. I understand how to turn reliably and go straight for short distances, but my problem is going straight for long distances.

The difference in encoder counts between both sides of the robot builds up at the end of a long run. This is worse if the floor isn't level or the motors on one side are stronger. What do teams do with this error?

Any sample code would be appreciated.

[JBotAlan]

I don't have much experience with encoders, but my guess is that you have a pair of encoders that doesn't match. I didn't think that encoders differ at all, so this comes as a surprise to me; however, 1140 (last year's Holly team) didn't even think about using encoders...made auton programming fun let me tell you... :ahh:

JBotAlan

PS: Someone with knowledge of encoders please post here!

[Dave Flowerday]

The difference in encoder counts between both sides of the robot builds up at the end of a long run. This is worse if the floor isn't level or the motors on one side are stronger. What do teams do with this error?
I'm not quite sure which problem you're having. Is it:

A) Your robot is driving perfectly straight (or nearly so) but the encoders are giving you different counts at the end of your run, indicating that the encoders aren't counting accurately for some reason.

or

B) Your encoders are giving you different counts and your robot is veering off to one side (i.e. the encoder counts are right, and you just want to use the difference between them to be able to drive straight).

[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 encoders working fine.

[Mr.G]

Dave everything is working correctly as far as the encoders go. I am looking to find out how other teams keep the robot going straight over long distances. Like you mentioned, an active feedback of the difference between the counts of the 2 sides. Does anyone have a sample equation?

Greg we use solid aluminum wheels so they all have the same diameter, but that is a very good observation that other teams should note.

This will also help solve other problems we have had:
Examples:
1. We get everything working good in one robot and then we download it into another robot with the same drive train and it tracks different. I assume it is because there are different motors and differing amount of friction in the drivetrains on each side, but we should be able to use the encoders to compensate for that.
2. The robot frame take a hit and start binding on one side, we don’t notice it, but from then on all the autonomous functions are off.
3. Or we burn up a motor or have one going bad and everything changes in autonomous.
4. The floor at one end of the area isn’t as level as the other end and the robot tracks different yet again.

As you can see this gets to be very frustrating and time consuming.

[Rickertsen2]

the best algorithm is PID(search these forums). If you want something simpler then just P:

*Subtract the left side encoder count from the right side. I you get a negative value then you are
veering to the left. Positive means you are going to the right

*multiply this number by some constant.

*Add the result to the left wheel. subtract it from the right wheel. Make sure nothing overflows.

This is not the best algorithm but it helps. One year, we found that for whatever reason one side of our robot was slightly more powerful than the other. We simply multiplied the more powerful side by a constant and it almost completely eliminated the problem without any feedback at all.

[phrontist]

Rickterson speaks the truth. What you need is a simple porportional algorithm, full PID is overkill for this.

Another, perhaps obvious, fix is to make sure your robot isn't peeling out. Don't floor it right off the bat in autonomus, but ramp up the values you send to the motors.

[Al Skierkiewicz]

Let us not forget that depending on the encoder used, accuracy enters into the calculations. If your encoder is only able to resolve about 1" of travel by counting at the wheel, you can get really far off before the encoders will try to pull you straight again. Accuracy can be improved by encdoding a shaft further up the reduction chain. The errors are then divided by the reduction ratio (all other things being equal). You may find that there is a constant difference between sides and apply a constant correction to one side as a simple fix. Although the Chalupa does not exhibit differences between forward and reverse, production differences do effect it's loaded speed and no two transmissions are identical so differences in speed (side to side) are a fact of life.

[binary_sandman]

we are also using encoders on our wheels and there is no way to stop this real-life application problem. but the ground is going to be level; the only problem is a motor going faster than another. which beforehand we will find our the difference if it is long term and put a speed filter on the other motor of the difference variable Usually divide by .2 ; if temporarily it is the chain's problem and will get fixed.

[Avarik]

There are a few ways to address this problem. The simplest is probably, as stated, to just find a constant which will get your fairly close to driving straight.

Another method would be to implement checks while trying to run straight. Maybe after every 100 encoder counts, you would, at that point, get your robot to adjust by sending a forward signal to one side, and a 127 to the other. One the counts were equal again, you could try going straight once more.

Another way is to adjust pwm values on the fly, implementing a straight drive. You could add and subtract to your pwm values depending on which side was going faster throughout your entire autonomous, which would make your robot travel much straighter. We implented this system with a gyro last year during human control, and it worked wonderfully.

[Joe Hershberger]

Another method would be to implement checks while trying to run straight. Maybe after every 100 encoder counts, you would, at that point, get your robot to adjust by sending a forward signal to one side, and a 127 to the other. One the counts were equal again, you could try going straight once more.

Avarik,

Don't forget: just because the number of ticks on each wheel are equal doesn't mean that your path was straight. You need the ticks to alternate one wheel then the other for the straightest path. If you just correct every 100 pulses, then you drive sideways for 100 pulses, straighten the robot, then drive sideways for another 100 pulses.

In an extreme case, one wheel sticks and the other goes 100 pulses, so you turned, say 90 degrees. Then you correct and wait till the other sees 100 pulses. That straightens you back out but you have barely moved. :eek:

Cheers!
-Joe

[Joe Hershberger]

Dave everything is working correctly as far as the encoders go. I am looking to find out how other teams keep the robot going straight over long distances. Like you mentioned, an active feedback of the difference between the counts of the 2 sides. Does anyone have a sample equation?
Kevin,
The way we approached this a few years back was to implement an observer on the optical encoders that tracked the current state of the robot (i.e. x/y position and orientation) We then used a PID control loop using our state as the feedback, not the raw encoder values. This allowed us to see that we drove away from the line we intended to follow and turn back toward it.

I can explain how the observer was modeled if that sounds like something you'd be interested in. The model is very simple and the implementation was straightforward.

Cheers!
-Joe