Redundancja sensorów nie polega na policzeniu dwóch żyroskopów na PCB. Dwa układy zasilane z tej samej szyny, podłączone do tej samej magistrali i umieszczone w tej samej strefie termicznej mogą utracić wiarygodność jednocześnie. Poprawny projekt identyfikuje domeny wspólnej awarii, mierzy świeżość i jakość danych, izoluje wadliwe źródło oraz przełącza estymację bez niekontrolowanego skoku stanu.

Spis treści#

Redundancja funkcjonalna i fizyczna#

Redundancja funkcjonalna oznacza dostępność alternatywnego sposobu uzyskania wymaganej wielkości. Redundancja fizyczna oznacza dodatkowy element. Dwa barometry są fizycznie redundantne; wysokość z GNSS i barometru daje również różnorodność funkcjonalną, choć sensory mają inne pasmo, błędy i odniesienie.

Wymaganie powinno brzmieć „po pojedynczej awarii X system utrzymuje Y przez Z sekund z dokładnością Q”, a nie „płytka ma trzy IMU”. Pozwala to sprawdzić, czy alternatywa naprawdę podtrzymuje funkcję.

Redundancja obejmuje detekcję i rekonfigurację. Rezerwowy sensor, którego awarii nie można rozpoznać, może dostarczyć fałszywe dane i pogorszyć wynik.

Domeny wspólnej awarii#

Macierz domen dla każdej instancji obejmuje:

Domena Pytanie
zasilanie ten sam regulator, load switch, masa i kondensator?
komunikacja ta sama magistrala, DMA, złącze i driver?
obliczenia ten sam MCU, task, biblioteka i pamięć?
zegar wspólne źródło i synchronizacja?
środowisko ta sama temperatura, wibracja, ciśnienie i pole magnetyczne?
konfiguracja ten sam błąd parametrów lub orientacji?
produkcja ta sama partia i mechanizm uszkodzenia?

Dwa IMU na jednym SPI z osobnymi CS nadal współdzielą SCK/MISO, kontroler DMA i driver. Zwarcie MISO jednego może zablokować oba. Dwa sensory na osobnych SPI, ale jednym regulatorze, nie chronią przed zapadem szyny.

Pełna niezależność ma koszt masy i energii. Celem jest rozdzielenie domen odpowiednich do analizy ryzyka, nie absolutna izolacja każdego elementu.

FMEA toru pomiarowego#

FMEA rozpoczyna się od funkcji, np. „dostarczyć prędkość kątową osi body z wiekiem < 1 ms”. Następnie dla każdego elementu zapisuje tryby awarii, skutek, detekcję i reakcję.

Przykład:

Element/awaria Objaw Detekcja Reakcja
IMU brak danych rośnie wiek timeout/generation usuń instancję
IMU stuck stała wartość mimo ruchu korelacja i excitation obniż score
bias step rozjazd z innymi innovation/voter przełącz lane
SPI stuck timeout DMA driver watchdog reset bus/sensor
regulator 3,3 V wiele sensorów znika rail monitor failsafe/inna domena
błąd orientacji spójny zły znak test osi/konfiguracji blokada arm

Detekcja musi być niezależna od sygnału uszkodzonego tam, gdzie to możliwe. Sensor deklarujący sam „health OK” nie wystarcza.

Klasy uszkodzeń sensora#

W testach uwzględnia się więcej niż off:

  • brak publikacji;
  • stuck-at-last-value;
  • stała wartość skrajna;
  • bias step i wolny drift;
  • wzrost szumu;
  • sporadyczne outliery;
  • zły timestamp lub rosnące opóźnienie;
  • duplikacja/stara ramka;
  • zmiana skali lub orientacji;
  • saturacja przy dynamicznym manewrze;
  • reset sensora i powrót do default configuration;
  • wspólne zakłócenie wszystkich instancji.

Prosty timeout wykrywa tylko pierwszą klasę. Voter potrzebuje jakości czasowej, statystycznej oraz kontekstu dynamicznego.

Nie każda różnica jest awarią. IMU w różnych miejscach ramy mierzą dodatkowe przyspieszenie od rotacji i elastyczności konstrukcji; barometry mają różne opóźnienia termiczne, a GNSS mogą używać odmiennych konstelacji.

Świeżość i ciągłość#

Każda próbka ma timestamp pomiaru, timestamp odbioru, numer generacji i status drivera. Monitor oblicza wiek względem wspólnego zegara.

Warunki minimalne:

generation wzrósł
measurement_time jest monotoniczny w ramach generacji sensora
age < limit typu
dt mieści się w zakresie
brak FIFO overflow / bus error

Po resecie sensora generacja źródła się zmienia, nawet jeśli licznik wewnętrzny wrócił do zera. Chroni to przed uznaniem starej próbki za kontynuację.

Stuck detector nie może bazować na braku zmiany pojedynczej osi: nieruchomy dron rzeczywiście ma stałe wartości. Wykorzystuje pobudzenie z innych sensorów, wariancję w oknie i oczekiwany szum kwantyzacji.

Range i plausibility#

Pierwsza warstwa odrzuca NaN, infinity, błędne długości, CRC i wartości poza fizycznym zakresem skonfigurowanego sensora. Druga sprawdza rate-of-change oraz spójność z modelem pojazdu.

Akcelerometr o normie bliskiej g nie jest zawsze poprawny; w locie dynamicznym norma się zmienia. Magnetometr o rozsądnej normie może mieć zły kierunek. Barometr może być płynny, ale przesunięty przez strugę śmigła.

Plausibility thresholds zależą od trybu i envelope. Zbyt ciasne progi odrzucą poprawny agresywny manewr, zbyt szerokie nie wykryją bias. Progi mają histerezę i czas potwierdzenia.

Informacja statusowa producenta — self-test, saturation, data-ready — jest wejściem do score, nie jedynym arbitrem.

Porównanie dwóch sensorów#

Dwa sensory pozwalają wykryć rozbieżność, ale nie wskazują jednoznacznie winnego. Potrzebna jest trzecia informacja: model, inny typ sensora, historia jakości albo wcześniejszy stan.

Residual:

r = y_1 - transform(y_2)
z = r / sqrt(var_1 + var_2 + var_alignment)

Porównanie wymaga wspólnego czasu, układu współrzędnych, skali i pasma. Sensor opóźniony o 5 ms przy szybkim obrocie może wyglądać jak bias.

Decyzja nie powinna przełączać po jednym przekroczeniu. Score rośnie przy serii błędów i maleje powoli po poprawie. Histereza zapobiega ping-pong.

Jeśli oba są równie wiarygodne, system sygnalizuje degraded ambiguity zamiast arbitralnie ogłaszać jeden „dobrym”.

Voting trzech sensorów#

Trzy niezależne pomiary umożliwiają majority/median voting przy pojedynczym odstającym źródle. Mediana skalarna jest odporna na jedną wartość skrajną, ale dla wektorów oddzielna mediana osi może stworzyć wektor, którego nie zmierzył żaden sensor.

Voter wektorowy może używać par odległości, covariance-aware residuals i wyboru sensora najbardziej zgodnego z pozostałymi. Przy dwóch zgodnych uszkodzeniach wspólnej przyczyny majority wybierze błędny wynik.

Nie uśrednia się ślepo trzech IMU. Uśrednienie redukuje nieskorelowany szum, lecz bias uszkodzonego źródła wpływa na wynik zanim voter je odrzuci. Często wybiera się primary, monitoruje pozostałe i prowadzi osobne estymatory.

Voter ma jawny stan: healthy, suspect, failed, recovering. Powrót failed sensora wymaga pełnej inicjalizacji, okresu obserwacji i ponownego wyrównania.

Różnorodność sensorów#

Różne modele układów zmniejszają ryzyko wspólnego błędu krzemu/drivera, ale zwiększają różnice pasma, skali i temperatury. Dwa identyczne sensory ułatwiają porównanie i logistykę.

Różnorodność może obejmować:

  • producenta i architekturę MEMS;
  • SPI kontra CAN z lokalnym MCU;
  • osobny clock/oscylator;
  • odmienny zakres pomiarowy;
  • inny typ obserwacji, np. baro + GNSS + lidar;
  • osobną implementację estymatora na drugim procesorze.

Wybór wynika z dominant common-cause. Jeśli największym ryzykiem jest wibracja całej ramy, zmiana producenta IMU nie rozwiązuje problemu; potrzebny jest montaż, filtracja i zakres odporny na saturację.

Kalibracja względna#

Przełączenie ujawnia różnice offsetu. Barometry mogą różnić się o równowartość wielu metrów, magnetometry — przez lokalne pole, a IMU — bias i misalignment.

Kalibracja fabryczna opisuje sensor osobno. Kalibracja względna w pojeździe estymuje transformację między instancjami przy warunkach uznanych za wiarygodne. PX4 opisuje względną kalibrację barometrów, której celem jest ograniczenie skoku wysokości przy failover.

Nie „kalibruje się” uszkodzenia: jeśli offset szybko rośnie, algorytm adaptacyjny może podążyć za błędnym sensorem i ukryć fault. Aktualizacja korekcji jest ograniczona, gated stanem i zapisywana w diagnostyce.

Temperatura jest osobnym wymiarem. Offsety porównuje się po kompensacji i przy zbliżonym czasie termicznym. Sensor blisko regulatora może nagrzewać się szybciej.

Redundantne estymatory#

Jeden EKF z przełączanymi wejściami ma wspólny stan i mniejszy koszt CPU, ale wadliwy sensor może skazić stan przed wykryciem. Równoległe lanes wiążą osobne instancje filtra z różnymi IMU i preferencjami sensorów pomocniczych.

Każdy lane prowadzi innowacje, kowariancję i status. Voter estymatorów ocenia nie tylko surowe sensory, ale zdolność filtra do wyjaśniania obserwacji.

Koszt rośnie niemal z liczbą lanes, a wszystkie mogą współdzielić ten sam kod i MCU. To redundancja danych/stanu, nie ochrona przed bugiem algorytmu lub awarią procesora.

Wymagana pamięć historii opóźnionych obserwacji też się mnoży. Harmonogram musi wykazać deadline przy wszystkich lanes aktywnych, nie tylko po wyłączeniu rezerwowych.

Lane switching#

ArduPilot EKF3 utrzymuje wiele lanes związanych 1:1 z wybranymi IMU; affinity pozwala preferować różne instancje pozostałych sensorów. Primary lane dostarcza rozwiązanie, a inne są aktualizowane w tle i mogą przejąć rolę.

Decyzja uwzględnia błędy EKF i zdrowie sensorów. Sam fakt, że secondary ma mniejszą pojedynczą innowację, nie powinien powodować częstych przełączeń. Potrzebna jest trwała przewaga i histereza.

Po switch loguje się stary/nowy lane, powód, różnicę attitude/position/velocity, health sensorów i timestamp. Operator musi wiedzieć, że trajektoria po zdarzeniu pochodzi z innego stanu.

Lane, który długo nie otrzymywał kompletu obserwacji, nie jest gorącą rezerwą. Jego gotowość ma osobny status.

Przełączenie bez skoku#

Dwa poprawne estymatory mogą różnić się yaw, wysokością i pozycją. Natychmiastowa zmiana wejścia regulatora tworzy skok błędu oraz komendę aktuatora.

Możliwe strategie:

  • zastosować jawny reset/delta stanu i poinformować kontroler;
  • zachować ciągłość lokalnej pozycji przez offset output frame;
  • ograniczyć slew zmiany setpoint/state, jeśli fizycznie dopuszczalne;
  • zresetować integratory regulatora lub przeliczyć je bumpless;
  • przejść do mniej wymagającego trybu lotu.

Nie wolno po prostu blendować orientacji z uszkodzonego i dobrego lane bez analizy. W okresie przejścia zły sygnał nadal wpływa na sterowanie.

Przed lotem mierzy się maksymalną dopuszczalną różnicę hot spare. Jeśli przekroczona, rezerwa nie jest ready, nawet gdy jej status lokalny jest healthy.

IMU#

IMU ma najwyższe tempo i wpływa bezpośrednio na stabilizację. Redundancja obejmuje:

  • osobne CS/magistrale i najlepiej domeny zasilania;
  • niezależne data-ready/timestamp;
  • orientację zapisaną per instancja;
  • zakres zapobiegający wspólnej saturacji;
  • temperature calibration;
  • clipping/FIFO/error counters;
  • voting raw i innovation w estymatorze.

Układ BMI088 ma oddzielne części akcelerometru i żyroskopu oraz interfejsy, ale obecność dwóch funkcji w jednej obudowie nie daje dwóch redundantnych żyroskopów.

Wibracja jest często skorelowana. Dwa układy obok siebie mogą saturate jednocześnie. Trzeci o większym zakresie lub innym montażu bywa bardziej użyteczny niż kolejna identyczna kopia.

Magnetometry i barometry#

Magnetometry są podatne na wspólny problem instalacji: prąd napędu, magnesy i elementy stalowe. Zewnętrzny kompas oddala źródło zakłócenia, ale kabel/magistrala tworzy nową domenę awarii.

Voter ocenia normę pola względem modelu, kierunek, innowacje yaw i zależność od throttle/prądu. Dwa magnetometry zakłócane tym samym przewodem baterii mogą zgodnie się mylić.

Barometry wymagają equalizacji offsetu, ochrony przed światłem/strugą i oceny temperatury. Różnica dynamiczna może wynikać z różnych filtrów. Porównuje się sygnały po wyrównaniu pasma lub w modelu estymatora.

Wysokość może być podtrzymana przez GNSS/rangefinder, ale przejście zmienia szum i odniesienie. Mode manager musi wiedzieć, które źródło jest dostępne.

GNSS i źródła pozycji#

Dwa odbiorniki GNSS na tej samej antenie aktywnej współdzielą antenę, LNA, kabel i środowisko RF. Dwie anteny rozdzielają więcej awarii i umożliwiają heading, ale wymagają geometrii i osobnych torów.

GNSS quality obejmuje fix type, liczbę satelitów, accuracy estimates, age, integrity flags oraz innovation względem INS. Dwa odbiorniki mogą być jednocześnie dotknięte multipath lub zakłóceniem.

Różnorodne źródła: optical flow, VIO, lidar/radar odległości, airspeed i constraints ruchu. Nie są prostym zamiennikiem globalnej pozycji. Każde ma envelope: wysokość, oświetlenie, teksturę, prędkość i opóźnienie.

Przejście GNSS-denied powinno zostać przetestowane jako tryb systemu z rosnącą niepewnością, nie jako obietnica nieskończonego dead reckoning.

Magistrale i zasilanie#

Sensor redundancy diagram powinien pokazywać całą ścieżkę:

Power A -> regulator A -> IMU1 -> SPI1 -> MCU
Power B -> regulator B -> IMU2 -> SPI2 -> MCU
Power B -> CAN node GNSS -> CAN1 -> MCU

Jeśli oba regulatory mają wspólne wejście za jednym złączem, utrata złącza pozostaje common cause. Jeśli oba SPI używają jednego DMA request, konflikt software może uderzyć w oba.

Zasilanie redundantnego sensora może być monitorowane i przełączane load switchem, ale odcięcie nie może przez diody sygnałowe back-powerować urządzenia. Reset domeny jest testowany z pozostałymi sensorami pracującymi.

CAN zapewnia fault confinement węzłów, lecz zwarcie pary zatrzymuje cały segment. Dwie magistrale potrzebują osobnych transceiverów i przewodów.

Fault containment#

Po wykryciu awarii źródło jest izolowane logicznie: jego dane nie trafiają do nowych update, a driver przechodzi w failed/recovery. Nie wystarczy obniżyć priorytetu, jeśli stara subskrypcja nadal publikuje.

Recovery ma etapy: reset bus, reset sensor, ponowna identyfikacja, pełna konfiguracja, self-test, okres obserwacji, względna kalibracja, ready. Nie wraca bezpośrednio do primary.

Liczba prób jest ograniczona. Sensor generujący ciągłe błędy nie może zabierać budżetu rate loop. Po limicie pozostaje latched failed do bezpiecznego stanu serwisowego.

Fault containment region może obejmować cały segment I²C. Wtedy utrata jednego układu zmienia status wszystkich klientów, a system korzysta z alternatywnej domeny.

Testy fault injection#

PX4 udostępnia mechanizm wstrzykiwania awarii sensorów i systemu; wspierane typy zależą od środowiska i komponentu. Jest to punkt startowy, nie pełne pokrycie.

Macierz testowa dla każdej instancji:

  1. off przed arm i w locie;
  2. stuck przy spoczynku i dynamicznym manewrze;
  3. wrong/bias step o kilku amplitudach;
  4. slow/delayed/intermittent;
  5. rosnący noise i pojedyncze outliery;
  6. timestamp jump/wrap;
  7. saturacja zakresu;
  8. reset i utrata konfiguracji;
  9. zwarcie wspólnej magistrali;
  10. utrata szyny zasilania;
  11. dwie jednoczesne awarie common-cause;
  12. powrót sensora po długiej przerwie.

SITL sprawdza logikę, HIL timing i interfejs, a test sprzętowy ujawnia zasilanie, EMI i mechanikę. Przełączenie na prawdziwym pojeździe poprzedza tether/stanowisko i bezpieczna obwiednia.

Kryteria: czas detekcji, false positives, poprawny winny, skok stanu, maksymalna komenda aktuatora, tryb po failover i kompletność logu.

Logowanie decyzji votera#

Bez logu voter wygląda jak losowy przełącznik. Zapisuje się:

  • health i score każdej instancji;
  • wiek, rate, error counters i temperaturę;
  • residuals/innovations z progami;
  • primary i powód zmiany;
  • różnicę stanów przed przełączeniem;
  • konfigurację orientacji i kalibracji;
  • reset/recovery generation;
  • domenę zasilania i magistralę;
  • stan pojazdu oraz czas od arm.

Log zdarzeniowy ma pre-trigger buffer, aby zachować sekundy przed fault. Wolny logger nie może opóźnić decyzji; zapis jest asynchroniczny i może być skrócony do kompaktowego rekordu.

Telemetry health podaje operatorowi degraded redundancy przed utratą primary. „System nadal lata” nie znaczy, że ma dalszą tolerancję awarii.

Lista projektowa#

  • Wymaganie redundancji opisuje funkcję i dopuszczalną pojedynczą awarię.
  • Każdy sensor ma mapę zasilania, magistrali, zegara, kodu i środowiska.
  • FMEA obejmuje off, stuck, bias, noise, delay, saturation i reset.
  • Timestamp, generacja i age są monitorowane niezależnie od wartości.
  • Dwa sensory nie są używane do arbitralnego wskazania winnego bez trzeciej informacji.
  • Voting uwzględnia wariancję, pasmo, orientację i synchronizację.
  • Rezerwowy lane pracuje stale i ma status ready.
  • Failover ma histerezę i ochronę przed ping-pong.
  • Różnica stanów jest ograniczana lub powoduje degradację trybu.
  • Powrót sensora wymaga pełnej rekwalifikacji.
  • Recovery nie blokuje krytycznego scheduler-a.
  • Testy obejmują common-cause i jednoczesne awarie.
  • Log pokazuje dowód decyzji i pozostały poziom redundancji.

Powiązane tematy#

Przypisy#

  1. ArduPilot, EKF3 Affinity and Lane Switching — lanes związane z IMU, affinity innych sensorów i przełączanie primary.
  2. PX4, Barometers — priorytety, failover i względna kalibracja wielu barometrów.
  3. PX4, System Failure Injection — mechanizm i klasy wstrzykiwanych awarii w SITL oraz na sprzęcie.
  4. PX4, Using PX4 Navigation Filter EKF2 — innovation tests, źródła obserwacji i diagnostyka estymatora.
  5. Bosch Sensortec, BMI088 — przykład architektury IMU i interfejsów sensora.

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

Powiązane tematy

IMU w droniePrzekrojowa inżynieria toru inercyjnego UAV: znaczenie pomiarów gyro i accel, modele błędów, zakresy, ODR, aliasing, timestamp, FIFO i DMA, filtry, drgania, montaż, kalibracja temperaturowa, redundancja, health monitoring oraz kwalifikacja laboratoryjna.Filtr Kalmana i EKF w UAVPraktyczna anatomia filtra nawigacyjnego: model stanu i błędów, macierze Q/R, opóźnione obserwacje, bramkowanie innowacji, Joseph form i diagnostyka.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.Architektura zasilania flight controlleraOd baterii i power module do rdzenia MCU: budżet mocy, ideal-diode ORing, priorytety źródeł, inrush, filtracja, sekwencjonowanie, load switch i obserwowalność.Diagnostyka logów i wibracjiPraktyczny proces diagnostyczny: synchronizacja czasu, setpoint kontra measurement, widmo drgań, saturacja i rozróżnianie awarii mechanicznej od problemu regulatora.

Źródła z centralnego rejestru

  1. ArduPilot: EKF3 Affinity and Lane Switching [dokumentacja projektu]
  2. PX4: barometer redundancy and calibration [dokumentacja projektu]
  3. PX4: System Failure Injection [dokumentacja projektu]
  4. PX4: Using PX4 Navigation Filter EKF2 [dokumentacja projektu]
  5. Bosch Sensortec: BMI088 [datasheet]