husarion/rosbot_ros

IMU in Gazebo Fortress not working

Closed this issue · 7 comments

After updating the rosbot_ros repository for our simulation lab I noticed, that the topic /odometry/filtered returns weird values.
But only in the yaw entry, x and y worked fine.
My first test was to let the robot rotate with 0.1 rad/s around its z-axis.
When looking at the filtered odometry values they appeared to have lost the integrating behaviour and only returned the angular velocity commanded divided by 2. So for 0.1 rad/s commanded it results in 0.05 rad/s on the filtered odometry.
After looking a little deeper I found the IMU to be the culprit. When I remove the IMU from the ekf.yaml file the filtered odometry works fine.
I then had the yaw change dynamically to see if there is a change in value on the imu_broadcaster/imu topic. But all values on the topic are static in the new version (unlike in the old one).
As there are no real differences in the ekf.yaml to the old version I was using I found, that the description of the plugin in the rosbot_macro.urdf.xacro is missing.
When I insert the following line into that file in line 144 the IMU and also the filtered odometry is working again:
<plugin filename="ignition-gazebo-imu-system" name="ignition::gazebo::systems::Imu"></plugin>

Here the full IMU description:

<gazebo reference="imu_link">
          <sensor name="${namespace_ext}imu" type="imu">
            <!-- <plugin filename="ignition-gazebo-imu-system" name="ignition::gazebo::systems::Imu"></plugin> -->
            <always_on>true</always_on>
            <update_rate>25</update_rate>
            <topic>${namespace_ext}imu/data_raw</topic>
            <visualize>false</visualize>
            <enable_metrics>false</enable_metrics>
            <frame_id>imu_link</frame_id>
            <ignition_frame_id>imu_link</ignition_frame_id>
            <ros>
              <namespace>${namespace_ext}</namespace>
            </ros>
          </sensor>
        </gazebo>

I would love to hear some feedback if I have done something wrong when updating and this plugin-tag was deleted intentional or if it is just missing and must be inserted again.

Thanks. Best regards
Heenne

Hello Heenne,

I analyzed the values ​​using plotjuggler in the simulation and did not find any such deviations.

image

  1. Are you sure you have all packages updated?
  2. Can you send detailed instructions on how to reproduce this error on another computer?

Hi, thanks for the quick reply.

Just a quick disclaimer upfront, I am running this in a singularity container.

I updated the codebase to the following commit ids/tags:
rosbot_ros: humble branch - 5d024d75
husarion/husarion_office_gz: 6049a8f25baac7329b911fcddd080c57bcc1c4f2
rosbot_hardware_interfaces: da1805839aaa21b8341a9c39498c96d9a1a4f87d
ros_components_description: 2a669a02582d89dbe0c5699381f096a3f7a51815
husarion_controllers: 217b09830f5f42930098b9992eda41710702b625
ros2_controllers: 60919d60fb02eb920b0bf42e4d86853db23233cc
micro_ros_msgs: 3.0.1
micro-ROS-Agent: 3.0.6
Micro-XRCE-DDS-Agent: c25243c19e0af3fdfc7ccbd5ce5838c376eb71ef

These versions were the ones installed during the update to the mentioned commit of the rosbot_ros repo.

For the installation of dependencies and so on I used the following commands in the singularity.def-file:

# Clone rosbot_ros repo
	bash -c "cd ${SINGULARITY_ROOTFS}/temp_ws/src \
		&& git clone https://github.com/husarion/rosbot_ros.git"

	# Execute the commands in the README of thew rosbot_ros repo for installation
	# 1. Set environmental variables for the dependency and build process
	# 2. execute vcs command from the Husarion ROSbot repository to include necessary dependencies in the src folder
	# 3. Copy the only two controllers needed into src folder
	# 4. Delete ros2_controllers as the remainders are not necessary (and rosbot instructions say so)
	# 5. Source setup.bash of ROS2 Humble
	# 6. Install dependencies (no rosdep init as this will crash the build process because its already initialized)
	# 7. Remove the micro-ROS-Agent repo as this will not be used in the simulation and only causes problems during build!
	# Note: No build here as we only prepare the source code
	bash -c "cd ${SINGULARITY_ROOTFS}/temp_ws \
		&& export HUSARION_ROS_BUILD_TYPE=\"simulation\" \
		&& export GZ_VERSION=\"fortress\" \
		&& vcs import ${SINGULARITY_ROOTFS}/temp_ws/src < ${SINGULARITY_ROOTFS}/match-DigitalTools/rosbot_ros_dependencies/rosbot_hardware.repos \
		&& vcs import ${SINGULARITY_ROOTFS}/temp_ws/src < ${SINGULARITY_ROOTFS}/match-DigitalTools/rosbot_ros_dependencies/rosbot_simulation.repos \
		&& cp -r ${SINGULARITY_ROOTFS}/temp_ws/src/ros2_controllers/diff_drive_controller ${SINGULARITY_ROOTFS}/temp_ws/src \
		&& cp -r ${SINGULARITY_ROOTFS}/temp_ws/src/ros2_controllers/imu_sensor_broadcaster ${SINGULARITY_ROOTFS}/temp_ws/src \
		&& rm -rf ${SINGULARITY_ROOTFS}/temp_ws/src/ros2_controllers \
		&& source /opt/ros/$ROS_DISTRO/setup.bash \
		&& rosdep update --rosdistro $ROS_DISTRO \
		&& rosdep install -i --from-path src --rosdistro $ROS_DISTRO -y"

Using these versions the /rosbot_base_controller/odom/pose -> yaw is normal. But the /odometry/filtered/pose -> yaw is reporting a very low value when the robot is moving (diff between two cycle). When the robot is standing still the pose is 0.

I am on holiday in the next couple of days. I will get back to further questions regarding this issue afterwards.

Best regards
Heenne

Hello @Heenne,

Can you remove your workspace and rebuild rosbot_ros repository according to README.md.
Let me know if anything has changed.

Hello @rafal-gorecki,
thanks for your response.
Two things I tried:

  1. Just rebuilding the workspace. --> Didnt work
  2. Deleting the rosbot_ros repository. Cloning it again. Rebuilding. --> Didnt work

The /odometry/filtered topic only works if I insert the plugin-description I mentioned above.

I will now have a look into the updates of the other dependencies and rebuilding the whole container.

Best regards

Hello @rafal-gorecki
I found the issue. It looks like the plugin definition for the imu is now in the .sdf-file for the Gazebo world.
As we used a customized, self-created world, the plugin-definition were missing.
Is this a standard practice to put the robots components in the world-definition? To me it would make much more sense to put the plugin-definition of something like the imu in the robots urdf-file. Maybe you know this.
But this is something I can work with and will fix in our world file.
Afterwards this issue can be closed. Thanks

Best regards
Heenne

Hello @Heenne,
We thought so at first, but there was an error when spawning many robots. According to one of the creators of the simulation, the IMU plugin should be defined at the world level: ros-controls/gz_ros2_control#191 (comment)

Thank you very much for the information and the link to the explanation.
Have a nice day.
Heenne