I have a setup in the SITL simulator where the drone takes off using OpticalFlow and then switch to GPS once it is initialized (separate EKF Srcs).
The switch is controlled by a companion computer via MAVLink and the basics work. The problem is how to know when the GPS is ready?
If the switch happens too soon, the EKF triggers failsafe. In the SITL, the cutoff is usually about 30-40 seconds after startup, corresponding to the NavEKF3_core::readyToUseGPS() method.
When starting with GPS, the pre-arm checks or “IMUn is using GPS” message can be used to know when the GPS is ready. But when taking off with OpticalFlow I have not found anything to go on.
I added some debug output and it turned out that the part in NavEKF3_core::readyToUseGPS() that took longest was actually delAngBiasLearned (delta angle bias). So just looking at the GPS status / accuracy etc. is unfortunately not enough.
Does anyone know if it is safe to take off using OpticalFlow during this calibration or does it have to be stationary before arming? (delAngBiasLearned is true for a short while in the beginning which allows the switch to relative aiding so it is possible)
@priseborough and @rmackay9, apologies for pinging you about a 6 year old commit, but I’m curious about the meaning of the EKF filter status flag pred_horiz_pos_abs.
Before this commit, it seems that pred_horiz_pos_abs could have been used to check if the GPS is ready for a switch, but after it always has the same value as horiz_pos_abs.
If not, is there some other way to know when it is safe to switch from OpticalFlow to GPS that takes the delAngBiasLearned into account? If possible via MAVLink, but a lua script could work as well…
There is a LUA script (ahrs-source-gps-optflow.lua) that transitions from OF to GPS (and back) when GPS becomes available/valid and vice versa. This script has some checks to establish if there is a valid GPS for the transition. I’m not sure how well this works but the documentation claims it works. Perhaps this will help?
I did look at the lua script and it uses at the GPS speed accuracy values to determine if it is healthy.
I assume this works well for transitions, but as far as I can tell the delAngBiasLearned is not directly related to the GPS and at least in my tests, the GPS becomes healthy, sets Gps Origin etc. long before delAngBiasLearned becomes true.