Wrong timestamp sample for SensorGPS.msg #40
Description
Greetings,
I am implementing an UKF for a drone with delay compensation and I realized that the field timestamp_sample of the message SensorGPS.msg looks incorrect, and thus I cannot fuse the updating correctly.
I have found the following issues:
- There is a huge difference between the timestamp sample and the timestamp of the message.
- The sample timestamp is the same in consecutive message, why is the data published again if it is the same sample?
- The timestamp_sample is decreasing instead of increasing.
Please find below the output echoing the topic:
timestamp: 1716551917338873
timestamp_sample: 1716551400058872
device_id: 10813445
lat: 244364943
lon: 546138945
alt: 3191
alt_ellipsoid: -24508
s_variance_m_s: 0.11500000208616257
c_variance_rad: 0.7475395202636719
fix_type: 4
eph: 0.23800000548362732
epv: 0.3880000114440918
hdop: 0.7400000095367432
vdop: 1.0499999523162842
noise_per_ms: 62
automatic_gain_control: 0
jamming_state: 1
jamming_indicator: 13
spoofing_state: 1
vel_m_s: 0.027000000700354576
vel_n_m_s: 0.027000000700354576
vel_e_m_s: 0.003000000026077032
vel_d_m_s: -0.015000000596046448
cog_rad: 0.8297291398048401
vel_ned_valid: true
timestamp_time_relative: 0
time_utc_usec: 1718107126750189
satellites_used: 28
heading: .nan
heading_offset: 0.0
heading_accuracy: 0.0
rtcm_injection_rate: 0.0
selected_rtcm_instance: 0
timestamp: 1716551917441887
timestamp_sample: 1716551400058872
device_id: 10813445
lat: 244364942
lon: 546138945
alt: 3168
alt_ellipsoid: -24531
s_variance_m_s: 0.1300000101327896
c_variance_rad: 0.7475398182868958
fix_type: 4
eph: 0.23800000548362732
epv: 0.3880000114440918
hdop: 0.7400000095367432
vdop: 1.0499999523162842
noise_per_ms: 62
automatic_gain_control: 0
jamming_state: 1
jamming_indicator: 13
spoofing_state: 1
vel_m_s: 0.023000001907348633
vel_n_m_s: -0.01600000075995922
vel_e_m_s: 0.017000000923871994
vel_d_m_s: -0.01900000125169754
cog_rad: 0.8297291398048401
vel_ned_valid: true
timestamp_time_relative: 0
time_utc_usec: 1718107126875189
satellites_used: 27
heading: .nan
heading_offset: 0.0
heading_accuracy: 0.0
rtcm_injection_rate: 0.0
selected_rtcm_instance: 0
timestamp: 1716551917624890
timestamp_sample: 1716551400058863
device_id: 10813445
lat: 244364942
lon: 546138944
alt: 3138
alt_ellipsoid: -24561
s_variance_m_s: 0.1080000028014183
c_variance_rad: 0.7475400567054749
fix_type: 4
eph: 0.23800000548362732
epv: 0.3880000114440918
hdop: 0.7400000095367432
vdop: 1.0499999523162842
noise_per_ms: 62
automatic_gain_control: 0
jamming_state: 1
jamming_indicator: 13
spoofing_state: 1
vel_m_s: 0.024000000208616257
vel_n_m_s: 0.023000001907348633
vel_e_m_s: -0.007000000216066837
vel_d_m_s: -0.02500000037252903
cog_rad: 0.8297291398048401
vel_ned_valid: true
timestamp_time_relative: 0
time_utc_usec: 1718107127000189
satellites_used: 28
heading: .nan
heading_offset: 0.0
heading_accuracy: 0.0
rtcm_injection_rate: 0.0
selected_rtcm_instance: 0
timestamp: 1716551917825881
timestamp_sample: 1716551400058863
device_id: 10813445
lat: 244364942
lon: 546138943
alt: 3133
alt_ellipsoid: -24566
s_variance_m_s: 0.08100000023841858
c_variance_rad: 0.7475403547286987
fix_type: 4
eph: 0.24000000953674316
epv: 0.39100003242492676
hdop: 0.7400000095367432
vdop: 1.0499999523162842
noise_per_ms: 62
automatic_gain_control: 0
jamming_state: 1
jamming_indicator: 13
spoofing_state: 1
vel_m_s: 0.04200000315904617
vel_n_m_s: -0.00800000037997961
vel_e_m_s: -0.04100000113248825
vel_d_m_s: -0.023000001907348633
cog_rad: 0.8297291398048401
vel_ned_valid: true
timestamp_time_relative: 0
time_utc_usec: 1718107127250188
satellites_used: 28
heading: .nan
heading_offset: 0.0
heading_accuracy: 0.0
rtcm_injection_rate: 0.0
selected_rtcm_instance: 0
timestamp: 1716551917937042
timestamp_sample: 1716551400058863
device_id: 10813445
lat: 244364943
lon: 546138943
alt: 3113
alt_ellipsoid: -24585
s_variance_m_s: 0.08100000023841858
c_variance_rad: 0.7475405335426331
fix_type: 4
eph: 0.24000000953674316
epv: 0.39100003242492676
hdop: 0.7400000095367432
vdop: 1.0499999523162842
noise_per_ms: 62
automatic_gain_control: 0
jamming_state: 1
jamming_indicator: 13
spoofing_state: 1
vel_m_s: 0.04800000041723251
vel_n_m_s: 0.003000000026077032
vel_e_m_s: 0.04700000211596489
vel_d_m_s: 0.032999999821186066
cog_rad: 0.8297291398048401
vel_ned_valid: true
timestamp_time_relative: 0
time_utc_usec: 1718107127375188
satellites_used: 27
heading: .nan
heading_offset: 0.0
heading_accuracy: 0.0
rtcm_injection_rate: 0.0
selected_rtcm_instance: 0
timestamp: 1716551918072862
timestamp_sample: 1716551400058863
device_id: 10813445
lat: 244364943
lon: 546138943
alt: 3107
alt_ellipsoid: -24592
s_variance_m_s: 0.09800000488758087
c_variance_rad: 0.7475407719612122
fix_type: 4
eph: 0.24000000953674316
epv: 0.3920000195503235
hdop: 0.7400000095367432
vdop: 1.0499999523162842
noise_per_ms: 62
automatic_gain_control: 0
jamming_state: 1
jamming_indicator: 13
spoofing_state: 1
vel_m_s: 0.030000001192092896
vel_n_m_s: 0.012000000104308128
vel_e_m_s: -0.02800000086426735
vel_d_m_s: 0.006000000052154064
cog_rad: 0.8297291398048401
vel_ned_valid: true
timestamp_time_relative: 0
time_utc_usec: 1718107127500188
satellites_used: 27
heading: .nan
heading_offset: 0.0
heading_accuracy: 0.0
rtcm_injection_rate: 0.0
selected_rtcm_instance: 0
I have been checking how the timestamp of the GPS is handled within the PX4 code, should I subtract to the timestamp the fix delay between the GPS and the IMU so it can be properly fused?
Thanks!