The No Rotation Update is a feature that can be used to improve the MTi's internal estimate of biases on the gyroscope data. For a general introduction to sensor biases and their influence, we recommend first reading this article.
For the Roll and Pitch axes, the gravitational acceleration can be used to determine inertial sensor bias. This is however not possible for the Yaw/Heading axis. If the gyroscope (rate of turn) sensor data bias for the yaw axis is not determined properly by the MTi's on-board filters, then this may result in a drift of the Yaw/Heading estimate. Although the onboard filters continuously estimate sensor biases in the background, the No Rotation Update can very quickly (in a matter of seconds) help the online filters to determine sensor biases on all axes. It does this by informing the filters that the device will not move at all during a specified period of time. The MTi will use the data recorded during that interval to establish a high confidence gyro bias estimation within the filter.
Performing the No Rotation Update
A No Rotation Update can be performed in various ways. The most simple case is when using MT Manager. Open the MT Settings window, click the Device Settings tab and locate 'Gyro Bias Estimation'.
Figure 1: The No Rotation Update command in MT Manager.
You can simply set the period of the No Rotation Update, hold the sensor motionless, and start the procedure by clicking 'Estimate Now'. The default period of six seconds is recommended and sufficient for a decent No Rotation Update.
While a No Rotation Update is active, its corresponding status bit will be high, as shown in Figure 2. At the end of the NRU, there are two possibilities; either the status bit goes back to 0, indicating a successful update, or the status bit stops at 2/3, indicating a failed update. In the latter case, the filter has detected that the device has moved during the update and its result will therefore be neglected.
Figure 2: The status bits in MT Manager showing a successful No Rotation Update (left) and a failed No Rotation Update (right).
The No Rotation Update can also be performed using the SetNoRotation Low Level Communication command (MID 0x22). Note that in order to do this, the device has to be in Measurement mode, as live gyroscope data is required to estimate sensor bias. For more information on the use of this command, refer to the LLCP Manual.
Finally, the No Rotation Update can be performed by using the Xsens Device API. We recommend reading this BASE post for an example C++ snippet. Some processors (e.g. ARM) cannot use the XDA library. This BASE post shows an example C++ snippet for such cases.
Note that gyro biases may change during the warm up period, as they depend on temperature. It is therefore important to properly warm up the MTi before performing a No Rotation Update (at least 5 minutes, preferably 10 minutes or more). In addition, one could perform an update directly after turning on the MTi as well as after 10 minutes. Note that a failed NRU (as a result of movement during the update period) should not cause any additional errors - the NRU result will simply be rejected in that case. An exception is the case where the device is rotated at a very constant angular velocity during the full update period.
It is not possible to write sensor bias estimates to the MTi's internal memory (not even by clicking 'Write to MT'). The MTi will always initialize using the sensor bias estimates as determined by the factory calibration.
Finally, you may also notice that the inertial sensor data plots will not show a change after the No Rotation Update. This is expected behavior, as the gyro bias estimation only affects the internal states in the filter. The inertial data with biases removed is used in the internal sensor fusion filter to calculate an accurate orientation estimate. However when the customer uses the sensor's accelerometer or gyroscope inertial data outputs themselves, they will have to remove the biases. We do not remove the biases on the outputs with our internal bias estimation values, because we do not want the data to have unknown offsets that may change suddenly without the customer knowing what is going on (which would be very undesirable for many control systems).