search

PX4 / PX4-Autopilot

PX4 Autopilot Software
https://px4.io
BSD 3-Clause "New" or "Revised" License
8.2k stars 13.37k forks source link

vehicle_gps_position_s.time_gps_usec is zero for a few seconds after power-up #1474

Closed hsteinhaus closed 9 years ago

hsteinhaus commented 9 years ago

After a cold start, vehicle_gps_position_s.time_gps_usec is published with invalid time values (0), even if the GPS seems to have an 3D lock already and seems to report valid position info. A few seconds later, a valid time is reported. The problem also might be on the device side - I observed the problem using a Zubax UAVCAN GNSS ( @pavel-kirienko )

A printf in my code (fix: vehicle_gps_position_s.fix_type, time_gps: ts_pos:vehicle_gps_position_s. time_gps_usec, etc.) produces the following output:

fix: 3 time_gps: 0, ts_pos: 25182013 ts_vel: 25182013 ts_time: 25182013 fix: 3 time_gps: 0, ts_pos: 25381667 ts_vel: 25381667 ts_time: 25381667 fix: 3 time_gps: 0, ts_pos: 25581633 ts_vel: 25581633 ts_time: 25581633 fix: 3 time_gps: 0, ts_pos: 25781710 ts_vel: 25781710 ts_time: 25781710 fix: 3 time_gps: 0, ts_pos: 25982194 ts_vel: 25982194 ts_time: 25982194 fix: 3 time_gps: 0, ts_pos: 26181587 ts_vel: 26181587 ts_time: 26181587 fix: 3 time_gps: 0, ts_pos: 26377703 ts_vel: 26377703 ts_time: 26377703 fix: 3 time_gps: 0, ts_pos: 26583912 ts_vel: 26583912 ts_time: 26583912 fix: 3 time_gps: 0, ts_pos: 26784712 ts_vel: 26784712 ts_time: 26784712 fix: 3 time_gps: 0, ts_pos: 26984303 ts_vel: 26984303 ts_time: 26984303 fix: 3 time_gps: 0, ts_pos: 27183873 ts_vel: 27183873 ts_time: 27183873 fix: 3 time_gps: 1417176275400100, ts_pos: 27484590 ts_vel: 27484590 ts_time: 27484590 fix: 3 time_gps: 1417176275600100, ts_pos: 27593131 ts_vel: 27593131 ts_time: 27593131 fix: 3 time_gps: 1417176275800100, ts_pos: 27793879 ts_vel: 27793879 ts_time: 27793879 fix: 3 time_gps: 1417176276000100, ts_pos: 27999840 ts_vel: 27999840 ts_time: 27999840 fix: 3 time_gps: 1417176276200100, ts_pos: 28178566 ts_vel: 28178566 ts_time: 28178566

pavel-kirienko commented 9 years ago

This behavior is caused by the u-blox internal logic.

Zubax GNSS employs the field gnss_timestamp for UTC timestamp, which is set to 0 if the GNSS receiver is unable to estimate the current UTC time. There are two preconditions, either one needs to be met in order for the receiver to estimate UTC:

In your case, it seems like the receiver has managed to find the GPS-only fix first, and GLONASS became available a few seconds later, making the UTC time observable.

Note that this behavior is documented in the message definition file.

hsteinhaus commented 9 years ago

Pavel,

thanks for the explanation. With this knowledge, I can easily work around it in the APM driver.

May be we should update the documentation whithin the ORB topic definition as well (I can do that). With the current description in the topic, this behavior is a little bit surprising and gives room for nasty bugs, like setting the system clock to 0 after getting the first fix.

Alternatively, a flag similar to vel_ned_valid (gps_time_valid?) could be a more obvious hint to the user of the data. @LorenzMeier, what do you think?

BTW, very interesting that this issue is once again related to the leap seconds thing (compare https://github.com/Zubax/zubax_gnss/issues/1 ).

LorenzMeier commented 9 years ago

The flags have the challenge of being ignored - how about defining 0 as the invalid value and checking for != 0?