Cube Autopilot — rodzina kontrolerów

Cube jest modularną rodziną autopilotów, w której właściwy moduł flight management unit łączy się z carrier board przez 80-pinowe złącze mezzanine. Moduł zawiera MCU, procesor I/O, sensory, pamięci i część ochrony, a carrier wyprowadza porty, realizuje dużą część zarządzania zasilaniem i może dodać urządzenia takie jak odbiornik ADS-B In. Ocena samej kostki bez konkretnego carriera nie opisuje całego kontrolera lotu.

Nazwy kolorów kodują generacje i warianty, lecz nie tworzą prostej skali. Cube Black opiera się na STM32F427 i ma komponenty historyczne, Cube Yellow na STM32F777, Cube Orange na STM32H753, a Orange+ na STM32H757. Warianty Purple mogą być uproszczone do jednego IMU, a Blue mają profil pochodzenia komponentów. Przed zakupem trzeba sprawdzić pełną nazwę, rewizję, listę sensorów, lifecycle i kompatybilność firmware — nie tylko kolor obudowy.

Spis treści#

Moduł plus carrier
Miejsce rodziny Cube
Mapa wariantów
Cube Black i starsze F4
Cube Yellow
Cube Orange
Cube Orange Plus
Cube Blue
Cube Purple
Architektura FMU i IO
Fixed IMU i isolated IMU
Co oznacza triple redundancy
Ogrzewanie sensorów
Barometry i magnetometry
Pamięć i logowanie
Wyjścia MAIN i AUX
UART I2C SPI i CAN
Architektura zasilania
Power brick aux USB i servo rail
Zasilanie peryferiów
Carrier board
ADS B In carrier
Własny carrier
Firmware i target
Dobór wariantu
Montaż i orientacja
Bring up
Kwalifikacja sensorów
Testy zasilania i IO
Migracja między Cube
Lifecycle i substitutions
Typowe błędy
Powiązane tematy
Przypisy

Moduł plus carrier#

Cube składa się z co najmniej dwóch projektów:

Cube module
  ├─ FMU MCU
  ├─ I/O MCU
  ├─ fixed IMU / barometer
  ├─ vibration-isolated IMU board
  ├─ heater and thermal sensors
  ├─ FRAM and microSD interface
  └─ 80-pin DF17 connector
             ↓
carrier board
  ├─ power inputs and protection
  ├─ power distribution to peripherals
  ├─ UART / CAN / I2C connectors
  ├─ MAIN and AUX headers
  ├─ USB / buzzer / LEDs / safety
  └─ optional devices, e.g. ADS-B In

Dokumentacja CubePilot opisuje mechaniczny footprint modułu około 35 × 35 mm, wzór otworów 30 × 30 mm i 80-pozycyjne złącze Hirose DF17 przenoszące interfejsy autopilota.[1] Wartości mechaniczne i mating connector należy potwierdzić w bieżącej specyfikacji przed zaprojektowaniem PCB.

Zaletą jest długi kontrakt pomiędzy modułem a pojazdem. Można zaprojektować carrier do konkretnego airframe i wymieniać generację Cube bez zmiany całej wiązki. Warunkiem jest zgodność z reference design, właściwa mechanika i nieużywanie pinów zarezerwowanych w sposób blokujący przyszłe moduły.

Carrier nie jest biernym adapterem. W oficjalnej architekturze odpowiada m.in. za źródła 5 V, ochronę wejść, rozdział zasilania peryferiów, connector pinout i często elementy HMI. Mini carrier, standard carrier, ADS-B carrier i carrier producenta pojazdu mogą mieć inne domeny zasilania oraz wyposażenie. Każdy zestaw trzeba kwalifikować jako całość.

Miejsce rodziny Cube#

Cube wyrósł z architektury Pixhawk i zachowuje rozdział FMU + I/O. Historycznie Cube Black jest klasyfikowany przez PX4 jako FMUv3.[5] W ekosystemie ArduPilot rodzina ma osobne targety sprzętowe i rozbudowane wsparcie. Nazwa „Pixhawk 2.1” spotykana przy Cube Black jest nazwą historyczno-handlową, nie aktualnym identyfikatorem generacji Pixhawk Standard.

Rodzina Cube różni się od modularnego Pixhawk Autopilot Bus. Używa własnego 80-pinowego interfejsu carrier, istniejącego od wcześniejszych generacji. Fizyczna kompatybilność Cube carrier nie oznacza zgodności PAB z FMUv6X. Nie można wkładać modułów między tymi rodzinami bez specjalnie zaprojektowanego interfejsu.

Cube należy wybierać, gdy przydatne są:

wymienny, zwarty moduł FMU/IMU;
dojrzałe wsparcie ArduPilot;
trzy IMU i dwa barometry w pełnych wariantach;
mechanicznie izolowana grupa sensorów;
osobny I/O MCU;
custom carrier dla produktu;
dostępne warianty H7 i profile łańcucha dostaw.

Nie jest automatycznie najlepszy dla bardzo małego FPV, platformy potrzebującej natywnego Ethernetu na standardowym carrierze albo systemu wymagającego innej certyfikowanej architektury.

Mapa wariantów#

Dokumentacja producenta podaje następujący podział procesorów:[1][2]

Wariant	FMU MCU	RAM	Flash	Profil sensorów w skrócie
Black / Green / Blue F4 / Purple F4	STM32F427	256 KB	2 MB	zależny od wariantu, sensory starszej generacji
Yellow	STM32F777	512 KB	2 MB	pełny profil z izolowanymi sensorami
Orange	STM32H753	1 MB	2 MB	H7, trzy IMU w pełnym wariancie
Orange+	STM32H757	1 MB	2 MB	H7 dual-core family, nowsze kombinacje IMU
Blue H7	STM32H753	1 MB	2 MB	pełny wariant o deklarowanym profilu pochodzenia
Purple H7	STM32H753	1 MB	2 MB	uproszczony profil, według tabeli producenta jedno IMU

Tabela producenta jest aktualizowana wraz z substitutions. Dla Orange+ wymienia alternatywne układy w pozycjach IMU, np. ICM-45686, ICM-20649, ICM-20948 i ICM-42688 zależnie od rewizji.[1] Nie należy budować sterownika lub procedury zakupowej na założeniu jednego stałego BOM bez zapisania hardware revision i device IDs.

Lifecycle w bieżącej tabeli CubePilot oznacza część starszych F4 jako EOL, a Orange, Orange+, Yellow, Blue H7 i Purple H7 jako dostępne/active.[1] Status handlowy może się zmienić. Trzeba go weryfikować w chwili zakupu i nie utożsamiać z okresem utrzymywania danego firmware targetu.

Cube Black i starsze F4#

Cube Black wykorzystuje STM32F427, 2 MB flash i 256 KB RAM. W pełnym profilu ma trzy IMU oraz dwa barometry, ale stosuje układy takie jak MPU9250, LSM303D i L3GD20, które producent oznacza jako EOL.[1]

Typowa architektura sensorów starszego Black:

fixed board: MPU9250;
isolated IMU board: LSM303D/L3GD20 oraz MPU9250;
barometry: MS5611 w dwóch domenach;
magnetometry: zależnie od wariantu dwa onboard.

Dokładne rozmieszczenie zależy od rewizji i wariantu Black/Black+. Black+ w tabeli ma inną kombinację, m.in. ICM20602 i ICM20948.[1]

Cube Black może być właściwy do utrzymania istniejącej floty, gdy build i airframe są zweryfikowane. Dla nowego projektu ryzyka obejmują EOL sensorów, mniejsze zasoby MCU, niepewną dostępność identycznych partii i ograniczony margines na rozwój firmware. Zakup „nowego Cube Black” z nieautoryzowanego kanału zwiększa ryzyko klonu albo mieszanej rewizji.

Migracja z Black do Orange nie powinna polegać na wgraniu całego param file. Board target, sensor IDs, thermal compensation i kalibracje są inne. Carrier może być zgodny, ale zasilanie, wyjścia i peryferia nadal wymagają testu.

Cube Yellow#

Cube Yellow używa STM32F777 z 512 KB RAM i 2 MB flash.[1][2] Jest etapem między F4 a H7, z pełnym profilem redundancji w tabeli producenta. Vibration-isolated IMU board v2 jest wymieniany dla Yellow podobnie jak dla Orange i Blue H7.[1]

Wybór Yellow może wynikać z zatwierdzonego BOM, istniejącego certyfikowanego systemu lub konkretnego kanału dostaw. Nie daje jednak zasobów H7. Trzeba sprawdzić, czy docelowy build ArduPilot wraz z Lua, EKF instances, CAN, logowaniem i dodatkowymi sterownikami mieści się z odpowiednim marginesem.

Porównanie Orange vs Yellow powinno obejmować:

CPU load i scheduler slips w locie maksymalnym;
RAM/stack margin;
dostępność build targetu i funkcji;
sensor combination i clipping range;
heater behavior;
pobór mocy;
lifecycle i koszt rekwalifikacji.

Cube Orange#

Cube Orange używa STM32H753 Cortex-M7, 1 MB RAM i 2 MB flash. Producent wymienia ICM-20649 jako fixed-board sensor o zakresie przyspieszenia 30 g, a na izolowanej płytce v2 układy ICM20602 oraz ICM20948.[1][2]

ArduPilot opisuje Cube Orange jako moduł z trzema redundantnymi IMU, z czego dwie grupy sensorów są mechanicznie izolowane, oraz z ogrzewaniem stabilizującym temperaturę.[4] Wyrażenie „dwie grupy są izolowane” trzeba rozumieć mechanicznie: nadal współdzielą obudowę, zasilanie systemowe, MCU i część środowiska.

H7 daje większy zapas na:

równoległe instancje EKF;
wyższe częstotliwości IMU;
DroneCAN i rozbudowane peryferia;
scripting;
złożone logowanie;
nowe moduły ArduPilot.

Zapas obliczeniowy nie usuwa ograniczenia 2 MB internal flash ani ryzyk cache/DMA charakterystycznych dla Cortex-M7. Target CubeOrange jest utrzymywany oddzielnie. Trzeba używać obrazu dla właściwej płytki, nie dowolnego H7.

Cube Orange Plus#

Cube Orange+ używa STM32H757, 1 MB RAM i 2 MB flash według dokumentacji producenta.[1][2] STM32H757 jest rodziną dual-core Cortex-M7/M4, ale dostępność i użycie drugiego rdzenia zależą od firmware. Nie wolno zakładać podwojenia wydajności tylko z part number.

Vibration-isolated IMU board v3 dla Orange+ występuje w kilku kombinacjach sensorów. Bieżąca tabela producenta zapisuje alternatywy przy IMU1–IMU3, co wskazuje na substitutions/revisions.[1] Profil egzemplarza powinien być odczytywany z boot logu i ewidencji dostawy.

Nowsze IMU mogą oferować inne zakresy, noise density, ODR, FIFO i interfejs danych. Po substitution należy powtórzyć:

sprawdzenie drivera w używanym release;
orientation i device ID;
clipping test;
vibration PSD;
temperature calibration;
estimator lane switching;
EMI immunity;
timing i data-ready behavior.

ArduPilot ma osobny target CubeOrangePlus w dystrybucji firmware. Orange i Orange+ nie powinny być traktowane jako jeden obraz bez potwierdzenia mechanizmu targetu.[4]

Cube Blue#

Rodzina Blue obejmuje starsze F4 oraz Blue H7. CubePilot deklaruje dla Blue profil produkcji w USA z komponentami pochodzącymi z USA i państw sojuszniczych.[1] Jest to deklaracja producenta dotycząca łańcucha dostaw, nie techniczny dowód odporności ani certyfikacja wszystkich komponentów.

Blue H7 używa STM32H753 i pełnego profilu trzech IMU w tabeli. Może być wybierany z powodu wymogów sourcing/traceability. Integrator powinien uzyskać formalne dokumenty partii, country of origin i change notification odpowiadające własnym wymaganiom; tekst na stronie nie zastępuje audytu dostawcy.

Blue F4 jest inną generacją i w tabeli lifecycle należy do starszych wariantów. Sama nazwa Blue bez H7 jest nieprecyzyjna.

Cube Purple#

Purple jest profilem uproszczonym. Dokumentacja rozróżnia Purple F4 i Purple H7; oba są przedstawione jako pojedynczy IMU/barometer bez triple redundancy i bez pełnego isolation system w tabeli porównawczej.[1]

Zalety uproszczenia:

niższy koszt;
mniejsza złożoność BOM;
brak pozornej redundancji, jeśli misja jej nie wymaga;
możliwość zachowania modularnego carrier ecosystem.

Ograniczenia:

brak fault detection przez porównanie trzech IMU;
pojedyncza awaria sensora jest krytyczna;
słabsza odporność na clipping specyficzny dla jednego zakresu;
brak izolowanej grupy sensorów według profilu.

Purple może być dobrym kontrolerem dla niekrytycznego prototypu albo UGV, ale nie powinien być zamiennikiem Orange w requirement „triple IMU”. Nazwy rodzinne i zgodny carrier nie oznaczają zgodności safety case.

Architektura FMU i IO#

Cube zachowuje dwa bloki logiczne w jednym module:

             ┌────────────────────────────┐
sensors SPI →│ FMU MCU                    │→ AUX / FMU outputs
GNSS/CAN   → │ estimator, nav, control    │
             └────────────┬───────────────┘
                          │ FMU–IO protocol
             ┌────────────▼───────────────┐
RC input   → │ I/O MCU                    │→ MAIN / IO outputs
power flags→ │ output/failsafe functions  │
             └────────────────────────────┘

FMU wykonuje pełny stos, a I/O obsługuje osiem pierwszych wyjść i ograniczone zachowania manual/failsafe. Dokumentacja CubePilot wskazuje, że I/O outputs mogą być sterowane przez I/O przy nieaktywnym FMU, podczas gdy sześć wyjść FMU ma niższą latency, ale nie ma tej ścieżki awaryjnej.[1]

I/O nie zapewnia drugiego estimator/navigator. Jeśli FMU straci stan pozycji, I/O nie dokończy misji. Może natomiast utrzymać określone wartości PWM albo obsłużyć RC zgodnie z konfiguracją.

W power architecture część flag zasilania jest doprowadzona do I/O, co pozwala rejestrować zdarzenia przy inflight reboot FMU.[1] Skuteczność zależy od logiki firmware I/O i od tego, czy carrier implementuje wymagane sygnały.

Fixed IMU i isolated IMU#

Cube ma sensory na fixed board oraz osobnej płytce amortyzowanej mechanicznie. Producent opisuje dwa IMU na izolowanym module i jedno fixed IMU w pełnych wariantach.[1]

Rola kanałów jest różna:

fixed IMU lepiej reprezentuje wysokoczęstotliwościowy ruch obudowy i może nie mieć rezonansu izolatora;
isolated IMU otrzymują mniej drgań napędu w paśmie powyżej charakterystyki tłumika;
izolator może mieć własny rezonans, przesunięcie fazy i cross-axis coupling;
oba izolowane sensory dzielą ruch tej samej płytki, więc nie są mechanicznie niezależne.

Model izolatora można przybliżyć układem masa–sprężyna–tłumik. Transmissibility zależy od stosunku częstotliwości wymuszenia do częstotliwości własnej. Poniżej rezonansu izolator nie tłumi, w pobliżu może wzmacniać, a dopiero powyżej daje redukcję.

Testy powinny porównać PSD każdej instancji IMU dla:

rozbrojonego pojazdu;
każdego silnika osobno;
pełnego sweep throttle;
różnych śmigieł i masy;
lotu translacyjnego;
gwałtownych manewrów;
temperatur cold/hot.

Jeśli isolated IMU ma wąski szczyt rezonansu, filtracja i mount całego Cube wymagają korekty. Nie należy dokładać miękkiej pianki bez pomiaru, bo dwa stopnie izolacji mogą utworzyć niski rezonans.

Co oznacza triple redundancy#

Trzy IMU umożliwiają consistency monitoring, wybór lane i przełączenie po wykryciu awarii. Nie tworzą jednak trzech niezależnych flight controllerów.

Wspólne elementy:

jeden FMU MCU i jeden kod estymatora;
wspólny connector/carrier;
obudowa i temperatura;
wspólne źródła 5 V przed regulatorami;
wspólne pole EMI i udar mechaniczny;
część układów może mieć ten sam producent/design defect;
dwa sensory są na tej samej isolated board.

Redundancja może wykryć:

jeden sensor stuck;
nadmierny bias/innovation;
clipping jednego zakresu;
utratę jednej magistrali;
rozbieżność po uszkodzeniu lokalnym.

Może nie wykryć jednoznacznie:

wspólnego błędu orientacji w konfiguracji;
tej samej wady algorytmu;
wibracji wpływającej podobnie na wszystkie;
błędu timestamp wspólnego driverowi;
zakłócenia zasilania całego modułu;
fałszywie spójnego dryfu kilku podobnych sensorów.

Safety case powinien opisać fault coverage, nie tylko count. Log musi rejestrować active lane, innovations, clipping, reset, temperature i reason for switch. Przełączenie powinno być testowane w HIL/fault injection.

Ogrzewanie sensorów#

Cube Orange/Orange+ i część pełnych wariantów mają heater stabilizujący temperaturę IMU. Celem jest praca w kontrolowanym punkcie powyżej typowej temperatury otoczenia, co ogranicza zmienność biasów.

Pętla cieplna:

temperature sensor → heater controller → resistor power → IMU board
       ↑                                       ↓
       └──────────── thermal mass/ambient ─────┘

Korzyści:

powtarzalniejszy bias po warm-up;
mniejsza zależność od szybkich zmian ambient;
skuteczniejsza kalibracja termiczna;
ograniczenie kondensacji, gdy moduł jest cieplejszy niż otoczenie, ale nie jej pełna eliminacja.

Koszty:

zwiększony pobór mocy;
czas warm-up;
gradienty temperatury między fixed/isolated sensors;
ryzyko przegrzania w zamkniętej obudowie;
zależność od przepływu powietrza i carrier heat.

Prearm powinien wymagać osiągnięcia stabilnego zakresu, jeśli kalibracja zakłada heater. Test cold start mierzy czas do stabilności, overshoot i drift bias. Przy wysokim ambient controller powinien ograniczyć grzanie, a cały moduł pozostać w ratingu.

Barometry i magnetometry#

Pełne warianty mają zwykle dwa MS5611 według tabeli producenta; Purple jeden.[1] Jeden może znajdować się na fixed board, drugi na isolated board. Podwójny barometr pomaga wykrywać rozbieżność i zapewnia fallback, ale oba są w tej samej obudowie ciśnieniowej.

Barometry są wrażliwe na:

prop wash;
dynamic pressure przez vent;
światło;
temperaturę;
kondensację;
opóźnienie pianki;
nagrzewanie MCU/heatera;
różny pressure path do dwóch sensorów.

W komorze ciśnieniowej trzeba porównać offset, noise, lag, hysteresis i response dwóch instancji. Niezgodność może wynikać z mechaniki obudowy, nie uszkodzenia elementu.

Onboard magnetometer w module blisko zasilania i przewodów napędu często jest mniej użyteczny niż external compass w GNSS mast. Cube Orange ma według dokumentacji jeden onboard compass, starsze warianty mogły mieć dwa.[1] Estimator powinien używać external sensor o poprawnej orientacji i kalibracji, a onboard może być disabled albo zapasowy według testów.

Pamięć i logowanie#

CubePilot wymienia 16 KB SPI FRAM na module oraz interfejs microSD przez SDIO.[1] FRAM przechowuje krytyczne dane o dużej liczbie zapisów, np. parametry lub stan, zależnie od firmware. MicroSD służy do logów i większych plików.

Ryzyka microSD:

karta o wysokiej szczytowej latency;
filesystem corruption po utracie zasilania;
pełna karta;
słaby kontakt w wibracji;
karta konsumencka o niskiej endurance;
thermal range;
log bandwidth większy niż sustained write.

Test należy wykonać z docelowym log bitmask/rate, wszystkimi IMU i CAN. Mierzy się drop count, longest write latency i CPU scheduling. Brak logu nie powinien blokować krytycznej pętli, lecz dla określonych operacji może blokować uzbrojenie zgodnie z polityką traceability.

Po power-cut trzeba sprawdzić możliwość odzyskania poprzedniego logu oraz rozpoczęcia nowego. FRAM i microSD nie tworzą automatycznie transakcyjnej konfiguracji; firmware musi stosować CRC/versioning.

Wyjścia MAIN i AUX#

Dokumentacja Cube opisuje 14 PWM outputs:

8 wyjść z I/O MCU;
6 wyjść z FMU.

W nomenklaturze ArduPilot pierwsza grupa jest zwykle mapowana jako MAIN, druga jako AUX, ale konkretne funkcje ustala SERVOx_FUNCTION. Wyjścia I/O mogą działać w grupach timerów, więc częstotliwość/protokół jednego kanału wpływa na inne w tej samej grupie.

Producent podaje dla I/O outputs do 400 Hz i możliwości GPIO; sygnały są logiczne, nie są źródłem prądu dla przekaźników/LED. Wskazywane 50 mA per output i 100 mA łącznie odnoszą się do driver capability w dokumentacji, nie do zasilania serw.[1] Typowe wejście servo potrzebuje mikroamperów/miliamperów sygnału; napęd serwa pochodzi z servo rail.

FMU outputs mają niższą latency, ale nie są kontrolowane przez I/O w failsafe. Wybór kanałów powinien uwzględniać:

krytyczność aktuatora;
wymagany protokół DShot/PWM;
group timer constraints;
behavior po FMU reset;
poziom napięcia sygnału;
wymaganie bidirectional telemetry;
liczbę wyjść.

Test motor/servo wykonuje się bez śmigieł i z ograniczonym zasilaniem. Należy sprawdzić zachowanie armed, disarmed, watchdog, RC failsafe, FMU reboot i I/O reboot.

UART I2C SPI i CAN#

Standardowy profil Cube wymienia pięć portów szeregowych, z czego dwa z hardware flow control, dwa I2C, jeden niebuforowany SPI i dwa CAN.[1]

UART#

Porty są 3,3 V CMOS, według dokumentacji buforowane i 5 V tolerant, ale peryferium oraz carrier mogą mieć inne ograniczenia. Flow control jest ważny dla szybkiej telemetrii lub companion. SERIALx w ArduPilot nie zawsze odpowiada numerowi nadrukowanemu wprost; mapping trzeba sprawdzić dla targetu.

I2C#

I2C jest niebuforowany i podciągany do 3,3 V na module. Długie kable zwiększają pojemność i podatność na EMI. Dwa porty pozwalają rozdzielić zewnętrzne magnetometry, ale stuck-low na jednej szynie nadal wymaga recovery. Nie wolno dokładać silnych pull-up do 5 V.

SPI#

External SPI jest niebuforowany i producent zaleca bardzo krótkie połączenia.[1] To interfejs board-level, nie magistrala przez wiązkę pojazdu. Długi przewód powoduje ringing, skew i false clocks. Dla odległego sensora lepszy bywa CAN.

CAN#

Dwa CAN umożliwiają DroneCAN GNSS, ESC, airspeed i inne nodes. Dokumentacja Cube wspomina CAN FD dla wybranych H7 z oznaczeniem CubePilot, ale praktyczna obsługa zależy od transceivera, rewizji i firmware.[1] Nie należy zakładać CAN FD na każdym Orange.

Wbudowana terminacja opisana dla niektórych carrierów wpływa na topology. Trzeba zmierzyć rezystancję magistrali i potwierdzić dwa terminatory. Więcej w CAN w UAV.

Architektura zasilania#

Cube rozdziela zarządzanie wejściami od modułu FMU. Carrier dostarcza chronione szyny, a wewnątrz modułu FMU i I/O mają własne dual-channel regulatory 3,3 V według dokumentacji producenta.[1]

Kluczowe domeny:

power brick 1 ─┐
power brick 2 ─┼→ carrier power selection/protection → 5V module/peripherals
USB 5V ────────┘                              │
                                              ├→ FMU dual regulator → FMU/sensors
servo rail 4–10.5V ───────────────────────────└→ IO backup only

To schemat funkcjonalny, nie dokładny schematic. Mini carrier może realizować backup inaczej niż standard/PRO carrier. Dokumentacja producenta zaznacza takie różnice.[1]

FMU i I/O mają niezależne regulatory 3,3 V, lecz wspólne wejście 5 V oraz carrier pozostają common-mode. Dwa power bricks zwiększają odporność tylko wtedy, gdy źródła i przewody są niezależne. Dwa moduły BEC z jednego uszkodzonego pack connectora nie dają pełnej redundancji.

Projekt wymaga:

zakresu nominalnego i absolute max;
OR-ing/priorities;
reverse polarity protection;
over/under-voltage behavior;
inrush i current limits;
dropout przy obciążeniu peryferiów;
power-good signals i logowania;
zachowania po USB connect;
thermal limit regulatorów.

Power brick aux USB i servo rail#

Dokumentacja Cube podaje typowe zakresy:[1]

Odbiorca	Brick/Aux/USB	Servo rail
FMU	4–5,7 V	brak
I/O	4–5,7 V	4–10,5 V backup
peryferia	4–5,7 V	brak

Wartości są dokumentacyjne dla rodziny; używany carrier może mieć ostrzejsze granice. Zasilanie powyżej 5,7 V na Brick/Aux może zostać odłączone lub uszkodzić układ poza ochroną. Nie wolno podłączać bezpośrednio 2S LiPo do 5 V input.

Brick jest preferowanym źródłem, Aux drugim niezależnym wejściem. USB służy do konfiguracji i bench; producent nie rekomenduje go jako źródła in-flight w opisanym profilu.[1]

Servo rail zasila serwa/ESC zgodnie z carrierem. Cube nie dostarcza mocy serwom. Servo rail może podtrzymać tylko I/O, nie FMU i peryferia. To „last chance failsafe”, nie pełny backup autopilota.

Scenariusz awarii main 5 V:

FMU loses power → navigation/control unavailable
IO survives from servo rail → configured output/failsafe behavior may remain
peripherals lose 5V → GNSS/radio may stop

Jeśli wymagane jest zachowanie pełnej misji po utracie jednego source, potrzebne są dwa prawidłowe Brick/Aux źródła, nie tylko servo backup.

Zasilanie peryferiów#

Carrier rozdziela zasilanie portów na grupy z current limiting i switching. Dokumentacja producenta podaje osobną grupę dla TELEM1 oraz wspólną dla innych peryferiów, z łącznym budżetem rzędu 2,5 A w opisanej architekturze.[1] Tekst dokumentacji zawiera w jednym miejscu sformułowanie niejasne dotyczące zasilania telemetrii; przy projektowaniu należy oprzeć się na schematicu/revizji carriera i uzyskać potwierdzenie producenta, zamiast interpretować pojedyncze zdanie.

Budget:

I_group_peak = Σ I_peripheral_peak + inrush + margin
V_at_device = V_source - I · (R_switch + R_connector + R_cable)

Companion computer, modem LTE i nadajnik wideo zwykle mają duże skoki prądu. Nie powinny być zasilane z portu flight controller bez potwierdzenia current limit i inrush. Lepiej zastosować osobny regulator z wspólną masą/sygnałem i ochroną przed backfeed.

Zwarcie jednego peripheral port nie powinno resetować FMU. Fault injection z electronic load lub kontrolowanym zwarciem przez rezystor/fixture mierzy current limit, temperaturę, spadek szyny i event log. Nie wykonuje się przypadkowego zwarcia przewodem.

RC receivers mają dedykowane źródła o małym budżecie. Nie wolno zasilać serw z RC supply.

Carrier board#

Standardowy carrier wyprowadza connector Cube na JST-GH, servo headers, power inputs i HMI. Inne warianty mogą dodawać Ethernet switch, CAN transceivers, izolowane I/O, high-current drivers, dodatkowe power domains lub specjalne connectors.

Carrier determinuje:

fizyczną liczbę portów;
pinout kabli;
source selection i protection;
CAN termination;
ESD/EMI filtering;
servo rail;
ADS-B/other onboard peripherals;
HMI i safety switch;
accessible debug;
mount i cooling.

Stwierdzenie „wszystkie Cube pasują do wszystkich carrierów” należy ograniczyć do carrierów zgodnych z reference design oraz funkcji wspólnych. Stary carrier może nie wyprowadzać nowszej funkcji, mieć inny backup power albo mechanicznie kolidować z obudową. Custom carrier może używać reserved pins.

Kompatybilność ma poziomy:

mechaniczna — connector i wysokość;
elektryczna — napięcia, pinout, protection;
funkcjonalna — wyprowadzone wymagane porty;
firmware — board target i peripheral mapping;
safety — zachowanie po awarii spełnia wymagania.

ADS B In carrier#

ADS-B In carrier dodaje odbiornik uAvionix 1090 MHz oraz wbudowaną antenę. Producent opisuje połączenie odbiornika z internal Serial 5 i możliwość wyświetlania identyfikatora, pozycji, wysokości oraz prędkości statków nadających ADS-B Out.[3]

Ograniczenia interpretacji:

ADS-B In widzi tylko cele nadające kompatybilny sygnał i znajdujące się w zasięgu;
pozycja/altitude/velocity mają latency i jakość źródła;
odbiornik nie jest aktywnym radarem;
antena w carrierze ma ograniczoną charakterystykę przez montaż i ekranowanie;
dane nie gwarantują separation ani zgodności z wymaganiami DAA;
system musi obsłużyć track stale, duplicate IDs i utratę odbiornika.

Carrier nie zapewnia ADS-B Out. Emisja ADS-B jest regulowana i wymaga osobnego, zatwierdzonego systemu oraz konfiguracji. Nie należy testować nieautoryzowanej transmisji.

W testach In stosuje się legalny odbiór realnych sygnałów lub symulator/fixture w ekranowanym środowisku zgodnie z prawem. Mierzy się time-to-display, track timeout, UART saturation i wpływ na scheduler.

Port Serial 5 jest zajęty przez onboard receiver na tym carrierze. Projektant musi uwzględnić utratę dostępnego UART względem carriera bez ADS-B.

Własny carrier#

Custom carrier jest uzasadniony, gdy standard board ma zbędne złącza albo pojazd wymaga innych connectorów, redundantnego zasilania, izolacji galwanicznej czy integracji payloadu.

Proces projektowy:

Przypiąć wersję Cube interface/reference design.
Zdefiniować obsługiwane moduły i future compatibility.
Utworzyć 80-pin pin matrix: source, direction, voltage, use, default state.
Zaprojektować wszystkie power paths i fault containment.
Zapewnić controlled impedance/return paths dla szybkich sygnałów.
Zastosować ESD/TVS/current limits dla zewnętrznych connectorów.
Przeanalizować CAN termination i ground reference.
Zapewnić mounting, connector compression i extraction.
Udostępnić test points oraz production programming.
Wykonać bring-up najpierw bez Cube, potem z current limit.

DF17 jest złączem board-to-board. Stack height, coplanarity, insertion force i liczba cykli są krytyczne. Śruby nie mogą wyginać PCB ani przenosić drgań w sposób obchodzący izolację. Potrzebne są keep-out i kontrola obudowy.

Carrier z wysokoprądową dystrybucją ESC na tej samej PCB może wprowadzić magnetic fields, ground bounce i switching noise. Lepiej oddzielić PDB albo zaprojektować warstwy i prądy powrotne na podstawie pomiarów EMC.

Firmware i target#

ArduPilot publikuje osobne obrazy dla CubeOrange i CubeOrangePlus. Board target definiuje MCU, pin mapping, sensory, bootloader, memory layout i default features. CubeBlack, Yellow i Purple także mają właściwe hwdefs.

Przy flashowaniu:

odczytać board ID;
użyć oficjalnego stable image dla targetu;
zapisać poprzedni build i param backup;
sprawdzić release notes i parameter migration;
po restarcie odczytać boot log oraz sensory;
nie przywracać kalibracji z innego modułu;
wykonać output mapping bez śmigieł;
przeprowadzić regresję failsafe.

PX4 wsparcie dla starszego Cube Black istnieje jako FMUv3 w dokumentacji, ale status konkretnych Cube H7 należy sprawdzić w bieżącej liście boardów i u producenta.[5] Rodzina Cube jest szczególnie związana z ArduPilot; wybór PX4 powinien opierać się na jawnie utrzymywanym targetcie, nie podobieństwie hardware.

Custom firmware musi zapisać git commit, toolchain, hwdef i feature set. H7 może pomieścić więcej funkcji, ale włączenie wszystkiego zwiększa load i powierzchnię testową.

Dobór wariantu#

Pełna redundancja i nowy projekt#

Orange/Orange+ albo Blue H7 są naturalnymi kandydatami. Wybór zależy od MCU targetu, sensor BOM, sourcing, lifecycle i kosztu rekwalifikacji. Orange+ nie jest automatycznie lepszy, jeśli docelowy release i procedura są dojrzalsze na Orange.

Istniejąca flota Cube Black#

Utrzymanie może być racjonalne do końca cyklu produktu. Trzeba zabezpieczyć autoryzowane części, wykrywać klony, zamrozić release i zaplanować migrację przed wyczerpaniem zapasu.

Mniej krytyczny system#

Purple H7 może zapewnić nowoczesny MCU bez kosztu trzech IMU. Safety assessment musi zaakceptować pojedynczy sensor. Nie należy emulować redundancy przez powielanie software lane na tych samych danych.

Wymogi łańcucha dostaw#

Blue H7 może odpowiadać deklarowanym kryteriom producenta, ale wymagane dokumenty procurement/traceability należy uzyskać dla partii. Nazwa koloru nie jest certyfikatem.

Własny carrier#

Najpierw zamrozić zestaw modułów wspieranych przez carrier. Jeśli ma obsłużyć F4 i H7, trzeba sprawdzić power budget, reserved pins, I/O voltage selection i mechanikę wszystkich wariantów.

Scorecard:

Kryterium	Black	Yellow	Orange	Orange+	Purple H7
zasoby CPU	starsze F4	F7	H7	H7	H7
pełny triple IMU	tak w pełnym Black	tak	tak	tak	nie
current lifecycle	EOL w tabeli	active	active	active	active
główny atut	legacy compatibility	F7 profile	dojrzały H7	nowszy H757/IMU	prostota
główne ryzyko	EOL sensors/CPU	mniejszy zapas	BOM revisions	target/substitutions	single IMU

Statusy są snapshotem dokumentacji i trzeba je ponownie sprawdzić przed zakupem.[1]

Montaż i orientacja#

Cube ma wewnętrzną izolację, ale cały moduł nadal wymaga prawidłowego montażu. Nie zakłada się automatycznie dodatkowych miękkich tłumików.

Wymagania:

arrow/orientation zgodna z parametrem board orientation;
moduł możliwie blisko środka obrotu;
carrier sztywny lokalnie i odseparowany od rezonansowej cienkiej płyty;
właściwy torque śrub;
connector pełni wsunięty, bez bocznego naprężenia;
przewody ze strain relief;
odległość od PDB, przewodów fazowych, magnesów i RF PA;
dostęp do microSD;
vent dla barometru;
bilans cieplny obudowy.

Po montażu wykonuje się axis sanity test: przechylenie w prawo ma dać poprawny roll, nos w dół poprawny pitch, obrót yaw właściwy kierunek. Każda instancja IMU musi mieć poprawną rotation.

Compass motor interference test decyduje, czy onboard compass może być użyty. External compass na maszcie ma zwykle mniejsze zakłócenia, ale przewód I2C jest wrażliwy; DroneCAN GNSS/compass może być odporniejszy.

Bring up#

Sekwencja dla nowego modułu/carriera:

inspect module + carrier + DF17
→ verify carrier rails without Cube
→ resistance checks
→ insert Cube with controlled mechanics
→ current-limited 5V on primary input
→ record current and temperatures
→ identify bootloader/board ID
→ flash approved target
→ enumerate every sensor
→ test SD/FRAM/log
→ connect peripherals one at a time
→ test outputs without propulsion
→ test backup power and failsafe

Baseline report:

module model, serial, hardware revision;
carrier model/revision;
bootloader and firmware build;
MCU ID;
IMU/baro/mag device IDs i buses;
heater target i warm-up time;
idle current cold/warm;
primary/aux voltage telemetry;
SD CID i benchmark;
CAN/UART mapping;
output functions;
parameter hash.

Jeśli tabela producenta dopuszcza sensor alternatives, baseline jest jedynym sposobem ustalenia faktycznego BOM bez rozbierania modułu.

Kwalifikacja sensorów#

Statyczna#

Allan deviation/noise dla gyro/accel;
bias repeatability po restartach;
warm-up trajectory;
cross-axis i orientation;
barometer noise/lag;
magnetometer offset.

Dynamiczna#

shaker sweep z każdą IMU;
motor-by-motor vibration;
clipping przy udarze i pełnym throttle;
time alignment między instancjami;
estimator innovations;
lane switch transient;
isolated board resonance.

Termiczna#

cold start do heater lock;
hot ambient z heater off/minimum;
bias vs temperature;
gradient fixed vs isolated IMU;
cycle hysteresis;
barometer thermal coupling.

Fault injection#

Na stanowisku programowym lub zmodyfikowanym fixture wymusza się stale data, bias ramp, clipping i utratę instancji. Sprawdza się detection time, selected lane, attitude step i failsafe. Fizyczne odłączanie wewnętrznego sensora w locie nie jest właściwą metodą.

Kryterium „przełączył się” jest niepełne. Potrzebny jest maksymalny skok orientacji, czas, zachowanie kontrolera i log reason.

Testy zasilania i IO#

Zasilanie#

cold start z minimalnego i maksymalnego napięcia;
primary only, aux only, USB bench;
hot-plug i source priority;
wolny spadek oraz krótki zapad;
utrata primary przy active aux;
utrata obu main sources z servo rail podtrzymującym I/O;
peripheral overcurrent;
reverse connection na chronionym fixture;
thermal load pełnych peryferiów.

Mierzy się szyny oscyloskopem na carrierze i module. Telemetria voltage może nie widzieć szybkiego zapadu. Trigger na reset/power-good pozwala skorelować log.

I/O#

każdy MAIN/AUX kanał;
timer group frequencies;
armed/disarmed PWM;
RC passthrough/failsafe tylko jeśli wymagany;
FMU reboot;
FMU–I/O link timeout;
I/O reboot;
servo rail present/absent;
DShot/PWM compatibility.

Test wykonuje się na logic analyzer i dummy loads, bez śmigieł. High-voltage servo rail sprawdza się z właściwymi serwami i osobnym current limit; sygnał 3,3 V musi być akceptowany.

Porty#

UART loopback i flow control;
I2C bus recovery po stuck-low;
CAN bus-off i termination;
SD write przy CAN/Ethernet load;
ADS-B UART saturation na właściwym carrierze;
ESD według procedury laboratoryjnej.

Migracja między Cube#

Fizyczne włożenie Orange do carriera po Black jest dopiero początkiem.

Plan migracji:

Sprawdzić carrier revision i oficjalną kompatybilność H7.
Zmierzyć power budget, zwłaszcza heater.
Użyć właściwego bootloadera/targetu.
Wyeksportować parametry starego systemu do review, nie do ślepego restore.
Przenieść funkcjonalne ustawienia airframe, serial, CAN, mission i tuning po mapowaniu nazw.
Wykonać od nowa accel/gyro/compass/level i power calibration.
Sprawdzić orientation każdej instancji.
Zweryfikować output mapping oraz I/O failsafe.
Powtórzyć notch/vibration analysis.
Powtórzyć SITL/HIL i lot envelope test.

Heater może zmienić pobór oraz thermal equilibrium w obudowie. Nowsze IMU mają inne zakresy i noise, więc filtry/notch settings ze starego modułu nie są automatycznie optymalne.

Mission/failsafe parameters mogą zmienić default między release. Migracja hardware połączona z dużym upgrade firmware mnoży zmienne. Lepiej rozdzielić etapy: najpierw update starego systemu i regresja, potem hardware, jeśli cykl pozwala.

Lifecycle i substitutions#

Producent jawnie wskazuje EOL starszych sensorów i rekomenduje H7 dla nowych designów.[1] To cenna informacja, ale substitution wewnątrz aktywnego modelu nadal wymaga kontroli.

Procurement powinien wymagać:

authorized source;
pełny MPN/model i hardware revision;
serial/lot traceability;
certificate of conformance według potrzeb;
PCN/EOL notification;
deklarowany sensor BOM albo lista dozwolonych alternatives;
bootloader/target compatibility;
gwarancja i RMA;
retention sample każdej partii.

Incoming inspection może automatycznie odczytać device IDs, barometer count, MCU ID i bootloader. Wynik porównuje się z allowlistą. Nieznana kombinacja nie trafia od razu do produkcji.

Klony Cube mogą odwzorować obudowę i connector, ale używać innych regulatorów, sensorów lub gorszej mechaniki izolatora. Autentyczność i kanał dostaw są częścią niezawodności.

Typowe błędy#

Ocenianie samego modułu#

Carrier definiuje zasilanie, ochronę, porty i opcjonalne urządzenia. System to Cube + carrier + wiązka + firmware.

Kolor jako pełna specyfikacja#

Blue F4 i Blue H7 są różnymi generacjami. Purple może mieć jeden IMU. Potrzebna jest pełna nazwa i rewizja.

Triple IMU jako potrójny autopilot#

Sensory współdzielą MCU, obudowę i źródła. Redundancja obejmuje tylko część fault model.

Dodatkowa miękka pianka bez pomiaru#

Wewnętrzna isolated board ma własny rezonans. Drugi izolator może pogorszyć pasmo drgań.

Servo rail jako backup FMU#

Servo rail może podtrzymać I/O, nie FMU i peryferia. Nie umożliwia kontynuacji pełnej nawigacji po utracie 5 V.

Powerowanie modemów z portu bez budgetu#

Skok LTE/companion może uruchomić current limit albo zresetować system. Wymagany jest osobny regulator lub potwierdzony profil.

SPI przez długi kabel#

External SPI jest niebuforowany i przeznaczony do krótkich połączeń. Dla oddalonych sensorów stosuje się odporniejszy interfejs.

Przywracanie kalibracji ze starego Cube#

Biasy, rotations i power scaling są egzemplarzowe. Pełny restore może wprowadzić błędny estimator.

Zakładanie identycznego BOM Orange Plus#

Producent wymienia alternatywne IMU. Każda partia wymaga device inventory i kwalifikacji allowlisty.

ADS B jako pełny DAA#

ADS-B In widzi tylko nadające cele i ma ograniczenia coverage/latency. Nie jest samodzielnym gwarantem separacji.

Ignorowanie portu zajętego przez carrier#

ADS-B carrier używa Serial 5. Plan portów musi uwzględnić urządzenia onboard.

Brak testu FMU IO#

Osiem MAIN i sześć AUX mają inne ścieżki oraz zachowanie failsafe. Mapowanie i reboot trzeba sprawdzić bez napędu.

Cube jest dojrzałą architekturą modularną, ale jego wartość wynika z poprawnego kontraktu między modułem, carrierem, firmware i procedurą. Kolorowa obudowa upraszcza identyfikację rodziny; nie zastępuje specyfikacji, pomiarów ani traceability.

Powiązane tematy#

Przypisy#

CubePilot, „The Cube Module Overview” — warianty, sensory, lifecycle, porty, power architecture, carrier interface i wyjścia.
CubePilot, „Flight Management Unit specifications” — MCU, pamięci i fixed-board sensors dla poszczególnych Cube.
CubePilot, „ADS-B IN Carrier Board” — integracja odbiornika uAvionix, Serial 5 i zakres funkcji odbiorczych.
ArduPilot, „The Cube Orange/Orange+ with ADS-B In Overview” — profil hardware oraz integracja z ArduPilot.
PX4, „Pixhawk Series” — klasyfikacja generacji i status rodzin hardware w ekosystemie PX4.
ArduPilot, dokumentacja logów — pobieranie i analiza DataFlash potrzebne do kwalifikacji sensorów, zasilania i failover.

Źródła z centralnego rejestru

CubePilot: The Cube Module Overview [dokumentacja producenta]
CubePilot: Flight Management Unit specifications [dokumentacja producenta]
CubePilot: ADS-B IN Carrier Board [dokumentacja producenta]
ArduPilot: The Cube Orange and Orange+ with ADS-B In overview [dokumentacja projektu]
PX4 Guide: Pixhawk Series [dokumentacja projektu]
ArduPilot: Downloading and Analyzing Data Logs [dokumentacja]