[#1273] Add options to prepend points to the trajectory and to customize the first point
Description
This MR allows customization of the trajectory sent to the controller by adding 3 node parameters.
-
lane_planner_nodes
.-
include_start_point
: whether to include the ego pose at the moment the goal was sent in the trajectory (defaulttrue
).
-
-
behavior_planner_nodes
.-
include_current_state
: whether to include the current pose of ego in the trajectory (default:true
). -
prepend_distance
: the desired distance of the trajectory behind ego (i.e., behind the trajectory point closest to ego) (default:0.0
m).
-
Closes #1273 (closed)
Notes for reviewer
How to test
Make sure to display the Trajectory
in rviz (topic /planning/trajectory
).
It also helps to deactivate the controller by removing the mpc
here.
Include start pose and current state, no preprend (default)
include_start_point: true
include_current_state: true
prepend_distance: 0.0
Expected result: first trajectory point is always at the ego position. simplescreenrecorder-2021-08-23_17.11.37
Include start pose and current state, prepend behind ego
include_start_point: true
include_current_state: true
prepend_distance: 5.0
Expected result: current ego state always included in the trajectory + points behind ego (extrapolated using the initial pose in the beginning). simplescreenrecorder-2021-08-23_17.16.01
Only prepend
include_start_point: false
include_current_state: false
prepend_distance: 5.0
Expected result: no trajectory points outside of the centerline + points behind ego. simplescreenrecorder-2021-08-23_17.00.44
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. If in doubt, pick from this list -
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; e.g. [#928] Fix foo in bar
-
- Code correctness
-
The problem/feature is solved (reproducibly) -
The solution is performant enough for the use case in mind
-
- 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 component test is included
Checklist for new package
- Structure
-
The package name and organization into files is sensible -
The files have a license header as per CONTRIBUTING.md -
Core functionality is separated from the ROS2-specific part where reasonable -
There is a design document that explains the package at a high level -
The design document is linked in an index.md
file -
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 to
AutowareAuto
, it should match the output ofautoware_auto_create_pkg
regarding-
calling autoware_set_compile_options
for each compiled target -
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 is opened and checked to render 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 -
If there are multiple commits, the MR title has to contain the issue number as it's used for the squashed commit message; e.g. [#928] Fix foo in bar
-
Assign MR to @merge-bot