[#1267] Extract 3D ground-truth detections from LGSVL
Description
See #1267 (closed)
Notes for reviewer
I tested this manually and it looks ok by eyeball
Please also check locally that the instructions for testing in the design doc are ok.
I made a simplifying assumption that LGSVL output are level on the ground. Let me know if that's ok. Otherwise I'd need some advice how to implement the 3D rotation idiomatically in Autoware.Auto. I checked my assumption on the autonomous stuff parking lot and the contribution of the quaternion from x and y is very small:
orientation:
x: 0.008025458082556725
y: 0.0070118666626513
z: -0.8366996645927429
w: 0.5475582480430603
--
orientation:
x: -0.0031861045863479376
y: 0.0018856896786019206
z: -0.9404424428939819
w: 0.33993256092071533
--
orientation:
x: -0.01815083809196949
y: 0.0065773287788033485
z: -0.9978581666946411
w: 0.06250099837779999
--
orientation:
x: 0.0027677007019519806
y: 0.011632697656750679
z: -0.8398739695549011
w: 0.5426495671272278
--
orientation:
x: 0.004030623473227024
y: -0.008634227328002453
z: 0.9339773058891296
w: -0.35720518231391907
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