Analog Devices

[billbo911]

Originally Posted by juchong

That's right! Shameless plug, I just updated the IMU driver to drastically reduce CPU usage in LabVIEW! Let me know if anyone has issues with it!

https://github.com/juchong/ADIS16448-RoboRIO-Driver

Juan,
First off, thank you for continuing to support this device!

We were fortunate enough to receive two of the ADIS16448 boards via FIRST Chiose. Based on this thread we chose to only use the gyro output data and not the Kalman filtered data for our headings.

Now that you are updating drivers..... Any chance you will be addressing this issue in Java code?

[Richard100]

The ADIS16448 retails for $850-$900 in single item quantities depending on where you source it, as far as I can tell. Is this what others see? Very nice that Analog Devices provided it in FIRST Choice this year. Given that there are other IMUs with similar functionality for less cost (AdaFruit breakout for 10-DoF IMU part #1604, at $30 and has the baro, for example ... no affiliation), what is special about the ADIS16448?

The technical specifications are difficult to directly compare, as they are not standardized across companies. Does anyone have the typical gyro drift rate for the ADIS16448?

For those teams that used the ADIS16448 this year, what do you think is distinctive about its performance? Did you use a sensor fusion algorithm to improve performance (such as Juan Chong's above, or other)?

I found the Bosch BNO055 IMU, which has integrated sensor fusion, to have good performance (no drift, good magnetic disturbance rejection). Cost about $35, or free from Digi-Key using this year's KoP voucher. Is this a higher performing product for the cost, or are there other considerations (output data rate appears a bit faster for the AD device, no baro or flash on BNO005)?

Has anyone performed side-to-side comparison between these IMUs? With the navX MXP?

[AustinSchuh]

Originally Posted by billbo911

We were fortunate enough to receive two of the ADIS16448 boards via FIRST Chiose. Based on this thread we chose to only use the gyro output data and not the Kalman filtered data for our headings.

Did you notice real world issues, or were you just being careful?

For autonomous, the drift is low enough without the filter that you won't have seen an issue. Probably for an entire match as well. The gyro in the ADIS16448 has noise properties of the ADXRS450, which would put it at 25 degrees/hr of drift.

Playing with the ADIS16448 properly is on my list of things to do this summer. Juan also recommended looking at the ADIS16460, which looks even more awesome. 6 degrees/hr of drift, and more dynamic range. I've been working through how to get a ground truth measurement (I think I can borrow a pair of GPS units and use those with drtk to get an accurate position) so we can try various algorithms and benchmark performance.

The ADIS16448 let us add some pretty cool features this year. We wrote a "down estimator" which estimated the direction of gravity using a gyro and 2 accelerometer axis. We used this in auto mode to detect when we crossed the defenses, and also to compensate our shot angle for the robot not being flat on the ground.

[billbo911]

Originally Posted by AustinSchuh

Did you notice real world issues, or were you just being careful?

Yep, just an over abundance of caution.

Originally Posted by AustinSchuh

For autonomous, the drift is low enough without the filter that you won't have seen an issue.

Agreed, we never had an issue in autonomous related to drift.

Originally Posted by AustinSchuh

Playing with the ADIS16448 properly is on my list of things to do this summer.

We do not have the programming resources to do this type of testing, thus we rely on the work and generosity of others. Therefore, I look forward to hearing what you find out.

[Richard100]

Originally Posted by AustinSchuh

For autonomous, the drift is low enough without the filter ...

Austin - Did you conduct the user calibration process or simply accept the factory calibration values?

Did you make use of the magnetometer?

Originally Posted by AustinSchuh

... looking at the ADIS16460 ...

The ADIS16480 has embedded sensor fusion, running an on-board Extended Kalman Filter. This puts it functionally on par with the Bosch BNO055. These 'Orientation Sensors', with embedded fusion algos, have ready low (or no) drift orientation outputs as well as stabilized gravity vector outputs - making for simpler/faster integration. (However, the ADI device appears to retail > $2k.)

[AustinSchuh]

Originally Posted by Richard100

Austin - Did you conduct the user calibration process or simply accept the factory calibration values?

Did you make use of the magnetometer?

We did a startup calibration (save the last 6 seconds of data, and re-zero when the robot enables), and did not use the magnetometer. Exploring factory calibration accuracy sounds like a good idea, thanks! We didn't really have time to explore many options during the season and opted to do what we knew from experience would just work.

Originally Posted by Richard100

The ADIS16480 has embedded sensor fusion, running an on-board Extended Kalman Filter. This puts it functionally on par with the Bosch BNO055. These 'Orientation Sensors', with embedded fusion algos, have ready low (or no) drift orientation outputs as well as stabilized gravity vector outputs - making for simpler/faster integration. (The ADI device appears to retail > $2k.)

I get to write kalman filters at my day job on good days For us, I'm less worried about embedding the sensor fusion algorithms in the sensor as I am about the quality of the sensor. A pre-built EKF will work well in the cases that it was designed for. By knowing your application more specifically (like that you have wheels and tend to move forwards, etc), you can make different tradeoffs in your filter design. A device with a pre-built EKF does save a bunch of time though when it works, as you aptly point out.

Juan recommended the ADIS16460 as an accurate sensor to be used by an EKF on the roboRIO.

[juchong]

Hi everyone! I had an interesting question pop up on GitHub that I thought might be of interest here. I also provide a bit of information on what we achieve with factory calibration and what the differences are between "factory calibration" and "drift calibration".

brhea on GitHub:

Is it really appropriate to store a drift calibration and use it every time. The ADIS16448 seems to drift less than other chips that we've used but it still exhibits drift. I thought the purpose of calculating a new drift calibration every time the robots are rebooted is to get a current calibration. I believe that the factory calibrates each chip and stores that calibration on chip. Storing a drift calibration and using the same one seems the same as the factory calibration.

My impression was that these chips have a different calibration every time they are started up and that it changes with the temperature, amount of ferrous metal in the surrounding building, etc.

I'm aware that if you don't perform the new drift calibration provided, the driver will behave as before and perform a calibration every time it starts. We would not want to lose this capability.

On another topic. Our team did not use the HUD last year because we had some issues in getting it to work reliably; we only used the axis variable. If you defined another item for the AHRS Algorithm enum, it could be set to "No HUD" and disable the filter and save some processor time. The algorithms seem to be pretty math intensive. If performing vision, etc. processor time is valuable.

Hi brhea,

The ADIS16448 IMU has much lower noise and does exhibit substantially less drift than other offerings. That being said, the factory calibration is meant to minimize orthogonality error (axis to axis misalignment) and changes in sensitivity (scale) across temperature. Unfortunately, no calibration can compensate for gyro drift in its entirety, but merely reduce as many sources of error as possible.

The "calibration" program included with the driver is perhaps a misnomer. Instead of calibration, this program should really be an "offset recorder". Using the default settings the program samples enough data to most effectively reduce drift (based upon the bias stability plot in the datasheet) and calculates an offset which is then applied to every sample. Even though a portion of the drift is due to uncontrollable noise sources, the drift characteristics will remain reasonably repeatable. Due to the nature of FRC and its short match times, this method of drift reduction is "good enough".

The 448 does have the ability to perform magnetometer soft and hard iron calibration, but both of these are unique to the application, mounting location, etc. and must be performed by the user. The 448, as with most MEMS and with the exception of the magnetometer, is mostly impervious to electromagnetic fields. As with any other electronics, given a high enough EM field strange things will begin to occur.

The user has the ability to revert to the original "power-on offset calculation" method after recording offset data. The only thing that he/she would need to do is delete the calibration file using the RoboRIO web interface.

I re-wrote the data-sampling portion of the driver and greatly improved CPU usage with some of NI's guidance, so I encourage you to give it a try! I'll work on incorporating an additional "Disable" case for those that are only using gyro integration. Both of the AHRS calculation algorithms should be fairly efficient, but "the proof is in the pudding". I'll add some comments to hopefully outline the performance trade-offs.

--------------------------------

As many of you have seen, I've updated the LabVIEW portion of the driver to include offset recording and real-time FIFOs instead of the previous calculation method. This should hopefully improve CPU usage!

I'd also like to see whether anyone would be interested in developing a position (displacement) calculation algorithm based around the 448. Please shoot me a PM if anyone is interested!

--------------------------------

Originally Posted by billbo911

Juan,
First off, thank you for continuing to support this device!

...

Now that you are updating drivers..... Any chance you will be addressing this issue in Java code?

You're welcome! We're excited to see teams using our sensors! I've locked down the IMU driver for the most part and it's currently being ported over to both Java and C++. Once we get closer to the beta, I may ask a few teams to help out with verification.

Originally Posted by Richard100

The ADIS16448 retails for $850-$900 in single item quantities depending on where you source it, as far as I can tell. Is this what others see? Very nice that Analog Devices provided it in FIRST Choice this year. Given that there are other IMUs with similar functionality for less cost (AdaFruit breakout for 10-DoF IMU part #1604, at $30 and has the baro, for example ... no affiliation), what is special about the ADIS16448?

The technical specifications are difficult to directly compare, as they are not standardized across companies. Does anyone have the typical gyro drift rate for the ADIS16448?

For those teams that used the ADIS16448 this year, what do you think is distinctive about its performance? Did you use a sensor fusion algorithm to improve performance (such as Juan Chong's above, or other)?

I found the Bosch BNO055 IMU, which has integrated sensor fusion, to have good performance (no drift, good magnetic disturbance rejection). Cost about $35, or free from Digi-Key using this year's KoP voucher. Is this a higher performing product for the cost, or are there other considerations (output data rate appears a bit faster for the AD device, no baro or flash on BNO005)?

Has anyone performed side-to-side comparison between these IMUs? With the navX MXP?

The greatest benefits to using our IMU are temperature, sensitivity, and orthogonality calibration. Gyro drift is specified on page 11 of the datasheet for both the gyros and accels using an Allan Variance plot. The lowest part of the plot (for the gyros) is located at about 30 tau (seconds), meaning that in order to achieve the best performance (lowest noise) you'd optimally have to sample for 30 seconds. This is also considered to be the "drift" number. Ideally (constant temperature, environment, etc) the 448 will exhibit 14.5 degrees/hour of drift when integrated over time.

Our sensors are also highly impervious to shock and vibration. Another often-overlooked parameter is vibration rectification error. Since these sensors will live on robots, this is a very important metric!

[billbo911]

Originally Posted by juchong

You're welcome! We're excited to see teams using our sensors! I've locked down the IMU driver for the most part and it's currently being ported over to both Java and C++. Once we get closer to the beta, I may ask a few teams to help out with verification.

When you are ready, please feel free to reach out to us. We will do all we can to help.