Now that the season is over does anyone know if Analog devices will be selling the IMU and if so where we can buy one
Please clarify, to which IMU are you referring?
the 10 DOF ADI IMU board from analog devices that was in FIRST choice this year. You can see them on here http://www.analog.com/en/landing-pages/001/FIRST.html
I was told that they were not selling them due to some contract with FIRST and would only be available this year in FIRST choice.
I spoke (very briefly) with an Analog Devices employee this weekend, and he said the issue is that if they sold the IMU it would be over the $400 limit for an individual component on the robot. Thus they provided them via FIRST Choice, making it a KOP item.
I do not know whether they have plans to sell them or not.
That is disappointing. Really wish i would have saw them on FIRST choice.
Maybe they will be around next year for testing. Any chance anyone on here has a spare one for sale?
Unfortunately, the module will not be sold to teams outside of FIRST Choice. The IMUs were donated by Analog Devices to FIRST, so FIRST owns the stock currently in FIRST Choice. That being said, I’m very confident the remaining stock shown in FIRST Choice will be made available next year. ADI may donate additional IMUs to FIRST Choice next season, so I would check back in a few months!
Strange, as I understand it, KOP items are exempt from the $400 limit. e.g. the $435 RoboRio…
And I know many teams will not use an item if they can get only one. I certainly won’t go to competition without a spare.
There was no limit on the IMUs. We got spares, and really enjoyed using them.
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!
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?
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?
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.
Yep, just an over abundance of caution.
Agreed, we never had an issue in autonomous related to drift.
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.
Austin - Did you conduct the user calibration process or simply accept the factory calibration values?
Did you make use of the magnetometer?
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.)
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.
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.
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!
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.
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!
When you are ready, please feel free to reach out to us. We will do all we can to help.