ADIS16485 Nulling

Question

We're using a ADIS16485 in combination with a new microprocessor, as a heading reference sensor (application has been working on a different micro for years). Most functionality is working OK; data ready line + interrupt driven SPI reads of (3) gyro + (3) accel + (1) temperature working good. We are running around 125 kbps SPI, and decimated output rate down to 153.8 Hz. We're using the "delta" values output of the gyro for heading integration. 
 In this application, we offer an external command to the HRS that kicks off a bias null cycle, to reduce heading drift. After implementing a nulling cycle algorithm, it doesn't seem that we're getting effective bias values that reduce drift. Even taking into consideration random walk, we're getting excessive drift, in excess of 1deg/min after bias is moved from CBE to manual bias registers. 
 So, a few questions: 
 
 Can you verify that our approach to nulling the gyro output is good?
 
 Generally, our nulling cycle steps are:
 
 (Ensure IMU is stationary for the duration of the nulling cycle) 
 Read out the manual bias registers, save off in the micro in case of jostle or other cancel during nulling 
 Set bias null timebase and flags 
 Write zeros to manual bias registers 
 Set (local to the micro) timer and wait for the appropriate time period to finish (we use 6.66s or 26s average time, mainly) 
 When timer expires, tell the IMU to update the manual bias register from CBE

We're seeing values in the manual bias registers after the last step, but still getting unstable heading output after integration (i.e. apparent rotation in our HRS heading output), almost as if the manual bias value is incorrect/insufficient

When the CBE is moved to the manual bias registers, does the value need to be adjusted due to the decimation rate that we're using?
 
 That is, after nulling cycle do we need to read out the manual bias registers, adjust for decimation rate (i.e. decimation period), then re-save? 
 We had assumed up to this point that the CBE was accommodating for the decimation rate.

Are most people using off-IMU resources to compute bias, rather than internal to the IMU as we are? Is our use case an expected usage of the bias registers? 
 
 Thanks in advance for your help! 
 Andrew

alex.nolan · Accepted Answer

Hello Andrew, 
 Thanks for reaching out. I have embedded some comments in your question below. 
 
 Can you verify that our approach to nulling the gyro output is good?
 
 Generally, our nulling cycle steps are:
 
 (Ensure IMU is stationary for the duration of the nulling cycle) -> Note, any motion will directly impact accuracy of bias estimate 
 Read out the manual bias registers, save off in the micro in case of jostle or other cancel during nulling 
 Set bias null timebase and flags -> Note, writing to NULL_CNFG flushes the bias data FIFO. Recommended use case is to set the desired value once at initialization and leave it during operation 
 Write zeros to manual bias registers -> Should not be needed, values will be overwritten w/ bias update command 
 Set (local to the micro) timer and wait for the appropriate time period to finish (we use 6.66s or 26s average time, mainly) 
 When timer expires, tell the IMU to update the manual bias register from CBE -> If you send command too soon after writing to NULL_CTRL, it will result in a shift in the bias estimate, due to FIFO entries of zero (not yet populated) being included in the calculated average of the FIFO. It is important to ensure that you have waited the full averaging time (plus maybe some margin), before issuing the null command.

We're seeing values in the manual bias registers after the last step, but still getting unstable heading output after integration (i.e. apparent rotation in our HRS heading output), almost as if the manual bias value is incorrect/insufficient

When the CBE is moved to the manual bias registers, does the value need to be adjusted due to the decimation rate that we're using?
 
 That is, after nulling cycle do we need to read out the manual bias registers, adjust for decimation rate (i.e. decimation period), then re-save? 
 We had assumed up to this point that the CBE was accommodating for the decimation rate. 
 The CBE accommodates for the decimation filter. Data is pushed into the CBE FIFO at the base sample rate of the system, before the decimation filter.

Are most people using off-IMU resources to compute bias, rather than internal to the IMU as we are? Is our use case an expected usage of the bias registers?
 
 You are using the CBE functionality as intended. The CBE can be effective if you have a good ability to ensure the system is stationary for the full duration of the averaging interval, but it is a fairly simple method for compensating gyroscope bias errors (moving average). A common approach for off-IMU bias compensation is to use a Kalman filter to estimate the gyroscope bias errors, leveraging the relative stability of the accelerometer to accommodate for gyro drift dynamically. This is more computationally heavy than the moving average of the CBE, but can offer some significant advantages in estimating gyro bias continuously, even in the presence of motion.

Mathworks provides a lot of good reference material on Kalman filtering for IMU systems. You can also take a look at the ADIS16480 (same form factor as the ADIS16485), which includes a Kalman filter for estimating pitch/roll/yaw. 
 https://www.analog.com/media/en/technical-documentation/data-sheets/adis16480.pdf 
 Hope this helps, 
 Alex Nolan

Electronic Design Services - PartnerZone

ADIS16485 Nulling

Top Replies