Anything better than a gyro?

[siggy2xc]

Is there something else we could use to accurately measure the rotation of the robot? The gyro we have slowly drifts off and within 2 minutes of driving around, its a good 30 degrees off. Or if we spin quickly then it gets thrown off by a large amount. We just need to know the direction we are facing relative to the driver. Maybe there is a better gyro or some sort of compass?

[Chris Hibner]

Originally Posted by siggy2xc

Is there something else we could use to accurately measure the rotation of the robot? The gyro we have slowly drifts off and within 2 minutes of driving around, its a good 30 degrees off. Or if we spin quickly then it gets thrown off by a large amount. We just need to know the direction we are facing relative to the driver. Maybe there is a better gyro or some sort of compass?

We've been using encoders attached to two dummy wheels for the last few years. It works very well. You can calculate the heading from the difference in the distance the two wheels have travelled.

[ajlapp]

Chris,

Do you recommend blending this two encoder technique with a gyro for increased redundancy/accuracy?

In our experience, the kit gyro provided last season had very little drift, though we use it in short burst only before resetting it.

[Joe Ross]

Different gyros have different maximum turn rates. Some that have been in the KOP in the past have been as low as 75 degrees/sec, which is easy to max out. If you used one of those, I would recommend getting a gyro better suited to your operation. We typically use gyros designed for 300 degrees/sec.

How much does your gyro drift when the robot doesn't move for 2 minutes?

If your gyro isn't mounted stably, you'd have problems.

[Chris Hibner]

Originally Posted by ajlapp

Chris,

Do you recommend blending this two encoder technique with a gyro for increased redundancy/accuracy?

In our experience, the kit gyro provided last season had very little drift, though we use it in short burst only before resetting it.

You can combine the two, and there are various techniques.

For Breakaway we had a problem with one of our encoder wheels losing contact with the floor when we drove over the lip near the tower. That caused our heading to get all out of whack. We wound up adding a gyro so we used the encoders up until we were within a few inches of the lip, then we'd switch to the gyro. Whenever we were using encoder-based heading we would constantly reset the gyro heading to the encoder heading. Once we switched to the gyro heading, we would keep track of a correction constant for the encoder heading once we switched back to the encoder based heading. It worked pretty well.

A project that I've been involved with at work combines inertial sensors (like the gyro) with wheel-based sensors. We have a novel way to combine them that I would love to share, but I'm sure my company wouldn't be happy if I did that.

In general, if you can solve the problem with fewer sensors, you're better off due to simplicity. Only add more sensors to solve a problem you can't solve otherwise.

[Sparks333]

Try a complimentary filter - it biases measurements depending on the frequency of the input. The gyro would be useful for high-frequency measurements, but will quickly drift in a low-frequency environment. An encoder, likewise, will probably be susceptible to wheel slippage at high speeds, but will work well when speed is slow. A very, very simple two-tap complimentary filter is simply to do:

total_rotation = 0.5*gyro_new - 0.5*gyro_old + 0.5*enc_new + 0.5*enc_old;
gyro_old = gyro_new;
enc_old = enc_old;

This is essentially a high-pass filter on the gyro with a low-pass filter on the encoder. This has the inherent flaw that it allows high-frequency noise from the gyro to enter the system, so a low-pass with a higher cutoff than the highpass filter might be required for the gyro first.

Hope this is useful.

Sparks