Failed Conversion, out of legal UTM zone

[MCFurry]

Using the latest jazzy driver we have a couple of situations where warning like these are output by the driver:
W 2025-02-19 13:10:57:614 [novatel.oem7.main::UTMPointFromGnss] Failed Conversion (tot: 177511) Lat: 48.3748 Lon: 16.7065; Zone: 31 Latitude 48.3748, longitude 16.7065 out of legal range for UTM zone 31

But as far as I understand from the code, the driver itself should switch UTM zone when the lat/lon coordinates are in another zone?

• Why is the driver not switching UTM zone?
• Does this mean the outputted lat/lon positions are now not to be trusted? Or is only the UTM and this Odom topic now failing?

[valgur]

I wonder if it could be related to this BESTUTM decoding bug that used to be present in NovAtel EDIE: novatel/novatel_edie#77

[novatel-applications-engineering]

Hi @MCFurry, thanks for reporting this. For the Jazzy release, we did not expect any changes for the UTM conversion relative to the current Humble branch.

To confirm, have you been using our humble driver regularly and not run into issues with this? What version of the humble driver have you been using?

As a more secure file transfer method, could you please reach out to support.novatel@hexagon.com and send us a ROS bag that you have collected that had this issue? We would especially appreciate a ROS bag with oem7raw. Please reference case 00354665 when you send it in.

[MCFurry]

We've been using the Humble driver before but now that we're on Jazzy we've been having way more machine operating hours. Hence it could be the issue was there in Humble as well but never noticed.

I'll reach out to send a bagfile with Novatel data in it.

[novatel-applications-engineering]

Thanks @valgur we'll definitely keep you comments in mind when looking at the data. As a general note, the odometry topic is published using the data from BESTPOS which is then converted to UTM coordinates for odometry specifically using the function UTMPointFromGnss.

[novatel-applications-engineering]

While help from @MCFurry, our team has helped identify the source of the issue. This is applicable to Humble as well, not just Jazzy.

When the receiver does not have a position such as at startup, it reports a latitude, longitude and height of 0,0,0 such as:
<BESTPOS USB1 0 69.0 UNKNOWN 0 15.000 024c0020 cdba 17399
<     INSUFFICIENT_OBS NONE 0.00000000000 0.00000000000 0.0000 0.0000 WGS84 0.0000 0.0000 0.0000 "" 0.000 0.000 0 0 0 0 00 00 00 00

This can occur if there has not yet been enough time to acquire signals, if you start in a GNSS denied environment or if your antenna is disconnected.

This data then gets received in the ROS driver, and the GPSFix outputs a 0,0,0 position. GPSFix then drives odometry. Odometry takes the 0,0,0 latitude, longitude and converts it to UTM coordinates. 0 degrees longitude is UTM Zone 31. Once UTM Zone 31 is determined, we then use that as our preferred zone in conversion.

Once you get a position, BESTPOS and GPSFix report a proper output. But odometry is still trying to use UTM Zone 31 even though we are in a different position.

Our team is currently working on a bug fix for this. But the immediate workaround is to not launch the driver until the receiver has a position.