Robotics StackExchange | Archived questions

How to define the execution of a sequence of launch actions within the ROS2 launch system

Greetings. Is there a way to manage the the execution order of my nodes within a launch file? Furthermore is there such a way for imported launch files and their nodes.

These questions relay to the use-case of spawning and controlling a robot with ros2_control and MoveIt2. The execution order would be roughly something like:

Top Level .launch file (sequence in cardinals)
|- 1. gzserver (IncludeLaunchDescription)
|- 2. Robot .launch file (IncludeLaunchDescription)
|        2.1. robot_state_publisher (Node)
|        2.2. ros2_control specific .launch file (IncludeLaunchDescription)
|        2.3. MoveIt specific .launch file (IncludeLaunchDescription)
|        2.4. spawn_entity (Node)
|- 3. Simulation .launch file (IncludeLaunchDescription)
|        3.1. Gazebo environment spawning (IncludeLaunchDescription)
|- 4. RViz .launch file (IncludeLaunchDescription)

As a beginner within the launch system I am unaware to achieve this. I am aware that the order of adding the launch actions does not have a controllable effect and that there are event handlers for delays within the launch system. However, the event handlers seem unable to achieve the desired outcome. Also many of the 'common' nodes do not yet inherit form rclcpp_lifecycle::LifecycleNode, since it is still in development.

Certainly a better versed ROS developer can point me to a solution, because it seems to be a somewhat common use-case.

Asked by NotARobot on 2022-06-14 10:03:17 UTC

Comments

Why do the event handlers not achieve the desired outcome?

Also, if you're using gazebo_ros2_control you should launch spawn_entity before your controllers. Since the controller manager from gazebo_ros2_control is inside your URDF and doesn't start unless you spawn the robot. You might need to move 2.4 to be 2.1.5 so to speak, if I'm remembering correctly.

I'm also not sure what the difference between 1 and 3 is. Are you first launching Gazebo and then adding the world after?

Asked by Joe28965 on 2022-06-15 04:38:33 UTC

Since the launch files are nested via inclusion I can not reference nodes from the included launch files on a higher level, or I am not mistaken? As far as I know the event handlers are able to look for on_exit or on_execution_complete events and others, from nodes but for this the events have to be registered in the launch file which starts the node. - Sorry, I am guessing a lot since I find the official documentation to shallow for such a case.

Oh I did not know I have to spawn it first, thank you! - I thought spawn_entity only spawns it within Gazebo, because with the publishing its already visible within RViz.

I do not have a Gazebo world to load. I want to spawn all necessary entities with the launch system, because this will become the virtual prototype of a modular test system with a fluctuating number of entities. Therefore I start the server, load the entities and start the visualization.

Asked by NotARobot on 2022-06-15 07:52:26 UTC

Answers

I know TimerAction can be used to delay IncludeLaunchDescription as well. An example of TimerAction. Just replace the Node under actions with your IncludeLaunchDescription.

I think on_exit might also be able to do it (vaguely remember something like that), but I'm not sure.

As for your comment on spawn_entity. The reason you can already see it in RViz is because robot_state_publisher is already active. That publishes the TF tree and that's what you see in RViz. Even on a real robot, you could see "the robot" in RViz already, even if the robot itself would still be turned off.

That comparison actually also works really well here. spawn_entity also ensures Gazebo launches all the included plugins: lidars, cameras and also the gazebo_ros2_control plugin (that works as the Controller Manager wrapper, as far as I know). You should be able to see the controllers time out if you don't spawn your robot.

spawn_entity also uses the /robot_description topic by default to get the URDF that it needs to spawn. robot_state_publisher publishes on that topic, which is why spawn_entity should start after (sorta) RSP.

The reason I say "sorta" is because for a lot of things, it really doesn't matter when you start them. At least in the case of spawn_entity, because it will wait to receive something on the /robot_description topic for a while.

This does actually also partially bring me back to my original question:

Why do the event handlers not achieve the desired outcome?

Which is actually not the real question I wanted to ask. The real question is much, much simpler. Why do you need to launch them in that sequence? Does something specifically go wrong if you don't? For my projects, I launch RSP, spawn_entity & the Gazebo world all at the same time. I usually launch Nav2 separately, because I don't have the best of experiences launching both Gazebo and Nav2 at the same time. For that reason, I can imagine having a delay for MoveIt, but for other things I'm not sure you need it.

Asked by Joe28965 on 2022-06-15 08:50:28 UTC

Comments

Why do you need to launch them in that sequence?

I have got some errors on which I am not entirely sure why they happen, if I could rule out wrong timing it would be easier.

  1. The MoveIt motion planning within RViz does not know the planning library on start up. I suspect a timing error, since it is there if I manually add it. RViz
  2. Somehow ROS2_control is not able to load the Gazebo_ROS2_control plug-in. However it is in the URDF and I have added spawn_entity before the start of the controller as you suggested. ROS2_control
  3. My move-group is not able to load the PlanningRequestAdapter and others. Move group

I would like to be able to retrace and manipulate the launch process for debugging and consistency, so each node starts when its necessary information is available.

Asked by NotARobot on 2022-06-17 02:26:42 UTC

is gazebo_ros2_control installed?

Asked by Joe28965 on 2022-06-17 13:17:03 UTC

It is. I suspect the plugin gazebo_ros2_control is not loaded, however it is available (build and sourced). The whole robot was working before MoveIt2 with a small test node which directly published the joint angles to the appropriate ros2_control controller.

Asked by NotARobot on 2022-06-24 08:24:41 UTC

gzserver loads gazebo_ros2_control after ros2_control_node tries to connect to the interface, resulting in ros2_control_nodes death and subsequently the inability to plan with MoveIt. gazebo_ros2_control

Asked by NotARobot on 2022-06-28 09:48:50 UTC