Our team utilizes the ADIS16448, and the drift from the gyro can be rather significant. We get the angle using the function imu.getAngleZ(). My first thought was to call imu.reset(); throughout the match, but that turns out to be problematic because it will throw the errorINVALID CRC when calling the angle.
I mean, if imu.reset() doesn’t work, you could just simply create a wrapper around the IMU class that keeps a “zero” angle, and for each reading it just returns the sensor reading minus the “zero” angle. But since you’re using an IMU with a compass and accelerometer and everything, a Kalman filter might be able to give you very precise heading readings without drift. (Take it with a grain of salt as I’ve never done it myself, and the math behind it is quite complicated.)
The ADIS16448 is at least as good as if not better hardware than the NavX, but the software (e.g. applied filtering / sensor integration) doesn’t seem to be as good.
Per the ADIS16448 spec: gyro in-run bias stability is 14.5 degress/hour (0.24 degrees/minute)
Per the NavX Technical Docs: gyro yaw angle accuracy of 0.25 degrees/minute when still, 1 degree/minute when moving
I wonder if the sensor integration software for the ADIS16448 is actually degrading the output accuracy due to interferences like motor magnetic fields. It may be worth trying to just get the gyro angle rather than the IMU fully sensor-integrated angle?
Can I ask if you’re using the Pitch/Roll/Yaw functions or the X/Y/Z functions? Whenever you use any of the getAngleX() functions on the ADIS16448, you are actually only reading the raw gyro data. We had built AHRS into the library which integrated the magnetometer (the Pitch/Roll/Yaw functions in the library), but the various metallic structures on a robot and magnetic fields generated by motors, etc. can have a negative impact on performance as you mentioned above, so we generally discourage teams from using the AHRS algorithms in the 448 library.
That being said, nothing is stopping you from implementing your own sensor fusion algorithms though. This article explains a little more on how different environmental factors can affect sensor performance. Bias Stability doesn’t always paint the whole picture - it’s just the best drift you can get out of a gyro under ideal conditions (think on a bench in a lab). I think it’s safe to say FRC is definitely not ideal considering you have vibrations caused by gearboxes, a compressor, and crashing into other robots (or, in the case of this year’s game, falling off of platforms).
The functions to use the AHRS calculations for the ADIS16448 would be getYaw() and similar (or Get AHRS in LabVIEW), assuming you set the proper yaw axis when you declared and defined your IMU object in code. The library defaults to using Z (roboRIO/IMU mounted flat horizontally on the robot) if you don’t specify one.
However, I want to re-emphasize/clarify what I mentioned earlier:
Directly quoted from the ADIS16448 FRC user guide (which can also be found here):
“Due to the size of typical FRC robots, AHRS calculations that rely on the magnetometer may be adversely affected by motors and metal objects close to the sensor.”
Since the AHRS implementation in the ADIS16448 library utilizes the magnetometer readings (not the accelerometer) as well as gyro readings, you might see negative impacts on performance when using the AHRS functions in this library if the IMU is not installed in an ideal location, away from motors and large metal structures. This can be a bit difficult in the context of an FRC robot. The AHRS algorithm in the ADI library is actually different from that used in the navX libraries. The navX documentation goes over the different sensor fusion methods and mentions why the use of a magnetometer to correct heading isn’t as suitable in FRC.
By nature, all gyros drift, some worst than others.
The best solution would be to feed the gyro outputs into a Kalman filter along with all other navigation sensors, including accelerometers, a Navx if fitted with one and wheel encoders.
This is what most robotic navigators, such as the ArduRover or ROS-based robots, do.
I’m not sure the RoboRio has the computing power to handle a Kalman filter, or most of its variants, though.
Even the metallic structure of your typical institutional building will severely mess with the magnetic field in which the robot will attempt to navigate. So, yes, stay away from any algorithm that relies on compass/magnetometer readings.