[!TIP] Just looking for the documentation? We also have various 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.

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.

Instead of dozens of imports and class instances for even the most basic tasks, your launchfiles could look as simple and beautiful as this:

from better_launch import BetterLaunch, launch_this

@launch_this
def my_main(enable_x: bool = True):
    """This is how nice your launchfiles could be!
    """
    bl = BetterLaunch()

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

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

# You can use `ros2 launch`, too, but `bl` is better :)
$> bl my_package my_launch_file.py --enable_x True

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

🧞‍♀️ Everything you need to know

• The What and Why
• Differences to ROS2
• Installation
• HowTo
• Examples

⛲ Highlights

📟 The TUI

[!NOTE] Using the TUI

better_launch comes with an optional, unobstrusive TUI (terminal user interface) based on prompt_toolkit, which will hover below the log output.

See the single line of shortcuts at the bottom? That’s the TUI, and it will never take up more than 3 lines! Despite its simplicity, the TUI allows you a comfortable degree of control over all nodes managed by the better_launch process it is running in:

• listing a node’s services and topics
• starting and stopping nodes
• triggering lifecycle transitions
• changing the log level
• etc.

# Run this line to see it in action!
bl better_launch 02_ui.launch.py

⛱️ TOML launchfiles

[!NOTE] Specification

For those with aversions against using a turing-complete programming language to specify system startup - fear not! better_launch introduces a new launchfile format based on TOML.

enable = true

[a_simple_cube]
if = "${enable}"
func = "find"
package = "better_launch"
filename = "cube.sdf"

[print_me_baby]
func = "log"
severity = "info"
message = "Found cube at ${a_simple_cube}"

Under the hood, TOML launchfiles result in calls to the BetterLaunch singleton, but offer a more focused and constrained feature set. If you are still missing ROS1 XML launchfiles (and substitutions like ${arg my_arg}!), these are for you!

🌱 Contributions

File truncated at 100 lines see the full file

Contributing to better_launch

Please inform me as early as possible about your planned developments. You may have noticed that better_launch is somewhat opinionated and I will be picky about what to include :) An easy way is to open an issue in which you explain what you are trying to do.

Issues

Any issues should be reported on the better_launch issue tracker. This is also the preferred way of getting support, making feature requests, etc. Keep your post short and concise, I have other books to read :) I will ask clarifying questions as needed.

Pull Requests

The preferred way to contribute to better_launch is to fork the repository on GitHub and work from the devel branch, 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 -b devel git@github.com:dfki-rc/better_launch.git
   

4. Create a branch to hold your changes:

    $ git checkout -b my-feature devel
   

   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
• something for converting regular ROS2 launch files to better_launch. Some people had good experiences using LLMs
• 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.