Closed AdamGoertz closed 3 months ago
I understand the confusion here. As you have correctly pointed out, on all platforms that have built-in IMU's, the data coming in from the MCU must be filtered. Therefore, for platform IMU's we only need to bridge the data_raw
topic to then filter it.
On the other hand, we support external IMU's that can be added to improve robot localization. These IMU's, like the microstrain_imu
, have independent drivers that allow for calibration and data filtering, resulting in data
topics that are assumed to be much more accurate.
In order to support both with just a single IMU
class of sensors, we opted to bridge both topics, assuming that one of the two would be used. It is not desirable and we will be making an update to prevent unnecessary bridges from being generated.
Got it, thanks for the explanation!
Please provide the following information:
Package version: 9dd763df8293da5008aeb43979b4dfd5592f0e4d
Expected behaviour GZ_TO_ROS bridges should only be created for topics that are actually published by gazebo.
Actual behaviour
imu_0_gz_bridge
creates a publisher for thesensors/imu_0/data
topic even though that topic is published by theimu_filter_node
.To Reproduce Provide the steps to reproduce:
ros2 launch clearpath_gz simulation.launch.py
ros2 topic info /w200_0000/sensors/imu_0/data -v
This issue can be fixed by deleting these lines
https://github.com/clearpathrobotics/clearpath_simulator/blob/9dd763df8293da5008aeb43979b4dfd5592f0e4d/clearpath_generator_gz/clearpath_generator_gz/param/sensors.py#L196-L201
Is there a configuration where it is expected that the simulator will publish the filtered IMU topic? Or where
sensors/imu_0/data
actually refers to the raw IMU data (instead of the filtered output)? A quick look suggests all of the URDFs in clearpath_platform_description use thedata_raw
topic.