Origins orientation not taken into account in static costmap

ros-navigation / navigation2

ROS 2 Navigation Framework and System

https://nav2.org/

Other

2.53k stars 1.28k forks source link

Origins orientation not taken into account in static costmap #1511

Closed maxlein closed 3 years ago

maxlein commented 4 years ago

Just found out that if you add a rotation to the map.yaml's origin, the global costmap is not rotating the map. So map and static costmap differ in der global representation.
But I am not sure if this is a bug, or if this is just how the costmap "works".
I think in ROS 1, it was the same.

Map without rotation:

image: map.pgm
mode: trinary
resolution: 0.05
origin: [-21.2, -14.9, 0]
negate: 0
occupied_thresh: 0.65
free_thresh: 0.25

Map with rotation:

image: map.pgm
mode: trinary
resolution: 0.05
origin: [-21.2, -14.9, 1.56]
negate: 0
occupied_thresh: 0.65
free_thresh: 0.25

Rotated gridmap

Bug report

Required Info:

Operating System:
- Ubuntu 18.04
Version or commit hash:
- navigation2 eloquent-devel sources
DDS implementation:
- CycloneDDS

Steps to reproduce issue

Start map server with a map where its origin is rotated.

Expected behavior

Global Costmap is also rotated and in sync with the map topic.

Actual behavior

Global costmap is not getting rotated.

SteveMacenski commented 4 years ago

To be upfront, I won’t have the cycles to work on this. If this is something important, I’d recommend taking the initiative and implementing it yourself and submitting a PR.

This is one of those “yeah, we know its a problem” but has reasonable workarounds so it doesn’t usually cause a huge hassle.

SteveMacenski commented 4 years ago

Steps (from slack):

ask for a file (if not provided on launch line, opening up one of those dialogs to navigate to the file)
Show the file and let the person rotate the map only, no translation
Once done save the map under a filename
Bonus points: in the Qt GUI, adding some coordinate lines so they can see how the frame aligns with the window.
Super bonus points that maybe I'll do one weekend as a toy: use PCA to "autorotate" to the principle components as a first guess

SteveMacenski commented 3 years ago

Closing this ticket as "wontfix", this has the same item as https://github.com/ros-planning/navigation/issues/166 which hasn't had any progress in 7 years. The fix is pretty easy to rotate the map in a graphics editing tool if you don't visually like the way its oriented. To implement this, we'd own a bunch of sin/cos functions every time we did a map operation that would likely increase the overhead of the costmap system non-trivially.

This is something that if were implemented, would be considered for merging, but given its legacy of 7 years of non-action and a reasonable work around for a visual-developer-only issue, I think its safe to remove this from any "todo" list in the issue tracker.