Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

modify launch docs #116

Merged
merged 5 commits into from
Jan 16, 2024
Merged

modify launch docs #116

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
0f20605
modify launch docs
StefanCaldararu Nov 20, 2023
cdfb43f
Aaron changes
StefanCaldararu Nov 20, 2023
c7df23e
add Aaron changes
StefanCaldararu Nov 20, 2023
f568baa
fix file structure
StefanCaldararu Nov 20, 2023
638888b
remove old comment
StefanCaldararu Nov 20, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 15 additions & 6 deletions docs/design/launch_system.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Launch System

The launch system is used to help spin up all the nodes associated with a given experiement (e.g. simulation, reality). This page describes the file structure and how files are designed.
The launch system is used to help spin up all the nodes associated with a given experiement (e.g. simulation, reality). This page describes the file structure and how files are designed, as well as how new launch dependencies should be added.

> [!NOTE]
> The term "orchestrator" is going to be used to describe a launch file that includes other launch files or does house keeping (defines `LaunchConfigurations`, etc.).
Expand All @@ -12,7 +12,9 @@ The file structure is as follows:
```
autonomy-research-testbed/
├── art_launch/
├── art_dev_launch/
├── launch_utils/
├── art_<vehice name>_launch/
└── art_<module>_launch/
```

Expand All @@ -22,20 +24,27 @@ Each folder contains a `launch/` folder where all the launch files should be pla

### File Naming Convention

All launch files end in `.launch.py`. Furthermore, all launch files specific to the a vehicle platform or orchastrator launch files are prefixed with `art_`.
All launch files end in `.launch.py`. Furthermore, all launch files specific to a vehicle platform or orchastrator launch files are prefixed with `art_`.

## `art_launch/`

This is where the main launch file is held: [`art.launch.py`](../../workspace/src/common/launch/art_launch/launch/art.launch.py). This file will do a few things.
This is where the main launch file is held: [`art.launch.py`](../../workspace/src/common/launch/art_launch/launch/art.launch.py). This is a common launch file through which most services will go through. `art_launch` accomplishes two tasks:

1. It will first define system wide parameters (e.g. `LaunchConfigurations`, `LaunchDescriptions`, etc.).
2. It will create a [composable node container](https://docs.ros.org/en/galactic/How-To-Guides/Launching-composable-nodes.html).
3. It will include all other orchestration launch files.
1. It will create a [composable node container](https://docs.ros.org/en/galactic/How-To-Guides/Launching-composable-nodes.html).
2. It will include all other orchestration launch files.

## `art_dev_launch/`

The purpose of this file is to define system wide parameters (e.g. `LaunchConfigurations`, `LaunchDescriptions`, etc.) for the `dev` service. This will allow all orchestrators to know which specific packages to launch, and which to ignore. This is currently set up to run a cone-based path following demo, but can be used to test any other packages.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this true? are those system wide parameters included by the vehicle specific launches or are they copied?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what you mean here; if the vehicle has the exact same intended task, then yes the params are just copied. If a certain package is intended to be launched in the exact same way, then yes it is just copied (e.g. both services want "EKF"). But in my mind two vehicles / services don't necessarily share any parameters, so they should each define them themselves.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe some of the "use_sim parameters would make sense to be shared, but even those I could see some scenarios where they shouldn't be...


## `launch_utils/`

The `launch_utils` folder contains helper functions for creating launch files. These helpers should be used throughout the launch system.

## `art_<vehicle name>_launch/`

Vehicle-specific launch files should be named following the above naming convention (`art_<vehicle name>_launch`), and should be structured in a similar way to `art_dev_launch`. This means they should only define launch arguments, leaving the process of actually launching modules to `art_launch`. This is defined to allow for multiple vehicles with various missions, sensor suites, etc. to all be launched in similar ways and all live in the same repository.

## `art_<module>_launch/`

This folders deal directly with the subfolders defined in the [ROS Workspace](./ros_workspace.md) page. For instance, the [`art_control_launch`](../../workspace/src/common/launch/art_control_launch/) folder contains launch files for the control nodes.
Expand Down