Enforce 3 decimal precision when writting map.yaml

[doisyg]

---

Basic Info

Info	Please fill out this column
Ticket(s) this addresses	(add tickets here #1)
Primary OS tested on	Ubuntu
Robotic platform tested on	Dexory's
Does this PR contain AI generated software?	No
Was this PR description generated by AI software?	No

---

Description of contribution in a few bullet points

Draft to discuss the impact and potentially a better method.
(and for context, I am playing with big maps and non zero origins)

I was using the same code snippets as in the map saver and realized that YAML::Precision(3) is not behaving as I expected. In other words, it is not enforcing a 3 decimals precision, but a 3 digits float precision, e.g.:

For map.info.origin.position.x = 12345.123, what will be written in the yaml is 1.23e+03, loosing quite a lot of precision.

So I am enforcing now 3 decimals (i.e mm) by converting to a string with cpp (method std::string to_string_with_precision(double value, int precision)).

Then I removed e << YAML::Precision(3);, but due to a yaml-cpp converting to the closest cpp float/double representation, we have trailing numbers, see jbeder/yaml-cpp#761 (comment)

So I set back e << YAML::Precision(7);, meaning that with this PR we will have mm accuracy up to almost 10km

Description of documentation updates required from your changes

Description of how this change was tested

---

Future work that may be required in bullet points

I have similar float comparison issues in the costmaps layers that arise with non zero OccupancyGrid origins and big size, due to double <-> float casting and trailing numbers.

For instance here:

navigation2/nav2_costmap_2d/plugins/static_layer.cpp

Lines 191 to 196 in 40a0451

	if (!layered_costmap_->isRolling() && (master->getSizeInCellsX() != size_x ||
	master->getSizeInCellsY() != size_y ||
	master->getResolution() != new_map.info.resolution ||
	master->getOriginX() != new_map.info.origin.position.x ||
	master->getOriginY() != new_map.info.origin.position.y ||
	!layered_costmap_->isSizeLocked()))

.

To makes things easier, in https://docs.ros2.org/foxy/api/nav_msgs/msg/MapMetaData.html, resolution is a float (32 bits) and the origin coordinates are double (64 bits), so we have some funky casting when doing multiplication.

I am wondering how to solve best generally. Maybe rounding to mm accuracy everywhere in the costmap layers ? wdyt ?

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
• Should this be backported to current distributions? If so, tag with backport-*.

[mergify]

@doisyg, your PR has failed to build. Please check CI outputs and resolve issues.
You may need to rebase or pull in main due to API changes (or your contribution genuinely fails).