Wrong acceleration sign when reloading configuration

[martfrau]

I use the 3DM-GQ7 device and I have a problem with the sign of the z-component of the linear acceleration published on the imu/data topic. The sign is correct at first, but after loading a different parameter file and then switching back to the first configuration again, the sign is incorrect.

The following description should make this clearer:

1. The 3DM-GQ7 device is placed horizontally (its z-axis points downward).
2. The ROS2 driver is launched with the config_ned_ned.yaml file (see attachment): ros2 launch microstrain_inertial_driver microstrain_launch.py configure:=true activate:=true params_file:=config_ned_ned.yaml
3. The config_ned_ned.yaml uses NED convention (i.e. use_enu_frame is set to false), so I expect a negative z-acceleration. This is indeed the case: When checking the output of ros2 topic echo /imu/data --field linear_acceleration.z, I get a negative z-acceleration.
4. The ROS2 driver is stopped and launched again with the microstrain.yaml file (which uses ENU convention; see attachment): ros2 launch microstrain_inertial_driver microstrain_launch.py configure:=true activate:=true params_file:=microstrain.yaml
5. The z-acceleration is again negative (although this time the parameter use_enu_frame is set to true).
6. The ROS2 driver is stopped and launched again with the config_ned_ned.yaml file (like in step 2).
7. This time the z-acceleration is positive. So the sign changed although the same configuration was used as in step 2.
8. The ROS2 driver is stopped and launched again with the default configuration: ros2 launch microstrain_inertial_driver microstrain_launch.py configure:=true activate:=true.
9. The z-acceleration is negative as it should be.
10. The ROS2 driver is stopped and launched a third time with the config_ned_ned.yaml file (see step 2).
11. The z-acceleration flipped sign again and is now negative again.

In short: With the same config_ned_ned.yaml file I get at first a negative z-acceleration, then a positive one, and finally a negative z-acceleration again.

For me it seems that somehow the ENU configuration (used in step 4) is not replaced by the NED configuration in step 6. Thus the wrong sign is observed in step 7.

Environment (please complete the following information):

• OS: Ubuntu 22.04
• Architecture: x86_64
• ROS Version: Humble
• ROS driver: ros2 branch of this repo at commit 39b5c5f
• Sensor: 3DM-GQ7
• Firmware: Tested with versions 1.0.07 and 1.1.02

Modifications
No modifications were done.

Launch Parameters
The parameter files are attached below.

Additional Information
I made a screen recording which shows the steps described above. The corresponding log files are attached below.
A firmware update to version 1.1.02 did also not solve the problem.

attachment.zip

[robbiefish]

Thank you very much for the detailed information. I was able to reproduce this, and am looking into a fix right now

[robbiefish]

@martfrau This appears to be a problem with the sensor to vehicle transform in microstrain.yaml. It is essentially flipping the Z axis when it is run, and then in config_ned_ned.yaml you have disabled the sensor to vehicle transform which results in the flipping of the Z axis persisting between runs.

There are a couple solutions to this depending on what you are trying to do.

If you are just using microstrain.yaml as a test and don't actually plan to switch between the two, your config_ned_ned.yaml should work fine if microstrain.yaml is not used to launch the driver.

If you plan to switch between microstrain.yaml and config_ned_ned.yaml when actually running your application, you should set filter_sensor2vehicle_frame_selector to some non 0 value and then configure the sensor to vehicle transform you want to use in that configuration. That will override whatever microstrain.yaml has written and resolve this problem.

[martfrau]

Thank you very much for your support! Setting filter_sensor2vehicle_frame_selector to a none 0 value solves my problem.

I thought by setting it to 0 would result in no transformation at all (independent of how the transformation euler, matrix, and quaternion are configured). I did not expect that the "cached" transformation is used instead.

[github-actions]

This issue is stale because it has been open for 2 weeks with no activity. If the issue is still not resolved, please leave a comment describing what is still not working

[github-actions]

This issue was closed because it has been inactive for 2 weeks since being marked as stale. If the issue is still not resolved, please reopen the issue, and leave a comment describing what is still not working