I need guidance on implementing an early, immediate stop when position accuracy degrades during autonomous flight.
Hardware Setup
Flight Controller: CUAV X7+
GPS: Neo 3
RTK with local base station
Mode: AUTO (waypoint mission)
Terrain following enabled
No companion computer currently, but can be added if needed
Operational Context
Flight altitude: 2–3 meters AGL
Environment: Farm with moderately dense trees
Terrain: Mostly flat (no slopes)
Mission type: Waypoint-based autonomous flight (for spraying)
At this altitude and density, a 1-meter lateral deviation from intended path can cause collision.
Current Behavior
When RTK degrades (e.g., FIX to FLOAT or position quality deteriorates):
The drone begins to drift off intended path
After a short delay, it sometimes enters BRAKE mode
However, in many cases, collision occurs before EKF failsafe reacts since it is reacting too late relative to my operating envelope.
What I Want
I want the drone to:
Immediately reduce XY velocity to zero and hold altitude
At the first reliable sign of position degradation
BEFORE drift exceeds 0.5–1 meter, just freeze in air (like BRAKE/LOITER hold) may be with an Optical Flow sensor.
**
What I Consider “Position Degradation”**
I am open to guidance here. Some candidate triggers:
EKF variance spike
Innovation test ratio increase
GPS glitch detection
Horizontal or vertical position accuracy (hAcc / vAcc)
Heading inaccuracy
Any EKF3 internal metric that precedes lateral drift
I want to trigger on the earliest meaningful indicator, not the late-stage failsafe.
Key Questions
What is the earliest reliable internal signal in EKF3 that indicates position estimate degradation?
Is there a parameter-based way to:
Trigger immediate BRAKE
Or zero XY velocity based on EKF variances or GPS quality?
Can EKF failsafe sensitivity be made significantly more aggressive?
Can a companion computer-based monitoring and triggering help?
Is optical flow a good choice to keep the drone from drifting?
Any guidance would be highly appreciated.
Thank you.
I think the best way (and may be wrong ofc) to go ahead with this would be to edit the firmware directly to add checks for GPS health (fix, hacc, vacc, sats) on each run of the auto mode update function and act accordingly. This would probably be the fastest in terms of response time and most customisable.
I generally agree that adding some stricter firmware level health checks may improve things significantly. You might consider adding some additional parameters in the same vein as GPS_HDOP_GOOD for control over each value.
However, I’m not really sure how you’re even getting an RTK fix with a Neo 3 GPS. AFAIK, it uses a Neo-M9N module, which is non-RTK capable.
Additionally, you may simply have too high an expectation here. Maintaining an RTK fix in dense tree cover is challenging, as is. And GNSS fix state takes time to degrade. I’ve seen up to about 1 minute of RTK Fixed indication after ceasing correction data. I’d have to do some additional research and testing to determine if you can discover drift rate/imprecision well enough during that period to preemptively trigger a failsafe of sorts. All that to say: I think you may need some degree of additional localization beyond GPS (like SLAM) to get the results you want.
Yes, that would be the final, production-grade approach. Right now, my challenge is to identify which parameters to tweak, which variables to read, and which mode to switch to, to prevent collisions due to RTK degradation.
Sorry for the confusion. Neo 3 is only the regular GPS. I’m using Ardusimple’s RTK modules as well, in addition.
Agree to your point on RTK Fix state (3D, Float, Fixed, etc.), that data can be stale with a high differential age going up to 10s of seconds. That drives me to the challenge of discovering the right set of parameters/variables that do not lag as much - perhaps some in EKF_STATUS_REPORT, GPW_RAW_INT? Would be great to get your thoughts.
You should focus more on messages available from the GNSS module itself, and less on what’s presently available within MavLink. Do some bench trials to see which diverge under various controlled but less than ideal circumstances. u-Center is your friend here, connected directly to modules subject to your test cases.
But again, I think you might be better off exploring some alternate localization methods than trying to coerce GPS to meet your needs.