inconsistent frame rate and wrong time to value assignment

[ga58lar]

Firstly, thank you for the OSS ROS 2 driver!

Describe the bug I am using your PwrPak7D-E2 receiver with the latest ROS 2 humble driver on a normal vehicle. I attached the config at the end of the issue.
A closer look at the data revealed that the ROS 2 messages do not arrive at a constant data rate. This can be seen, for example, with BESTPOS, BESTGNSSPOS, or BESTVEL. In addition to the inconsistent frequency, there also appears to be an incorrect assignment of the values to the time stamps. If the vehicle direction and speed remain constant, there are jumps when plotting the values over time. However, if you plot BESTPOS with lat/lon as a 2D plot, for example, you will see a constant distribution of the measurement points. This indicates that the position data is recorded correctly, but is time-stamped and sent with a delay/inconsistently. You can see the behavior in the attached diagrams. I have also included a short ros2bag with BESTPOS data.

To Reproduce Steps to reproduce the behavior:

1. ros2 launch novatel_oem7_driver oem7_net.launch

Expected behavior Consistent data rates and outputs of the ROS2 topics.

Screenshots

Environment:

• OS: Dockerized - Ubuntu 22.04
• ROS 2 Humble
• novatel_oem7_driver/humble: d82103e6018b27f1519020d0ec5b26534221db08
• Receiver: PwrPak7D-E2 with dual antenna setup
• Firmware: 7.09.02

Attachments custom_init_commands.yaml
novatel_bag.zip

[novatel-applications-engineering]

Hi @ga58lar We would like to gain more understanding about your network and the connections used, can you please submit a case through NovAtel's support website, in order to provide us with more details? Please mention this GitHub issue in the case.

[ga58lar]

After communicating with the support, I found that the issue lies in the way the driver handles the GNSS data before publishing it. The NovAtel driver uses rclcpp::Node::now() as header timestamp. It seems like there is an internal buffering happening, looking at the attached image, where I plotted the BESTPOS-lat value over the GPS time from the BESTPOS-milliseconds value and over the UNIX time from the header stamp. It is obvious from the plot that the receiver receives the data at a constant rate but does not publish it at a constant rate.
A possible solution would be to re-write the driver to use the stamp from gps_weeks and gps_milliseconds. I am using a sensor abstraction between the NovAtel topics and my software, therefore, I will calculate the header stamp of the abstracted topic from the gps times.