feat(failsafe): v1.103 — promote single-rotor-out reconfiguration into production FlightCore#242
Merged
Merged
Conversation
…o production FlightCore
The rotor-loss recovery (FAULT-P02) was verified end-to-end only in the
falcon-sitl-gz example; the production FlightCore — the controller the real WASM
component runs — always used the full-attitude mix(). This wires the detect→
reconfigure→land chain into FlightCore, REUSING the existing verified pieces (no
new detector — verify-first caught that a planned one would have duplicated the
relay-iekf RotorFaultDetector).
- FlightBackend::read_motor_rpm() -> Option<[i32;4]> (default None): the
achieved-per-rotor source (ESC telemetry, e.g. DroneCAN esc.Status). A backend
without ESC feedback runs unchanged (no detection).
- FlightCore::step: forms the per-rotor effectiveness residual |commanded −
achieved| from the RPM, feeds the relay-iekf RotorFaultDetector (CUSUM, the same
thresholds the SITL chain proved), and on isolation latches failed_motor and
switches the control law to relay-geo moment_reduced (reduced-attitude S²,
yaw relinquished) + relay-mix-quad mix_rotor_out (failed rotor → 0, MIX-P08) —
the exact composition FV-FALCON-FAULT-002 verifies.
- FlightSupervisor: on isolation, commands LAND (Failsafe with have_position=false)
— a 3-rotor quad has no yaw authority to navigate home, so RTL is unsafe.
Tests (deterministic — RPM is a direct backend input, not estimator-derived, so
none of the wind/runaway estimator-corruption fragility):
- fdi_isolates_dead_rotor_and_reconfigures: healthy never isolated; a rotor at
0 RPM under command is isolated in a few cycles → commanded 0, healthy in
[floor,1].
- motor_failure_commands_land: an airborne vehicle that loses a rotor → Land.
41 falcon-core tests; the SITL fault_tolerance chain still passes; falcon-mavlink/
hitl unaffected. rivet FV-FALCON-FAULT-002 extended with the production-wiring
evidence. validate PASS, 0 error-gaps.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Rotor-loss recovery (FAULT-P02) was verified end-to-end only in the falcon-sitl-gz example; the production
FlightCore— the controller the real WASM component runs — always used the full-attitudemix(). This wires the detect→reconfigure→land chain intoFlightCore, reusing the existing verified pieces (no new detector — verify-first caught that a planned one would have duplicatedrelay-iekf::RotorFaultDetector).FlightBackend::read_motor_rpm() -> Option<[i32;4]>(defaultNone): the achieved-per-rotor source (ESC telemetry). A backend without ESC feedback runs unchanged.FlightCore::step: forms the residual|commanded − achieved|from RPM → feedsRotorFaultDetector(CUSUM, the SITL-proven thresholds) → on isolation switches torelay-geo::moment_reduced(yaw relinquished) +mix_rotor_out(failed rotor → 0, MIX-P08) — the exact compositionFV-FALCON-FAULT-002verifies.FlightSupervisor: on isolation, commands Land (have_position=false) — a 3-rotor quad can't navigate home, so RTL is unsafe.Verification (deterministic — RPM is a direct backend input)
fdi_isolates_dead_rotor_and_reconfigures: healthy never isolated; a rotor at 0 RPM under command isolated in a few cycles → commanded 0, healthy in [floor,1].motor_failure_commands_land: an airborne vehicle that loses a rotor → Land.41 falcon-core tests; the SITL
fault_tolerancechain still passes; falcon-mavlink/hitl unaffected. No new Kani (RotorFaultDetector + mix_rotor_out already proven; this is integration).rivet validatePASS, 0 error-gaps; FV-FALCON-FAULT-002 extended.Arc
This completes the motor-failure thread: v1.102 enforced the orphaned mixer proofs, v1.103 promotes the SITL-demonstrated reconfiguration into the production controller. The remaining
FlightBackendESC plumbing on real hardware (DroneCAN esc.Status →read_motor_rpm) is a jess/bring-up binding.🤖 Generated with Claude Code