Orientation convergence after hard hits is very slow

[peci1]

Describe the bug
When the IMU gets a hard(er) hit (e.g. slapping it against a table), orientation accumulates some error which is then very slowly converging to the correct values. The convergence time is on the order of 30 seconds, and all the time in between, the reported orientation is wrong.

This was tested with a 3DM-CV7-AHRS running this ROS 2 driver (ROS Kilted). I tested it on two independent units, one table-top, and one integrated inside a robot.

To Reproduce
Steps to reproduce the behavior:

1. Launch the node, i.e. in launch file with <include file="$(find-pkg-share microstrain_inertial_driver)/launch/microstrain_launch.py"><arg name="params_file" value="...imu.yaml" /></include>
2. The config file is listed below.
3. Make slow changes of orientation -> everything is okay
4. Make fast changes of orientation -> everything is okay
5. Slap the IMU against a table several times in succession - there is some error accumulated in both roll and pitch, and this error shows extremely slow convergence.

Expected behavior
Hard hits should only have very time-limited effect on the absolute orientation.

Environment (please complete the following information):

• OS: Ubuntu 24.04
• Architecture: amd64
• ROS Version: kilted
• Version: 4.8.1
• Sensor(s): 3DM-CV7-AHRS

Modifications
No

Launch Parameters

imu.yaml

Additional context
A normal imu_filter_madgwick shows a much saner solution.

I've recorded a video of the problem and also a bag file, both are available at https://drive.google.com/drive/folders/1XHkVMp7_PIkJYf4jnwnpnZ8hjyirxryN?usp=drive_link . The video shows plotjuggler with 3 rows of roll/pitch angles: top row is /imu/data, medium us /ekf/imu/data, the bottom one is /imu/data_madg (i.e. the madgwick filter).

[peci1]

CC @herolada

[peci1]

This is a visualization of the output of the internal filter:

The slapping on the table started where the blue vertical line is, and convergence was achived where the red vertical bar is, 28 seconds later.

[peci1]

From Microstrain support:

---

Barry Trutor commented:

Martin:

Thank you for your email and thank you for being our customer.

Item 1

Reference is made to the 3DM-CV7-AHRS Documentation Center, and more particularly, the Mechanical Shock Limits page: Mechanical Shock Limits

Here you will read:

The accelerometers used by the IMU are sensitive instruments that can suffer mechanical damage if subjected to large or frequent accelerations beyond their rated range while in operation. To protect themselves from occasional over-range events, the accelerometer’s control circuitry will temporarily reduce drive power to the sense element if acceleration exceeds twice the full-scale range. While this protective mode is enabled, the reported acceleration values will be inaccurate and will appear to drift towards zero. Normal operation will resume after sensed acceleration returns to an acceptable level.

It is essential to note that, even with this automatic protection circuitry, repeated exposure of the accelerometer to shock and vibration acceleration levels exceeding twice its full-scale range will cause excessive mechanical wear. Over time, damage can accumulate and may cause the device to become defective. Care should be taken not to subject the sensor to accelerations beyond twice the full scale range during normal operating conditions.

Item 2

The filter on the 3DM-CV7-AHRS calculates roll and pitch by integrating the accelerometers (acceleration) and angular rates (gyroscopes).

Item 3

Your test regime of slapping the 3DM-CV7-AHRS on the desktop is 1) significantly over-ranging the accelerometers, thereby causing error in the roll and pitch calculation, and 2) potentially causing the accelerometers to prematurely fail. As stated, this is a precision instrument with limitations to the physics it can endure. If your application requires the inertial sensor to survive and accurately measure such physics, this is not the correct instrument for the task.

Best.

Barry Trutor

[peci1]

My answer to Microstrain support:

---

Dear Barry, please, look at the data. I don't think you have paid enough attention to them. In the provided MCAP recordings, you can clearly see that neither the accelerations nor the angular rates exceed the limits. The accelerations are within +- 3g and angular rates are within +- 4.5 rad/s ~ +- 260 dps. Topic /mip/sensor/overrange_status is all zeros in the test recordings.

Task 1: Please, examine the issue again with the above knowledge on mind.

I've faced another issue now - there seems to be no way in the API to actually know which range limits are in use by the IMU. I know there are commands 0x52 and 0x53 that can set the range limits, but there doesn't seem to be any command that would confirm which mode is actually in use by the unit. I somehow thought the the smallest limits would be the default, but it doesn't seem so because in some recordings I see accelerations up to 5g, which is more than the 4g limit.

Question 2: Is there a command that would tell me which range limits are currently in use by the IMU?

Question 3: What is the default range limit for each sensor when I do not set them explicitly?

Could you please describe in detail what do the range limits precisely mean? I.e., if the range limit of acceleration is 4g, does it mean that under no circumstances the IMU can output anything higher than +- 4*9.81 m/s^2. Or is it a kind of soft limit and numbers slightly above the limit values are expected to be seen?

Question 4: Please explain precisely the meaning of range limits.

Question 5: When the unit measures overrange values, does it go to saturation and output some maximum (constant) value until it recovers?

Also, the docs are silent about possible influence of the range limits to resolution. Other IMUs usually have it as a compromise between larger range and better resolution, i.e. larger range means coarser resolution. Is this also the case for Mircrostrain IMUs?

Question 6: Do range limits of a sensor influence its resolution or accuracy?

Thank you for answering my questions.

Martin

[peci1]

My email to Microstrain support:

---

Okay, I've resolved some of my questions already. It seems our sensor starts up in the middle ranges by default, i.e. 500 dps and 8 g. But I don't know if this is a universal rule, so my question remains.

I've also already found the APIs to read the currently set values for ranges. I've created a pull request adding support for reading and setting them to the ROS driver: LORD-MicroStrain/microstrain_inertial_driver_common#108 .

I also did some more table-top experiments to determine the overrange behavior. It seems to me the sensor does not have a constant overrange value, but it reports values very close to some threshold (however, they differ a bit from each other). Also, the threshold doesn't seem to be exactly 500 dps and 8g, but a little bit more or less. I've seen overrange status to switch to 1 for gyro, but I haven't ever seen it being triggered for the accelerometer, even when it shows values that are actually very close to the range limit. Is it needed that the overrange situation holds for some time for the flag to become active? I've mostly observed saturation of accelerometers just for a single measurement, so maybe that's not enough to flip the flag?

[peci1]

Response from Microstrain support:

---

Please, examine the issue again with the above knowledge on mind.

Respectfully, I again reiterate that your test regime of slapping the 3DM-CV7-AHRS on the desktop is 1) significantly over-ranging the accelerometers, thereby causing error in the roll and pitch calculation, and 2) potentially causing the accelerometers to prematurely fail.

In your ROS support ticket, you show this occurrence in roll and pitch:

This is a secondary issue falling out from the slapping.

This occurrence is caused by vibration rectification error in the gyroscopes.

The attached technical note entitled CV7 Vibration Isolation Tech Note provides some detail.

CV7 Vibration Isolation Tech Note.pdf

Is there a command that would tell me which range limits are currently in use by the IMU?

Yes.

You can get and set the range limits using these commands:

Sensor Range (0x0C,0x52)

Get Calibrated Sensor Ranges (0x0C,0x53)

What is the default range limit for each sensor when I do not set them explicitly?

Accelerometers = +/8g

Gyroscopes = +/500 degrees/second

Could you please describe in detail what do the range limits precisely mean? I.e., if the range limit of acceleration is 4g, does it mean that under no circumstances the IMU can output anything higher than +- 4*9.81 m/s^2. Or is it a kind of soft limit and numbers slightly above the limit values are expected to be seen?

Please explain precisely the meaning of range limits.

The range limits are the measurements that the sensor will accurately measure.

The sensor can output measurements that are beyond the range but those measurements are suspect at best, and should not be considered accurate.

When the unit measures overrange values, does it go to saturation and output some maximum (constant) value until it recovers?

No.

It outputs what should be considered garbage values until it recovers.

By observing the validity flags, the filter state, etc., one can utilize the filter’s own determination of what is valid or invalid.

Also, the docs are silent about possible influence of the range limits to resolution. Other IMUs usually have it as a compromise between larger range and better resolution, i.e. larger range means coarser resolution. Is this also the case for Mircrostrain IMUs?

Do range limits of a sensor influence its resolution or accuracy?

Yes.

The greater the range, the granularity of the resolution lessens, and the accuracy of the measurement lessens.

The tighter the range, the granularity of the resolution increases, and the accuracy of the measurement increases.

[peci1]

My email to Microstrain support:

---

Thank you for the answer and clearing some of the concerns.

I still think you overestimate the slapping. It was nothing harsh. I attach a plot including accel and gyro readings, where you can clearly see that accelerations did not go much above 2 g and gyro rates were well within 500 dps (there is a 500 dps part near the end of the plot, but the convergence problem appears after a segment with 300 dps at most). I wouldn't call this significant over-ranging. As already said, /mip/sensor/overrange_status is all zeros all the time. So either the protection mechanism fires prematurely, or the range limit is wrong.

Thank you for pointing me to the VRE note. I see what it says about the problems, though I thought it only applies to much harder shock than normal accelerations within the range bounds. I don't think that VRE is the problem here. The gyro and accel outputs both fall back to steady/unbiased values very quickly, while the roll an pitch estimates are bad for quite some time. Also, as stated in the original issue, a simple Madgwick filter works well on these data. So I'd say that gyro and accel data are good and the problem is in the onboard fusion.

Could you please quantify the resolution values for every choice of range?

Thank you, Martin

[peci1]

Reply from Mircostrain support:

---

I spoke with our senior physicist who is also our inertial Kalman filter designer and we have not characterized the resolution values for every choice of sensor range. I’d like to accommodate you but the work to accomplish this has not been done by engineering.

[peci1]

My reply to Microstrain support:

---

Thank you for your help, Barry.

I still have two remaining questions.

Question 1: You say resolution has not been determined for various range settings. Are you sure you are talking about resolution and not accuracy? In my understanding, resolution is (among others) a property of the discretization, e.g. the number of ADC bits available and the multiplier of them. Of course, there are also other factors that influence resolution, but looking at the datasheets of other IMUs, most seem to agree that this range/resolution tradeoff is really mostly about the ADC bits and their multiplier. I.e., twice the range, twice the minimum difference between two distinct output values.

Question 2: I have carefully reviewed the vibration isolation tech note. I understand that repeated shocks can influence the bias of gyros. I have also carefully reviewed the data attached to the github issue, but I don't see any bias being introduced to the gyros or accelerometers (except for the moments of the shocks, where I of course don't know the correct values). Please, have a look at the attached visualization of the data where I zoomed gyros and accelerometers close to their steady state values. I don't observe any longer-term bias in any of the measurements that would explain the roll/pitch error. The fact that a third party orientation filter is able to produce much better results on the same inputs strengthens my assumption that the problem is not in the measurements but in the internal filter used by CV7. Could you please show me parts of the data where do you think the unit is affected by the VRE or other documented mechanisms that can result in bogus measurements? I will just repeat that overrange status is all zeros in this experiment and the unit was using the default range, i.e. 8g / 500 dps and all measured values were within this range.

If I should explain what I see in the data, I'd guess that the filter (is it (E)KF, or Madwick, or complementary filter?) gets wrong roll/pitch because of the shocks and then it puts too much weight on gyro measurements that tell it that the orientation is not changing, while the accelerometer suggest something very different. So the orientation very slowly drifts to the one suggested by the accelerometers while not violating the gyro measurements too much. For our application, we'd need this weight on gyros to be much lower.

PS: I copy/paste this communication to the github issue because it contains information other users could also find quite useful. If you don't like this, please tell me and I will delete the posts.

Thank you,

Martin

[peci1]

Response from Microstrain support:

---

Question 1: You say resolution has not been determined for various range settings. Are you sure you are talking about resolution and not accuracy? In my understanding, resolution is (among others) a property of the discretization, e.g. the number of ADC bits available and the multiplier of them. Of course, there are also other factors that influence resolution, but looking at the datasheets of other IMUs, most seem to agree that this range/resolution tradeoff is really mostly about the ADC bits and their multiplier. I.e., twice the range, twice the minimum difference between two distinct output values.

I am discussing resolution and as you say, one aspect of that is A/D conversion but the final resolution is a much more complex calculation due to the filtering and other factors. Again, we have not done the characterization of the many combinations of sensor settings.

Question 2: I have carefully reviewed the vibration isolation tech note. I understand that repeated shocks can influence the bias of gyros. I have also carefully reviewed the data attached to the github issue, but I don't see any bias being introduced to the gyros or accelerometers (except for the moments of the shocks, where I of course don't know the correct values). Please, have a look at the attached visualization of the data where I zoomed gyros and accelerometers close to their steady state values. I don't observe any longer-term bias in any of the measurements that would explain the roll/pitch error. The fact that a third party orientation filter is able to produce much better results on the same inputs strengthens my assumption that the problem is not in the measurements but in the internal filter used by CV7. Could you please show me parts of the data where do you think the unit is affected by the VRE or other documented mechanisms that can result in bogus measurements? I will just repeat that overrange status is all zeros in this experiment and the unit was using the default range, i.e. 8g / 500 dps and all measured values were within this range.

The event circled in red is VRE.

[peci1]

The support ticket got closed as Done. So I guess the conclusion is Microstrain thinks this is okay and they won't fix it. One more sensor that could have been great but it needlessly isn't...