RP2040 jako flight controller

RP2040 może być rdzeniem samodzielnie zbudowanego kontrolera lotu, szczególnie jako platforma edukacyjna, badawcza i dla lekkich, nieuzbrojonych UAV. Dwa rdzenie Cortex‑M0+, 264 kB SRAM, 12 kanałów DMA i osiem maszyn stanów PIO pozwalają deterministycznie próbkować sensory oraz generować protokoły wykonawcze. Ograniczenia są równie istotne: brak sprzętowej jednostki zmiennoprzecinkowej, zewnętrzny flash XIP, niewielka liczba klasycznych UART/SPI/I²C, ograniczone priorytety przerwań M0+ i brak wbudowanego CAN.

Nie jest to „Pixhawk w tańszym układzie”. Własny flight controller wymaga zaprojektowania zasilania, zegarów, resetu, pamięci, toru IMU, wyjść, logowania, bootloadera i procedur awaryjnych. RP2040 ma wyjątkowo elastyczne PIO, ale PIO nie zastępuje architektury czasu rzeczywistego ani niezależnego nadzoru.

Spis treści#

Kiedy RP2040 ma sens
Najważniejsze zasoby
Dwa rdzenie Cortex-M0+
Brak FPU
Pamięć SRAM i flash XIP
PIO
DMA
SPI i tor IMU
I2C, UART i USB
Wyjścia PWM i DShot
Proponowana architektura firmware
Podział między rdzenie
Domena czasu
Estymacja i regulatory
Watchdog i reset
Blackbox i pamięć
PCB i zasilanie
Minimalny projekt sprzętowy
Program uruchomienia
Testy czasu rzeczywistego
Ograniczenia i decyzja
Powiązane tematy
Przypisy

Kiedy RP2040 ma sens#

RP2040 jest dobrym wyborem, gdy celem jest zrozumienie pełnego toru sterowania, prototyp nietypowego I/O albo mały kontroler o ściśle ograniczonej funkcji. PIO pozwala zbudować interfejsy, których nie ma w klasycznych peryferiach, a niski koszt ułatwia wykonywanie wielu iteracji PCB.

Typowe sensowne zastosowania:

laboratoryjny kontroler multirotora na stanowisku i małej platformie;
kontroler powierzchni/aktuatorów jako węzeł pomocniczy;
rejestrator IMU i protokołów RC/ESC;
eksperymenty z własnym filtrem orientacji oraz PID;
generator/decoder DShot, SBUS lub niestandardowego sygnału przez PIO;
sterownik UGV lub łodzi, gdzie dynamika jest wolniejsza;
redundantny procesor I/O nadzorujący wyjścia głównego autopilota.

Mniej odpowiedni jest rozbudowany autopilot z ciężkim EKF, computer vision, wieloma sensorami CAN i pełnym stosem sieciowym. Można napisać wydajny kod, lecz koszt inżynierski i ryzyko przekraczają zalety taniego MCU. Dla platformy przewożącej ludzi lub krytycznego ładunku potrzebna jest analiza zgodności i architektura o innym poziomie assurance.

Najważniejsze zasoby#

RP2040 według datasheetu zawiera:

zasób	znaczenie dla FC
2 × Cortex‑M0+ do 133 MHz nominalnie	separacja szybkiego toru i usług
264 kB SRAM w wielu bankach	kod czasu rzeczywistego, bufory DMA, stan estymatora
zewnętrzny QSPI flash z XIP	firmware i stałe, ale ze zmiennym opóźnieniem cache
2 × SPI	IMU i pamięć/sensor o wysokiej przepływności
2 × I²C	wolniejsze sensory i konfiguracja
2 × UART	RC, GNSS, telemetria — szybko stają się wąskim gardłem
16 kanałów PWM w ośmiu slices	serwa i prostsze wyjścia
2 bloki PIO × 4 state machines	deterministyczne niestandardowe I/O
12 kanałów DMA	transfer sensorów, PIO, UART i logowanie
USB 1.1 device/host	konfiguracja i logi laboratoryjne
watchdog, timer, alarmy	nadzór i harmonogram

Nominalne 133 MHz nie jest właściwą jednostką oceny pętli. Trzeba zmierzyć WCET funkcji, opóźnienia flash, konflikty magistrali i przerwań. Podkręcanie zegara ponad specyfikację producenta nie powinno być podstawą kwalifikowanego kontrolera lotu.

Dwa rdzenie Cortex-M0+#

Dwa rdzenie współdzielą pamięć i peryferia. Nie oznacza to automatycznie dwukrotnej wydajności. Wymagają jawnego podziału własności i synchronizacji. Dostęp do wspólnej struktury bez bariery pamięci może dać częściowo zaktualizowany stan.

Praktyczny podział:

core 0: IRQ IMU → acquisition → filtracja → estymacja → PID/mixer
core 1: RC/GNSS/telemetria → logowanie → parametry → USB
PIO/DMA: deterministyczne wejścia i wyjścia

Core 0 nie powinien wykonywać formatowania tekstu, zapisu flash ani stosu USB. Core 1 nie zapisuje bezpośrednio rejestrów aktuatorów; publikuje polecenia przez ograniczoną kolejkę. Najnowszy kompletny snapshot parametrów jest kopiowany w kontrolowanym punkcie.

RP2040 oferuje sprzętowe spinlocki i FIFO między rdzeniami. Spinlock w szybkiej pętli musi trwać bardzo krótko. Jeśli core 1 może go utrzymać podczas wolnej operacji, core 0 traci deadline. Lepsze są ring buffery single-producer/single-consumer i double buffering.

Każdy rdzeń ma własne przerwania, lecz nie wszystkie mechanizmy są całkowicie niezależne. Manifest firmware określa, który rdzeń jest właścicielem każdego IRQ, DMA i peryferium.

Brak FPU#

Cortex-M0+ w RP2040 nie ma sprzętowej FPU. Operacje float są realizowane programowo. Nie uniemożliwia to stabilizacji — częstotliwości rzędu kHz są osiągalne przy małym, zoptymalizowanym filtrze — ale rozbudowany EKF z dużymi macierzami szybko zużywa budżet.

Opcje:

pozostawić float, mierzyć WCET i ograniczyć model;
użyć fixed-point w krytycznych filtrach, z analizą zakresów;
mieszać: sensory/filtrowanie fixed-point, estymacja małym float;
przenieść wolną nawigację do companion/autopilota wyższego poziomu;
zmniejszyć rate zadań pozycyjnych względem pętli rate.

Fixed-point nie jest automatycznie bezpieczniejszy. Wymaga saturacji, skalowania, ochrony przed overflow i testów granicznych. float ma z kolei NaN/Inf, które trzeba wykrywać przed wyjściem do miksera.

Budżet mierzy się dla najgorszej ścieżki: normalizacja kwaternionu, aktualizacja filtra, PID wszystkich osi, mikser i publikacja wyjść. Średnia z prostego lotu nie wystarcza.

Pamięć SRAM i flash XIP#

Kod wykonywany bezpośrednio z zewnętrznego QSPI flash przechodzi przez cache. Trafienie jest szybkie, miss wymaga transferu po zewnętrznej magistrali. Zapis/erase flash może czasowo zablokować wykonywanie XIP, dlatego nie wolno zapisywać parametrów ani logu flash w aktywnej ścieżce lotu bez architektury świadomie umieszczającej krytyczny kod w RAM.

Podział pamięci:

krytyczne ISR, sterowniki DMA i pętla rate w SRAM;
bufory DMA wyrównane i o statycznym rozmiarze;
stałe kalibracyjne w snapshot RAM podczas lotu;
log jako bounded ring buffer;
aktualizacja flash tylko disarmed lub przez osobny bezpieczny etap;
stosy obu rdzeni z high-water monitoringiem.

264 kB wystarcza dla małego FC, ale duże bufory USB/logów szybko ją zużywają. Linker map i runtime watermark są częścią testów. Dynamiczna alokacja po inicjalizacji jest zbędna i utrudnia przewidywalność.

Boot z zewnętrznego flash zwiększa znaczenie integralności zasilania oraz poprawnego layoutu QSPI. Własna PCB musi korzystać z zaleceń producenta dotyczących pamięci, decouplingu i połączeń.

PIO#

Każdy z dwóch bloków PIO ma cztery state machines wykonujące krótkie programy deterministycznego I/O. State machine ma rejestry przesuwne, FIFO, dzielnik zegara, elastyczne mapowanie pinów, IRQ i handshake DMA.

Zastosowania w FC:

generowanie DShot dla wielu ESC;
odbiór bidirectional DShot/eRPM;
dekodowanie SBUS/CRSF w specjalnych przypadkach;
wejścia capture dla PPM/PWM;
precyzyjny trigger sensorów lub synchronizacja kamery;
niestandardowy redundantny link między MCU.

PIO daje deterministyczny timing, o ile FIFO nie jest głodzone i program nie ma nieprzeanalizowanej ścieżki. DMA zasila FIFO, a CPU przygotowuje większe ramki. Timeout FIFO/IRQ musi być wykrywalny.

Pamięć instrukcji PIO jest mała i współdzielona w obrębie bloku. Programy trzeba przydzielić na etapie projektu. Cztery state machines na blok nie oznaczają dowolnej liczby niezależnych interfejsów; część protokołów zużywa więcej niż jedną.

Kod PIO powinien mieć osobne testy cycle-accurate. Przejście z RP2040 na RP2350 nie może zakładać identycznych rozszerzeń PIO bez kontroli wymaganej wersji.

DMA#

RP2040 ma 12 kanałów DMA. Mogą przenosić dane memory↔peripheral i memory↔memory, być taktowane żądaniami DREQ, łączyć się łańcuchowo i generować przerwania. To fundament niskiego jittera.

Przykładowe przydziały:

kanały	funkcja
0–1	SPI IMU RX/TX
2–5	PIO/DShot wyjścia lub grupy
6–7	bidirectional capture
8	UART RC RX ring
9	UART telemetry TX
10	pamięć blackbox SPI
11	rezerwa/diagnostyka

To tylko przykład. Konflikty DREQ i przerwań trzeba sprawdzić w datasheecie. DMA zapisuje do bufora dopiero po konfiguracji adresów, liczby elementów i rozmiaru transferu. Błąd byte/halfword/word może nadpisać pamięć.

Każdy transfer ma timeout i numer sekwencji. Chain DMA nie może działać w nieskończoność po utracie sensora. Przerwania DMA są współdzielone; handler odczytuje maskę i obsługuje wszystkie zgłoszone kanały bez kasowania cudzych flag.

SPI i tor IMU#

Główne IMU powinno korzystać z SPI, nie I²C, jeśli oczekujemy próbkowania wielu kHz i kontrolowanego opóźnienia. Linia data-ready wyzwala timestamp oraz transfer DMA.

IMU DRDY → GPIO IRQ / PIO capture → timestamp
       → SPI DMA burst → buffer N
       → validate/status → filtr antyaliasingowy
       → estimator/rate loop

Timestamp należy przypisać do momentu powstania próbki albo zbocza DRDY, nie do końca późniejszego transferu. FIFO IMU może zmniejszyć ryzyko utraty, ale zwiększa latency i wymaga rekonstrukcji czasu próbek.

Dwa SPI pozwalają rozdzielić główne IMU od flash/secondary sensors. Jeśli kilka urządzeń dzieli magistralę, każde ma własny CS, tryb i maksymalny zegar. Driver musi przełączać konfigurację atomowo.

RP2040 nie ma wbudowanego ADC wysokiej jakości dla sensorów lotniczych; wewnętrzny ADC wystarcza do orientacyjnych napięć, ale pomiar prądu/baterii wymaga analizy dokładności, filtracji i referencji. Krytyczny power monitor może być zewnętrzny.

I2C, UART i USB#

I²C nadaje się do barometru, magnetometru i wolnych sensorów, ale blokada magistrali nie może zatrzymać pętli rate. Driver ma timeout, możliwość recovery SCL i odizolowaną kolejkę. Magnetometr umieszcza się z dala od prądów napędu, często na module GNSS.

Dwa UART-y szybko się kończą:

RC CRSF wymaga TX+RX;
GNSS zajmuje kolejny RX/TX;
MAVLink telemetry potrzebuje następnego portu;
debug console nie może współdzielić portu lotnego bez kontroli.

PIO może implementować dodatkowe UART-y, ale zwiększa koszt testów i zużywa state machines/DMA. Alternatywą jest zewnętrzny UART bridge albo ograniczenie funkcji. USB służy do konfiguracji i pobierania logów na ziemi; podłączenie hosta nie może zmieniać priorytetu szybkiej pętli.

Brak sprzętowego CAN jest istotny dla DroneCAN. Można dodać zewnętrzny kontroler CAN po SPI i transceiver, lecz latency, obciążenie oraz dodatkowy punkt awarii są większe niż w MCU z CAN-FD. Jeśli CAN jest wymaganiem podstawowym, inny MCU może być lepszy.

Wyjścia PWM i DShot#

RP2040 ma PWM slices, które mogą generować klasyczne impulsy serw. Kanały w slice dzielą część konfiguracji okresu. DShot naturalnie pasuje do PIO+DMA, dzięki czemu klasyczne PWM pozostaje dla serw.

Wymagania wyjść:

pin ma bezpieczny stan pull-down przy reset;
driver startuje od disarmed/zero;
pełny wektor aktuatorów jest atomowy;
PIO/DMA ma watchdog postępu;
poziom 3,3 V jest zgodny z odbiornikiem;
osobna szyna serw ma własne zasilanie/BEC;
bidirectional DShot wymaga toru dwukierunkowego.

Nie wolno generować DShot poprzez pętlę sleep_us() na core 0. PIO zapewnia timing niezależny od cache i IRQ. CPU jedynie dostarcza ramki przed deadline.

Proponowana architektura firmware#

               core 0 — domena lotu
IMU DRDY/DMA → acquisition → filters → attitude → PID → mixer
       │                                              │
       └──── timestamp/health                         ▼
                                              actuator frame
                                                     │
                                       PIO/PWM + output watchdog

               core 1 — domena usług
RC/GNSS → parsers → command snapshot
telemetry/log/USB/parameters
       │
       └── bounded queues / double buffers ──> core 0

Każdy moduł publikuje dane z timestamp, sequence, valid i health counters. Core 0 używa tylko danych mieszczących się w deadline. Parametry są niezmienne podczas pojedynczej iteracji.

Bare metal z przerwaniami wystarcza dla małego projektu. FreeRTOS może uporządkować usługi, ale scheduler nie powinien sterować czasem najważniejszej pętli bez pomiaru. Najszybsza domena może pozostać event-driven na core 0, a RTOS działać na usługowym core 1.

Podział między rdzenie#

Własność zasobów:

zasób	właściciel
SPI0 + IMU DMA	core 0
PIO aktuatorów	core 0
UART RC	core 1, snapshot do core 0
UART GNSS	core 1
USB/log	core 1
parametry aktywne	read-only snapshot dla core 0
watchdog heartbeat	oba rdzenie, decyzja nadzorcy

Core 1 nie może zablokować core 0 spinlockiem. Komunikat RC ma stały rozmiar, a kolejka może nadpisywać starą pozycję najnowszą, zachowując licznik utraty. Teksty telemetryczne używają osobnej kolejki o niskim priorytecie.

Awaria core 1 nie może zatrzymać stabilizacji, ale utrata RC/GNSS ostatecznie uruchamia odpowiedni failsafe. Awaria core 0 wymaga zatrzymania aktuatorów przez watchdog/PIO state, a core 1 nie przejmuje spontanicznie kontroli bez zaprojektowanego trybu.

Domena czasu#

Monotoniczny licznik mikrosekund jest wspólną podstawą. Każda próbka i komenda ma timestamp. Nie stosuje się czasu ściennego do deadline.

Przykładowe rate:

zadanie	przykładowy rząd wielkości
odczyt gyro	4–8 kHz zależnie od IMU/filtra
filtr/rate PID	1–4 kHz po pomiarze WCET
attitude	250–1000 Hz
barometr	25–100 Hz
GNSS	5–20 Hz
log	zależnie od nośnika i budżetu

To nie są wartości obowiązkowe. Wybiera się je na podstawie dynamiki, szumu, opóźnienia sensora i budżetu CPU. Pętla 8 kHz z niedeterministycznymi deadline jest gorsza od stabilnej 2 kHz.

Histogram czasu iteracji, max lateness i missed deadlines jest rejestrowany. GPIO debug ustawiane na początku/końcu pozwala mierzyć oscyloskopem niezależnie od logu.

Estymacja i regulatory#

Minimalny bezpieczny etap laboratoryjny może użyć:

kalibracji bias/scale IMU;
filtra komplementarnego lub Mahony dla attitude;
kwaternionu zamiast singularnych kątów Eulera;
PID rate oraz zewnętrznego angle loop;
anti-windup i ograniczeń miksera;
jawnej detekcji NaN/Inf i saturacji.

Pełny EKF pozycji nie powinien być pierwszym celem. Najpierw należy dowieść stabilnego próbkowania, timestampów i pętli rate. Nawigację można rozwijać po przejściu testów HIL.

Bez FPU należy profilować każdą funkcję. Aproksymacje trygonometryczne muszą mieć znany błąd. Normalizacja kwaternionu ma ochronę przed zerową/niepoprawną normą. Parametry PID mają zakresy i wersjonowanie.

Watchdog i reset#

Sprzętowy watchdog resetuje układ po braku karmienia. Nie może być karmiony z przypadkowego ticka. Nadzorca sprawdza heartbeat core 0, core 1, IMU sequence i output driver. Dopiero komplet zdrowych warunków odnawia watchdog.

Przed resetem nie zawsze da się wykonać kod, dlatego hardware musi ustawić wyjścia w stan nieaktywny. ESC ma własny timeout. Po restarcie przyczyna resetu jest logowana, a system pozostaje disarmed.

Testy obejmują zatrzymanie każdego rdzenia, zawieszenie DMA, brak IMU i deadlock spinlocka. Jeśli tylko core 1 przestaje odpowiadać, polityka może utrzymać stabilizację przez krótki czas, ale brak RC/GNSS prowadzi do failsafe. Watchdog całego układu nadal ma termin ostateczny.

Blackbox i pamięć#

Wewnętrzny flash XIP nie jest idealnym blackboxem. Erase ma długi czas i blokuje dostęp. Lepszy jest zewnętrzny SPI NOR/FRAM lub karta SD obsługiwana poza krytyczną domeną, z dużym ring bufferem i polityką drop.

Minimalny log:

timestamp/sequence IMU;
surowe i filtrowane gyro/accel;
attitude oraz setpoint;
PID P/I/D i saturacja miksera;
komendy/wyjścia silników;
RC age/failsafe;
napięcia i brownout flags;
execution time/deadline miss;
health DMA/PIO/watchdog.

Rekordy binarne mają stały format i CRC bloków. Metadata zawiera wersję firmware, hash parametrów i skalowanie. Zapis nie może blokować core 0.

PCB i zasilanie#

Pico jako moduł jest dobry do prototypu stołowego, ale finalny FC wymaga własnej PCB albo mechanicznie zabezpieczonego modułu. Dokument Hardware design with RP2040 opisuje zasilanie, QSPI flash, kryształ, USB i layout.

Domeny:

bateria → regulator 5 V/BEC → 3.3 V logic
                    │
                    ├─ RP2040 + flash
                    ├─ IMU clean rail / filtr
                    ├─ GNSS/radio według budżetu
                    └─ osobna szyna serw, jeśli potrzebna

IMU wymaga sztywnego mechanicznie obszaru, poprawnego decouplingu i oddalenia od przetwornicy. Masę prowadzi się tak, aby prąd ESC/serw nie płynął przez referencję sensora. USB ESD, SWD, boot select i testpoints ułatwiają serwis.

RP2040 ma wewnętrzny regulator rdzenia i określone wymagania kondensatorów. QSPI ścieżki są krótkie i zgodne z zaleceniami. Kryształ/zegar musi mieć przewidzianą stabilność dla USB i timingów.

Minimalny projekt sprzętowy#

Minimalny użyteczny FC laboratoryjny:

RP2040 + zgodny QSPI flash;
stabilny zasilacz 3,3 V i supervisor/brownout monitor;
IMU SPI z DRDY;
barometr I²C/SPI;
złącze GNSS + magnetometr;
pełny UART RC i UART telemetry/GNSS według priorytetu;
cztery wyjścia PIO DShot i wejścia bidirectional opcjonalnie;
wyjścia PWM serw;
zewnętrzny blackbox;
USB, SWD, przycisk boot/reset;
pomiar napięcia i prądu;
buzzer/LED stanu niezależne od uzbrojenia.

Brak złącza nie może być później „naprawiany” losowym przewodem na wejściu o nieznanym poziomie. Pinout, kierunki i napięcia opisuje dokument interfejsów.

Program uruchomienia#

Zasilanie: prąd spoczynkowy, ripple, reset i brownout.
Zegar/flash: boot powtarzalny w temperaturze.
GPIO: bezpieczne stany wszystkich wyjść.
Monotoniczny timer i debug pulse.
SPI IMU polling, następnie DRDY+DMA.
Kalibracja i statystyka szumu na stole.
PIO/PWM na analizatorze bez ESC.
DShot do ESC bez śmigieł, timeout i eRPM.
RC parser oraz failsafe z odłączonym napędem.
Estymator w replay i HIL.
PID na stanowisku jednego stopnia swobody.
Captive/tethered test małej platformy w bezpiecznym środowisku.
Stopniowe zwiększanie envelope z kryteriami abort.

Każdy etap ma kryterium zaliczenia. Nie przechodzi się do lotu, jeśli występują niewyjaśnione reset, deadline miss albo błąd DMA.

Testy czasu rzeczywistego#

WCET każdej fazy pętli przy code/flash cache miss;
jednoczesne USB, telemetry, GNSS i zapis blackbox;
pełny rate IMU i wszystkich DMA;
konflikt PIO/DMA i sztuczne opóźnienia core 1;
24-godzinny soak z monitorowaniem sequence;
temperatura i napięcie graniczne;
fuzz parserów UART przy zachowanej stabilizacji;
zatrzymanie IMU, core, PIO i DMA;
watchdog reset oraz bezpieczne wyjścia;
HIL z replay drgań i gwałtownych manewrów.

Kryteria obejmują brak utraty próbek ponad limit, max jitter, stack watermark, brak niekontrolowanego wyjścia i poprawny log przyczyny.

Ograniczenia i decyzja#

zaleta	koszt/ograniczenie
PIO o deterministycznym I/O	mała pamięć programu i ograniczona liczba state machines
12 DMA	przydział i IRQ wymagają starannego projektu
dwa rdzenie	synchronizacja i wspólne zasoby
niski koszt i dostępność	mniej peryferiów lotniczych niż STM32H7
264 kB SRAM	mało dla dużego EKF/logów/stosu sieciowego
prosty SDK C/C++	brak dojrzałego ekosystemu autopilota równoważnego głównym targetom
elastyczne GPIO	brak wbudowanego CAN/FPU/ECC pamięci

RP2040 jest bardzo dobrym układem do nauczenia się budowy kontrolera od zera i do wyspecjalizowanych węzłów. Może stabilizować mały UAV, jeśli kod i hardware są rygorystycznie ograniczone oraz przetestowane. Jeżeli wymaganiem jest pełny ArduPilot/PX4, wiele CAN, ciężki EKF i redundancja sensorów, rozsądniej wybrać wspierany STM32F7/H7 lub potraktować RP2040 jako procesor I/O.

Najważniejszym kryterium nie jest możliwość uruchomienia PID w demonstracji. Jest nim zachowanie deadline, świeżości danych i bezpiecznych wyjść przy jednoczesnym logowaniu, błędach sensorów, zakłóceniach i resetach.

Powiązane tematy#

Przypisy#

Raspberry Pi, RP2040 Datasheet, https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf (dostęp: 15 sierpnia 2026).
Raspberry Pi, Hardware design with RP2040, https://datasheets.raspberrypi.com/rp2040/hardware-design-with-rp2040.pdf (dostęp: 15 sierpnia 2026).
Raspberry Pi, Pico C/C++ SDK, https://github.com/raspberrypi/pico-sdk (dostęp: 15 sierpnia 2026).
Raspberry Pi, Programmable I/O API, https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/hardware_pio/include/hardware/pio.h (dostęp: 15 sierpnia 2026).
Raspberry Pi, Pico SDK examples, https://github.com/raspberrypi/pico-examples (dostęp: 15 sierpnia 2026).

Źródła z centralnego rejestru

Raspberry Pi: RP2040 Datasheet [datasheet producenta]
Raspberry Pi: Hardware design with RP2040 [dokumentacja producenta]
Raspberry Pi Pico C/C++ SDK [repozytorium producenta]
Raspberry Pi Pico SDK: Programmable I/O API [dokumentacja i kod producenta]
Raspberry Pi Pico SDK examples [repozytorium producenta]
Sumit Sharma, „Drone Development from Concept to Flight” [książka]
Terry Kilby, Belinda Kilby, „Make: Drony dla początkujących” [książka]