DJI Matrice — profil architektury rodziny

Rodzina DJI Matrice nie jest jedną platformą powiększaną lub pomniejszaną w kolejnych generacjach. Matrice 350 RTK i Matrice 400 są ciężkimi, modułowymi nośnikami dla wymiennych głowic oraz urządzeń zewnętrznych, natomiast Matrice 4E i 4T integrują zestaw kamer w zwartej obudowie. Wspólne są: zamknięty autopilot, ścisła integracja statku z kontrolerem naziemnym, wielosensorowa nawigacja, transmisja DJI Enterprise i programistyczne interfejsy na obrzeżach systemu. Różne pozostają masa, energia, model payloadu i zakres redundancji.[1][3][4]

Profil architektury trzeba zatem czytać warstwowo. Dokumentacja producenta pozwala dobrze opisać interfejsy, parametry użytkowe, sensory zewnętrzne i wspierane SDK. Nie ujawnia jednak schematu kontrolera lotu, modeli użytych IMU, mikrokontrolerów, kodu estymatora ani logiki arbitrażu redundantnych sensorów. Tych braków nie wolno uzupełniać analogią do Pixhawka lub rozbiórkami innego modelu. Tam, gdzie z publicznych danych wynika jedynie funkcja systemowa, artykuł nazywa ją funkcją, a nie rzekomo znanym podzespołem.

Spis treści#

Zakres i poziomy pewności
Trzy profile platformy
Porównanie rodziny
Matrice 350 RTK
Matrice 400
Matrice 4E i 4T
Płatowiec i układ napędowy
Masa, środek ciężkości i bezwładność
Zasilanie M350 i TB65
Zasilanie M400 i TB100
Budżet energii
Flight controller — co wiadomo
GNSS, RTK i heading
Wizja, LiDAR i radar
ADS-B In
Łącze O3 i O4 Enterprise
Łączność komórkowa
Architektura payloadu
E-Port V2 i zasilanie akcesoriów
Kamery Matrice 4E i 4T
Payload SDK
Mobile SDK
Cloud API
Granica otwartości systemu
Dane, aktualizacje i cyberbezpieczeństwo
Odporność i degradacja
IP55 i środowisko
Program odbioru technicznego
Test energii i czasu lotu
Test RTK i nawigacji
Test detekcji przeszkód
Test łącza
Test payloadu
Zarządzanie konfiguracją
Typowe błędy interpretacyjne
Powiązane tematy
Przypisy

Zakres i poziomy pewności#

W zamkniętym systemie producenta trzeba rozróżnić cztery klasy wiedzy:

potwierdzone przez dokumentację — masa, rodzaj baterii, lista interfejsów, deklarowane ograniczenia środowiskowe i obsługiwane funkcje;
deklarowane osiągi — czas lotu, zasięg transmisji i dokładność RTK zmierzone w warunkach zdefiniowanych przez producenta;
wniosek architektoniczny — np. istnienie warstwy arbitrażu między sensorami, wynikające z obserwowalnego zachowania, lecz bez znajomości implementacji;
informacja niepubliczna — modele układów scalonych, topologia wewnętrznych magistral, kod regulatora, klucze i szczegóły protokołu radiowego.

To rozróżnienie ma znaczenie praktyczne. Deklarowane 55 minut lotu nie jest gwarantowanym czasem misji. Dokładność RTK wyrażona jako 1 cm + 1 ppm nie opisuje błędu zdjęcia na gruncie ani jakości modelu fotogrametrycznego. Obecność radaru nie oznacza, że system wykryje każdy przewód. Interfejs SDK nie daje dostępu do surowej pętli regulacji. Każda z tych liczb i nazw opisuje tylko fragment łańcucha.

Dokumentację należy zawsze wiązać z wersją. Na stronie pobierania M400 producent publikuje instrukcje użytkownika, release notes, pakiety firmware, maintenance manual i raport dotyczący systemów redundantnych. W sierpniu 2026 r. widoczna jest instrukcja w wersji 2.0 z 8 lipca 2026 r.; wcześniejszy zrzut strony albo instrukcja z 2025 r. może opisywać inny zestaw funkcji.[2]

Trzy profile platformy#

Matrice 350 RTK reprezentuje dojrzały ciężki nośnik poprzedniej generacji. Jego istotą jest wymienny payload Zenmuse lub zgodne urządzenie PSDK, dwie baterie TB65 i infrastruktura stanowiska pracy z kontrolerem RC Plus. Jest właściwy tam, gdzie ważniejsza od małego czasu przygotowania jest możliwość zmiany głowicy, dłuższa praca i kontrolowana integracja akcesoriów.[3]

Matrice 400 rozwija profil ciężkiego nośnika: producent podaje maksymalną masę startową 15,8 kg, maksymalny payload do 6 kg w określonej konfiguracji, cztery E-Port V2, nowsze łącze O4 Enterprise Enhanced oraz układ wykrywania przeszkód wykorzystujący widzenie, obracający LiDAR i radar fal milimetrowych. Jest to platforma transportująca system pomiarowy, nie tylko „dron z kamerą”.[1]

Matrice 4E i 4T należą do innego segmentu. Payload jest integralną częścią konstrukcji. Wariant 4E jest ukierunkowany na obrazowanie widzialne i fotogrametrię, m.in. przez szerokokątną kamerę 4/3 z migawką mechaniczną. Wariant 4T łączy kamery widzialne z termowizją. Krótszy łańcuch integracji zmniejsza liczbę złączy, adapterów i osobnych wersji firmware, ale użytkownik nie może zastąpić głowicy dowolnym modułem tak jak w ciężkich Matrice.[4]

Porównanie rodziny#

Cecha	Matrice 350 RTK	Matrice 400	Matrice 4E / 4T
profil	ciężki nośnik modułowy	ciężki nośnik modułowy	kompaktowa platforma z kamerami zintegrowanymi
masa z podstawowym zasilaniem	ok. 6,47 kg z dwiema TB65	ok. 9,74 kg z bateriami	zależna od wariantu; patrz bieżąca specyfikacja
maksymalna masa startowa	9,2 kg	15,8 kg	klasa znacznie lżejsza
deklarowany payload	gimbal do 960 g	do 6 kg na trzecim złączu w warunkach producenta	zasadniczo sensory wbudowane
łącze	O3 Enterprise	O4 Enterprise Enhanced	system Enterprise właściwy generacji
główne wykrywanie przeszkód	wizyjne i podczerwone	wizyjne, LiDAR, ToF i mmWave radar	wielokierunkowe widzenie i dolny 3D IR
integracja payloadu	gimbale i urządzenia PSDK	gimbale, E-Port V2 i urządzenia PSDK	głównie funkcje wbudowanych kamer
typowe zadanie	inspekcja, mapowanie, bezpieczeństwo publiczne	ciężkie sensory, złożone inspekcje, wielopayload	szybka inspekcja, obrazowanie, termowizja

Tabela celowo nie przenosi zasięgu radiowego lub czasu lotu do jednej liczby. Producent podaje je dla różnych domen radiowych, obciążenia, prędkości, wiatru i sposobu zakończenia próby. Porównanie bez normalizacji warunków prowadziłoby do fałszywej precyzji.

Matrice 350 RTK#

M350 jest składanym quadrocopterem o rozstawie osi około 895 mm. Producent podaje masę około 6,47 kg z dwiema bateriami TB65, maksymalną masę startową 9,2 kg, maksymalną prędkość poziomą 23 m/s i odporność na wiatr do 12 m/s podczas startu i lądowania. Deklarowane 55 minut uzyskano bez payloadu, bez wiatru, przy locie do osiągnięcia progu zdefiniowanego w procedurze producenta; nie jest to planowalny czas pracy z głowicą.[3]

System może przenosić głowice Zenmuse i certyfikowane urządzenia zgodne z Payload SDK. Dostępne konfiguracje gimbali obejmują mocowania dolne i górne, a układ należy oceniać jako całość: statek, adapter, przewód, gimbal, sensor, karta pamięci i ewentualne anteny. Limit masy gimbala 960 g nie zastępuje kontroli kompatybilności na liście producenta.

M350 korzysta z wielu konstelacji GNSS i RTK. Wizyjne sensory przeszkód mają określone zakresy pracy, wymagają dostatecznej tekstury oraz oświetlenia; czujniki podczerwone pokrywają krótsze dystanse. Gładka, przezroczysta, bardzo ciemna albo refleksyjna powierzchnia może nie spełnić założeń algorytmu, mimo że mieści się geometrycznie w polu widzenia.

Matrice 400#

M400 jest platformą większą i cięższą: producent podaje 9,74 kg masy z bateriami, 15,8 kg maksymalnej masy startowej, rozstaw osi 1070 mm, śmigła klasy 25 cali i maksymalną prędkość poziomą 25 m/s. Pułap eksploatacyjny i dopuszczalna konfiguracja śmigieł zależą od wysokości oraz payloadu; liczba „7000 m” w specyfikacji nie oznacza zdolności startu z pełnym obciążeniem na każdej wysokości.[1]

Deklarowany maksymalny payload 6 kg dotyczy trzeciego złącza i konfiguracji montażowej wskazanej przez producenta, mierzonej przy poziomie morza. W pozostałych konfiguracjach występują niższe limity. Producent rozróżnia mocowanie szybkozłączne i śrubowe, pojedynczy, podwójny oraz trzeci punkt montażowy. To ważne, bo „udźwig platformy” nie jest jedną stałą — ograniczają go równocześnie masa startowa, mocowanie, środek ciężkości, zasilanie, wibracje i warunki atmosferyczne.

M400 udostępnia cztery porty E-Port V2, każdy o deklarowanej mocy do 120 W, oraz osobne interfejsy dla modułów komórkowych. Układ sensorów środowiska obejmuje wielokierunkowe kamery stereoskopowe typu fisheye, obracający LiDAR, górny czujnik 3D ToF, dolny czujnik podczerwieni i — w regionach, w których funkcja jest dopuszczona — sześciokierunkowy radar mmWave. Jest to architektura komplementarna: sensory mają różne pola widzenia, rozdzielczości, opóźnienia i słabe punkty.

Matrice 4E i 4T#

Matrice 4E łączy szerokokątną kamerę 4/3 o rozdzielczości 20 MP i migawce mechanicznej z kamerami o dłuższych ogniskowych. Migawka mechaniczna ogranicza artefakty rolling shutter przy obrazowaniu z ruchu, ale nie usuwa błędów wynikających z wysokości, czasu ekspozycji, niewłaściwego overlapu, błędów RTK lub odkształcenia sceny. Profil 4E jest zatem sensowny dla mapowania i dokumentacji, lecz jakość produktu zależy od całego workflow fotogrametrycznego.[4]

Matrice 4T ma zestaw kamer widzialnych oraz sensor termiczny 640 × 512. Producent opisuje tryb super-resolution 1280 × 1024 oraz NETD nie większe niż 50 mK przy określonych warunkach. Super-resolution nie zmienia fizycznej liczby detektorów. Parametr NETD nie jest tożsamy z dokładnością temperatury obiektu, która zależy również od emisyjności, odbić, transmisji atmosfery, odległości, ostrości i kalibracji.

W obu wariantach obraz z szerokiego, średniego i teleobiektywu pochodzi z różnych torów optycznych i sensorów. Przejście między powiększeniami może zmienić geometrię, ekspozycję, ostrość i położenie osi optycznej. Dla pomiarów nie należy traktować „zoomu hybrydowego” jako jednego kalibrowanego obiektywu o płynnie zmienianej ogniskowej.

Płatowiec i układ napędowy#

Ciężkie Matrice są quadrocopterami. Cztery zespoły napędowe zapewniają prostą mechanikę i dobrą sprawność względem platform o sześciu lub ośmiu wirnikach, ale awaria napędu pozostawia mniej swobody niż w multirotorze z nadmiarowym wirnikiem. Informacja o „redundancji systemu” nie może być automatycznie interpretowana jako zdolność kontynuowania lotu po dowolnym uszkodzeniu silnika, ESC lub śmigła.

Producent dobiera silnik, ESC, śmigło i algorytmy sterowania jako zestaw. Nie ma podstaw, aby zastępować śmigło modelem o tych samych wymiarach bez kwalifikacji. Różnica sztywności, masy, profilu i momentu bezwładności wpływa na prąd, pasmo napędu i zapas regulatora. Łopatę trzeba oceniać pod kątem pęknięć przy piaście, wyszczerbień, rozwarstwień, luzu i symetrii pary.

Moc zawisu rośnie w przybliżeniu szybciej niż liniowo z ciężarem. W idealizowanym modelu momentum:

P_induced ≈ T^(3/2) / sqrt(2 ρ A)

gdzie T to całkowity ciąg, ρ — gęstość powietrza, a A — suma pól tarcz wirników. Dodatkowy kilogram nie skraca czasu lotu o stały procent dla każdej konfiguracji. Zmienia punkt pracy śmigieł, prąd, temperaturę uzwojeń, rezerwę do manewru i prędkość optymalną energetycznie.

Masa, środek ciężkości i bezwładność#

Masa payloadu jest tylko pierwszym testem. Drugi stanowi położenie środka ciężkości, trzeci — momenty bezwładności. Ten sam sensor umieszczony daleko od środka zwiększa moment bezwładności I = Σ m r², przez co statek wolniej zmienia prędkość kątową i wymaga większego różnicowania ciągu. Długi wysięgnik może mieścić się w limicie masy, a mimo to pogorszyć tłumienie oscylacji i zapas sterowania na wietrze.

Integracja powinna zawierać:

ważenie kompletnej konfiguracji gotowej do lotu;
wyznaczenie środka ciężkości w trzech osiach;
kontrolę obwiedni śmigieł i ruchu gimbala;
sprawdzenie pola widzenia GNSS, radarów, LiDAR-u i kamer;
kontrolę przewodów przy skrajnych położeniach gimbala;
próbę wibracyjną i analizę obrazu;
pomiar temperatury payloadu oraz interfejsu zasilania;
stopniowe rozszerzanie obwiedni lotu.

Dokumentacja M400 podaje dodatkowo różną trwałość elementu tłumiącego zależnie od masy gimbala: dla cięższej głowicy okres obsługowy może być krótszy. To pokazuje, że ograniczenie nie kończy się na wytrzymałości statycznej. Elastomer akumuluje cykle, pełzanie i ekspozycję środowiskową.[1]

Zasilanie M350 i TB65#

M350 pracuje z parą inteligentnych baterii TB65. Producent podaje dla pojedynczej baterii energię 263,2 Wh i masę około 1,35 kg. Dwie sztuki tworzą nominalny zasób około 526,4 Wh, ale energii tej nie należy w całości wpisywać do planu misji. Część pozostaje jako rezerwa, część jest niedostępna wskutek ograniczeń napięciowych pod obciążeniem, temperatury i starzenia.[3]

Para baterii musi być zarządzana jako para eksploatacyjna. Należy rejestrować numery, liczbę cykli, różnicę napięć sekcji, temperatury, historię błędów i wynik testu pojemności. Losowe łączenie baterii o różnym stanie zdrowia może sprawić, że słabszy pakiet narzuci ograniczenie całemu zestawowi. Komunikat aplikacji nie zastępuje oględzin pod kątem obrzęku, uszkodzeń obudowy, korozji styków i śladów przegrzania.

Stan naładowania jest estymatem, nie pomiarem paliwa w zbiorniku. Battery-management system łączy coulomb counting z modelem napięcia, temperatury i historii. Po długim składowaniu, głębokim rozładowaniu lub zmianie temperatury błąd estymacji może się zwiększyć. Procedura organizacji powinna używać progów powrotu i lądowania z zapasem niezależnym od optymistycznego czasu pozostałego.

Zasilanie M400 i TB100#

Specyfikacja TB100 podaje układ 13S Li-ion, pojemność 20 254 mAh, napięcie nominalne 48,23 V, energię 977 Wh i masę około 4,72 kg. Maksymalny deklarowany prąd rozładowania opisano jako 4C, ładowania jako 2C, a projektową liczbę cykli jako 400 w warunkach producenta. Bateria ma funkcję ogrzewania.[1]

Iloczyn pojemności i napięcia daje kontrolę rzędu wielkości:

20,254 Ah × 48,23 V ≈ 976,9 Wh

zgodną z deklarowanymi 977 Wh. Nie znaczy to, że prawie 1 kWh zostanie oddane napędowi w każdej temperaturze. Maksymalny prąd, spadek napięcia, straty przekształtników, ogrzewanie i próg bezpieczeństwa ograniczają użyteczną energię.

Liczba 400 cykli nie jest datą automatycznej bezpieczności ani awarii. „Cykl” może odpowiadać sumie częściowych rozładowań, a degradacja zależy od głębokości rozładowania, temperatury, czasu na wysokim SOC i prądu. Flota potrzebuje kryterium opartego na pojemności, rezystancji, błędach BMS i wymaganiach misji, nie tylko liczniku.

Budżet energii#

Budżet misji można zapisać jako:

E_misji = E_start + E_dolot + E_praca + E_powrot + E_ladowanie + E_rezerwa

Każdy składnik powinien pochodzić z pomiarów dla danej masy i warunków. Lot zawisowy, przelot i praca z ciężkim sensorem mają inne punkty pracy. Payload pobierający 100 W przez pół godziny zużyje około 50 Wh, lecz jego masa może zwiększyć pobór napędu o znacznie więcej.

Próby czasu lotu należy kończyć przy operacyjnym progu, a nie przez wymuszanie lotu do 0%. Dla kolejnych konfiguracji warto zapisywać:

Wielkość	Sposób raportowania
masa startowa	zmierzona wraz z baterią i przewodami
temperatura	powietrza, baterii przed startem i po lądowaniu
wiatr	średni i porywy, z podaniem metody pomiaru
profil	czas zawisu, prędkości, wznoszenie, praca payloadu
energia	SOC początkowy/końcowy oraz energia raportowana
napięcie	minimum pod obciążeniem i po odciążeniu
rezerwa	próg powrotu, lądowania i faktyczny zapas

Porównywalność jest ważniejsza niż rekord. Lot wykonany na nowej baterii w bezwietrzny dzień nie kwalifikuje misji zimowej po 150 cyklach.

Flight controller — co wiadomo#

Publiczna dokumentacja potwierdza funkcje: stabilizację, nawigację GNSS/RTK, integrację sensorów wizyjnych, procedury powrotu, zarządzanie łączem i baterią. Nie podaje natomiast pełnej listy procesorów, IMU, częstotliwości pętli, filtrów ani schematu zasilania. Dlatego nie należy opisywać M400 jako „kontrolera STM32H7 z EKF3” tylko dlatego, że taka architektura jest popularna gdzie indziej.

Zachowanie systemowe sugeruje wiele domen obliczeniowych: sterowanie krytyczne czasowo, przetwarzanie obrazu i LiDAR-u, kodowanie transmisji, obsługa payloadów i aplikacja kontrolera. To rozsądny model blokowy, ale liczba fizycznych SoC i sposób izolacji nie są w pełni publiczne.

Bezpieczny model dokumentacyjny brzmi:

sensory lotu -> estymacja stanu -> sterowanie -> napęd

sensory otoczenia -> percepcja -> ograniczenia trajektorii / ostrzeżenia

RC / misja -> logika zadania -> zadania nawigacyjne

payload -> E-Port / gimbal -> aplikacja i zapis danych

Nie należy dopisywać, że wszystkie strzałki prowadzą przez jeden procesor. Równie ważne jest to, że obstacle avoidance może ograniczać komendę zadania, ale nie jest gwarantowanym systemem certyfikowanego detect-and-avoid dla każdego środowiska.

GNSS, RTK i heading#

M350 i M400 obsługują wielokonstelacyjny GNSS, a tryb RTK korzysta z korekt oraz geometrii anten do wyznaczenia pozycji i kierunku. Producent deklaruje dla RTK dokładność poziomą 1 cm + 1 ppm i pionową 1,5 cm + 1 ppm w warunkach pomiarowych, a dla headingu M400 błąd mniejszy niż 2°.[1][3]

Składnik ppm rośnie z odległością od źródła korekt. Przy 10 km wartość 1 ppm odpowiada 10 mm dodatkowego składnika, ale całkowity błąd produktu nie jest prostym wynikiem dodawania jednej liczby. Wpływ mają stan fixed/float, wielodrożność, zasłonięcie nieba, jakość bazy lub NTRIP, opóźnienie korekt, transformacja układu współrzędnych, lever arm kamery i georeferencja czasu ekspozycji.

RTK heading jest szczególnie użyteczny w zawisie, gdzie kierunek z różnicy kolejnych pozycji jest słabo obserwowalny. Nie zastępuje jednak kontroli montażu anten i stanu rozwiązania. Konstrukcja payloadu nie może zasłaniać anten, tworzyć silnych reflektorów RF ani wnosić zakłóceń do pasma GNSS.

Raport z misji powinien przechowywać co najmniej:

liczbę i konstelacje satelitów;
tryb rozwiązania RTK w czasie;
wiek i źródło korekt;
przerwy w korektach;
estymowaną dokładność i ostrzeżenia;
układ odniesienia oraz geoidę;
wersje firmware i aplikacji;
położenie bazy i metodę jego wyznaczenia.

Wizja, LiDAR i radar#

Wielomodalny sensing M400 nie polega na tym, że trzy sensory mierzą dokładnie to samo. Kamery stereoskopowe dają bogatą informację kątową i teksturę, ale słabną w ciemności, przy olśnieniu, mgle i na powierzchniach bez cech. LiDAR mierzy zasięg aktywnie, lecz jego skuteczność zależy od reflektancji, geometrii, atmosfery i gęstości próbek. Radar mmWave może wykrywać obiekty przy trudniejszej widoczności optycznej, ale ma inną rozdzielczość kątową i charakter clutteru.

Producent podaje dla obrotowego LiDAR-u M400 m.in. zakres od 0,5 do 100 m przy 10% reflektancji i silnym oświetleniu oraz przepływ do 520 tys. punktów/s. Są to warunki graniczne specyfikacji, nie obietnica wykrycia każdego obiektu na 100 m. Cienki przewód może trafić pomiędzy wiązki, mieć niekorzystny kąt i małą efektywną powierzchnię odbicia.[1]

Fusion może poprawić pokrycie, lecz tworzy nowe wymagania:

kalibracja położenia i orientacji sensorów;
synchronizacja czasowa;
transformacje współrzędnych;
maskowanie fragmentów statku i payloadu;
wykrywanie zabrudzenia lub degradacji;
logika konfliktu między obserwacjami;
ograniczenie prędkości względem zasięgu i opóźnienia.

Minimalny dystans zatrzymania można oszacować:

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

Przy wzroście prędkości część hamowania rośnie kwadratowo. Sensor widzący przeszkodę daleko nie pomoże, jeśli percepcja, planowanie, reakcja napędu i wiatr zużyją cały margines.

ADS-B In#

M400 ma podwójną antenę ADS-B In; producent deklaruje odbiór sygnałów załogowych statków powietrznych w sprzyjających warunkach nawet z dużej odległości. ADS-B In jest źródłem świadomości sytuacyjnej, a nie pełnym detect-and-avoid. Nie każdy obiekt emituje ADS-B, wiadomość może być opóźniona lub błędna, a geometria anten i zakłócenia zmieniają zasięg.[1]

Operator nie powinien wnioskować „brak celu na ekranie = brak ruchu lotniczego”. ADS-B trzeba łączyć z obserwacją, procedurami przestrzeni, informacją służb ruchu i ograniczeniami operacji. System odbiorczy nie nadaje statkowi pierwszeństwa ani nie legalizuje lotu BVLOS.

Łącze O3 i O4 Enterprise#

M350 korzysta z O3 Enterprise, a M400 z O4 Enterprise Enhanced. Są to zintegrowane łącza sterowania, telemetrii i obrazu, pracujące w pasmach oraz mocach zależnych od regionu. Producent publikuje różne maksymalne odległości dla FCC, CE, SRRC i MIC oraz dla poziomu zakłóceń. Dla M400 wartości w słabym środowisku mogą sięgać dziesiątek kilometrów, podczas gdy w silnym zakłóceniu specyfikacja podaje zakres rzędu 1,5–6 km.[1][3]

Takiej liczby nie wolno wpisywać jako „zasięgu drona”. Zasięg operacyjny ograniczają równocześnie:

przepisy i zezwolenie operacyjne;
linia widzenia oraz strefa Fresnela;
wysokość anten;
EIRP właściwe regionowi;
orientacja anten statku i kontrolera;
zajętość kanału;
opóźnienie, utrata pakietów i bitrate obrazu;
zapas energii na powrót;
pogoda i teren awaryjnego lądowania.

W próbie należy zapisywać jakość łącza względem trasy, a nie tylko maksymalną odległość. Interesują: procent czasu z degradacją wideo, utrata telemetrii, opóźnienie komendy, czas rekonfiguracji kanału, zachowanie po zasłonięciu i margines przy powrocie inną orientacją.

Łączność komórkowa#

M400 ma interfejsy dla modułów Cellular Dongle 2. Łączność komórkowa może uzupełnić tor radiowy, ale wnosi zależność od operatora, zasięgu komórki, routingu, przeciążenia, APN, roamingu i opóźnienia. Nazwa „4G enhanced transmission” nie oznacza deterministycznego kanału czasu rzeczywistego.

Ocena LTE powinna obejmować:

medianę oraz percentyle 95/99 opóźnienia, nie tylko średnią;
przerwy przy handover między komórkami;
zachowanie przy utracie uplinku i downlinku;
limit transferu i politykę operatora;
zgodność regionalną modułu i kart SIM;
rozdzielenie danych lotnych, wideo i administracji;
procedurę utraty usług chmurowych.

Tor komórkowy nie powinien być pretekstem do usunięcia lokalnego failsafe. Platforma ma bezpiecznie zakończyć lot również wtedy, gdy Internet, DNS, serwer i uwierzytelnienie są niedostępne.

Architektura payloadu#

W ciężkim Matrice payload jest podsystemem z własną mechaniką, zasilaniem, danymi, termiką i lifecycle firmware. Głowica Zenmuse wykorzystuje zdefiniowane mocowanie oraz protokół producenta. Urządzenie trzecie może korzystać z Payload SDK i odpowiedniego zestawu rozwojowego, ale zakres funkcji zależy od statku, portu, wersji firmware oraz wersji PSDK.[5]

Architekt powinien przygotować macierz:

Warstwa	Pytanie kwalifikacyjne
mechanika	masa, CG, moment, obwiednia i częstotliwości własne
energia	napięcie, moc ciągła/szczytowa, inrush i zachowanie brownout
dane	interfejs, bitrate, opóźnienie, utrata i timestamp
sterowanie	komendy, stany, timeouty i bezpieczny stan
termika	temperatura obudowy i hot spot w zawisie/słońcu
EMC	emisja do GNSS/RC i odporność na ESC/radio
software	wersje PSDK, firmware, aplikacji oraz zgodność modelu
operacje	checklista, uprawnienia operatora i recovery danych

Payload nie może polegać na pojedynczej komendzie „włącz” bez potwierdzenia stanu. Potrzebne są: identyfikator urządzenia, health, kod błędu, stan zapisu, pozostałe miejsce, temperatura i jednoznaczny timestamp. W pomiarach naukowych informacja o nieudanej próbce jest równie ważna jak sama próbka.

E-Port V2 i zasilanie akcesoriów#

M400 oferuje cztery E-Port V2 o deklarowanej mocy do 120 W każdy. Maksimum portu nie oznacza, że cztery urządzenia mogą jednocześnie pobierać maksimum w każdych warunkach. Trzeba sprawdzić całkowity limit systemu, ograniczenia konkretnego przewodu i zestawu rozwojowego, rozruch obciążeń pojemnościowych oraz wpływ na czas lotu.[1][5]

Przy własnym payloadzie należy zmierzyć:

prąd jałowy po inicjalizacji;
prąd szczytowy przy starcie sensora, grzałki lub komputera;
moc w najgorszym trybie przetwarzania;
zachowanie przy spadku i zaniku zasilania;
czas bezpiecznego zamknięcia pliku;
temperaturę złącza i przewodu;
emisję RF w pobliżu anten GNSS i łącza.

Komputer pokładowy powinien używać odpornego systemu plików albo transakcyjnego zapisu. Odłączenie zasilania przy lądowaniu nie może niszczyć całej sesji. Dla ważnych danych stosuje się dzielenie na krótkie segmenty, fsync w kontrolowanych punktach, sumy kontrolne i manifest sesji.

Kamery Matrice 4E i 4T#

Zintegrowany payload zmniejsza ryzyko złego CG i niezgodnej wersji gimbala, ale nie usuwa konieczności kalibracji. W 4E parametry szerokiej kamery 4/3 z migawką mechaniczną wspierają mapowanie. Trzeba nadal dobrać GSD, overlap, prędkość i ekspozycję:

GSD ≈ H · p / f

gdzie H jest wysokością nad obiektem, p rozmiarem piksela, a f ogniskową. W praktyce używa się kalibracji i danych producenta, ponieważ cyfrowe przeskalowanie oraz korekcja optyczna komplikują prosty model.

W 4T radiometria termiczna wymaga osobnej procedury. Dwie powierzchnie o tej samej temperaturze mogą mieć różną radiancję wskutek emisyjności. Metal może odbijać chłodne niebo albo gorące źródło poza kadrem. Termogram powinien przechowywać ustawienia zakresu, emisyjności, odległości, temperatury odbitej i atmosfery, jeśli celem jest pomiar, a nie tylko wykrycie kontrastu.

Teleobiektyw jest dobry do inspekcji z dystansu, ale zwiększa czułość na drgania i błąd kierunku. Czas ekspozycji powinien być sprawdzany względem ruchu kątowego, a autofokus — kwalifikowany na rzeczywistym celu. Ostry podgląd skompresowanego streamu nie gwarantuje ostrego pliku źródłowego.

Payload SDK#

Payload SDK jest warstwą integracji urządzenia pokładowego z ekosystemem DJI. Udostępnia funkcje zależne od platformy, m.in. komunikację, sterowanie gimbalem lub kamerą, przesył danych, widgety w aplikacji i dostęp do wybranych informacji statku. Oficjalna dokumentacja utrzymuje macierz wspieranych produktów, interfejsów i wersji firmware.[5]

Najważniejsza zasada: obecność nazwy funkcji w PSDK nie oznacza wsparcia na każdym modelu. Projekt musi przypiąć:

model statku + wersja firmware + port + hardware adaptera + wersja PSDK + funkcja

Test na M350 nie kwalifikuje automatycznie M400. Aktualizacja PSDK może wymagać zmiany toolchainu lub zachowania kodu. Przed wdrożeniem należy zachować artefakt kompilacji, plik wersji, commit własnego kodu i wynik testów regresji.

PSDK nie jest otwartym firmware kontrolera lotu. Umożliwia integrację na przewidzianej granicy i celowo ogranicza dostęp do funkcji krytycznych. To korzystne dla spójności, lecz utrudnia eksperymenty wymagające własnej pętli sterowania albo surowych danych sensorów z deterministycznym timestampem.

Mobile SDK#

Mobile SDK V5 służy do budowy aplikacji współpracujących z obsługiwanymi produktami DJI. Zapewnia API wysokiego poziomu dla informacji o statku, kamer, gimbali, misji i części funkcji sterowania. Dokumentacja i lista kompatybilności są wersjonowane; przed obietnicą wsparcia konkretnego Matrice trzeba sprawdzić bieżącą macierz, a nie zakładać zgodność całej rodziny.[6]

Aplikacja mobilna nie powinna mieszać trzech warstw:

stanu rzeczywistego statku;
stanu żądanej komendy;
stanu interfejsu użytkownika.

Po kliknięciu przycisku lokalna ikona nie jest dowodem wykonania komendy. Interfejs powinien czekać na potwierdzony stan urządzenia, obsługiwać timeout i prezentować przyczynę odrzucenia. Telemetria musi nieść timestamp oraz wskaźnik świeżości, aby stara wartość nie wyglądała jak aktualna.

Automatyzacja misji wymaga testów po przerwaniu aplikacji, zablokowaniu ekranu, zmianie sieci i utracie kontrolera. Nie można zakładać, że lifecycle systemu Android jest równoważny ciągłemu procesowi przemysłowemu.

Cloud API#

Cloud API opisuje model device–edge–cloud. Statek nie łączy się bezpośrednio z dowolnym backendem użytkownika. Rolę bramy pełni obsługiwany kontroler z DJI Pilot 2 albo Dock; komunikacja z chmurą wykorzystuje m.in. MQTT, HTTPS i WebSocket. Backend może działać w infrastrukturze publicznej lub prywatnej, jeśli brama może go osiągnąć.[7]

Rozdział odpowiedzialności można przedstawić tak:

UAV / payload -> RC Plus lub Dock -> protokoły Cloud API -> backend -> operator

Cloud API obejmuje funkcje takie jak zarządzanie urządzeniem, mapą, świadomością sytuacyjną, livestreamem, mediami i trasami; dla Docka również wybrane zdalne operacje i alarmy. Nie oznacza to dostępu do wewnętrznej pętli stabilizacji.

Backend powinien projektować operacje jako idempotentne. Ponowiona wiadomość MQTT po reconnect nie może utworzyć dwóch misji ani dwukrotnie zatwierdzić niebezpiecznej operacji. Potrzebne są identyfikatory żądań, wersjonowanie stanu, jawne ACK i log audytowy.

Synchronizacja czasu ma znaczenie dla zdjęć, telemetrii i tras. NTP bramy, czas backendu i zegar payloadu mogą się różnić. W produkcie pomiarowym trzeba mierzyć offset i nie mieszać czasu odbioru wiadomości z czasem wykonania ekspozycji.

Granica otwartości systemu#

Rodzina Matrice jest rozszerzalna, ale nie otwarta w rozumieniu ArduPilot/PX4. Użytkownik może integrować payload, aplikację i chmurę przez udokumentowane API. Nie może swobodnie przebudować estymatora, miksera, sterownika ESC ani systemu bootowania kontrolera lotu.

Ma to konsekwencje:

krótsza integracja typowych głowic;
wspólny UX i serwis;
mniejsza kontrola nad niskim poziomem;
zależność od roadmapy i macierzy wsparcia producenta;
konieczność regresji po aktualizacji firmware;
trudniejszy niezależny audyt algorytmów krytycznych;
ograniczona możliwość HIL z pełnym firmware statku.

Do badań nad payloadem lub workflow inspekcyjnym zamknięcie może być akceptowalne. Do badań nad regulacją lotu, własnym estimatoriem albo formalną weryfikacją kodu lepsza będzie platforma otwarta. Decyzję należy oprzeć na warstwie, którą zespół rzeczywiście chce zmieniać.

Dane, aktualizacje i cyberbezpieczeństwo#

System enterprise obejmuje statek, kontroler, aplikację, ewentualny Dock, payload i backend. Każdy element ma osobny firmware, konto, logi i kanał aktualizacji. Bezpieczeństwo nie sprowadza się do hasła Wi-Fi.

Minimalny model powinien uwzględniać:

konta administratorów i operatorów z najmniejszymi uprawnieniami;
ewidencję numerów seryjnych i wersji;
kontrolowane źródło pakietów aktualizacji;
hash pobranego artefaktu, jeśli jest publikowany lub możliwy do obliczenia lokalnie;
szyfrowanie nośników i politykę eksportu logów;
retencję zdjęć, telemetrii i danych lokalizacji;
separację sieci kontrolera od biurowej;
certyfikaty, sekrety MQTT/API i ich rotację;
procedurę zgubienia kontrolera;
tryb pracy bez chmury i oczekiwane ograniczenia.

Aktualizacji nie powinno się wykonywać tuż przed ważną misją. Najpierw laboratorium, potem lot regresyjny bez payloadu, następnie konfiguracja referencyjna i dopiero konkretna misja. Jeśli producent udostępnia pakiet offline, organizacja może lepiej kontrolować okno i archiwizować używaną wersję, ale nadal musi przestrzegać warunków oraz weryfikować autentyczność pakietu.[2]

Log audytowy powinien wiązać misję z operatorem, statkiem, baterią, payloadem, wersją aplikacji, wersją firmware, planem, źródłem korekt RTK i eksportem danych. Bez tego po incydencie nie da się rozstrzygnąć, czy zmiana wyniku pochodziła z hardware, środowiska czy aktualizacji.

Odporność i degradacja#

Redundancja jest właściwością konkretnej funkcji, nie etykietą całego statku. Dwie baterie, anteny albo sensory mogą chronić przed niektórymi awariami wspólnymi, ale nie przed wszystkimi. Wspólny przewód, złącze, regulator, procesor, błąd firmware albo zalanie może pokonać oba kanały.

Analizę FMEA warto prowadzić per funkcja:

Funkcja	Usterka	Wykrycie	Degradacja	Działanie operatora
pozycja GNSS	utrata korekt	stan RTK i alert	RTK fixed do float/standalone	przerwać pomiar precyzyjny
heading	konflikt źródeł	alert lub skok yaw	większy błąd kierunku	ustabilizować i lądować wg instrukcji
sensing	zabrudzenie kamery/LiDAR	self-test lub niespójność	ograniczone omijanie	zwiększyć separację, zakończyć zadanie
transmisja	blokada/zasłonięcie	jakość linku	spadek bitrate, utrata obrazu	uruchomiona wcześniej procedura link-loss
bateria	duży sag/temperatura	BMS i alert	limit mocy / krótszy czas	lądowanie z zapasem
payload	timeout lub brownout	heartbeat	brak danych misji	nie powtarzać komend bez kontroli stanu

Nie wolno projektować procedury wyłącznie na podstawie tabeli — dokładne zachowania i komunikaty muszą pochodzić z instrukcji właściwej wersji. Tabela pokazuje sposób myślenia i dokumentowania.

IP55 i środowisko#

M350 i M400 są deklarowane jako IP55 w warunkach określonych przez producenta. Oznaczenie nie jest zgodą na zanurzenie, mycie ciśnieniowe ani pracę z dowolnym payloadem w ulewie. Odporność może zmienić otwarte złącze, niezgodny adapter, uszkodzona uszczelka i zużycie.

Po locie w wilgoci trzeba stosować instrukcję maintenance: odłączyć zasilanie, skontrolować złącza, śmigła, komory i payload, wysuszyć w dozwolony sposób oraz rejestrować ekspozycję. Nie wolno ładować mokrej lub bardzo zimnej baterii. Kondensacja może powstać również po wniesieniu zimnego statku do ciepłego pomieszczenia.

Gęstość powietrza maleje z wysokością i temperaturą. Napęd potrzebuje większej prędkości indukowanej dla tego samego ciągu, rośnie obciążenie układu, a dostępny margines może spaść. Limit wysokości i payloadu trzeba czytać łącznie z tabelami producenta, nie jako niezależne maksima.

Program odbioru technicznego#

Odbiór nowej platformy powinien być powtarzalnym procesem, nie tylko pierwszym startem:

spisać model, numery seryjne, wersje i zawartość zestawu;
skontrolować ramiona, blokady, podwozie, osłony, anteny i porty;
obejrzeć wszystkie śmigła oraz mocowania;
zinwentaryzować baterie i ładowarkę;
sprawdzić kompatybilność payloadu w bieżącej macierzy;
zarchiwizować instrukcję i release notes;
skonfigurować konta, sieć i politykę danych;
wykonać test naziemny bez śmigieł tam, gdzie instrukcja na to pozwala;
wykonać zawis w kontrolowanym obszarze;
sprawdzić RTH, RTK, gimbal, zapis i alerty zgodnie z instrukcją;
utworzyć konfigurację referencyjną i raport odbioru.

Test funkcji bezpieczeństwa nie powinien polegać na prowokowaniu ryzykownej awarii w powietrzu. Utratę sieci backendu, błąd payloadu czy pełny nośnik można zasymulować na ziemi. Zachowania wymagające lotu testuje się stopniowo w pustej przestrzeni i w ramach dozwolonych procedur producenta.

Test energii i czasu lotu#

Program energii powinien mieć co najmniej trzy profile: lekki zawis, nominalna trasa oraz najcięższy dopuszczony payload. Każdy powtarza się przy kilku stanach baterii i, jeśli operacja tego wymaga, temperaturach.

Wynik to nie tylko minuty. Należy wykreślić:

SOC i napięcie względem czasu;
prąd lub moc, jeśli telemetria je udostępnia;
minimalne napięcie przy manewrze;
temperaturę baterii;
czas do ostrzeżenia i lądowania;
energię na kilometr oraz minutę pracy;
rozrzut między bateriami.

Model planowania powinien używać konserwatywnego percentyla, nie najlepszego lotu. Jeśli 95% porównywalnych prób kończy zadanie z zakładaną rezerwą, jest to lepsza podstawa niż średnia maskująca najsłabsze pakiety.

Test RTK i nawigacji#

Pozycję można zweryfikować na punktach kontrolnych o lepszej, niezależnej geodezyjnie znanej pozycji. Próba powinna rozdzielić:

powtarzalność zawisu;
błąd absolutny;
błąd między przelotami;
czas uzyskania fixed;
odporność na krótką utratę korekt;
zachowanie obok budynku i na otwartym terenie;
zgodność znaczników zdjęć z czasem ekspozycji.

Nie należy używać tej samej usługi lub niepewnego punktu zarówno jako odniesienia, jak i badanego źródła. W fotogrametrii punkty kontroli jakości muszą być niezależne od punktów użytych do dopasowania modelu.

Test headingu może porównać oś statku ze zmierzonym azymutem na stanowisku wolnym od zakłóceń. Trzeba uwzględnić różnicę między osią obudowy, osią gimbala i osią optyczną kamery.

Test detekcji przeszkód#

Próby sensing wykonuje się od obiektów dużych i kontrastowych, przez trudniejsze powierzchnie, po reprezentatywne elementy infrastruktury. Celem nie jest „udowodnienie, że unika wszystkiego”, lecz zbudowanie obwiedni wiarygodności.

Macierz testu może obejmować:

dzień, zmierzch i sztuczne oświetlenie;
słońce z przodu i z tyłu;
beton, szkło, siatkę, przewód, gałęzie i wodę;
suchą nawierzchnię, deszcz lub mgłę tylko w granicach instrukcji;
różne prędkości oraz kąty podejścia;
payload zasłaniający część pola widzenia;
sensor czysty i kontrolowanie zabrudzony na ziemi;
ostrzeżenie, hamowanie i zachowanie planera.

Próba cienkiego przewodu musi używać dodatkowych zabezpieczeń i małych prędkości. Nie powinno się polegać na automatycznym systemie jako jedynym zabezpieczeniu stanowiska.

Test łącza#

Trasa testowa powinna przechodzić przez reprezentatywne geometrie: wolną linię widzenia, obrót statku, obniżenie za przeszkodą i środowisko RF podobne do misji. Test musi pozostawać w legalnym zakresie operacji.

Rejestruje się:

kanał i pasmo;
domenę regulacyjną;
położenie oraz orientację kontrolera;
jakość telemetrii i wideo;
bitrate, rozdzielczość i klatkaż;
opóźnienie oraz dropout;
czas odzyskania łącza;
ewentualny udział LTE;
zdarzenie i rezultat failsafe.

„Obraz jeszcze działał” jest niewystarczającym kryterium. Wideo może mieć wielosekundowy bufor, podczas gdy świeżość telemetrii albo komend jest już nieakceptowalna. UI powinien ujawniać wiek danych.

Test payloadu#

Własny payload przechodzi test mechaniczny, elektryczny, informatyczny i misji. Sekwencja rozszerzania ryzyka:

uruchomienie na laboratoryjnym zasilaniu z limitem prądu;
komunikacja z zestawem developerskim;
pomiar inrush, mocy i temperatury;
montaż na statku bez śmigieł;
sprawdzenie enumeracji, heartbeat i komend;
test zapisu po nagłym zaniku zasilania;
analiza zakłóceń GNSS/łącza;
krótki zawis z atrapą masową;
zawis z aktywnym urządzeniem;
stopniowe rozszerzenie trasy i profilu.

Atrapa masowa powinna odwzorować nie tylko masę, lecz również środek ciężkości i w miarę możliwości moment bezwładności. Metalowa bryła może jednak inaczej wpływać na anteny niż docelowa elektronika, więc nie zastępuje końcowego testu EMC.

Zarządzanie konfiguracją#

Platforma przemysłowa jest konfiguracją, nie samym numerem modelu. Dla każdego lotu warto generować manifest:

aircraft_model: Matrice 400
aircraft_serial: ...
aircraft_firmware: ...
controller_model: ...
controller_app_version: ...
battery_serials: [...]
payloads: [{model: ..., serial: ..., firmware: ...}]
sdk_versions: {psdk: ..., msdk: ..., cloud_api: ...}
rtk_source: ...
mission_revision: ...
operator: ...

Manifest nie powinien przechowywać sekretów ani tokenów. Jest kluczem do logów, plików zdjęć, raportu pogody i checklisty. Pozwala odtworzyć środowisko po aktualizacji lub wykryć, że błąd występował tylko z jedną baterią.

Macierz kompatybilności jest artefaktem żywym. Kolumny powinny obejmować statek, firmware, kontroler, aplikację, payload, adapter, SDK i status testu. Wpis „producent wspiera” oraz „organizacja zweryfikowała” to dwa osobne pola.

Typowe błędy interpretacyjne#

Jedna rodzina oznacza jedną architekturę. M350, M400 i M4 rozwiązują różne problemy. Wspólne API nie oznacza wspólnej elektroniki wewnętrznej.

Maksymalny zasięg transmisji jest zasięgiem operacyjnym. To wartość laboratoryjna zależna od domeny, zakłóceń i geometrii; lot ograniczają również energia i przepisy.

RTK daje centymetr w każdym zdjęciu. RTK poprawia rozwiązanie pozycji, ale produkt zależy od fixed status, synchronizacji, lever arm, modelu kamery i procesu obróbki.

Radar i LiDAR gwarantują uniknięcie przewodu. Cienkie, słabo odbijające i niekorzystnie ustawione obiekty są przypadkiem trudnym. System ma ograniczenia prędkości i środowiska.

IP55 oznacza pełną wodoodporność. Nie obejmuje zanurzenia, otwartych złączy ani dowolnego payloadu; potrzebna jest obsługa po ekspozycji.

SDK otwiera flight controller. PSDK, MSDK i Cloud API rozszerzają system na określonych granicach. Nie zastępują dostępu do kodu autopilota.

Udźwig jest jedynym kryterium integracji. Payload wpływa na CG, bezwładność, drgania, termikę, EMC, energię i pola widzenia.

Aktualizacja jest zawsze przezroczysta. Nowy firmware może zmienić funkcje, komunikaty, kompatybilność i zachowanie. Każda wersja wymaga regresji proporcjonalnej do ryzyka.

Powiązane tematy#

Przypisy#

DJI Enterprise, „Matrice 400 — Specifications”, bieżąca specyfikacja producenta: masa, napęd, GNSS/RTK, sensing, transmisja, porty E-Port V2 i bateria TB100.
DJI Enterprise, „Matrice 400 — Downloads”, instrukcje, release notes, maintenance manual, raport redundancji i pakiety aktualizacji; wersje należy sprawdzać w dniu kwalifikacji.
DJI Enterprise, „Matrice 350 RTK — Specifications”, dane statku, baterii TB65, O3 Enterprise, GNSS/RTK i sensorów przeszkód.
DJI Enterprise, „Matrice 4 Series — Specifications”, parametry kamer M4E/M4T, termowizji i sensorów otoczenia.
DJI Developer, „Payload SDK Documentation”, dokumentacja oraz wersjonowana macierz platform, interfejsów i funkcji.
DJI Developer, „Mobile SDK V5 Documentation”, API aplikacji i macierz kompatybilności produktów.
DJI Developer, „Cloud API — Product Architecture”, model device–edge–cloud oraz użycie bramy, MQTT, HTTPS i WebSocket.

Źródła z centralnego rejestru

DJI Enterprise: Matrice 400 specifications [dokumentacja producenta]
DJI Enterprise: Matrice 400 manuals, release notes and technical downloads [dokumentacja producenta]
DJI Enterprise: Matrice 350 RTK specifications [dokumentacja producenta]
DJI Enterprise: Matrice 4 Series specifications [dokumentacja producenta]
DJI Developer: Payload SDK documentation and supported-product matrix [dokumentacja producenta]
DJI Developer: Mobile SDK V5 documentation [dokumentacja producenta]
DJI Developer: Cloud API product architecture [dokumentacja producenta]