Teensy 4.1 jako flight controller

Teensy 4.1 może realnie pełnić rolę komputera flight controllera. Płytka ma szybki Cortex‑M7, sprzętową arytmetykę float i double, wiele interfejsów szeregowych, DMA, CAN, SDIO oraz wystarczająco dużo RAM na bufory sensorów i logowanie. Dowodem praktycznej wykonalności jest m.in. otwarty dRehmFlight: kontroler edukacyjno-prototypowy rozwijany dla Teensy 4.0, którego autor wskazuje Teensy 4.1 jako zgodny z istniejącą mapą pinów. Nie oznacza to jednak, że sama płytka deweloperska jest gotowym autopilotem. Trzeba zaprojektować zasilanie, sensory, wyjścia, watchdog, mechanikę i oprogramowanie czasu rzeczywistego.

Odpowiedź krótka#

Teensy 4.1 jest dobrym wyborem, gdy celem jest:

własny flight controller do nauki i szybkiego prototypowania;
nietypowy VTOL lub stanowisko badawcze wymagające łatwej modyfikacji kodu;
szybka pętla sterowania z rozbudowanym logowaniem;
komputer payloadu współpracujący z osobnym certyfikowanym autopilotem;
HIL, sterowanie stanowiskiem lub eksperyment z nowym algorytmem.

Jest gorszym wyborem, gdy projekt wymaga od razu redundantnych IMU, wejść z ochroną przemysłową, produkcyjnego złącza, kontrolowanego BOM-u, certyfikacji albo pełnej zgodności z ArduPilot/PX4 bez własnego board support package. Gotowy kontroler lotu ma na jednej płycie elementy, które wokół Teensy trzeba dopiero dodać.

Zasoby Teensy 4.1 istotne dla UAV#

Według dokumentacji PJRC płytka wykorzystuje Cortex‑M7 przy 600 MHz i sprzętową jednostkę zmiennoprzecinkową dla 32- oraz 64-bitowych typów. Ma około 8 MB Flash, 1 MB RAM, w tym 512 KB pamięci tightly coupled, 55 linii cyfrowych, 35 PWM, osiem UART, trzy SPI, trzy I²C, trzy CAN (jeden CAN FD), 32 kanały DMA i natywne SDIO dla karty microSD.

Zasób	Znaczenie w flight controllerze	Pułapka
Cortex‑M7 600 MHz	filtracja, EKF, regulatory, kodowanie telemetrii	duży zapas mocy może ukryć niedeterministyczny projekt
FPU float/double	czytelna matematyka orientacji i filtrów	zgodność numeryczna nadal wymaga testów
ITCM/DTCM	niski i przewidywalny czas kodu i danych pętli	DMA nie widzi wszystkich obszarów tak samo
RAM2/DMAMEM	bufory DMA, logowanie, podwójne bufory SPI	potrzebna obsługa spójności cache/pamięci
3 × SPI	osobne magistrale IMU, barometru i pamięci	biblioteka blokująca nadal może popsuć deadline
8 × UART	GNSS, RC, telemetria, companion computer	poziomy 3,3 V, brak ochrony wejść
3 × CAN	DroneCAN lub własne węzły sensorów	potrzebny zewnętrzny transceiver i terminacja
microSD przez SDIO	szybki blackbox	zapis karty ma długie ogony opóźnienia
Ethernet/USB	HIL i szybkie logi laboratoryjne	nie są automatycznie łączem lotniczym

Liczba portów ma znaczenie praktyczne. IMU można odseparować na własnym SPI, GNSS otrzymuje osobny UART, a odbiornik RC nie konkuruje z logowaniem. Na małym AVR kompromis ten często kończy się software serial albo współdzieleniem magistrali.

i.MX RT1062: szybki MCU, a nie komputer Linux#

i.MX RT1062 należy do klasy crossover MCU: wydajność jest wysoka, ale program nadal działa bez systemu operacyjnego ogólnego przeznaczenia, z bezpośrednią kontrolą przerwań i peryferiów. To korzystne dla pętli czasu rzeczywistego. Nie ma procesu planisty Linux, swapu ani nieprzewidywalnych usług tła.

Cortex‑M7 ma jednak cache, wiele domen pamięci i złożony system magistral. Kod może działać bardzo szybko z ITCM/DTCM, podczas gdy bufor w innej pamięci zachowuje się inaczej. Transfer DMA do bufora, który CPU nadal widzi przez cache, wymaga właściwego umieszczenia danych albo operacji utrzymania spójności. Błąd nie musi występować w każdej iteracji — może ujawniać się dopiero po zmianie wyrównania lub rozmiaru bufora.

Dlatego projekt powinien jawnie klasyfikować pamięć:

kod krytycznej pętli i mały stan: ITCM/DTCM;
bufory wejściowe/wyjściowe DMA: obszar przeznaczony dla DMA, odpowiednio wyrównany;
duże logi przed zapisem: RAM2;
stałe i kod niekrytyczny: Flash;
opcjonalny PSRAM: dane niekrytyczne czasowo, nigdy jedyny bufor safety.

Czego brakuje na płytce#

Teensy 4.1 nie zawiera IMU, barometru, magnetometru, odbiornika GNSS ani transceivera CAN. Nie ma też typowej dla autopilota sekcji power module, pomiaru napięcia/prądu, redundancyjnego regulatora, izolacji USB od zasilania pokładowego, pamięci FRAM i złączy blokowanych mechanicznie.

Minimalna płyta nośna powinna zawierać:

Zasilanie. Regulator o znanym zachowaniu przy brownout, filtr wejściowy, ograniczenie przepięć, pomiar napięcia oraz poprawną sekwencję VUSB/VIN.
IMU. Sensor na SPI, lokalne odsprzęganie, mechaniczne odsunięcie od źródeł drgań i linia data-ready.
Barometr. Osłona od światła i przepływu, ale bez zamknięcia wyrównania ciśnienia.
Wejścia RC/GNSS. Bufory, ESD, właściwe poziomy i złącza.
Wyjścia. Bufor lub driver z jednoznacznym stanem po resecie; sygnał enable kontrolowany przez hardware.
Watchdog. Wewnętrzny plus — dla ryzykownego stanowiska — zewnętrzny supervisor odcinający wyjścia.
Debug. Punkty SWD/JTAG, pin heartbeat, piny pomiaru czasu ISR i pętli.
Migawka. Transoptor/PhotoMOS albo open-drain do dedykowanego wejścia aparatu.

Dokumentacja PJRC ostrzega, że cyfrowe i analogowe piny przyjmują maksymalnie 3,3 V i nie są tolerancyjne na 5 V; rekomendowany prąd wyjściowy to tylko kilka miliamperów. To wyklucza bezpośrednie podłączanie wielu starych odbiorników, magistrali 5 V czy obciążenia wejścia aparatu bez adaptera.

Architektura programu#

Najprostszy czytelny podział wygląda następująco:

data-ready IMU -> ISR/DMA -> bufor A/B + timestamp
                               |
timer 1 kHz -> work flag ------+--> estimator --> rate PID --> mixer --> output buffer
                                                  |
RC UART DMA -> parser -> setpoint ----------------+
GNSS UART DMA -> parser -> wolniejsza estymacja
SDIO writer <- ring buffer <- logger <- snapshot pętli
camera request -> edge detector -> pulse/lockout -> optoizolator
watchdog <- health monitor <- deadline + sample age + sensor status

ISR nie powinna wykonywać filtra i regulatora. Data-ready uruchamia DMA lub kopiuje gotowy rekord, timer ustawia flagę, a obliczenia odbywają się w deterministycznym kontekście. Dzięki temu priorytety i WCET są mierzalne.

Pierwsza wersja może działać bez RTOS. Główna pętla obsługuje zadania według flag oraz deadline. RTOS warto dodać, gdy istnieje kilka niezależnych interfejsów, ale sam scheduler nie gwarantuje czasu rzeczywistego. Priorytet, blokady, alokacja pamięci i czas bibliotek pozostają odpowiedzialnością autora.

Częstotliwości pętli#

Nie należy ustawiać każdej funkcji na 8 kHz tylko dlatego, że CPU jest szybki. Sensowny harmonogram wynika z sensorów i dynamiki:

Zadanie	Przykładowy rząd	Uwaga
odczyt żyroskopu	1–8 kHz	zależny od ODR, filtra i magistrali
regulator rate	1–4 kHz	powinien używać świeżej próbki
regulator attitude	100–500 Hz	wolniejsza warstwa kaskady
barometr	25–100 Hz	filtr i opóźnienie sensora
GNSS	5–20 Hz	timestamp ważniejszy niż szybkie przepytywanie
logowanie snapshotu	100–1000 Hz	zapis fizyczny poza pętlą
health monitor	10–100 Hz	deadline, temperatury, błędy magistral

To wartości projektowe do weryfikacji, nie ustawienia uniwersalne. Każda częstotliwość musi wynikać z datasheetu sensora, opóźnienia filtra i zmierzonego czasu wykonania.

IMU: SPI, data-ready i timestamp#

Do podstawowej IMU lepiej użyć SPI niż I²C, gdy wymagany jest wysoki rate i ograniczone opóźnienie. Transakcja powinna pobrać status i wszystkie osie w jednym burst. Linia data-ready wyznacza moment dostępności próbki; ISR zapisuje timestamp i rozpoczyna transfer. Po zakończeniu DMA bufor uzyskuje numer sekwencyjny i status complete.

Podwójny bufor eliminuje wyścig:

DMA wypełnia B
CPU przetwarza A
DMA complete: timestamp B, complete B = true, swap active
CPU pobiera spójny B, a A wraca do DMA

Jeśli sensor ma FIFO, należy wykrywać overrun i znać czas każdej próbki w paczce. Przypisanie wszystkim wartościom czasu zakończenia transferu fałszuje fazę sygnału i może pogorszyć regulator mimo pozornie wysokiej częstotliwości.

Cache, DMA i logowanie#

Teensy 4.1 ma na tyle dużo RAM, że można zastosować duży bufor kołowy blackboxa. Nie wolno jednak wykonywać flush karty SD w pętli rate. Karty mają opóźnienia o długim ogonie związane z wewnętrznym zarządzaniem Flash. Logger zapisuje stałe rekordy do RAM, a zadanie o niższym priorytecie wysyła większe bloki SDIO.

Rekord powinien być binarny i mieć wspólny timestamp:

t_us, seq, gyro_raw[3], accel_raw[3], setpoint[3],
pid_p[3], pid_i[3], pid_d[3], motor[4], sample_age,
loop_time, deadline_flags, shutter_state

CSV tworzy się po locie. Format binarny redukuje koszt konwersji liczb i liczbę bajtów, a narzędzie offline może sprawdzić ciągłość numerów sekwencji.

Wyjścia napędu#

Teensy ma wiele kanałów PWM i FlexIO, ale biblioteka Arduino analogWrite() nie jest automatycznie właściwym driverem ESC. Należy określić protokół, częstotliwość, rozdzielczość, stan po resecie i sposób atomowej aktualizacji grupy kanałów.

Pierwszy poziom laboratorium nie generuje sygnału do prawdziwego ESC. Cztery znormalizowane wartości trafiają do emulatora. Następny poziom używa timera lub FlexIO, ale na analizatorze logicznym. Dopiero później można podłączyć ESC bez śmigła i z ograniczeniem prądu.

Hardware enable powinien pozostać nieaktywny, dopóki:

firmware nie ukończy inicjalizacji;
IMU nie dostarczy serii spójnych próbek;
pętla nie zmieści się w deadline;
stan wejścia sterującego jest znany;
watchdog i procedura zerowania wyjść są sprawdzone.

Migawka aparatu i selfie stick#

Teensy może wyzwalać zdjęcie na trzy sposoby.

Izolowane wejście remote aparatu#

Pin steruje transoptorem lub PhotoMOS, który zwiera styki wejścia remote. Firmware generuje impuls 120 ms. Jeżeli aparat rozdziela focus i shutter, potrzebne są dwa kanały oraz sekwencja focus-before-shutter zgodna z instrukcją aparatu.

Przewodowy selfie stick#

Najmniej ryzykowne jest wykorzystanie kompletnego sticka. Fototranzystor dołącza się równolegle do jego przycisku, dzięki czemu zachowane zostają pinout TRRS i fabryczna drabinka rezystorów. Teensy nie jest elektrycznie połączone z telefonem. Aplikacja aparatu musi mapować dany przycisk na migawkę.

BLE HID#

Bezprzewodowe selfie sticki często wysyłają zdarzenie HID przycisku głośności. ST publikuje przykład STM32WB, w którym BLE HID wysyła volume down i system telefonu używa go jako skrótu zdjęcia. Teensy 4.1 nie ma wbudowanego Bluetooth, więc ten wariant wymaga osobnego modułu BLE z własnym firmware i parowaniem. FC wysyła do modułu pojedyncze żądanie, a moduł zwraca status wysłania.

W każdym wariancie rdzeń używa zbocza, impulsu i lockoutu. Zdarzenie przechowuje timestamp, ale ekspozycja może wystąpić później z powodu autofocusu i aplikacji. Do fotogrametrii potrzebne jest potwierdzenie aparatu albo synchronizacja jego logu, nie tylko czas GPIO.

dRehmFlight jako dowód wykonalności#

dRehmFlight jest otwartym kontrolerem przeznaczonym do nauki stabilizacji i szybkiego prototypowania nietypowych VTOL. Projekt bazuje na Teensy 4.0 i MPU6050; dokumentacja repozytorium wskazuje, że Teensy 4.1 jest bezpośrednio zgodny z mapą pinów. To ważny dowód, że platforma była rzeczywiście używana do sterowania, a nie tylko oceniana na podstawie tabeli parametrów.

Nie należy jednak kopiować wniosków poza zakres projektu. Sam autor opisuje dRehmFlight jako narzędzie edukacyjne i prototypowe, nie zamiennik komercyjnego kontrolera. MPU6050 na module GY-521, przewody na płytce stykowej i pojedynczy sensor nie tworzą architektury odpornej na awarie. Kod warto czytać jako przejrzysty punkt startowy, a nie certyfikowany baseline.

Teensy kontra STM32 flight controller#

Cecha	Teensy 4.1	Typowy gotowy FC STM32 H7
start programu	bardzo szybki dzięki Teensyduino/Arduino	wymaga konfiguracji board support
moc CPU	bardzo wysoka, Cortex‑M7 600 MHz	wysoka, zależna od STM32H7
sensory na płycie	brak	1–3 IMU, barometr, czasem magnetometr
zasilanie i pomiary	do zaprojektowania	zwykle gotowe wejścia VBAT/current
złącza	goldpiny/pady deweloperskie	JST/GH lub dedykowane złącza
CAN	kontroler w MCU, potrzebny transceiver	często transceiver na płycie
SD	wbudowane gniazdo SDIO	zwykle microSD, czasem wolniejsze połączenie
ekosystem	Arduino/Teensyduino, własny kod	PX4, ArduPilot, Betaflight zależnie od płytki
swoboda eksperymentu	bardzo duża	duża, ale ograniczona layoutem FC

Teensy wygrywa jako szybki komputer do własnego algorytmu. Gotowy FC wygrywa integracją elektryczną i mechaniczną. Dobrym układem hybrydowym jest Teensy jako companion/payload computer po CAN lub UART, a sprawdzony autopilot jako właściciel stabilizacji i failsafe.

Co implementuje `fc-lab-teensy`#

Katalog git/fc-lab-teensy zawiera rdzeń C testowany na hoście, szkic target/teensy41/main.cpp, konfigurację PlatformIO, emulator ESC, scenariusz HIL i log. Rdzeń realizuje P rate, mikser quad-X, limit wieku próbki, safe state oraz migawkę.

Szkic używa IntervalTimer przy 1 kHz, ale ISR tylko zapisuje czas i ustawia flagę. Fizyczne wyjścia napędu pozostają wyłączone; wartości można obserwować przez USB Serial. Polecenie c uruchamia impuls optoizolatora migawki, e włącza obliczenia laboratoryjne, a x wraca do stanu bezpiecznego.

cd git/fc-lab-teensy
make test
make hil

Test sprawdza start bez zezwolenia, kierunek miksera, wygaśnięcie migawki i reakcję na próbkę starszą niż 5 ms. To dopiero kontrakt bazowy. Następne testy powinny objąć rollover millis(), utratę wielu ticków, NaN w wejściu, nasycenie, watchdog oraz spójność buforów DMA.

Plan dojścia do prototypu#

Host. Testy rdzenia i HIL na zapisanych trajektoriach.
Teensy bez sensorów. Pomiar IntervalTimer, USB logu i migawki analizatorem.
Jedna IMU. SPI burst, data-ready, timestamp, identyfikacja osi i test nieruchomy.
Rate loop w HIL. Prawdziwa Teensy liczy regulator, model dynamiki działa na PC.
Emulator wyjść. Driver timer/FlexIO podłączony do analizatora, timeout sprzętowy.
Stanowisko jednoosiowe. Ograniczona energia, brak śmigła, fizyczny kill switch.
Nośnik bez napędu. Test zasilania, wibracji, EMI, karty SD i GNSS.
Mały nieuzbrojony demonstrator. Dopiero po fault injection i przeglądzie logów.

Na każdym etapie kryterium awarii jest konkretne: przeterminowana próbka, overrun DMA, brak ticku, przekroczony WCET, błędny sensor lub brownout prowadzą do stanu bezpiecznego. „Program się nie zawiesił” nie jest kryterium zaliczenia.

Najczęstsze błędy#

Zasilanie jednocześnie z USB i VIN bez rozdzielenia VUSB/VIN zgodnie z dokumentacją płytki.
Podanie 5 V na pin, bo wcześniejsze Teensy albo Arduino tolerowało taki poziom.
Użycie dynamicznej alokacji w krytycznej pętli.
Bufor DMA w niewłaściwym obszarze pamięci lub bez obsługi cache.
Blokujący zapis SD i formatowanie tekstu w pętli rate.
Odczyt IMU bez data-ready i bez timestampu.
Uznanie liczby PWM za gotowy, bezpieczny driver ESC.
Wspólna masa telefonu i układu napędowego przy migawce, mimo że izolacja kosztuje jeden element.
Brak testu zachowania pinów podczas bootloadera i resetu.
Strojenie PID przed pomiarem opóźnienia filtrów oraz jitteru.

Wniosek#

Teensy 4.1 jest realną i bardzo wydajną platformą dla własnego kontrolera lotu, zwłaszcza w edukacji, badaniach i nietypowym prototypie. Jej przewagą jest połączenie prostego środowiska z zasobami Cortex‑M7, DMA, wieloma interfejsami i szybkim SDIO. Jej słabością jest właśnie forma płytki deweloperskiej: wszystkie elementy lotniczego produktu — sensory, zasilanie, zabezpieczenia, złącza i safety case — pozostają po stronie konstruktora.

W praktyce największy sens ma podejście dwutorowe: rozwijać algorytm na Teensy w HIL, a decyzję o docelowym hardware podejmować dopiero po zebraniu profilu czasu, pamięci, I/O i awarii. Jeżeli nośnik ma być czymś więcej niż eksperymentem, wyniki można przenieść na własną płytę i.MX RT albo sprawdzony FC STM32, zachowując testy oraz kontrakty modułów.

Powiązane tematy#

Przypisy#

PJRC, Teensy 4.1 Development Board, specyfikacja, pamięć, I/O, zasilanie, poziomy logiczne i środowiska programistyczne.
NXP, i.MX RT1060 Crossover MCU, dokumentacja rodziny MIMXRT1062.
NXP, i.MX RT1060 datasheet, parametry elektryczne i peryferia.
Nick Rehm, dRehmFlight, otwarty kontroler Teensy dla prototypowania małych VTOL, licencja GPL‑3.0.
STMicroelectronics, STM32WB BLE HID Selfie, przykład BLE HID wysyłający przycisk głośności jako wyzwolenie zdjęcia.
Android Developers, KeyEvent API reference, zdarzenia klawiszy i KEYCODE_CAMERA.

Źródła z centralnego rejestru

PJRC: Teensy 4.1 Development Board [oficjalna dokumentacja płytki; MCU, pamięć, I/O, DMA, SDIO, zasilanie i poziomy logiczne]
NXP: i.MX RT1060 Crossover MCU [oficjalna dokumentacja rodziny MCU używanej przez Teensy 4.1]
NXP: i.MX RT1060 datasheet [datasheet producenta]
dRehmFlight — Teensy flight controller for small-scale VTOL [repozytorium open source GPL-3.0; projekt edukacyjny i prototypowy]
STMicroelectronics: STM32WB BLE HID Selfie [oficjalny przykład BLE HID używający klawisza głośności do wyzwalania zdjęcia]
Android Developers: KeyEvent API reference [oficjalna dokumentacja zdarzeń przycisków, w tym KEYCODE_CAMERA]