Missing links/joints in lbr_bringup simulation on Ubuntu20 and foxy

[MightyMirko]

Description

When I start the lbr_bringup simulation with the command ros2 launch lbr_bringup lbr_bringup.launch.py model:=iiwa7 sim:=true, the links and joints of the robot are missing after Link 0. Steps to Reproduce

Launch the lbr_bringup simulation using the command ros2 launch lbr_bringup lbr_bringup.launch.py model:=iiwa7 sim:=true.
Observe the robot in the simulation environment.

Expected Result

I expect to see the complete robot model with all its links and joints in the simulation environment. Actual Result

The links and joints of the robot are missing after 0 in the simulation environment. System Configuration

Operating System: [Insert Operating System and version]
lbr_bringup version: [Insert version]

Additional Information The Problem occurs with iiwa14 aswell

[MightyMirko]

[rviz2-8] Warning: Invalid frame ID "lbr_link_4" passed to canTransform argument source_frame - frame does not exist
[rviz2-8]          at line 133 in /tmp/binarydeb/ros-foxy-tf2-0.13.13/src/buffer_core.cpp
[rviz2-8] Warning: Invalid frame ID "lbr_link_5" passed to canTransform argument source_frame - frame does not exist

I assume i need to take a look in the xacro urdf files?

[CarlDegio]

it seems that the gazebo is not launched. If the TF found(after visual or real robot connecting), the warning will stop.

[mhubii]

Thanks for mentioning this issue and thanks @CarlDegio for pointing to the solution. If the robot state publisher doesn't publish the transforms for one reason or the other the robot is not displayed correctly in rviz. Now this issue can occur and is hard to debug remotely. Will have a look at it. What happens if you echo the /tf topic? Any output ?

[mhubii]

Maybe as a quick check, when you launch the lbr_bringup, add | grep ERROR at the end

[MightyMirko]

Hello,

gazebo wasn't killed properly and therefore couldn't start the 2nd Instance. The first instance was either killed by x in gui or by ctrl + c in terminal. GUI was closed but the server was still up.

Quick Question: Is there maybe more documentation for this repo or are there published papers using this repo stack?

[mhubii]

sorry but currently there isn't any further documentation, but we are working actively on improving documentation and a small publication for explaining the structuring. Do you have any specific questions? Was your initial issue solved?

[mhubii]

closing this issue because it can't be replicated. This issue might occur on first start-up. Gazebo seems to initialize some files and takes longer to start-up. Please feel free to re-open at any time @MightyMirko

The best documentation for the architecture of this software is currently in this comment https://github.com/KCL-BMEIS/lbr_fri_ros2_stack/issues/50#issuecomment-1425562881

[MightyMirko]

Hello,

i was hoping for some kind of tutorial or how to start guide. Whenever i try to do a motion with moveit in rviz the first time seems good, but a second run to a new position throws errors and even after restart i cant get rid of it. I choose 5ms, client-ip 172.31.1.100 and both Position_Modes. Result is:

After shutting down the launch script and restart it with ros2 launch lbr_bringup lbr_bringup.launch.py model:=iiwa7 sim:=false

the robot wants to move real fast and is killing the fuse for axis id4-id7.. EDIT: Today only mastering was needed..

[MrstupidJ]

Hi @MightyMirko ,

Not sure why your robot tried to move rapidly, but here are some tips:

1. If your java application ends with lots of error, run and stop a template app (I usually run the braketest app for a few seconds), reset the app and then rerun LBRServer.
2. Robot joints might exceed their limit when it runs too fast and break the safety configuration rules. To recover from this, turn the key on the Smartpad and switch to CRR (or whatever the new mode other than T1, T2, and Auto, pls refer to KUKA Sunrise Cabinet manual) and remaster the joint.

Hope these help!

[srisainachuri]

Hi, I'm having the same issue and I was wondering if anyone can provide some debugging guidance. I'm also running Ubuntu20, foxy, running simulation mode with iiwa14. However, the above solutions do not seem to work for me.

Information I've gathered:

• gazebo shows my robot in it's rest state but rviz has the same errors as @MightyMirko
• gzserver wasn't killed properly on ctrl+C and I manually killed the process, but upon re-launching the bringup, I still have the same issue
• echo /tf topic does not have any output
• | grep ERROR at the end of the bringup does not show any errors

Essentially I've tried other suggestions but I can't get the simulation to properly show in Rviz with the transforms.

[mhubii]

hi @srisainachuri and thanks for the feedback. What branch are you on? Since foxy and galactic have reached their end of life it would be best to run the humble branch. I can check foxy tomorrow though.

[srisainachuri]

Thanks for getting back to me @mhubii . I actually tried to re-install and now I'm seeing the following error stack from grep ERROR:

[move_group-7] [ERROR] [1694122364.207972733] [moveit.ros.occupancy_map_monitor]: No 3D sensor plugin(s) defined for octomap updates
[ERROR] [gzserver-1]: process has died [pid 237252, exit code 139, cmd 'gzserver                                                                    -s libgazebo_ros_init.so   -s libgazebo_ros_factory.so   -s libgazebo_ros_force_system.so       '].
[spawner.py-5] [ERROR] [1694122374.157036797] [spawner_joint_state_broadcaster]: Controller manager not available
[spawner.py-6] [ERROR] [1694122374.164633730] [spawner_position_trajectory_controller]: Controller manager not available
[ERROR] [spawner.py-5]: process has died [pid 237262, exit code 1, cmd '/opt/ros/foxy/lib/controller_manager/spawner.py joint_state_broadcaster --controller-manager /controller_manager --ros-args'].
[ERROR] [spawner.py-6]: process has died [pid 237264, exit code 1, cmd '/opt/ros/foxy/lib/controller_manager/spawner.py position_trajectory_controller --controller-manager /controller_manager --ros-args'].
[move_group-7] [ERROR] [1694122379.288017800] [moveit.simple_controller_manager.follow_joint_trajectory_controller_handle]: Action client not connected: position_trajectory_controller/follow_joint_trajectory

I'm current running all of this on the foxy branch. I did recognize foxy is EOL, and I initially tried using Humble, but I ran into issues when trying to install and thus reverted to using foxy. I assumed it was something to do with my Ubuntu version (Ubuntu 20.04) since Humble is better supported for 22.04.

[mhubii]

okay got you. Makes sense to use foxy and it is a little unfortunate humble is only distributed for 22. I'll have a look at it, but chances are this is an issue with ros2_control. Sorry for the inconvenience

[mhubii]

So one immediate thing you could try is to run the launch files and just wait a minute.

On the very first boot gazebo takes quite long to spawn the model for some reason.

The model then loads the controller manager through a plugin. So this might be your issue @srisainachuri

[srisainachuri]

Thanks for checking that out @mhubii I tried waiting about 10-15 minutes for gazebo to see if anything changes, but unfortunately the error seems to persist with the transform not detected. Gazebo itself seems fine since I can see the robot in it's rest state in the Gazebo program tab. Do you have any suggestions for ensuring that plugin is working correctly?

[mhubii]

you could try out the ros2 control demos for foxy to check whether everything works as intended https://github.com/ros-controls/ros2_control_demos/tree/foxy

Sorry, I'll try to run this repo on foxy asap and backport some of the humble changes to foxy

[mhubii]

okay I tested it and can confirm this issue. It will be addressed in #118

[mhubii]

this issue should now be fixed @srisainachuri . There was an issue with the launch files. I hope this will make this package useable for you. Sorry for the inconvenience and thank you for reporting. If you have time, please let me know whether it works for you or not

Please keep in mind that moveit seems relatively buggy for foxy and that the launch files of this package are not well written in foxy. There are big changes for humble and things work cleaner

[srisainachuri]

Thanks for the help @mhubii and the new changes seem to work for me. 1 small step I needed to also make was updating my cmake version without uninstalling the old one, so I followed the steps here: https://gist.github.com/bmegli/4049b7394f9cfa016c24ed67e5041930

Thanks also for the heads up on the foxy moveit issue with the launch files, and I'll see if I can give humble install a try again for better performance.

[mhubii]

great news, thank you for the help!