-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Constrained smoother failing with duplicate path pose #4755
Comments
Can you manually backport that to humble and submit a PR? Regardless, I'm happy to merge that in as a fix which moves the ball forward. The way I read this is that this is seemingly a full fix. The end-point of the path was incorrectly indexed due to the binning that PR resolves -- so we add in the extra point to have the exact goal criteria met. If the goal binned into the search space is correct, then we wouldn't have the extra point. If you see it fixing this problem and the problem is related to the end point only, I'm convinced this is a full solution.
We do catch points that are overlapping using the This is more evidence to me that the backport fix is a full fix :-)
Where do you see implicit unsigned int and float/double conversions? We're reasonably careful about those globally in Smac. |
There are a few that throw errors but the one that is a bit worrying to me is this for example:
node->pose->theta is float but getAngleFromBin takes unsigned int. Also here it is a float but used as an index:
I can create a PR for this. If I backport more features to the humble branch is there a template for creating backport PRs? |
There's no specific template, just open them with the eq. |
Opened backport pull request #4760 |
Merged! |
Bug report
Required Info:
Steps to reproduce issue
Any goal with a heading that triggers this issue:
#4596
and then using the constrained smoother on the path
Expected behavior
A normal smoothed path
Actual behavior
Additional information
I already debugged this and the issue is that the smoother crashes on duplicate poses because the distance between two poses is used in the smoothing cost as a division. Here the current segment length is used in a division while it can be 0 for duplicate poses. This happens in all branches, not just humble as far as I am aware. The duplicate poses should not be there to begin with so I looked at the smac_hybrid code and found the indexing to be the issue. Here the analytic expansion gets the index for the node that the analytic expansion goes through. This index in some cases fails to retrieve the goal pose because of the angle inaccuracy. When that happens the index next to it is wrongly set and this causes the last node of the expansion to be set as the parent of the goal pose even though their poses are identical. This seems to be fixed when backporting #4636 to the humble branch but I am a bit sceptical if this is a full fix or just covers it better than before.
Feature request
Feature description
This should be fixed in both the smoother and the smac planner. The smoother should check for duplicate poses and throw an error as the error message for this case is currently very cryptic compared to how simple the error is. On the other hand the problem of having the last pose duplicated by the smac planner should be fixed and probably will be when this change is backported to the humble branch.
Implementation considerations
The smoother just needs a check for the distance between poses and throw a meaningful error message. The smac planner needs the linked PR backported to the humble branch. I am not sure if this fully fixes the issue though as I am not 100% sure what is exactly happening and if this might have just been an accidental fix that doesnt fully cover the problem. I think another cause for this might be that there are a lot of implicit conversions. Most worrying for me are the ones between unsigned int and float/double. Fixing those is a fairly big task as compiling with -Wconversion -Werror throws a lot of errors but this might be part of what causes this error.
The text was updated successfully, but these errors were encountered: