Resolve "Split launch file into pipelines to make them re-usable"
Description
This MR resolves #857 (closed) by creating a new package autoware_auto_launch
which splits launch files into re-usable pipelines. These have been split into the following categories:
- localization
- mapping
- perception
- planning
- sensors
- simulator
- vehicle
- visualization
Some notes about implementation details:
- The
mpc_controller
node is launched with the the planning stack since these components are highly related. - The
map_publisher
is a node that belongs to thendt_nodes
package however it more related to the mapping than localization. This could be improved in the future by moving this node into the mapping sub-directory. - The name of the package
autoware_auto_launch
is also subject to change, if there are better alternatives please feel free to suggest them.
Notes for reviewer
- All launch should be able to be launched and should not output any errors
- Launching all launch files should run the AVP demo.
-
sensors
is a launch file which manipulates sensor data - this could be moved into perception since the only pointclouds are being filtered. The rationale for keeping filtering nodes separate from perception nodes as perception nodes also does classification and segmentation of sensor data (i.e. input = pointcloud, output = bounding box). While filtering nodes would keep the sensor data types consistent (i.e. input = pointcloud, output = pointcloud).
Pre-review checklist for the author before submitting for review
Every developer is encouraged to be familiar with our contributor guidelines.
- MR formalities
-
"WIP" or "Draft" removed from the MR title -
MR title and description help a friendly human understand the problem solved -
MR has a link to the original issue in the description, if it exists -
If the source branch is on a fork, MR is configured to allow commits from developers with access to push to the target branch -
Sensible notes for the reviewer added to the section above to facilitate review -
Target branch set correctly. Default: master
-
MR assigned to a capable reviewer. Default: @JWhitleyWork -
Splitting the MR into smaller, easier-to-review merge requests was considered
-
- Code and tests
-
Code is properly formatted -
Tests affected by new code pass locally -
Reasonable coverage with unit tests of 90+%; else create a follow-up ticket -
Review any // TODO
item added in the MR that can be addressed without the reviewer's help
-
- Documentation
-
Any new and modified code has accurate doxygen documentation -
Any diagrams are committed
-
Checklist for the reviewer
Only the reviewer is allowed to make changes in this section!
Items not applicable to this MR are crossed out by the reviewer.
[ ] For new nodes, the checklist is expanded and reviewed-
For a new package, the checklist is expanded and reviewed -
Reviewer crossed out non-applicable items
Checklist
If the MR provides an improvement, don't hesitate to add a
Mark all the items that are done.
Checklist for development
- Basic checks
-
The MR title describes what is being done on the ticket -
All functional code written in C++14, tooling code may be written in Python 3.5+ or Bash -
The first commit has a proper commit message to be used as a basis for the squashed commit created at the very end
-
- Code correctness
-
The problem/feature is solved (reproducibly) -
The solution is performant enough for the use case in mind -
Any disabled lints inside the code or at the package level are justified
-
- Open work
-
Any added source-code comment about future work refers to a follow-up GitLab issue explicitly; e.g., // TODO #551 refactor code below
-
- Documentation
-
New classes, methods, functions in headers are documented with doxygen-style comments -
If implementation (of a function...) is modified, the doxygen documentation is updated accordingly -
The design article is updated with the implementation -
Drawings are created when needed and committed to git
-
Modified files have a license that is compatible with AutowareAuto
-
- Testing
-
Code coverage with unit tests does not decrease. Aim for coverage with unit tests of 90+%; else create a follow-up ticket -
Unit tests make sense and cover the business logic and error cases -
Integration tests are sensible and not flaky
-
Checklist for new ROS2 nodes
-
Every node is registered as a component -
The naming conventions are followed -
At least the basic launch integration test is included
Checklist for new package
- Structure
-
The package name and organization into files is sensible -
Core functionality is separated from the ROS2-specific part where reasonable -
There is a design document that explains the package at a high level -
All dependencies are explicitly included in package.xml
with the proper<*depend>
declaration
-
When starting from scratch, new packages should be created with the autoware_auto_create_pkg
macro and they will automatically satisfy the following criteria.
-
If an existing package is added toAutowareAuto
, it should match the output ofautoware_auto_create_pkg
regarding-
same set of linters -
visibility control -
finding build dependencies in cmake
withament_auto_find_build_dependencies()
-
installing with ament_auto_package()
-
Post-review checklist for the author
After receiving approval:
-
Rendered documentation looks as expected -
All checkboxes in the MR checklist are checked or crossed out. Syntax example: 1. [ ] ~~this item crossed out~~
-
Developers were informed about breaking changes on slack in the committers-autoware-auto channel -
Assign MR to maintainer with sufficient rights to merge. Default: @JWhitleyWork