Skip to content
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

map_saver: fix saved raw image being too dark #4712

Conversation

DylanDeCoeyer-Quimesis
Copy link
Contributor

@DylanDeCoeyer-Quimesis DylanDeCoeyer-Quimesis commented Oct 7, 2024

The map cell value comes from an OccupancyGrid and ranges from 0 to
100. Dividing it by 255 makes the output ratio range from 0 to 0.39. This is clearly an error as the output should range from 0 to 1. The consequence is that the output raw image is darker than expected.


Basic Info

Info Please fill out this column
Ticket(s) this addresses /
Primary OS tested on Ubuntu 22.04
Robotic platform tested on /
Does this PR contain AI generated software? No

Description of contribution in a few bullet points

  • Fixed an error in the pixel value when saving a costmap in raw mode

Description of documentation updates required from your changes


Future work that may be required in bullet points

For Maintainers:

  • Check that any new parameters added are updated in docs.nav2.org
  • Check that any significant change is added to the migration guide
  • Check that any new features OR changes to existing behaviors are reflected in the tuning guide
  • Check that any new functions have Doxygen added
  • Check that any new features have test coverage
  • Check that any new plugins is added to the plugins page
  • If BT Node, Additionally: add to BT's XML index of nodes for groot, BT package's readme table, and BT library lists

The map cell value comes from an OccupancyGrid and ranges from -1 to
100. So, it makes no sense to divide this value by 255 when computing
the intensity ratio.
@@ -505,7 +505,7 @@ void tryWriteMapToFile(
if (map_cell < 0 || 100 < map_cell) {
q = MaxRGB;
} else {
q = map_cell / 255.0 * MaxRGB;
q = map_cell / 100.0 * MaxRGB;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to the other PR, the ROS 1 version seems to use 255 (see negate) which has been in use for 10+ years. This seems OK on face value, but I'm a little weary

https://github.com/ros-planning/navigation/blob/noetic-devel/map_server/src/image_loader.cpp#L130-L136

Copy link
Member

@SteveMacenski SteveMacenski Oct 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though, the MapMode::Scale seems to agree with you, so I'm leaning towards merging this. Lets continue to chat in the other PR you submitted and we'll handle these as a pair since they seems tied together

Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @SteveMacenski , thanks for your reviews. You are right, the other PR relies on this one. However, the opposite is not true.

In my understanding, this PR fixes a real bug. It could be merged even though discussions are still opened in the other one.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I commented on the other thread. Can you update this PR to contain the updates that supersedes #4713? Lets just put both of these together, its a simple enough set of code changes to review and are related

This implementation is inspired from the Costmap2D implementation [1].
It remains valid even if the LETHAL_OBSTACLE, FREE_SPACE,
OCC_GRID_OCCUPIED, and OCC_GRID_FREE constants are modified in the
future. Unfortunately, the nav2_costmap_2d namespace cannot be accessed
from this module, so the LETHAL_OBSTACLE and FREE_SPACE constants had
to be hard-coded.

By the same way, this commit fixes an issue in the output image where
the areas of NO_INFORMATION and LETHAL_OBSTACLES cannot be distinguished
as they both use the same value: 255. Now, the LETHAL_OBSTACLES pixels
are restored to their rightful value: 254.

[1] https://github.com/ros-navigation/navigation2/blob/main/nav2_costmap_2d/src/costmap_2d.cpp#L80
@DylanDeCoeyer-Quimesis
Copy link
Contributor Author

After investigation, I finally understood that there was no error in the initial implementation. The values stored in the .pgm are NOT meant to be equivalent to the ones stored in the Costmap2D internal grid, despite sharing the same range [0-255]. The .pgm file is just used as a uint8_t container to store the raw int8_t values of the OccupancyGrid ranging from 0 to 100. The only modified value is -1 (UNKNOWN) which is mapped to 255. So, it's expected to have a "dark" costmap stored in the .pgm file. And the UNKNOWN level is perfectly distinguishable from the others.

My apologies for the time lost.

@SteveMacenski
Copy link
Member

No worries!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants