Step Response
The below results and discussion relate to testing done with version 7.2 of the NXP Sensor Fusion algorithm (as ported to the ESP platform in this project). Some earlier results using version 4.2 of the NXP Sensor Fusion algorithm (as incorporated in the Adafruit AHRS library) are found below.
Place the sensor on a rotatable test fixture. Let the heading reading settle. Manually rotate the fixture at between 50 and 250 degrees/second to a new position and hold the sensor stationary at that position for about 10 seconds. Record the heading as it settles to the new position. Then rotate the fixture back to another starting position and repeat. Use starting positions about 45 or 90 degrees in both directions from the stopping point.
The stopping point was the same in all the trials, but was visually determined so there is an estimated variability in the absolute position of the stopping point of about +/- 1 degree.
The heading settles to within about 2 degrees of the stopping point heading in about 1 second. There is a little undershoot, i.e. the heading appears to lag the true position slightly and catches up once the motion has ceased (as judged by the Rate-of-turn parameter from the gyroscope sensor). It was not noticed whether the amount of undershoot was related to the speed of the rotation.
Here is the entire test sequence with 15 trials. 
Each of the trials was shifted such that the stopping of motion corresponded with zero-time, and plotted with all 15 trials overlaid. 
The settling time after a large rotation seems acceptable. Most vessel motions will be of a slower and smaller amount, so the undershoot will likely be diminished as well (though this hasn't been tested). The repeatability of the heading at the stopping position was good, at about +/- 1.5 degrees, considering that the stopping position was visually judged using a mark on the wheel and therefore had a variability of its own of about 1 or 2 degrees.
It appears, based on these limited trials, that the version 7.2 algorithm is improved over version 4.2 in its ability to settle on the correct heading following a rotation. It is not known what particular change in the algorithm has accomplished this, or even whether it is due to an external factor. More experience using the version 7.2 algorithm may provide more certainty in this.
The below results and discussion relate to testing done with version 4.2 of the NXP Sensor Fusion algorithm (as incorporated in the Adafruit AHRS library). Results were not very satisfactory, mainly because of over/undershoot and/or long settling time once motion had stopped. See discussion.
Place the sensor on a rotatable test fixture. Let the heading reading settle. Manually rotate the fixture quickly (< 1 second) to a new position and record the heading as it (hopefully) settles to the new position. Then rotate the fixture back to the approximate starting position (to observe the response in both directions).
The general behaviour is approximately as expected - the heading adapts to the new orientation after the move. However, there is often a lot of over- or under-shoot in the response, and it takes many (> 5) seconds to close onto the new heading.
This behaviour is not always seen in the same magnitude and it is not yet known why. Compare the following two tests - the first graph shows a large oscillation as the heading converges; the second converges much more rapidly. However the second graph exhibits another undesirable characteristic - i.e. the heading does not always remain constant once motion has stopped.
Overshoot and undershoot is observed in the filter's Heading output when the sensor is exposed to a quick rotation. In the following graph, the heading output computed by three different filter algorithms (Madgwick, Mahony, and NXP Fusion) is plotted while the test fixture's wheel was manually held stationary, then rotated quickly by about 100 degrees, held stationary, then rotated back to the approximate starting position.
This graph shows the sensor reading for heading, plus pitch and roll. The latter two parameters are plotted against the second Y-axis, and they can be seen to be of small magnitude and to settle quickly. It is expected that the pitch and roll change with rotation, as the sensor is attached to the spokes of the wheel, which are not orthogonal to the axis of rotation of the wheel.
The under/overshoot seems much greater in magnitude than expected, but is not consistent. See the discussion by Kris on (https://github.com/kriswiner/EM7180_SENtral_sensor_hub/wiki/K.-Limits-of-Absolute-Heading-Accuracy-Using-Inexpensive-MEMS-Sensors). His apparatus does differ from the wheel used here: his sensor is mounted coaxial with the fixture and therefore would report very low accelerations while being rotated. Also, his method did not involve a quick step motion, rather he measured position at multiple stationary points with (presumably) the filter output settling after each motion. However, on a vessel it will be critical to respond correctly to abrupt surges/rolls/pitches etc. Regardless, Kris' results suggest that we should be able to achieve accuracy within 2 degrees and currently we see +/- 10 degrees or worse.
- not caused by exceeding maximum rotation speed gyro can report (currently 250 degrees/sec)
- doesn't seem to be caused by incorrect scaling of the gyro output, as a separate test in which the wheel was allowed to freely rotate showed that the rotation reported by the gyro corresponded within ~3% of the rate measured by a position sensor located on the rim of the wheel.
- the sensor defaults to not using the built-in 32-sample FIFO - i.e. the measured rotations are realtime, not buffered. So it does not appear to be caused by a temporal lag between actual motion and measured motion.