nav2_smac_planner: Fix incorrect conversion between costmap and worlrd coordinates #4949
Conversation
… coordinates The Smac planner computes paths using costmap coordinates (cell indexes). Therefore, conversions between world coordinates and costmap coordinates are required. The issue was that the world-to-costmap conversion used a floor approximation, while the costmap-to-world conversion behaved as if a ceil approximation had been used. As a result, the planner's output was often shifted in the negative direction. This commit corrects the inconsistency to ensure proper alignment between costmap and world coordinates.
There was a problem hiding this comment.
This was changed in July to supposedly fix the issue in reverse: 137b93b (and that test that was added is now failing in this PR 😉 )
What distribution did you test this against? Main / Rolling / Jazzy is -, but humble / iron is + due to backport conflicts, so it seems like humble/iron are outliers and inconsistent with the current state of the main branches.
I'm therefore wondering if this change is actually correct. I think perhaps you need to invert that in Humble / Iron that you're using and the main change is incorrect. Or, do you think the previous PR to change it that's in Main/Rolling/Jazzy is wrong? Its worth pausing and having that conversation since your issue reports using iron but this PR is against main. I'm wondering if you inverted them in iron to fix it, but then submitted the inversion in main assuming that they were the same (and they're not; apparently).
Please test and let me know :-) If the right answer is to fix Iron / Humble, submitting PRs with the compliment of this change there should be easy for me to merge. I don't typically accept new PRs for EOL distributions (Iron), but I will in this case since this is presumably a mathematical error
The Smac planner computes paths using costmap coordinates (cell indexes).
Therefore, conversions between world coordinates and costmap coordinates are required.
The issue was that the world-to-costmap conversion used a floor approximation, while the costmap-to-world conversion behaved as if a ceil approximation had been used.
As a result, the planner's output was often shifted in the negative direction.
This commit corrects the inconsistency to ensure proper alignment between costmap and world coordinates.
Basic Info
Description of contribution in a few bullet points
Description of documentation updates required from your changes
Description of how this change was tested
Future work that may be required in bullet points
For Maintainers: