How do you launch your systems?

Regarding ROS2, I would recommend looking into nav2-bringup

It features also top level launch and lots of conditions for multiple setups (tests, single, multi-robot) while staying most of the time ROS2 native regarding the launch system.

ROS2 is really powerful for that, but missing widespread examples and documentation is fogging this star…

2 Likes

The amount of creative solutions is probably explained by the general frustration with ROS launching mechanisms. :wink:

In general, I am using single, robot specific launch scripts, which are wrapped in systemd units when deployed. I avoid using script parameters and never use them to launch nodes conditionally, IMO that makes scripts more manageable. Common launch script parts are extracted and moved to higher levels in package dependency tree. Multiple launch scripts are occasionally used for testing.

Another useful tool not mentioned so far is environment variables, which are handy for managing node startup process in general, for example, launch nodes with valgrind, control node crash handling, etc, e.g. ccws/bringup.launch at master · asherikov/ccws · GitHub.

ROS2 launch, I believe, is an unfortunate step back compared to modern unit-based service managers like systemd. I am inclined to Magazino approach, but I would prefer to completely replace launch scripts with unit files.

1 Like

There’s also a multiverse of different docker-based solutions where ros(2) launch is used in its simplest form while most of the job is taken care of by a launch system managing docker containers. This way you don’t even need your entire software stack to be buildable on the same environment which is often desirable when you have different dependencies, os needs or ros distro needs.

1 Like

Any reference examples in the wild?

And remember, when you are frustrated you can always launch them out the window… xD

1 Like

I work on projects that typically use ROS in two different operating styles, 1) as the execution environment for real-time mobile robot control and 2) as the execution environment for constructive time-based simulations which may or may not involve robotics at all (mostly unmanned systems).

In the first case, we typically build a singular launch file that contains everything that may be needed to operate the robot. We typically use a global manager that publishes states and sometimes sub-states and each node may come alive or go dormant depending on the state. Here ‘alive’ and ‘dormant’ means that the ROS node is active but may or may not do anything depending on the state. To start everything, we setup a startup script to invoke the ros launch file at boot and that’s about it. Powering up the bot, automatically starts everything.

In the second case, where there is more variability in input parameters, we build launch files that take some command line arguments and pass them on to nodes as a means to adapt to required options. We try to avoid implementing any functionality or smarts in the launch file itself, even when using ROS2 where this is very tempting, we try to avoid it as a rule. A while ago we experimented with using a simple GUI that would allow us to specify all our options (execution frequency, visualization, init position, etc etc.) and then the GUI would generate the launch file but for us, the complexity of maintaining yet another GUI didn’t add up. Each node has their own config file and we can specify these on the launch command line (mostly with ROS2) but we try very hard to keep the launch file itself as a singular file that rarely changes.

1 Like

My team uses a combination of Docker Compose files and ROS launch. The core modules of the system are launched inside a single container using roslaunch but the hardware specific nodes or configuration variables are managed via separate containers launched along side the core container. This is mainly a way to maintain separate dependency trees for different hardware configurations.

All I want for Christmas is for someone to take this thread and write a summary of “real-world” launch
examples in the ROS 2 docs. :snowman_with_snow:

.

8 Likes

I know this problem well. What I’ve done is written a python script CLI wtih commands to declare what model robot this is (because we have multiples of each model), what the name of this individual is (because their network names are derived from that) and a few other declarations, and then the script correctly sets up ROS_MASTER_URI and ROS_IP. I’ve been constructing a hierarchical structure of launch files with appropriate parameterization. So that I think I have well in hand.

However, what I am not there yet is the “best” or "right? way to cause any launch file to be launched automatically when the robot boots up so that we don’t have to ssh to tell it to bringup. I am posting a separate question about this to see what we can learn.

Longtime lurker here, but this can easily be solved with a systemd service. I use ansible to manage our fleet of robots, install dependencies and keep things running and at expected configurations. This gives an example of setting services that your ROS nodes need as a dependency, setting environment variables, and pre-flight commands before launching our ros node. Note the jinja templating inside of the curly braces. This allows us to run the same service/template regardless if we are prototyping on Ubuntu or on our custom operating systems compiled from yocto. Here is a generic version of our template for the systemd service:

Looks like you forgot a paste?

We use docker compose that start launch files, separate launchfile as much as we can to keep it modular and have one container per launchfile, then pass yaml files for common configurations and environment variables or cli arguments for more specific ones.
It’s quite verbose but easy to determine what is the problem when it pops and it ensures not everything fails at the same time. The only pitfall we experience at the moment is the accumulation of logs in each container in ~/.ros, we still need to figure out how to disable them.

While developing an application, I launch every node in different terminal for debugging and analysing the system. But, once I am done writing the application. I collect every node and launch file into a single launch file.

What I and others will like if ROS provides some package to create a GUI with buttons to launch different nodes. A kind of wrap up all the nodes in a single executable.

rosmon - ROS Wiki :sunglasses:

4 Likes

Thanks, I did not know that. This is why one should be part of a community. :smiley:

Hi @dvoid,

I think you forgot to paste…! I’d love to try your solution!

Pito Salas
Faculty, Computer Science
Brandeis University

I didn’t, but it looks like Discourse removes anything indented. Here is the data without an indent.

[Unit]
Description=Robot software control system
After=random_dependency.service
Wants=random_dependency.service

[Service]
Type=simple
Environment=CATKIN_DIR={% if ansible_os_family == "Debian" %}/home/catkin_ws{% else %}/home/root/catkin_ws{% endif %}

User=non_root
ExecStartPre=/bin/bash -c 'echo "800000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq'
ExecStartPre=/bin/bash -c 'echo "running command"'
ExecStartPre=/bin/bash -c '/usr/sbin/randomcommand -check'
ExecStart=/bin/bash -c -l '{% if ansible_os_family == "Debian" %}source /opt/ros/{{ ros_codename }}/setup.bash; {% else %}{% endif %}source ${CATKIN_DIR}/devel/setup.bash; /opt/ros/{{ ros_codename }}/bin/roslaunch launch_dir launch_file.launch hostname:="{{ ansible_nodename }}"'
Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target

You’ll have better luck getting answers by creating a new thread. This question doesn’t have anything to do with the topic here.

what about osrf capabilities server?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.