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".
Quote:
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.
|
Quote:
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!
--------------------------------
Quote:
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.
Quote:
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!
I don't think 330 should have built 330's 2016 robot - Joe Ross [more] 
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.
03-08-2016, 01:26
Linear Mode
