Analiza wypadku UAV nie zaczyna się od wykresu żyroskopu, lecz od zabezpieczenia ludzi, energii i danych. Wrak może zawierać uszkodzony akumulator, obracający się aktuator, napięte elementy kompozytowe i kondensatory, a pochopne ponowne podłączenie zasilania może nadpisać log, skasować licznik resetów albo pogłębić zwarcie. Dopiero po opanowaniu zagrożeń dokumentuje się stan zastany i buduje linię czasu.

Celem nie jest znalezienie pierwszej anomalii, która pasuje do intuicji. Trzeba wskazać przyczynę pierwotną, czynniki współuczestniczące, działanie zabezpieczeń i skutki uderzenia, a każdemu wnioskowi nadać poziom pewności. Pęknięty przewód po wydobyciu wraku może być przyczyną utraty zasilania, skutkiem uderzenia albo skutkiem nieostrożnego demontażu. Sam obraz elementu nie rozstrzyga kolejności zdarzeń.

Spis treści#

Zakres analizy#

Zdarzenie obejmuje nie tylko upadek. Analizy wymagają również niekontrolowane odejście od trajektorii, utrata separacji, niezamierzone lądowanie, aktywacja failsafe, utrata payloadu, przegrzanie, chwilowa utrata napędu i sytuacja, w której zabezpieczenie zapobiegło szkodzie. Near miss dostarcza często lepszych danych niż zniszczona platforma.

Na początku zapisuje się pytanie badawcze i granice systemu. Przykładowo: „dlaczego o 12:14:32 UTC platforma utraciła moment wokół osi roll?” jest lepsze niż „dlaczego dron się zepsuł?”. Granice obejmują statek, operatora, GCS, łącza, korekty RTK, usługi chmurowe, stację bazową i środowisko.

Rezultat powinien rozdzielać:

  • zdarzenie inicjujące — pierwsze odejście systemu od stanu poprawnego,
  • przyczynę pierwotną — mechanizm, którego usunięcie zapobiegłoby zdarzeniu,
  • czynniki współuczestniczące — zwiększały prawdopodobieństwo lub ciężkość,
  • reakcję systemu — kontrolery, redundancja i failsafe,
  • reakcję człowieka — komendy, decyzje i dostępne informacje,
  • skutki — uszkodzenia powstałe po utracie kontroli i przy uderzeniu.

Nie zawsze da się wskazać pojedynczą przyczynę. Awaria może wymagać jednoczesnego błędu zasilania, braku redundancji i nieprawidłowej reakcji failsafe.

Bezpieczeństwo miejsca#

Przed dotknięciem platformy należy ocenić:

  • czy silniki lub serwa mogą się uruchomić,
  • stan i temperaturę akumulatorów,
  • dym, zapach elektrolitu, przebicie pakietu i zwarcie,
  • naprężone śmigła, sprężyny, linki i elementy kompozytowe,
  • ostre włókna węglowe i szkło,
  • substancje z payloadu,
  • ryzyko dla osób postronnych i infrastruktury.

Jeżeli można bezpiecznie odłączyć energię zgodnie z procedurą platformy, robi się to bez niepotrzebnego poruszania wrakiem. Uszkodzonego LiPo nie ładuje się i nie przewozi jak sprawnego pakietu. Nośnik danych wyjmuje się dopiero po upewnieniu, że zapis został zakończony i urządzenie nie jest zasilane.

Obowiązki zgłoszeniowe zależą od jurysdykcji, rodzaju operacji i skutków. Techniczny zespół badawczy powinien zachować dane oraz skoordynować działania z osobą odpowiedzialną za bezpieczeństwo i wymagane zgłoszenia. Nie należy kasować logów ani naprawiać platformy przed decyzją o zakresie formalnego badania.

Zamrożenie konfiguracji#

Konfiguracja jest częścią dowodu. Trzeba zapisać:

  • wersję firmware każdego urządzenia i identyfikator buildu,
  • pełny eksport parametrów FC, ESC, odbiornika i payloadu,
  • mikser, kolejność oraz kierunki aktuatorów,
  • mission file, geofence, rally points i home,
  • ustawienia failsafe i trybów lotu,
  • kalibracje IMU, kompasu, RC, airspeed i zasilania,
  • mapowanie portów, timerów i CAN node ID,
  • wersję aplikacji GCS oraz konfigurację operatora,
  • manifest sprzętu z numerami seryjnymi.

Nie wolno najpierw aktualizować firmware „żeby sprawdzić, czy problem zniknie”. Aktualizacja zmienia kod, parametry domyślne, format logu i zachowanie bootloadera. Jeżeli urządzenie musi zostać uruchomione, tworzy się plan odczytu minimalizujący zapis i dokumentuje każdą czynność.

W systemach zapisujących parametry przy starcie nawet samo podłączenie USB może zmienić stan. Warto projektować osobny tryb serwisowy lub interfejs tylko do odczytu.

Dokumentacja wraku#

Przed demontażem wykonuje się zdjęcia szerokie i szczegółowe z miarką oraz oznaczeniem orientacji. Dokumentuje się położenie platformy, rozrzut elementów, orientację śmigieł, stan złączy, pozycje przełączników, mechanizmy zatrzaskowe i ślady termiczne.

Każdy odłączony element dostaje identyfikator i opis miejsca. Luźna śruba znaleziona wewnątrz kadłuba może być ważna, ale trzeba ustalić, czy pochodzi z danego mocowania. Fragmenty śmigła warto dopasować bez wymuszania, aby ocenić kierunek i charakter pęknięcia.

Szczególnie istotne są:

  • ślady łuku elektrycznego i stopione złącza,
  • odbarwienia PCB i komponentów,
  • śruby silników sięgające uzwojeń,
  • przecięte lub wyrwane przewody fazowe,
  • złamane ramiona i charakter powierzchni pęknięcia,
  • odkształcenie piasty oraz krawędzi śmigła,
  • przesunięte ciężkie moduły i bateria,
  • stan izolacji w pobliżu ostrych krawędzi,
  • mocowanie anten i przewodów RF.

Zdjęcie po rozebraniu nie zastępuje stanu pierwotnego. Każdy etap demontażu powinien mieć osobną serię fotografii.

Łańcuch pochodzenia danych#

Dla każdego pliku zapisuje się źródło, osobę pobierającą, czas, narzędzie, metodę i późniejsze kopie. Ma to znaczenie nie tylko formalne: pozwala odróżnić oryginał z karty od wersji przetworzonej przez viewer.

Minimalny rejestr:

Pole Przykład zawartości
identyfikator FC-SD-01 / GCS-TLOG-01
źródło karta microSD z flight controllera
data pozyskania czas lokalny i UTC
metoda obraz nośnika albo kopiowanie pliku
narzędzie i wersja czytnik, system, program
suma SHA-256 hash oryginału
osoba operator czynności
uwagi nośnik uszkodzony, plik bez końca

Oryginał przechowuje się bez modyfikacji. Analizę wykonuje się na kopii roboczej. Eksport CSV, naprawiony ULog i przycięty film są nowymi artefaktami z własnymi sumami.

Kopia robocza i sumy kontrolne#

Suma kryptograficzna nie dowodzi, że plik był prawidłowy w chwili zapisu, ale pozwala wykazać, że później się nie zmienił. SHA-256 jest praktycznym wyborem do identyfikacji kopii. Wynik zapisuje się obok manifestu, nie w samym analizowanym pliku.

Jeżeli karta ma błędy, pierwszeństwo ma wykonanie obrazu lub odczyt w sposób minimalizujący kolejne próby. Wielokrotne wkładanie uszkodzonego nośnika może pogorszyć stan. Naprawę systemu plików prowadzi się na kopii, ponieważ narzędzie może zmienić metadane i zawartość.

Pliki z narzędzi online mogą ujawniać pozycję, identyfikatory i parametry platformy. Przed wysłaniem do usługi zewnętrznej trzeba ocenić poufność, politykę przechowywania i to, czy analiza może być wykonana lokalnie.

Źródła danych#

Żadne źródło nie jest kompletne. Typowy zestaw obejmuje:

  • log pokładowy FC,
  • log ESC lub telemetrię eRPM/temperatury,
  • log GCS i strumień MAVLink,
  • log odbiornika RC i nadajnika,
  • zapis modemu lub sieci,
  • log payloadu oraz komputera pokładowego,
  • wideo FPV, payloadu i obserwatora naziemnego,
  • dane stacji pogodowej,
  • konfigurację misji i mapę,
  • zeznania operatora i obserwatora,
  • wrak i wyniki pomiarów komponentów.

Log pokładowy najlepiej pokazuje stan wewnętrzny kontrolera, ale może się urwać przy utracie zasilania. Telemetria naziemna może zachować ostatnie wiadomości wysłane przed zanikiem FC, lecz ma niższy rate i straty pakietów. Wideo pokazuje efekt fizyczny, ale zwykle ma opóźnienie i stabilizację obrazu.

ULog, DataFlash i Blackbox#

ULog zapisuje wiadomości, definicje pól, parametry i komunikaty w formacie opisanym przez PX4. Plik może zawierać dynamiczne subskrypcje, dropped messages i dane wielu instancji.[3] DataFlash ArduPilot ma własne typy wiadomości i metadane; Mission Planner oraz narzędzia projektu umożliwiają pobieranie i wykresy.[1]

Blackbox Betaflight rejestruje wejścia, stany pośrednie i wyjścia pętli w wysokiej częstotliwości. Plik zawiera sesje, nagłówki konfiguracji i ramki różnicowe; przepustowość nośnika może powodować dropped frames.[6][7]

Przed analizą należy ustalić:

  • wersję formatu i firmware,
  • częstotliwość próbkowania każdego pola,
  • jednostki i układ współrzędnych,
  • czy wartości są raw, filtered, setpoint czy estimate,
  • liczbę brakujących ramek,
  • moment rozpoczęcia i zakończenia sesji,
  • czy plik zawiera kilka lotów.

Nie wolno porównywać punkt po punkcie kanałów o różnych timestampach bez resamplingu i oceny opóźnienia.

Telemetria, GCS i serwer#

Log GCS może zawierać STATUSTEXT, eventy, zmianę trybu, parametry wysłane w locie i komendy operatora. PX4 Events mają poziom logowania oraz metadane interpretowane przez GCS i Flight Review; brak opisu eventu w viewerze nie oznacza braku zdarzenia — może brakować zgodnych metadanych wersji.[5]

Tlog ma ograniczenia: łącze może tracić pakiety, GCS może subskrybować tylko część strumieni, a czas zapisu bywa czasem odbioru na ziemi. Mimo to utrata całej telemetrii dokładnie w chwili końca logu pokładowego wzmacnia hipotezę zaniku zasilania lub resetu.

Log serwera lub chmury może dodać heartbeat, latency, retransmisje i polecenia API. Trzeba jednak sprawdzić, czy czas serwera był synchronizowany i czy kolejka nie zmieniała kolejności zdarzeń.

Wideo, audio i obserwacje#

Wideo pomaga rozpoznać odłączenie śmigła, flutter, kontakt z przeszkodą, pożar, zmianę dźwięku i faktyczny ruch kadłuba. Stabilizacja cyfrowa może ukrywać krótkie obroty, rolling shutter zniekształca śmigła, a automatyczna ekspozycja utrudnia ocenę czasu.

Audio często pokazuje zmianę prędkości jednego napędu przed widocznym ruchem. Analiza widma może wskazać utratę harmonicznej, lecz identyfikację silnika trzeba potwierdzić eRPM lub geometrią ruchu. Kompresja i automatyczne odszumianie ograniczają wartość ilościową.

Relacje świadków zapisuje się osobno, możliwie szybko i bez sugerowania odpowiedzi. „Silnik zgasł” jest obserwacją interpretacyjną; cenniejszy opis brzmi „pojawił się krótki wysoki dźwięk, potem platforma obróciła się w prawo”.

Synchronizacja zegarów#

Oś czasu wymaga mapowania zegarów. Źródła mogą używać UTC, GPS time, czasu od boot, numeru klatki albo lokalnego czasu komputera. Ustala się punkty wspólne:

  • arming beep widoczny w Blackbox i słyszalny na wideo,
  • zmiana trybu w FC i GCS,
  • komenda testowa widoczna w kilku logach,
  • błysk LED lub impuls synchronizacyjny,
  • PPS GNSS,
  • kontakt z ziemią widoczny jako pik IMU i obraz.

Mapowanie liniowe ma postać:

t_B = a · t_A + b

b opisuje offset, a a dryft częstotliwości zegara. Jeden punkt wyznacza tylko offset; dwa odległe punkty pozwalają oszacować dryft. Wideo 30 fps daje nominalną rozdzielczość 33,3 ms, ale variable frame rate może ją pogorszyć.

Każdy wykres w raporcie powinien używać tej samej osi czasu albo jasno podawać przesunięcie.

Czy log jest kompletny#

Nagły koniec pliku w powietrzu jest sam w sobie wskazówką. PX4 wskazuje utratę zasilania lub hard fault jako ważne hipotezy i zaleca szukanie osobnych zapisów fault na karcie.[4] Nie jest to jednak dowód: nośnik mógł się zapełnić, logger zostać zatrzymany, plik uszkodzić przy uderzeniu albo sesja mogła być źle wybrana.

Sprawdza się:

  • poprawność końcowej ramki i znacznika zakończenia,
  • dropped messages przed końcem,
  • zajętość i błędy nośnika,
  • napięcie oraz reset reason,
  • obecność pliku hard fault/crash dump,
  • ciągłość heartbeat w GCS,
  • czy po końcu logu wideo nadal pokazuje sterowany lot,
  • czy urządzenie uruchomiło nową sesję po reboocie.

Brak danych nie może być interpretowany jak wartość zero. Jeżeli RPM przestaje być raportowane, nie wiadomo jeszcze, czy silnik stanął, ESC zresetował się czy tylko zniknęła telemetria.

Oś czasu zdarzenia#

Najpierw dzieli się lot na fazy: boot, pre-arm, arm, start, lot ustalony, manewr, pierwsza anomalia, reakcja, utrata kontroli, kontakt i stan po kontakcie. Dla każdej fazy zapisuje się tryb, setpointy, źródła estymacji, zasilanie i alerty.

Tabela osi czasu powinna być krótka i oparta na dowodach:

Czas względny Obserwacja Źródło Interpretacja
-2,40 s wzrost setpoint roll log FC komenda operatora/misji
-0,18 s eRPM M3 spada, komenda rośnie ESC + FC utrata odpowiedzi napędu 3
0,00 s roll rate przekracza zakres kontroli IMU początek niekontrolowanego obrotu
+0,62 s koniec ULog i heartbeat FC + GCS utrata zasilania przy kontakcie lub reset

Nie wpisuje się „awaria ESC” w kolumnie obserwacji. To hipoteza wymagająca dalszych testów.

Punkt pierwszej rozbieżności#

Punkt pierwszej rozbieżności to najwcześniejszy moment, w którym oczekiwane i rzeczywiste zachowanie przestają się zgadzać. Szukanie od uderzenia wstecz ogranicza ryzyko uznania skutków za przyczynę.

Przykłady:

  • komenda roll pozostaje stała, ale measured rate odchodzi od setpointu,
  • pozycja GNSS skacze, lecz INS nie rejestruje ruchu,
  • napięcie zasilania spada przed resetem urządzeń,
  • actuator command się zmienia, ale feedback pozycji serwa nie reaguje,
  • RC input znika przed przejściem do failsafe,
  • CPU load i loop time rosną przed watchdog reset.

Należy cofnąć się jeszcze wcześniej i szukać warunków przygotowujących: narastającej temperatury, błędów magistrali, wibracji, spadku RSSI, saturacji regulatora lub zapełniania kolejki.

Komenda, odpowiedź i skutek#

Każdy tor sterowania analizuje się jako trzy sygnały:

setpoint/command → odpowiedź aktuatora/sensora → ruch platformy

Jeżeli command nie powstał, problem leży przed mikserem lub w logice. Jeżeli command powstał, a eRPM/pozycja serwa nie odpowiedziały, problem jest w interfejsie, zasilaniu lub aktuatorze. Jeżeli aktuator odpowiedział, ale platforma nie wykonała oczekiwanego ruchu, trzeba badać mechanikę, aerodynamikę i model miksowania.

Ta struktura chroni przed wnioskiem „PID spowodował wypadek” tylko dlatego, że wyjście PID jest duże. Regulator po utracie ciągu powinien zwiększyć komendę; jest to reakcja na awarię, niekoniecznie jej przyczyna.

Analiza zasilania#

Rejestruje się napięcie baterii, szyn logicznych, prąd, power flags, brownout i reset reason. Napięcie raportowane przez FC może nie pokazywać lokalnego zapadu ESC ani chwilowego spadku krótszego niż rate loggera.

Wskazówki awarii zasilania:

  • jednoczesny zanik kilku niezależnych urządzeń,
  • koniec logu bez kontrolowanego disarm,
  • restart i nowa sesja po zdarzeniu,
  • niskie minimalne napięcie lub skok prądu,
  • stopione/odbarwione złącze,
  • reset reason BOR/POR/watchdog zależnie od MCU,
  • krótkie zaniki heartbeat przed końcem.

Pakiet po uderzeniu może mieć niskie napięcie z powodu zwarcia wtórnego. Pomiar po odzyskaniu nie dowodzi zapadu przed zdarzeniem. Liczy się kolejność w logu i ślady fizyczne.

Analiza estymatora#

Porównuje się raw sensors, estymowane stany, innowacje, test ratios, fusion flags i resety. Duży błąd postawy może być przyczyną błędnego sterowania albo skutkiem obrotu po utracie napędu.

Kluczowe pytania:

  • czy sensor publikował i był zdrowy,
  • czy jego dane przeszły bramkę innowacji,
  • czy estymator zmienił źródło lub lane,
  • czy reset pozycji/yaw nastąpił przed odejściem,
  • czy wibracje spowodowały clipping/aliasing,
  • czy timestamp i latency były prawidłowe,
  • czy magnetometr, GNSS i prędkość były spójne.

Skok raw GNSS odrzucony przez EKF nie powinien bezpośrednio sterować platformą. Skok global position po resecie estymatora może już wywołać agresywną korektę w trybie pozycyjnym.

Analiza pętli sterowania#

Wykreśla się setpoint, measured rate/attitude, error, P/I/D/FF, output miksera i saturację. Zdrowa pętla śledzi setpoint z opóźnieniem zgodnym z dynamiką. Oscylacje rosnące przed anomalią mogą wskazywać niestabilność, rezonans lub zmianę konstrukcji.

Saturacja jest ważna: gdy wyjście osiąga granicę, regulator nie ma już autorytetu. Powodem może być zbyt mały ciąg, skrajny środek ciężkości, wiatr, błędny miks, uszkodzony silnik albo nierealny setpoint. Windup członu I może opóźnić powrót po zejściu z granicy.

Nie ocenia się strojenia po fragmencie obejmującym kontakt z przeszkodą. Impuls uderzenia naturalnie przekracza pasmo regulatora i może wygenerować skrajny D-term.

Analiza napędu i aktuatorów#

Dla silników porównuje się command, eRPM, prąd, temperaturę i flagi ESC. Utrata eRPM przy utrzymanej komendzie poprzedzająca odchylenie osi jest silnym śladem awarii napędu. Dla serw potrzebny jest feedback pozycji lub przynajmniej pomiar prądu; sama komenda PWM nie dowodzi wychylenia powierzchni.

Sprawdza się:

  • desync, stall i błędy telemetrii,
  • odłączenie lub pęknięcie śmigła,
  • przerwę fazy i zimny lut,
  • przegrzanie i ograniczenie prądowe,
  • błędny kierunek lub mapowanie po serwisie,
  • mechaniczne zablokowanie serwa,
  • luz cięgna, zawiasu albo sworznia,
  • saturację aktuatora i rate limit.

Śmigło złamane przy uderzeniu często ma inne ślady niż pęknięcie zmęczeniowe w locie, ale pewny wniosek może wymagać analizy materiałowej. Brak fragmentu ogranicza pewność.

Analiza łącza i failsafe#

RSSI, LQ, SNR i liczba utraconych ramek pokazują stan łącza, ale failsafe zależy również od timeoutu odbiornika, protokołu do FC i konfiguracji flight controllera. Nadajnik może nadal pokazywać telemetrię, gdy kanały RC do FC są nieprawidłowe, i odwrotnie.

Rekonstruuje się:

  1. ostatnią prawidłową ramkę sterującą,
  2. stan odbiornika po utracie RF,
  3. moment wykrycia timeout przez FC,
  4. wejście w stage/mode failsafe,
  5. wybraną akcję i jej warunki,
  6. możliwość wykonania akcji przy stanie estymatora i energii,
  7. komendy operatora po zdarzeniu.

RTL nie jest dowodem sprawnego failsafe, jeśli pozycja globalna była błędna. System mógł prawidłowo wykonać źle dobraną strategię.

Firmware, watchdog i hard fault#

Koniec logu bez spadku zasilania może wynikać z hard fault, deadlocku, przeciążenia CPU lub błędu pamięci. Szuka się crash dump, fault file, reset reason, liczników watchdog, stack watermark i eventów scheduler.

Watchdog reset jest reakcją, nie przyczyną pierwotną. Należy ustalić, które zadanie przestało robić postęp i dlaczego. Adres faultu mapuje się do dokładnego ELF i map file tego samego buildu; symbolizacja na innej wersji daje fałszywe wyniki.

Jeżeli problem pojawił się po aktualizacji, porównuje się diff parametrów, release notes i zmianę sterowników. Sam związek czasowy nie dowodzi regresji — serwis mógł również zmienić okablowanie.

Mechanika i aerodynamika#

Mechanika może inicjować zdarzenie bez błędu elektroniki. Bada się środek ciężkości, mocowanie baterii i payloadu, sztywność ramy, luzy, pęknięcia zmęczeniowe, flutter, oblodzenie, zanieczyszczenie rurki Pitota i deformację powierzchni.

W fixed-wing utrata prędkości i przeciągnięcie mogą dać duży błąd postawy przy sprawnych serwach. W VTOL krytyczna jest faza przejścia, w której maleje autorytet jednego układu, a drugi jeszcze go nie przejął. W multirotorze przesunięcie baterii zmienia środek ciężkości i może doprowadzić do saturacji jednego zestawu silników.

Warunki środowiskowe zapisuje się z niezależnego źródła: wiatr, porywy, opad, temperatura, gęstość powietrza i oświetlenie dla vision. Dane pogodowe z odległej stacji mogą nie odzwierciedlać lokalnego przepływu przy budynku.

Człowiek i interfejs#

Analiza człowieka nie służy przypisaniu winy, lecz sprawdzeniu, czy system dostarczył właściwe informacje i czy procedura była wykonalna. Bada się tryb lotu, układ przełączników, komunikaty GCS, workload, opóźnienia wideo, szkolenie, checklistę i presję operacyjną.

„Błąd operatora” nie jest końcem analizy. Trzeba zapytać:

  • dlaczego komenda była możliwa w tym stanie,
  • czy interfejs jednoznacznie pokazywał aktywny tryb,
  • czy ostrzeżenie było widoczne i zrozumiałe,
  • czy procedura wymagała nierealnego czasu reakcji,
  • czy dwa przełączniki miały myląco podobne funkcje,
  • czy automatyka zmieniła tryb bez wyraźnego potwierdzenia.

Działanie człowieka bywa również skuteczną barierą, którą należy zachować w projekcie.

Skutek uderzenia a przyczyna#

Kontakt z ziemią generuje przyspieszenia znacznie większe niż lot, odłącza złącza, łamie luty i przesuwa elementy. Wszystko, co występuje dopiero po pierwszym piku kontaktu, jest domyślnie skutkiem, dopóki inne dowody nie pokażą wcześniejszego początku.

Przydatne reguły:

  • koniec logu po piku uderzenia nie dowodzi wcześniejszej utraty zasilania,
  • przerwana wiązka bez śladu łuku nie dowodzi przerwy pod obciążeniem,
  • błąd IMU po przekroczeniu zakresu w uderzeniu nie wyjaśnia utraty kontroli przed nim,
  • zmiana pozycji modułu po pęknięciu mocowania nie oznacza, że był luźny w locie,
  • uszkodzony nośnik może wyjaśnić brak końca logu, ale nie wcześniejszą trajektorię.

Najsilniejszy dowód przyczynowy łączy anomalię przed kontaktem z fizycznym uszkodzeniem i odtwarzalnym testem.

Drzewo hipotez#

Hipotezy buduje się równolegle, aby uniknąć zakotwiczenia. Dla utraty roll można rozważyć:

utrata momentu roll
├── brak wymaganej komendy
│   ├── błędny setpoint/tryb
│   ├── błąd estymacji
│   └── saturacja/mikser
├── command jest, aktuator nie odpowiada
│   ├── sygnał/protokół
│   ├── zasilanie
│   ├── ESC/serwo
│   └── przewód/mechanika
└── aktuator odpowiada, efekt aerodynamiczny zły
    ├── śmigło/powierzchnia
    ├── środek ciężkości
    ├── przeciągnięcie/napływ
    └── uszkodzenie konstrukcji

Dla każdej gałęzi zapisuje się przewidywane ślady i obserwacje przeczące. Hipoteza wartościowa musi być falsyfikowalna. „Zakłócenia” bez wskazania sygnału, mechanizmu i oczekiwanego śladu nie są wystarczającą hipotezą.

Testy rozstrzygające#

Test ma rozróżniać co najmniej dwie hipotezy. Przykłady:

  • zamiana silnika i ESC pokazuje, za którym elementem podąża wada,
  • odtworzenie obciążenia z pomiarem napięcia rozróżnia brownout od timeoutu sygnału,
  • analiza osobnego tlogu rozstrzyga, czy FC przestał nadawać przed końcem ULog,
  • pomiar serwa pod obciążeniem odróżnia poprawny PWM od mechanicznej utraty momentu,
  • odtworzenie timestampów w replay pokazuje wpływ latency na innowacje.

Nie wykonuje się lotu reprodukcyjnego, dopóki hipotezę można sprawdzić na stole, w symulacji lub osłoniętym stanowisku. Uszkodzonych elementów krytycznych nie używa się ponownie tylko po to, aby „zobaczyć, czy awaria wróci”.

Każdy test ma konfigurację, kryterium przerwania, pomiary, wynik i wpływ na prawdopodobieństwo hipotez.

Reprodukcja w SITL i HIL#

SITL pozwala odtworzyć mission, tryby, utratę linku i błędy sensorów bez ryzyka. HIL dodaje prawdziwy flight controller, timing, porty i część konfiguracji. Replay logu może sprawdzić zachowanie estymatora na tych samych obserwacjach.

Reprodukcja powinna używać dokładnej wersji firmware i parametrów. Należy jednak rozróżnić „model odtworzył skutek” od „dowiedziono przyczyny”. Wiele różnych usterek może dać tę samą trajektorię po utracie jednego silnika.

Największą wartość ma test predykcyjny: hipoteza przewiduje konkretny, wcześniej niesprawdzony ślad, a eksperyment go potwierdza lub obala.

Poziomy pewności#

Wnioski oznacza się jawnie:

  • potwierdzone — bezpośrednie, spójne dowody z wielu źródeł lub rozstrzygający test,
  • bardzo prawdopodobne — najlepiej wyjaśnia dane, alternatywy mają dowody przeciwne,
  • prawdopodobne — zgodne z danymi, ale brakuje rozstrzygającego źródła,
  • możliwe — mechanizm realny, dowody słabe lub niepełne,
  • wykluczone w badanym zakresie — test przeczy hipotezie przy opisanych warunkach,
  • nieustalone — dane nie pozwalają rozstrzygnąć.

Nie używa się wartości procentowych bez modelu probabilistycznego. Pewność dotyczy konkretnego zdania, nie całego raportu.

Raport końcowy#

Raport powinien zawierać:

  1. streszczenie zdarzenia i skutków,
  2. zakres oraz ograniczenia badania,
  3. opis platformy, konfiguracji i misji,
  4. źródła danych i ich integralność,
  5. zsynchronizowaną oś czasu,
  6. ustalenia dla zasilania, sterowania, estymacji, napędu, łącza i mechaniki,
  7. hipotezy rozważone oraz dowody za/przeciw,
  8. przyczynę pierwotną i czynniki współuczestniczące z poziomem pewności,
  9. ocenę reakcji failsafe i operatora,
  10. działania korygujące, właścicieli i testy zamknięcia,
  11. załączniki: hashe, wykresy, konfiguracje, zdjęcia i narzędzia.

Każdy wykres ma nazwy pól, jednostki, źródło, wersję dekodera i wspólny czas. Wybrany fragment nie może ukrywać wcześniejszego trendu.

Działania korygujące#

Działanie powinno odpowiadać mechanizmowi i mieć test akceptacyjny. „Wymienić ESC” jest słabsze od: „zastąpić ESC, zweryfikować fazy i telemetrię, wykonać profil hamowni do maksymalnego prądu, brak zdarzeń desync, temperatura poniżej limitu z marginesem”.

Kolejność działań:

  • natychmiastowe ograniczenie ryzyka lub uziemienie konfiguracji,
  • naprawa komponentu/procedury,
  • zmiana konstrukcyjna zapobiegająca powtórzeniu,
  • poprawa detekcji i failsafe,
  • rozszerzenie logowania,
  • test regresji oraz przegląd podobnych platform.

Warto sprawdzić, czy ta sama wada systemowa istnieje w innych egzemplarzach, partiach przewodów lub wersjach konfiguracji.

Minimalny pakiet logowania#

Platforma projektowana do diagnozowalności powinna rejestrować:

  • identyfikator buildu i snapshot parametrów,
  • raw oraz filtered IMU z informacją o clipping,
  • setpointy i stany estymowane,
  • innovations, variances i fusion flags,
  • wejścia RC/misji oraz zmiany trybu,
  • wyjścia miksera i feedback aktuatorów/eRPM,
  • napięcia, prądy, power flags i temperatury,
  • stan linków, błędy magistral i timeouty,
  • eventy, failsafe, watchdog i reset reason,
  • timestamp sample oraz publication.

Rate dobiera się do zjawiska. Napięcie 10 Hz może nie uchwycić zapadu 2 ms, a log IMU 50 Hz nie wystarczy do analizy rezonansu. Z drugiej strony przeciążony logger gubi ramki. Projektuje się budżet przepływności i monitoruje dropped messages.[3][6]

Nośnik powinien mieć zapas i kontrolę stanu. Betaflight ostrzega, że pełny dataflash wyłącza logowanie, a po disarm trzeba dać czas na zakończenie zapisu.[7]

Lista kontrolna#

Na miejscu#

  • [ ] zabezpieczono ludzi, energię i payload,
  • [ ] nie uruchamiano ponownie urządzeń bez planu,
  • [ ] wykonano zdjęcia przed przemieszczeniem i demontażem,
  • [ ] oznaczono elementy oraz miejsce znalezienia,
  • [ ] zabezpieczono nośniki i log GCS,
  • [ ] zapisano czas, pogodę i relacje świadków.

Dane#

  • [ ] utworzono kopie i SHA-256,
  • [ ] zachowano oryginały bez modyfikacji,
  • [ ] wyeksportowano parametry i mission,
  • [ ] ustalono wersje firmware i formatów,
  • [ ] oceniono dropped frames i koniec logu,
  • [ ] zsynchronizowano zegary.

Analiza#

  • [ ] wyznaczono punkt pierwszej rozbieżności,
  • [ ] rozdzielono command, feedback i ruch,
  • [ ] sprawdzono zasilanie, estymator, sterowanie, aktuatory, łącze i mechanikę,
  • [ ] oddzielono skutki uderzenia,
  • [ ] zapisano alternatywne hipotezy,
  • [ ] wykonano bezpieczne testy rozstrzygające,
  • [ ] wnioskom przypisano pewność,
  • [ ] działania korygujące mają test zamknięcia.

Powiązane tematy#

Przypisy#

  1. ArduPilot, Downloading and Analyzing Data Logs — pozyskiwanie i podstawowa analiza logów DataFlash.
  2. ArduPilot, Diagnosing Common Problems Using Logs — interpretacja zasilania, GPS, wibracji i odpowiedzi systemu w logach.
  3. PX4, ULog File Format — struktura wiadomości, definicje pól, parametry i obsługa dropped messages.
  4. PX4, Log Analysis using Flight Review — uporządkowana analiza ULog, kompletność zapisu, sensory, sterowanie i awarie zasilania/firmware.
  5. PX4, Events Interface — zdarzenia, poziomy logowania i metadane interpretowane przez GCS oraz Flight Review.
  6. Betaflight, Blackbox Logging Internals — struktura sesji i ramek, częstotliwość oraz zapis stanów pętli sterowania.
  7. Betaflight, Blackbox Flight Data Recorder — konfiguracja nośnika, logged data, dropped frames i bezpieczne zakończenie zapisu.

Powiązane tematy

Diagnostyka logów i wibracjiPraktyczny proces diagnostyczny: synchronizacja czasu, setpoint kontra measurement, widmo drgań, saturacja i rozróżnianie awarii mechanicznej od problemu regulatora.Blackbox: pamięć i logowanie w UAVBlackbox jako tor pomiarowy bez wpływu na sterowanie: model sygnałów, częstotliwości i czasu, buforowanie, ramki resynchronizujące, media flash/SD, brownout i walidacja parsera.ESC desync — diagnostyka utraty komutacjiPraktyczna diagnostyka utraty komutacji bezczujnikowego BLDC: mechanizm przejścia od back-EMF do następnej komutacji, rozróżnianie desync od zaniku komendy, brownoutu i usterki mechanicznej, interpretacja logów oraz eRPM/EDT, wpływ obciążenia, timingu, kompensacji demagnetyzacji, idle, PWM i DShot, a także kontrolowany plan prób od testu bez śmigła do hamowni.Diagnostyka problemów GNSS w UAVMetodyczna diagnostyka toru GNSS od anteny i LNA przez interfejs odbiornika po fuzję w EKF: czas do fixa, C/N0 per sygnał, geometria satelitów, accuracy estimates, update rate i latency, multipath i self-jamming, stan korekt RTK, różnice między raw fix a pozycją estymowaną, innowacje pozycji/prędkości, porównanie dwóch odbiorników oraz bezpieczne reakcje na zakłócenia i podejrzenie spoofingu.Brownout w UAVAnatomia krótkiego zapadu zasilania: źródła impulsów, impedancja toru, dobór progów BOR/PVD, kondensator hold-up, reset reason i testy z kontrolowanym obciążeniem.Failsafe jako maszyna stanówFailsafe jako deterministyczny system decyzji: źródła faultów, persistence i hysteresis, priorytety reakcji, konflikty RC/GNSS/baterii, latch, recovery oraz macierz testowa.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.Proces uruchomienia nowego UAVKontrolowany commissioning nowej platformy: konfiguracja bazowa, testy zasilania i sensorów, mapowanie aktuatorów bez śmigieł, failsafe, próby naziemne, pierwszy zawis i decyzje go/no-go.Symulacja SITL, HITL i HILPorównanie poziomów symulacji i projektowanie testów, które rzeczywiście wykrywają błędy firmware, integracji oraz konfiguracji.

Źródła z centralnego rejestru

  1. ArduPilot: Downloading and Analyzing Data Logs [dokumentacja]
  2. ArduPilot Copter: Diagnosing Common Problems Using Logs [dokumentacja projektu open source]
  3. PX4: ULog File Format [specyfikacja formatu]
  4. PX4 Guide: Log Analysis using Flight Review [dokumentacja projektu]
  5. PX4 Guide: Events Interface [dokumentacja projektu open source]
  6. Betaflight: Blackbox logging internals [dokumentacja projektu]
  7. Betaflight: Blackbox Flight Data Recorder [dokumentacja projektu open source]