More streamlined launch system

[Terracom12]

Update the main launch system to use launch_ros and provide a centralized system to launch:

1. Missions
2. Subsystems

Also update subsystem launch files to ensure that they are well organized and document. Parameterize a log level of DEBUG wherever possible so as to allow higher-level launch files to propagate this argument downwards.

[Terracom12]

Topics for consideration:

• Namespacing of different subsystems
• Log level parameterization (see above)
• Hierarchical structuring
  • Missions -> Subsystems -> individual nodes

Note: more details will likely present themselves after the system is in a working state and we determine some testing workflows

[Terracom12]

Also, ensure that all nodes are named in launch files via the name field in the launch_ros.actions.Node action.

This is to ensure that any changes of the names in the Nodes impls will not potentially break their capability to work with the launch system.

[nate0m]

@Terracom12 can you take a look at these commits when you get a chance to see if I am on the right track. I'm thinking that I need to properly namespace the different nodes but I'm not sure, I'm gonna look into it next.

Launch
Drive
Heartbeat

I figured I'd start with drive since it seems highly testable and once we get drive working I can start on one of the missions.

large project launch file tutorial for future reference
launch_ros examples

[Terracom12]

I like the direction you're going in to create a singular centralized launch file per subsystem. For drive, perhaps, it might seem a little much since there's only two nodes that need to be launched, but I think that it will prove to be a nice abstraction to use once implemented in more complex subsystems.

As for the newly added heartbeat launch file, it is currently duplicating the YAML launch file. This is fine, for now, as I don't want to accidentally break any systems reliant upon it by deleting the YAML version. However, I would like you to add a comment to the YAML version stating something along the lines of This is deprecated; remove soon to note this duplication. It would be good to switch all launch files to python, as I think I mentioned before, if only for consistency's sake.

Looking at drive_launch.py in the launch_system repo, I'm unsure what your thought process is here. If the heartbeat_launch is included unconditionally, then we won't be able to use this file properly on the rover, as heartbeat should only be run on base-station.

ISSUE:

This line in the drive launch file is using the incorrect launch condition.

[Terracom12]

Design and Scope

Since I haven't properly written it in text yet, and my descriptions to you in person were likely more than a bit hard to follow, I'll do my best to explain the scope of my ideas for this system below, and as much of my thought process that I can reason about at this hour. I will also provide a few ideas for implementation, though don't take any of these as concrete must-dos; you might find any of them to be counterintuitive or conflicting as you think more about the design and implementation, so they are by no means set in stone.

Principles

The leading (and only) one I can think of is: the system for the end-user should be simple and easy to reason about and use. That's really all there is to be said. By end-user I am referring both to a CLI user who will be typing ros2 launch <pkg> <launch-file> into their terminal, as well as an API user which will likely come from the GUI in the near future, as well as future launch files which may hook with whatever is placed into this repo.

What does this mean for us as designers? Take into highest consideration the actions that end-users will be taking most often. Here are a few high-level examples along with a brief description of the implied behavior:

• Test autonomous navigation (only) ->
  • rover: launch robot_navigator nodes, drive motor relay, gps nodes, and autonomy_led
  • base-station: launch heartbeat, visualizers (parameterized)
• Mission-ready driving
• rover: launch drive motor relay, gps launch, camera encoders
• base-station: launch heartbeat, drive control input, camera decoders, gps at base-station (for when RTK is tested...)
• Simply drive the rover around -> (this one's already pretty easy to do with a launch file in drive, but I thought I'd just mention it)
  • rover: launch drive motor relay
  • base-station: launch heartbeat, drive control input
• Drive + arm -> same as above, PLUS
  • rover: launch arm motor relay, camera encoders
  • base-station: launch arm control input, camera decoders

That's certainly a brief list considering all the possible permutations, but I think that covers at least most of the common operations we'll want to quickly get going without any hassle in the field. Note that this is ignoring science for now, but it should certainly be taken into consideration in design.

System Design

Well-thought-out design is essential for this sort of everyday use system.

As I mentioned in my last comment, I might like the idea of a centralized launch file per subsystem, though I may need to think about this a little more. My thoughts regarding the capabilities of these scripts is for them to be able to perform every feasible permutation of actions that one might want that is within the subsystem's capabilities.
Like the one you've already implemented in drive, the behavior of said files would be completely parameterized so that higher-level launch scripts in the launch_system repo could perform any action needed.
The reason I am becoming hesitant to endorse this structure is that these amalgamated files may not actually provide any useful abstraction. For drive and arm, they are definitely fine and are in a good place, since they only really manage two nodes. The issue would come with a subsystem like autonomy where there are relatively distinct packages within that repo which can't be easily grouped as one.
I think that the best strategy right now would be to stick to package-specific launch files and the necessary grouping of components like gps + autonomy and drive + heartbeat will be fully handled within the confines of the launch_system repo. I am not sure how nicely a design like this will turn out, and I think we will both have to do a bit of thinking upon this before committing.

It would probably be helpful for you to first implement a design on paper first (be it in text, or with graphs, etc.), since a system of this nature will essentially correspond one-to-one with any paper design, save perhaps a few convoluted parameters.

Base-Rover Launch Communication

I would like launch scripts on base-station to be capable of launching nodes on both base station and the rover. See the Usage section below for an example of the utility and usage of such behavior.

There are several possible methods to do this. The simplest I can think of is to have the launch script on base-station communicate via ssh with the rover to send another launch command for separate, rover-only nodes. Here's an execution flow example:

(base) launch full drive system
-> (base) launch drive control input
-> (base) launch heartbeat
-> (base) launch ssh session to connect to rover
-> (rover@ssh) launch rover drive
-> (rover) launch drive motor relay

This ssh facility certainly have to be abstracted. Perhaps launch provides an easy way to extend a launch.action. If so, that would be a great way to implement this.

Usage

In this section I want to outline what I envision the high-level usage from an end-user's perspective to be, utilizing a few examples from the Principles section.

Say the user wants to test drive:

ros2 launch launch_system drive

Run on base-station, this should launch everything necessary to drive the rover.
Same sort of script, arm, for arm resp.

Say the user wants to run-through the equipment servicing mission:

ros2 launch launch_system servicing_mission

Run on base-station, this should launch everything necessary for equipment servicing including drive, arm and televideo.

Closing Thoughts

I left quite a few ideas out to keep this briefer, though it ended up much longer than I'd hoped, and probably a bit wordy. I appreciate you commenting on this thread with your progress, and I hope that this can clear up a bit for you. Please continue to ask here any questions that arise, along with any design proposals you would like to run by me. Thank you!