I’ve been trying out Dead Reckoning for the past week, and I am really impressed on Ardupilot’s performance to estimate’s the drone position during a GPS failure. Currently using a Cube Orange+, but I’ll eventually be working with an ADIS16740 FC, hoping it will track it’s position even better.
However, I have to set EK3_SRC1_POSZ=1 (BARO) if I want decent results. If I set EK3_SRC1_POSZ=3 (GPS), which is what we want our quadcopter to fly with, the altitude isn’t stable at all when disabling the GPS (using an auxiliary switch as described in the Dead Reckoning tutorial here). However, according to the EK3 Source Selection documentation:
Option 3: GPS is only recommended if the vehicle will fly long duration flights where the air pressure may change significantly and the vehicle has a high quality GPS (e.g. UBlox F9P dual band). In case of GPS failure the EKF will fallback to using the barometer (if present)
Which is not something I’ve observed.
Here are 3 trials that show that, at the moment of the simulated GPS loss, the GPS and Baro register a drop/variation in altitude, while the EKF (from the POS log structure thinks it is steadily hovering.
(In the 3rd figure, I had to manually increase the altitude at 18 seconds as the drone was nearing the ground)
The vertical line is the moment I trigger the GPS loss, and the dashed vertical line is when the Dead Reckoning Failsafe begins. I have the Failsafe set to “Do Nothing”, to observe how well the position is held for a simple hover. In my mind, I’m observing that the EKF fallbacks on the IMU for altitude estimation.
Here is a log of this occurring (twice). Maybe I’ve got a wrong parameter?
Is this normal? Or should I look into lua scripting to switch the Altitude Source to Baro automatically?
Had a look at the code. It seems that there is no Baro fallback when simulating a GPS loss. But there should be in the case of an actual GPS loss. In AP_NavEKF3_PosVelFusion.cpp:
The condition for detecting GPS loss is only if the last time AP received a GPS update was more than 2 seconds ago. But lastTimeGpsReceived_ms gets updated, even when there’s a simulated GPS loss.
So a condition should be added to account for the simulated GPS loss, ideally with the same 2 second delay from the moment on simulated GPS loss (which is currently not recorded, as currently the only thing that happens when activating the GPS Disable switch is the change of the GPS status to NO_FIX)
EDIT: Actually, timing[instance].last_fix_time_ms is the time variable not getting updated when simulating GPS loss, and also when there is a real GPS loss. So the condition for Baro Fallback should use that instead of timing[instance].last_message_time_ms. Unfortunately, last_fix_time_ms is not present in AP_DAL_GPS, which is what is used in AP_NavEKF3_PosVelFusion.cpp.
