PPK Improvement Discussion

[AlexKlimaj]

Describe problem solved by the proposed feature

A number of people would like to use PPK with the ARK RTK GPS/Ublox F9P. Currently PPK is only supported by using GPS Dump, which logs the raw UBX messages in the ulog file. Then the UBX needs to be pulled out of the ulog and then converted to RINEX.

Describe your preferred solution

We should support saving a native RINEX obs file with the same name as the ulog. Then support saving a json file with the camera capture data, again with the same name.

For running on the ARK RTK GPS, the data needs to be transmitted over CAN before it can be logged.

Describe possible alternatives

Please let me know if I have captured all the requirements.

Additional context

Relevant input capture work. https://github.com/PX4/PX4-Autopilot/pull/21962

[ChinaMan28]

PPK would be a tremendous implementation to have. At the moment the UAS manufacturing industry is focusing on RTK, which is mystifying when the people who are actually using these systems have already transitioned or are starting to transition to a PPK workflow.

The positives of a PPK workflow over RTK boils down to "peace of mind". Never having to worry about someone else's network being down, or out of data coverage, or need the use of more than one base station. I'd rather ppk multiple flights, then to ever have to worry about well or how reliable someone else's base is set up.

Utilizing RTK or anything live for that matter is only good in areas where you have zero doubt you'll have data connection issues, drone connection issues, or base station issues. Other than that PPK is dawae.

[dagar]

This is only tangentially related to PPK workflow, but here's what I have in mind for improving GPS timesync (and time in general) in the system. The overlap with PPK is that by having the system time much more closely in sync with GPS (including CAN GPS) will make it easier to log any input capture and not have to worry about things like physically connecting all the way back to the GPS (eg ublox EXTINT).

1. gps driver timepulse gpio event and populating sensor_gps.timestamp_sample (maybe configure to use with UBX-TIM-TP so it's explicit), timestamp_sample should be 0 if we don't have it
2. ekf2 respect timestamp_sample rather then using EKF2_GPS_DELAY
3. sensors/vehicle_gps_position use sensor_gps.timestamp_sample and sensor_gps.time_utc_usec to set PX4 system clock
4. UAVCAN time ditch dedicated timer and use HRT everywhere (CAN nodes need to tolerate 1 big monotonic time jump backwards?). Then in UAVCAN GNSS the timestamp is the real timestamp_sample from the same timebase the FMU is already using.

The benefits for PX4 are that the GPS navigation solution timing is now perfect for onboard sensor fusion with the IMU, etc (we'd be immune to jitter in the driver, extra ubx data, etc), and the actual system clock would be very closely synced with GPS time.

We already have parts of this with drivers/pps_capture, but that's only beneficial when post processing logs, I want the actual system to benefit from this integration.

[tnedev]

Is there any progress on this?