[!TIP] Just looking for the documentation? We also have multiple examples!

🧭 About

Let’s face it: ROS2 has been a severe downgrade in terms of usability compared to ROS1. While there are many considerable improvements, the current launch system is borderline unusable. I’ve listed my personal gripes below, but if you’re here you likely feel the same. This is why I wrote better_launch.

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:

from better_launch import BetterLaunch, launch_this

@launch_this(ui=True)
def my_main(enable_x: bool = True):
    """
    This is how nice your launch files could be!
    """
    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")

$> bl my_package my_launch_file.py --enable_x True

Do I have your attention? Read on to learn more!

🤔 Why not improve the existing ROS2 launch?

Because I think it is beyond redemption and no amount of refactoring and REPs (ROS enhancement proposals) will turn the sails. Tools like the highly rated simple_launch or launch-generator exist, but still use ROS2 launch under the hood and so inherit much of its clunkiness. Rather than fixing an inherently broken solution, I decided to make a RAP - a ROS abandonment proposal :)

Essentially, better_launch is what I wish ROS2 launch would be: intuitive to use, simple to understand, easy to remember. This is why better_launch is not yet another abstraction layer over ROS2 launch; it is a full replacement with no required dependencies on the existing launch system.

🧩 Okay, what can I do with it?

Everything you would expect and a little more! The BetterLaunch instance allows you to

• create subscribers, publishers, services, service clients, action servers and action clients on the fly
• start and stop nodes
• start and stop lifecycle nodes and manage their lifecycle stage
• start and stop composers and load components into them
• organize your nodes in groups
• define hasslefree topic remaps for nodes and groups
• pass any arguments from the command line without having to declare them
• easily load parameters from yaml files
• locate files based on filenames and package names
• use string substitutions to resolve e.g. paths
• include other better_launch launch files
• include other ROS2 launch files
• let regular ROS2 launch files include your better_launch launch files
• configure logging just as you would in ROS2, yet have much more readable output
• manage your node using a nice terminal UI reminiscent of rosmon

For a quick comparison, bravely unfold the sections below:

Contributing to better_launch

Please inform the maintainer as early as possible about your planned feature developments, extensions, or bugfixes that you are working on. An easy way is to open an issue or a pull request in which you explain what you are trying to do.

Pull Requests

The preferred way to contribute to better_launch is to fork the main repository on GitHub, then submit a “pull request” (PR):

1. Create an account on GitHub if you do not already have one.

2. Fork the project repository: click on the ‘Fork’ button near the top of the page. This creates a copy of the code under your account on the GitHub server.

3. Clone this copy to your local disk:

    $ git clone git@github.com:dfki-rc/better_launch.git
   

4. Create a branch to hold your changes:

    $ git checkout -b my-feature
   

   and start making changes. Never work in the master branch!

5. Work on this copy, on your computer, using Git to do the version control. When you’re done editing, do::

    $ git add modified_files
    $ git commit
   

   to record your changes in Git, then push them to GitHub with::

   $ git push -u origin my-feature
   

Finally, go to the web page of the your fork of the bolero repo, and click ‘Pull request’ to send your changes to the maintainers for review. request.

Merge Policy

Developers have to submit pull requests. Those will be reviewed by at least one other developer and merged by the maintainer. New features must be documented and tested. Breaking changes must be discussed and announced in advance with deprecation warnings.

Roadmap

• a tool for generating launch graphs from better_launch launch files
• more interactions for the TUI like setting live parameters
• a tool for converting regular ROS2 launch files to better_launch. This is a big maybe as it seems quite annoying to do
• who knows :)

Funding

better_launch was initiated and is currently developed at the Robotics Innovation Center of the German Research Center for Artificial Intelligence (DFKI) in Bremen.