NDT only runs for one optimization step per iteration on Elise #1559
Labels
anomaly
Something isn't working
Severity 2
Critical fault in mission essential capability, with a workaround
Milestone
Comments
msmcconnell
added
anomaly
9 tasks
msmcconnell
added a commit
to usdot-fhwa-stol/autoware.ai
that referenced
this issue
Dec 14, 2021
This PR resolves usdot-fhwa-stol/carma-platform#1559 by updating the NDT optimization parameters to reflect the new PCL 1.9+ API changes. ROS Noetic targets PCL v 1.10 whereas ROS Kinetic target PCL v 1.7.2 It seems that in v1.9 the API for the error epsilons was changed (see PointCloudLibrary/pcl#1724) Now the translation epsilon is actually a squared error and there is an additional epsilon which is the rotation angle error in an axis-angle rotation representation. This PR updates the translation error setting in NDT to therefore be 0.001 which makes the optimization selectivity closer to the old value (TODO I'm still evaluating if 0.001 or 0.0001 (which is 0.01*0.01) is better) (No longer investigating, see comment below). The rotation error is computed as 1.0-translation error which is the default used technique in the ICP matching algorithm (seems they didn't add a default for NDT matching). This may seem strange but actually makes sense as the input is cos(angle error). And arccos(0.999) =0.044 rad or 2.5 deg error. This PR also removes the --sequential build argument from the docker image to hopefully speed up build times. I performed some comparison runs using translation epsilons of 0.001 and 0.0001 respectively. Both gave similar over all NDT score values. The first value required fewer iterations overall and hit the max less often while the second value more often hit the max. Both ran within reasonable time frames though the second value did go above 100ms more frequently. Since I did not see a noticeable improvement in NDT score, I plan to continue with 0.001 for now as it stayed under the 100ms execution time target more reliably. However, I have left a comment describing that 0.0001 can work as documentation of its feasibility.
|
Resolved by above PR |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Types of Issue
Descriptive summary
While testing on Elise and develop it was observed that NDT seemed to reach the minimum slower than normal. Investigation shows that the iteration count of NDT matching was never more than 1 which meant the optimization only ran as fast as the loop rate of NDT matching.
Carma version where this issue was discovered
release/elise and develop after elise was merged in
Expected behavior
NDT behaves similarly to 3.9 release
Actual behavior
See description
Steps to reproduce the actual behavior
Run carma in default configuration or NDT only matching mode
Related work
The text was updated successfully, but these errors were encountered: