Hi all,
We have an aircraft running px4 v1.13.3, using dual gps (CUAV RTK devices, connected to uart) as its heading source. Recently we have ran into positioning and heading errors with it. There have been several different, probably related problems, some of which appeared with single-gps setups as well (using ARK RTK device). These all happened in the same flight, in this order:
- Global position and heading is lost
While flying normally, the aircraft suddenly reported global position and heading loss at least twice, the second time for so long that the heading source got reset to the magnetometer. See the map for how the fused global position (blue) deviated from the gps positions (red and green):
Short heading losses before the global position loss are visible in the logs:
- Fix type dropping to 0
In “normal” conditions, the fix type of the “base” receiver is mostly RTK fixed, sometimes dropping to normal GPS fix; and the fix type of the “rover” is constant RTK fixed. However in some occasions, the fix type of them drops to 0. That also triggers a “jump” in the gps coordinates. The fix type drop has been experienced with the ARK device as well, but in that case the number of satellites used stayed positive (above 30).
Other details of the aircraft:
FC hardware: pixhawk 6x
FC software: px4 v1.13.3 with custom controller modules
Other details on the flight:
- datastream from the gps devices were continuous, so timeout of the data is not probable, and also not reported
- after the global position was lost, the mavsdk-python “health” message showed the global position as false, but did not recover once the global position was reset in the flight controller
- the meaning of
vehicle_status/onboard_control_sensors_present,_enabledand_healthare a bit confusing (at least the logged values). It seems that the gps got enabled when it was considered not healthy (which kept being not healthy during the flight, probably causing the mavsdk problem above) (the plot shows only the gps-bit of the bitmasks)
- gps jamming doesn’t seem the cause, at least according to the logs, the jamming values was well within the limits suggested in px4’s docs
The question we are trying to answer now for some time now is why are these intermittent dropouts and deviations happen? Since we don’t know the reason, we cannot be sure the aircraft can recover from it (like the logs show) every time or once it will cause a fatal problem crashing the aircraft. Also, as the mavsdk message (the vehicle_status bitmasks?) does not reset, it is impossible to make sure during flight that the aircraft is recovered.
Has anyone experienced these kind of issues before, or has some guesses/advice to find the root cause/elimination method?