Failsafe nie jest pojedynczym warunkiem „jeżeli utracono radio, ląduj”. Jest systemem zarządzania wieloma jednoczesnymi awariami, stanem pojazdu i dostępnymi zdolnościami. Ta sama utrata GNSS wymaga innej reakcji podczas ręcznego lotu stabilizowanego, misji pozycyjnej i końcowego podejścia. Poprawna implementacja rozdziela detekcję faultu od decyzji, stosuje persistence i histerezę, arbitruje konflikty oraz rejestruje pełne uzasadnienie przejścia.

Spis treści#

Hazard, fault, failure i action#

Pojęcia powinny być rozdzielone:

  • fault — wykryta anomalia elementu lub danych, np. brak nowych ramek RC;
  • failure — utrata wymaganej funkcji, np. brak sterowania przez operatora;
  • hazard — stan mogący prowadzić do szkody, np. niekontrolowane oddalanie;
  • action — kontrolowana reakcja systemu, np. przejście do lotu bez pozycji albo lądowanie.

Jeden fault nie zawsze powoduje failure: utrata primary IMU przy działającym redundantnym lane nie odbiera estymacji. Z kolei kilka pozornie drobnych faultów może wspólnie usunąć funkcję.

Failsafe action dobiera się do pozostałych zdolności, nie do nazwy sensora. „GPS failsafe” jest skrótem; rzeczywisty problem to brak wiarygodnej pozycji/global navigation.

Dlaczego potrzebna jest maszyna stanów#

Zbiór niezależnych if prowadzi do wyścigu:

if radio_lost -> RTL
if gps_bad -> ALT_HOLD
if battery_critical -> LAND
if radio_restored -> previous_mode

Kolejność wykonania decyduje, czy wygrywa LAND, ALT_HOLD czy powrót do poprzedniego trybu. Przy każdym cyklu wynik może się zmieniać.

Maszyna stanów ma jedno miejsce, które:

  1. przyjmuje snapshot faultów i zdolności;
  2. ocenia severity oraz kontekst;
  3. wybiera docelową action według jawnej tabeli;
  4. wykonuje kontrolowane przejście;
  5. utrzymuje latch/recovery policy;
  6. publikuje powód i stan.

Detektory nie zmieniają bezpośrednio flight mode. Publikują fakty z timestampem, confidence i trwałością.

Warstwa detekcji#

Każdy monitor ma kontrakt:

Pole Znaczenie
active fault spełnia warunki potwierdzenia
first_seen początek podejrzenia
confirmed_at początek aktywnego faultu
last_good ostatnia poprawna obserwacja
severity advisory/degraded/critical
latched czy wymaga jawnego resetu
evidence liczniki, wiek, próg, wartość

Detektor powinien odróżniać not-present, stale, invalid i inconsistent. Brak urządzenia przed startem nie jest tym samym co utrata podczas lotu.

Walidacja wejścia obejmuje zakres, CRC, sequence, timestamp i status. Heartbeat GCS odebrany przez UART nie dowodzi, że operator ma sterowanie; zależy to od roli linku.

Świeżość zamiast samej obecności#

Wiele awarii polega na zamrożeniu ostatniej wartości. Flaga has_gps = true pozostaje, choć wiadomość ma pięć sekund. Każda zdolność ma limit wieku.

fresh = valid && generation_changed && now - measurement_time < max_age

Wiek jest mierzony względem właściwego czasu. GNSS może wysłać starą obserwację po buforowaniu; arrival time i measurement time są oddzielne.

RC failsafe powinien uwzględniać brak ramek, flagę failsafe odbiornika, utratę ramek oraz zakres kanałów. Jedna stała pozycja drążka nie jest sama w sobie stale fault.

Link GCS może nigdy nie być używany. ArduPilot dokumentuje, że GCS failsafe nie aktywuje się, jeśli GCS nigdy się nie połączyło. To przykład kontekstowej aktywacji monitora.

Persistence, hysteresis i debounce#

Pojedyncza zła próbka nie powinna zmieniać trybu lotu, ale zbyt długi delay zwiększa hazard. Dla każdego faultu definiuje się:

  • T_confirm — czas ciągłego/powtarzalnego błędu do aktywacji;
  • T_clear — czas stabilnej poprawy do clear;
  • progi enter/exit;
  • limit liczby zdarzeń w oknie;
  • natychmiastowe wyjątki, np. brownout/utrata całego toru aktuatorów.

Histereza wartości:

enter low_battery, gdy V < V_enter przez T_confirm
clear tylko gdy V > V_exit, gdzie V_exit > V_enter

Persistence nie zawsze oznacza ciągłość. Dla sporadycznych błędów liczy się N zdarzeń w oknie T. Filtr ma jawny reset przy zmianie źródła.

Model zdolności#

Decision layer korzysta z capabilities:

  • attitude_valid;
  • height_valid;
  • local_position_valid;
  • global_position_valid;
  • heading_valid;
  • manual_control_valid;
  • mission_link_required/valid;
  • propulsion_authority;
  • energy_to_land/return;
  • home_valid i route_valid;
  • terrain data valid;
  • actuator_output_valid.

Capabilities są wyprowadzone z wielu monitorów. Na przykład local position może pozostać dzięki VIO mimo utraty GNSS. RTL wymaga global/local navigation, home/route i wystarczającej energii.

Model powinien odpowiadać „co system potrafi teraz”, nie „który sensor działa”. Ułatwia współpracę nowych sensorów bez przepisywania całej tabeli failsafe.

Stany nadrzędne#

Przykładowe stany, niezależne od konkretnych nazw PX4/ArduPilot:

DISARMED
PREFLIGHT_BLOCKED
ARMED_NORMAL
ARMED_DEGRADED
FAILSAFE_HOLD
FAILSAFE_RETURN
FAILSAFE_LAND
FAILSAFE_TERMINATE
POST_FAULT_LATCHED

DEGRADED oznacza utratę redundancji lub funkcji niekrytycznej przy zachowaniu bieżącego trybu. HOLD kupuje czas tylko wtedy, gdy stabilizacja/pozycja są dostępne. RETURN jest planowaną trajektorią do bezpiecznego obszaru. LAND minimalizuje czas w powietrzu. TERMINATE jest ostateczną reakcją określoną wymaganiami i prawem; w zwykłych nieuzbrojonych UAV może oznaczać natychmiastowe wyłączenie napędu tylko w ściśle zdefiniowanych warunkach.

Każdy stan ma entry action, continuous action, exit guard i timeout eskalacji.

Priorytety reakcji#

Akcje tworzą częściowy porządek, nie jedną uniwersalną listę. Krytyczna bateria może preferować natychmiastowe lądowanie nad odległym RTL. Utrata estymacji pozycji wyklucza RTL, choć radio również znikło.

Decision function ocenia feasible actions:

candidates = actions_per_active_fault
candidates = filter(capabilities_satisfy_preconditions)
selected = most_conservative_according_to_context(candidates)

„Most conservative” nie zawsze znaczy land. Fixed-wing bez wystarczającej prędkości/terenu może potrzebować innej trajektorii niż multicopter.

Priorytety są zapisane w tabeli i testowane parami faultów. Nie zależą od kolejności bitów lub wywołań callbacków.

Wiele równoczesnych faultów#

Macierz kombinacji obejmuje co najmniej pary:

  • RC lost + GNSS lost;
  • GCS lost + mission active;
  • low battery + route home blocked/invalid;
  • primary IMU failed + secondary degraded;
  • geofence breach + position uncertainty;
  • motor failure + battery critical;
  • power source lost + telemetry lost;
  • estimator reset + manual input restored.

Stan wynikowy musi być idempotentny: ten sam snapshot prowadzi do tej samej decyzji niezależnie od kolejności zdarzeń.

Jeżeli nowy fault odbiera precondition bieżącej akcji, maszyna eskaluje. Przykład: FAILSAFE_RETURN traci global_position, więc przechodzi do action możliwej bez niej.

Clear jednego faultu nie przywraca automatycznie normal, jeśli drugi pozostaje.

Utrata RC i GCS#

RC i GCS mają inne role. RC jest manual control; GCS może nadzorować misję, wysyłać offboard setpoints albo tylko obserwować.

Monitor RC uwzględnia:

  • timeout poprawnej ramki;
  • receiver failsafe/frame lost flags;
  • mapowanie kanałów i valid ranges;
  • czy manual control jest wymagany w bieżącym mode;
  • odzyskanie linku z persistence.

Monitor GCS uwzględnia heartbeat właściwego system/component, nie dowolny MAVLink ruch. Jeśli offboard setpoints są wymagane częściej niż heartbeat, osobny timeout setpointu jest ważniejszy.

Po utracie linku action może kontynuować autonomiczną misję, hold, return lub land — zależnie od wcześniejszej konfiguracji i zdolności. Dokumentacja ArduPilot pokazuje, że opcje mogą modyfikować standardowe zachowanie; konfiguracja musi być częścią wersjonowanego profilu pojazdu.

Bateria i zasilanie#

Rozróżnia się:

  • low energy — czas na planową reakcję;
  • critical energy — minimalny zapas do lądowania;
  • emergency — natychmiastowa utrata możliwości;
  • power-path fault — utrata jednego źródła przy działającym drugim;
  • brownout/reset — przerwa w pracy FC.

Próg zależy od obciążenia, temperatury, modelu baterii i odległości. Samo napięcie pod impulsem może powodować false trigger; energia/coulomb count i persistence poprawiają decyzję, ale nie zastępują progu ochronnego.

Utrata redundancji źródeł wywołuje DEGRADED i może odłączyć payload, zanim pojawi się low battery. Power MUX status i pomiar obu wejść powinny być dostępne.

Action po critical battery nie może zostać anulowana tylko przez chwilowy rebound napięcia po zmniejszeniu throttle. Taki stan jest zwykle latched do lądowania/disarm.

GNSS, EKF i sensory#

GNSS fault nie jest równy EKF failure. Odbiornik może mieć fix, ale innowacje wskazują niespójność. EKF może utrzymać local position z VIO/flow bez GNSS.

Monitor estymacji publikuje ważność attitude, velocity, position i heading osobno. Covariance, innovations, resets i timeout obserwacji tworzą evidence.

Po przełączeniu lane możliwy jest skok. Failsafe może chwilowo ograniczyć tryb, dopóki nowy stan nie jest stable. Nie należy natychmiast przywracać misji po jednej poprawnej próbce.

Utrata magnetometru nie zawsze odbiera heading — zależy od alternatyw. Utrata barometru może być zastąpiona GNSS/range, lecz zmienia dokładność wysokości.

Geofence i pozycja#

Geofence wymaga wiarygodnej pozycji. Brak pozycji nie oznacza automatycznie „wewnątrz”. Maszyna rozróżnia:

  • confirmed breach;
  • predicted breach;
  • fence state unknown wskutek invalid position;
  • powrót do fence z potwierdzeniem.

Action breach może użyć return point, brake/hold lub land. Jeśli navigation invalid, wybiera reakcję niewymagającą tej samej utraconej funkcji.

Fence geometry i home muszą być zweryfikowane przed arm. Dynamiczna aktualizacja fence w locie jest atomowa i logowana.

Awaria aktuatora#

Awaria silnika/serwa wpływa na control authority. Detektor korzysta z telemetry RPM/current, modelu odpowiedzi i residuals, ale brak telemetrii nie zawsze oznacza failure.

Allocator publikuje achieved/unallocated torque/thrust, saturation i failed bitmask. Capability layer określa, które osie nadal są kontrolowalne.

Multirotor quad zwykle nie ma pełnej tolerancji pojedynczego silnika w standardowej konfiguracji. Hexa/octo może zachować część authority, ale wymaga przetestowanej rekonfiguracji. Fixed-wing może utracić jeden control surface i mieć alternatywne powierzchnie.

Failsafe nie zakłada, że „więcej silników” automatycznie zapewnia lądowanie. Używa konkretnego modelu geometry i testów.

RTL nie zawsze jest dostępne#

Return-to-launch wymaga więcej niż GNSS:

  • poprawny home/launch reference;
  • pozycja i heading;
  • wysokość/terrain clearance;
  • wykonalna trajektoria i geofence;
  • control authority;
  • wystarczająca energia;
  • znajomość typu pojazdu i fazy VTOL.

Jeśli brakuje któregoś warunku, action jest odrzucana lub modyfikowana. Critical battery blisko ziemi może preferować land in place, a fixed-wing potrzebować nearest safe loiter/landing plan.

Home może być stary lub błędny po przeniesieniu pojazdu bez reboot. Preflight waliduje jego świeżość i źródło.

Latch i recovery#

Każdy fault ma recovery class:

  • auto-clear po stabilnym czasie;
  • clear po operator acknowledgement;
  • clear dopiero po disarm;
  • latched do reboot/serwisu.

Critical battery i actuator failure zwykle nie powinny automatycznie przywracać poprzedniej misji. Krótka utrata RC może zezwalać na przejęcie po określonym, świadomym poleceniu operatora.

ArduPilot dokumentuje, że po failsafe powodującym zmianę mode pojazd pozostaje w tym mode, dopóki pilot nie zmieni go bezpośrednio. To ogranicza nieoczekiwany powrót.

Recovery guard sprawdza capabilities, stabilność i zgodę. Poprzedni mode jest tylko kandydatem, nie automatycznym celem.

Arming i preflight#

Preflight checks zapobiegają startowi z faultem, który w locie wymagałby failsafe. Lista zależy od planowanego mode: lot manual attitude może nie wymagać global position, mission tak.

Checks obejmują:

  • sensor health/calibration/orientation;
  • estimator validity;
  • power source i battery;
  • actuator mapping i test bez śmigieł;
  • RC/offboard/GCS wymagane role;
  • home/fence/mission;
  • storage i parametry critical;
  • pozostałą redundancję.

Override check jest jawny, ograniczony do uprawnionych warunków i logowany. Nie można override warunku, którego brak oznacza niekontrolowalny pojazd.

Arming transition zamraża część konfiguracji. Zmiana geometry/mixer/failsafe table w locie jest zabroniona albo atomowo kwalifikowana.

Interakcja z watchdogiem#

Failsafe działa, gdy software nadal kontroluje system. Watchdog resetuje po utracie postępu. Nie powinny ze sobą walczyć.

Jeśli failsafe LAND trwa poprawnie, supervisor nadal odświeża watchdog. Jeśli control pipeline nie publikuje nowych wyjść, watchdog zadziała niezależnie od state machine.

Po watchdog reboot system odczytuje armed state/reset reason, ale nie zakłada bezpiecznej kontynuacji. Wyjścia aktuatorów mają hardware/default timeout.

Failsafe state i active faults trafiają do crash record, aby po restarcie wiedzieć, co działo się przed utratą postępu.

Log i komunikat operatora#

Każde przejście zapisuje:

  • state from/to;
  • trigger fault i wszystkie aktywne fault IDs;
  • capabilities snapshot;
  • wybraną action i odrzucone actions/preconditions;
  • wartości/progi/persistence;
  • pozycję, energię, mode i armed;
  • config version;
  • czas od detekcji do action.

Komunikat dla operatora powinien mówić „Critical battery: LAND latched”, nie tylko „failsafe”. Severity, action i możliwość recovery muszą być jasne.

Spam jest kontrolowany: event emituje się na enter/exit/eskalację i okresowo z niskim rate. Log wewnętrzny zachowuje pełną rozdzielczość detektorów.

Projekt tabelaryczny#

Zamiast rozproszonych if używa się danych:

Fault Kontekst Wymagane capabilities Action Latch Eskalacja
RC lost manual global+home RETURN ack LAND timeout
RC lost manual attitude+height LAND/HOLD ack LAND
GCS lost autonomous mission independent continue auto/ack wg energii
battery critical dowolny height/control LAND disarm emergency
local position lost position mode attitude+height degraded mode ack LAND
actuator authority lost dowolny zależne controlled landing/terminate disarm immediate

Tabela jest wersjonowana i generuje dokumentację/test cases. Parametry mogą wybierać dozwolone warianty, ale nie tworzą nieprzetestowanych kombinacji.

Testy scenariuszy#

Failsafe State Machine Simulation PX4 pozwala testować zachowanie konfiguracji; fault injection umożliwia wprowadzanie części awarii. Dodatkowo tworzy się model-based tests.

Minimalna macierz:

  1. każdy fault w każdym flight mode;
  2. fault przed arm, podczas arm, po arm i po disarm;
  3. wszystkie pary critical faultów w obu kolejnościach;
  4. fault w trakcie innej action;
  5. krótszy/dłuższy od persistence;
  6. oscylacja przy progu;
  7. recovery przed i po latch;
  8. utrata capability wymaganej przez RTL/HOLD;
  9. timeout action i eskalacja;
  10. reboot/watchdog podczas failsafe;
  11. wrap zegara i opóźnione wiadomości;
  12. różne profile parametrów i migracja wersji.

Inwarianty:

  • nigdy nie wybieraj action bez preconditions;
  • critical severity nie prowadzi do mniej bezpiecznego stanu przez auto-clear;
  • identyczny snapshot daje identyczny wynik;
  • pojedynczy fault event generuje co najwyżej jedno wejście bez ping-pong;
  • po disarm wszystkie wyjścia są bezpieczne;
  • log zawiera przyczynę każdej zmiany.

SITL sprawdza logikę i trajektorię, HIL timing oraz wyjścia, a test lotny tylko scenariusze z uprzednio ograniczonym ryzykiem.

Lista projektowa#

  • Fault detection jest oddzielone od action selection.
  • Każdy fault ma timestamp, evidence, persistence, hysteresis i severity.
  • Capabilities opisują dostępne funkcje, nie tylko obecność sensorów.
  • Priorytet wielu faultów jest tabelaryczny i niezależny od kolejności callbacków.
  • Każda action ma jawne preconditions i timeout eskalacji.
  • RTL sprawdza home, navigation, energy i control authority.
  • Recovery ma politykę auto/ack/disarm/service.
  • Critical actions nie są anulowane przez chwilowe odbicie sygnału.
  • Failsafe i watchdog mają rozdzielone role.
  • Preflight blokuje konfiguracje bez wymaganych zdolności.
  • Log zapisuje aktywne faults, capabilities i odrzucone actions.
  • Testy obejmują pary faultów, progi, recovery i reboot.

Powiązane tematy#

Przypisy#

  1. PX4, Safety (Failsafe) Configuration — aktualne źródła failsafe, działania oraz zależności konfiguracji.
  2. PX4, Failsafe State Machine Simulation — narzędzie do sprawdzania kombinacji i wyników maszyny stanów.
  3. ArduPilot, Copter Failsafe — klasy failsafe i zachowanie trybu po aktywacji.
  4. PX4, System Failure Injection — wstrzykiwanie faultów sensorów/systemu w symulacji i na sprzęcie.

Utworzono: 15 sierpnia 2026. Ostatnia aktualizacja: 15 sierpnia 2026. Źródła zweryfikowano: 15 sierpnia 2026.

Powiązane tematy

Watchdog i recovery flight controlleraWatchdog jako ostatnia warstwa ochrony: niezależny zegar, okno odświeżenia, monitor postępu zadań, reset reason, crash record, boot loop i testowanie recovery.Harmonogram czasu rzeczywistego flight controlleraProjekt harmonogramu od data-ready IMU do wyjścia aktuatorów: okresy, deadline, worst-case execution time, priorytety, blokowanie, DMA i pomiary schedulability.Redundancja sensorów w flight controllerzeRedundancja bez liczenia samych układów: niezależność zasilania i magistral, wykrywanie stuck/noise/bias, voting, równoległe estymatory i kontrolowane failover.MAVLink — architektura protokołuDokumentacyjny opis MAVLink 2: format on-wire, system/component ID, CRC_EXTRA, podpisywanie oraz semantyka usług parametrów i misji.Testy firmware UAV: unit, integration, SITL i HILPraktyczna strategia testowania embedded flight stack: separacja HAL, fake clock, testy liczbowe i parserów, sanitizers, scenariusze SITL, HIL, fault injection oraz kwalifikacja sprzętu.

Źródła z centralnego rejestru

  1. PX4 User Guide: Safety Configuration and Failsafes [dokumentacja projektu]
  2. PX4: Failsafe State Machine Simulation [dokumentacja projektu]
  3. ArduPilot Copter: Failsafe [dokumentacja projektu]
  4. PX4: System Failure Injection [dokumentacja projektu]