Autel EVO Max — profil architektury

Autel EVO Max jest rodziną składanych quadrocopterów przemysłowych z modułową głowicą, sześciokierunkowym systemem percepcji oraz interfejsami dla payloadów trzecich. Wariant 4T łączy kamery widzialne, termowizję i dalmierz laserowy, 4N dodaje tor nocny o bardzo wysokiej czułości, a nowsza rodzina V2 zmienia płatowiec, baterię i dostępne głowice. Producent udostępnia PSDK, Mobile SDK i Cloud API, dzięki czemu rozszerzalność obejmuje sprzęt pokładowy, aplikację operatora oraz backend.[1][2][4][7][8]

Nie należy jednak traktować „EVO Max” jako jednej konfiguracji. Masa 4T pierwszej generacji wynosi około 1645 g, 4T V2 około 1665 g; używane są baterie ABX40 lub ABX41-D, różne śmigła i pakiety Fusion. Europejski limit MTOM w konfiguracji C2 wynosi 1890 g, podczas gdy w innych regionach producent podaje 1999 g. Port dla fabrycznej głowicy C-Port nie ma publicznej definicji pinów; urządzenia własne korzystają z P-Port, P-Port Lite albo adaptera udostępnianego w ekosystemie PSDK.[1][2][6]

Spis treści#

Rodzina i wersje
Poziomy pewności
Płatowiec
Masa i zapas konfiguracji
Napęd i śmigła
Baterie ABX40 i ABX41-D
Hot swap
Percepcja sześciokierunkowa
Radar fal milimetrowych
Omijanie przeszkód
GNSS, RTK i nawigacja
A-Mesh
Łącze SkyLink
Pakiety Fusion
Fusion 4T
Fusion 4N i 4NZ
Termowizja
Dalmierz laserowy
Smart Controller V3
Architektura portów
P-Port
P-Port Lite
C-Port i adapter gimbala
Payload SDK
Linux i RTOS
Synchronizacja czasu
Mobile SDK
Cloud API
Granice dostępu
Dane i bezpieczeństwo
Program kwalifikacji payloadu
Test percepcji
Test A-Mesh i łącza
Test kamer i radiometrii
Test energii
Zarządzanie wersjami
Typowe błędy
Powiązane tematy
Przypisy

Rodzina i wersje#

Pierwsza generacja obejmuje EVO Max 4T, 4N i 4T XE. Instrukcja wymienia masy około 1635–1665 g z baterią ABX40, głowicą i śmigłami. V2 obejmuje 4T V2, 4N V2 oraz 4NZ V2 z masami około 1665, 1700 i 1715 g oraz baterią ABX41-D.[1][2]

Różnice nie są wyłącznie kosmetyczne:

płatowiec V2 ma nieco inne wymiary i rozstaw;
używa ABX41-D 136,5 Wh;
wspiera hot swap po aktywacji funkcji;
ma nowsze głowice Fusion;
parametry kamer mogą się różnić;
katalog kompatybilnych attachments i firmware jest wersjonowany.

W danych starszych broszur występują wcześniejsze masy, odległości transmisji i śmigła 1136. Bieżąca dokumentacja opisuje zastąpienie ich 1158. Portal traktuje instrukcję i stronę produktu właściwej wersji jako źródło nadrzędne, a starszą broszurę jako zapis historyczny.

Tabela identyfikacyjna floty powinna zawierać:

Pole	Przykład
generacja	EVO Max / EVO Max V2
wariant	4T / 4N / 4T XE / 4NZ
gimbal	pełna nazwa Fusion i revision
bateria	ABX40 / ABX41-D
śmigło	1136 / 1158
region	CE/C2, FCC, SRRC, MIC
firmware	statek, kontroler, gimbal

Poziomy pewności#

Autel publikuje szczegółowe specyfikacje mechaniczne, optyczne, radiowe i PSDK. Nie publikuje pełnego schematu flight controllera, kodu fusion ani implementacji A-Mesh. Artykuł rozróżnia:

potwierdzone — interfejsy, napięcia, sensory wymienione w dokumentacji;
deklarowane — czas lotu, zasięg, odporność na wiatr i dokładność;
wniosek architektoniczny — np. konieczność arbitrażu danych vision/radar;
informacja niepubliczna — MCU, IMU, protokół C-Port i kod autopilota.

Jeśli producent podaje dwa warianty sensora termicznego dostarczane w mieszanych partiach, nie należy przypisywać konkretnego modelu wszystkim egzemplarzom. Numer gimbala i metadata pliku są ważniejsze niż nazwa handlowa statku.[1]

Płatowiec#

EVO Max V2 ma po rozłożeniu ze śmigłami około 563 × 657 × 147 mm, rozstaw diagonalny 467 mm i śmigła 11 × 5,8 cala. Maksymalna prędkość w trybie Ludicrous wynosi według producenta 23 m/s do przodu, 18 m/s wstecz i 20 m/s bokiem w bezwietrznych warunkach blisko poziomu morza. Wznoszenie osiąga 8 m/s, opadanie 6 m/s.[1][2]

Tryby Slow, Smooth, Standard i Ludicrous mają różne ograniczenia. Maksimum nie mówi o dostępnym obstacle avoidance ani jakości obrazu. Przy 23 m/s statek 1,665 kg ma:

E_k = 1/2 · 1,665 · 23² ≈ 440 J

bez energii wirników. Prędkość inspekcyjna powinna wynikać z GSD, blur, zasięgu detekcji i drogi hamowania, nie z możliwości napędu.

Klasa IP43 daje ochronę ograniczoną w porównaniu z IP55 cięższych platform. Oznacza ochronę przed obiektami i natryskiem pod określonym kątem, a nie strugą ze wszystkich kierunków czy pyłoszczelność. Producent ostrzega, że długotrwała ekspozycja może prowadzić do awarii. Po locie w wilgoci potrzebna jest kontrola zgodna z maintenance manual.[3]

Temperatura V2 wynosi od −20°C do +50°C bez obciążenia i do +40°C z pełnym obciążeniem. To ważny przykład: temperatura maksymalna zależy od payloadu i termiki.

Masa i zapas konfiguracji#

Dla V2 4T o masie 1665 g:

do regionalnego MTOM 1999 g pozostaje 334 g;
do konfiguracji C2 1890 g pozostaje 225 g.

Nie jest to automatyczny udźwig PSDK. W zapasie muszą zmieścić się payload, adapter, przewody, śruby i ewentualne osłony. Obowiązuje też limit portu, położenie środka ciężkości i obwiednia producenta.

PSDK podaje maksymalnie dwa payloady dla pierwszej generacji: jeden na P-Port i jeden na P-Port Lite. Liczba portów nie oznacza, że oba mogą wykorzystać cały pozostały MTOM i pełną moc jednocześnie.[5]

Ważenie wykonuje się w konfiguracji ready-to-fly. Środek ciężkości można kontrolować przez reakcję zawisu i metodę mechaniczną dopuszczoną przez producenta, ale ostateczne limity położenia muszą pochodzić z ICD.

Napęd i śmigła#

Śmigło 1158 ma nylon z włóknem węglowym, masę około 10,3 g i maksymalną prędkość 7500 rpm. Starsze 1136 wykorzystywało nylon z włóknem szklanym, masę 10,8 g i do 8000 rpm.[1][2]

Nie wolno mieszać łopat i mocowań między typami bez instrukcji. Różny pitch 3,6 vs 5,8 cala zmienia ciąg i prąd. Autopilot może mieć parametry dostosowane do aktualnego śmigła i firmware.

Kontrola obejmuje:

oznaczenie modelu;
właściwy kierunek i pozycję;
pęknięcia przy piaście;
rozwarstwienie kompozytu;
ślady kontaktu;
luz mocowania;
kompletność pary.

Wymiana pojedynczej uszkodzonej łopaty musi być zgodna z procedurą. Samodzielne szlifowanie lub balansowanie śmigła może usunąć materiał i zmienić wytrzymałość.

Baterie ABX40 i ABX41-D#

V2 używa ABX41-D: Li-Po 4S, 9248 mAh, 14,76 V, 136,5 Wh i około 530 g. Ładowanie ma moc znamionową 120 W, maksymalną 282 W w odpowiednim systemie, a zakres ładowania +5…+45°C. Poniżej +5°C bateria przerywa ładowanie i uruchamia self-heating.[1][2]

Kontrola energii:

9,248 Ah × 14,76 V ≈ 136,5 Wh

Producent wskazuje replacement po przekroczeniu 200 cykli dla ABX41-D. Licznik nie zastępuje oceny stanu: pakiet może wymagać wycofania wcześniej po spuchnięciu, uszkodzeniu, błędzie BMS albo utracie pojemności.

ABX40 należy opisywać na podstawie instrukcji pierwszej generacji. Nie wolno ładować jej parametrami ABX41-D ani zakładać identycznego firmware BMS. Stacje ładowania i przewody wymagają zgodności.

Deklarowany maksymalny czas lotu rodziny wynosi około 42 min w warunkach producenta. Payload, wiatr, temperatura, A-Mesh i sensory zmieniają wynik. Operacyjny czas trzeba zmierzyć do konserwatywnego progu.

Hot swap#

V2 deklaruje hot swap po wcześniejszym włączeniu funkcji w aplikacji. Oznacza to, że część elektroniki może być podtrzymana podczas szybkiej zmiany baterii. Nie oznacza wymiany w locie ani braku procedury.[1][2]

Ryzyka:

funkcja nieaktywna;
zbyt długi czas wymiany;
luźny styk;
niezgodna bateria;
błędny SOC po zmianie;
podtrzymanie stanu, który powinien być zresetowany;
przypadkowe uzbrojenie napędu.

Hot swap testuje się bez śmigieł, zgodnie z instrukcją. Po zmianie operator potwierdza numer, SOC, health i gotowość. Nie należy używać hot swap jako sposobu omijania self-testu przed kolejną misją.

Percepcja sześciokierunkowa#

EVO Max łączy system wizyjny w przód, tył, boki, górę i dół z radarem fal milimetrowych. Starsza broszura podaje zakres vision: do około 31 m w przód, 25 m w tył, 26 m w bok/górę i 23 m w dół, zależnie od tekstury, światła i geometrii.[1][2]

Wizja daje wysoką rozdzielczość kątową i cechy sceny, ale ma problemy ze szkłem, ciemnością i jednolitymi powierzchniami. Radar jest aktywny i może działać przy trudniejszym świetle, lecz ma inną rozdzielczość i zależy od odbicia elektromagnetycznego.

Fuzja wymaga:

kalibracji extrinsics;
synchronizacji;
modelu pola widzenia;
oceny confidence;
detekcji zabrudzenia;
arbitrażu konfliktu;
mapy przeszkód w body/local frame.

Producent nie publikuje algorytmu arbitrażu. Nie należy przypisywać mu konkretnego EKF/SLAM.

Radar fal milimetrowych#

Dokumentacja wymienia pasma 60–64 GHz i 24,0–24,25 GHz, zależne od regionu/konfiguracji. Zasięg różni się kierunkiem i obiektem. Producent wprost zaznacza, że detekcja zależy od powierzchni oraz zdolności odbijania fal elektromagnetycznych.[1]

Radar nie „widzi przez wszystko”. Słabe są:

cienki przewód o niekorzystnej orientacji;
mały obiekt;
materiał o małej przenikalności/odbiciu;
clutter przy podłożu;
multipath w metalowej hali;
obiekt blisko dużej konstrukcji;
opad przy granicznych wymaganiach.

24 GHz i 60 GHz różnią się propagacją, anteną i regulacją. Nie wolno aktywować pasma niezgodnego z regionem ani zmieniać hardware radaru.

Raport testowy powinien zapisywać, czy detekcja pochodziła z vision, radar czy fusion, jeśli UI/log to udostępnia. Sam fakt zatrzymania nie określa źródła.

Omijanie przeszkód#

Droga zatrzymania:

d_stop = v · t_latency + v²/(2a) + d_margin

Przy prędkości 15–23 m/s zakres około 20–30 m szybko przestaje być dużym zapasem. Profile Standard i Ludicrous powinny mieć różne ograniczenia OA. Dokładne zachowanie trzeba potwierdzić w instrukcji i release notes.

Omijanie może:

zahamować;
ominąć;
ograniczyć komendę;
wyłączyć się w trudnym środowisku;
być niedostępne w określonym trybie.

Operator powinien widzieć stan funkcji i confidence. Nie należy używać obecności ikon radarowych jako certyfikowanego detect-and-avoid względem lotnictwa.

GNSS, RTK i nawigacja#

Rodzina obsługuje GPS, Galileo, BeiDou i GLONASS. Producent podaje dokładność zawisu vision około ±0,15 m poziomo, GNSS około ±0,3 m oraz RTK około ±0,1 m w danych broszurowych, ale liczby zależą od warunków i wersji.[1][2]

RTK jest osobnym systemem korekt. Należy zapisywać:

stan fixed/float;
źródło korekt;
age of correction;
układ współrzędnych;
baseline;
liczbę satelitów;
timestamp ekspozycji;
lever arm.

Dokumentacja PSDK wspomina PPS i surowe wyjścia RTK w adapterze gimbala. To umożliwia lepszą synchronizację własnego sensora, ale nie gwarantuje automatycznej georeferencji — urządzenie musi prawidłowo rejestrować edge PPS i komunikat czasu.[6]

W urban canyon radar nie poprawia pozycji globalnej sam z siebie. Może wspierać odległość od przeszkód, podczas gdy VIO/GNSS odpowiadają za stan nawigacyjny.

A-Mesh#

A-Mesh jest funkcją sieciowania statków i kontrolerów, reklamowaną jako rozwiązanie rozszerzające łączność i współpracę wielu jednostek. Publiczna dokumentacja opisuje funkcje na poziomie użytkowym, ale nie ujawnia pełnego protokołu routingu, MAC, kryptografii ani warunków skalowania.[1][2]

Mesh nie oznacza, że każdy statek jednocześnie retransmituje każdą wiadomość bez kosztu. Występują:

airtime;
interferencja między hopami;
narzut routingu;
opóźnienie rosnące z hop count;
asymetria linków;
zmiana topologii;
wspólna domena radiowa;
zużycie energii.

Do opisu technicznego potrzebne są pomiary. Bez publicznego protokołu nie należy deklarować maksymalnej liczby hopów lub odporności kryptograficznej ponad dane producenta.

A-Mesh może zwiększyć pokrycie wokół przeszkody, ale relay również musi mieć bezpieczną pozycję i energię powrotu. Utrata węzła pośredniego może podzielić sieć.

Łącze SkyLink#

Łącze działa zależnie od regionu w 900 MHz, 2,4 GHz, 5,2 i 5,8 GHz. Maksymalna deklarowana odległość bieżącej wersji to 15 km FCC i 8 km CE w warunkach producenta; starsze materiały mogły podawać 20 km FCC.[1]

Ta różnica pokazuje, dlaczego broszura nie może zastąpić aktualnej specyfikacji. EIRP w CE jest niższe, np. 20 dBm w 2,4 GHz i 14 dBm w 5,8 GHz. Pasmo 900 MHz nie jest dostępne w każdej domenie.

Budżet łącza obejmuje:

P_rx = P_tx + G_tx + G_rx - L_fs - L_misc

ale realna jakość zależy od modulacji, szerokości kanału, anteny, Fresnela i zakłóceń. Telemetria, sterowanie i wideo mają inne wymagania. Degradacja bitrate obrazu może poprzedzać utratę kontroli, lecz nie musi.

Zasięg operacyjny ograniczają prawo, energia, teren i procedura. Maksymalna liczba nie jest zgodą na BVLOS.

Pakiety Fusion#

Głowica Fusion integruje kilka torów na stabilizowanym gimbalu. Dzięki fabrycznej integracji obraz, kąt, zapis i dalmierz są dostępne w jednej aplikacji. Kosztem jest zależność od wariantu oraz niepublicznego C-Port.

Porównanie funkcji:

Wariant	Wide	Zoom	Night	Thermal	LRF
4T	tak	tak	pośrednio przez wide	tak	tak
4T XE	inny wide/thermal zależnie od wersji	tak	—	tak	tak
4N	tak	zależnie od głowicy	0,0001 lux deklarowane	tak	tak
4NZ V2	wide/zoom	bardzo czuły tor nocny	tak	tak	tak

Dokładne sensory i ogniskowe należy czytać z tabliczki/metadata konkretnej głowicy. Strona producenta wskazuje mieszane dostawy termowizji o różnych parametrach.[1]

Fusion 4T#

Zoom camera ma sensor 1/2 cala 48 MP, ekwiwalent 64–234 mm, 2,7–10× zoom optyczny, f/2.8–4.8 i focus od około 2 m. Hybrid/digital zoom do 160× nie daje 160× rozdzielczości optycznej.[1]

Wide camera w zależności od wersji ma 48/50 MP i sensor około 1/2–1/1,28 cala. Zmiany wersji są ważne dla intrinsics, pixel pitch i low-light. Nie wolno używać jednego profilu calibration dla różnych głowic.

Gimbal stabilizuje trzy osie, z controllable pitch około −90° do +30° i mechanicznym szerszym zakresem. Deklarowany angular vibration poniżej 0,005° jest parametrem warunkowym. Tele przy 234 mm nadal może pokazać mikroruch.

Ekspozycja 1/30 s przy locie może powodować blur. Operator powinien ustawić czas na podstawie prędkości kątowej obrazu, nawet jeśli ISO rośnie.

Fusion 4N i 4NZ#

4N dodaje super-starlight night camera z deklarowaną minimalną iluminacją 0,0001 lux i bardzo wysokim ISO. Takie parametry nie gwarantują obrazu bez szumu, smużenia i denoisingu. Minimalna iluminacja zależy od kryterium SNR, przysłony i czasu ekspozycji, które trzeba sprawdzić w warunkach producenta.[1]

Tor nocny jest uzupełnieniem, nie zamiennikiem percepcji nawigacyjnej. Kamera payloadu może pokazywać scenę, podczas gdy kamery obstacle sensing mają zbyt mało światła. UI powinno osobno wskazywać health OA.

4NZ V2 łączy funkcje nocne i zoom. Większa liczba torów zwiększa obciążenie zapisu oraz potrzebę jednoznacznego wyboru streamu. Automatyczna aplikacja nie może zakładać, że „kamera główna” zawsze ma ten sam indeks.

Termowizja#

Typowa głowica oferuje 640 × 512, zakres temperatur około −20…550°C i zoom cyfrowy. Ogniskowa 9,1 lub 13 mm zależy od wariantu, co zmienia pole widzenia i IFOV.[1]

Radiometria wymaga:

emisyjności;
temperatury odbitej;
odległości;
wilgotności;
atmosfery;
prawidłowego gain;
NUC;
ostrości;
kalibracji.

Producent podaje, że JPG może zawierać informacje temperaturowe analizowane przez dedykowane SDK/narzędzia. Zwykły viewer może pokazać paletę bez danych radiometrycznych. Pipeline musi zachować oryginał i metadata.

Różni dostawcy sensora w mieszanych partiach utrudniają porównanie floty. Test czarnego ciała powinien być wykonany per głowica, a raport zawierać serial i wersję.

Dalmierz laserowy#

LRF pracuje przy długości fali 905 nm, ma deklarowany zakres 5–1200 m i dokładność:

±(1 m + D × 0,15%)

dla pionowej powierzchni odbijającej. Przy 1000 m składnik to ±2,5 m. Na małym, ciemnym, pochylonym albo zamglonym celu zasięg może być mniejszy.[1]

Punkt dalmierza musi zostać powiązany z osią optyczną i orientacją gimbala. Odległość skośna nie jest wysokością nad ziemią. Do współrzędnej celu potrzebne są pozycja statku, attitude, kąty gimbala, lever arms i model Ziemi/terenu.

905 nm może być niewidzialne dla oka. Producent definiuje klasę i zasady; nie należy patrzeć w aperture ani kierować na ludzi, pojazdy lub statki powietrzne. Portal nie publikuje procedur zwiększania mocy lub obchodzenia zabezpieczeń.

Smart Controller V3#

Kontroler waży około 1195 g bez osłony, ma ekran 7,9 cala 2000 nitów, 128 GB storage, Android 11, HDMI i GNSS. Obsługuje instalację aplikacji Android trzecich.[1]

Możliwość instalacji aplikacji jest zaletą MSDK, ale zwiększa powierzchnię ataku. Kontroler produkcyjny powinien mieć:

listę dozwolonych aplikacji;
brak prywatnych kont operatora;
kontrolowane aktualizacje;
wyłączone niepotrzebne usługi;
politykę USB;
szyfrowanie i blokadę;
procedurę utraty;
oddzielny egzemplarz developerski.

IP43 kontrolera nie pozwala zakładać odporności na ulewny deszcz. Jasny ekran zwiększa pobór: producent podaje około 3 h przy maksymalnej jasności i 4,5 h przy 50% w określonej konfiguracji. Kontroler może rozładować się szybciej niż kilka baterii statku.

Architektura portów#

EVO Max rozdziela:

C-Port dla oficjalnych gimbali;
P-Port dla payloadu PSDK;
P-Port Lite dla prostszego drugiego urządzenia;
adapter ring do integracji z mocowaniem gimbala.

To ważny podział własności. C-Port nie ma publicznej definicji pinów. Nie należy próbować reverse-engineering przez przypadkowe podawanie napięcia. P-Port ma udokumentowane VCC, USB, UART, detection i PPS zależnie od wariantu.[6]

Własny payload musi używać reference design i SDK właściwej wersji. NC pozostają niepodłączone. Zarezerwowany pin nie jest „wolnym GPIO”.

P-Port#

P-Port ma zasilanie VCC 12,8–17 V, limit 4 A i całkowitą moc 51,2–68 W zależnie od napięcia. Dokumentacja zaleca użycie wszystkich czterech pinów VCC dla stabilnego prądu. ON_DET zwarty do GND informuje statek o urządzeniu; nie stosuje się tam rezystora szeregowego według ICD.[6]

Dane:

USB 2.0, gdzie UAV jest hostem, payload device urządzeniem;
RNDIS/TCP-IP over USB;
UART RX/TX;
PPS w pełnym P-Port;
power management przez PSDK.

Przed podłączeniem własnego hardware:

sprawdzić pinout z bieżącej wersji;
zmierzyć rezystancję do masy;
uruchomić payload na zasilaczu laboratoryjnym;
zmierzyć inrush;
zweryfikować USB role;
dopiero użyć statku bez śmigieł.

Nie należy podawać zewnętrznego napięcia na VCC statku. Backfeeding może uszkodzić regulatory.

P-Port Lite#

P-Port Lite pozwala podłączyć drugi payload, ale nie obsługuje PPS według macierzy. Może służyć do prostych urządzeń UART albo debug przez USB-C, zależnie od aktualnego zestawu.[5][6]

Brak PPS ma znaczenie dla pomiarów. Timestamp software przez UART/USB ma zmienny latency. Jeśli sensor wymaga dokładności mikrosekundowej, Lite może być niewłaściwym wyborem.

„Lite” nie oznacza automatycznie mniejszego limitu masy; oznacza ograniczony interfejs. Wszystkie parametry elektryczne trzeba sprawdzić, zamiast kopiować pełny P-Port.

C-Port i adapter gimbala#

C-Port jest przeznaczony wyłącznie dla oficjalnych gimbali i nie ma ujawnionego pinoutu. Adapter gimbala udostępnia zdefiniowane zaciski dla zasilania, komunikacji, PPS, surowych wyjść RTK i Ethernetu wysokiej prędkości w przewidzianej konfiguracji.[6]

To nie znaczy, że C-Port stał się otwarty. Adapter jest warstwą translacji i mechanicznym interfejsem zatwierdzonym przez producenta. Projekt musi uwzględnić jego masę i ograniczenia.

Ethernet pomaga payloadom wysokiego bitrate, ale trzeba dobrać adresację, MTU, QoS i recovery po reconnect. Nie wolno zakładać gigabitowego transferu tylko z nazwy „Ethernet”; specyfikacja portu i realny throughput są nadrzędne.

Payload SDK#

PSDK jest biblioteką C dla Linux i RTOS. Oferuje logowanie, subskrypcję danych, zarządzanie kamerą/gimbalem, zasilanie, health, kanały danych, synchronizację czasu, motion planning i integrację z kontrolerem w zakresie macierzy produktu.[4][5]

Macierz wersji PSDK 1.1 wskazuje różnice funkcji między EVO Max i Autel Alpha. Przykładowo ogólna pozycja „Camera Functions” może być niedostępna dla EVO Max, mimo że Camera Management jest wspierane. Nazwy podobne nie są równoważne.

Projekt przypina:

aircraft + firmware + port + PSDK + toolchain + funkcja

Aktualizacja biblioteki statycznej może zmienić ABI lub wymagania. Artefakty, nagłówki i licencję trzeba archiwizować.

PSDK nie otwiera kodu autopilota. „Flight Control Support” jest API wysokiego poziomu i musi działać przez failsafe producenta, nie daje PWM do silnika.

Linux i RTOS#

Dokumentacja używa Raspberry Pi 4B jako referencji Linux oraz HC32F460 dla RTOS. Obsługiwane toolchainy obejmują aarch64/x86 Linux i Cortex-M4, m.in. STM32F407. HAL i OSAL pozwalają przenieść aplikację.[5]

Linux sprawdza się dla:

vision/AI;
storage;
Ethernet/USB;
rozbudowanych bibliotek.

RTOS sprawdza się dla:

małego poboru;
deterministycznej akwizycji;
prostego sensora;
krótkiego bootu.

Linux nie jest automatycznie mniej bezpieczny, a RTOS nie jest automatycznie real-time bez analizy. Liczą się priorytety, bounded queues, watchdog i worst-case latency.

Portowanie wymaga implementacji HAL UART/network oraz OSAL threads, mutex, semaforów i czasu. Funkcja sleep nie może udawać precyzyjnego harmonogramu.

Synchronizacja czasu#

Pełny P-Port i adapter mogą udostępnić PPS. PPS daje krawędź sekundy, ale do numeru sekundy potrzebny jest komunikat czasu. Payload powinien:

timestampować edge sprzętowo;
odczytać UTC/GNSS time;
mierzyć offset zegara;
wykrywać brak PPS;
zachować status RTK;
nie skakać zegarem monotonicznym.

Kamera, LiDAR lub sensor multispectral potrzebują powiązania pomiaru z ekspozycją, nie czasem zapisu pliku. Event trigger może sygnalizować dokładny moment.

P-Port Lite bez PPS może użyć synchronizacji sieciowej, ale dokładność i jitter trzeba zmierzyć. PTP/NTP nie wolno zakładać bez udokumentowanego wsparcia.

Mobile SDK#

Mobile SDK udostępnia sterowanie kamerą/gimbalem, telemetry, stream, media, virtual sticks i inteligentne misje. Aplikacja działa na urządzeniu/kontrolerze i łączy się przez warstwy Autela.[7]

Virtual stick to komenda podobna do drążka, nie trajektoria z gwarancją. Wymaga regularnego odświeżania, ograniczeń i zachowania po timeout. Waypoint mission ma wyższy poziom i lokalną logikę statku.

UI musi rozdzielać:

command requested;
sent;
acknowledged;
active state;
completed;
failed.

Autel SDK wymaga app key. Sekretu nie należy przechowywać jawnie w publicznym repozytorium. Build production i developer powinny używać różnych kluczy i kont.

Instalacja aplikacji na Smart Controller wymaga testu Android lifecycle, storage, permission i aktualizacji systemu.

Cloud API#

Cloud API wspiera EVO Max i opiera się na MQTT, HTTPS i WebSocket. Smart Controller, drone nest lub inne urządzenie brzegowe łączy system z chmurą trzeciej strony. Funkcje obejmują stream, media, wayline, HMS i zdalne sterowanie w obsługiwanym zakresie.[8]

Model:

UAV -> controller/nest/gateway -> Cloud API -> backend -> operator

Backend musi obsługiwać:

idempotency requestów;
reconnect MQTT;
kolejność wiadomości;
timestamp i freshness;
autoryzację per urządzenie;
rotację certyfikatów;
offline/degraded mode;
log audytowy.

Chmura nie powinna być jedynym miejscem failsafe. Utrata DNS, WAN lub tokena nie może uniemożliwić lokalnego powrotu/lądowania.

Granice dostępu#

Autel udostępnia więcej niż tylko aplikację, ale mniej niż otwarty autopilot:

PSDK rozszerza payload;
MSDK rozszerza GCS;
Cloud API rozszerza backend;
flight controller pozostaje zamknięty;
C-Port pozostaje niepubliczny;
A-Mesh jest funkcją bez pełnego publicznego protokołu.

To dobre środowisko dla integratora czujnika. Nie nadaje się do badań wymagających zmiany regulatora attitude, estymatora lub miksera.

Zamknięcie wymaga regresji po firmware. API może pozostać, a zachowanie motion planning się zmienić. Test kontraktu nie kończy się na kompilacji.

Dane i bezpieczeństwo#

System obejmuje statek, kontroler Android, payload Linux/RTOS, kartę SD, PSDK, MSDK i Cloud API. Najsłabszym elementem może być własny Raspberry Pi z domyślnym hasłem, nie szyfrowane łącze producenta.

Minimalne wymagania payloadu:

secure boot, jeśli platforma go wspiera;
read-only root lub atomic update;
unikalny credential;
wyłączone usługi debug;
firewall interfejsu RNDIS/Ethernet;
podpisany własny firmware;
szyfrowanie danych wrażliwych;
SBOM i licencje;
watchdog;
log bez sekretów.

RNDIS tworzy sieć IP. Nie należy ufać jej tylko dlatego, że kabel jest wewnątrz statku. Walidacja wiadomości, limit rozmiaru i odporność parsera pozostają potrzebne.

Cloud API wymaga threat model dla MQTT topics, tenancy i storage. Payload nie powinien przyjmować dowolnego polecenia z chmury bez autoryzacji i kontekstu stanu lotu.

Program kwalifikacji payloadu#

Etapy:

analiza masy, CG i portu;
test zasilania laboratoryjnego;
pomiar inrush oraz peak power;
test HAL/OSAL i PSDK na dev kit;
enumeracja bez śmigieł;
timeout, reconnect i brownout;
zapis po utracie zasilania;
EMC przy GNSS i łączu;
atrapa masowa w zawisie;
aktywny payload w zawisie;
stopniowy lot i pełna misja.

Budżet mocy P-Port do 68 W nie oznacza, że payload może stale pobierać 68 W w +40°C przy MTOW. Trzeba uwzględnić derating, przewody i termikę.

Inrush może wyzwolić ograniczenie mimo średniej 10 W. Stosuje się soft-start, pojemność zgodną z ICD i sekwencję power management.

Payload przechodzi do safe state przy utracie heartbeat. Mechaniczny actuator do zastosowania cywilnego powinien mieć krańcówki, timeout i brak ruchu po restarcie bez komendy.

Test percepcji#

Macierz łączy vision i radar:

Cel	Warunki	Oczekiwany pomiar
ściana betonowa	dzień/noc	dystans detekcji i hamowania
szkło	dzień	failure envelope vision/radar
przewód	różny kąt	recall i minimalna prędkość
siatka	metal/plastik	clutter i stabilność
roślinność	wiatr	obiekt ruchomy
powierzchnia czarna	słońce/cień	vision contrast
hala metalowa	multipath	false targets radaru

Test prowadzi się z małą energią i zabezpieczeniem. Celem jest wyznaczenie obwiedni, nie demonstracja kolizji.

ALIGNMENT: nie podajemy instrukcji aktywnego zakłócania radarów, GNSS ani łącza. W autoryzowanym laboratorium odporność można oceniać w komorze i z emulatorem; praktyczne kroki emisji zakłócającej pomijamy ze względów bezpieczeństwa i zgodności z zasadami.

Test A-Mesh i łącza#

A-Mesh testuje się jako topologię, nie tylko odległość:

direct;
jeden relay;
zmiana położenia relay;
utrata relay;
partition i merge;
różny ruch wideo;
kilka statków;
congested RF;
powrót po reconnect.

Metryki:

RTT p50/p95/p99;
packet loss;
command age;
video bitrate;
czas rekonwergencji;
hop count, jeśli dostępny;
zużycie energii relay;
spójność stanu misji.

Duplikat wiadomości po rekonwergencji nie może dwukrotnie uruchomić akcji. Każda komenda ma ID i idempotentną obsługę.

SkyLink testuje się w legalnym zakresie pasm. Region urządzenia i EIRP trafiają do raportu. Anteny kontrolera trzeba ustawić zgodnie z instrukcją.

Test kamer i radiometrii#

Wide/zoom:

rozdzielczość i MTF;
autofocus od minimalnego dystansu;
przejście między zoomami;
rolling shutter;
gimbal jitter;
metadata;
DNG/JPG;
bitrate H.264/H.265;
synchronizacja z LRF.

Termalna:

czarne ciało w kilku temperaturach;
NUC i warm-up;
emisyjność;
gain range;
drift;
RJPEG/JPG metadata;
alignment RGB–IR;
różnica między partiami sensorów.

LRF:

target pionowy o znanej odległości;
kilka reflektancji;
różne kąty;
porównanie 5, 100 i większych dystansów w dozwolonym obiekcie;
zgodność punktu aim z kamerą.

Test dalmierza wymaga bezpiecznej strefy optycznej i przestrzegania klasy lasera.

Test energii#

Profile osobno dla ABX40 i ABX41-D:

bez dodatkowego payloadu;
nominalna głowica + zapis;
jeden P-Port;
dwa payloady;
A-Mesh relay;
maksymalny legalny MTOM;
zimno/gorąco w zakresie instrukcji.

Zapisuje się masę, temperaturę, wiatr, SOC, napięcie, czas i progi. Lot kończy się przy operacyjnym progu, nie przez wymuszenie 0%.

Moc payloadu można oszacować przez energię:

E_payload = P_payload · t

Urządzenie 50 W przez 30 min pobierze 25 Wh — około 18% nominalnych 136,5 Wh ABX41-D — zanim uwzględnimy większą moc napędu z powodu masy.

Hot swap testuje się jako osobną procedurę naziemną. Po swapie system musi poprawnie rozpoznać nową baterię i nie zachować błędnego SOC.

Zarządzanie wersjami#

Manifest:

aircraft_family: EVO Max
generation: V1|V2
variant: 4T|4N|4T-XE|4NZ
aircraft_firmware: ...
controller_firmware: ...
gimbal_model: ...
gimbal_serial: ...
battery_model: ABX40|ABX41-D
propeller_model: 1136|1158
region: CE|FCC|...
psdk: ...
msdk: ...
cloud_api: ...
payloads: [...]

Do wersji PSDK dochodzi toolchain i hash biblioteki statycznej. Do Linux — kernel, image i commit aplikacji. Do RTOS — config oraz map file.

Aktualizacja wymaga testów kontraktów PSDK, portów, synchronizacji, cameras, OA, A-Mesh i failsafe. Nowa głowica wymaga calibration oraz pipeline metadata.

Dokumentacja pobrana z sekcji downloads powinna być archiwizowana z datą, bo plik pod tym samym linkiem może się zmienić.[3]

Typowe błędy#

EVO Max to jeden model. Generacja, wariant, gimbal, bateria i śmigła zmieniają parametry.

Różnica MTOM to dowolny udźwig. Port, CG, moc, termika i region ograniczają payload.

Vision + radar wykryje każdy przewód. Oba sensory mają przypadki słabe; fusion nie daje gwarancji.

A-Mesh ma darmowy zasięg przez wiele hopów. Każdy hop zużywa airtime, energię i zwiększa opóźnienie.

15/20 km to stała specyfikacja. Aktualne i starsze dokumenty różnią się, a CE/FCC mają inne EIRP.

160× zoom jest optyczny. Tylko część zakresu to zoom optyczny; reszta jest hybrydowa/cyfrowa.

0,0001 lux daje czysty obraz w ciemności. Minimalna iluminacja zależy od ekspozycji i kryterium SNR; obraz może smużyć i szumieć.

P-Port i C-Port są równie otwarte. C-Port ma niepubliczny pinout; P-Port jest interfejsem PSDK.

USB oznacza dowolne urządzenie. Role host/device, VCC, ON_DET i biblioteka PSDK są zdefiniowane.

Hot swap eliminuje preflight. Podtrzymuje system, ale nie zwalnia z kontroli baterii i stanu.

Cloud API steruje bezpośrednio silnikami. To warstwa systemowa przez gateway i autopilot, z własnymi ograniczeniami.

Powiązane tematy#

Przypisy#

Autel Robotics, „EVO Max 4T / EVO Max Series — Technical Specifications”, bieżące warianty, płatowiec, sensory, gimbale, łącze i bateria.
Autel Robotics, „EVO Max Series V2 Multi-rotor Drone User Manual”, instrukcja generacji V2 i parametry Appendix A.
Autel Robotics, „EVO Max Series Related Downloads”, instrukcje, maintenance manual i materiały wersjonowane.
Autel Developer, „What is PSDK”, zakres Payload SDK i jego miejsce obok Mobile SDK oraz Cloud API.
Autel Developer, „Choosing the Development Platform”, macierz funkcji EVO Max, P-Port/P-Port Lite, Linux i RTOS.
Autel Developer, „UAV Hardware Interfaces”, pinout P-Port, limity zasilania, USB/UART/PPS i granica C-Port.
Autel Developer, „Introduction to Mobile SDK”, virtual stick, misje, telemetria, media i aplikacje mobilne.
Autel Developer, „Cloud API”, architektura MQTT/HTTPS/WebSocket i wsparcie EVO Max.

Źródła z centralnego rejestru

Autel Robotics: EVO Max 4T and EVO Max Series technical specifications [dokumentacja producenta]
Autel Robotics: EVO Max Series V2 Multi-rotor Drone User Manual [instrukcja producenta]
Autel Robotics: EVO Max Series related downloads [dokumentacja producenta]
Autel Developer: Payload SDK overview [dokumentacja producenta]
Autel Developer: PSDK development-platform and feature matrix [dokumentacja producenta]
Autel Developer: EVO Max P-Port and payload hardware interfaces [dokumentacja producenta]
Autel Developer: Mobile SDK introduction [dokumentacja producenta]
Autel Developer: Cloud API overview [dokumentacja producenta]