Flight controller — jak działa

Flight controller, w skrócie FC, jest komputerem czasu rzeczywistego, który przekształca pomiary ruchu, polecenia operatora i cele autonomiczne w bezpieczne sygnały dla silników oraz serw. Nie robi tego jednym algorytmem. W każdej sekundzie wykonuje setki lub tysiące cykli: odbiera próbki, sprawdza ich świeżość, estymuje stan statku, oblicza błędy regulacji, rozdziela żądane siły i momenty między aktuatory, nadzoruje zasilanie i zapisuje dane diagnostyczne.

Najważniejszą cechą dobrego kontrolera nie jest więc sam model mikrokontrolera ani maksymalna częstotliwość pętli. Liczy się cały zamknięty tor: od chwili fizycznego ruchu do chwili zmiany siły na aktuatorze. Jego opóźnienie, jitter, pasmo, odporność na błędne dane i zachowanie po awarii decydują o jakości lotu.

Ten artykuł buduje przekrojowy model kontrolera lotu. Po jego przeczytaniu powinno być jasne, co dzieje się między poruszeniem drążka a zmianą obrotów silników, dlaczego GNSS nie stabilizuje bezpośrednio przechylenia, czym różni się estymator od regulatora, gdzie kończy się odpowiedzialność FC, a zaczyna ESC oraz dlaczego poprawne logi są częścią architektury, a nie dodatkiem dla zaawansowanych użytkowników.

Najkrótsza poprawna definicja#

Kontroler lotu zamyka pętlę sprzężenia zwrotnego:

            zakłócenia: wiatr, asymetria, drgania, zmiana masy
                               ↓
wartość zadana → regulator → aktuatory → statek → sensory
       ↑                                           │
       └────────────── estymowany stan ────────────┘

Sensory nie mówią kontrolerowi wprost „dron jest przechylony o 7° i leci na północ 3 m/s”. Dostarczają fragmentaryczne, zaszumione i opóźnione obserwacje: prędkość kątową, siłę właściwą, ciśnienie, pole magnetyczne, czas przelotu sygnału GNSS albo przepływ obrazu. Estymator stanu łączy je z modelem ruchu. Regulator porównuje oszacowany stan z wartością zadaną. Alokator sterowania przekłada żądane siły i momenty na konkretne silniki, powierzchnie sterowe lub mechanizmy wektorowania ciągu.

W konsekwencji FC wykonuje równocześnie kilka różnych zadań:

Flight controller, autopilot i komputer towarzyszący#

Nazwy bywają używane zamiennie, ale warto rozdzielić role.

Flight controller oznacza zwykle płytkę i firmware odpowiedzialne za stabilizację oraz krytyczne funkcje lotu. Autopilot podkreśla szerszą funkcjonalność: estymację pozycji, tryby automatyczne, misje, geofencing i zarządzanie awariami. W prostym quadrocopterze oba pojęcia opisują to samo urządzenie. W dużej architekturze autopilot może składać się z kilku modułów, a sama jednostka FMU jest tylko jednym z nich.

Komputer towarzyszący — Raspberry Pi, Jetson, x86 albo inny SBC — wykonuje zadania wymagające systemu Linux, dużej pamięci lub akceleratora: wizyjne wykrywanie przeszkód, mapowanie, planowanie wysokiego poziomu, przetwarzanie payloadu. Nie powinien być jedynym elementem utrzymującym szybką stabilizację, jeśli jego system operacyjny nie gwarantuje deadline'ów. Utrata procesu wizyjnego może odebrać tryb autonomiczny, ale lokalna pętla rate powinna nadal działać.

ESC nie jest wyjściowym stopniem mocy kontrolera. FC przesyła mu wartość zadaną przez PWM, DShot albo magistralę cyfrową. Dopiero ESC mierzy prądy lub położenie wirnika, komutuje tranzystory i zasila fazy silnika BLDC.

Odbiornik RC dekoduje łącze radiowe i dostarcza kanały, pakiety lub wartości zadane. GCS konfiguruje, wizualizuje telemetrię i zarządza misją. Żaden z tych elementów nie powinien bezpośrednio omijać ograniczeń i maszyny stanów FC przy sterowaniu krytycznymi aktuatorami.

Pełna droga sygnału#

Praktyczny model kontrolera można przedstawić jako dwa przecinające się tory: tor danych lotnych oraz tor nadzoru.

TOR LOTNY

IMU ───────┐
barometr ──┤
GNSS ──────┼→ czas + kalibracja + walidacja → estymator → stan statku
magnetometr┤                                         │
flow/VIO ──┘                                         ↓

RC / misja / offboard → wybór trybu → setpoint → regulatory kaskadowe
                                                     ↓
                                    siła i momenty żądane
                                                     ↓
                       geometria → alokacja → limity → wyjścia → aktuatory

TOR NADZORU

zasilanie + świeżość danych + deadline + łącza + energia + geofence
                → stan zdrowia → arming / degradacja / failsafe
                → zdarzenia, telemetria i blackbox

Rozpatrzmy prosty przypadek: podmuch przechyla quadrocopter w prawo.

1. Kadłub zaczyna obracać się wokół osi roll.
2. Żyroskop rejestruje dodatnią lub ujemną prędkość kątową — znak zależy od przyjętej konwencji osi.
3. Próbka przechodzi przez kalibrację, kompensację biasu i zaprojektowaną filtrację.
4. Pętla rate porównuje zmierzoną prędkość kątową z wartością zadaną przez pętlę attitude.
5. Regulator oblicza wymagany przeciwny moment roll.
6. Alokator zwiększa zadanie odpowiedniej pary silników i zmniejsza zadanie drugiej, uwzględniając bieżący ciąg oraz ograniczenia.
7. Sterownik wyjściowy generuje ramki DShot albo impulsy PWM.
8. ESC zmienia prąd fazowy, silniki i śmigła zmieniają ciąg, a kadłub reaguje.
9. Nowa reakcja zostaje zmierzona przez IMU i cykl się zamyka.

W dobrym projekcie każdy etap ma znany znacznik czasu, jednostkę, układ współrzędnych, zakres poprawnych wartości i status jakości. Bez tego awaria na początku toru może wyglądać w logu jak błąd regulatora na końcu.

Anatomia sprzętowa kontrolera#

Mała płytka 30,5 × 30,5 mm i przemysłowa jednostka autopilota różnią się skalą, lecz składają się z podobnych bloków.

Mikrokontroler to nie cały kontroler#

Rodziny STM32, RP2040, ESP32, AVR czy 8051 mogą wykonywać algorytm stabilizacji o różnej złożoności. Sama informacja „F7” lub „H7” nie mówi jednak, czy płytka jest dobra. Kontroler może mieć szybki rdzeń, lecz współdzielić jedną magistralę ze wszystkimi sensorami, mieć źle poprowadzone zasilanie IMU albo używać wyjść kolidujących z innymi peryferiami.

Przydatne zasoby MCU to:

• timery zdolne generować równoległe wyjścia bez obciążania CPU;
• DMA do obsługi SPI, UART i wyjść czasowych;
• wystarczająca pamięć RAM na bufory sensorów, stosy zadań i estymator;
• pamięć programu na firmware, bootloader i mechanizm bezpiecznej aktualizacji;
• FPU i instrukcje DSP, jeżeli stos wykonuje intensywną filtrację oraz estymację;
• kilka niezależnych kontrolerów SPI/UART/CAN, aby rozdzielić domeny awarii;
• watchdog sprzętowy i wiarygodne źródło informacji o przyczynie resetu.

Cache procesora przyspiesza średni czas obliczeń, lecz może zwiększyć rozrzut czasu najgorszego przypadku. DMA redukuje obciążenie rdzenia, ale w MCU z cache wymaga poprawnego zarządzania spójnością pamięci. Dlatego „więcej MHz” nie zastępuje pomiaru deadline'ów na docelowej płytce.

Sensory wbudowane i zewnętrzne#

Wbudowana IMU ma krótkie połączenie i wspólny zegar systemowy, lecz dzieli temperaturę, drgania i zakłócenia płytki. Zewnętrzny magnetometr umieszczony przy antenie GNSS może być dalej od przewodów silnikowych. Zewnętrzny barometr albo moduł air-data może mieć lepszą ekspozycję na mierzone ciśnienie. Sensory na DroneCAN mogą zawierać własne znaczniki czasu i diagnostykę węzła, ale dodają opóźnienie sieciowe oraz kolejne zasilanie.

Kilka IMU nie oznacza automatycznie redundancji. Dwa identyczne układy na tej samej płytce mogą jednocześnie ucierpieć od rezonansu, przegrzania, błędu wspólnego sterownika, uszkodzenia jednej szyny 3,3 V albo przerwy wspólnej magistrali. Więcej o separacji i głosowaniu opisuje redundancja sensorów.

Rozruch i maszyna stanów#

FC nie powinien po prostu rozpocząć generowania sygnałów wykonawczych zaraz po resecie. Rozruch jest sekwencją kontrolowanych przejść:

brak zasilania
     ↓
reset / bezpieczny stan pinów
     ↓
bootloader → weryfikacja obrazu → start firmware
     ↓
inicjalizacja zegarów, pamięci, magistral i sterowników
     ↓
autotest + kalibracje + wykrycie konfiguracji
     ↓
DISARMED / PRE-ARM
     ↓  wszystkie wymagane warunki spełnione
ARMED → lot / praca aktuatorów
  │
  ├→ degradacja trybu
  ├→ failsafe
  └→ disarm po bezpiecznym zakończeniu

Po resecie wyjścia muszą mieć stan elektrycznie bezpieczny jeszcze zanim firmware ustawi GPIO. Oznacza to właściwe rezystory pull-up/pull-down, zachowanie buforów i uwzględnienie pinów, które podczas bootowania pełnią funkcje specjalne. Jeśli bootloader trwa sekundę, nie może przez tę sekundę emitować przypadkowych impulsów przypominających polecenie dla serwa.

Testy przed uzbrojeniem powinny oceniać co najmniej: zgodność typu platformy i geometrii, stan kalibracji, orientację FC, zdrowie wymaganych sensorów, jakość estymatora, konfigurację wyjść, napięcie i energię, stan łącza sterującego oraz obecność krytycznych błędów. Konkretny zestaw zależy od trybu — lot attitude bez GNSS nie ma tych samych wymagań co misja pozycyjna.

Obejście kontroli pre-arm nie naprawia przyczyny. Zamienia błąd wykryty na ziemi w błąd aktywny po uruchomieniu aktuatorów.

Czas rzeczywisty: ważniejszy od średniej częstotliwości#

Określenie „pętla 1 kHz” jest niepełne. Trzeba wiedzieć:

• z jaką częstotliwością sensor fizycznie wykonuje konwersję — ODR;
• kiedy próbka trafia do rejestru lub FIFO;
• kiedy sterownik ją odbiera i jak wyznacza chwilę pomiaru;
• jak długo trwa filtracja i estymacja;
• kiedy regulator oblicza wyjście;
• kiedy ramka dociera do ESC;
• jaka jest dynamika samego napędu lub serwa.

Jeżeli IMU dostarcza nową próbkę co 1 ms, ośmiokrotne wykonanie regulatora na tej samej wartości nie tworzy ośmiu razy większej informacji. Może jedynie zwiększyć obciążenie i ukryć błędną synchronizację.

Opóźnienie, jitter i wiek danych#

Opóźnienie jest czasem od zdarzenia fizycznego do reakcji aktuatora. Jitter to zmienność czasu wykonania lub okresu. Wiek danych mówi, jak stara była użyta próbka w chwili obliczenia. Są to osobne wielkości.

Przykładowo sterownik może wykonywać się dokładnie co 1 ms, ale zawsze używać próbki GNSS opóźnionej o 180 ms. Ma mały jitter i duże opóźnienie. Inny może mieć średni okres 250 µs, lecz sporadycznie blokować się na 2 ms podczas zapisu flash — średnia wygląda dobrze, deadline nie.

Przy częstotliwości zakłócenia f czyste opóźnienie T wnosi w przybliżeniu przesunięcie fazy:

φ = -2π f T

Dla f = 50 Hz każde dodatkowe 1 ms oznacza około 18° opóźnienia fazowego. To pokazuje, dlaczego agresywna filtracja może uspokoić wykres szumu, a jednocześnie pogorszyć margines stabilności.

Architektura wyzwalana danymi#

Sterownik IMU może używać przerwania data-ready, odczytu przez DMA i kolejki z timestampem. Po zakończeniu transferu publikuje próbkę, która wyzwala filtrację oraz regulator. Wolniejsze zadania — barometr, GNSS, telemetria, zapis logu — pracują we własnych domenach czasu.

W systemie z RTOS albo work queues priorytet nie oznacza automatycznie poprawności. Długie zadanie na wspólnej kolejce może zablokować kolejne. Przerwanie o zbyt wysokim priorytecie może zagłodzić pętlę sterowania. Szczegółowe podejście do budżetów czasu, WCET i deadline'ów opisuje harmonogram czasu rzeczywistego FC.

Przykładowy budżet cyklu#

Poniższe liczby są ilustracją metody, nie uniwersalną specyfikacją:

Budżet musi być sprawdzony pomiarem na firmware produkcyjnym, z włączonym logowaniem i wszystkimi interfejsami. Profilowanie wersji „odchudzonej” nie dowodzi dotrzymania czasu w locie.

Układy współrzędnych i znaki#

Wiele pozornych problemów PID jest w rzeczywistości błędem osi. Kontroler jednocześnie operuje w kilku układach:

• sensor frame — osie nadrukowane lub zdefiniowane przez producenta sensora;
• body frame — osie związane z kadłubem;
• navigation frame — np. NED albo ENU;
• actuator frame — geometria ramion, zawiasów i kierunków ciągu;
• camera/payload frame — często z inną orientacją i przesunięciem względem IMU.

Orientacja sensora jest transformowana do body frame, a estymator wiąże body frame z ramą nawigacyjną. Ten sam kwaternion może opisywać obrót „body względem navigation” albo transformację w przeciwnym kierunku; zapis musi podawać konwencję. Podobnie dodatni yaw w NED i ENU nie powinien być zgadywany po nazwie zmiennej.

Test znaków wykonuje się dla całego toru:

1. wskazać fizycznie dodatni zwrot osi na kadłubie;
2. obrócić statek ręcznie w tę stronę i sprawdzić znak żyroskopu;
3. sprawdzić zmianę estymowanej orientacji;
4. wymusić mały dodatni setpoint i potwierdzić znak regulatora;
5. sprawdzić, czy alokator zmienia aktuatory tak, aby wytworzyć moment przeciwdziałający błędowi.

Sama poprawna animacja modelu w GCS nie gwarantuje poprawności ostatniego kroku. Zamieniona kolejność silników może pozostawić estymację idealną i przewrócić platformę natychmiast po wzroście ciągu.

Tor sensorów: od MEMS do próbki#

IMU jako szybki zmysł kontrolera#

IMU łączy co najmniej trójosiowy żyroskop i trójosiowy akcelerometr. Żyroskop jest podstawowym sprzężeniem szybkiej pętli prędkości kątowej. Akcelerometr mierzy siłę właściwą: w spoczynku reaguje na podparcie przeciwne grawitacji, a w locie zawiera jednocześnie składowe ruchu translacyjnego, drgań i grawitacji wyrażonej w osi kadłuba.

Nie wolno więc w manewrze interpretować wektora akcelerometru jako czystego „kierunku do dołu”. Estymator wykorzystuje dynamikę, model niepewności i inne źródła. Magnetometr dostarcza odniesienia kursowego, ale jest wrażliwy na pole przewodów, silników i elementów ferromagnetycznych. Barometr obserwuje zmianę ciśnienia, a nie odległość od gruntu. GNSS dostarcza pozycję, prędkość i czas z opóźnieniem większym niż IMU.

Co robi sterownik sensora#

Sterownik powinien:

• odczytać i zweryfikować identyfikator układu;
• ustawić zakres, ODR, filtry i zachowanie FIFO;
• związać przerwanie data-ready z zegarem FC;
• wykrywać przepełnienie FIFO, błędy magistrali i przerwy w sekwencji;
• przeliczyć surowy kod na jednostkę fizyczną;
• zastosować właściwą macierz orientacji oraz kalibrację;
• publikować próbkę z czasem pomiaru i statusem jakości;
• zgłaszać temperaturę i liczniki błędów.

Używanie „ostatniej poprawnej próbki” bez limitu wieku tworzy ukryte zawieszenie sensora: regulator nadal otrzymuje liczby, ale nie opisują one aktualnego ruchu. Wiek danych musi być warunkiem zdrowia.

Kalibracja nie jest jedną liczbą offsetu#

Dla trójosiowego sensora ogólny model pierwszego rzędu można zapisać:

y = M · (x_raw - b(T))

gdzie b(T) jest zależnym od temperatury biasem, a macierz M zawiera współczynniki skali, nieortogonalność osi i transformację montażową. Dla żyroskopu ważny jest bias w spoczynku i jego zmiana z temperaturą. Dla akcelerometru potrzebne są skala i geometria osi. Magnetometr wymaga kompensacji hard-iron i soft-iron, najlepiej po zamontowaniu całej instalacji.

Kalibracja przy nierozgrzanym FC może być poprawna przez pierwszą minutę i błędna po ustaleniu temperatury. Kalibracja wykonana na stole nie obejmuje pola powstającego przy dużym prądzie napędu. Dlatego parametry fabryczne, kalibracja użytkownika i kompensacja w locie rozwiązują różne klasy błędów.

Filtracja: mniej szumu za cenę opóźnienia#

Tor filtracji zaczyna się przed ADC lub wewnątrz sensora. Jeżeli energia drgań powyżej połowy częstotliwości próbkowania zostanie spróbkowana bez dostatecznego tłumienia, pojawi się jako alias w niższym paśmie. Filtr cyfrowy po aliasingu nie wie, że sygnał ma fałszywą częstotliwość.

Typowy tor żyroskopu może zawierać:

1. filtr analogowy lub wewnętrzny filtr MEMS;
2. próbkowanie z określonym ODR;
3. decymację lub integrację próbek z FIFO;
4. statyczny low-pass;
5. notch dla znanego rezonansu;
6. dynamiczny notch albo filtr śledzący RPM;
7. osobny filtr toru pochodnej regulatora.

Każdy filtr zmniejsza część szumu, ale wnosi opóźnienie i może tłumić rzeczywisty ruch. Celem nie jest najgładszy wykres, lecz dostateczny stosunek sygnału do szumu przy zachowaniu pasma i marginesu fazy. Jeśli źródłem problemu jest luźne ramię, uszkodzone łożysko albo źle wyważone śmigło, dokładanie kolejnych filtrów maskuje usterkę mechaniczną.

Telemetria RPM może pomóc śledzić harmoniczne napędu, lecz sama jest strumieniem danych z opóźnieniem i możliwymi brakami. Utrata pojedynczej ramki nie powinna zatrzymywać stabilizacji. Filtr musi mieć zdefiniowane zachowanie przy danych nieświeżych.

Estymacja stanu: czego nie można zmierzyć bezpośrednio#

Regulator potrzebuje spójnego stanu, nie kolekcji surowych odczytów. Najprostszy AHRS integruje żyroskop i powoli koryguje przechylenie oraz pochylenie na podstawie akcelerometru. Autopilot nawigacyjny utrzymuje znacznie większy wektor stanu.

Przykładowe elementy to:

• orientacja jako kwaternion;
• prędkość w ramie nawigacyjnej;
• pozycja globalna i lokalna;
• bias żyroskopu i akcelerometru;
• składowe ziemskiego pola magnetycznego i zakłócenia pokładowe;
• wiatr;
• wysokość terenu albo offsety wybranych sensorów.

Predykcja i korekta#

IMU służy do szybkiej predykcji ruchu. Z powodu biasów integracja dryfuje. Wolniejsze obserwacje — GNSS, barometr, magnetometr, optical flow, VIO, dalmierz — korygują stan i ograniczają dryf.

W EKF każda korekta wytwarza innowację, czyli różnicę między obserwacją a tym, czego filtr spodziewał się na podstawie stanu i modelu. Innowacja bez jej wariancji jest niepełna. Ta sama różnica 2 m może być mała dla zaszumionego GNSS i ogromna dla precyzyjnego systemu motion capture.

Jeżeli test statystyczny odrzuca pomiar, kontroler powinien zalogować:

• wartość innowacji i jej wariancję;
• próg testu;
• źródło obserwacji;
• przyczynę odrzucenia;
• zmianę źródła albo reset stanu.

Bez tych danych nagły skok pozycji wygląda jak „błąd GPS”, choć przyczyną może być zły timestamp, błędny lever arm, niedoszacowany szum lub reset estymatora.

Opóźnione sensory#

Próbka GNSS opisuje stan z wcześniejszej chwili. Współczesny estymator może buforować IMU, korygować stan na opóźnionym horyzoncie fuzji, a następnie propagować wynik do czasu bieżącego. Proste „odjęcie stałej od timestampu” nie wystarcza, jeśli opóźnienie jest zmienne albo dotyczy tylko części toru.

Kamera może rejestrować ekspozycję w chwili t0, zakończyć ją w t1, przetworzyć obraz w t2, a wysłać pozycję w t3. Do fuzji potrzebna jest jasno zdefiniowana chwila pomiaru. Dotyczy to szczególnie visual odometry i komputera towarzyszącego.

Estymator attitude a estymator nawigacyjny#

Mały kontroler akrobacyjny może stabilizować rate bez pozycji, GNSS i rozbudowanego EKF. Autopilot fixed-wing może potrzebować prędkości powietrznej, wiatru i pozycji. VTOL w przejściu musi utrzymywać stan użyteczny dla dwóch różnych reżimów aerodynamicznych. Nie istnieje jeden minimalny zestaw sensorów dobry dla każdej platformy i każdego trybu.

Skąd bierze się wartość zadana#

FC nie steruje zawsze „do pozycji z drążka”. Znaczenie wejścia zależy od trybu:

Przejście między trybami musi być bezudarowe. Jeżeli regulator pozycji przejmuje sterowanie przy aktualnym przechyle 12°, jego początkowy setpoint i stany integratorów nie mogą wytworzyć sztucznego skoku. Podobnie utrata strumienia offboard nie może pozostawić ostatniego polecenia aktywnego bezterminowo.

Warstwa arbitrażu rozstrzyga, które źródło setpointu ma prawo sterować: RC, misja, failsafe, geofence, komputer towarzyszący czy procedura lądowania. Priorytety muszą być jawne, testowalne i widoczne w logu. „Ostatni zapis wygrywa” nie jest bezpieczną architekturą sterowania lotem.

Regulatory kaskadowe#

Wielowirnikowiec nie przechodzi zwykle bezpośrednio od błędu pozycji do wartości czterech silników. Sterowanie jest kaskadą:

pozycja zadana
      ↓
regulator pozycji → prędkość zadana
      ↓
regulator prędkości → przyspieszenie / ciąg i attitude zadane
      ↓
regulator attitude → prędkość kątowa zadana
      ↓
regulator rate → momenty roll/pitch/yaw
      ↓
alokator → silniki / serwa

Pętla wewnętrzna musi być wyraźnie szybsza niż zewnętrzna. Jeśli rate nie śledzi poleceń, regulator pozycji widzi statek o innej dynamice niż zakładana. Zwiększanie wzmocnienia pozycji nie naprawi wolnej lub nasyconej pętli wewnętrznej.

Pętla rate#

Pętla prędkości kątowej używa żyroskopu i zazwyczaj ma największe pasmo. Uproszczona postać regulatora:

e = ω_setpoint - ω_measured

u = Kp·e + Ki·∫e dt + Kd·de/dt + Kff·ω_setpoint

Implementacja praktyczna różni się od szkolnego wzoru. Pochodna może być liczona z pomiaru, aby uniknąć derivative kick; tor D jest filtrowany; integrator ma ograniczenia i mechanizm anti-windup; feedforward poprawia odpowiedź na celowe ruchy bez oczekiwania na błąd. Szczegółowo opisuje to artykuł PID w kontrolerze lotu.

Pętla attitude#

Regulator orientacji porównuje żądaną i estymowaną orientację. Przy kwaternionach błąd powinien respektować geometrię obrotów, a nie tylko odejmować kąty Eulera w pobliżu osobliwości. Wynikiem jest zwykle zadana prędkość kątowa ograniczona do możliwości platformy.

Pętle prędkości i pozycji#

Regulator pozycji generuje żądaną prędkość, a regulator prędkości — żądane przyspieszenie lub wektor ciągu. Ograniczenia prędkości, przyspieszenia, jerk i przechylenia są częścią sterownika trajektorii. Bez nich nagły skok waypointu może żądać fizycznie niemożliwej reakcji i natychmiast nasycić wewnętrzne pętle.

Fixed-wing i VTOL#

W samolocie powierzchnie sterowe wytwarzają moment zależny od prędkości powietrza. Gaz i pochylenie są sprzężone z energią potencjalną oraz kinetyczną. Ten sam sygnał serwa ma inny efekt blisko przeciągnięcia niż w szybkim locie. Dlatego autopilot fixed-wing korzysta z harmonogramowania wzmocnień, ograniczeń kąta natarcia lub systemów zarządzania energią.

VTOL potrzebuje dodatkowo logiki przejścia. W zawisie dominuje alokacja wirników, w locie postępowym — aerodynamika skrzydła i sterów, a w przejściu oba zestawy aktuatorów mogą współpracować. Przełączenie nie może zerwać ciągłości setpointów ani estymacji.

Mikser i alokacja sterowania#

Regulator rate nie powinien wiedzieć, że silnik 1 leży z przodu po prawej. Generuje żądany wektor:

v = [Fz, Mx, My, Mz]ᵀ

Alokator używa geometrii i modelu skuteczności aktuatorów:

v = B · u

B jest macierzą efektywności, a u wektorem zadań aktuatorów. Dla prostego quada może istnieć rozwiązanie analityczne. Dla hexacoptera, platformy z pochylanymi silnikami albo układu z uszkodzonym aktuatorem potrzebna jest alokacja z ograniczeniami.

Nasycenie jest normalnym stanem, nie wyjątkiem#

Silnik nie może zejść poniżej minimalnej stabilnej prędkości ani przekroczyć maksimum wynikającego z napięcia, ESC i śmigła. Serwo ma ograniczenie pozycji, prędkości i momentu. Kiedy żądanie jest niewykonalne, alokator musi ustalić priorytety.

Przykładowo w quadzie przy maksymalnym ciągu nie ma już rezerwy na zwiększenie dwóch silników dla roll. Można zmniejszyć ciąg wspólny i odzyskać authority momentu, ograniczyć yaw albo proporcjonalnie przeskalować wszystkie osie. Każda strategia zmienia zachowanie platformy.

Regulator powinien wiedzieć, że jego żądanie zostało ograniczone. W przeciwnym razie integrator narasta, choć aktuator nie może zrealizować komendy. Po wyjściu z saturacji zgromadzona wartość powoduje odbicie — klasyczny windup.

Awaria aktuatora#

W platformie nadmiarowej alokator może przeliczyć sterowanie po utracie silnika, ale tylko w granicach pozostałej authority. Sam fakt posiadania sześciu lub ośmiu silników nie gwarantuje kontrolowalności każdego przypadku. Liczą się geometria, kierunki obrotu, zapas ciągu, przesunięcie środka masy i zdolność estymatora do rozpoznania awarii.

W quadzie bez zmiennego skoku pełna kontrola czterech stopni swobody po utracie jednego silnika zwykle nie jest możliwa w zwykłym modelu. Algorytm może zaakceptować obrót yaw i próbować zachować część kontroli translacyjnej, ale jest to inny reżim, wymagający osobnego projektu i walidacji.

Wyjścia: od wartości znormalizowanej do aktuatora#

Po alokacji wartość przechodzi przez ograniczenia, mapowanie funkcji na kanał i sterownik sprzętowy.

DShot wykrywa część błędów transmisji i usuwa niejednoznaczność szerokości impulsu, ale nie potwierdza, że silnik osiągnął zadaną prędkość. Ramka może być poprawna, a ESC może ograniczać prąd, przegrzewać się albo utracić synchronizację z wirnikiem.

Telemetria ESC — RPM, prąd, napięcie, temperatura, status — zamyka dodatkową pętlę diagnostyczną. W systemie zaawansowanym może też wspierać sterowanie prędkością wirnika. Dane telemetryczne muszą mieć status świeżości tak samo jak sensory nawigacyjne.

Serwa różnią się od napędu wielowirnikowca. Zadanie pozycji nie mówi, czy orczyk rzeczywiście osiągnął cel ani czy zawias nie jest zablokowany. Bez sprzężenia pozycji/prądu FC widzi jedynie wysłany impuls. Opóźnienie, martwa strefa, backlash i ograniczenie szybkości powinny być uwzględnione w projekcie serw dla UAV.

Zasilanie i integralność elektryczna#

Kontroler może wykonywać idealny algorytm i resetować się przy każdym gwałtownym ruchu gazu. Zasilanie FC jest częścią pętli sterowania.

Typowe źródła problemów:

• spadek napięcia BEC podczas impulsu prądu odbiornika, modemu lub serwa;
• przepięcia i ground bounce od przełączania ESC;
• zbyt mały kondensator przy wejściu lub długi przewód zasilający;
• pętla masy między komputerem, telemetrią, wideo i autopilotem;
• wsteczne zasilanie przez USB albo pin sygnałowy;
• niekontrolowane przełączenie między dwoma źródłami;
• nagrzanie stabilizatora zwiększające spadek napięcia;
• zwarcie peryferium wyłączające wspólną szynę sensorów.

Średni prąd zmierzony multimetrem nie pokazuje krótkiego impulsu. Potrzebny jest pomiar oscyloskopem w punkcie obciążenia, z pasmem pozwalającym zobaczyć transient. Minimalne napięcie, czas poniżej progu brownout i zachowanie resetu są ważniejsze niż sama średnia.

Rozbudowana architektura zasilania FC może używać dwóch wejść, ideal-diode/power mux, osobnych regulatorów dla sensorów i peryferiów oraz pomiaru napięcia za elementem przełączającym. Redundancja zasilania nie istnieje, jeśli oba wejścia korzystają z jednego BEC albo wspólnego złącza o pojedynczym styku masy.

EMC, PCB i montaż#

IMU umieszcza się z dala od cewek przetwornic, gorących stabilizatorów i przewodów fazowych. Magistrala SPI powinna mieć krótką drogę z ciągłą referencją masy. Kondensator odsprzęgający działa zgodnie z impedancją pętli prądu, nie zgodnie z tym, czy znajduje się „gdzieś obok” na schemacie.

Mechaniczna izolacja jest filtrem o własnej częstotliwości rezonansowej. Zbyt miękkie mocowanie może pozwolić płytce kołysać się względem kadłuba i dodać opóźnienie. Zbyt twarde przenosi harmoniczne silników. Dobór powinien wynikać z widma drgań i masy modułu. Osobne artykuły omawiają PCB flight controllera, EMC/EMI i montaż FC.

Łączność wewnątrz systemu#

Kontroler łączy różne klasy interfejsów:

• szybkie, lokalne SPI do IMU;
• I²C do wolniejszych sensorów na krótkiej magistrali;
• UART do GNSS, odbiornika RC i telemetrii;
• CAN do rozproszonych urządzeń z arbitrażem oraz diagnostyką;
• USB/Ethernet do konfiguracji, aktualizacji i szybkich danych;
• analogowe wejścia napięcia, prądu lub RSSI;
• timery do PWM/DShot i pomiaru impulsów.

Szybkość nominalna magistrali nie jest jej przepustowością użytkową. Transfer ma narzut protokołu, przerwy, arbitraż i czas obsługi. Współdzielona I²C może zostać zablokowana przez urządzenie trzymające SDA. UART bez kontroli przepływu może przepełnić bufor. CAN zachowuje się przewidywalnie tylko przy poprawnej terminacji, długości odgałęzień i obciążeniu.

MAVLink jest protokołem wymiany wiadomości, nie algorytmem stabilizacji ani gwarancją transportu. Komunikat może przejść przez UART, USB, UDP lub radio. Krytyczny odbiorca powinien sprawdzać identyfikator systemu/komponentu, typ komunikatu, kolejność, timeout i semantykę układu współrzędnych. Sam poprawny CRC ramki nie dowodzi, że setpoint jest aktualny i uprawniony.

Bezpieczeństwo funkcjonalne i odporność na awarie#

FC działa poprawnie nie tylko wtedy, gdy wszystkie dane są idealne, lecz także wtedy, gdy rozpoznaje granice własnej wiedzy.

Zdrowie jest wektorem, nie jedną flagą#

Przydatny model zdrowia sensora obejmuje:

• obecność i poprawną inicjalizację;
• świeżość próbki;
• ciągłość numerów/znaczników czasu;
• błędy magistrali i przepełnienia;
• zakres fizyczny i nasycenie;
• zgodność z drugim sensorem lub modelem;
• temperaturę;
• wynik testów innowacji estymatora.

Sensor może odpowiadać na SPI i jednocześnie podawać zamrożoną wartość. Może też podawać zmienną wartość, która jest fizycznie niemożliwa. Flaga „device present” nie wystarcza.

Watchdog#

Watchdog powinien wykrywać brak postępu krytycznego systemu, a nie jedynie to, że jedno przerwanie nadal się wykonuje. Poprawny wzorzec agreguje potwierdzenia z pętli sensorów, estymatora i sterowania:

bool healthy_cycle = imu_fresh
                  && estimator_advanced
                  && control_deadline_ok
                  && actuator_pipeline_alive;

if (healthy_cycle) {
    watchdog_kick();
}

Po resecie trzeba zachować przyczynę, licznik restartów i ostatni stan. Automatyczny restart bez informacji może stworzyć cykl reset–uzbrojenie–reset. Polityka ponownego wejścia do lotu zależy od platformy i nie może wynikać wyłącznie z faktu, że MCU ponownie działa.

Failsafe jako maszyna stanów#

Failsafe nie jest jedną komendą „wróć do domu”. Zależy od wykrytej awarii, dostępnych sensorów, fazy lotu, energii i przestrzeni. Utrata RC przy zdrowym GNSS jest innym przypadkiem niż utrata GNSS, błąd estymatora albo niski poziom energii.

Przejścia powinny mieć:

• jednoznaczny warunek wejścia i histerezę;
• timeout oraz warunek odzyskania;
• priorytet względem innych awarii;
• wymagania sensorowe trybu docelowego;
• obserwowalny powód w logu i telemetrii;
• zachowanie przy nakładających się zdarzeniach.

Jeżeli GNSS jest niewiarygodny, failsafe zależny od pozycji GNSS nie staje się bezpieczny tylko dlatego, że nazywa się RTL. Projektowanie takich przejść omawia failsafe jako maszyna stanów.

Redundancja i przyczyny wspólne#

Redundancję należy rozpatrywać jako ścieżkę:

sensor → magistrala → zasilanie → sterownik → estymator → decyzja wyboru

Dwa sensory na dwóch magistralach mogą nadal używać tego samego regulatora. Dwa regulatory mogą być zasilane przez jeden filtr. Dwie jednostki obliczeniowe mogą uruchamiać ten sam błędny firmware. Dodatkowy element poprawia niezawodność tylko względem awarii, które rzeczywiście rozdziela.

Logowanie i obserwowalność#

Kontroler, którego decyzji nie da się odtworzyć, jest trudny do strojenia i jeszcze trudniejszy do certyfikowania. Blackbox powinien rejestrować nie tylko końcową pozycję.

Minimalny zestaw do analizy szybkiej pętli:

• czas cyklu, dt, jitter i przekroczenia deadline;
• surowe i filtrowane gyro/accel;
• setpoint rate i pomiar rate;
• składowe P, I, D i feedforward;
• żądane momenty/ciąg przed alokacją;
• wyjścia po alokacji i flagi saturacji;
• RPM lub status ESC, jeżeli dostępny.

Dla nawigacji potrzebne są również:

• źródła fuzji i ich timestampy;
• stan estymatora, biasy i niepewności;
• innowacje, wariancje, progi i odrzucenia;
• resety stanu i zmiany źródeł;
• wybrany tryb, źródło setpointu i przyczyna przejścia;
• zdarzenia failsafe, zdrowie sensorów i energię.

Log musi mieć wspólną podstawę czasu. Zestawienie gyro z zegara MCU i GNSS z czasu odbioru ramki bez przeliczenia timestampów może przesunąć sygnały i zasugerować nieistniejącą przyczynowość.

Jak rozdzielać klasy problemów#

Jak różnią się popularne stosy firmware#

Nie istnieje jeden „najlepszy firmware”. Ich architektury są zoptymalizowane pod różne platformy.

W Betaflight model „main loop” jest szczególnie widoczny w formacie Blackbox. PX4 rozdziela moduły i komunikuje je przez uORB; tempo wielu modułów wynika z publikacji nowych danych. ArduPilot korzysta z własnego schedulera i wspólnych bibliotek dla wielu klas pojazdów. Różnice w kodzie nie zmieniają fizyki pętli, ale zmieniają miejsca konfiguracji, obserwowalność i sposób izolowania awarii.

Przed wyborem warto przeczytać osobne wprowadzenia do Betaflight, ArduPilot i PX4.

Jak dobrać kontroler do projektu#

Dobór zaczyna się od wymagań systemu, nie od tabeli MCU.

1. Klasa platformy i firmware#

Sprawdź, czy firmware obsługuje konkretną geometrię, liczbę aktuatorów, tryby i sensory. „Da się wgrać” nie oznacza, że wszystkie funkcje mają dojrzałe sterowniki i walidację dla tej płytki.

2. Wejścia i wyjścia#

Policz UART, CAN, SPI/I²C, wejścia analogowe, wyjścia timerowe i wymagane poziomy napięć. Zrób tabelę konfliktów pinów. Osiem padów opisanych „motor” nie gwarantuje ośmiu niezależnych wyjść o dowolnym protokole.

3. Sensory i ich rozmieszczenie#

Ważniejsze od liczby IMU są ich modele, magistrale, zakresy, orientacja, izolacja i wsparcie sterownika. Dla fixed-wing sprawdź barometr, wejście airspeed i możliwość zewnętrznego magnetometru. Dla platformy o wysokich wibracjach oceń mechanikę montażu.

4. Zasilanie#

Ustal napięcie wejściowe, dopuszczalne źródła, pobór peryferiów, pomiar prądu, ochronę przed odwrotną polaryzacją i zachowanie przy zaniku. Nie zakładaj, że złącze „5 V” może zasilić modem, serwa i komputer.

5. Pamięć i diagnostyka#

Karta SD daje pojemność, lecz może mieć zmienne opóźnienia. Flash ma ograniczoną trwałość. Sprawdź, czy log zawiera potrzebne częstotliwości i czy pamięć wystarczy na najgorszą misję. Brak miejsca na logi zwiększa koszt każdej awarii.

6. Odporność i utrzymanie#

Liczą się złącza z blokadą, dokumentacja schematu, dostępność plików pinout, wersjonowanie hardware, bootloader recovery, aktywne wsparcie firmware i możliwość odtworzenia konfiguracji. Płytka bez jednoznacznej rewizji utrudnia produkcję seryjną.

7. Środowisko#

Temperatura, wilgotność, kondensacja, ciśnienie, pył, wibracje i EMI powinny odpowiadać profilowi misji. Specyfikacja samego MCU nie jest specyfikacją gotowej płytki. Zakres konsumencki elementu może nie obejmować nagrzanego wnętrza kadłuba w słońcu.

Macierz decyzji#

Uruchomienie nowej platformy#

Pierwszy lot nie może być pierwszym testem orientacji, kolejności silników, failsafe ani brownoutu.

Etap 1 — kontrola bez zasilania#

• porównaj schemat połączeń z pinoutem dokładnej rewizji płytki;
• sprawdź ciągłość masy i brak zwarć na szynach;
• zweryfikuj polaryzację oraz napięcia dopuszczalne dla każdego złącza;
• zapisz modele sensorów, ESC, odbiornika i wersje firmware;
• udokumentuj kolejność silników/serw oraz kierunki fizyczne.

Etap 2 — pierwsze zasilanie z ograniczeniem prądowym#

Zasil FC bez śmigieł i odłączonych dużych obciążeń. Zmierz wszystkie szyny, pobór i temperaturę. Sprawdź, czy USB nie zasila wstecznie reszty instalacji. Wykonaj kilka kontrolowanych odłączeń zasilania i potwierdź, że system wraca do DISARMED z zachowaną przyczyną resetu.

Etap 3 — sensory i układy osi#

• potwierdź model każdego wykrytego sensora;
• sprawdź osie gyro/accel przez ręczny ruch;
• porównaj barometr z warunkami otoczenia;
• sprawdź kompas z wyłączonym i włączonym obciążeniem elektrycznym;
• oceń czas uzyskania GNSS, prędkość raportowania i timestamp;
• rozgrzej urządzenie i obserwuj bias oraz temperaturę.

Etap 4 — wejścia i tryby#

Sprawdź zakresy kanałów RC, kierunki, deadband, timeout i failsafe odbiornika. Dla offboard zatrzymaj strumień setpointów i potwierdź oczekiwane przejście. Każde źródło sterowania testuj osobno, a potem w konflikcie z innym źródłem.

Etap 5 — aktuatory bez śmigieł lub z mechanicznie odłączonym napędem#

Zweryfikuj mapowanie funkcji na fizyczne wyjścia, kolejność, kierunki obrotu i reakcję na małe polecenie każdej osi. Nie ograniczaj się do testu „wszystkie silniki kręcą”. Dodatni moment roll musi tworzyć właściwą różnicę sił.

Etap 6 — testy programowe i symulacja#

W SITL/HIL sprawdź:

• zmianę trybów i bumpless transfer;
• utratę RC, GNSS, offboard i telemetrii;
• nieświeży sensor i skok timestampu;
• niskie napięcie oraz nakładające się failsafe;
• saturację aktuatorów;
• restart albo przeciążenie zadania;
• przerwanie i wznowienie misji.

Etap 7 — próba napędu i analiza logu#

Na zabezpieczonym stanowisku oceniaj prąd, drgania, RPM, temperaturę, błędy ESC i szyny FC. Dopiero log z działającym napędem pokazuje rzeczywiste zakłócenia magnetyczne i widmo wibracji.

Etap 8 — lot stopniowany#

Pierwszy lot powinien minimalizować energię i liczbę aktywnych funkcji. Najpierw stabilizacja podstawowa, następnie wysokość, pozycja i dopiero później misja. Po każdym etapie analizuj log, zamiast traktować brak wypadku jako zaliczenie testu.

Kryteria powinny być liczbowe: maksymalny jitter, dopuszczalny wiek próbki, udział czasu w saturacji, zakres drgań, minimalna rezerwa napięcia, czas wykrycia awarii i oczekiwany stan końcowy.

Najczęstsze błędne wyobrażenia#

„GNSS utrzymuje drona poziomo”#

Szybką stabilizację kątową zapewnia przede wszystkim żyroskop i pętla rate. GNSS koryguje wolniejszą pozycję oraz prędkość. Platforma może mieć stabilne attitude bez GNSS i niestabilną pozycję; może też mieć świetny fix GNSS i przewrócić się przez odwróconą oś silnika.

„Więcej Hz zawsze znaczy lepiej”#

Pętla szybsza od świeżych danych nie dodaje informacji. Zwiększa wymagania czasowe, może wymusić słabsze filtry albo ograniczyć logowanie. Liczy się pasmo zamkniętej pętli, opóźnienie i deterministyczność.

„DShot steruje fazami silnika”#

DShot przekazuje cyfrowe zadanie do ESC. Komutacja i pętla prądowa znajdują się w ESC. FC nie widzi rzeczywistego momentu bez dodatkowego sprzężenia.

„Dwie IMU rozwiązują problem awarii”#

Tylko wtedy, gdy istnieje sposób wykrycia rozbieżności i sensowna separacja przyczyn. Dwie IMU mogą zgodnie mierzyć tę samą wibrację albo utracić wspólne zasilanie.

„PID naprawi złą mechanikę”#

Regulator może odrzucać ograniczone zakłócenia. Nie naprawi luźnego śmigła, nasyconego napędu, przesuwającego się środka masy, elastycznego ramienia ani odwróconego serwa. Strojenie zaczyna się od sprawnej platformy.

„Failsafe to zawsze RTL”#

RTL wymaga wiarygodnej pozycji, wysokości, energii i trasy. Przy awarii jednego z tych założeń bezpieczniejszy stan może być inny. Failsafe jest polityką zależną od kontekstu.

„Jeśli lata, architektura jest poprawna”#

Lot w spokojnym powietrzu nie testuje deadline'ów, spadku napięcia, awarii sensora, saturacji, przejść trybu ani błędów wspólnej przyczyny. Poprawność wymaga testów granicznych i obserwowalnych kryteriów.

Model mentalny do zapamiętania#

Kontroler lotu można zrozumieć przez siedem pytań:

1. Co zmierzono? — wartość, jednostka, oś, czas i jakość.
2. Jaki jest stan? — estymacja wraz z niepewnością, nie pojedynczy sensor.
3. Jaki jest cel? — źródło setpointu, tryb i ograniczenia trajektorii.
4. Jakiego efektu potrzeba? — siła i moment wyliczone przez regulatory.
5. Jak wytworzą go aktuatory? — geometria, alokacja, limity i sprzężenie.
6. Czy system nadal spełnia założenia? — zdrowie, energia, deadline i redundancja.
7. Czy da się odtworzyć decyzję? — wspólny czas, logi, zdarzenia i konfiguracja.

Jeżeli na którekolwiek pytanie odpowiedź brzmi „firmware jakoś to robi”, właśnie tam znajduje się obszar wymagający dokumentacji albo testu.

Powiązane tematy#

• IMU w dronie — żyroskop, akcelerometr, błędy MEMS i próbkowanie.
• PID w kontrolerze lotu — pętle kaskadowe, anti-windup i strojenie.
• Filtr Kalmana w UAV — predykcja, korekta, kowariancja i innowacje.
• Mikser i alokacja sterowania — geometria, macierz efektywności i saturacja.
• Harmonogram czasu rzeczywistego FC — deadline, WCET, DMA i priorytety.
• Watchdog w flight controllerze — detekcja braku postępu i bezpieczny restart.
• Failsafe jako maszyna stanów — projektowanie przejść awaryjnych.
• Architektura zasilania FC — domeny, redundancja i brownout.
• Blackbox, pamięć i logowanie — obserwowalność i format danych.
• STM32 w flight controllerach — zasoby MCU i generacje sprzętu.
• PCB flight controllera — layout, sensory i integralność sygnałów.
• Montaż flight controllera — orientacja, izolacja i prowadzenie instalacji.
• Diagnostyka logów i wibracji — praktyczna analiza problemów.
• Symulacja SITL i HIL — testy przed uruchomieniem fizycznej platformy.

Przypisy#

1. PX4, Architectural Overview — modularny przepływ od sensorów i setpointów przez estymatory oraz regulatory do aktuatorów; uORB i różne częstotliwości modułów.
2. PX4, Controller Diagrams — architektura kaskadowa, tor żyroskopu, ograniczenie integratora i miejsce alokacji.
3. PX4, Control Allocation — oddzielenie żądanych sił/momentów od geometrii i fizycznych wyjść.
4. PX4, Using PX4's Navigation Filter EKF2 — wektor stanu, buforowanie opóźnionych obserwacji, innowacje i propagacja do czasu bieżącego.
5. ArduPilot, Copter Attitude Control — przepływ sterowania attitude/rate w stosie Copter.
6. ArduPilot, Pre-Arm Safety Checks — klasy kontroli wykonywanych przed uzbrojeniem.
7. ArduPilot, Failsafe — oddzielne mechanizmy reakcji na utratę RC/GCS, problemy baterii, EKF i inne zdarzenia.
8. Betaflight, Blackbox Logging Internals — związek rekordu logu z iteracją głównej pętli i sposób rejestracji czasu.
9. Pixhawk, Reference Standards oraz PX4, Reference Flight Controller Design — rozdzielenie standardu referencyjnego od konkretnego produktu i firmware.
10. Bosch Sensortec, BMI088 — dokumentacja 6-osiowej IMU projektowanej do środowisk o wysokich wibracjach.
11. TDK InvenSense, ICM-42688-P — parametry, FIFO i interfejsy współczesnej 6-osiowej IMU.
12. STMicroelectronics, STM32H743/753 documentation — timery, DMA, pamięć, cache i watchdog jako zasoby sprzętowe MCU.
13. Terry Kilby, Belinda Kilby, Make: Drony dla początkujących, rozdz. 4–7 — kontroler, IMU, ESC, GNSS, magnetometr, RC i telemetria.
14. Sumit Sharma, Drone Development from Concept to Flight, rozdziały o architekturze UAV, awionice i sensorach nawigacyjnych.
15. Ty Audronis, Drony. Wprowadzenie, s. 53–67 — sensory, procesor kontrolera, częstotliwość próbkowania i łańcuch elektryczny platformy.

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.PID w kontrolerze lotuRegulator PID bez metafor: postać dyskretna, ograniczenia, anti-windup, filtracja D, feedforward i rozpoznawanie problemów w logu.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.Mikser i alokacja sterowaniaPrzejście od żądanego ciągu i momentów do komend silników oraz serw: geometria, znaki, macierz B, pseudoodwrotność, ograniczenia, priorytety osi i diagnostyka authority.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.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.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.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ść.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.STM32 w flight controllerachPorównanie rodzin STM32 z perspektywy FC: magistrale, DMA, cache, TCM, timery, FPU, pamięć i pułapki deterministyczności.MAVLink — architektura protokołuDokumentacyjny opis MAVLink 2: format on-wire, system/component ID, CRC_EXTRA, podpisywanie oraz semantyka usług parametrów i misji.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. Sumit Sharma, „Drone Development from Concept to Flight” [książka]
2. Terry Kilby, Belinda Kilby, „Make: Drony dla początkujących” [książka]
3. Ty Audronis, „Drony. Wprowadzenie” [książka]
4. PX4 Architectural Overview [dokumentacja]
5. PX4: Controller Diagrams [dokumentacja projektu]
6. PX4: Using PX4 Navigation Filter EKF2 [dokumentacja projektu]
7. PX4 Guide: Control Allocation (Mixing) [dokumentacja projektu open source]
8. PX4 User Guide: Safety Configuration and Failsafes [dokumentacja projektu]
9. PX4 Guide: Reference Flight Controller Design [dokumentacja projektu]
10. ArduPilot: Copter Attitude Control [dokumentacja projektu]
11. ArduPilot Copter: Pre-Arm Safety Checks [dokumentacja projektu]
12. ArduPilot Copter: Failsafe [dokumentacja projektu]
13. Betaflight: Blackbox logging internals [dokumentacja projektu]
14. Bosch Sensortec: BMI088 [datasheet]
15. TDK InvenSense: ICM-42688-P [datasheet]
16. STMicroelectronics: STM32H743/753 documentation [producent]
17. MAVLink Protocol Overview [specyfikacja]