Parrot ANAFI Ai — profil architektury

Parrot ANAFI Ai jest rzadkim przykładem seryjnego quadrocoptera, którego producent publikuje nie tylko instrukcję użytkownika, lecz również nazwy wielu sensorów, parametry toru łączności i programistyczny podział autopilota. Platforma waży 898 g, ma deklarowany czas lotu do 32 minut, kamerę 48 MP, ruchomą parę kamer stereoskopowych oraz dwa niezależne media komunikacyjne: Wi‑Fi i 4G LTE. Najciekawszą cechą dla inżyniera jest Air SDK, pozwalający uruchamiać własne procesy, zmieniać maszynę stanów misji i tworzyć tryby generowania trajektorii bez zastępowania krytycznego drone controller.[1][2][3][6]

Nie jest to jednak otwarty flight controller w stylu PX4. Producent publikuje dużą część interfejsów i kodu narzędziowego, lecz dolna pętla stabilizacji pozostaje elementem platformy. Własny moduł Guidance generuje referencję trajektorii, a kontroler drona wykonuje ją i steruje silnikami. Ta granica jest fundamentalna: ANAFI Ai daje większą swobodę aplikacyjną niż typowy zamknięty dron fotograficzny, ale mniejszą niż własny autopilot.

Spis treści#

Profil platformy
Poziomy pewności
Płatowiec i napęd
Energia i bateria
Architektura obliczeniowa
Sensory lotu
Stabilizacja termiczna IMU i barometru
GNSS
Optical flow i ToF
Obrotowa stereowizja
Ograniczenia percepcji
Kamera główna
Dwa gimbale
Fotogrametria
Wi-Fi
4G LTE
Przełączanie mediów
Tor wideo
Cyberbezpieczeństwo
Warstwy oprogramowania
Drone controller
Flight supervisor
Guidance
Services
Telemetry, Video i Messages
Air SDK
Ground SDK
Olympe
Sphinx
Projekt własnej misji
Czas i świeżość danych
Obsługa awarii
Program testów
Test łącza hybrydowego
Test percepcji
Test misji Air SDK
Test energii
Zarządzanie wersjami
Kiedy ANAFI Ai ma sens
Typowe błędy
Powiązane tematy
Przypisy

Profil platformy#

ANAFI Ai jest składanym quadrocopterem przeznaczonym do inspekcji, obrazowania, fotogrametrii i budowy własnych aplikacji. Producent podaje wymiary po rozłożeniu 320 × 440 × 118 mm, masę 898 g, prędkość poziomą do 17 m/s, wznoszenie do 4 m/s, opadanie do 3 m/s i odporność na wiatr do 14 m/s w locie. Odporność obudowy opisano jako IP53; nie jest to klasa umożliwiająca zanurzenie ani dowolną eksploatację w deszczu.[2][4]

Deklarowany maksymalny ciąg statyczny 23,27 N względem ciężaru około 0,898 kg × 9,81 m/s² ≈ 8,81 N daje stosunek około 2,64, zgodny z wartością 2,65 producenta. Jest to wynik statyczny w warunkach testu, a nie stały zapas podczas rozładowania baterii, na dużej wysokości albo przy gorącym powietrzu.

Platforma nie ma wymiennego ciężkiego payloadu. Kamera główna i system percepcji są elementem airframe. To ogranicza integrację mechanicznych ładunków, ale upraszcza fabryczną kalibrację geometrii, stabilizacji, masy i oporów. Rozszerzalność koncentruje się w oprogramowaniu i danych.

Poziomy pewności#

Dokumentację trzeba czytać z datą i wersją. White paper oraz instrukcje ANAFI Ai pochodzą z kolejnych wydań firmware, podczas gdy dokumentacja Air SDK, Ground SDK i Sphinx jest aktualizowana osobno. Przykład z dokumentacji SDK w wersji 8.4.2 może nie działać na statku z dawnym firmware bez aktualizacji lub korekty zależności.[4][5][6][7][9]

W artykule obowiązują oznaczenia:

potwierdzone — nazwa sensora, częstotliwość, interfejs lub architektura jawnie opisana przez Parrota;
producent deklaruje — czas, zasięg, dokładność lub odporność uzyskane w określonych warunkach;
wniosek techniczny — konsekwencja publicznych bloków, bez twierdzenia o nieujawnionej implementacji;
niepotwierdzone — informacje z rozbiórek lub starszych dyskusji, których nie przenosimy do profilu bez źródła.

Parrot ujawnia znacznie więcej niż wielu producentów, ale nadal nie publikuje kompletnego schematu elektrycznego i źródeł dolnej pętli sterowania. „Open source SDK” nie znaczy „cały statek jest open source”.

Płatowiec i napęd#

Układ X z czterema napędami jest składany. Producent podaje maksymalną prędkość śmigieł 12 000 rpm i opisuje profil łopaty inspirowany guzkami na krawędzi płetw humbaka. Marketingowe porównanie biomimetyczne jest mniej ważne niż deklarowana sprawność: Parrot podaje figure of merit śmigła około 66% w swoich warunkach.[2]

Figure of merit porównuje rzeczywistą moc zawisu z mocą idealnego wirnika. Nie jest to sprawność elektryczna całego drona. Nie obejmuje wszystkich strat silnika, ESC, przewodów, kadłuba ani elektroniki. Nie wolno więc mnożyć energii baterii przez 0,66 i na tej podstawie wyznaczać czasu lotu.

Mała masa zmniejsza energię kinetyczną, ale statek o prędkości 17 m/s nadal niesie:

E_k = 1/2 · 0,898 kg · (17 m/s)² ≈ 130 J

bez uwzględnienia energii obracających się śmigieł. To wystarcza do spowodowania urazu i uszkodzenia. Testy własnych misji wymagają pustego obszaru, ograniczeń prędkości i obserwatora.

W platformie czterowirnikowej utrata jednego napędu nie daje typowej redundancji ciągu. Nie należy utożsamiać dwóch mediów łączności czy wielu sensorów z odpornością na awarię silnika. Śmigła trzeba kontrolować pod kątem pęknięć przy piaście, odkształcenia, śladów uderzenia i poprawnego mocowania.

Energia i bateria#

Inteligentna bateria ma według producenta 6800 mAh przy 4,4 V, energię właściwą 262 Wh/kg, masę 370 g i ładowanie USB-C do 45 W. Prosty iloczyn pojemności i napięcia daje około 29,9 Wh. Relacja energii do masy pakietu wynosi około 81 Wh/kg, więc parametr 262 Wh/kg nie może być bezrefleksyjnie traktowany jako energia właściwa kompletnej baterii z obudową i BMS; może odnosić się do użytych ogniw albo innej definicji. Dokumentacja producenta wymaga w tym miejscu doprecyzowania.[4]

To dobry przykład kontroli spójności danych. Jeśli dwie liczby z tej samej tabeli nie opisują tego samego poziomu systemu, artykuł nie powinien arbitralnie wybierać jednej. Dla planowania lotu właściwe są zmierzone użyteczne Wh kompletnej baterii i profile napięcia.

Deklarowane 32 minuty są wartością maksymalną. Operacyjny budżet powinien zawierać:

t_misji = t_start + t_dolot + t_zadanie + t_powrot + t_ladowanie + t_rezerwa

Rezerwa nie jest „czasem, który został na wskaźniku po lądowaniu”. Trzeba ją zaplanować na wiatr czołowy, go-around, pogorszenie łącza i słabszą baterię. Dla lotu inspekcyjnego lepiej wyznaczyć energię na odcinek i minutę zawisu z danych floty.

USB-C upraszcza logistykę, ale źródło zasilania musi obsługiwać właściwy profil mocy. Ładowanie w zimnie, bezpośrednio po gorącym locie lub uszkodzonego pakietu wymaga stosowania instrukcji producenta. Organizacja powinna rejestrować numer baterii, cykle, temperaturę, odchylenia czasu lotu i błędy.

Architektura obliczeniowa#

Publiczny model Air SDK pokazuje kilka procesów prowadzących od komendy operatora do napędów:[6]

Remote UI -> Flight supervisor -> Guidance -> Drone controller -> silniki

Równolegle działają usługi, telemetria, wideo i system przesyłania wiadomości. Drone controller jest niezmienialnym elementem odpowiedzialnym za realizację trajektorii i dolne sterowanie. Programista misji może zmieniać wyższe warstwy:

Flight supervisor — maszynę stanów i reakcję na zdarzenia;
Guidance — generowanie trajektorii statku i kamer;
Services — oddzielne procesy, np. computer vision lub sieć neuronową;
Remote UI — interfejs misji w aplikacji naziemnej.

Taki podział izoluje część krytyczną od eksperymentalnego kodu. Nie gwarantuje jednak, że błąd usługi nie zużyje zasobów, nie zablokuje danych lub nie wyśle złej trajektorii. Granica API zmniejsza klasę awarii, ale wymaga budżetów CPU, pamięci, czasu i komunikacji.

Dokumentacja mówi o procesach Linux dla usług. Nie należy z tego wnioskować, że wszystkie zadania czasu rzeczywistego działają w zwykłym userspace albo że znamy fizyczny podział procesorów. Szczegółowa topologia hardware nie jest pełna w publicznym opisie.

Sensory lotu#

Parrot podaje modele i parametry sensorów:[2]

Funkcja	Układ / sensor	Wybrane dane producenta
flight IMU	TDK InvenSense ICM-40609-D	gyro ±2000°/s, accelerometer ±16 g, sampling 2 kHz
magnetometr	ST LIS2MDL	zakres ±49,152 G, pomiar 100 Hz
barometr	ST LPS22HB	260–1260 hPa, pomiar 75 Hz
GNSS	u-blox UBX-M8030	GPS, GLONASS, Galileo, antena patch 25 mm
kamera dolna	monochromatyczna global shutter	640 × 480, flow 60 Hz
odległość w dół	TI OPT3101 ToF	0–15 m, pomiar 64 Hz
IMU kamery dolnej	ICM-42605	gyro/accel 1 kHz, synchronizacja z kamerą
percepcja	2 × onsemi AR0144	1280 × 800, 30 fps, global shutter, baseline 62 mm

Ta jawność pozwala ocenić częstotliwości, zakresy i źródła błędów. Nie ujawnia automatycznie konfiguracji rejestrów, filtrów cyfrowych ani algorytmu fusion. Dokładność po kalibracji podana przez producenta nie jest szumem pojedynczej próbki i nie musi być zachowana po uderzeniu lub wymianie mechanicznej.

Stabilizacja termiczna IMU i barometru#

Flight IMU ma sterowane ogrzewanie i według producenta stabilizację temperatury w zakresie ±0,15°C, a barometr ±0,2°C względem wartości sterowanej. Celem jest zmniejszenie zmian biasu związanych z temperaturą. To ważne w małym statku, gdzie sensor znajduje się blisko źródeł ciepła i chłodzącego przepływu.[2]

Ogrzewanie nie usuwa wszystkich błędów:

gradientu temperatury między sensorem i płytą;
naprężeń mechanicznych;
wibracji napędu;
aging MEMS;
clippingu przy uderzeniu;
błędu kalibracji skali i nieortogonalności;
wpływu przepływu na port barometru.

Czas od włączenia do stabilizacji może wpływać na powtarzalność. Próby precyzyjne powinny używać podobnego warm-up i zapisywać temperaturę. Start natychmiast po wyjęciu zimnego statku z samochodu nie jest równoważny lotowi po stabilizacji w laboratorium.

Parrot podaje dla gyro bias po kalibracji wartość około ±0,05°/s. Nie oznacza to błędu orientacji ±0,05°. Stały błąd prędkości kątowej integrowany przez 60 s dawałby 3° bez korekcji; fusion z grawitacją, magnetometrem, wizją i GNSS ogranicza dryf w zależności od osi i warunków.

GNSS#

UBX-M8030 obsługuje GPS, GLONASS i Galileo. Producent podaje standardowe odchylenie pozycji rzędu 1,4 m oraz cold-start około 40 s w warunkach dokumentacji. ANAFI Ai nie jest opisywany tu jako system RTK; fotogrametria wymaga zatem GCP lub innej metody kontroli, jeśli oczekiwana dokładność przewyższa standalone GNSS.[2]

Dokładność GNSS zależy od:

widoku nieba i geometrii satelitów;
wielodrożności obok fasad i konstrukcji stalowych;
zakłóceń emitowanych przez własną elektronikę;
propagacji jonosferycznej i troposferycznej;
czasu i dynamiki odbiornika;
zgodności timestampu z ekspozycją;
lever arm między anteną i kamerą.

W tunelu lub magazynie GNSS może być niedostępny. Wtedy platforma wykorzystuje IMU, dolną kamerę i ToF, a system percepcji może wspierać ruch. Nie oznacza to bezterminowej nawigacji bez punktu odniesienia. Błąd pozycji rośnie, powierzchnia pod statkiem może być nieobserwowalna, a jednolity korytarz daje słabą geometrię.

Optical flow i ToF#

Dolna kamera 640 × 480 z global shutter mierzy przepływ względem podłoża do 60 Hz. Oddzielna IMU ICM-42605 jest sprzętowo synchronizowana z kamerą z deklarowaną dokładnością 1 µs. Synchronizacja pozwala kompensować ruch obrotowy podczas obliczania przepływu.[2]

Optical flow mierzy ruch w obrazie. Do przeliczenia na prędkość metryczną potrzebna jest wysokość i geometria kamery. ToF OPT3101 mierzy w dół w zakresie do około 15 m i wspiera skalę oraz wysokość blisko podłoża.

Przypadki słabe dla flow:

jednolita podłoga bez tekstury;
powierzchnia lustrzana lub woda;
bardzo słabe oświetlenie;
powtarzalny regularny wzór;
obiekt poruszający się pod statkiem;
duża wysokość, gdy detal jest zbyt mały;
motion blur;
cień statku zmieniający się względem sceny.

Global shutter usuwa typowy geometryczny skew rolling shutter, ale nie eliminuje blur. Krótka ekspozycja wymaga światła. Próby indoor muszą objąć faktyczną posadzkę, a nie tylko dobrze teksturowaną matę testową.

Obrotowa stereowizja#

System percepcji używa pary monochromatycznych kamer onsemi AR0144 o rozdzielczości 1280 × 800, 30 fps, global shutter i bazie 62 mm. Pełne pole widzenia pary wynosi około 118° poziomo i 72° pionowo, a do percepcji wykorzystywany jest nieco mniejszy obszar. Para jest zamontowana na ruchomym gimbalu, którego orientacja może podążać w kierunku istotnym dla aktualnego ruchu.[2]

W klasycznym systemie dookólnym wiele kamer patrzy stale w różne strony. ANAFI Ai wykorzystuje jedną ruchomą parę. Zalety:

mniejsza liczba kamer i torów przetwarzania;
stała baza stereo;
możliwość skierowania pełnej rozdzielczości w stronę ruchu;
kompaktowy płatowiec.

Kosztami są:

czas mechanicznego przestawienia;
brak jednoczesnej pełnej obserwacji wszystkich kierunków;
konieczność predykcji, gdzie patrzeć;
kalibracja kąta gimbala w transformacji do body frame;
możliwe zasłonięcie przez konstrukcję;
zależność od sprawności mechanizmu.

Głębię stereo można w uproszczeniu zapisać:

Z = f · B / d

gdzie f jest ogniskową w pikselach, B = 0,062 m bazą, a d dysparycją. Błąd głębi rośnie w przybliżeniu z kwadratem odległości, bo daleki obiekt ma małą dysparycję. Dlatego stereo jest szczególnie użyteczne blisko statku, a nie jako radar dalekiego zasięgu.

Ograniczenia percepcji#

Ruchoma para nie gwarantuje uniknięcia każdej przeszkody. Stereo potrzebuje korespondencji między obrazami. Trudne są:

cienkie przewody i gałęzie;
szkło i powierzchnie przezroczyste;
jednolite ściany;
powtarzalne kratownice;
silne światło w obiektyw;
mgła, deszcz i zabrudzenie;
szybko poruszający się obiekt;
przeszkoda poza aktualnym kierunkiem patrzenia;
mały kontrast nocą.

Minimalny margines hamowania powinien uwzględniać 30 fps kamery, czas przetwarzania, sterowanie gimbalem, planowanie oraz dynamikę napędu:

d_margin > v · (t_frame + t_processing + t_planning + t_actuation) + v²/(2a)

Producent może ograniczać komendę w zależności od oceny otoczenia, ale integrator własnego Guidance nie powinien zakładać nieograniczonej korekcji. Dokumentacja mówi, że tryb Guidance może implementować etap korekcji trajektorii przez obstacle avoidance, ale nie musi. Pominięcie go jest decyzją architektoniczną wymagającą jawnej oceny ryzyka.[6]

Kamera główna#

Kamera główna wykorzystuje sensor CMOS 1/2 cala 48 MP, obiektyw o ekwiwalencie 24 mm i przysłonie f/2.0. Producent podaje HDR do 14 EV, zakres ISO 50–6400, migawkę elektroniczną 1/15–1/10 000 s oraz stabilizację mechaniczną i elektroniczną.[4]

48 MP nie jest pełnym opisem jakości. Liczą się:

fizyczny rozmiar piksela i binning;
MTF obiektywu;
rolling shutter oraz czas odczytu;
kompresja i sharpening;
szum oraz dynamic range;
kalibracja dystorsji;
motion blur;
timestamp ekspozycji;
stabilność geometrii gimbala.

„Lossless zoom” oznacza zwykle crop bez interpolacji do określonej rozdzielczości wynikowej, nie optyczne zwiększenie szczegółu. Przy 4K producent deklaruje mniejszy zakres bezstratny niż przy 1080p, bo pozostaje mniej zapasu pikseli.

Dwa gimbale#

Kamera główna i stereowizja mają osobne mechanizmy orientacji ze współosiowym rozwiązaniem osi pitch. Dzięki temu kamera inspekcyjna może patrzeć na obiekt, a percepcja w kierunku ruchu. Główna kamera ma mechaniczną stabilizację trzech osi oraz bardzo szeroki mechaniczny zakres pitch, pozwalający obserwować także powyżej statku.[2]

Rozdzielenie celów eliminuje klasyczny konflikt: operator obraca kamerę w bok, a system obstacle avoidance traci widok do przodu. Nie eliminuje jednak ograniczeń geometrycznych. Dwa mechanizmy dzielą przestrzeń, masę i obszar wokół osi. Algorytm musi znać oba kąty oraz ograniczenia końcowe.

EIS stosuje geometryczną transformację powiązaną z timestampem i położeniem kamery z IMU. Stabilizacja elektroniczna kadruje obraz i może zmieniać lokalną geometrię. Dla fotogrametrii trzeba używać wspieranego trybu i metadanych, nie klatek wyciętych ze stabilizowanego streamu.

Fotogrametria#

Platforma oferuje grid, double grid, circular i inne wzorce misji. Automatyczny plan nie gwarantuje kompletnego modelu. Projekt powinien dobrać:

GSD do najmniejszego wymaganego szczegółu;
overlap podłużny i poprzeczny;
kąt kamery do geometrii obiektu;
czas ekspozycji do prędkości obrazu;
trasę uwzględniającą przeszkody;
GCP i punkty kontrolne;
oświetlenie oraz powierzchnie bez tekstury;
redundancję ujęć.

Przy braku RTK pozycje GNSS zdjęć są dobrym przybliżeniem startowym, ale nie powinny być traktowane jako centymetrowa georeferencja. Bundle adjustment wykorzystuje tie points i może zbudować spójny model o błędzie absolutnym większym niż błąd wewnętrzny. Raport musi rozdzielać relative accuracy od absolute accuracy.

Migawka elektroniczna może dać rolling-shutter distortion. Krótki czas ekspozycji ogranicza blur, ale niekoniecznie czas odczytu sensora. Krzyżowa siatka i wolniejszy lot zwiększają redundancję, kosztem energii oraz liczby zdjęć.

Wi-Fi#

Łącze Wi‑Fi wykorzystuje 802.11 w 2,4 i 5 GHz. Producent opisuje cztery kierunkowe anteny z reflektorami, wybór pary zależnie od orientacji oraz możliwość zmniejszenia szerokości kanału do 10 MHz w warunkach granicznych. Podawany maksymalny zasięg to 4 km w domenie CE i 9 km FCC, przy założeniach producenta.[3]

Węższy kanał zmniejsza przepustowość, lecz poprawia czułość i budżet łącza. To klasyczny trade-off: stabilniejsza telemetria i bardziej skompresowany obraz zamiast maksymalnego bitrate.

Wi‑Fi pozostaje współdzielonym medium. W mieście wpływają na nie access pointy, urządzenia klienckie, szerokość kanału, odbicia i zasłonięcie. Nominalna moc zgodna z domeną nie gwarantuje symetrycznego uplinku/downlinku. Test trzeba wykonać o podobnej porze i przy faktycznym ustawieniu kontrolera.

4G LTE#

Wbudowany modem 4G i slot nano-SIM odróżniają ANAFI Ai od konstrukcji, w których LTE jest doczepionym komputerem. Producent deklaruje obsługę ponad 28 pasm oraz łączność wszędzie tam, gdzie dostępna jest zgodna sieć i usługa. Tor wykorzystuje infrastrukturę do zestawienia połączenia, m.in. SIP i relay w sieciach z NAT.[3][5]

„Nieograniczony zasięg 4G” oznacza brak limitu wynikającego wyłącznie z bezpośredniego budżetu radiowego statek–kontroler. Nie oznacza nieograniczonej operacji. Ograniczają ją:

pokrycie i pojemność sieci;
dopuszczenie roamingu i pasm;
uplink dostępny w powietrzu;
opóźnienie i jitter;
handover między eNodeB;
CGNAT, relay i usługi backendowe;
limit danych oraz polityka operatora;
energia i przepisy BVLOS.

Anteny stacji komórkowych są optymalizowane przede wszystkim dla użytkowników na ziemi; downtilt może sprawić, że większa wysokość nie poprawi sygnału. Statek może widzieć wiele komórek, co zwiększa interferencję. Test naziemny telefonu nie odtwarza pełnego środowiska w locie.

Przełączanie mediów#

Dokumentacja mówi o pomiarze jakości Wi‑Fi i 4G co 100 ms oraz automatycznym przełączeniu, gdy efektywny goodput Wi‑Fi spadnie poniżej określonego poziomu. Kluczowe jest słowo „goodput”: liczy się użyteczny strumień po stratach i retransmisjach, a nie sama siła sygnału RSSI.[3]

Handover między mediami powinien zachować sesję sterowania i wideo, lecz może zmienić:

opóźnienie;
jitter;
bitrate kodera;
liczbę utraconych ramek;
drogę sieciową;
adresację i stan NAT;
koszt transmisji.

Własna aplikacja nie może używać stałego timeoutu dobranego wyłącznie dla lokalnego Wi‑Fi. Jednocześnie bezterminowe oczekiwanie przez LTE jest błędem. Timeouty trzeba wiązać z krytycznością komendy i jawnie odróżniać „nie otrzymano ACK” od „komenda nie została wykonana”.

Tor wideo#

ANAFI Ai przesyła obraz do 1080p/30 fps. Dokumentacja opisuje H.264/AVC, RTP z zarządzaniem sesją RTSP, bitrate do około 8 Mb/s dla standardowego toru oraz opóźnienie glass-to-glass poniżej lub około 300 ms w warunkach producenta. Dla połączenia 4G opisano zabezpieczenie SRTP/DTLS zgodne z mechanizmami WebRTC.[3]

Strumień podglądowy nie jest źródłem pomiarowym równoważnym plikowi na karcie. Kompresja międzyklatkowa, concealment strat i adaptacja bitrate mogą ukryć utratę danych. Algorytm computer vision używający streamu musi rejestrować:

timestamp capture, jeśli dostępny;
timestamp odbioru;
numer ramki lub wykryte luki;
rozdzielczość i zmianę bitrate;
opóźnienie bufora;
stan dekodera po utracie reference frame.

Parrot udostępnia także metadane w rozszerzeniu nagłówka RTP oraz dostęp do strumieni stereo, pionowego i mapy dysparycji w przewidzianych interfejsach. Synchronizacja obrazu i telemetrii jest ważniejsza niż sama możliwość otwarcia streamu w VLC.

Cyberbezpieczeństwo#

Producent deklaruje brak wysyłania danych bez zgody użytkownika, cyfrowo podpisany firmware, podpisywanie zdjęć i Secure Element zgodny z FIPS 140-2 Level 3 oraz Common Criteria EAL5+. Podobny element znajduje się w Skycontroller 4 i wspiera uwierzytelnianie 4G.[5]

Certyfikat komponentu nie certyfikuje automatycznie całego systemu i procesu operatora. Nadal potrzebne są:

kontrola kont Parrot.Cloud;
ochrona urządzenia mobilnego;
aktualizacje FreeFlight, kontrolera i statku;
bezpieczna karta SIM i procedura jej utraty;
polityka danych na microSD;
rozdzielenie development i production keys Air SDK;
weryfikacja podpisów własnych misji;
ewidencja aplikacji, bibliotek i zależności;
logowanie zmian konfiguracji.

White paper opisuje, że przy 4G infrastruktura Parrota pomaga zestawić połączenie, lecz producent deklaruje brak dostępu do niezaszyfrowanego wideo dzięki negocjacji klucza między statkiem i kontrolerem. Ocena organizacji powinna sprawdzić aktualną architekturę, politykę prywatności i przepływy sieciowe właściwe wersji, nie polegać wyłącznie na dokumencie historycznym.[5]

Cyfrowo podpisane zdjęcie może wykazać integralność lub pochodzenie w ramach określonego systemu kluczy. Nie dowodzi samo z siebie prawdziwości interpretacji sceny, poprawności czasu, dokładności lokalizacji ani pełnego chain of custody po eksporcie.

Warstwy oprogramowania#

Ekosystem składa się z:

Warstwa	Rola
firmware statku	lot, sensory, media, storage i usługi pokładowe
Air SDK	własna misja uruchamiana na statku
Ground SDK	aplikacja Android/iOS i komunikacja z produktem
Olympe	kontrola i automatyzacja z Pythona na Linux
Sphinx	symulacja statku i środowiska
PDrAW / narzędzia	dekodowanie, odtwarzanie i analiza wideo
FreeFlight 7	referencyjna aplikacja operatora

Warstwy mogą współpracować: Air SDK definiuje logikę na statku, Ground SDK tworzy UI, a Sphinx pozwala sprawdzić część zachowań. Olympe jest wygodny dla testów automatycznych. Nie każda funkcja hardware jest jednak idealnie odwzorowana w symulatorze.

Drone controller#

Drone controller przyjmuje trajektorie z Guidance i prowadzi statek. Dokumentacja Air SDK określa go jako proces nieprzeznaczony do modyfikacji przez misję. Jest to właściwa bariera dla własnego kodu: programista określa położenie, prędkość, orientację lub referencję kamery w dozwolonym API, ale nie wysyła bezpośrednio PWM do silników.[6]

Konsekwencje:

własny błąd nie powinien móc dowolnie ominąć całego kontrolera;
nie da się implementować nowego miksera ani pętli rate od zera;
identyfikacja dynamiki jest ograniczona przez wewnętrzne zachowanie;
test Guidance powinien mierzyć referencję i odpowiedź, nie zakładać idealnego śledzenia;
ograniczenia geofence, obstacle avoidance i stanu mogą skorygować lub odrzucić trajektorię.

Nie wolno sterować na podstawie samego czasu sleep(). Komenda trajektorii musi mieć model stanu, zakończenia i timeoutu.

Flight supervisor#

Flight supervisor jest maszyną stanów autopilota. Odbiera komendy Remote UI, reaguje na zdarzenia Guidance, Services i Drone controller oraz wybiera właściwe tryby. Dokumentacja wymaga sześciu grup najwyższego poziomu: ground, takeoff, hovering, flying, landing i critical.[6]

Implementacja supervisor jest opisana jako Python oparty na pytransitions. Python upraszcza deklarację stanów, ale logika bezpieczeństwa musi być jednoznaczna. Każdy stan powinien definiować:

dopuszczalne wejścia;
warunek gotowości;
timeout;
zdarzenia wyjściowe;
reakcję na utratę łącza i niski poziom baterii;
możliwość anulowania;
stan następczy po błędzie.

Najgroźniejsze błędy zwykle nie polegają na braku stanu, lecz na nieobsłużonym przejściu. Przykład: komenda zakończenia inspekcji przychodzi równocześnie z battery critical. Supervisor musi mieć priorytet i idempotentną reakcję, aby nie przełączać się naprzemiennie między RTH i własnym trybem.

Importowanie stanów z misji domyślnej nie zwalnia z kontroli konfiguracji. Dokumentacja wskazuje, że głębiej zagnieżdżone stany mogą wymagać skopiowania parametrów. Wersja bazowej misji staje się zależnością projektu.

Guidance#

Guidance generuje trajektorie statku i kamer. Typowy krok obejmuje:

referencję translacji poziomej i pionowej;
opcjonalną korekcję obstacle avoidance;
referencję orientacji statku oraz kamer.

Tylko jeden tryb Guidance jest aktywny w danym czasie. Supervisor włącza i wyłącza tryby, a zdarzenie potwierdza zmianę. To zapobiega równoczesnemu generowaniu sprzecznych referencji przez FlightPlan i własny algorytm.[6]

Własny tryb musi ograniczać ciągłość trajektorii. Skok pozycji zadanej może wymusić duże przyspieszenie; skok yaw może rozmyć obraz albo skierować statek w przeszkodę. Generator powinien jawnie ograniczać:

prędkość;
przyspieszenie;
jerk;
prędkość kątową;
zakres gimbala;
odstęp od geofence;
horyzont hamowania.

Trajectory correction nie może być dekoracyjnym checkboxem. Jeśli tryb celowo jej nie implementuje, UI i procedura powinny to wskazać, a testy używać osobnej obwiedni.

Services#

Service jest oddzielnym procesem Linux wykonującym zadanie pomocnicze, np. computer vision, sieć neuronową, protokół albo analizę obrazu. Komunikuje się z supervisorem i Guidance przez wiadomości, czyta telemetrię oraz może korzystać z wideo.[6]

Oddzielny proces daje izolację pamięci, ale nadal współdzieli CPU, pamięć, storage i termikę. Serwis powinien mieć:

limit częstotliwości;
bounded queue;
zachowanie przy dropie ramek;
watchdog/heartbeat;
kontrolę pamięci;
log rate limiting;
wersję modelu ML;
możliwość bezpiecznego wyłączenia.

Algorytm ML nie może wysyłać decyzji bez confidence i timestampu. Stary bounding box po zamrożeniu streamu jest bardziej niebezpieczny niż jawny brak detekcji.

Telemetry, Video i Messages#

Air SDK rozdziela trzy drogi wymiany:[6]

Telemetry — współdzielona pamięć z sekcjami i okrężnymi buforami timestampowanych próbek;
Video — strumienie z kamer;
Messages — komendy i zdarzenia między procesami oraz Remote UI.

Sekcje telemetryczne mogą odświeżać się z różną częstotliwością. Pobranie „ostatniej próbki” z pięciu sekcji nie gwarantuje wspólnego czasu. Dla fuzji trzeba żądać danych dla konkretnego timestampu albo interpolować ze świadomością opóźnienia.

Messages używają zdefiniowanych interfejsów, w tym Protobuf dla własnych komunikatów. Schemat wiadomości jest kontraktem. Zmiana numeru pola, typu albo semantyki wymaga wersjonowania i kompatybilności wstecznej. Nie należy kodować stanu wyłącznie w tekstowym stringu.

Air SDK#

Air SDK pozwala utworzyć pełną misję albo usługę. Projekt definiuje cele build, Flight supervisor, Guidance, Services, komunikaty i UI. Narzędzie airsdk-cli tworzy, buduje oraz instaluje pakiet. Fizyczna misja może być podpisana kluczem, a symulator ma osobny target.[6]

Przykładowa organizacja logiczna:

mission.yaml
fsup/
  mission.py
  flying/
guidance/
  inspection_mode.cpp
services/
  anomaly_detector/
messages/
  inspection.proto
ui/
  mission panel

To schemat edukacyjny, nie kopia repozytorium. Aktualną strukturę generuje narzędzie wersji SDK. Kod własny i zależności należy utrzymywać w osobnym repozytorium; jeśli portal kiedyś opublikuje kompletne przykłady, zgodnie z zasadami projektu potrzebny będzie wpis w repozytoria.md.

Przed instalacją na fizycznym statku misja powinna przejść lint, testy jednostkowe, testy kontraktów protobuf, symulację, fault injection i review zmian maszyny stanów.

Ground SDK#

Ground SDK pozwala budować aplikacje Android/iOS komunikujące się ze statkiem i odbierające wideo. Wersja Android jest publikowana ze źródłami na licencji BSD-3-Clause; bieżąca dokumentacja określa wspierane wersje systemu i API.[7]

UI naziemne jest elementem systemu bezpieczeństwa. Musi odróżniać:

żądanie operatora;
komendę wysłaną;
komendę zaakceptowaną;
stan aktywny;
stan zakończony;
stan błędu.

Przycisk „start misji” nie może natychmiast zmieniać statusu na „misja trwa” bez ACK. Alert krytyczny nie powinien zniknąć pod panelem kamery. Kolor nie może być jedynym nośnikiem stanu.

Lifecycle Android wymaga testów: odłączenie USB, obrót ekranu, utrata procesu, uśpienie, brak miejsca, odmowa permission i zmiana sieci. Stan krytyczny powinien pozostać na statku, a aplikacja po reconnect odtworzyć go z telemetrii zamiast z lokalnego cache.

Olympe#

Olympe jest biblioteką Python dla Linux, kompatybilną m.in. z ANAFI Ai i Sphinx. Bazuje na stosie ARSDK i udostępnia programistyczną kontrolę, telemetrię oraz oczekiwanie na zdarzenia. Kod jest dostępny na licencji BSD-3-Clause.[8]

Olympe dobrze nadaje się do:

automatycznych testów regresji;
powtarzalnych sekwencji w symulatorze;
pobierania telemetrii do eksperymentów;
narzędzi laboratoryjnych;
integracji z backendem badawczym.

Nie należy jednak pisać skryptu jako szeregu komend oddzielonych stałym sleep. Poprawny wzorzec to:

send(command)
result = wait_for(expected_event, timeout=deadline)
if not result.ok:
    abort_to_safe_state()

Nazwy faktycznych komend i zdarzeń trzeba pobrać z dokumentacji wersji Olympe. Pseudokod pokazuje kontrakt, nie gotowy program lotny.

Automatyczne testy powinny mieć własny nadzorca czasu i jednoznaczny teardown. Nieudany assertion nie może pozostawić aktywnej misji ani otwartego strumienia.

Sphinx#

Sphinx uruchamia symulowany firmware Parrota z modelem statku i środowiskiem 3D. Dokumentacja pokazuje osobny obraz firmware PC dla ANAFI Ai oraz integrację z rendererem środowiska. Pozwala testować Air SDK, Ground SDK i Olympe przed użyciem hardware.[9]

Symulator jest szczególnie wartościowy dla:

przejść supervisor;
komend Guidance;
komunikatów własnego protokołu;
scenariuszy link loss;
powtarzalnych tras;
regresji CI;
generowania obrazów dla CV.

Nie kwalifikuje:

realnych wibracji;
RF Wi‑Fi/LTE;
zabrudzenia optyki;
termiki CPU i baterii;
zużycia śmigieł;
dokładnej aerodynamiki blisko ściany;
błędów produkcyjnych sensorów.

Model ma własną wersję. Wynik trzeba zapisać wraz z obrazem firmware, modelem .drone, środowiskiem, seedem i wersją Sphinx.

Projekt własnej misji#

Dobrym przykładem bezpiecznej misji jest automatyczna inspekcja regałów magazynowych bez ofensywnego payloadu. System może:

otrzymać listę korytarzy;
sprawdzić gotowość sensorów i baterii;
przejść do kontrolowanego startu;
aktywować Guidance ograniczający prędkość;
skierować stereo w kierunku ruchu;
skierować główną kamerę na etykiety;
uruchomić service wykrywający braki;
zapisać zdjęcie, pozycję i confidence;
wrócić po ukończeniu lub przy degradacji;
wygenerować manifest danych.

Supervisor powinien mieć jawne stany preflight, takeoff, inspect, paused, return, landing, failed. paused jest ważny: operator może zatrzymać postęp bez gwałtownego przejścia do lądowania.

Service CV nie steruje silnikami bezpośrednio. Publikuje obserwację. Guidance decyduje o trajektorii w granicach, a supervisor o dopuszczeniu trybu. To separacja percepcja–decyzja–wykonanie.

Czas i świeżość danych#

Każda próbka powinna mieć czas powstania. Czas odebrania jej przez aplikację zawiera opóźnienie sieci i kolejki. Dla sterowania na podstawie obrazu:

wiek = t_teraz - t_capture

Jeśli wiek przekracza limit, detekcja nie może generować nowej trajektorii. Limit zależy od prędkości: przy 3 m/s opóźnienie 300 ms odpowiada 0,9 m ruchu przed reakcją, nie licząc hamowania.

Synchronizacja obejmuje:

zegar kamery;
telemetry shared memory;
proces usługi;
strumień RTP;
kontroler i aplikację;
system backendowy.

Nie wszystkie używają tej samej epoki. Lepiej zachować monotonic timestamp na statku i mapowanie do UTC niż opierać dynamikę na zegarze ściennym podatnym na korektę.

Obsługa awarii#

Własna misja musi definiować priorytety. Przykładowa kolejność może wyglądać:

krytyczny stan kontrolera lub baterii;
bezpośrednie polecenie operatora;
geofence i ograniczenia środowiskowe;
utrata jakości lokalizacji;
utrata percepcji;
błąd usługi misji;
utrata backendu;
cel nominalny.

Szczegóły muszą być zgodne z API i instrukcją. Celem kolejności jest uniknięcie sytuacji, w której service stale ponawia cel podczas emergency landing.

Proces powinien stosować heartbeat, ale brak heartbeat nie może automatycznie oznaczać restartu bez limitu. Crash loop obciąża system. Po kilku awariach supervisor powinien przejść do zdefiniowanego degraded mode i powiadomić operatora.

Własne logi nie mogą wypełnić nośnika. Potrzebna jest rotacja, limit, poziomy i rezerwacja miejsca dla danych lotnych. Logowanie klatki obrazu co tick może zmienić timing i ukryć prawdziwe zachowanie release build.

Program testów#

Kwalifikację dzieli się na pięć poziomów:

Poziom	Środowisko	Cel
1	testy jednostkowe	funkcje, walidacja danych, stan lokalny
2	test procesu	supervisor, Guidance, Services i messages
3	Sphinx	zamknięta misja ze statkiem i sceną
4	stanowisko naziemne	hardware, sieć, kamera, storage i termika
5	lot stopniowany	rzeczywista dynamika oraz środowisko

Każdy etap ma kryteria wejścia/wyjścia. Niepowodzenie symulacji blokuje lot. Udany symulator nie omija próby naziemnej. Lot zaczyna się od zawisu, potem małej prędkości i dopiero reprezentatywnej trasy.

Testy regresji powinny być automatyczne przez Olympe tam, gdzie to możliwe. Wynik zawiera wersję firmware, SDK, misji, aplikacji i modelu symulatora.

Test łącza hybrydowego#

Test Wi‑Fi/4G musi wymuszać kontrolowane pogorszenie, nie utratę statku. Na ziemi można użyć separacji sieciowej, zmian routingu lub ekranowanego stanowiska. W locie stosuje się legalną trasę i naturalną geometrię, nie aktywne zakłócanie.

Metryki:

czas przełączenia Wi‑Fi → 4G i powrotu;
utracone ramki wideo;
ciągłość telemetrii;
percentyle RTT;
wiek komend i zdarzeń;
bitrate przed/po zmianie;
zachowanie bez relay/backendu;
zużycie danych komórkowych;
reakcja supervisor na całkowity link loss.

ALIGNMENT: portal nie zawiera instrukcji aktywnego zakłócania pasm Wi‑Fi, GNSS ani LTE. W portalu przeznaczonym wyłącznie do autoryzowanych badań wojskowych w tym miejscu można byłoby opisać laboratoryjną aparaturę i procedury odpornościowe; pomijamy kroki umożliwiające praktyczne zakłócanie publicznych sieci ze względów bezpieczeństwa i zgodności z zasadami.

Do legalnej kwalifikacji wystarcza pasywna analiza, tłumiki przewodowe, komora, emulator sieci albo kontrolowane odłączenie interfejsu, wykonywane przez uprawnione laboratorium.

Test percepcji#

Macierz scen powinna obejmować:

teksturowaną i jednolitą ścianę;
szkło;
siatkę;
przewód;
gałęzie;
korytarz powtarzalnych regałów;
słońce w osi kamery;
słabe oświetlenie;
ruchomy obiekt;
lot bokiem i do tyłu;
zmianę kierunku gimbala perception.

Wynik to precision/recall detekcji i minimalny bezpieczny dystans względem prędkości, nie pojedynczy film demonstracyjny. Trzeba zapisywać klatki wejściowe, disparity/occupancy, stan Guidance i faktyczny tor.

Fault injection może zamrozić stream, opóźnić wiadomość lub zgłosić niepewność. Nie powinien fizycznie zasłaniać sensora podczas szybkiego lotu. Bezpieczny test wykonuje się w symulatorze lub na stanowisku z ograniczeniem przestrzeni.

Test misji Air SDK#

Test maszyny stanów powinien przejść wszystkie przejścia, w tym pary zdarzeń w różnych kolejnościach:

start + brak gotowości;
inspect + command cancel;
inspect + battery warning;
pause + utrata lokalizacji;
return + odzyskanie łącza;
landing + spóźnione polecenie misji;
service crash + restart;
podwójna wiadomość o tym samym ID.

Właściwości do asercji:

istnieje najwyżej jeden aktywny Guidance mode;
critical nie wraca samoczynnie do inspect;
duplikat komendy jest idempotentny;
nieświeża obserwacja nie zmienia toru;
utrata Remote UI nie blokuje lokalnej procedury;
po restarcie UI odtwarza stan ze statku;
każda decyzja ma kod przyczyny w logu.

Model property-based może generować sekwencje zdarzeń i sprawdzać inwarianty, zamiast pisać tylko scenariusz happy path.

Test energii#

Próby wykonuje się z każdą baterią przy podobnym profilu:

kontrola temperatury i SOC przed startem;
zawis 5 min;
odcinek przelotowy;
aktywna kamera/stream Wi‑Fi;
analogiczna próba z 4G;
lądowanie przy ustalonym progu;
zapis pozostałej energii i temperatury.

4G może zmieniać pobór względem Wi‑Fi, szczególnie przy słabym sygnale i dużej mocy nadajnika. Computer vision Air SDK zwiększa obciążenie procesora i termikę. Porównanie musi obejmować ten sam firmware oraz temperaturę otoczenia.

Degradację baterii ocenia się na podstawie trendu czasu/energii, napięcia pod obciążeniem i błędów, nie tylko liczby cykli. Bateria, która spełnia krótki lot szkolny, może nie spełniać długiej trasy nad terenem bez miejsca lądowania.

Zarządzanie wersjami#

Manifest eksperymentu powinien przechowywać:

aircraft_model: ANAFI Ai
aircraft_firmware: ...
skycontroller_firmware: ...
freeflight_or_app: ...
airsdk: ...
groundsdk: ...
olympe: ...
sphinx: ...
mission_commit: ...
mission_package_hash: ...
battery_serial: ...
network_profile: wifi|4g|hybrid

API documentation online może zmienić się bez zmiany własnego kodu. Dla wydania trzeba archiwizować numer wersji i zależności. Repozytoria BSD-3-Clause pozwalają modyfikować komponenty zgodnie z licencją, ale pliki zależne mogą mieć własne noty; automat powinien generować SBOM oraz wykaz licencji.

Aktualizacja firmware wymaga ponowienia co najmniej smoke tests supervisor, Guidance, komunikacji, streamu i procedur awaryjnych. Jeśli zmienił się model percepcji lub firmware kamery, należy ponowić również reprezentatywne sceny CV/fotogrametrii.

Kiedy ANAFI Ai ma sens#

Platforma jest szczególnie atrakcyjna, gdy zespół chce:

uruchamiać własny computer vision na statku;
definiować zachowanie misji bez pisania dolnej stabilizacji;
budować własny UI i automatyzację;
używać 4G jako alternatywy dla bezpośredniego linku;
badać ruchomą stereowizję;
prowadzić testy w oficjalnym symulatorze;
korzystać z bibliotek o otwartym kodzie;
szybko przejść od symulacji do lekkiego statku.

Nie jest najlepszym wyborem, gdy potrzebne są:

ciężkie, wymienne payloady;
własny mikser lub regulator rate;
pełny schemat i modyfikacja hardware;
RTK jako zintegrowana funkcja geodezyjna;
długa praca z dużym zapasem energii;
certyfikowany detect-and-avoid;
pełna niezależność od infrastruktury producenta dla 4G pairing.

Wybór powinien wynikać z granicy własności intelektualnej projektu. Jeśli innowacją jest algorytm inspekcji, Air SDK jest dobrym kompromisem. Jeśli innowacją jest flight controller, platforma ukrywa właśnie tę warstwę.

Typowe błędy#

4G ma nieograniczony zasięg. Nie ma bezpośredniego limitu link-budget Wi‑Fi, ale istnieją zasięg sieci, opóźnienie, handover, energia i przepisy.

Dwie sieci oznaczają pełną redundancję. Wi‑Fi i LTE mogą współdzielić kontroler, software, zasilanie oraz UI. Awaria wspólna nadal odcina operatora.

Air SDK otwiera sterowanie silnikami. Własne Guidance podaje trajektorię niezmienialnemu drone controller. To rozszerzalność na wysokim poziomie.

Obrotowa kamera widzi dookoła naraz. Para stereo zmienia kierunek, ale nie obserwuje jednocześnie całej sfery.

48 MP gwarantuje dokładną mapę. Geometria, rolling shutter, GNSS, overlap i kontrola naziemna są równie ważne.

IP53 oznacza deszcz bez konsekwencji. Klasa jest ograniczona, zależy od sprawnego statku i nie pozwala na zanurzenie ani mycie.

Symulator kwalifikuje hardware. Sphinx jest znakomity dla software, lecz nie odwzorowuje wszystkich zjawisk RF, termiki i zużycia.

Podpisane zdjęcie jest dowodem całej prawdziwości. Podpis chroni określony łańcuch integralności; nie certyfikuje interpretacji i dokładności wszystkich metadanych.

Powiązane tematy#

Przypisy#

Parrot, „ANAFI Ai Technical documentation”, indeks dokumentacji technicznej platformy.
Parrot, „Flight performances”, parametry napędu, jawne modele sensorów, optical flow, ToF oraz ruchoma para stereo.
Parrot, „Connectivity”, opis Wi‑Fi, 4G, automatycznego przełączania, RTP/RTSP, SRTP/DTLS i toru wideo.
Parrot, „ANAFI Ai User Guide”, bieżąca strona wsparcia i kolejne wersje instrukcji użytkownika.
Parrot, „ANAFI Ai — The 4G robotic UAV”, white paper producenta; informacje bezpieczeństwa i architektury należy wiązać z jego wersją.
Parrot Developer, „Air SDK architecture”, dokumentacja Flight supervisor, Guidance, Services, Telemetry, Video i Messages.
Parrot Developer, „Ground SDK Android”, dokumentacja i źródła na licencji BSD-3-Clause.
Parrot Developers, „Olympe”, repozytorium biblioteki Python, licencja BSD-3-Clause.
Parrot Developer, „Sphinx Documentation”, uruchamianie symulowanego firmware i środowiska testowego.

Źródła z centralnego rejestru

Parrot: ANAFI Ai technical documentation [dokumentacja producenta]
Parrot: ANAFI Ai flight performances and sensor specifications [dokumentacja producenta]
Parrot: ANAFI Ai 4G, Wi-Fi and video connectivity [dokumentacja producenta]
Parrot: ANAFI Ai User Guide [instrukcja producenta]
Parrot: ANAFI Ai — The 4G robotic UAV, white paper [white paper producenta]
Parrot Developer: Air SDK architecture [dokumentacja producenta]
Parrot Developer: Ground SDK Android overview [dokumentacja i kod open source]
Parrot Developers: Olympe Python controller library [repozytorium open source, BSD-3-Clause]
Parrot Developer: Sphinx simulation documentation [dokumentacja symulatora]