Własny flight controller: od Arduino do STM32

Dlaczego zaczynać od prostego kontrolera#

Arduino Uno lub Nano z MPU‑6050 nadal jest użyteczne jako stanowisko dydaktyczne. Kod mieści się w jednym obrazie mentalnym: odczyt sensora, filtr komplementarny, regulator i sygnał dla ESC. Taki układ pozwala zobaczyć wpływ czasu próbki, znaków osi i saturacji. Nie jest jednak współczesnym, niezawodnym autopilotem operacyjnym. Określenie „przestarzały” opisuje ograniczenia względem dzisiejszych FC, a nie brak wartości edukacyjnej ani niemożność stabilnego lotu prostej platformy.

Artykuł Payload.pl z 2020 roku trafnie rozdziela potrzebę lokalnej stabilizacji od sterowania nadrzędnego, ale miesza też kilka warstw. Pin Arduino nie „steruje silnikiem BLDC” w sensie komutacji i zasilania; przekazuje zadanie do ESC. Shield BLDC nie jest zwykłym wymaganiem flight controllera. Sześć lat w elektronice wbudowanej zmieniło dostępne płytki, modemy i oczekiwania wobec diagnostyki.

Drabina rozwoju#

UNO R4 używa mikrokontrolera Cortex‑M4, a Portenta H7 układu STM32H747. Nazwa Arduino opisuje ekosystem i warstwę narzędziową, nie jedną klasę wydajności. Równocześnie nawet mocna płytka deweloperska nie zapewnia właściwego zasilania, ochrony wejść, montażu IMU ani kontrolowanego stanu wyjść podczas resetu.

Trzy znaczenia „kontrolera na Arduino”#

Pierwsze oznacza gotową płytkę Uno/Nano i program napisany przez Arduino Core. Drugie — sam ATmega328P na własnej płytce, nadal programowany bootloaderem lub ISP. Trzecie — dowolny nowoczesny moduł obsługiwany przez Arduino IDE. Te konstrukcje mają różne timery, pamięć i charakterystyki czasu, więc nie można przenosić kodu wyłącznie dlatego, że wszystkie kompilują plik .ino.

Oficjalny UNO R3 ma 16 MHz, 32 KiB Flash, 2 KiB SRAM, 1 KiB EEPROM, sprzętowy UART, SPI, I²C, watchdog oraz trzy timery. Dokumentacja udostępnia schemat i pliki open hardware, więc płytę można odtworzyć albo zredukować do samego ATmega328P, zasilania, zegara, resetu, ISP i wymaganych złączy. Własny minimalny moduł jest lepszą lekcją elektroniki niż bezrefleksyjne użycie pełnego Uno.

Projekt odporny na zmianę dostępności części#

Odporność nie polega na wyszukaniu jednego „niekontrolowanego” komponentu. Polega na zmniejszeniu sprzężenia między algorytmem i konkretnym BOM-em:

• sterownik IMU wystawia próbkę w jednym formacie;
• warstwa czasu nie zależy od delay() ani przypadkowego timera biblioteki;
• mapa pinów i peryferiów jest osobnym plikiem;
• BOM zawiera funkcję, parametry graniczne i zweryfikowane zamienniki;
• test przyjęcia wykrywa błędny identyfikator, bias, pamięć i zegar;
• bootloader nie jest jedyną drogą programowania — pozostaje ISP/SWD.

Taka architektura pozwala użyć płytki ze zbiorów, nowego zamiennika albo własnego PCB. Nie usuwa obowiązku stosowania legalnych części i prowadzenia dokumentacji bezpieczeństwa.

Minimalna architektura laboratoryjna#

timer ─→ data-ready IMU ─→ SPI/DMA ─→ filtr ─→ estymacja
                                               ↓
RC/test setpoint ─→ ograniczenia ─→ PID ─→ mikser ─→ ESC emulator
                                               ↓
                                      log binarny / USB

Pierwsza wersja powinna sterować emulatorem ESC albo nieuzbrojonym stanowiskiem, nie latającą platformą. Wyjście można obserwować analizatorem logicznym. W ten sposób błędy znaku i harmonogramu nie obracają śmigłem.

void control_tick(void) {
    const uint32_t now = micros_monotonic();
    if (!imu_sample_is_fresh(now)) { enter_safe_state(); return; }
    const float dt = seconds_since(last_tick, now);
    attitude_update(&state, &imu, dt);
    rate_pid_update(&control, setpoint, state.gyro, dt);
    mixer_apply_limited(&outputs, control.torque, setpoint.thrust);
    log_enqueue(now, &state, &control, &outputs);
    last_tick = now;
}

To pseudokod dydaktyczny. Produkcyjna implementacja wymaga obsługi błędów zmiennoprzecinkowych, przepełnień czasu, watchdogów i atomowego przekazywania danych.

AVR kontra STM32#

AVR ma mało RAM, brak zaawansowanego DMA i ograniczoną liczbę timerów. Zmusza do prostoty, co jest zaletą edukacyjną. STM32 pozwala rozdzielić akwizycję, przetwarzanie i wyjścia, ale wprowadza cache, hierarchię magistral, priorytety przerwań i pułapki koherencji DMA. Większa moc obliczeniowa nie usuwa problemu deterministyczności.

Jeszcze bardziej skrajnym ćwiczeniem jest flight controller na rdzeniu 8051. Pokazuje on, które elementy są naprawdę konieczne i jak budżetować system bez FPU, DMA oraz dużej pamięci. Ścieżki 8051 → AVR → Cortex‑M nie należy traktować jako rankingu jakości, lecz jako serię eksperymentów o rosnącej złożoności.

Na Cortex‑M7 bufory DMA mogą wymagać umieszczenia w odpowiednim RAM i operacji cache. Funkcja działa w debuggerze, a gubi próbki przy pełnej optymalizacji — to typowy błąd architektoniczny, nie „niestabilny sensor”.

Bare metal czy RTOS#

Prosta pętla cykliczna jest czytelna i wystarcza do demonstratora. RTOS pomaga rozdzielić telemetrię, zapis i sterowniki, ale mutex w szybkim torze może wprowadzić nieograniczony czas blokady. Krytyczna pętla powinna wymieniać dane przez bufory o znanym czasie operacji, a logowanie działać asynchronicznie.

Stanowisko testowe#

Niezbędne przyrządy to zasilacz z ograniczeniem prądu, oscyloskop lub analizator logiczny, sztuczne obciążenie wyjść, możliwość rejestracji reset reason i fizyczny odłącznik energii. Testy obejmują:

• niepoprawny identyfikator IMU i zawieszoną magistralę;
• utratę kolejnych próbek oraz przepełnienie FIFO;
• restart podczas aktywnego wyjścia;
• spadek napięcia i impuls obciążenia modemu;
• NaN w estymatorze;
• brak postępu jednego zadania przy działającym timerze.

Projekty referencyjne#

dRehmFlight jest czytelnym projektem edukacyjnym dla Teensy i pozostaje aktywny. CodeDroneDIY dobrze pokazuje historyczny minimalizm Arduino, ale jego stan trzeba traktować jako materiał do nauki, nie aktualny produkt. bcflight pokazuje bardziej współczesny kierunek własnego stosu. Przed wykorzystaniem kodu należy sprawdzić licencję, wspieraną rewizję sprzętu i otwarte problemy; portal nie kopiuje obszernych fragmentów repozytoriów.

Kryterium przejścia do własnego PCB#

Własna płytka ma sens dopiero wtedy, gdy prototyp ma mierzalne wymagania: liczbę wejść i timerów, częstotliwość próbkowania, maksymalny jitter, zapotrzebowanie energetyczne, zakres temperatur i potrzebne interfejsy. „Mniejsza płytka” nie jest wystarczającą specyfikacją.

Pierwsza rewizja powinna udostępniać punkty pomiarowe szyn, SWD, osobne zasilanie sensorów i możliwość odłączenia peryferiów. Stan BOOT, reset i wszystkie wyjścia wykonawcze muszą być zdefiniowane rezystorami, zanim firmware zacznie działać.