Trouble with ADXRS453 Gyro

[alopex_rex]

This year we're trying to use an ADXRS453 gyro on our robot. (With this (http://www.digikey.com/product-detail/en/EVAL-ADXRS453Z/EVAL-ADXRS453Z-ND/2700448) eval board.) Yesterday we wired it up and managed to communicate with using the WPILib SPI class. We simply read the sensor data every time TeleopPeriodic was called, and integrated the results to get a measure of our heading. This worked extremely well, as in, the heading would not change at all while the gyro was sitting still, and changed as we would expect it to when we rotated it.

Then we go to work with it today, without changing the program, and it drifts like crazy. (Like, a degree every couple of seconds.) We wrote code to try and compensate for it, by sampling the rate for a couple seconds while it's still, and the values still oscillate and drift while the gyro is sitting still.

In another thread, members of several teams said they had used this gyro with success. Any idea what's going on? Any wisdom you can share about how to work with it?

[thatprogrammer]

Posting your code would help. :]

[Tom Line]

Please post your code as you go. We've got a couple of these gyros on the way as well, and are curious as to how to go about computing bias, etc.

[alopex_rex]

As of this posting, a little bit out of date, (also generally rough) but here you go:
https://github.com/FRC830/2015Robot/tree/master/util

ADXRS450Gyro.h and ADXRS450Gyro.cpp are the relevant files. The ADXRS450Gyro::Update() function gets called in TeleopPeriodic.

[wireties]

I took the previous posters code and improved it a bit - the drift is more than acceptable.

https://github.com/FRC1296/RHSRobot2015/blob/master/ADXRS453Z.cpp

Enjoy

[duane]

Thank you for sharing the code for the gyro. A couple of comments:

You used a Task and Timers rather than a notifier. Seems like a notifier could make the code easier, but there are also two timers which indeed complicate a bit. Are two timers needed? I'd have to read closer to work it out.

The floating point values are floats instead of doubles. Any particular reason? I'm used to thinking of doubles as being just fine for most uses. WPI Lib seems to use doubles everywhere.

The float values are being updated from a task and read from the robot loop. I think a mutex is needed to protect the values being read. Keep in mind that this year, we really do have multiple processors which means we should pay attention to atomic operations. I don't think a double or float is atomic.

This should be great for us to get going with the gyros.

I'll be happy to contribute to any changes we make.

...Duane
ps Gotta luv github!

[wireties]

Thank you for sharing the code for the gyro. A couple of comments:

no problem

You used a Task and Timers rather than a notifier. Seems like a notifier could make the code easier, but there are also two timers which indeed complicate a bit. Are two timers needed? I'd have to read closer to work it out.

I did not change the original code all that much. The changes you recommend make sense. One could use a single timer for both the calibration and update functions. I've not used a WPI notifier yet. Is it a wrapper for a counting semaphore? The gyro started working right and I wanted to get it to the students to work on their autonomous behaviours.

The floating point values are floats instead of doubles. Any particular reason? I'm used to thinking of doubles as being just fine for most uses. WPI Lib seems to use doubles everywhere.

I did not think the precision was necessary. One can only "point" the robot with a certain amount of accuracy anyways. Doubles will work.

The float values are being updated from a task and read from the robot loop. I think a mutex is needed to protect the values being read. Keep in mind that this year, we really do have multiple processors which means we should pay attention to atomic operations. I don't think a double or float is atomic.

Floats are atomic as they are word-sized on a 32-bit machine. But a more portable implementation would protect the data - good idea.

This should be great for us to get going with the gyros.

I'll be happy to contribute to any changes we make.

good luck!

adding averaging would be nice

ps Gotta luv github!

ditto

[orangelight]

Does anyone have the source code for java?