Requesting clarification on GQ7 ROS Driver
mgoli-cav opened this issue · 5 comments
I am using the latest ROS driver from source. It seems with the recent updates the default IMU/sensor frame for publishing IMU data is in ROS standard ENU frame (use_enu_frame : True). Is it safe to assume that the IMU data is now getting published wrt to the RGB frame shown below but on the same origin of the original frame?
Moreover, I have integrated this GQ7 on a Husky rover from Clearpath Robotics. When I run the ROS driver -from source- and check the IMU data at imu/data topic, the time stamps is not consistent with let’s say the odometry/filtered topic (it start close but diverge after some time passed). The result of ekf_localization (published to odometry/filtered) when subscribing to imu/data (published to by the GQ7) is not reliable neither.
I appreciate any advice, and/or resources/documentation on this matter.
To answer your questions about the frame in your picture, that is indeed correct.
I am currently working on putting together an example configuration for using a GQ7 with ekf_localization and will post it here when it is finished.
Thanks for the confirmation. Any update on the example configuration for ekf_localization?
The microstrain_inertial_localization repository contains an example of providing raw IMU data to an ekf_localization node.
For examples of the configuration, see this section for ROS and this example file for ROS2.
Additionally, when you originally posted the issue, there was a bug in the driver that had the orientation field of the imu message in the wrong frame which would cause the data to be interpreted wrong if *_remove_gravitational_acceleration was set to true (which it needed to be). If you run on the latest tag (4.2.0 at the time of writing), this issue should be resolved.
In terms of the timestamp problem, I did not notice that in my testing. We currently timestamp all of our data using ros time when it arrives, and assuming that ekf_localization does the same thing, although there may be a small amount of latency between them, they should definitely not diverge. If you see this problem again, could you please provide some data so I can take a closer look?
I have another question on this topic. Since the new update, the GPS status value remains at -1 in GPS topic (for both GPS topics), which likely indicates it cannot connect to any satellites, despite being in an open sky area where the signal should be strong. Do you have any insights on this issue?
Keep in mind that the reference frame printed on the device is the correct orientation, but not in the correct position. Antenna offsets should be calculated relative to the sensor origin, defined here:
So don't make any measurements relative to the printed symbol.