/novatel/oem7/odom z-position inconsistency

[JTomasi]

Describe the bug Hello,

After collecting a bag of data using the ROS driver with a Novatel CPT7 device, I noticed that the z-position estimate reported on the /novatel/oem7/odom topic seemed to jump between height above mean sea level and the height above the ellipsoid. Please see the figure attached.

Upon reading through the driver source code, in particular, the bestpos_handler.cpp file, I saw in the initialization function a comment indicating that the driver will dynamically determine which position source is used if not overridden by the user. I have not set any config parameters (I am using the default parameters in the ROS driver version 2.3.0). I was wondering if the behaviour of the device is intended or not?

The processPositionAndPublishGPS() function is responsible for setting the altitude of the gpsfix_ member variable which is used to populate the nav_msgs::Odometry message that is output to the novatel/oem7/odom topic. I noticed that there are several instances where this altitude value is updated. The lines where the altitude is populated are as follows: • Line 466 (Height above mean sea level) • Line 581 (Height above the ellipsoid) • Line 588 (Height above the ellipsoid converted to height above mean sea level using the udulation value) • Line 602 (Height above the ellipsoid converted to height above mean sea level using the udulation value)

In my plot, I notice that almost all of the output z-positions are the height above the ellipsoid, with a few instances where the z-position is output as the height above mean sea level.

I am unsure if this is a bug or is intended. What is the intended altitude output of the /novatel/oem7/odom topic? Is the behaviour I am experiencing with the current version of the driver intended?

To Reproduce Record data with the default ROS driver.

Expected behavior The filtered z-position would remain consistent (with respect to mean sea level OR with respect to the ellipsoid).

Screenshots

Environment (please complete the following information):

• OS: Ubuntu 20.04
• Version 2.3.0

[novatel-applications-engineering]

Hello,

Thank you for providing all the details. It is a bug, the output must be consistent. For now, the only workaround is setting the 'position_source' parameter to disable the dynamic change of position source.

[novatel-applications-engineering]

Hello,

Would you be able to provide us receiver output that causes this condition?

Set the 'oem7_receiver_log_file' variable under the driver namespace to the capture file name, and run your test. e.g. in the launch file:

If this is not possible, please capture a bag file with driver output.

Please send the file(s) to support.novatel@hexagon.com , referencing this issue.

Thank you.

[novatel-applications-engineering]

Hello,

The issue is caused by the driver not dealing with lever arm settings correctly.

For now, we recommend to select either 'BESTPOS' or 'INSPVAS' as the source of GPSFix /NavSatFix / Odometry, and disable dynamic switching.

Please set the 'position_source' parameter to either 'BESTPOS' or 'INSPVAS'.

The height is output as follows:

BESTPOS: geoid at GNSS antenna INSPVAX: geoid at IMU center of navigation + lever arm z offset INSPVAS: ellipsoid at IMU center of navigation + lever arm z offset

[edwardribbit]

Does using SETINSTRANSLATION USER 0 0 0 have any effect on reported position? Is there a config parameter to report position at the centre of navigation only without any offset to antenna?

[JTomasi]

Hello,

I am following up to confirm if this bug is being addressed and if so, when we can expect the fix to be implemented?

Thanks!

[novatel-applications-engineering]

Hi @JTomasi , apologies for a late reply here. We should have been more specific in the previous response on Sept. 22. The issue seen here was found to not be a bug, but rather a configuration issue. An explanation of proper configuration is below:

1. Users must configure the lever arm to output INSPVA/INSPVAX at antenna center; do not specify “position_source” parameter. Our documentation makes this suggestion.

2. If the user needs the position output at point other than antenna center, they should configure their ROS transform tree appropriately. This may require use of ‘static transform broadcaster’ to broadcast the static translation from the antenna center to the desired point.

This way, ROS messages GPSFix, NavSatFix, Odometry output the highest quality position at any given time at the highest possible rate (that one of the INSPVAS).

Also, any translations from antenna center are explicit and visible to ROS tools.

If the users do not wish to use ROS transforms, and instead want the driver to output the position at the correct point:

1. Users must configure lever arm appropriately
2. Users must lock the position source to INSPVA.

Locking to BESTPOS as position source should used for special cases only.