Class ADXRS450_Gyro output angles?

[BitTwiddler]

We're using the AD XRS450 gyro module from the KOP this year. We need to know how the angles are output (we're using LabView) from this WPI library function. According to the C++ documentation the get_angle method returns an angle that continues from 360 to 361 and so forth. If so then our drive straight routine will need some pre-processing of the angle data before we use it. I don't want to invent something that might not be needed.

Can anyone verify that the ADXRD450 GetAngle() method does indeed output angles in the 0-360 degree and beyond range?

[jojoguy10]

Originally Posted by BitTwiddler

We're using the AD XRS450 gyro module from the KOP this year. We need to know how the angles are output (we're using LabView) from this WPI library function. According to the C++ documentation the get_angle method returns an angle that continues from 360 to 361 and so forth. If so then our drive straight routine will need some pre-processing of the angle data before we use it. I don't want to invent something that might not be needed.

Can anyone verify that the ADXRD450 GetAngle() method does indeed output angles in the 0-360 degree and beyond range?

We just tested with this sensor recently. We found that it did go past 360 (and also -360 if you turn it CCW).

(Disclaimer: We use Java, but that shouldn't matter)

[wt200999]

The angle is continuous, there is no code to wrap in the ADXRS library (so 360 to 361, or on the other hand, 0 to -1 etc). I attached the portion of code that does the actual accumulation which shows this is the case.

[BitTwiddler]

Originally Posted by jojoguy10

We just tested with this sensor recently. We found that it did go past 360 (and also -360 if you turn it CCW).

(Disclaimer: We use Java, but that shouldn't matter)

Thanks for verifying this for me. And thanks for the heads-up about the -360 degree aspect. I need to check to see if the pre-processing accounts for that possibility.

[BitTwiddler]

Originally Posted by wt200999

The angle is continuous, there is no code to wrap in the ADXRS library (so 360 to 361, or on the other hand, 0 to -1 etc). I attached the portion of code that does the actual accumulation which shows this is the case.

Is this the code that runs on the FPGA? If so, it never occurred to me that it would be written in LabView. I can see that all it really does is integrate the rate info over time. No real magic to it.
Thanks, this explains a lot.

[Ether]

You don't need to invent anything when dealing with a continuous angle sensor. It's already been invented.

The IEEEremainder function (supported in Java and C++) can take any angle and convert it to the range -180 to +180

You can also use it to find the shortest angle (magnitude and sign) between a setpoint and a process variable.

[wt200999]

Originally Posted by BitTwiddler

Is this the code that runs on the FPGA? If so, it never occurred to me that it would be written in LabView. I can see that all it really does is integrate the rate info over time. No real magic to it.
Thanks, this explains a lot.

The gyro code above runs in the background on the RIO itself (would be nice if it was on the FPGA, but doesn't happen in this case). You can find that code snippet if you look in the Gyro Open VI.

However I believe the FPGA implementation is also all done in LabVIEW using LabVIEW FPGA. Due to the parallel nature of LabVIEW it actually lends itself quite well to being compiled onto the FPGA.