Fix user UTM conversion and catch GeographicErr to not crash navsat_transfrom node #917
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The service setUTM was introduced in ROS1 at first:
#627
And later also ported to ROS2:
#856
However, a small error was left here where the
gpsFixCallback()
does a forward conversion without specifying the utm-zone. So GeographicLib does the conversion based on lat/lon only.In case the lat/lon in the gpsfix message are in a neighbouring zone, utm-coordinates for that other zone are calculated and when
mapToLL()
converts back with the savedutm_zone_
, also incorrect lat/lon values are produced.You can spot the difference here, where in the original introduction
utm_zone_
was used:https://github.com/cra-ros-pkg/robot_localization/pull/627/files#diff-e2f5adb2665b53274a429c05d5f267ae428aee0cb9e5fdb058f46cb3993a9617R636
But in the ROS2 port it dropped out:
https://github.com/cra-ros-pkg/robot_localization/pull/856/files#diff-e2f5adb2665b53274a429c05d5f267ae428aee0cb9e5fdb058f46cb3993a9617R668
Moreover, callers to
mapToLL()
are now also protected from crashing the node in case of an exception.