odom velocity mesaurement are not relative to vehicle frame

[martfrau]

This issue continues issue https://github.com/LORD-MicroStrain/microstrain_inertial/issues/275. I opened it since the old issue was closed but the bug is not solved yet.

I tested the bugfix/ros2_vel_in_sensor_frame branch with the 3DM-GQ7 device and it is not working correctly.

This is my setup:

• Device: 3DM-GQ7
• Firmware: 1.1.02
• Distribution: ROS2 Humble
• Mounting: x-axis pointing forward, y-axis pointing to the right, and z-axis pointing downward

I drove a short round in clockwise direction for each of these 4 parameter configurations:

• ENU ENU: use_enu_frame:=true and filter_vel_in_vehicle_frame:=false
• ENU VEH: use_enu_frame:=true and filter_vel_in_vehicle_frame:=true
• NED NED: use_enu_frame:=false and filter_vel_in_vehicle_frame:=false
• NED VEH: use_enu_frame:=false and filter_vel_in_vehicle_frame:=true

As can be seen in the following plot, the x-acceleration (topic imu/data; field linear_acceleration.x) is positive during the first 6 seconds for all configurations. But the x-velocity (topic nav/odom; field twist.twist.linear.x) goes negative even though the x-axis points forward and filter_sensor2vehicle_frame_transformation_euler:=[0.0, 0.0, 0.0].

I have attached the 4 parameter files used during the measurements: parameter_files.zip

[acascone]

I think I've seen something similar. We've been working with ROS1 version of this feature and observed inconsistency with the velocity information being properly transformed into the the vehicle/sensor frame. We have some data collections that look aligned with the sensor, ie forward velocity aligned with the x axis even as the orientation changes. Then we power cycle the sensor and the velocity's appear to be in some other frame. I haven't yet been able to confirm what the frame that is, but will try to collect more runs this morning to determine what is happening.

It's my understanding on the ROS1 side that this change has been rolled into 3.2.1 which is the current packaged version for noetic. This is what we've been running with.

We're not clear on why we're seeing the inconsistency. We might not have configured something correctly. It's just odd that some times the data looks great, and others where things are off, and the only change is that we power cycled the system.

[github-actions[bot]]

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

[dschmag]

@acascone Any new insights?

[acascone]

We tabled using the velocity data from the device due to the issues we had been seeing. Since that point, we realized we were seeing some rotational drift issues on startup which caused various issues. We began making a service call for the gyro calibration and the sensor outputs have generally appeared more stable, but we haven't revisited the velocity data. Our prior bags are probably irrelevant. If I get some time, I can look at more recent data and see if that addressed our issue.

[nathanmillermicrostrain]

Hello,

From the original plot above, it is apparent that the filter is performing poorly due to the saw-toothing in the velocity information. This points to the heading being incorrect and the filter integrating the acceleration in the wrong direction. This typically occurs when there is a setup issue, such as the antenna offsets being incorrect if using dual antenna heading. Multipath can also cause an incorrect heading initialization in certain circumstances. I would check that the reported heading matches reality.... with the correct heading, the velocity should be as expected. You can also monitor the filter status to check for warnings, which should enumerate in the case of the saw-toothing shown above.

Hope that helps,

Nathan

[martfrau]

I updated the ROS2 driver to v4.0.0 and made sure that the antenna offsets are configured properly. Both the heading and the velocity are now correct and I experienced no issues anymore. We may close this issue, if @acascone's problems were indeed solved with gyro calibration.

[acascone]

Fine to close for now. We will revisit when we have more time.