Yaw Rate Sensor Drift?

[phrontist]

I've heard that accellerometers are plauged by drift, by which I mean they slowly build up innaccuracy to the point of uselessness. Are yaw rate sensors similarly afflicted?

[MattK]

yes, from what I hear anyway....

wait let me think about this for a bit....

okay new conclusion- I think they can get "dizzy" but if 2 were used you could take the average reading between the 2 and it would dampen the effect.

[phrontist]

The averaging method is crude at best. Is the problem surmountable through sheilding?

[MattK]

I have a friend who will know- I'll check with him. We had a convo in a elevator one day about using 1 something... I cant recall if it was a tilt sensor or a gyro- I think gyro but I cant be 100% sure.

Anyway whatever it was will build up huge inaccuracies over only a few min.

[EricS-Team180]

Hi,
Last year we used an Analog devices adxrs150abgnd yaw rate sensor. It had 2 purposes:
1) use it to detect undesirable yaw rate and trim it out
2) integrate the yaw rate to give us a "poor man's electric compass"

Hooking it up as a 10 bit analog input gives you a 0-1024 range. So the theoretical neutral point is 512, 0 and 1024 represented +/- 150deg/sec...which is really not that fast of a turn rate. Anyway, in practice we found out that the neutral point was typically biased somewhere away from 512 and that the input "dithered" about neutral. What we did to compensate was:
1) during comp mode ( the time between power up and autonomous), we simply averaged the input with the previous, which allowed us to determine whatever the neutral point would be for that particular time of day, temperature, phase of moon ...etc
2) we set up a deadband (we settled on +/-11) about the neutral point. Anytime we read a value inside the deadband, we stored it as 0.

This worked great as a yaw trimmer, and OK as a "compass" - really a yaw position calculator - not a North/South direction finder.

Since we could not mount the sensor on the c/g, we had an inherrent error. I also speculate that mounting it in the chassis pan close to wiring, speed controllers, and motors may have been adding electrical interference - but I have no proof. In the end we moved the sensor away from the electronics - as much as possible and tucked it in as close to the c/g as we could. With trig of 2 decimal place accuracy, we averaged about 1.7deg of error over 360deg of rotation....something we'll definitely improve on. To compensate for that error, we added an additional operator reset switch. The driver could always re-align our 'bot with the up-field direction as re-zero the compass.

Hope that helps
Eric

PS we are also experimenting with an x/y accelerometer, which shows similar behaviors

[Astronouth7303]

I don't think gyro sensors are affected my electro-magnetic interference (They don't use N/S to determine orientation). But the transmission of the data may be...

The gyro we used was some-what off center, and did require a deadband. But that center basically stayed put.

As for a compass, you only really need to know ''forward": the orientation of the robot on the field. A cumulative counter is best (I think), and hopefully any errors that creap in counter-act each other.

[Andrew]

Originally Posted by EricS-Team180

Since we could not mount the sensor on the c/g, we had an inherrent error.

We used an analog devices yaw rate sensor last year in much the same way that you did (except for the dead band). For the very short time needed to feedback on heading (the 15 seconds of autonomy), the minor dither associated with the resolution of the ADC was not noticible. I'm pretty sure there is a signal processing algorithm to detect a constant bias from a stream of data which would have allowed us to null out even this minor annoyance.

BTW, the angular velocity of all points in a body is the same, regardless of location. The yaw rate sensor detects angular velocity about its measurement axis. Putting the sensor somewhere other than the c/g does not affect the measurement.

[EricS-Team180]

Originally Posted by Andrew

Putting the sensor somewhere other than the c/g does not affect the measurement.

DOH! Andrew, you are so right!

When I read - on the analog devices site - that the chip detected the Coriolis motion, I got it in my head that radial placement would affect the measurement. Your comment made me go back and look at a derivation of Coriolis force ( http://www.scienceworld.wolfram.com/...olisForce.html is a nice one ). It is, indeed, independent of radial position.

my bad

Eric

[phrontist]

Originally Posted by EricS-Team180

This worked great as a yaw trimmer, and OK as a "compass" - really a yaw position calculator - not a North/South direction finder.

Very helpful post, thanks!

When you say you used it as a yaw trimmer do you mean that it was used to correct the robots steering? I was thinking about this and I figured that the errors would build up to the degree that the sensors would give such faulty information that the robot would no longer be operable. I take it this isn't the case?

[Mark McLeod]

Originally Posted by phrontist

When you say you used it as a yaw trimmer do you mean that it was used to correct the robots steering? I was thinking about this and I figured that the errors would build up to the degree that the sensors would give such faulty information that the robot would no longer be operable. I take it this isn't the case?

It works great as a yaw trim to correct stearing due to the relatively short distances involved in a single movement on the field. The drift error builds up over time so it affects absolute position the most because your comparison is to the original starting position of the robot and that gets further and further away in time as the game goes on and drift increases over time.

Yaw trimming on the other hand can be thought of as being broken up into separate distinct movements (like backing up, going straight ahead, then a curved forward or backward movement). Yaw trim doesn't require an absolute heading, but a relative one. Each distinct movement applies the gyro from only the beginning of that distinct motion which is a much shorter time for drift to have an opportunity to enter the equation.
For instance, suppose that halfway through a match the gyro drift results in a cumulative error of 5 degrees. The driver starts a forward movement in the original starting direction, but the RC uses the new gyro output of 5 degrees as the heading to maintain. If you're at the end of autonomous and start driving a new direction then you might be pointed in the wrong direction overall because of the total drift, but you'll drive straight as an arrow for that one motion.

[EricS-Team180]

Nicely put, Mark...

We used a slightly different approach in that we built a simple proportional control with the yaw rate (as opposed to the integrated yaw position) as the input. The intent was to keep the yaw rate to a value of zero, when driving straight.
Since we had a chassis with omni wheels, this year, "straight" meant translation in any direction (in the plane of the field) without rotation. Our control inputs included a joystick for translation and a pot (with a spring return) for rotation. The output of the yaw rate trimmer was an "adder" to the rotation input. But, since the trimmer was only active when the operator was not requesting rotational input with the pot, the 2 did not fight each other...that is the rotational input either came from the pot or from the trimmer...not both.

Thanks,
Eric

[bheller]

Where did you find a spring return pot? The closest I've been able to find are 2-axis joysticks.

[EricS-Team180]

Originally Posted by bheller

Where did you find a spring return pot? The closest I've been able to find are 2-axis joysticks.

We found some "Gamestick 3-d" sticks on line, from CH Products. They were cheap....both in $$ and quality. Twisting the stick provided an output on the aux pin but the twisting axis worked poorly. The pot was poorly mounted, and moved around so much, that we were constantly getting input, when it should have been zero-ed. (There was also no cal wheel for it) We at first, scrapped them and tried driving with another 2 axis stick, by using the x-axis input as a rotate left or right. That worked, but we did not like the handling quality of the 'bot with that type of input. Finally, (I believe it was) James Jones, gutted a Gamestick and re-worked it with a pot from the Kit of parts...(correct me if I'm wrong fellow SPAMers)

Eric

[Warren Boudreau]

Originally Posted by EricS-Team180

Finally, (I believe it was) James Jones, gutted a Gamestick and re-worked it with a pot from the Kit of parts...(correct me if I'm wrong fellow SPAMers)

Eric

Close. I think it was Glen who took a second joystick, removed the handle, then stood the base on end and attached a handle directly to the x-axis pot. It was already spring loaded and still had trim capability. It looks funny, but it worked.