Explanation TimeSync with ROS2 and XRCE-DDS bridge

ROS 1 / ROS 2
1

Hello,

I have a Jetson Xavier NX as a companion computer for my drone which uses a pixhawk flight controller. I have the latest firmware beta version on the pixhawk as I’m using ROS2 to communicate with the Jetson thanks to the XRCE-DDS bridge. I have a USB camera connected to my Jetson and a ROS topic that publishes detections from this camera’s images at certain timestamps. I need to synchronize these timestamps with the timestamps coming from the pixhawk (for example a topic like /fmu/out/vehicle_local_position).

Thus, I’m looking for a way to synchronize the timestamps. In dds_topics.yaml I noticed the topic /fmu/out/timesync_status but I don’t understand how it works and what I need to do with it even though I looked at https://mavlink.io/en/services/timesync.html

When echoing this timesync_status topic I get such values :

timestamp: 1685627282799767
source_protocol: 2
remote_timestamp: 1685627282796707
observed_offset: -1685624282890066
estimated_offset: -1685624282890795
round_trip_time: 4654

I’m not sure how to interpret those values given that when I publish for example to the topic /fmu/in/vehicle_command, my code sets the timestamps with the following command : uint64_t timestamp = node->get_clock()->now().nanoseconds() / 1000;
and the corresponding published message looks like this :

timestamp: 1685627425075143
param1: 1.0
param2: 4.0
param3: 2.0
param4: 0.0
param5: 0.0
param6: 0.0
param7: 0.0
command: 176
target_system: 1
target_component: 1
source_system: 1
source_component: 1
confirmation: 0
from_external: true

and when I listen to a topic like /fmu/out/vehicle_local_position coming from the pixhawk, the timestamps have a very similar value :

timestamp: 1685626860535678
timestamp_sample: 1685626860535269
xy_valid: false
z_valid: true
v_xy_valid: false
v_z_valid: true
x: 0.0004316429840400815
y: -0.00031042000045999885
z: -2.9434313774108887
delta_xy:
- 3.0614144552743028e-09
- 1.0718685494737201e-08
xy_reset_counter: 1
delta_z: 0.0
z_reset_counter: 1
vx: 0.0009532887488603592
vy: -0.0001496115728514269
vz: -0.0008669407689012587
z_deriv: -0.0017052473267540336
delta_vxy:
- 6.991126610955689e-07
- 2.4477471924910787e-06
vxy_reset_counter: 1
delta_vz: -0.00020352080173324794
vz_reset_counter: 1
ax: -0.00023102709383238107
ay: 0.03141145408153534
az: -0.03113688714802265
heading: -2.064100742340088
delta_heading: -2.2383649349212646
heading_reset_counter: 1
heading_good_for_control: false
xy_global: false
z_global: false
ref_timestamp: 0
ref_lat: .nan
ref_lon: .nan
ref_alt: .nan
dist_bottom: 0.10035395622253418
dist_bottom_valid: false
dist_bottom_sensor_bitfield: 0
eph: 0.01077322755008936
epv: 0.2710666060447693
evh: 0.03419855237007141
evv: 0.07012168318033218
dead_reckoning: true
vxy_max: .inf
vz_max: .inf
hagl_min: .inf
hagl_max: .inf

Thus I am confused by the crazy offset given by TimeSyncStatus (estimated_offset: -1685624282890795).

Can anyone explain to me how this works please ?

Thanks a lot :smiley:

2

Hi @Toto ,

time synchronization is automatically managed by the XRCE-DDS bridge.
estimated_offset compares the time difference (in microseconds) between PX4 and the clock on the agent side (pay attention that this is the wall clock, not the ROS clock. These two are normally the same as long as the ROS 2 parameter use_sim_time is false). So let’s assume that you have use_sim_time=false.
The PX4 clock starts counting and is resetted when you power up the board. The Jetson instead is using unix time format, therefore its zero is set to JAN 1st, 1970.
You should see now why the offset is so large.

So the bridge automatically compute the offset, then applies it to every message that go from ROS 2 to PX4 and vice-versa. You can see it by using listener command on the nuttx shell or by using the mavlink inspector and comparing the timestamp values with the ones of the associated ROS 2 topics.

You can use the timestamps of /fmu/out/vehicle_local_position (or any other topic) without any further modification :smile:

2 Likes
3

Fantastic thanks a lot !

Key take-away : the XRCE-DDS bridge makes my life easier :smiley:

2 Likes