search

iRobotEducation / create3_sim

ROS 2 Simulation for the iRobot® Create® 3 Educational Robot
BSD 3-Clause "New" or "Revised" License
110 stars 56 forks source link

RViz2 Link Issue: No Transform from left wheel to odom #125

Closed slowrunner closed 1 year ago

slowrunner commented 3 years ago

Performed git pull today 10/30/2021, and rebuilt

ubuntu@c3desktop:~/create3desktop/create3_sim_ws$ ros2 launch irobot_create_gazebo create3.launch.py

RVIz2 reports 

...
[robot_state_publisher-2] The root link base_link has an inertia specified in the URDF, but KDL does not support a root link with an inertia.  As a workaround, you can add an extra dummy link to your URDF.
...

[rviz2-3] [INFO] [1635608298.268809669] [rviz2]: OpenGl version: 3.1 (GLSL 1.4)
[rviz2-3] [INFO] [1635608298.414576071] [rviz2]: Stereo is NOT SUPPORTED
[spawn_entity.py-7] [INFO] [1635608298.679113579] [spawn_create3]: Spawn Entity started
[spawn_entity.py-7] [INFO] [1635608298.680126137] [spawn_create3]: Loading entity published on topic robot_description
[spawn_entity.py-7] [INFO] [1635608298.685871188] [spawn_create3]: Waiting for entity xml on robot_description
[spawn_entity.py-7] [INFO] [1635608298.695959200] [spawn_create3]: Waiting for service /spawn_entity, timeout = 5
[spawn_entity.py-7] [INFO] [1635608298.698954616] [spawn_create3]: Waiting for service /spawn_entity
[spawn_entity.py-9] [INFO] [1635608298.753982614] [spawn_standard_dock]: Spawn Entity started
[spawn_entity.py-9] [INFO] [1635608298.755026702] [spawn_standard_dock]: Loading entity published on topic standard_dock_description
[spawn_entity.py-9] [INFO] [1635608298.758160530] [spawn_standard_dock]: Waiting for entity xml on standard_dock_description
[rviz2-3] Warning: Invalid frame ID "left_wheel" passed to canTransform argument source_frame - frame does not exist
[rviz2-3]          at line 156 in /tmp/binarydeb/ros-galactic-tf2-0.17.2/src/buffer_core.cpp
[rviz2-3] Warning: Invalid frame ID "right_wheel" passed to canTransform argument source_frame - frame does not exist
[rviz2-3]          at line 156 in /tmp/binarydeb/ros-galactic-tf2-0.17.2/src/buffer_core.cpp
[rviz2-3] Warning: Invalid frame ID "wheel_drop_left" passed to canTransform argument source_frame - frame does not exist
[rviz2-3]          at line 156 in /tmp/binarydeb/ros-galactic-tf2-0.17.2/src/buffer_core.cpp
[rviz2-3] Warning: Invalid frame ID "wheel_drop_right" passed to canTransform argument source_frame - frame does not exist
[rviz2-3]          at line 156 in /tmp/binarydeb/ros-galactic-tf2-0.17.2/src/buffer_core.cpp
[rviz2-3] Warning: Invalid frame ID "left_wheel" passed to canTransform argument source_frame - frame does not exist
[rviz2-3]          at line 156 in /tmp/binarydeb/ros-galactic-tf2-0.17.2/src/buffer_core.cpp
[rviz2-3] Warning: Invalid frame ID "right_wheel" passed to canTransform argument source_frame - frame does not exist
[rviz2-3]          at line 156 in /tmp/binarydeb/ros-galactic-tf2-0.17.2/src/buffer_core.cpp
[rviz2-3] Warning: Invalid frame ID "wheel_drop_left" passed to canTransform argument source_frame - frame does not exist
[rviz2-3]          at line 156 in /tmp/binarydeb/ros-galactic-tf2-0.17.2/src/buffer_core.cpp
[rviz2-3] Warning: Invalid frame ID "wheel_drop_right" passed to canTransform argument source_frame - frame does not exist
[rviz2-3]          at line 156 in /tmp/binarydeb/ros-galactic-tf2-0.17.2/src/buffer_core.cpp
[spawn_entity.py-9] [INFO] [1635608298.762957974] [spawn_standard_dock]: Waiting for service /spawn_entity, timeout = 5
[spawn_entity.py-9] [INFO] [1635608298.763997195] [spawn_standard_dock]: Waiting for service /spawn_entity
[joint_state_publisher-1] [INFO] [1635608298.824486174] [joint_state_publisher]: Waiting for robot_description to be published on the robot_description topic...
No_transform
rjcausarano commented 3 years ago

I managed to reproduce this error. I'll fix it today.

justinIRBT commented 3 years ago

This is a startup condition before the odom->base_link transform has synced with the base_link->children frames tree. The application runtime should be fine. We can look into startup order to see if it makes the warning go away, but it should be harmless. I see other ROS packages that have similar warnings at startup until the tf trees sync.

slowrunner commented 3 years ago

Yes the application runs fine, but currently RViz leaves the wheels at the dock while the Create3 explores. When does "until the tf trees sync" happen?

Wheel_At_Dock
justinIRBT commented 3 years ago

I see what you are talking about, tf trees should sync quickly all coming from the same application, that is not the source of this model issue. We will look into it, thanks for the report

rjcausarano commented 3 years ago

I did my best to solve this but I was unsuccessful. What is happening is that Rviz is not receiving the publications of the joint_state_publisher and thus cannot figure out how the wheels are connected to the robot. The joint_state_publisher is indeed publishing but I think there is a mismatch of QoS going on....

We just need to wait a little though, when https://github.com/ros-controls/ros2_controllers/issues/253 is solved I think I can simply update our source dependencies and it should be solved

slowrunner commented 3 years ago

Does this still happen if RViz is up and running long before robot_state_publisher and joint_state_publisher are started?

rjcausarano commented 3 years ago

I tested running joint_state_publisher manually way after rviz, confirming in the process that the joint states were indeed being published... but Rviz just isn't reading these joint state messages... Like I said these are symptoms of QoSs not matching...

I prefer to not spend more time trying to fix the joint_state_publisher code because I think it's just a matter of (short) time before they fix https://github.com/ros-controls/ros2_controllers/issues/253 and then I expect everything to run smoothly

roni-kreinin commented 1 year ago

On the physical robot the issue here seems to be that there is no controller for the prismatic joint of the wheel drop. robot_state_publisher does not publish any transform for prismatic joints, and so there is no transform to the wheel_drop_left and wheel_drop_right links when the robot description is published. The physical robot publishes a left_wheel -> base_link transform directly, rather than left_wheel -> wheel_drop_left -> base_link, which is why we don't see an error on the actual wheel links.

I've found a couple of quick fixes for the robot, which is to either publish a static transform manually like so:

ros2 run tf2_ros static_transform_publisher 0 0.1165 0.0402 -1.5707 0 0 base_link wheel_drop_left

Or to just set the wheel_drop joint type to "fixed".

The issue with the fixed joint is that in sim it will no longer act as a spring, so that is not great.

schenkch commented 1 year ago

I have the same issue but with running turtlebot4_navigation (with the physical robot) and rviz in Galactic. I tried updating the files as it was done here (https://github.com/turtlebot/turtlebot4/commit/7f6d8f0b5e348024d324346f2e0c4a9d31af8240) for Humble. How can I make sure that these changes actually take effect? How do I rebuild the code? It would be great if somebody can help me out.

roni-kreinin commented 1 year ago

@schenkch If you built the workspace with --symlink-install then the changes should be applied without rebuilding. Otherwise you can just colcon build the workspace again.

schenkch commented 1 year ago

@roni-kreinin Thanks for the quick response. But for that I have to build the turtlebot4 packages from source in the workspace? I build them with apt and they are in /opt/ros/galactic/share. So I thought that I can change the files in this folder somehow and rebuild somehow but that is not possible, right?