-
Notifications
You must be signed in to change notification settings - Fork 91
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.
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
planner_3d: fix cost calculation bug on in-place turning #725
Conversation
This comment has been minimized.
This comment has been minimized.
Codecov Report
@@ Coverage Diff @@
## master #725 +/- ##
==========================================
+ Coverage 88.67% 88.87% +0.20%
==========================================
Files 62 62
Lines 4582 4584 +2
==========================================
+ Hits 4063 4074 +11
+ Misses 519 510 -9
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a test case if it's not too complicated?
This comment has been minimized.
This comment has been minimized.
I added small tests in test_planner_3d_cost.cpp. |
This comment has been minimized.
This comment has been minimized.
[528] PASSED on noeticAll tests passed
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This PR fixes a bug in
GridAstarModel3D::cost()
.When the movement between
cur
andnext
is an in-place turning,cm_[cur]
is not evaluated. I think it is a simple mistake.In contrast, when the movement between
cur
andnext
is not an in-place turning,MotionCache
is used to interpolate the movement of the robot. BecauseMotionCache::Page::getMotion()
does not return the last pose (I guess this is needed to avoid double counting of costs), thecm_[next]
is not evaluated. Therefore, when only thecm_[next]
is 100 and the costs of other poses are not 100,GridAstarModel3D::cost()
returns a positive value mistakenly.Because of these bugs, the planner_3d could create a path in which the robot collides with an obstacle in the following situation.
Assume that the cost of the grid (10, 5, 0) is 100, and the costs of other grids are not 100. For example, the path (5, 5, 0) -> (10, 5, 0) -> (10, 5, 3) can be generated.
The interpolated poses between (5, 5, 0) to (10, 5, 0) generated by
MotionCache
do not include (10, 5, 0) as it is the last pose, so the cost of the grid (10, 5, 0) is not evaluated.The interpolated poses between (10, 5, 0) to (10, 5, 3) do not include the first pose (10, 5, 0) because of the bug in the cost calculation of in-place turning motion.
As a result, the cost of (10, 5, 0) is never evaluated and planner_3d can generate an untraversable path.