Crazyflie jako platforma badawcza

Crazyflie 2.1+ jest otwartą platformą badawczą wielkości dłoni, a nie miniaturowym odpowiednikiem Pixhawka. Płyta główna, napęd, radio, bootloadery, firmware i biblioteki klienta tworzą spójny system przeznaczony do szybkiej iteracji eksperymentów. W standardowej konfiguracji waży około 29 g, lata na szczotkowych silnikach z akumulatorem 1S i udostępnia STM32F405 jako główny procesor oraz nRF51822 jako radio/power-management MCU.[1][2]

Wartość naukowa Crazyflie wynika z powtarzalności, otwartych źródeł i ekosystemu decków: optical flow, range, Lighthouse, UWB, mocap markers, AI i sensory środowiskowe. Ograniczenia są równie ważne: mały zapas energii i payloadu, brak GNSS w bazie, wrażliwość na prop wash, ograniczona moc obliczeniowa i współdzielone radio. Dobrze użyty system pozwala badać estymację, sterowanie i roje; źle użyty produkuje efektowne demonstracje bez powtarzalnych danych.

Spis treści#

Dlaczego platforma badawcza
Warianty sprzętowe
Crazyflie 2.1 Plus
Crazyflie 2.1 Brushless
Architektura dual MCU
STM32F405
nRF51822
Sensory bazowe
Napęd i dynamika
Zasilanie i bateria
Łącze radiowe i BLE
CRTP
Firmware
Estymatory
Kontrolery
Parametry i logi
Deck bus
Automatyczne wykrywanie decków
Konflikty zasobów
Flow deck
Lighthouse
Loco UWB
Motion capture
Swarm i skalowanie
Czas i synchronizacja
ROS i biblioteki
Własny kod pokładowy
Własny deck
Projekt poprawnego eksperymentu
Metryki sterowania
Fault injection
Bezpieczeństwo laboratorium
Ograniczenia platformy
Typowe błędy
Powiązane tematy
Przypisy

Dlaczego platforma badawcza#

Platforma badawcza powinna zmniejszać liczbę niewiadomych między hipotezą i pomiarem. Crazyflie dostarcza:

publiczne schematy hardware;
otwarte firmware i biblioteki hosta;
powtarzalny airframe;
znany protocol i telemetry API;
wymienne decki o zdefiniowanym interfejsie;
systemy pozycjonowania indoor;
możliwość bezprzewodowego flashowania;
małą energię kinetyczną w porównaniu z większym UAV;
dostęp do tych samych zmiennych w wielu egzemplarzach.

To skraca drogę od algorytmu do lotu. Nie usuwa jednak obowiązku identyfikacji modelu, kalibracji i walidacji. Dwa egzemplarze różnią się silnikami, śmigłami, baterią, biasami IMU i masą decków. Jeśli eksperyment nie zapisuje tych różnic, wynik może być efektem partii hardware.

Crazyflie jest szczególnie przydatny do:

estymacji attitude/position;
nowych regulatorów;
trajectory tracking;
visual/UWB/Lighthouse localization;
swarm coordination;
distributed sensing;
human–robot interaction;
nauczania systemów czasu rzeczywistego;
testu firmware i komunikacji;
porównania algorytmów na identycznym airframe.

Nie jest właściwym modelem dla aerodynamiki dużego fixed-wing, napędu o wysokim Reynoldsie, systemów z ciężkim payloadem ani pełnej kwalifikacji sprzętu lotniczego. Wyniki trzeba ostrożnie skalować.

Warianty sprzętowe#

Rodzina 2.x obejmuje bazowy Crazyflie 2.1+, nowszy Crazyflie 2.1 Brushless oraz płytki pokrewne, np. Bolt/Roadrunner w ekosystemie firmware. Artykuł koncentruje się na 2.1+ jako najbardziej typowym mikroquadrocopterze i wskazuje różnice Brushless.

Nie należy mylić:

Crazyflie 1.0 — stara generacja, której ostatnim wspierającym release firmware był według repozytorium 2017.06;[3]
Crazyflie 2.1 — wcześniejsza wersja bazowa;
Crazyflie 2.1+ — rozwinięcie z nową baterią/śmigłami i wzmacniaczem RF;
Crazyflie 2.1 Brushless — inny napęd i większy payload;
Crazyflie Bolt — kontroler do własnego airframe, nie gotowy mikroquadrocopter.

W badaniu pełna nazwa produktu, hardware revision, firmware release i deck revisions muszą znaleźć się w metadanych.

Crazyflie 2.1 Plus#

Producent podaje:[1][2]

Parametr	Crazyflie 2.1+
takeoff mass	29 g
rozmiar	około 92 × 92 × 29 mm
FMU	STM32F405, 168 MHz, 192 KB SRAM, 1 MB flash
radio/power MCU	nRF51822, 32 MHz, 16 KB SRAM, 128 KB flash
IMU	BMI088 accel/gyro
barometr	BMP388
radio	2,4 GHz proprietary link + BLE
bateria bazowa	1S, zestaw producenta
deklarowany czas lotu	około 7 min
deklarowany max payload	15 g
ładowanie	onboard USB, typowo około 40 min dla stock battery

Są to dane producenta w warunkach jego konfiguracji. 15 g payload to rekomendowana granica, nie gwarancja 7 minut lotu. Deck zwiększa drag i przesuwa środek masy. Zużyte silniki szczotkowe oraz battery sag zmniejszają możliwości.

Wzmacniacz RF do 20 dBm i U.FL zwiększają potencjalny zasięg, ale test >1 km LOS nie jest gwarancją operacyjną.[1] Lokalny limit EIRP, antenna gain, interference i legalność częstotliwości trzeba sprawdzić. Mikro-UAV nie powinien być testowany poza kontrolowanym obszarem tylko dlatego, że link działa daleko.

Crazyflie 2.1 Brushless#

Brushless jest pełnoprawnym wariantem badawczym, nie tylko wymianą silników. Producent podaje cztery silniki 08028 10000 KV, zintegrowane 1S ESC do 5 A z BLHeli_S/Bluejay, 55 mm propellers, około 10 min lotu i max recommended stock payload 40 g.[9]

Masa startowa z legs około 34 g lub 37 g z guards według datasheet. Większa rezerwa thrust umożliwia:

cięższe decki;
większy acceleration envelope;
dłuższy lot;
badania aerial manipulation;
lepszą odporność na umiarkowany przepływ powietrza.

Zmienia się jednak model:

ESC ma własne firmware i dynamics;
motor electrical time constant jest inny;
DShot/PWM i update rate wpływają na delay;
vibration spectrum jest inne;
prop guards i masa zmieniają inertia;
bateria 350 mAh ma inny sag;
payload limit nie oznacza, że środek masy może być dowolny.

Eksperyment porównujący brushed i brushless nie może używać tych samych gains bez identyfikacji. To dwie platformy w jednym ekosystemie software.

Architektura dual MCU#

Crazyflie rozdziela funkcje:

host / Crazyradio / BLE
          ↕
      nRF51822
 radio + BLE + power management
          ↕ internal link
      STM32F405
 sensors + estimator + controller + decks
          ↓
       motor drivers

nRF pozostaje aktywny jako komunikacja i zarządzanie zasilaniem, podczas gdy STM32 wykonuje flight stack. Osobne repozytorium crazyflie2-nrf-firmware zawiera kod nRF, a crazyflie-firmware kod aplikacyjny STM32.[3]

Korzyści:

radio timing nie obciąża bezpośrednio pętli sterowania;
BLE i proprietary radio mogą dzielić SoC;
bezprzewodowy bootloader/update;
zaawansowane eksperymenty peer-to-peer;
power button/charging logic oddzielona od flight tasks.

Ryzyka:

dwa obrazy firmware i kompatybilność protocol;
queueing między MCU;
różne zegary;
utrata linku wewnętrznego;
restart jednego MCU;
ograniczona przepustowość do hosta.

Log diagnostyczny powinien zawierać wersję obu firmware, nie tylko aplikacji STM32.

STM32F405#

STM32F405 Cortex-M4F przy 168 MHz i 192 KB SRAM jest wystarczający do kilkusethercowych/kilohertzowych pętli, EKF, komunikacji i deck drivers, ale ma ograniczony margines dla wizji komputerowej. AI deck przenosi cięższe obliczenia na własny GAP8/ESP, zamiast wykonywać je na STM32.

Firmware wykorzystuje RTOS i zadania o priorytetach. Typowe ścieżki:

IMU interrupt/read
  → sensor task/filter
  → estimator
  → setpoint manager
  → attitude/rate controller
  → power distribution/motor command

Dodanie własnego tasku może naruszyć deadline. Mierzyć trzeba execution time, stack i jitter. Blocking I2C albo formatowanie tekstu w high-priority task jest błędem.

1 MB flash pozwala na bogaty firmware, lecz Kconfig wybiera funkcje. Custom build powinien zapisać commit, config i toolchain. Moduł dostępny jako parametr runtime nie musi być wkompilowany.

nRF51822#

nRF51822 Cortex-M0 obsługuje 2,4 GHz, BLE i zarządzanie power. Ma znacznie mniej RAM/flash niż STM32. Jego zadaniem nie jest uruchamianie głównego kontrolera.

Funkcje badawcze:

Crazyradio link;
BLE mobile control;
peer-to-peer packets;
bootloader transport;
antenna selection;
power state i button.

Radio packet scheduling wpływa na swarm scaling. Jeden dongle ma skończoną airtime i USB latency. Większa liczba dronów wymaga podziału kanałów/rates i ograniczenia logów.

Zewnętrzne deck pins połączone z nRF mają inne ograniczenia niż STM32 pins. Datasheet ostrzega, że piny nRF oraz PA5 nie są 5 V tolerant, mimo że wiele innych I/O jest.[1][2] Custom deck musi mieć level compatibility 3,0 V.

Sensory bazowe#

Crazyflie 2.1+ ma BMI088 i BMP388.[1] BMI088 integruje osobne accel i gyro dies w jednym package family, z interfejsem cyfrowym. BMP388 daje ciśnienie do względnej wysokości.

Brak w bazie:

magnetometru;
GNSS;
rangefindera;
optical flow;
absolute indoor positioning.

Sama IMU daje orientation i krótkoterminową propagację, ale position drift rośnie. Stabilny hover position wymaga decku lub external position.

W małym airframe IMU jest blisko silników. Drgania, commutation brushed, frame contact i uszkodzone śmigło szybko zwiększają noise. Analizować należy:

accel/gyro PSD;
clipping;
bias warm-up;
sample rate/jitter;
estimator innovations;
battery/motor correlation.

Barometr w indoor jest wrażliwy na pressure pulses, HVAC i prop wash. Nie daje centymetrowego z-hold bez range/position aiding.

Napęd i dynamika#

Standard 2.1+ ma cztery szczotkowe coreless motors sterowane tranzystorowo PWM. Ich thrust zależy silnie od battery voltage, temperature, brush wear i propeller fit.

Uproszczony model:

motor PWM → electrical current → shaft speed → thrust ≈ kT · omega²
battery sag ↗            friction/brush wear ↘

Nie ma closed-loop RPM w bazowej konfiguracji. Ten sam command nie daje identycznego thrust między egzemplarzami. Firmware może kompensować napięcie, lecz motor-to-motor variation pozostaje.

Identyfikacja:

zważyć każdą platformę;
zmierzyć hover command przy pełnej i częściowej baterii;
wykonać thrust stand dla motor/prop sample;
zapisać motor hours lub liczbę lotów;
wymieniać zestawy według kryterium, nie intuicji;
dynamic balance/inspect propellers.

Moment bezwładności zmienia każdy deck. Deck na górze zwiększa z i może pogorszyć roll/pitch coupling. Payload powinien być wycentrowany.

Zasilanie i bateria#

Crazyflie jest systemem 1S. Onboard charger ma tryby 100, 500 i 980 mA według producenta.[1][2] Właściwy current zależy od baterii, USB source i thermal constraints.

Battery metrics:

open-circuit voltage;
loaded voltage/sag;
capacity z testu;
internal resistance;
cycle count;
temperature;
mass;
connector condition.

Lot nie powinien kończyć się dopiero hard brownout. Supervisor ustala low-voltage behavior. W swarm różne baterie powodują różny thrust margin i timing misji.

Deck VCC 3,0 V ma limit 100 mA. VCOM jest unregulated VBAT lub VUSB, z deklarowanym max 1 A. VUSB może być input/output zależnie od power state.[1] Custom deck musi uwzględnić:

minimum/maximum VBAT;
inrush;
regulator efficiency;
backfeed;
charging interaction;
ground noise;
100 mA limit VCC;
mass i thermal dissipation.

Nie zasila się AI/SBC z 3,0 V rail, jeśli przekracza limit. Deck z własnym regulatoriem bierze energię z VCOM zgodnie ze specyfikacją.

Łącze radiowe i BLE#

Crazyradio używa 2,4 GHz proprietary link o małym latency. BLE umożliwia prostą obsługę mobilną. Do badań preferowany jest Crazyradio 2.0/PA i komputer, bo daje pełne log/param/memory APIs.

Link budget jest funkcją:

received = TX power + TX antenna gain + RX antenna gain
         - path loss - body/deck shadowing - mismatch - interference

Crazyflie 2.1+ ma chip antenna oraz U.FL. External antenna zmienia pattern, masę i EIRP. U.FL ma ograniczoną liczbę cykli i łatwo go uszkodzić.

W indoor multipath powoduje burst losses. Nie wystarczy średni packet loss. Mierzyć:

longest outage;
RTT distribution;
command age;
log gaps;
channel occupancy;
interference od Wi-Fi/BLE;
scaling z liczbą dronów.

Onboard controller powinien utrzymywać stability bez ciągłego linku. Setpoint watchdog i supervisor określają reakcję po utracie hosta. Open-loop stream z laptopa nie może być jedynym stabilizatorem.

CRTP#

Crazy RealTime Protocol jest wspólną warstwą komunikacji nad radio lub USB. Dokumentacja opisuje porty dla console, parameters, logging, memory, localization i innych usług.[4]

application (cflib/cfclient)
       ↓
CRTP port/channel packets
       ↓
link abstraction
       ↓
Crazyradio / USB / BLE path

CRTP nie jest MAVLink. Ma mniejsze pakiety i API dopasowane do ograniczonej platformy. Warstwy klienta mapują TOC log/params i memory operations.

Wersjonowanie protocol jest ważne. Dokumentacja opisuje zasadę zgodności wersji: klient powinien rozumieć zakres obsługiwany przez firmware, a skok większy może oznaczać incompatibility.[4]

Własny CRTP port wymaga:

unikalnego ID/channel;
limitu packet rate;
queue policy;
timeout;
endian/serialization;
version field;
testów lost/reordered packets;
ochrony control task przed flood.

Radio nie zapewnia automatycznie niezawodnego transferu semantycznego. Param write, firmware update i memory access muszą mieć acknowledgments/checksums na swojej warstwie.

Firmware#

crazyflie-firmware jest aktywnie rozwijanym projektem C, z release 2026.04 jako najnowszym widocznym w repozytorium podczas weryfikacji.[3] Kod jest dzielony na drivers, modules, platform, config, tests i app API.

Główne obszary:

stabilizer;
estimators;
controllers;
commander/setpoints;
sensors;
deck drivers;
CRTP services;
parameters/logging;
memory subsystem;
supervisor;
power distribution.

Badanie powinno przypinać git commit/tag. master może zmienić controller, parameter default lub deck API. Reproducibility bundle zawiera:

firmware commit
Kconfig/build target
compiler/toolchain
nRF firmware version
deck firmware hashes
cflib/cfclient version
experiment code commit

Wireless flashing ułatwia iterację, ale może prowadzić do floty z mieszanymi wersjami. Przed eksperymentem skrypt powinien odczytać platform/firmware revision i przerwać przy niezgodności.

Estymatory#

Firmware udostępnia m.in. complementary estimator, extended Kalman filter oraz eksperymentalne opcje zależne od build. Parametr stabilizer.estimator wybiera tryb; dokumentacja API oznacza UKF jako eksperymentalny i wymagający Kconfig.[8]

Wybór zależy od sensorów:

attitude-only manual flight → complementary może wystarczyć;
Flow deck + range → EKF dla local position;
Lighthouse/UWB/mocap → EKF z external position;
eksperymentalny estimator → osobny build i baseline.

Estimator interfaces powinny przenosić measurement timestamp i covariance. External position wysłane po radio z opóźnieniem nie może być traktowane jako pomiar „teraz”. Mierzyć end-to-end latency mocap camera → host → Crazyradio → estimator.

Kryteria:

position/velocity error;
innovation whiteness;
covariance consistency;
reset count;
recovery po dropout;
sensitivity na geometry;
CPU time.

Ground truth nie powinien być tym samym pomiarem, który zasila estimator, chyba że badanie ocenia controller, a nie estimator. Lighthouse użyte do estimation nie jest niezależnym ground truth bez osobnego kanału.

Kontrolery#

Dokumentacja firmware wymienia PID, Mellinger, INDI, Brescianini i Lee controllers, przy czym dostępność może zależeć od build/config.[8]

Warstwy:

position error → velocity/acceleration target
velocity error → attitude/thrust target
attitude error → body rate target
rate error → motor moments
mixer → four motor commands

Nie każdy controller używa identycznej reprezentacji. Mellinger/Lee bazują na modelu trajectory/SE(3), INDI na incremental dynamics i pomiarach przyspieszeń, PID na kaskadzie. Porównanie wymaga:

tego samego estimator;
tej samej trajectory;
tych samych saturation limits;
jawnego mass/inertia;
identycznych batteries lub voltage normalization;
warm-up;
powtórzeń losowych;
raportu crashes/exclusions.

Tuning jednej platformy nie przenosi się idealnie na każdą. Mass deck i motor wear zmieniają plant. Gains powinny być zapisane jako param snapshot.

Parametry i logi#

Crazyflie udostępnia runtime parameter TOC i log TOC. Host może odczytywać, zmieniać i zapisywać wartości oraz subskrybować zmienne.

Parametry są dobre do:

gains;
estimator/controller selection;
deck configuration;
supervisor limits;
experiment mode;
persistent calibration.

Nie są dobrą metodą przesyłania high-rate setpointów, jeśli API commander ma dedykowane packet types.

Log blocks mają ograniczony rozmiar i rate. Więcej zmiennych zwiększa airtime. Swarm z pełnymi logami szybko nasyca link. Należy wybrać minimum:

state estimate;
setpoint;
control output;
battery;
radio quality;
sensor/position quality;
experiment marker;
deck status.

Timestamp hosta przy odbiorze nie jest czasem próbki. Jeśli log packet nie zawiera pełnej semantyki czasu, trzeba odtworzyć ją z firmware tick i zsynchronizować z hostem.

Deck bus#

Expansion connector jest wyprowadzony na górę i dół. Obejmuje:[1]

3,0 V do 100 mA;
GND;
VCOM unregulated;
VUSB;
I2C 400 kHz;
SPI;
dwa UART;
cztery GPIO/chip select;
1-Wire identification;
dwa GPIO nRF51.

Deck nie jest zwykłym shieldem 3,3/5 V. System ma 3,0 V logic high. Większość STM32 I/O jest 5 V tolerant, ale PA5 i nRF pins nie są; input threshold urządzenia 3,3 V trzeba sprawdzić.

Deck stacking jest możliwy mechanicznie, ale zasoby są współdzielone. Dwa decki mogą żądać tego samego UART lub GPIO. Power i masa rosną. Optyczny deck może zostać zasłonięty przez inny.

Top/bottom orientation wpływa na sensor axes i FOV. Driver powinien znać mount i calibration.

Automatyczne wykrywanie decków#

Decki używają pamięci 1-Wire do identyfikacji. Format zawiera VID/PID, bitmaskę używanych pinów, CRC oraz key/value data, np. name, revision i calibration.[5]

Boot flow:

enumerate OneWire memories
→ validate header CRC
→ read VID/PID/revision/usedPins
→ detect conflicts
→ locate matching driver
→ initialize/self-test
→ expose deck parameter/log status

System nie powinien startować niebezpiecznie, jeśli dwa decki konfliktują. Forced driver przez Kconfig jest użyteczny dla development deck bez EEPROM, ale omija część auto-detection i wymaga jawnego config.

Nowy subsystem deck memory pozwala także enumerować firmware na deckach, wskazać required hash/length, stan bootloadera i wykonać upgrade, zależnie od deck capability.[6] To ważne dla AI deck/Lighthouse, gdzie kilka MCU ma osobne obrazy.

Eksperyment musi zapisać deck VID/PID/revision i firmware hash. Nazwa „Flow deck v2” bez firmware nie wystarcza.

Konflikty zasobów#

Deck driver deklaruje usedGpio i usedPeriph. Konflikty mogą dotyczyć:

UART1/UART2;
SPI chip select;
I2C address;
GPIO/interrupt;
nRF pins;
VCC current;
physical occlusion;
total payload;
radio bandwidth;
firmware flash/RAM.

Walidator powinien wykryć resource conflict przed uzbrojeniem. Niektóre konflikty są elektryczne i mogą uszkodzić piny, jeśli dwa outputs są zwarte.

Power budget:

Σ I_3V_decks ≤ 100 mA minus reserve
Σ P_VCOM affects battery flight time and sag
mass_total ≤ qualified payload

Dwa decki osobno działające mogą razem powodować brownout. AI deck ma duży pobór i RF, Lighthouse wymaga visibility, Flow wymaga widoku w dół. Stack design jest wielokryterialny.

Flow deck#

Flow deck łączy optical flow z range sensor skierowanym w dół. Umożliwia lokalny hover bez external infrastructure nad teksturowaną powierzchnią.

Flow measurement daje angular pixel motion. Przeskalowanie do ground velocity zależy od height, attitude i calibration:

v_ground ≈ flow_rate · height / focal_scale

Warunki:

tekstura i oświetlenie;
height w zakresie range sensor;
ograniczona prędkość/blur;
czysta optyka;
ground approximately planar;
kompensacja rotation z gyro;
timestamp alignment.

Flow nie daje globalnej pozycji. Pozycja dryfuje przy całkowaniu velocity. Można utrzymywać lokalny hover, ale powrót do laboratory coordinate wymaga Lighthouse/UWB/mocap.

Badanie zapisuje quality metric, range validity i raw flow. Failure injection obejmuje jednolitą podłogę, zmianę światła, wyjście poza range i nagły yaw.

Lighthouse#

Lighthouse deck odbiera sweep angles z SteamVR base stations. Znając calibration i geometry baz, Crazyflie oblicza pozycję onboard. Po konfiguracji komputer nie jest potrzebny do każdej aktualizacji position.[7]

Bitcraze podaje dla V2 około 6 m range, około 50 Hz, szerszy FOV i obsługę kilku baz; firmware standardowo konfiguruje do czterech, a hardware może skalować dalej z custom build. V2 jest aktywnie rozwijanym profilem.[7]

Pipeline:

base station laser sweep
→ deck photodiodes + timestamps
→ angles per sensor/base
→ geometry/calibration model
→ crossing beams or sweep model
→ position/pose measurement
→ onboard EKF

Wymaga line of sight. Direct sunlight, lustra, szkło i zasłonięcie przez deck stack pogarszają dane. Geometry bases musi być dokładna i zapisana.

Bitcraze raportuje sub-mm relative precision w dobrym 5 × 5 m setup i absolute accuracy rzędu poniżej 10 cm, ale te wartości są zależne od geometrii i nie są gwarancją każdego laboratorium.[7] Należy zmierzyć własny field error map.

Jeśli Lighthouse zasila EKF, do ground truth użyć niezależnego mocap albo precyzyjnego fixture. Log delta/beam residual pomaga wykrywać słabą geometrię.

Loco UWB#

Loco Positioning używa DWM1000 UWB anchors i tag deck. Pozycja może być liczona onboard. Tryby:[7]

Tryb	Mechanizm	Skala tagów	Ograniczenia
TWR	tag aktywnie mierzy range do anchors	zwykle jeden tag w opisanym schedulerze	większy airtime, do 8 anchors
TDoA2	tag pasywnie słucha zsynchronizowanych anchors	wiele tagów	do 8 anchors, wymagany volume geometry
TDoA3	randomizowany schedule anchors	wiele tagów	więcej anchors, inna konfiguracja

Producent opisuje dokładność rzędu 10 cm zależną od setup/environment. UWB ma multipath i NLOS positive bias. Metal, ludzie i antenna orientation zmieniają wyniki.

Minimum geometry 3D teoretycznie wymaga czterech anchors, ale praktycznie sześć–osiem daje redundancy i lepsze DOP.[7] Anchors muszą mieć dokładnie zmierzone coordinates i wspólny frame.

Swarm korzysta z TDoA, bo tags są pasywne i nie zwiększają airtime anchor system tak jak TWR. Nie znaczy to nieskończonej skali: Crazyradio C2/logging, collision avoidance i compute host nadal ograniczają liczbę.

Motion capture#

Mocap oblicza position/pose na zewnętrznym komputerze i wysyła pomiar przez radio. Daje dokładny ground truth, ale tworzy latency pipeline:

camera exposure
→ reconstruction
→ rigid body solve
→ network/host callback
→ Crazyradio queue
→ CRTP localization packet
→ estimator update

Timestamp pomiaru jest na początku, nie przy odbiorze. Jeśli firmware nie kompensuje delay, szybki lot ma phase lag. Mierzyć median, p95 i maximum age.

Marker deck zwiększa mass/drag i może zostać zasłonięty. Rigid body geometry powinna być asymetryczna, aby uniknąć ambiguity.

Do testu controller mocap może być estimator input i osobno logowany ground truth, ale wtedy niezależność jest ograniczona. Lepszy setup ma dwa systemy albo raw mocap używany do prawdy, podczas gdy Crazyflie estymuje z Lighthouse/UWB.

Swarm i skalowanie#

Rój wymaga skalowania czterech zasobów:

radio airtime;
host USB/scheduler;
pozycjonowanie;
przestrzeń i collision management.

Przy N dronach:

airtime ≈ Σ(command_rate_i · bytes_i + log_rate_i · bytes_i + retries_i)

Nie można utrzymać single-drone log profile dla 50 sztuk. Komendy trajectory można wysłać wcześniej i uruchomić time-synchronized, zamiast streamować setpoint do każdego w każdej próbce.

TDoA UWB i Lighthouse obliczane onboard skalują position delivery lepiej niż centralny mocap stream, ale geometry i visibility nadal ograniczają przestrzeń. Base station/anchor failures trzeba obsłużyć.

Swarm experiment potrzebuje:

unique radio URI/address;
channel/data-rate assignment;
firmware hash allowlist;
synchronized start;
per-vehicle state/health;
exclusion zone i emergency stop;
battery sorting;
automatic abort on missing member;
collision constraints;
post-run log alignment.

Single broadcast emergency stop musi być niezależny od głównego orchestration, a jednocześnie odporny na przypadkowe uruchomienie. Testuje się go przy full channel load.

Czas i synchronizacja#

Porównywanie trajectory z logiem wymaga wspólnego czasu. Źródła:

STM32 tick;
nRF radio timing;
host monotonic clock;
mocap clock;
Lighthouse sweeps;
UWB anchor timebase;
deck MCU clocks.

Host receive timestamp ma zmienne USB/radio delay. Synchronizację można estymować przez round-trip i model affine:

t_host ≈ offset + scale · t_cf

scale reprezentuje drift. Dla dłuższych eksperymentów offset trzeba aktualizować. Event marker wysłany do wszystkich pojazdów może mieć różną latency; lepiej pre-load trajectory i uruchomić przy lokalnym future tick, jeśli API wspiera.

Raport powinien podać synchronisation method i measured error. Bez niej wykres phase lag może być artefaktem timestampów.

ROS i biblioteki#

cflib Python zapewnia discovery, connection, log, params, memory i commander. ROS/ROS 2 bridges integrują Crazyflie z większym systemem, ale dodają queueing i frame conventions.

Kontrakt:

frame map/odom/base_link;
ENU/NED conversion;
units;
timestamp source;
QoS;
command timeout;
vehicle ID namespace;
estimator source;
emergency state.

ROS message „position setpoint” nie gwarantuje, że platforma odebrała go na czas. Trzeba monitorować end-to-end age i acknowledgement/state.

Python GIL i OS scheduling nie nadają się do hard real-time inner loop. Stabilizacja pozostaje na STM32. Host planuje trajectory, wysyła high-level commands i zbiera dane.

W eksperymencie container/lockfile zapisuje versions. pip install latest niszczy powtarzalność.

Własny kod pokładowy#

App layer pozwala dodać kod bez głębokiego forka core, zależnie od API. Dobry custom module:

ma jawny task period/deadline;
nie blokuje high-priority tasks;
używa existing estimator/setpoint interfaces;
publikuje log variables;
ma params z ranges;
ma watchdog/timeout;
jest testowalny jednostkowo;
przechodzi style/CI.

Przykładowy bezpieczny eksperyment laboratoryjny — ograniczenie setpointu do klatki:

setpoint.position.x = clamp(setpoint.position.x, -1.0f, 1.0f);
setpoint.position.y = clamp(setpoint.position.y, -1.0f, 1.0f);
setpoint.position.z = clamp(setpoint.position.z,  0.2f, 1.5f);

if (!position_is_valid || command_age_ms > 200) {
    supervisor_request_land();
}

To szkic logiki, nie gotowy patch do firmware; nazwy API trzeba dopasować do konkretnego release. Wymagane są SITL/test rig i propeller-off bench przed lotem.

Nie modyfikuje się jednocześnie estimator, controller, radio i motor model w jednym eksperymencie. Trudno wtedy ustalić przyczynę.

Własny deck#

Workflow:

Zdefiniować sensor/actuator, bandwidth, latency i power.
Wybrać I2C/SPI/UART/GPIO bez konfliktów.
Sprawdzić 3,0 V logic oraz 5 V tolerance każdego pinu.
Zaprojektować regulator z VCOM, jeśli >100 mA.
Użyć KiCad template i prawidłowego stack connectora.
Dodać 1-Wire memory z VID/PID, used pins, revision i CRC.
Napisać deck driver z init/self-test.
Udostępnić log/param/memory API.
Zmierzyć mass, center of gravity i flight time.
Wykonać EMI, brownout i conflict tests.

Driver deklaruje zasoby, aby system wykrył conflict. init() nie powinien zakładać obecności bez poprawnego VID/PID. Self-test zwraca konkretny fault.

Deck z własnym firmware powinien używać memory subsystem do wersjonowania/upgrade, jeśli jest obsługiwany. Hash core–deck compatibility zapobiega uruchomieniu niezgodnych protokołów.[6]

Mechanicznie długie piny mogą zasłonić Lighthouse sensors. Bottom deck musi mieć clearance od podłoża i prop wash.

Projekt poprawnego eksperymentu#

Hipoteza#

Przykład: „INDI obniży RMS position error w bocznym podmuchu o co najmniej 20% względem PID przy tej samej platformie i estimatorze”. To jest falsyfikowalne. „INDI lata lepiej” nie jest.

Zmienne kontrolowane#

ten sam Crazyflie lub randomizacja egzemplarzy;
battery state/internal resistance;
mass/CG;
propeller/motor condition;
firmware commit;
estimator i positioning;
trajectory;
airflow;
room geometry;
log profile.

Powtórzenia#

Wykonać wiele prób, randomizować kolejność controllerów, raportować odrzucone loty i przyczyny. Jeden najlepszy przebieg nie jest wynikiem.

Ground truth#

Użyć niezależnego mocap albo osobnego systemu. Zmierzyć latency i accuracy. Kalibrować transform frame.

Artefakty#

Udostępnić:

manifest.yaml
firmware.bin + commit/config
nrf/deck firmware versions
param dump
trajectory
raw logs
calibration/geometry
analysis script + environment lock
hardware inventory

Bez raw logs odbiorca nie zweryfikuje filtracji i wykluczeń.

Metryki sterowania#

Dla trajectory r(t) i estimate/ground truth p(t):

e(t) = p(t) - r(t)
RMSE = sqrt(mean(||e||²))
max_error = max(||e||)
IAE = integral ||e(t)|| dt

Dodatkowo:

settling time;
overshoot;
phase delay;
control effort/RMS motor command;
saturation fraction;
battery energy;
estimator innovation;
dropout time;
crash/abort rate;
success confidence interval.

RMSE estimate-to-reference może wyglądać dobrze, gdy estimator jest błędny, ale controller śledzi jego stan. Dlatego metrykę liczy się względem ground truth.

W swarm:

formation error;
minimum pair distance;
synchronization error;
packet delivery distribution;
member dropout;
convergence time;
airtime per vehicle.

Raportować distribution, nie tylko mean. Long-tail radio outage jest ważniejszy dla safety niż średni RTT.

Fault injection#

Bezpieczne fault injection zaczyna się w symulacji i na stanowisku.

Scenariusze:

drop external position packets;
add delay/jitter;
bias/ramp range measurement;
occlude Lighthouse base;
remove UWB anchor;
command timeout;
radio burst loss;
battery sag model;
motor effectiveness reduction w symulatorze;
deck not started/firmware mismatch;
parameter corruption rejected by range.

Każdy fault ma onset time, magnitude, duration i expected response. Wynik obejmuje detection latency, max deviation, recovery i false positives.

Fizyczne odcięcie jednego silnika w locie małego quadrotora zwykle prowadzi do upadku i nie wnosi więcej niż symulacja/bench. Testuje się to tylko w osłoniętej klatce z jednoznacznym uzasadnieniem i bez osób w volume.

Po position dropout platforma powinna przejść do określonego supervisor state. „Keep last setpoint forever” jest złe. Timeout zależy od estimator drift i cage size.

Bezpieczeństwo laboratorium#

Mała masa ogranicza energię, ale śmigła mogą zranić oczy i uszkodzić sprzęt. Procedura:

flight cage lub wyznaczony volume;
okulary ochronne przy bliskich testach;
prop guards;
żadnych luźnych włosów/przewodów;
emergency stop znany operatorowi;
test kill przy full radio load;
battery bag i inspekcja LiPo;
limit altitude/position;
jedna osoba odpowiedzialna za arm;
odłączone propellers przy bench;
automatyczne land/stop po stale setpoint/position.

Swarm zwiększa ryzyko przez liczbę obiektów. Operator nie przejmie ręcznie 30 dronów. Supervisor musi działać onboard i per-vehicle.

Lighthouse laser/base stations i mocap mają własne wymagania producenta. UWB/radio muszą pracować zgodnie z lokalnymi regulacjami.

Ograniczenia platformy#

Energia i czas#

7 minut producenta jest krótkie dla eksperymentu; logging, deck i battery wear skracają. Trzeba planować automatic landing i szybki battery swap.

Payload#

15 g to duży ułamek masy 29 g. Zmienia inertia, thrust-to-weight i czas. Brushless ma większy limit, lecz także inny model.

Brak globalnej pozycji#

Bez deck/infrastructure Crazyflie nie ma position hold. Flow daje lokalny velocity, ale dryfuje. Lighthouse/UWB/mocap wymagają przygotowania przestrzeni.

Compute#

F405 nie wykonuje nowoczesnej ciężkiej wizji. AI deck lub external computer są potrzebne, co dodaje latency/power.

Radio#

2,4 GHz jest współdzielone z Wi-Fi/BLE. Swarm i logi nasycają airtime. Deklarowany long range nie rozwiązuje indoor interference.

Aerodynamika skali#

Małe propellers i Reynolds, silniki szczotkowe oraz ground effect różnią się od dużych UAV. Regulator może nie skalować liniowo.

Hardware variation#

Motors/props/batteries zużywają się szybko. Potrzebny inventory i replacement criteria.

Brak pełnej certyfikacji#

Otwarta research platform nie jest certyfikowanym autopilotem do krytycznych operacji. Wyniki naukowe nie są dowodem airworthiness większego systemu.

Typowe błędy#

Traktowanie Crazyflie jak zabawki#

Bez manifestu wersji, kalibracji i logów eksperyment jest niereprodukowalny.

Streamowanie inner loop z Pythona#

OS/radio nie są hard real-time. Stabilizacja musi pozostać onboard.

Lighthouse jako jednocześnie estimator input i niezależna prawda#

To zawyża ocenę. Potrzebny mocap/independent measurement albo jasne ograniczenie badania.

Ignorowanie battery variation#

Sag zmienia thrust. Sortować baterie i logować voltage/current/proxy.

Deck bez power budgetu#

3,0 V rail ma 100 mA. Przeciążenie prowadzi do brownout lub noise.

Łączenie decków bez conflict check#

Wspólny UART/GPIO może powodować elektryczny konflikt. OneWire usedPins i driver declarations są istotne.

Używanie host receive timestamps#

USB/radio delay zafałszowuje phase. Potrzebna synchronizacja zegarów.

Przenoszenie gains 2.1 Plus do Brushless#

Napęd i dynamika są inne. Wymagana identyfikacja i tuning.

Maksymalny zasięg jako wymaganie operacyjne#

Test LOS producenta nie gwarantuje indoor link ani zgodności prawnej. Projektować według measured packet-age distribution.

Swarm bez onboard supervisor#

Centralny komputer nie zatrzyma bezpiecznie floty po radio congestion. Każdy pojazd potrzebuje timeout/limit.

Brak ewidencji deck firmware#

Core i deck mogą być niezgodne. Zapisywać hash i stan upgrade.

Analiza tylko udanych lotów#

Crash/abort rate jest metryką. Wykluczenia muszą być jawne i ustalone przed analizą.

Crazyflie jest wyjątkowo użyteczny wtedy, gdy traktuje się go jak instrument pomiarowy: identyfikuje hardware, kontroluje wersje, mierzy latency i błędy, publikuje raw data i oddziela system estymacji od ground truth. Mały rozmiar przyspiesza iterację, ale rygor badawczy pozostaje taki sam jak w większym UAV.

Powiązane tematy#

Przypisy#

Bitcraze, „Crazyflie 2.1+” — bieżąca specyfikacja platformy, radio, mechanika i expansion connector.
Bitcraze, „Crazyflie 2.1+ Datasheet Rev. 1” — MCU, sensory, zasilanie, czas lotu i payload.
Bitcraze, repozytorium crazyflie-firmware — kod, wydania, build i zakres platform.
Bitcraze, „CRTP — Communication with the Crazyflie” — warstwa transportu i porty usług.
Bitcraze, „Deck memory format” — OneWire VID/PID, used pins, CRC i auto-detection.
Bitcraze, „Deck memory” — enumeracja pamięci/firmware decków i mechanizm upgrade.
Bitcraze, dokumentacja systemów pozycjonowania Lighthouse i Loco UWB — geometria, tryby i deklarowane parametry.
Bitcraze, firmware parameter/controller documentation — dostępne estimators i controllers oraz status funkcji eksperymentalnych.
Bitcraze, „Crazyflie 2.1 Brushless” — napęd, masa, czas lotu i rekomendowany payload wariantu brushless.

Źródła z centralnego rejestru

Bitcraze: Crazyflie 2.1+ product page and specification [dokumentacja producenta i projektu open source]
Bitcraze: Crazyflie 2.1+ Datasheet Rev. 1 [datasheet producenta]
Bitcraze: crazyflie-firmware repository [repozytorium open source]
Bitcraze: CRTP communication protocol [dokumentacja projektu]
Bitcraze: Crazyflie deck memory format and automatic discovery [dokumentacja projektu]
Bitcraze: Positioning Systems Overview [dokumentacja projektu]
Bitcraze: Loco Positioning System [dokumentacja projektu]
Bitcraze: Lighthouse Positioning System [dokumentacja projektu]
Bitcraze: Crazyflie 2.1 Brushless specification [dokumentacja producenta]