ESP32 jako flight controller

ESP32 może pełnić funkcję kontrolera lotu, lecz „ESP32” jest nazwą rodziny, nie jednego układu. Klasyczny ESP32, ESP32-S3, S2, C3, C6 i kolejne warianty różnią się rdzeniami, pamięcią, peryferiami i obsługą radia. W tym artykule platformą referencyjną jest ESP32-S3: dwurdzeniowy SoC z rdzeniami Xtensa LX7, jednostką zmiennoprzecinkową, pamięcią wewnętrzną, zewnętrznym flash/PSRAM, Wi-Fi 2,4 GHz i Bluetooth LE.

ESP32-S3 ma więcej mocy obliczeniowej i pamięci niż proste AVR czy 8051, ale jego głównym problemem w roli flight controllera nie jest średnia wydajność. Jest nim przewidywalność: współdzielone cache, kod wykonywany z zewnętrznego flash, zadania systemowe Wi-Fi/BLE, FreeRTOS, dynamiczne skalowanie zegarów i okresy wyłączenia cache mogą zwiększać jitter. Poprawna architektura izoluje szybką pętlę lotu w IRAM/DRAM, używa DMA i sprzętowych peryferiów oraz traktuje radio jako usługę niekrytyczną.

Spis treści#

Który ESP32
Kiedy ESP32-S3 ma sens
Zasoby istotne dla flight controllera
Dwa rdzenie i FreeRTOS
FPU i obliczenia estymatora
IRAM, DRAM, flash i PSRAM
Cache jako źródło jittera
SPI i akwizycja IMU
MCPWM
RMT
DShot i wyjścia wykonawcze
TWAI i brak CAN-FD
UART, I2C i USB
Wi-Fi i Bluetooth LE
Proponowana architektura firmware
Priorytety i affinity zadań
Domena czasu i synchronizacja
Watchdogi
Brownout, boot i wyjścia
Bezpieczeństwo aktualizacji
PCB, moduł czy goły SoC
Minimalny projekt kontrolera
Program uruchomienia
Testy czasu rzeczywistego
Porównanie z RP2040 i STM32
Ograniczenia i decyzja
Powiązane tematy
Przypisy

Który ESP32#

Projekt powinien wskazać pełny target, rewizję krzemu, wariant pamięci i moduł. Kod skompilowany dla esp32s3 nie opisuje jeszcze hardware. Moduły WROOM i MINI różnią się rozmiarem, anteną, flash oraz PSRAM. Piny strapping, flash/PSRAM i USB mogą ograniczyć GPIO dostępne dla sensorów i aktuatorów.

ESP32-S3 ma dwa 32-bitowe rdzenie Xtensa LX7 taktowane do 240 MHz, 512 kB SRAM w układzie, pamięci RTC, sprzętowe wsparcie DSP/vector instructions oraz radio Wi-Fi/BLE. Zewnętrzny flash jest wymagany, a PSRAM opcjonalny. W odróżnieniu od klasycznego ESP32 układ S3 nie obsługuje Bluetooth Classic; ma Bluetooth LE.

Nie należy przenosić tabel pinów, liczby peryferiów ani workaroundów pomiędzy wariantami rodziny. Dokumentacja ESP-IDF ma wybór targetu i opisuje API dla konkretnego SoC. W repozytorium konfiguracja sdkconfig, tabela partycji, bootloader i target są częścią artefaktu.

Kiedy ESP32-S3 ma sens#

ESP32-S3 jest interesujący dla:

eksperymentalnego kontrolera lotu z własnym firmware;
małego UAV lub UGV z lokalnym interfejsem Wi-Fi/BLE do konfiguracji;
węzła telemetrycznego albo companion-lite;
kontrolera payloadu z prostą stabilizacją;
platformy laboratoryjnej do nauki FreeRTOS, DMA i estymacji;
redundantnego procesora komunikacyjnego przy osobnym FC;
kontrolera, w którym native USB i szyfrowany boot mają znaczenie.

Nie jest automatycznie dobrym wyborem dla pełnego autopilota ArduPilot/PX4. Główne projekty mają dojrzałe targety i sterowniki dla innych rodzin MCU, a samodzielny port to znacznie więcej niż kompilacja PID. Jeśli wymagane są liczne interfejsy CAN-FD, rozbudowana redundancja, wiele IMU i rygorystyczny WCET, STM32H7 lub inny MCU lotniczo-przemysłowy może być prostszy.

Najlepszy pierwszy cel to nie lot autonomiczny. To kontrolowany tor: IMU → attitude/rate → PID → cztery bezpieczne wyjścia, przetestowany w replay, HIL i na stanowisku.

Zasoby istotne dla flight controllera#

zasób ESP32-S3	zastosowanie i ograniczenie
2 × Xtensa LX7 do 240 MHz	separacja domeny lotu i usług; współdzielona pamięć/cache
FPU single precision	filtry orientacji i PID, lecz nadal trzeba mierzyć WCET
512 kB SRAM	kod IRAM, dane DRAM, bufory DMA i stosy
zewnętrzny SPI flash	firmware/XIP; zapis może wyłączać cache
opcjonalny PSRAM	duże bufory/logi; nie dla ścisłej pętli bez analizy latency
SPI2/SPI3 i GDMA	IMU, pamięć blackbox, inne szybkie sensory
3 UART	RC, GNSS i telemetria przy starannym przydziale
2 I²C	barometr, magnetometr, wolne sensory
2 jednostki MCPWM	serwa, capture, synchronizacja i fault/brake
RMT	precyzyjne ciągi impulsów, DShot/WS2812/odbiór timingowy
TWAI	klasyczny CAN 2.0; wymaga transceivera, bez CAN-FD data phase
USB OTG	konfiguracja, logi i serwis
Wi-Fi + BLE	łączność niekrytyczna, znaczące obciążenie RF/systemowe
watchdogi i brownout detector	wielowarstwowy nadzór oraz bezpieczny restart

Lista peryferiów nie dowodzi, że wszystkie można używać jednocześnie. GPIO matrix jest elastyczna, lecz wybrane sygnały mają ograniczenia, a piny flash/PSRAM/strapping są szczególne. Przydział zasobów powstaje przed schematem PCB.

Dwa rdzenie i FreeRTOS#

ESP-IDF używa FreeRTOS zmodyfikowanego dla architektury wielordzeniowej. Zadania mogą mieć affinity do rdzenia albo być uruchamiane przez scheduler na dostępnych rdzeniach. Dla kontrolera lotu swobodna migracja zadań zwiększa trudność analizy czasowej.

Praktyczny podział:

CPU1 / flight core:
  IMU completion → preprocess → estimator → rate/attitude PID → mixer

CPU0 / service core:
  RC, GNSS, telemetry, logging, CLI, Wi-Fi/BLE, parameters

hardware:
  SPI DMA, MCPWM/RMT/GDMA, watchdog, capture

Nie jest to absolutna reguła: stos Wi-Fi ma własne wymagania i historycznie wiele zadań systemowych jest przypiętych do określonego rdzenia. Wybór affinity trzeba sprawdzić dla wersji ESP-IDF. Ważny jest cel: flight task ma minimalną konkurencję i nie czeka na mutex trzymany przez usługę.

Komunikacja między domenami używa stałych, ograniczonych kolejek lub podwójnych buforów. Flight task pobiera najnowszy kompletny snapshot RC/parametrów z timestampem. Formatowanie JSON, DNS, sockety i zapis flash nigdy nie działają w tej samej sekcji krytycznej.

ISR powinien wykonać minimum: zapisać timestamp, potwierdzić przerwanie, przełączyć bufor i obudzić task. Estymator nie działa w ISR. Priorytet taska nie zastępuje priorytetu przerwania ani umieszczenia kodu w IRAM.

FPU i obliczenia estymatora#

Sprzętowa FPU single precision ułatwia implementację filtrów komplementarnych, Mahony/Madgwick, kwaternionów i małego EKF. Nie zwalnia z kontroli NaN, Inf, denormal i dzielenia przez wartość bliską zeru.

Budżet obliczeniowy rozdziela się:

filtrację i rate PID w częstotliwości IMU lub jej podziale;
attitude estimator wolniej, jeśli pozwala dynamika;
pozycję/prędkość znacznie wolniej niż gyro;
zadania nawigacyjne niezależnie od pętli wykonawczej;
telemetrię bez wpływu na deadline.

Instrukcje wektorowe ESP32-S3 mogą przyspieszyć wybrane operacje DSP, ale własne asemblerowe optymalizacje zwiększają koszt utrzymania. Najpierw profiluje się kod C/C++ z właściwymi flagami i IRAM, potem optymalizuje rzeczywiste hotspoty.

WCET mierzy się przy aktywnym radiu, cache miss, DMA i wszystkich taskach. Wynik benchmarku w izolacji nie jest dowodem dotrzymania terminów w locie.

IRAM, DRAM, flash i PSRAM#

ESP32-S3 rozróżnia pamięć wewnętrzną dostępną jako instrukcje/dane oraz zewnętrzny flash/PSRAM przechodzący przez cache. Kod funkcji może zostać oznaczony do umieszczenia w IRAM, a dane krytyczne w wewnętrznym DRAM.

Do IRAM/DRAM trafiają:

ISR data-ready IMU i zakończenia DMA;
krytyczne callbacki MCPWM/RMT;
funkcja timebase i output watchdog;
mały flight task oraz jego stałe aktywne;
bufory DMA i struktury synchronizacji;
kod wywoływany, gdy cache może być wyłączony.

Do flash/PSRAM mogą trafić:

UI, strony WWW i teksty diagnostyczne;
duże bufory niekrytycznych logów;
modele lub dane companionowe;
kod usług niewykonywany podczas cache-disabled;
archiwalne parametry, ale nie aktywny snapshot pętli.

DMA ma wymagania co do lokalizacji i wyrównania bufora. Nie każdy obszar PSRAM jest prawidłowym źródłem/celem każdego peryferium. API ESP-IDF oraz capabilities allocator muszą być używane świadomie.

Stosy flight task i ISR nie mogą zależeć od PSRAM. High-water marks są monitorowane, a dynamiczna alokacja po uzbrojeniu jest blokowana albo ściśle ograniczona.

Cache jako źródło jittera#

ESP-IDF dokumentuje, że operacje flash read/write/erase mogą czasowo wyłączyć cache. W tym czasie nie-IRAM-safe ISR są odroczone, a próba dostępu do kodu lub danych cache może wywołać błąd „cache disabled but cached memory region accessed”.

Konsekwencje:

parametrów nie zapisuje się do NVS w locie;
OTA nie działa podczas armed;
log do wewnętrznego flash jest buforowany i zapisywany po disarm;
wszystkie funkcje wywoływane z IRAM ISR także muszą być IRAM-safe;
stałe, tablice i callback context używane wtedy muszą być w pamięci wewnętrznej;
opcje CONFIG_*_ISR_IRAM_SAFE są częścią konfiguracji, nie domyślnym założeniem.

Samo oznaczenie funkcji IRAM_ATTR nie wystarcza, jeśli wywołuje funkcję z flash, logowanie albo odwołuje się do stałej w pamięci cache. Analiza map file i test wymuszonego cache-disable są obowiązkowe.

Najprostsza polityka produkcyjna: podczas armed zabronić każdej operacji erase/write flash, a flight domain utrzymać w pamięci wewnętrznej.

SPI i akwizycja IMU#

Główne IMU powinno korzystać z SPI z linią data-ready. Transakcja DMA minimalizuje obciążenie CPU i jitter.

IMU DRDY GPIO IRQ
      ↓ timestamp monotonic
SPI queued DMA → buffer A/B
      ↓ completion callback
validate status/counter → filtr → estimator

Timestamp dotyczy chwili próbki/DRDY, a nie czasu obudzenia taska. Przy FIFO IMU każda próbka dostaje odtworzony czas na podstawie ODR i numeru próbki. Przepełnienie FIFO jest błędem health.

ESP-IDF SPI master ma kolejki transakcji i DMA. Flight driver powinien prealokować descriptors oraz bufory. Nie używa malloc ani blokującej transmisji z nieograniczonym timeoutem. Magistrala dla IMU nie powinna być współdzielona z wolnym wyświetlaczem albo flash bez jawnego harmonogramu.

Drugie IMU może trafić na osobny host SPI, jeśli zasoby pozwalają. Redundancja sensorów na wspólnej szynie i wspólnym regulatorze nie chroni przed awarią tych elementów.

I²C pozostaje dla barometru/magnetometru. Zawieszona magistrala ma timeout i recovery; nie blokuje flight task.

MCPWM#

ESP32-S3 ma dwie grupy MCPWM. Każda grupa zawiera timery, operatory, komparatory, generatory, capture, synchronizację oraz fault/brake. To znacznie bogatszy blok niż prosty PWM.

Zastosowania:

impulsy serw o kontrolowanym okresie i szerokości;
wyjścia napędu wymagające wspólnej synchronizacji;
input capture sygnałów RC lub tachometru;
sprzętowy brake po zewnętrznym sygnale awarii;
pomiar okresu/impulsu;
generowanie komplementarnych sygnałów w stanowiskach energoelektronicznych.

Flight controller używający gotowych ESC nie steruje bezpośrednio bramkami MOSFET mostka. MCPWM generuje sygnał komendy dla ESC albo serwa. Fault input można jednak wykorzystać do sprzętowego wymuszenia bezpiecznego stanu wyjść po sygnale supervisor/interlock.

Timery i operatory są zasobami grupowymi. Wyjścia dzielą zegary/synchronizację w określony sposób. Konfiguracja musi być sprawdzona dla docelowej wersji ESP-IDF, bo legacy MCPWM API i nowe object API różnią się.

Callbacki ISR MCPWM powinny być IRAM-safe. Wartość compare aktualizuje się przez mechanizm bez glitchy w ustalonym zdarzeniu timera, a pełny wektor aktuatorów publikuje atomowo.

RMT#

RMT wysyła i odbiera sekwencje par poziom + czas trwania. Jest naturalnym kandydatem do DShot, WS2812, PPM i innych protokołów impulsowych. Driver nowej generacji używa kanałów, encoderów i transakcji; szczegóły liczby kanałów/pamięci zależą od SoC.

Dla DShot encoder tworzy 16 komórek z czasem T0H/T1H i stanem dopełniającym. RMT odtwarza je bez programowego bit-bangingu. W bidirectional trzeba po TX przełączyć pin/odbiornik i zmierzyć odpowiedź ESC w terminie.

RMT ma własny zegar. Dynamic frequency scaling może zmienić zależności, jeśli źródło nie jest odporne na DFS. W flight controllerze:

blokuje się odpowiednią częstotliwość power-management lock;
wybiera stabilne źródło zegara;
mierzy rzeczywiste impulsy oscyloskopem;
prealokuje symbole/enkodery;
monitoruje underrun i completion timeout;
nie współdzieli kanału z LED podczas lotu.

RMT nie gwarantuje automatycznej synchronizacji czterech silników. Trzeba zmierzyć skew startu kanałów i ocenić wspólny trigger/alternatywę MCPWM/GDMA.

DShot i wyjścia wykonawcze#

DShot na ESP32-S3 można generować RMT, MCPWM z DMA lub wyspecjalizowanym driverem. Wybór zależy od liczby silników, potrzeby bidirectional i zasobów.

Wymagania wspólne:

pełny wektor silników powstaje z jednej iteracji miksera;
wartości 0, 1–47 i 48–2047 są rozdzielone;
ramka i checksum są testowane niezależnymi wektorami;
start kanałów ma ograniczony skew;
driver ma timeout postępu;
reset ustawia pin w idle i ESC zatrzymuje się po własnym timeout;
bidirectional telemetry ma valid, age i licznik błędów per silnik.

Klasyczne serwa mogą używać MCPWM. Szyna serw ma osobny BEC; pin sygnałowy nie zasila serwa. Po boot wyjścia pozostają disarmed do zakończenia pre-arm checks.

GPIO matrix ułatwia routing, lecz część pinów jest wejściowa, strapping albo zajęta przez pamięć. Pinout musi być zatwierdzony na podstawie modułu/SoC.

TWAI i brak CAN-FD#

TWAI Espressif jest kontrolerem zgodnym funkcjonalnie z klasycznym CAN 2.0. Wymaga zewnętrznego transceivera i terminacji magistrali. Nie jest CAN-FD z szybszą fazą danych.

Może obsługiwać:

prostą magistralę sensorów/aktuatorów CAN;
wybrane profile DroneCAN, jeśli wymagania ramek i timing są spełnione;
diagnostykę oraz redundantny link między kontrolerami;
standardowe/rozszerzone identyfikatory klasycznego CAN.

Projekt obejmuje 120 Ω na obu końcach, kontrolowaną topologię, common-mode, TVS i transceiver z właściwym zasilaniem. bus-off, error passive i liczniki błędów są stanami health.

Jeśli wymagane jest Cyphal/CAN-FD albo duża przepływność sensorów, zewnętrzny kontroler CAN-FD po SPI zwiększa złożoność i latency. Wtedy MCU z natywnym FDCAN może być lepszym wyborem.

UART, I2C i USB#

Trzy kontrolery UART pozwalają typowo przydzielić:

UART0: serwis/console albo zrezygnować z niego w locie;
UART1: RC CRSF full-duplex;
UART2: GNSS lub MAVLink telemetry.

To nadal mało dla GNSS2, companion, rangefindera i dodatkowej telemetrii. USB CDC może obsłużyć konfigurację na ziemi. Nie powinno być krytycznym linkiem lotnym bez analizy hosta i zasilania.

UART RX używa ring buffer DMA/drivera z bounded queue. Parsery CRSF, SBUS, GNSS i MAVLink mają timeout oraz ograniczenia długości. Logowanie tekstowe na wspólny port nie może wstrzykiwać bajtów do protokołu.

I²C ma timeout i recovery. Własny task sensora nie może blokować CPU flight. Jeśli driver ESP-IDF blokuje dłużej niż budżet, wykonuje się go na core usługowym, a flight core używa ostatniej świeżej próbki.

Wi-Fi i Bluetooth LE#

Radio jest atrakcyjne do konfiguracji, pobierania logów i telemetrii lokalnej. Nie powinno być jedynym kanałem krytycznego sterowania bez pełnej analizy opóźnienia, utraty, bezpieczeństwa i regulatory domain.

Wpływ Wi-Fi/BLE:

taski stosu i przerwania konkurują o CPU;
radio pobiera impulsowy prąd i może zakłócać zasilanie/IMU/GNSS;
antena wymaga keepout oraz odległości od carbonu i przewodów;
transmisja zmienia temperaturę SoC i jitter;
socket/heap mogą fragmentować pamięć;
eventy reconnect/DHCP mają długie ścieżki;
RF 2,4 GHz współistnieje z RC, wideo i Bluetooth.

Zalecany tryb:

Wi-Fi/BLE wyłączone podczas lotu albo ograniczone do zweryfikowanego profilu;
interfejs konfiguracji tylko disarmed;
brak zapisu flash po zmianie parametru w locie;
TLS/authentication dla panelu serwisowego;
limit klientów, pakietów i pamięci;
flight task odporny na pełne zatrzymanie stosu radia.

Test porównuje jitter z radiem wyłączonym, w idle, podczas skanowania, reconnect i maksymalnego transferu.

Proponowana architektura firmware#

                    domena lotu — CPU1
IMU DRDY → SPI GDMA → preprocess → attitude/EKF → PID → mixer
    │                                                     │
    └── sensor health / timestamp                         ▼
                                               MCPWM/RMT actuator frame
                                                        │
                                                output watchdog/fault

                    domena usług — CPU0
RC/GNSS/CAN → parsers → timestamped snapshots
MAVLink / blackbox / USB / Wi-Fi / BLE / parameters
                 │
                 └── bounded queues ─────────────> flight domain

Flight domain nie alokuje pamięci, nie zapisuje flash, nie korzysta z socketów i nie czeka na usługowy mutex. Parametry aktywne są immutable snapshotem z CRC/wersją. Zmiana krytyczna jest akceptowana tylko disarmed.

Peryferia mają właściciela. Jedno urządzenie nie jest obsługiwane równocześnie przez kilka tasków. Health manager łączy heartbeat, age danych, deadline misses, stack watermark i stany watchdogów.

Warstwa HAL powinna oddzielać ESP-IDF od algorytmów estymacji. Dzięki temu filtry i regulatory można uruchamiać na hoście w replay/SITL.

Priorytety i affinity zadań#

Przykładowa hierarchia, wymagająca pomiaru:

poziom	zadanie
najwyższy aplikacyjny	flight loop obudzony po komplecie IMU
wysoki	output commit i failsafe supervisor
średnio-wysoki	RC parser, sensor completion
średni	GNSS, CAN, telemetry state
niski	blackbox flush, USB, Wi-Fi UI
najniższy	statystyki, maintenance

Nie nadaje się maksymalnego priorytetu wszystkim taskom. Zadanie wysokie, które blokuje na mutexie lub wykonuje printf, może zagłodzić system. ISR przesyła małe zdarzenie przez mechanizm ISR-safe i wybudza właściwy task.

Tick FreeRTOS nie jest zegarem próbkowania IMU. Szybka pętla jest wyzwalana sprzętowym DRDY/DMA, a vTaskDelay() służy wolnym zadaniom. Deadline mierzy esp_timer/sprzętowy monotoniczny licznik odpowiedni dla targetu.

Core affinity i konfiguracja unicore/SMP są częścią testowanej wersji firmware. Zmiana ESP-IDF może zmienić scheduler; upgrade wymaga regresji timingowej.

Domena czasu i synchronizacja#

Wszystkie sensory i komendy mają monotoniczne timestampy. Znacznik IMU jest pobierany przy DRDY, RC przy zakończeniu poprawnej ramki, GNSS rozróżnia czas odbioru i czas pomiaru.

Budżet latency:

IMU sample → IRQ → DMA → estimator → controller → mixer → output start

Każdy odcinek ma maksimum i percentyle. GPIO debug ustawiane w punktach ścieżki pozwala mierzyć oscyloskopem niezależnie od logu.

Dynamic frequency scaling i light sleep są wyłączone albo objęte power-management lock w domenie lotu. Zmiana APB/CPU clock nie może przesunąć DShot, PWM ani timebase. Źródło zegara każdego peryferium jest jawne.

Synchronizacja wielu wyjść używa zdarzeń MCPWM lub kontrolowanego startu RMT. Sekwencyjne wywołania API bez pomiaru mogą dać zmienny skew.

Watchdogi#

ESP-IDF opisuje kilka warstw:

Interrupt Watchdog wykrywa zbyt długie blokowanie obsługi przerwań/tick;
Task Watchdog wykrywa taski, które nie oddają CPU;
RTC watchdog nadzoruje boot i może działać dalej w aplikacji;
dodatkowy watchdog zegara 32 kHz dotyczy wybranej konfiguracji.

Flight controller potrzebuje własnego health gate. Nie karmi watchdogów tylko dlatego, że idle task działa. Nadzorca sprawdza:

nowy sequence IMU;
heartbeat flight task;
postęp output drivera;
brak niedozwolonego NaN/saturacji;
heartbeat core usługowego lub świadomy tryb degradacji;
stan pamięci/stosu;
age RC i krytycznych sensorów.

Po watchdog reset bootloader zapisuje przyczynę, wyjścia są bezpieczne, a system pozostaje disarmed. Debugger może wyłączać watchdogi przy breakpointach, więc test produkcyjny wykonuje się bez JTAG lub z kontrolą tego zachowania.

Zwiększanie timeoutu Interrupt Watchdog, aby ukryć długą sekcję krytyczną, jest błędem. Dokumentacja Espressif zaleca skrócenie ISR i przeniesienie pracy do taska.

Brownout, boot i wyjścia#

Radio i ESC powodują skoki prądu. Brownout detector ma wykryć spadek zasilania, ale poprawna odpowiedź zaczyna się od regulatora, kondensatorów, layoutu i monitoringu napięcia.

Sekwencja bezpieczna:

zewnętrzne pull-down utrzymują sygnały ESC w idle;
boot ROM i bootloader nie zmieniają pinów na aktywny protokół;
aplikacja czyta przyczynę resetu;
inicjalizuje MCPWM/RMT z zerową komendą;
uruchamia sensory i health checks;
potwierdza stabilne zero do ESC;
dopiero po pre-arm dopuszcza dodatni throttle.

Piny strapping nie powinny być jednocześnie wyjściami, które podłączone ESC/serwo może wymusić podczas resetu. W przeciwnym razie urządzenie może wejść w tryb download zamiast boot.

Testy obejmują wolne narastanie zasilania, krótkie zapady, niezależny reset FC/ESC, USB podłączone/odłączone i każdy stan pinów strapping.

Bezpieczeństwo aktualizacji#

ESP32-S3 wspiera secure boot, flash encryption i mechanizmy OTA. Są użyteczne dla platformy terenowej, ale wymagają zarządzania kluczami i procedury odzyskania.

Zasady:

aktualizacja tylko disarmed i przy stabilnym zasilaniu;
podpisany obraz i weryfikacja przed aktywacją;
dwie partycje aplikacji z rollback po nieudanym self-test;
wersja konfiguracji i migracja parametrów;
blokada downgrade, jeśli wymaga tego model zagrożeń;
fizyczny tryb recovery nie aktywuje silników;
żadnego OTA w trakcie lotu;
klucze nie są przechowywane w repozytorium ani logu.

Flash encryption może zmieniać czas dostępu i proces produkcji. Kwalifikacja odbywa się na konfiguracji produkcyjnej, nie na obrazie developerskim bez zabezpieczeń.

Panel Wi-Fi/BLE ma uwierzytelnienie i limit prób. CRSF/MAVLink oraz lokalne API nie dostają prawa zapisu krytycznej konfiguracji podczas armed.

PCB, moduł czy goły SoC#

Moduł ESP32-S3 upraszcza flash/PSRAM, zegary i tor RF oraz może mieć certyfikacje radiowe. Jest większy i wymaga keepout pod anteną. Goły SoC daje mniejszą płytkę, lecz projektant odpowiada za pamięć, RF, dopasowanie anteny, kryształ i compliance.

Dla pierwszej wersji FC moduł z anteną zewnętrzną lub poprawnym keepoutem jest rozsądniejszy. Węglowa rama tłumi antenę; umieszczenie modułu w środku stacka może zniszczyć zasięg.

PCB rozdziela:

czystą szynę IMU od impulsowego zasilania radia;
masę sensora od powrotów serw/ESC;
QSPI/PSRAM i USB zgodnie z zaleceniami;
antenę od miedzi, baterii i carbonu;
TWAI transceiver przy złączu z TVS;
testpointy zasilania, SWD/JTAG/USB i krytycznych sygnałów.

IMU ma mechaniczne odsprzężenie dobrane do spektrum, a nie miękką piankę bez analizy. Przetwornica i antena są oddalone od IMU, barometru i magnetometru.

Minimalny projekt kontrolera#

Minimalny kontroler laboratoryjny ESP32-S3:

moduł/SoC ESP32-S3 z udokumentowanym flash i opcjonalnym PSRAM;
regulator 3,3 V z zapasem na szczyty Wi-Fi;
supervisor/brownout oraz pomiar napięcia;
IMU SPI z DRDY i poprawnym decouplingiem;
barometr oraz opcjonalny magnetometr/GNSS;
trzy UART-y przydzielone RC/GNSS/telemetry;
cztery wyjścia DShot RMT/MCPWM oraz PWM serw;
zewnętrzny blackbox SPI lub SD w osobnej domenie;
TWAI transceiver, jeśli CAN jest wymagany;
USB, przycisk boot/reset i złącze debug;
buzzer/LED oraz sprzętowy interlock wyjść.

Wi-Fi/BLE nie jest obowiązkowe. Jeśli radio nie ma funkcji operacyjnej, jego wyłączenie zmniejsza pobór, EMI i jitter. Wersja bez anteny/radia może być koncepcyjnie prostsza, choć wtedy warto rozważyć MCU bez wbudowanego RF.

Program uruchomienia#

Zasilanie i brownout: ripple, prąd, radio TX burst.
Boot/flash/PSRAM: test pamięci i przyczyn resetu.
Bezpieczne stany GPIO od power-on do aplikacji.
Monotoniczny timebase i GPIO znacznika WCET.
IMU SPI polling, potem DRDY+DMA.
Kalibracja i pomiar szumu/wibracji na stole.
MCPWM dla serw na obciążeniu logicznym.
RMT/DShot na analizatorze, następnie ESC bez śmigieł.
RC parser i wszystkie scenariusze failsafe.
Estymator w replay/SITL oraz HIL.
PID na stanowisku jednego stopnia swobody.
Test z Wi-Fi/BLE off/on/reconnect/transfer.
Captive test małej, nieuzbrojonej platformy.
Stopniowe rozszerzanie envelope z kryteriami abort.

Każdy etap ma raport: wersja IDF, sdkconfig, hash firmware, hardware revision, parametry, temperaturę, napięcie i wynik. Niewyjaśniony reset, cache panic, missed deadline albo DShot error blokuje przejście dalej.

Testy czasu rzeczywistego#

Macierz obciążenia:

wymiar	warianty
radio	off, idle, scan, reconnect, maksymalny TCP/UDP, BLE event storm
pamięć	cache hot/cold, PSRAM load, flash operation disarmed, zakazana armed
sensory	nominalny/max ODR, FIFO overflow, brak DRDY, SPI error
output	PWM, DShot300/600, bidirectional, timeout kanału
komunikacja	RC max rate, GNSS burst, MAVLink flood, CAN bus load
CPU	oba rdzenie pełne, sekcje krytyczne, task starvation
zasilanie	min/max, brownout pulse, USB i radio burst
temperatura	zakres komponentów i self-heating RF

Mierzone wielkości:

WCET i jitter flight task;
latency IMU→output;
lost samples i FIFO overflow;
DShot skew oraz error rate eRPM;
stack high-water i heap minimum;
cache-disabled violations;
watchdog/panic/reset reason;
age RC/GNSS/telemetry;
napięcia oraz brownout counter.

24-godzinny soak i fuzz parserów są wykonywane przy aktywnej pętli HIL. Test negatywny potwierdza, że flood Wi-Fi nie zmienia wyjść ani nie blokuje failsafe.

Porównanie z RP2040 i STM32#

cecha	ESP32-S3	RP2040	typowy STM32F7/H7 FC
rdzenie	2 × LX7 do 240 MHz	2 × M0+ do 133 MHz nominalnie	zwykle 1 × M7, czasem M7+M4
FPU	single precision	brak	FPU, H7 często DP/SP zależnie od rdzenia
pamięć	512 kB SRAM + flash/PSRAM	264 kB SRAM + flash XIP	większa SRAM, flash wewnętrzny/zewnętrzny zależnie od MCU
niestandardowe I/O	RMT/GPIO matrix	bardzo elastyczne PIO	bogate timery/DMA
motor PWM	MCPWM	PWM slices/PIO	timery zaawansowane
CAN	TWAI klasyczny CAN	brak	często CAN/FDCAN
radio	Wi-Fi + BLE	brak w SoC, Pico W osobny układ	zwykle brak
RTOS	ESP-IDF/FreeRTOS standardowo	bare metal lub RTOS	NuttX/ChibiOS/bare metal
deterministyczność	wymaga izolacji od cache/radia	prostsza, flash XIP nadal istotny	dojrzałe ścieżki FC i timery
ekosystem autopilota	ograniczony/własny port	ograniczony/własny port	dojrzałe targety ArduPilot/PX4/Betaflight

ESP32-S3 ma przewagę, gdy radio i większa moc obliczeniowa są rzeczywiście potrzebne. RP2040 ma wyjątkowe PIO i prostszy profil systemowy. STM32 ma najdojrzalszy ekosystem kontrolerów lotu oraz peryferia dobrane do takiego zastosowania.

Koszt układu nie dominuje kosztu projektu. Jeśli miesiące portowania i kwalifikacji wynikają tylko z oszczędności kilku dolarów, wybór jest ekonomicznie błędny. Jeżeli celem jest nauka lub unikalna integracja Wi-Fi/edge processing, ESP32-S3 może być uzasadniony.

Ograniczenia i decyzja#

ESP32-S3 może stabilizować UAV, jeśli:

flight domain jest przypięty i znajduje się w IRAM/DRAM;
flash/OTA/NVS są zabronione podczas armed;
Wi-Fi/BLE są wyłączone lub przechodzą pełną kwalifikację jitter/EMI;
IMU używa SPI DMA i sprzętowego DRDY;
aktuatory korzystają z MCPWM/RMT, nie programowych opóźnień;
watchdog sprawdza postęp domeny, nie tylko idle task;
bezpieczne GPIO obowiązują od resetu;
target, moduł i sdkconfig są wersjonowane;
całość przechodzi HIL, soak, fault injection i testy zasilania.

Nie jest dobrym wyborem, jeśli projekt wymaga natywnego CAN-FD, wielu niezależnych szybkich magistral, dojrzałego portu ArduPilot/PX4 albo formalnie prostego WCET. Wtedy radio można oddzielić do procesora companion/telemetry, a właściwy FC oprzeć na STM32.

Najbardziej odporna architektura często używa ESP32-S3 jako procesora łączności i interfejsu użytkownika, podczas gdy osobny flight MCU odpowiada za IMU, estymację i wyjścia. Awaria stosu sieciowego nie wpływa wtedy bezpośrednio na stabilizację.

Powiązane tematy#

Przypisy#

Espressif Systems, ESP32-S3 Series Datasheet, https://www.espressif.com/sites/default/files/documentation/esp32-s3_datasheet_en.pdf (dostęp: 15 sierpnia 2026).
Espressif Systems, ESP32-S3 Technical Reference Manual, https://www.espressif.com/sites/default/files/documentation/esp32-s3_technical_reference_manual_en.pdf (dostęp: 15 sierpnia 2026).
Espressif Systems, ESP-IDF Programming Guide for ESP32-S3, https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/ (dostęp: 15 sierpnia 2026).
Espressif Systems, Motor Control PWM (MCPWM), https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/api-reference/peripherals/mcpwm.html (dostęp: 15 sierpnia 2026).
Espressif Systems, Remote Control Transceiver (RMT), https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/api-reference/peripherals/rmt.html (dostęp: 15 sierpnia 2026).
Espressif Systems, Watchdogs, https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/api-reference/system/wdts.html (dostęp: 15 sierpnia 2026).
Espressif Systems, Fatal Errors — cache-disabled constraints, https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/api-guides/fatal-errors.html (dostęp: 15 sierpnia 2026).
Espressif Systems, Two-Wire Automotive Interface (TWAI), https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/api-reference/peripherals/twai.html (dostęp: 15 sierpnia 2026).

Źródła z centralnego rejestru

Espressif Systems: ESP32-S3 Series Datasheet [datasheet producenta]
Espressif Systems: ESP32-S3 Technical Reference Manual [dokumentacja producenta]
Espressif: ESP-IDF Programming Guide for ESP32-S3 [dokumentacja producenta]
ESP-IDF: Motor Control PWM for ESP32-S3 [dokumentacja producenta]
ESP-IDF: Remote Control Transceiver for ESP32-S3 [dokumentacja producenta]
ESP-IDF: Watchdog timers for ESP32-S3 [dokumentacja producenta]
ESP-IDF: Fatal errors and cache-disabled constraints on ESP32-S3 [dokumentacja producenta]
ESP-IDF: Two-Wire Automotive Interface (TWAI) for ESP32-S3 [dokumentacja producenta]
Sumit Sharma, „Drone Development from Concept to Flight” [książka]