Tracking wheel odometry imbalance

VEX V5 Technical Support UNOFFICIAL Tech Support
#1

SEE POST BELOW BY ME FOR LATEST QUESTION!

So we have discovered that our 3-wheel tracking setup or odometry (coded in PROS using okapilib) is consistently reading the correct heading of around 0 degrees when turned 360 degrees (by-hand) clockwise, but around -15 degrees (345 degrees) when the same is done but anti-clockwise (or counter-clockwise for Americans!). We know that the quad encoders themselves work perfectly fine and the code is unlikely to be the issue since turning one wheel at a time (when the robot is upside down) produces consistent heading readings, both encoders, both directions. We therefore believe that it is some kind of mechanical issue, however both left, right and center tracking wheels are evenly spaced to the nearest 3mm or so. Each wheel is elasticated downwards on levers.

#2

I’ve never used okapilib, but I can take a look at your code maybe. It is probably not a mechanical error considering it works properly in one direction. The odds of an encoder mechanically failing in only one direction are low (really low).

The way the quadrature encoder works is by detecting changes in light caused by a symmetrical rotor. If the only way you’re retrieving heading data is by approximating through the encoder values, then either the way you set up your chassis in okapi is wrong or your code is wrong.
unnamed

Try using this formula:

lEncoder - rEncoder / (lDistance + rDistance)
where the difference between the change in encoder value from the last update is divided by the sum of the distance of each tracking wheel to the tracking center. This will return the updated change in heading value in radians (multiply by 180/Ď€ to convert to degrees). The derivation for this formula can be found on the Pilons odom document.

10 Likes
#3

We have now managed to balance turns by increasing the power of the elastics by 2-3 times, 4 times would probably raise the back drive wheels off the ground! We are using the same elasticity for the middle tracking wheel, however, by using the correct middle wheel distance parameter, the odometry appears to drift quite considerably to the left (negative x) over the course of an autonomous. I am using okapilib’s odom chassis controller so the algorithm cannot be the problem, however the chassis dimensions or some other mechanical issue may be causing the problem.

Any ideas?

#4

How reliable is it if you don’t add the 3rd tracking wheel programmatically?

#5

It now appears that the angle is causing the error, the robot thinks that the heading is out and this puts the middle tracking wheel out. To combat this, I have measured the scale factor for turning error, which seems to be consistent and have scaled the wheel track dimension accordingly. This is not a nice fix, however it does make it far more accurate. I would like to be able to use the correct dimensions and still achieve accurate results, any reason why this scaling would occur?

#6

This sounds like you have a huge friction issue either on the tracking wheel pivot point or on the wheel’s axis of rotation. One mildly stretched #64 rubber band (I can’t give you an exact torque value applied to the tracking wheel, but it isn’t significant) should be enough to keep the wheel on the ground.

In that case, it is very possible that your parameters are off. Make sure you’re using the correct units everywhere. Without you providing your code, or more details of your tracking wheel assembly (perhaps an image), I can’t really provide specific feedback.

2 Likes