AP_GPS: downgrade fix status when reported location is uninitialised#33142
AP_GPS: downgrade fix status when reported location is uninitialised#33142dakejahl wants to merge 1 commit into
Conversation
A backend publishing status>=FIX_2D with lat==lng==0 is reporting a lock it does not have. Squash to NONE in update_instance() before any downstream consumer reads state[], so AHRS, the EKF, terrain, arming, set_home, Lua bindings and the DroneCAN re-broadcast cannot latch (0,0). See the inline comment for the observed conditions and the other backends reachable with the same shape.
| // the AP_DroneCAN GPS re-broadcast safe with one check. We use | ||
| // a direct lat==0 && lng==0 predicate rather than | ||
| // Location::initialised() because the latter also treats | ||
| // (0, 0, alt!=0) as initialised, which a spoofer can produce. |
There was a problem hiding this comment.
with a really big comment explaining what you've seen!
Claude really took the suggestion seriously 😂
|
You say this is easy to replicate, can you get a bus data trace to confirm this is what's happening? There is this funny waf It's easy to believe the GPS may also fib its last known location in RAM or other similar things. This might be something that just can't be defended against. |
Yeah I'll test again during normal hours when the production line is running.
Right, but we could try to minimize the fallout, terrain tile cache seeding and dead reckoning reference location. There's probably more, that's just what Claude flagged. Anyway this all fell out of some QGC warning spam I saw while working on something tangential, figured I'd try to patch the issue at the source rather than just fixing QGC |
2 participants
Summary
A GPS backend publishing
status >= FIX_2Dwithlat == lng == 0is a contract violation. Observed from a ublox M9N behind a DroneCAN node during cold start under jamming/spoofing. Catch it once inAP_GPS::update_instance()so no downstream consumer latches(0,0).Supersedes #33141 and #33135.
Problem
AP_GPS::update_instance()publishes whatever each backend writes intostate[i]. When the (status, location) pair is inconsistent, the bad coordinates flow straight through toAP_AHRS_DCM(latches(0,0)as the dead-reckoning origin), the DroneCAN re-broadcast, Lua scripts viagps:location(), and anything else that gates only onstatus >= FIX_2D.Solution
In
update_instance(), immediately after a successfulread()and before fix-timing accounting, downgradestate[i].statustoNONEwhenstatus >= FIX_2D && lat == 0 && lng == 0. One chokepoint, no per-consumer churn. Inline comment explains the observed conditions.