Launch file nightmares/hygene/best practice

[Pito Salas]

This is not a complaint about ROS2 bor about any of the packages mentioned. We all are working with a set of tools and doing the best we can with them. I am just looking for advice or at least look over your shoulder at how you handle things.

We don’t usually think of them that way but launch files IMO are part of the application logic and algorithms. For example the order in which nodes are launched, the names of various arguments and defaults, and even conditionals.  

I use the nav2 package, in particular nav2_bringup. I use it via Linorobot2_navigation which invokes it (among other things). But I use a fork of linorobot2_navigation from Thomas Chou.

Each of these three have a launch file which launches nav2 via it’s own launch file but in different contexts, with different yaml files, and in different orders (potentially). 

Modularity seem to be destroyed by this. I look at the nav2_bringup package and it suggests that I make my own version of that launch file. But if I do that I am cutting off whatever linorobot2 added in terms of logic and bug fixes. For example if I compare slam.launch.py in linorobot2/ with the forked corresponding launch file I see: 

Don’t worry about the particulars. But someone did that for some good reason. They commented out a whole sub launch. 

I see three different “flavors” of the same launch file. What do I do? I am do diffs between them, back and forth, I see what one changed and the other didn’t. I check dates of update?

It’s a mess. And I think the mess comes from the fact that launch files contain logic. And while I use nav2 as a library that is tested as a unit a key source file, the .launch file, is copied and pasted as source from one client (linorobot2) to another (Thomas’s fork of it) to another (my robot.)

What’s your experience and what is your methodology? What am I missing?

(Again not complaining about anyone. I take these packages I rely on as gifts. I am just looking for a better way to deal with my particular use case.

Best,

Pito

Boston Robot Hackers && 

Comp. Sci Faculty, Brandeis University (Emeritus)

[Sergei Grichine]

You just hit ROS2's nerve, Pito - expect a lot of flying tomatoes ;-) Seriously, that's the MAIN issue we all are dealing with, so - thanks for the question.

I think of ROS2 "robot code" strictly as a collection of launch, config and description files. Anything outside is packages - standard, fixed (for bugs) or somewhat customized. Add behavior trees to that.

Writing a Node code in C++ or Python is not writing robot code, it is writing a package - more or less universal.

IMNHO, you can deal with the sea of possibilities and your robot's peculiarities in several ways:

- start basically from scratch (examples), build your own (Sigyn?)

- find a working code base and modify it, hopefully merging improvements from the upstream (Stingray? your Linorobot variant?)

- find a good architecture example and build from it, ultimately detaching from upstream (my articubot_one)

As a lazy human, capable of only speaking for myself, I resort to ChatGPT.com to explain how I deal with the problem you described. Enjoy the Iron Brain's wisdom - it is better that me talking about it ;-)

Q: Would you crawl my ROS2 robots repository and characterize how I approach the task of having multiple robots with some common code and many peculiar features (different sensors, wheels motors and even whole "base" communication protocols?

    https://github.com/slgrobotics/articubot_one/tree/dev

A: Absolutely — that’s a fascinating systems-engineering question. (yes, iron brain, flattery works ;-))

Thanks — I crawled your articubot_one dev branch and reviewed the repo structure and key files. Below is a concise but deep characterization of how you approach supporting multiple robots with shared code + per-robot peculiarities, plus a few practical observations and suggestions. I’ve cited the repository pages I inspected so you can jump to the source quickly.

---

High-level summary — your multi-robot design approach

1. Single package contains multiple robots
   The repository is organized as one main ROS package (articubot_one) that contains a robots/ directory with one folder per robot (e.g., seggy, turtle, plucky). The README explicitly describes the intent: each robot folder is a small variation (copy/rename) of a template so adding a new robot is mostly copying and tweaking per-robot files. This is a straightforward, pragmatic approach for small fleets and experimentation. GitHub+1

2. Shared runtime code + per-robot config/launch/description
   You keep the common runtime code and ROS node implementations at package root (CMakeLists/package.xml etc.), while per-robot differences live under each robot directory (config files, URDF/description, launch fragments). This pattern minimizes duplication of logic while keeping hardware differences isolated. GitHub+1

3. Configuration-driven customization
   Per-robot config/*.yaml files (examples visible in robots/seggy/config) are used to tune behavior: PID/limits, smoothing frequency, sensor/driver parameters. Launch files pick the appropriate YAMLs so the same launch logic can be reused across robots simply by pointing to different param files. This yields a composable workflow: code = shared; config = robot unique. GitHub

4. Launch + simulation parity
   The README and launch layout show you run the same stacks in simulation (Gazebo) and on hardware; simulation launch files are included so you can validate changes before deploying to a Raspberry Pi-based robot. That helps keep your “island of stability” reproducible. GitHub

5. Pragmatic template/copy pattern
   You explicitly encourage copying an existing robot folder to create a new robot. That’s fast and low-friction for a small number of platforms with modest differences (sensors, wheel encoders, comms). It trades a bit of duplication for developer speed and clarity in each robot’s directory. GitHub

---

Specific architectural/organizational patterns I observed

• Per-robot configs: robots/<robot>/config/* contain tuned parameters (e.g., velocity_smoother settings for Seggy). This is where robot-specific PID, smoothing, and sensor parameters live. Keeping these in YAML means launch-time parameterization (swap YAML → different robot behavior). GitHub

• Per-robot launch and description: each robot has its own launch/ and description/ fragments (URDF or xacro) allowing you to swap hardware descriptions without changing shared nodes. This makes it easy to re-use the same navigation stack or node graph across robots.

• One package, one build: The package-level CMakeLists.txt and package.xml indicate you build one artifact and install multiple runtime assets. That keeps the build simple for a small robot family while still supporting per-robot runtime selection. GitHub+1

• Simulator parity: simulation launch files are present and linked in README; you run the same high-level launch stacks in sim and on-robot, which is good for testing changes before flashing to hardware. GitHub

---

Strengths of this approach

• Low cognitive overhead — developers can clone and tweak a robot folder to create a new robot quickly.

• High reuse of logic — common nodes, controllers and libraries are centralized so fixes/improvements benefit all robots.

• Config-driven tuning — YAML-based parameters and per-robot config files allow per-robot tuning without code changes.

• Good sim/hw parity — having simulation launch files reduces surprises when moving to hardware.

• Practical for small fleets and rapid experimentation — fits your goal of building a shareable codebase people can drop onto their own platform.

---

Limitations / risks (and simple mitigations)

1. Copy-and-paste drift

   • Risk: Robot folders copied and modified diverge; fixes in shared behavior may not propagate if people edit robot copies.

   • Mitigation: Consider templating per-robot folders (e.g. a robots/template with a small generator script that fills in robot-specific values) or a thin layer of “robot metadata” (one YAML per robot) used by generic launch files rather than literal code copies.

2. Scaling pain

   • Risk: If you scale to many robots with many permutations of sensors/wheels/protocols, the copy approach becomes brittle.

   • Mitigation: Add a small abstraction layer: a robot_description package that consumes a robot meta-YAML and exposes parameters/URDF/driver selection. Use composition instead of duplication.

3. Hard-to-automate compatibility

   • Risk: Different robots may require different driver installs (e.g., custom kernel modules, libcreate variants). Managing those differences across multiple deployments can cause drift.

   • Mitigation: Document per-robot installation steps in each robot folder and consider small setup_<robot>.sh helpers. For more automation, provide a declarative rosdep/Ansible script per robot.

4. Testing coverage

   • Risk: Unit tests / CI that run on the shared code might miss robot-specific misconfigurations.

   • Mitigation: Add small, fast integration tests that load each robot’s launch with use_sim_time:=true to ensure param files and node graphs are valid (can be run on CI).

---

Practical suggestions you can adopt incrementally

1. Robot metadata file

   • Create robots/<name>/robot.yaml with keys: frame_id, base_type, wheel_type, encoder_ticks, sensor_list, launch_aliases. Then write small shared launch files that accept a robot argument and load the matching metadata. This reduces folder copying while keeping per-robot uniqueness.

2. Templated launch composition

   • Instead of many near-duplicate launch files, have a few generic launches that accept a robot parameter and include robot-specific fragments. Keep robot folders with only the fragments (URDF, YAML, maybe small driver node remappings).

3. Driver abstraction layer

   • For different base communication protocols (e.g., serial, CAN, custom driver board), expose a small common driver interface (topics/services) and implement adapters per base. This keeps navigation and higher layers driver-agnostic.

4. Central tuning repository

   • Keep a tuning/ folder with reference parameter sets and performance notes for each robot to make it easier to reproduce stable configurations (you already have such param files — centralizing them and linking to docs helps).

5. Add smoke tests

   • Add a small test that launches each robot’s launch file in sim for a few seconds and checks that required topics and nodes come up — very cheap CI coverage.

---

Example concrete pointers (where you already do things well)

• Your robots/seggy/config/velocity_smoother.yaml demonstrates sensible per-robot tuning: the smoothing frequency is explicitly tuned and recorded (experimental notes). Keep that style — explicit comments and links in the YAML are very helpful. GitHub

• README already documents the “copy folder” workflow — that’s great for onboarding contributors. Consider adding a short “how to add a robot” checklist linking to the per-robot metadata idea. GitHub

---

Short, plain-English characterization (one-liner)

You use a single-package, config-driven approach: centralize shared code (nodes, controllers, launches) in one package, and express robot differences through per-robot folders (URDF/config/launch fragments). It’s pragmatic, easy to understand, and excellent for small fleets and active experimentation — with straightforward steps to scale toward more formal abstractions if you need them. GitHub+1

---

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/3DC714C5-D6D3-43AA-8E80-72C266DE8EEB%40gmail.com.

--

Best Regards,

-- Sergei

[Sergei Grichine]

And, just for fun - (I shoud've requested to address me as "your Majesty" ;-)):

Q: Based on your analysis, would you briefly describe how I deal with the common issue of "Launch file nightmares/hygene/best practices"?

A: You handle the typical “launch file nightmare” in ROS2 quite elegantly — your approach emphasizes structure, reuse, and clarity over cleverness. In practice, you:

1. Use clear directory separation
   You keep per-robot launch files in each robot’s own folder, isolating differences in hardware and configuration. That prevents a single, sprawling launch tree filled with conditionals.

2. Favor explicit inclusion over logic-heavy composition
   Each launch file is a straightforward list of nodes and parameter file inclusions — not a maze of conditionals or substitutions. You rely on the filesystem hierarchy to express variation, not runtime branching.

3. Reuse base launch templates
   Shared or simulation launches live at the package root and are reused by multiple robots, maintaining consistency without duplication of node definitions.

4. Keep parameter files external
   Most tuning (topics, rates, limits) is offloaded into YAMLs, so launches remain short and declarative. This keeps launches focused on “what to start” rather than “how to configure”.

5. Document the pattern
   Your README and file organization explain how to copy or adapt launches for new robots. That documentation itself enforces hygiene — new launches are built by example, not improvisation.

In short, you manage launch-file complexity by structuring for clarity, isolating differences, and externalizing configuration, turning what’s often a tangled web into a clean, reproducible hierarchy.

[Pito Salas]

Wait friends!

Are those all ChatGPT generated answers? Because I think they miss the main point of my question and they have way too many words. Maybe my question had too many words.

My main question is about nested dependencies between packages.

A) So we have nav2 from ROS2 which contains navigation/bringup.launch plus nav2.yaml

B) We have the same bringup.launch, modified in linorobot2/linorobot2_navigation and presumably “better”. With it comes a nav2.yaml that is also “better”.

C) We have the same two files, also better, in hippo5329/linorobot2_navigation

D) Finally we have my app which uses hippo’s fork.

And this is just an example. It’s a pattern I have seen in many places. It seems to force me to understand all the intricacies of the package and each of the improvements.

Oy!

Best,

Pito

Boston Robot Hackers &&
Comp. Sci Faculty, Brandeis University (Emeritus)

> Thanks — I crawled your articubot_one dev branch and reviewed the repo structure and key files. Below is a concise but deep characterization of how you approach supporting multiple robotswith shared code + per-robot peculiarities, plus a few practical observations and suggestions. I’ve cited the repository pages I inspected so you can jump to the source quickly.High-level summary — your multi-robot design approach

> • Single package contains multiple robots

> The repository is organized as one main ROS package (articubot_one) that contains a robots/directory with one folder per robot (e.g., seggy, turtle, plucky). The README explicitly describes the intent: each robot folder is a small variation (copy/rename) of a template so adding a new robot is mostly copying and tweaking per-robot files. This is a straightforward, pragmatic approach for small fleets and experimentation. GitHub+1

> • Shared runtime code + per-robot config/launch/description
> You keep the common runtime code and ROS node implementations at package root (CMakeLists/package.xml etc.), while per-robot differences live under each robot directory (config files, URDF/description, launch fragments). This pattern minimizes duplication of logic while keeping hardware differences isolated. GitHub+1
> • Configuration-driven customization
> Per-robot config/*.yaml files (examples visible in robots/seggy/config) are used to tune behavior: PID/limits, smoothing frequency, sensor/driver parameters. Launch files pick the appropriate YAMLs so the same launch logic can be reused across robots simply by pointing to different param files. This yields a composable workflow: code = shared; config = robot unique. GitHub
> • Launch + simulation parity
> The README and launch layout show you run the same stacks in simulation (Gazebo) and on hardware; simulation launch files are included so you can validate changes before deploying to a Raspberry Pi-based robot. That helps keep your “island of stability” reproducible. GitHub
> • Pragmatic template/copy pattern
> You explicitly encourage copying an existing robot folder to create a new robot. That’s fast and low-friction for a small number of platforms with modest differences (sensors, wheel encoders, comms). It trades a bit of duplication for developer speed and clarity in each robot’s directory. GitHub

> Specific architectural/organizational patterns I observed
> • Per-robot configs: robots/<robot>/config/* contain tuned parameters (e.g., velocity_smoother settings for Seggy). This is where robot-specific PID, smoothing, and sensor parameters live. Keeping these in YAML means launch-time parameterization (swap YAML → different robot behavior). GitHub

> • Per-robot launch and description: each robot has its own launch/ and description/fragments (URDF or xacro) allowing you to swap hardware descriptions without changing shared nodes. This makes it easy to re-use the same navigation stack or node graph across robots.

> • One package, one build: The package-level CMakeLists.txt and package.xml indicate you build one artifact and install multiple runtime assets. That keeps the build simple for a small robot family while still supporting per-robot runtime selection. GitHub+1
> • Simulator parity: simulation launch files are present and linked in README; you run the same high-level launch stacks in sim and on-robot, which is good for testing changes before flashing to hardware. GitHub

> Strengths of this approach
> • Low cognitive overhead — developers can clone and tweak a robot folder to create a new robot quickly.
> • High reuse of logic — common nodes, controllers and libraries are centralized so fixes/improvements benefit all robots.
> • Config-driven tuning — YAML-based parameters and per-robot config files allow per-robot tuning without code changes.
> • Good sim/hw parity — having simulation launch files reduces surprises when moving to hardware.
> • Practical for small fleets and rapid experimentation — fits your goal of building a shareable codebase people can drop onto their own platform.

> Limitations / risks (and simple mitigations)
> • Copy-and-paste drift
> • Risk: Robot folders copied and modified diverge; fixes in shared behavior may not propagate if people edit robot copies.
> • Mitigation: Consider templating per-robot folders (e.g. a robots/template with a small generator script that fills in robot-specific values) or a thin layer of “robot metadata” (one YAML per robot) used by generic launch files rather than literal code copies.
> • Scaling pain
> • Risk: If you scale to many robots with many permutations of sensors/wheels/protocols, the copy approach becomes brittle.
> • Mitigation: Add a small abstraction layer: a robot_description package that consumes a robot meta-YAML and exposes parameters/URDF/driver selection. Use composition instead of duplication.
> • Hard-to-automate compatibility
> • Risk: Different robots may require different driver installs (e.g., custom kernel modules, libcreate variants). Managing those differences across multiple deployments can cause drift.
> • Mitigation: Document per-robot installation steps in each robot folder and consider small setup_<robot>.sh helpers. For more automation, provide a declarative rosdep/Ansible script per robot.
> • Testing coverage
> • Risk: Unit tests / CI that run on the shared code might miss robot-specific misconfigurations.
> • Mitigation: Add small, fast integration tests that load each robot’s launch with use_sim_time:=true to ensure param files and node graphs are valid (can be run on CI).

> Practical suggestions you can adopt incrementally
> • Robot metadata file
> • Create robots/<name>/robot.yaml with keys: frame_id, base_type, wheel_type, encoder_ticks, sensor_list, launch_aliases. Then write small shared launch files that accept a robot argument and load the matching metadata. This reduces folder copying while keeping per-robot uniqueness.
> • Templated launch composition
> • Instead of many near-duplicate launch files, have a few generic launches that accept a robot parameter and include robot-specific fragments. Keep robot folders with only the fragments (URDF, YAML, maybe small driver node remappings).
> • Driver abstraction layer
> • For different base communication protocols (e.g., serial, CAN, custom driver board), expose a small common driver interface (topics/services) and implement adapters per base. This keeps navigation and higher layers driver-agnostic.
> • Central tuning repository
> • Keep a tuning/ folder with reference parameter sets and performance notes for each robot to make it easier to reproduce stable configurations (you already have such param files — centralizing them and linking to docs helps).
> • Add smoke tests
> • Add a small test that launches each robot’s launch file in sim for a few seconds and checks that required topics and nodes come up — very cheap CI coverage.

> Example concrete pointers (where you already do things well)
> • Your robots/seggy/config/velocity_smoother.yaml demonstrates sensible per-robot tuning: the smoothing frequency is explicitly tuned and recorded (experimental notes). Keep that style — explicit comments and links in the YAML are very helpful. GitHub
> • README already documents the “copy folder” workflow — that’s great for onboarding contributors. Consider adding a short “how to add a robot” checklist linking to the per-robot metadata idea. GitHub

> Short, plain-English characterization (one-liner)
> You use a single-package, config-driven approach: centralize shared code (nodes, controllers, launches) in one package, and express robot differences through per-robot folders (URDF/config/launch fragments). It’s pragmatic, easy to understand, and excellent for small fleets and active experimentation — with straightforward steps to scale toward more formal abstractions if you need them. GitHub+1
>
>
>

> On Mon, Nov 10, 2025 at 11:38 AM Pito Salas <pito...@gmail.com> wrote:
> This is not a complaint about ROS2 bor about any of the packages mentioned. We all are working with a set of tools and doing the best we can with them. I am just looking for advice or at least look over your shoulder at how you handle things.
>
> We don’t usually think of them that way but launch files IMO are part of the application logic and algorithms. For example the order in which nodes are launched, the names of various arguments and defaults, and even conditionals.
>
> I use the nav2 package, in particular nav2_bringup. I use it via Linorobot2_navigation which invokes it (among other things). But I use a fork of linorobot2_navigation from Thomas Chou.
>
> Each of these three have a launch file which launches nav2 via it’s own launch file but in different contexts, with different yaml files, and in different orders (potentially).
>
> Modularity seem to be destroyed by this. I look at the nav2_bringup package and it suggests that I make my own version of that launch file. But if I do that I am cutting off whatever linorobot2 added in terms of logic and bug fixes. For example if I compare slam.launch.py in linorobot2/ with the forked corresponding launch file I see:
>

> <Screenshot 2025-11-10 at 12.33.02 PM.png>
> Don’t worry about the particulars. But someone did that for some good reason. They commented out a whole sub launch.
>
> I see three different “flavors” of the same launch file. What do I do? I am do diffs between them, back and forth, I see what one changed and the other didn’t. I check dates of update?
>
> It’s a mess. And I think the mess comes from the fact that launch files contain logic. And while I use nav2 as a library that is tested as a unit a key source file, the .launch file, is copied and pasted as source from one client (linorobot2) to another (Thomas’s fork of it) to another (my robot.)
>
> What’s your experience and what is your methodology? What am I missing?
>
> (Again not complaining about anyone. I take these packages I rely on as gifts. I am just looking for a better way to deal with my particular use case.
>
> Best,
>
> Pito
>
> Boston Robot Hackers &&
> Comp. Sci Faculty, Brandeis University (Emeritus)
>
>
> --
> You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/3DC714C5-D6D3-43AA-8E80-72C266DE8EEB%40gmail.com.
>
>
> --
> Best Regards,
> -- Sergei
>
>
> --
> Best Regards,
> -- Sergei
>
> --
> You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/CA%2BKVXVP8Jpg%2Ba07j%3DhPguyaiVUyik2_R-LqoFBVLJztXA17FDQ%40mail.gmail.com.

[James H Phelan]

Pito,

As a relative novice in robotics (despite many years of floundering) I appreciate your confusion!

"I am only an egg."  {can you place the quote?}

"Robotics is HARD!"

ROS(-2) is what takes robotics from absolutely impossible, to merely hard.

It takes a village to make a robot.  

Every one of the over 30,000 ROS2 packages (per Google AI overview) was written by someone(s).

Then someone(s) else (often one of us) thinks they can do better and does.

If a giraffe is "an animal built by committee", it's got nothing on our robots!

Launch files are the seat of customization. That's why they vary so much.

It's where you adapt the cut and paste modules to your particular robot and mission.

I have, finally, just succeeded in getting Nav2 to take my Stormy the Stingray robot from my study to the living room and back!

https://www.youtube.com/watch?v=Kj8ijCCRR4o  for iPhone piggyback video

https://www.youtube.com/watch?v=YAfdKwbhIpI  for Rviz2 screencast of the trip

For this, I wanted just the bare minimum of accessories - just motor encoders, LIDAR and, for a trial, IMU.

No camera, no depthcamera pointcloud.  No edge distance sensors or sonar (as if I had any).

For this I 'uncommented' the statement that activated the BNO055 IMU and left 'commented out' the OAK-D camera.

Some other time I'll try the camera.

Different 'expert' roboticists in HBRC (and we have MANY) do launch files differently.

Sergei likes to bundle the activation code lines at the end, handy to comment out or in.

Michael likes to put them at the end of each module.

Camp eschews launch files and likes to run each module manually in turn so he's clear on what's happening.

What are the 'best practices' of robotics?

How should you organize your directories?

What's the best overall layout for a launch file?

I, too, wish there were a Strunk and White The Elements of Style for robotics!

Maybe we could get an AI to write it for us but, given the bogus directions they've given me so far, NOT!

So, you talk to your colleagues here and at your local robotics coven.  Ask the big picture questions.

Some can look down from the upper slopes of the 'learning curve', see you struggling near the bottom, remember being there, and tell you where to place your foot for the next step.  Some cannot.

Fortunately, we have many in HBRC who can.

Come to the ROS Special Interest Group Zooms Tues 19:00 Pacific. (21:00 my time but worth staying up for)

Listen to the 'experts' troubleshoot each other's problems.  

Never be ashamed of your ignorance.  NOBODY knows it all, not even these guys.  

Which makes me feel just a little less so.

James

James H Phelan
"Nihil est sine ratione cur potius sit quam non sit"
Leibniz

[Pito Salas]

Thanks!

Best,

Pito

Boston Robot Hackers &&
Comp. Sci Faculty, Brandeis University (Emeritus)

>> <Screenshot 2025-11-10 at 12.33.02 PM.png>
>> Don’t worry about the particulars. But someone did that for some good reason. They commented out a whole sub launch.
>>
>> I see three different “flavors” of the same launch file. What do I do? I am do diffs between them, back and forth, I see what one changed and the other didn’t. I check dates of update?
>>
>> It’s a mess. And I think the mess comes from the fact that launch files contain logic. And while I use nav2 as a library that is tested as a unit a key source file, the .launch file, is copied and pasted as source from one client (linorobot2) to another (Thomas’s fork of it) to another (my robot.)
>>
>> What’s your experience and what is your methodology? What am I missing?
>>
>> (Again not complaining about anyone. I take these packages I rely on as gifts. I am just looking for a better way to deal with my particular use case.
>>
>> Best,
>>
>> Pito
>>
>> Boston Robot Hackers &&
>> Comp. Sci Faculty, Brandeis University (Emeritus)
>>
>> --
>> You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
>> To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/3DC714C5-D6D3-43AA-8E80-72C266DE8EEB%40gmail.com.
>
> --
> You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/67ed254e-9dcc-4756-b912-f8e41c87d49d%40hal-pc.org.

[Pito Salas]

Based on my previous rant, I started looking for alternatives to struggling with ROS2 launch files. It would have to be very simpatico with the existing launch files so that each can call the other without problems.

Have you seen Better Launch? It reads pretty promising so I will experiment with it a little and let you know what I find. Maybe you’ve tried it?

I think there may be more tools to supplement, improve or replace launch files in a fully compatible way. Have you seen any others?

Pito

[James H Phelan]

Pito,

"Oy!"  Exactly!

James H Phelan
"Nihil est sine ratione cur potius sit quam non sit"
Leibniz

[James H Phelan]

Pito,

I'm all for a better mousetrap, but 'community support' is critical.

Although launch files can be (ARE) a nightmare, your colleagues will be familiar with them and can help.

But they won't be familiar with Better Launch so you'll be on your own when (not if) you run into problems.

There's hope that the greater ROS community will catch wind of Better Launch and start to incorporate the idea into the standard.

But as for myself, I'll seek safety in the herd.

James

James H Phelan
"Nihil est sine ratione cur potius sit quam non sit"
Leibniz

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/67DC32A5-CE8D-41C0-A854-792C5DB6019F%40gmail.com.

[Sergei Grichine]

James — you brought up an interesting point in this conversation: is there a particular “preferred style” we should learn and adopt when creating launch files for our robots?

I’d guess that “do what Sergei (or Michael, or Camp...) does” isn’t the best answer to that. But “do what the official ROS packages do” comes pretty close to a good one.

It’s a bit like studying art or music — the best way to develop a good sense of taste and style is by experiencing a lot of prior art.

When creating my own launch files, I tried to read and understand those from /opt/ros, and follow their lead. I can’t judge how well I learned, but my proof is in the working robots.

To illustrate the point, I zipped all launch files from /opt/ros/jazzy/shared on my machine:

sergei@sergeiu7:/opt/ros/jazzy/share$ find . -name "*.launch.py" | zip /tmp/launch_files.zip -@

 and fed it to chatgpt.com with the following prompt:

Q: "I have an archive of launch files from standard ROS2 Jazzy distribution. Please come up with a "style guide" - how to properly structure my own launch files, how to properly handle includes, parameters and arguments - make it a high-level architecture overview, rather than a detailed instructional. Identify patterns and inconsistencies in how launch files are written. Provide a style guide based mostly on these files, not generic considerations."

A: https://chatgpt.com/s/t_69129a0d98ec8191a47edb59b4e4e7c3   (yes, that's many words - but well worth scrolling through)

I couldn't resist to proceed with: "Would you like me to also provide a companion template for each robot’s *_driver.launch.py (the small per-robot include this file expects)? It can follow the same style and be ready to drop into each robot’s launch/ folder."

A: https://chatgpt.com/s/t_69129b48b2748191ba92f6a94b8ee0ba  - that's an interesting template, worth exploring further to me.

Best regards,

-- Sergei

To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/F7021555-7844-4828-87EC-7ACBF58950D4%40gmail.com.

[James H Phelan]

Sergei,

Leave it to you to find the "right way" to do things!

I think we can all benefit from the resulting 'style sheet' for better exchange.

I'm going to put them with my other 'cheat sheets'.

James

James H Phelan
"Nihil est sine ratione cur potius sit quam non sit"
Leibniz

To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/CA%2BKVXVOb7bgaWBhWZTR-baLU9SNk3m5cDTqGFWezy4%3Dgbrs%2Biw%40mail.gmail.com.

[Pito Salas]

Hi James

I totally agree with your point. I am violating my own rule in trying this. But I am so annoyed with launch files. I don’t know about you but all that boilerplate “noise” drives my senses nuts. So I will try bl and see how it goes. I may not need it’s power because yaml launch files *are* supported but they are not totally powerful and very poorly documented…

Best,

Pito

Boston Robot Hackers &&
Comp. Sci Faculty, Brandeis University (Emeritus)

> To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/7df16a08-0fdb-42c3-a678-c4fe54a5510b%40hal-pc.org.

[Michael Wimble]

As you may know, both Sergei and I are working on writing a comprehensive book on ROS2. Well, Camp, Ross, Jim, I think are also write a book but I think theirs is pointed more are a project-motivated, more of a beginner market (correct me if I’m wrong). So, today, I’m working on writing several chapters that, together, I hope will make it easier to understand the launch eco system. Watch this space for further info.

[camp .]

> Well, Camp, Ross, Jim, I think are also write a book but I think theirs is pointed more are a project-motivated...

    It's me, Dr. Alan Federman, Ross Lunan, Phil McCary III, and Thomas Messerschmidt. We're the Mockers, and we're making MockBOTs. That is "Mock TurtleBots." In addition to total world domination, one of our primary goals is to beat you guys to press!  :-]]] 

Thanks,

Camp

On Tuesday, November 11, 2025 at 06:33:09 PM EST, Michael Wimble <mwi...@gmail.com> wrote:

As you may know, both Sergei and I are working on writing a comprehensive book on ROS2. Well, Camp, Ross, Jim, I think are also write a book but I think theirs is pointed more are a project-motivated, more of a beginner market (correct me if I’m wrong). So, today, I’m working on writing several chapters that, together, I hope will make it easier to understand the launch eco system. Watch this space for further info.

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/5744FB48-A0F9-4070-BD6A-A6A80DE8128E%40gmail.com.

[Michael Wimble]

Well, my last book was self published. Let me see what I can get done before the zoom meeting. 

On Nov 11, 2025, at 6:18 PM, camp . <ca...@camppeavy.com> wrote:



To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/34298782.7145121.1762913889382%40mail.yahoo.com.