better_launch: a replacement for the ROS2 launch system - intuitive, simple, memorable

[ndahn]

Hi there!

I just released my tool better_launch, which is a complete replacement for the ROS2 launch system. With this package, instead of dozens of imports and class instances for even the most basic tasks, your launch files could look as simple and beautiful as this:

#!/usr/bin/env python3
from better_launch import BetterLaunch, launch_this

@launch_this
def my_main(enable_x: bool = True):
    """
    The docstring will also document function args and provide a --help flag!
    """
    bl = BetterLaunch()

    if enable_x:
        bl.node(
            "examples_rclpy_minimal_publisher",
            "publisher_local_function",
            "example_publisher",
        )

    # Include other launch files, even regular ROS2 launch files!
    bl.include("better_launch", "ros2_turtlesim.launch.py")

What does it do?

The Readme has more details, but to give you an overview of what it does:

• Launch files are determinstic: any actions taken in the launch files are executed immediately, allowing direct and meaningful interactions with nodes, topics and services as the launch process develops.
• Launch arguments are passed as natural types to your launch function.
• Use regular python syntax like if/else. No async shenanigans!
• The entire launch logic is contained within a single, fully documented package, examples included.
• Write launch files fully compatible with ROS2’s launch system. This means they can be started through ros2 launch, include regular ROS2 launch files, and even get included from regular ROS2 launch files.
• Includes convenience functions for various common tasks like starting a joint_state_publisher or bridging Gazebo topics.
• Comes with a **replacement for ros2 launch called bl, which is both faster than its counterpart and provides additional features like auto completion for launch arguments.
• Designed with user friendliness in mind and thus generates reformatted and colored terminal output by default.
• Unless killed with SIGKILL, better_launch will leave no zombie processes behind.

Terminal UI included!

better_launch also comes with an optional terminal UI similar to rosmon, which can be used for stopping and restarting nodes, triggering life cycle transitions, list a node’s subscribed topics, dynamically adjust the logging level and more (screenshot below)!

Is it for me?

We already have it in use on several robots at my research institute, so I consider it mature enough for general use in research applications.

If you find any bugs, missing features, or just want to give feedback in general I would much appreciate it

Links

• Github: https://github.com/dfki-ric/better_launch
• Moi: https://www.linkedin.com/in/nikolas-dahn

Thank you ~
Nikolas

[jak]

Love it! Thank you for the initiative

[shouheng]

Thanks for sharing. I came across this repo the other day: GitHub - Kodo-Robotics/launchmap: Interactive ROS 2 launch file visualizer for VS Code. Explore and debug launch graphs with an intuitive UI.

You might be interested in taking a look as well.

[ndahn]

I recently was made aware of it It’s nice, but of course tailored for ROS2 launch. I’m also still debating if it’s an actual use case - or more like a symptom because the regular launch files are so cumbersome to work with.

[davidmc]

Great work! In the repo, I checked the “Why not improve the existing ROS2 launch?”. Is it really not possible? I would love to use better_launch, but even the name is already adding some confusion. That’s the same feeling I had with catkin_simple and now with ament_auto. It feels to me that it should be the other way around. The “better”, “simple”, and “auto” should be the standard, and manual options should be used in specific cases… What has been the feedback from maintainers of the launch system so far?

[salogranada]

This looks really nice! Does it support nodes composition and creating component containers?

[chfritz]

How does this relate to @emersonknapp ‘s effort of getting us all back to a declarative language for launch files in ROS2? Is there any sort of coordination or perhaps even convergence/integration between these efforts?

Declarative ROS presentation slides & the Robograph project kickoff

Wanted to first say thanks to everyone who came out to ROS By-the-bay last night at Circuit Launch! It was a great event, lots of good conversation. Here are the slides, for anyone who wants them: I encourage you to fill out this super duper quick survey! You can optionally put in your email address, and I will use that at some point to populate a mailing list (easy to opt back out if you change your mind) to give updates on this topic. Finally, please come join the conversation over at Ro…

[Guela_kais]

I would like to echo that sentiment of " Why not improve the existing ROS2 launch?". The current system for creating ROS2 launch files has several advantages:

• Several supported languages to write launch files for it. Xml, Yaml and Python are supported languages to write ROS2 launch files with.
• It’s established. In point of view as a package maintainer, I find it difficult to argue why we should care about maintaining a brand new package that may be less popular and used less than an established, battle-tested package that’s already the default. As a ROS 2 developer, I find it quite challenging to work with new packages that target an existing and solved problem, because most of the time it isn’t simply a case of downloading it and it just working! Using such convenience layers usually means you have to keep an eye on them to ensure your program still works tomorrow.

I really don’t like the mentality of ‘abandon the old technology. Just build a new one’, especially if you haven’t even tried to discuss your point of view with the maintainers of this technology. I see in your Project the motivation to make the art of writing ros2 launch files better and that’s what I can agree with. Writing ros2 launch files is quite a struggle. I simply think, that it would be better to improve the current existing technology. I would like to end my statement with one request. Would you please show me one example which shows, why exactly you don’t think, ROS2 launch can’t be improved?

[ndahn]

Sorry, I didn’t check here for a while and didn’t get any notifications either

From my point of view, the current system cannot be fixed because the design is fundamentally flawed. One reason is that the class-based system has to somehow mimic basic python functionality, which is just awkward. But it also results in extremely complex constructs even for simple cases. My favorite example for this is the IncludeLaunchDescription class and its related code). This is well over 500 lines - better_launch does it in less than 30.

The name started as a joke, but it stuck around. There was a brief discussion over on github if the name is acceptable, but in the end all reviewers were fine with it If ROS2 decides to make it the standard at some point they can of course name it whatever they want, but for now it’s what it is.

[ndahn]

It does indeed! You can simply write something like this:

bl = BetterLaunch()

with bl.compose("my_composer"):
    bl.component("composition", "composition::Talker", "comp_talker")

Remaps and so on are also supported.

[ndahn]

I wasn’t aware of this one, thanks for pointing it out! I’ll have to look into it a bit more, but I wonder what the actual benefits would be? Don’t get me wrong, I really liked the ROS1 launch files, but anything more complex (even a simple if/else or doing stuff based on a config) was anywhere between awkward and impossible.

[ndahn]

Of course, thank you for your input I get your point and I will certainly not force anyone to use better_launch. For me it represents the way I want to write launch files (or at least it’s very close to it). It started out as a passion project and indeed took quite a while to get to the current state.

To address your concerns, I’ll copy my answer I’ve given before to davidmc:

@ndahn

From my point of view, the current system cannot be fixed because the design is fundamentally flawed. One reason is that the class-based system has to somehow mimic basic python functionality, which is just awkward. But it also results in extremely complex constructs even for simple cases. My favorite example for this is the IncludeLaunchDescription class and its related code). This is well over 500 lines - better_launch does it in less than 30.

Regarding supported languages, I think that’s a bit of a stretch. Yes, you can write ROS2 launch files using xml or yaml, but good luck e.g. starting a lifecycle node. I’m not even sure if you could read parameters from somewhere?

Lastly, I want to highlight that using better_launch is not exclusive in fact, you can even include better_launch launch files in ros2 launch files or run them via ros2 launch!

[davidmc]

Thanks! I wonder if it looks like ROS 2 launch, but better, why is it not ROS2 launch? Did you study the coverage of functionality compared to ROS 2 launch? @Guela_kais As a maintainer, do you see any option for adopting it (just to have some feedback)?

[Timple]

@ndahn

Regarding supported languages, I think that’s a bit of a stretch. Yes, you can write ROS2 launch files using xml or yaml, but good luck e.g. starting a lifecycle node. I’m not even sure if you could read parameters from somewhere?

That’s a bit strong maybe.

I’ve heard stories of people reducing 1000 lines of python code by 43 lines of xml.

I think it’s a shame that from the beginning of ROS 2 (and still) they started promoting the python launch syntax. While the XML was also there and 94% identical for simple use cases.

[mjcarroll]

The XML and YAML frontends definitely lagged behind in implementation after the original Python launchfile examples. In general, XML should be more than sufficient for many applications.

@christophebedard and @emersonknapp have actually been leading the charge on getting documentation to reflect that people should be considering XML first, we would like that to be the broad recommendation going forward (and have example parity for L-turtle).

[ndahn]

One thing to consider is that the current ROS2 launch system is entirely based around asyncio. This is nice as a concept, but it has many surprising consequences. One really awkward example is the following:

Did you ever try running this example turtlebot launch file? Because there are no guarantees regarding startup times (or even execution order), it needs to introduce a delay before calling the service - and even then it will usually fail because the node was not quite ready yet. When testing better_launch with this at first I thought I had a bug because the service call actually succeeded

I think for now better_launch is too far away from the ROS2 design philosophy to become an official solution. However, if it is adopted by the community I hope this will change in the future.

[ndahn]

If you mean how better_launch compares to ROS2 launch in functionality - I think there is a considerable gap in favor of better_launch. As far as I’m aware I have covered everything that the ROS2 launch system can do, plus:

• out-of-the-box functionality for interacting with publishers and services
• convenience functions for gazebo and common patterns like joint state publishers
• interactions with running nodes from inside launch files
• a terminal UI
• the ros2 launch substitute (bl) is faster and has auto-completion for “declared” arguments
• …

If there is a negative gap, it’s in the fact that better_launch doesn’t execute yaml or xml launch files - it just forwards them to the ROS2 launch service.

[Guela_kais]

Just to clarify, I’m not a maintainer of ROS 2 launch. I am a maintainer of NixOS. I write Nix package declarations for nixpkgs. What I meant was that if better_launch is battle-tested and used enough, so it could be included in the package sources of a Linux distribution’s package manager. That’s my point of view.

@ndahn

One reason is that the class-based system has to somehow mimic basic python functionality, which is just awkward. But it also results in extremely complex constructs even for simple cases.

I don’t think you should go out on a limb too far here. Your code also uses a lot of python classes, and you have a completely different problem. As far as I can see, large parts of better launch are based on rclpy, the Python interface used to build ROS 2 nodes. There are good reasons why ros2 launch is not based on the node interfaces. One example is that ros2 launch files not only handles nodes, but also the parameterisation of urdf files, for example. If you work with ros2 control, you do this regularly.

[christophebedard]

@ndahn

Did you ever try running this example turtlebot launch file? Because there are no guarantees regarding startup times (or even execution order), it needs to introduce a delay before calling the service - and even then it will usually fail because the node was not quite ready yet.

I think that’s an antipattern; this isn’t a launch issue, it’s an application issue. Your application shouldn’t rely on a strict orchestration (manually ros2 running nodes or ros2 launching them) timing to properly work.

If you did something like this in your code with a service, you’d get the service client to wait for the service server to be available with ClientBase::wait_for_service(). Same for pub/sub (+ the transient local durability QoS). In fact, ros2 param set now has a --timeout N option that waits for the corresponding node to be available (which was added after the <timer> action you point to was added to the docs), and then it calls AsyncParameterClient.wait_for_services() before setting the parameter. I’ve opened an issue to remove the <timer> action from the example launch files: Example launch file "Using substitutions" tutorial shouldn't use timer action to delay setting parameter · Issue #5826 · ros2/ros2_documentation · GitHub.

[Guela_kais]

The ROS 2 launch system is not there to support inadequate node robustness. If the nodes are to fragile, they need to be fixed, not the launch system. Additionally, the launch system itself is more of a convenience layer for running nodes. As far as I know, most of the things launch files do can be recreated with shell scripts.