A Dead Drone That Looked Alive
This is the most important safety bug I've fixed on this project, and the scariest kind: the drone lost its link, and the console kept showing it flying. Frozen position, frozen battery — a calm, healthy-looking asset that was no longer talking to anyone. Silence has to look like silence.
I found it by accident. The link dropped while I was watching, and nothing on the screen changed. Same position, same heading, battery still reading 61%. The card looked exactly as healthy as it had a second earlier, and it stayed that way.
Patay na, mukhang buhay pa (dead already, still looks alive). On a tactical display, that's the single most dangerous thing a screen can do.
Why a frozen display is worse than a blank one
If a screen goes blank, the operator knows something is wrong and acts on it. If a screen shows stale data as if it were live, the operator makes decisions on a fiction. They route around an asset that has actually drifted. They hold fire for a drone that isn't there any more. They trust a position that's minutes old.
The lie is a confident one, and the confidence is what makes it deadly.
The fix: a watchdog on every asset
Every connected vehicle is expected to check in continuously — a steady heartbeat and telemetry stream. The console now watches the gap since the last message for each asset independently. Miss the expected check-ins for too long, and the asset is marked stale: its card visibly changes, its telemetry is flagged as no-longer-current, and the map marker stops pretending it's live.
The operator sees, immediately and unambiguously: this asset is not talking. What you're looking at is its last-known state, not its current one.
Grades of not-talking
It isn't just on/off. A brief gap might be a hiccup; a long one is a real loss. So there are stages: healthy, a caution state when check-ins start slipping, and a full stale/link-lost state when they've clearly stopped. The operator gets early warning as a link degrades, not just a binary at the end.
This is the honesty principle, made literal
Every honest-display decision on this project has been the same idea: the screen must never claim to know something it doesn't. The ghost markers for unconnected assets. The mode display that shouldn't flip before confirmation. The arming refusal that must not look like success. This is that same rule applied to the most consequential case — an asset going silent mid-mission.
Where this leaves the project
The console speaks the protocol real autopilots use, shows the whole fleet at a glance, records everything to a tamper-evident black box, and — as of this fix — tells the truth the moment an asset stops answering. The dangerous gap between "connected" and "trusted" is closed. Matagal, pero matibay (slow, but solid).
Worth saying plainly, since it's easy to imply otherwise: all of this has been exercised against simulators I wrote. No PX4 software-in-the-loop yet, and no physical aircraft. The watchdog is built and tested; what it hasn't done is watch a real radio go quiet.
Thoughts?
Comments are threads on GitHub, so a GitHub account is needed to post. No account? Email me instead — I read everything.