Static Layer Ignores Map Orientation

[DLu]

[dornhege]

This also affects AMCL. Should I open a new issue for that?

As a quick fix I would at least like a graceful exit when orientation is set != 0.

[DLu]

Yes, please open another issue.

[mkhansenbot]

I am trying to use a map with a rotated orientation, and the global costmap is not using that same orientation, which makes it impossible for me to navigate using that map. Will this bug ever be fixed?

[mikeferguson]

Adding "help wanted" tag -- AFAIK there are no active developers with a plan to tackle this (would also need to tackle the AMCL-related issue mentioned above). If someone is interested in tackling this, please speak up!

[Ekanshh]

I am trying to use a map with a rotated orientation, and the global costmap is not using that same orientation, which makes it impossible for me to navigate using that map. Will this bug ever be fixed?

I too got stuck with the same issue. The problem is that the map follows the orientation but not the costmap. The only way I found to get this work is to tweak the <map_file.pgm> image which created for mapping the world. Just rotate the <map_file.pgm> present in your package and then check the Rviz map. Hopefully It will solve your problem.

[dirkdior]

Also got stuck with the issue, in my case though my workaround involved making an empty call to the global_localization service which scatters the amcl particles, then I rotate the robot for a few seconds to converge the amcl particles and get proper orientation, I repeat the process over again just to be thorough. This works well for me so far.

[olivier-haddad]

I also encountered this issue.

I don't really understand the policy of closing issues that are obviously bugs and leaving the corresponding Yaw parameter in the mapping package, even if the packages may not be maintained by the same person(s).

The ROS governing body should at least make sure of either of those:

• that the documentation states the issue and warns not to use the yaw parameter in all the packages that use the map
• that the packages with the bug issue a warning or exit if the yaw is !=0

This will go a long way towards not having some unsuspecting folks waste a lot of time on this.

[mikeferguson]

I don't really understand the policy of closing issues that are obviously bugs and leaving the corresponding Yaw parameter in the mapping package, even if the packages may not be maintained by the same person(s).

Not sure what you are saying here - this ticket is open.

The ROS governing body should at least make sure of either of those:

• that the documentation states the issue and warns not to use the yaw parameter in all the packages that use the map
• that the packages with the bug issue a warning or exit if the yaw is !=0

This will go a long way towards not having some unsuspecting folks waste a lot of time on this.

The documentation for the map_server package in the section about the YAML spec states "Many parts of the system currently ignore yaw". If you think other parts of the documentation should carry a warning, anyone can edit the ROS wiki.

[olivier-haddad]

@mikeferguson I was commenting on the fact, maybe in the wrong thread, that two issues mentionned here, #661 and #1511 were closed without fix (one with "won't fix"). As the other packages closed the yaw issue without planned fix, this parameter is just misleading (why would there be a useless parameter) and a quick search on the issue shows the number of people that encountered the issue.

You are right that the map_server package indeed states that "other parts of the system currently ignore yaw". It is however lost in a regular paragraph, not emphazised in any way. I certainly missed it.

[mikeferguson]

The first link is really a duplicate of this one - it's a fairly standard practice to close duplicates (with a link to the original, as is posted in that issue).

The second link is an entirely different project - navigation2 for ROS2.

As for the "useless parameter" - someone was probably trying to be "generic" with the map_server, but the implementation in nav/nav2 was never completed for either the costmaps nor AMCL (it's a decent amount of work - you'd have to re-render the costmap rather than just copying it - and also have to deal with aliasing issues). While lots of folks have noted or complained about the issue, in the 12 years since the nav stack was initially released, nobody has found it troubling enough to implement a solution.

This ticket remains both open, and tagged as "help wanted".