Pixhawk — standardy i rodzina platform

Pixhawk nie jest dziś nazwą jednego kontrolera lotu ani synonimem PX4. Oznacza rodzinę otwartych standardów sprzętowych, generacje architektury FMU, historyczne płytki referencyjne oraz zgodne produkty wielu producentów. Ten sam fizyczny kontroler może uruchamiać PX4 albo ArduPilot, a urządzenie reklamowane jako „Pixhawk compatible” nie musi spełniać aktualnego standardu ani używać tego samego firmware targetu.

Najważniejsza umiejętność przy doborze nie polega więc na porównaniu numerów 4, 5 i 6. Trzeba ustalić: jaki standard FMU realizuje urządzenie, czy ma osobny I/O MCU, ile niezależnych domen sensorów i zasilania rzeczywiście istnieje, jakie interfejsy są wyprowadzone na carrier/baseboard, kto utrzymuje target firmware i czy konkretny produkt został zweryfikowany jako Pixhawk Standard Autopilot. Dopiero potem porównuje się cenę, masę i liczbę złączy.

Spis treści#

• Czym jest Pixhawk
• Czego Pixhawk nie oznacza
• Warstwy standardu
• Ewolucja generacji FMU
• FMUv2 i FMUv3
• FMUv4 i FMUv5
• FMUv5X
• FMUv6X
• FMUv6C
• FMUv6U
• FMUv6X RT
• FMU i procesor IO
• Sensory i redundancja
• Zasilanie i domeny awarii
• Interfejsy
• Pixhawk Connector Standard
• Pixhawk Autopilot Bus
• Payload Bus i Radio Interface
• Firmware target i zgodność binarna
• PX4 i ArduPilot
• Standard a konkretny produkt
• Licencja i znak towarowy
• Kryteria doboru
• Integracja elektryczna
• Montaż mechaniczny i termiczny
• Bring up nowej konstrukcji
• Kwalifikacja i testy
• Migracja między generacjami
• Typowe błędy
• Powiązane tematy
• Przypisy

Czym jest Pixhawk#

Projekt Pixhawk publikuje specyfikacje elektryczne, mechaniczne i architektoniczne dla kontrolerów oraz współpracujących modułów UAV. Standardy są rozwijane przez Pixhawk Special Interest Group koordynowaną przez Dronecode Foundation i udostępniane w publicznym repozytorium.[1] Oficjalny zestaw obejmuje m.in. standard złączy, Autopilot Bus, generacje autopilota, Payload Bus i Radio Interface.[1][2]

Można wyróżnić cztery znaczenia:

1. Projekt i standardy — dokumenty DS określające architekturę i interfejsy.
2. Generacja FMU — np. FMUv5X, FMUv6X albo FMUv6C.
3. Płytka referencyjna lub historyczny produkt — np. pierwotny Pixhawk oparty na FMUv2.
4. Produkt producenta — np. kontroler Holybro, CUAV lub ARK realizujący określony standard.

Poprawny opis urządzenia powinien podać wszystkie istotne warstwy:

produkt: Holybro Pixhawk 6X
standard: FMUv6X + odpowiednie standardy interfejsów
MCU: STM32H753
firmware target: konkretny target PX4/ArduPilot
carrier/baseboard: wariant i rewizja producenta

Samo „Pixhawk 6” jest niejednoznaczne. Może chodzić o 6X, 6C, wersję mini, Pro albo produkt o podobnej nazwie, lecz innym zestawie portów i sensorów.

Czego Pixhawk nie oznacza#

Nie jest firmware#

PX4 jest stosem autopilota uruchamianym m.in. na hardware Pixhawk. ArduPilot jest innym stosem obsługującym wiele tych samych i innych płytek. Pixhawk definiuje przede wszystkim hardware; MAVLink jest protokołem, QGroundControl i Mission Planner są GCS. Projekty mają wspólną historię i ekosystem, ale nie są tym samym.

Nie gwarantuje identycznej jakości produktu#

Dwie płytki zgodne funkcjonalnie mogą używać innych konkretnych IMU, regulatorów, obudów, connectorów, layoutu i procesu testowego. Standard zmniejsza ryzyko integracyjne, ale nie zastępuje kwalifikacji produkcyjnej, kontroli partii ani dokumentacji producenta.

Nie znaczy dowolnej płytki H7#

Kontroler ze STM32H743 i trzema IMU nie staje się FMUv6X. Standard określa architekturę, przypisania sygnałów, wymagane peryferia i zachowanie interfejsów. Płytka producenta może być doskonała i wspierana przez PX4, mimo że nie jest Pixhawk Standard Autopilot; należy ją wtedy opisywać jako manufacturer-supported lub własny design, nie rozszerzać znaczenia standardu.

Wyższy numer nie zawsze oznacza lepszy wybór#

PX4 przypomina, że kolejne oznaczenia FMU wskazują nowszą generację, ale nie tworzą prostej skali możliwości; niektóre warianty różnią się głównie architekturą złączy lub docelowym profilem.[4] Mały pojazd może skorzystać z prostszego 6C, a system modularny z PAB — z 6X.

Warstwy standardu#

Repozytorium Pixhawk Standards wymienia obecnie następujące dokumenty istotne dla autopilotów:[1]

Status dokumentu trzeba sprawdzać w chwili projektowania. Repozytorium oznacza niektóre wcześniejsze propozycje, m.in. Smart Battery DS-013 i dawny DS-015, jako nieużywane.[1] Strona marketingowa lub stary datasheet nie powinny być podstawą nowego projektu, jeśli repozytorium podaje inny status.

Standard autopilota opisuje wnętrze modułu FMU: procesory, sensory, pamięci, mapowanie interfejsów i wymagania konstrukcyjne. Connector Standard opisuje złącza kablowe. PAB definiuje modularne połączenie FMU z carrierem. Payload Bus rozszerza interoperacyjność na urządzenia zadaniowe. Zgodność z jednym dokumentem nie oznacza automatycznie zgodności ze wszystkimi.

Ewolucja generacji FMU#

PX4 dokumentuje generacje od FMUv1 do FMUv6X-RT.[3][4] Tabela przedstawia architektoniczny skrót, nie katalog wszystkich produktów:

Dokumentacja PX4 na stronie reference design i Pixhawk series nie jest w każdym miejscu idealnie zsynchronizowana co do skrótowych wartości historycznych. Przy projektowaniu nowej płytki źródłem normatywnym jest właściwy dokument DS i jego rewizja, a nie tabela poglądowa.[1][3][4]

FMUv2 i FMUv3#

FMUv2 utrwalił klasyczną architekturę Pixhawk z STM32F427 jako FMU i osobnym procesorem I/O w wielu realizacjach. Ograniczenie 1 MB dostępnego flash stało się z czasem poważne: współczesne buildy muszą usuwać moduły, a część funkcji i parametrów może być niedostępna. PX4 wskazuje ten wyjątek wprost.[4]

FMUv3 zachował podobną architekturę, lecz dzięki 2 MB flash pozwolił utrzymać większy firmware. Nazwy produktów są mylące: Cube Black jest klasyfikowany przez PX4 jako FMUv3, mimo że historycznie bywa kojarzony z „Pixhawk 2.1”. Numer handlowy nie odpowiada więc numerowi FMU.

Starsza generacja może nadal być właściwa do utrzymania istniejącego, zweryfikowanego systemu. Nie jest jednak dobrym punktem startowym dla nowego projektu wymagającego Ethernetu, wielu CAN, dużych logów, nowoczesnych estimatorów lub długiego cyklu wsparcia. Ryzyko obejmuje EOL sensorów, ograniczony flash, brak aktualnego wsparcia producenta i trudniejsze pozyskanie identycznej rewizji.

FMUv4 i FMUv5#

FMUv4 zwiększył zasoby i liczbę interfejsów, a część produktów zrezygnowała z osobnego I/O MCU dla rozmiaru i prostoty. To wpływa nie tylko na liczbę wyjść, ale na zachowanie przy restarcie FMU i mapowanie MAIN/AUX.

FMUv5 przeszedł na STM32F765. Cortex-M7 zapewnia większą wydajność obliczeniową, cache i bogatsze peryferia, ale wprowadza także kwestie spójności DMA/cache i bardziej złożonego timing. Nie należy oceniać kontrolera tylko przez MHz; layout sensorów, magistrale, zasilanie i firmware są równie ważne.

PX4 opisuje Pixhawk 4 jako przykład FMUv5, dziś oznaczony w dokumentacji jako discontinued.[4] Produkt wycofany może mieć działający target, lecz nowy zakup powinien uwzględniać dostępność, podróbki, rewizje komponentów oraz politykę aktualizacji.

FMUv5X#

FMUv5X przesuwa architekturę w kierunku modułowego FMU i zwiększonej redundancji. Standard DS-011 został opublikowany w repozytorium Pixhawk. Litera X nie oznacza po prostu szybszego MCU; sygnalizuje profil architektoniczny rozbudowany względem kompaktowych wariantów.

Kluczowe idee rodziny X:

• odseparowanie modułu obliczeniowo-sensorowego od carrier/baseboard przez PAB;
• wiele IMU na niezależnych magistralach lub domenach;
• osobny I/O MCU;
• redundantne ścieżki zasilania i monitorowania;
• większa liczba CAN, UART, SPI/I2C i wyjść;
• możliwość tworzenia carrierów dla różnych statków bez przeprojektowania FMU.

Modularność zwiększa liczbę połączeń. PAB connector, carrier routing i mechanika stają się częścią integralności systemu. Luźny moduł albo błędny carrier może unieważnić zalety redundantnego FMU.

FMUv6X#

FMUv6X używa w dokumentacji PX4 STM32H753, do 480 MHz, z 1 MB RAM i 2 MB flash.[3][4] Standard DS-012 definiuje pełny profil, a produkty takie jak CUAV Pixhawk V6X i Holybro Pixhawk 6X są wymieniane w ekosystemie jako implementacje tej generacji.[4][5]

PX4 porównuje v6X z v6C i v6X-RT następująco:[4]

To wartości standardu/generacji zestawione przez PX4, nie gwarancja, że każdy port jest dostępny na każdym carrierze. Producent może wyprowadzić podzbiór, zmienić obudowę albo dodać peryferia. Należy przeczytać pinout produktu.

STM32H753 ma szybszy rdzeń, rozbudowane DMA i pamięci, lecz firmware musi świadomie zarządzać cache, regionami DMA i obciążeniem. Zapas CPU może zostać zużyty przez wysokie częstotliwości IMU, logowanie, szyfrowanie, Ethernet i dodatkowe sterowniki. W kwalifikacji mierzy się scheduler latency i load w najgorszej konfiguracji.

FMUv6C#

FMUv6C jest profilem opartym na STM32H743V. Zestawienie PX4 pokazuje 1 MB RAM, 2 MB flash, osobny STM32F103 I/O, dwa IMU, jeden barometr, jeden magnetometr, osiem FMU PWM, osiem I/O PWM i dwa CAN. Nie przewiduje PAB ani secure elementu i w tabeli nie ma wsparcia Ethernetu.[4]

C można traktować jako profil bardziej kompaktowy i prostszy niż 6X, lecz nie „gorszy” w każdej misji. Dla małego UAV dwa niezależne IMU, H7 i komplet wymaganych portów mogą wystarczyć. Mniejsza liczba elementów, złączy i domen może obniżyć masę, rozmiar i koszt.

Wymaganie „trzy IMU” ma sens tylko wtedy, gdy estimator, zasilanie, magistrale i procedura wyboru potrafią wykorzystać redundancję. Jeśli ryzyko misji nie wymaga triplex, dobrze zaprojektowany 6C może być racjonalniejszy. Jeśli wymagane są PAB, Ethernet, secure element albo trzy sensory, 6X jest bliższy profilowi.

FMUv6U#

DS-016 opisuje FMUv6U i jest w oficjalnym README oznaczony jako draft.[1] To ważne: status roboczy oznacza, że projekt produktu powinien przypiąć dokładny commit/revision dokumentu i nie obiecywać zgodności z przyszłą wersją bez ponownej oceny.

PX4 reference design podaje dla v6U STM32H753, 1 MB RAM i 2 MB flash.[3] Sam opis nie wystarcza do wnioskowania o connectorach, sensorach i kompatybilności z v6X. Litery wariantów są częścią identyfikatora standardu; nie wolno traktować ich jako wymiennych rewizji.

FMUv6X RT#

FMUv6X-RT według tabeli PX4 używa NXP i.MX RT1176 z rdzeniem Cortex-M7 do 1 GHz i drugim Cortex-M4 do 400 MHz, 2 MB RAM oraz 64 MB Octal SPI flash. Profil zachowuje I/O MCU STM32F103, secure element, PAB, Ethernet, trzy IMU i dwa barometry, a zwiększa liczbę FMU PWM do 12 oraz CAN do trzech.[4]

Większa wydajność służy rozbudowanym algorytmom czasu rzeczywistego i interfejsom, ale nie zastępuje companion computera dla ciężkiej wizji komputerowej. PX4 nadal wskazuje, że zadania obliczeniowo intensywne, takie jak computer vision, zwykle wymagają companion solution.[4]

Architektura wielordzeniowa tworzy nowe pytania:

• które funkcje pracują na M7, a które na M4;
• jak izoluje się awarię i współdzieli pamięć;
• jakie są deadline i priorytety IPC;
• jak bootloader i update obsługują external flash;
• czy cały stos i sterowniki są równie dojrzałe jak na STM32;
• jaki jest pobór mocy i bilans cieplny.

Nie należy migrować do RT wyłącznie dla częstotliwości zegara. Trzeba mieć obciążenie, którego nie spełnia obecny kontroler, i plan kwalifikacji nowego targetu.

FMU i procesor IO#

W pełnej architekturze Pixhawk FMU uruchamia estimator, nawigację, kontrolery i główny stos. Osobny I/O MCU obsługuje krytyczne wyjścia, wejścia RC i bezpieczne zachowanie przy chwilowej niedostępności FMU.

Uproszczony przepływ:

IMU/GNSS/baro → FMU MCU → setpoints/actuator commands → I/O MCU → PWM/outputs
                    ↘ CAN/UART/Ethernet
RC/failsafe input ────────────────────────────────↗

I/O nie jest drugim pełnym autopilotem. Nie wykonuje zwykle niezależnej nawigacji. Może jednak utrzymać bezpieczne poziomy wyjść, miksować w ograniczonym zakresie, odebrać RC i egzekwować część failsafe. Dokładne zachowanie zależy od firmware I/O i konfiguracji.

PX4 ostrzega, że mapowanie MAIN i AUX zależy od obecności I/O oraz build targetu. Na płytkach bez I/O te same fizyczne wyjścia mogą być prezentowane inaczej; w przypadku Pixhawk 4 Mini dokumentacja opisuje nawet niezgodność nadruku z nazwą magistrali w konfiguratorze.[3] Migracja wymaga testu każdego kanału bez podłączonych śmigieł.

Awaria łącza FMU–I/O powinna prowadzić do określonego stanu. Wymagania obejmują timeout, poziomy wyjść, zachowanie armed/disarmed i log zdarzenia. Nie należy zakładać, że I/O automatycznie poprawia safety bez poprawnej konfiguracji.

Sensory i redundancja#

Standardy wyższych generacji stosują wiele IMU, barometrów i czasem magnetometrów. Redundancja może zapewniać:

• wybór sensora o najniższych innowacjach;
• przełączenie po awarii magistrali;
• wykrycie stuck-at i clipping;
• voting lub consistency monitoring;
• różne zakresy pomiarowe;
• termiczną i mechaniczną różnorodność.

Trzy układy w jednej obudowie nie są trzema całkowicie niezależnymi kanałami. Mogą dzielić:

• PCB i mechaniczne drgania;
• główną domenę zasilania;
• zegar lub linię reset;
• ten sam typ komponentu i jego common-mode defect;
• temperaturę;
• MCU i algorytm;
• lokalizację narażoną na EMI.

Architektura v6X dąży do rozdzielenia magistral i domen, ale produkt oraz carrier trzeba sprawdzić na schemacie. Estimator musi potrafić przejść między instancjami bez skoku. Kalibracja orientacji i biasu jest osobna dla każdego sensora.

Wartości 3× IMU i 2× barometer w tabeli standardu nie mówią, jakie konkretne modele znajdują się w danej rewizji produktu. Producenci mogą dokonywać substitutions z powodu EOL. Firmware target i device IDs muszą obsługiwać zamienniki, a operator powinien znać rewizję hardware.

Więcej o logice przełączania opisuje Redundancja sensorów w kontrolerze lotu.

Zasilanie i domeny awarii#

Kontroler może mieć dwa wejścia power module, USB, zasilanie z carrier/baseboard i osobne szyny dla servo rail. „Redundant power” nie zawsze oznacza idealne OR-ing dwóch całkowicie niezależnych źródeł. Trzeba ustalić:

• zakres napięć każdego wejścia;
• priorytet i układ OR-ing;
• maksymalny prąd dostarczany do kontrolera i peryferiów;
• czy USB może cofać prąd;
• czy servo rail zasila logikę;
• jakie porty mają własne current limit/load switch;
• jak mierzone są voltage/current;
• co dzieje się przy brownout jednego źródła;
• czy resetuje się FMU, I/O, sensory lub cały moduł.

Wielokrotne wejścia nie pomagają, jeśli oba power modules są zasilane z tego samego uszkadzalnego złącza akumulatora. Redundancja systemowa wymaga analizy common cause od ogniwa do regulatora i przewodu.

Spadek napięcia przy servo movement albo nadajniku radiowym może wprowadzić reset bez trwałego uszkodzenia. Testy brownout powinny rejestrować napięcia na samym module, sygnały reset i boot reason. Carrier musi mieć poprawną impedancję masy oraz kondensatory zgodne ze standardem.

Szerzej temat opisuje Architektura zasilania flight controllera i Brownout w UAV.

Interfejsy#

Typowa platforma Pixhawk udostępnia część następujących interfejsów:

Liczba portów w tabeli standardu nie oznacza, że można użyć wszystkich kombinacji jednocześnie. MCU ma alternate functions i DMA resources. Carrier może współdzielić linie. Firmware może nie mieć sterownika albo domyślnego mappingu. Potrzebna jest macierz pin–peripheral–DMA–driver dla konkretnego targetu.

CAN jest preferowany dla rozproszonych urządzeń o większej odporności i diagnostyce, ale wymaga poprawnej magistrali. I2C nadaje się do krótkich połączeń na płytce, nie do przypadkowej wiązki przez cały UAV. UART pozostaje elastyczny, lecz nie zapewnia automatycznie identyfikacji i redundancji.

Pixhawk Connector Standard#

DS-009 standaryzuje złącza i pinouty używane w ekosystemie. W praktyce spotyka się rodziny JST-GH i opisane role portów. Najważniejszą wartością jest ograniczenie dowolności, ale identyczna obudowa connectora nie gwarantuje identycznego pinoutu na urządzeniu spoza standardu.

Przed podłączeniem należy porównać:

• numer pinu 1 i orientację;
• napięcie zasilające;
• czy linie są wejściami czy wyjściami;
• poziomy 3,3 V/5 V;
• obecność hardware flow control;
• limit prądu portu;
• wspólną masę;
• ekranowanie i retention;
• opis kabla obu producentów.

Kabel „GPS Pixhawk” może łączyć moduł GNSS, magnetometr i safety switch/LED, ale różne generacje mają różne zestawy złączy. Przekładanie gotowych kabli bez pinout check jest częstą przyczyną uszkodzeń.

Connector Standard nie zastępuje wymagań wiązki: przekrój, spadek napięcia, promień gięcia, odporność na wibracje, strain relief, kluczowanie, oznaczenia i inspekcja są częścią systemu.

Pixhawk Autopilot Bus#

PAB z DS-010 oddziela moduł FMU od carrier/baseboard. Wielopinowe połączenie przenosi zasilanie i wiele interfejsów, umożliwiając wspólny moduł obliczeniowo-sensorowy na różnych carrierach.

Zalety:

• reużycie zweryfikowanego FMU;
• carrier dopasowany do pojazdu i złączy;
• krótszy czas projektowania wariantu;
• łatwiejsza wymiana modułu;
• rozdzielenie szybkiej elektroniki od wysokoprądowej dystrybucji.

Koszty:

• dodatkowy connector i jego niezawodność;
• ograniczenia pin assignment;
• trudniejsza mechanika i stack-up;
• potrzeba kontroli impedance/signal integrity;
• nowe ścieżki ESD i ground return;
• ryzyko niepełnej zgodności carrierów.

Carrier zgodny elektrycznie nie jest automatycznie zgodny termicznie i mechanicznie. Obudowa może dociskać moduł, utrudniać tłumienie drgań albo blokować przepływ powietrza. Wysokoprądowe ścieżki ESC na carrierze mogą sprzęgać EMI do IMU.

Projekt carrier board powinien zaczynać się od właściwej rewizji DS-010 i standardu FMU. Każda niewykorzystana linia, power domain i strap musi mieć zdefiniowany stan. Nie wolno opierać projektu tylko na reverse engineering jednego produktu.

Payload Bus i Radio Interface#

DS-014 Payload Bus definiuje hardware/software integration dla kamer, gimbali i urządzeń zadaniowych, z interfejsem programowym opartym na MAVLink i mechanizmami ochrony hot-swap wymienionymi przez Pixhawk.[2] Celem jest interoperacyjność, a nie przenoszenie surowych sygnałów każdej kamery.

Payload Bus powinien być analizowany osobno od PAB:

• PAB łączy FMU z carrierem autopilota;
• Payload Bus łączy system z payloadem;
• MAVLink opisuje sterowanie i status;
• szybkie dane wideo mogą wymagać Ethernetu lub innego kanału;
• zasilanie payloadu ma własny inrush, current limit i fault containment.

DS-017 Radio Interface dotyczy standaryzacji interfejsu radiowego. W praktycznym projekcie trzeba ustalić przepustowość, latency, port fizyczny, zasilanie, anteny, aktualizację firmware i zachowanie po utracie linku. Sam standard connectora nie zapewnia jakości C2.

Firmware target i zgodność binarna#

Generacja FMU jest powiązana z firmware targetem. Płytki oparte na tym samym reference design powinny być binarnie zgodne, ale konkretne produkty mogą wymagać osobnego targetu z powodu sensorów, pin mappingu, bootloadera lub peripheral set.[3][4]

Łańcuch identyfikacji:

USB/bootloader board ID
  → firmware target
  → board configuration
  → pin/peripheral map
  → sensor probe list and rotations
  → parameter defaults

Wgranie obrazu dla „podobnego H7” może uruchomić MCU, ale błędnie skonfigurować zasilanie sensorów, wyjścia, safety switch albo LED. Bootloader powinien weryfikować board ID i kompatybilność obrazu.

Zgodność binarna nie oznacza identycznych parametrów kalibracji. Każdy egzemplarz ma własne biasy IMU, compass offsets, voltage dividers i orientacje instalacji. Kopia pełnego pliku parametrów może nadpisać kalibrację urządzenia.

Przy własnym buildzie trzeba zapisać commit, toolchain, config, moduły i board target. Oficjalny stable release dla standard board ma inną ścieżkę testową niż prywatny fork.

PX4 i ArduPilot#

Pixhawk jest reference hardware dla PX4 i standardowe płytki należą zwykle do najlepiej utrzymywanych targetów projektu.[4] Nie oznacza to, że każdy wariant wspiera każdą funkcję ani że main jest wydaniem produkcyjnym.

ArduPilot obsługuje szeroką gamę kontrolerów, w tym wiele rodzin Pixhawk i Cube. Używa własnych board definitions, bootloaderów, parameter set i polityki wydawniczej. Lista wspieranych hardware i ograniczeń musi pochodzić z dokumentacji bieżącej wersji ArduPilot oraz producenta.

Wybór stosu wpływa na:

• target i sposób flashowania;
• mapowanie wyjść;
• obsługę sensorów i redundancy policy;
• parametry CAN/serial;
• format logów;
• GCS;
• funkcje misji i failsafe;
• procedurę update/rollback;
• zakres testów producenta.

Sprzęt nie powinien być kupowany przed sprawdzeniem docelowej funkcji w konkretnym buildzie. „PX4 compatible” może znaczyć możliwość uruchomienia podstawowego firmware, a nie wsparcie Ethernetu, wszystkich IMU lub konkretnego peripheral drivera.

Standard a konkretny produkt#

Oficjalna strona Pixhawk publikuje listę qualified designs/products i wymienia bieżące implementacje generacji.[5] PX4 osobno rozróżnia Pixhawk Standard Autopilots, manufacturer-supported, experimental/discontinued i unsupported.[4]

Profil produktu powinien zawierać:

Nie należy przepisywać parametrów z innego produktu tej samej generacji. FMUv6X definiuje bazę, ale Holybro i CUAV mogą różnić się obudową, portami, carrierem, sensorami konkretnej rewizji oraz procedurą producenta.

„Klone Pixhawk” wymaga szczególnej ostrożności. Możliwe ryzyka to inne regulatory, podrabiane sensory, błędne orientation, brak ESD, słabsze złącza, zmienione dzielniki napięcia i brak traceability. Cena nie pozwala ocenić zgodności.

Licencja i znak towarowy#

PX4 podaje, że schematy i reference designs projektu Pixhawk są udostępniane na CC BY-SA 3.0. Bezpośrednio pochodne projekty muszą spełnić obowiązki attribution/share-alike; niezależnie utworzony kompatybilny schemat może mieć inną licencję według opisu projektu.[4] Dokładną ocenę licencyjną należy oprzeć na plikach źródłowych i konsultacji prawnej, nie na tym skrócie.

Pixhawk jest znakiem towarowym i jego użycie w nazwie produktu wymaga zgodności z zasadami właściciela. „Obsługuje target FMUv6X” nie jest automatycznie prawem do nazwania produktu Pixhawk 6X.

Otwartość standardu nie oznacza otwartości każdego produktu. Producent może realizować interfejsy na niezależnym schemacie i zachować część designu jako proprietary. Kupujący powinien ustalić dostępność schematu, BOM, gerberów, bootloadera i plików carrier separately.

Kryteria doboru#

Dobór zaczyna się od wymagań, nie od modelu MCU.

Funkcja i ryzyko#

• rodzaj platformy: multirotor, fixed-wing, VTOL, UGV, USV;
• liczba aktuatorów i rodzaje wyjść;
• potrzebna redundancja sensorów;
• wymagania safety I/O;
• geofence/misja/autonomia;
• krytyczność utraty kontrolera;
• czas wsparcia i traceability.

Interfejsy#

• liczba GNSS i magnetometrów;
• DroneCAN ESC/servo;
• Ethernet i companion;
• liczba telemetrii UART;
• airspeed/rangefinder;
• RC i backup C2;
• payload bus;
• debug i test points.

Zasoby#

• CPU load w docelowym buildzie;
• RAM peak i stack margins;
• flash na moduły i rollback;
• log bandwidth na microSD;
• liczba estimator instances;
• kryptografia i secure element;
• przewidywany rozwój firmware.

Fizyczne#

• masa i wymiary z carrierem;
• orientacja złączy;
• drgania;
• temperatura i chłodzenie;
• IP/obudowa;
• EMI od napędu i radia;
• obsługa serwisowa.

Ekosystem#

• status targetu w stable release;
• dokumentacja producenta;
• dostępność w legalnym kanale;
• polityka substitutions;
• narzędzia testowe;
• wsparcie GCS i akcesoriów;
• możliwość zakupu identycznej rewizji.

Wynikiem powinien być scorecard z wymaganiami must/should, a nie ranking „najlepszy Pixhawk”.

Integracja elektryczna#

Proces integracji:

1. Zamrozić model i rewizję kontrolera oraz carrier.
2. Zebrać pinout, schemat blokowy, limity zasilania i target firmware.
3. Utworzyć tabelę każdego portu: złącze, pin, funkcja, poziom, kierunek, current limit.
4. Zbudować budget prądu kontrolera i peryferiów.
5. Zaprojektować CAN topology i terminację.
6. Sprawdzić ground return dla analogów i power modules.
7. Określić ESD/TVS, ekranowanie i strain relief.
8. Wykonać continuity test wiązki przed podłączeniem.
9. Uruchomić z current-limited supply.
10. Sprawdzić rails, pobór i temperaturę przed flashowaniem.

Servo rail bywa oddzielny od zasilania logiki. Nie należy zakładać, że kontroler zasili serwa ani że BEC na servo rail zasili FMU. Konkretna płytka może mieć częściowe połączenia, ale trzeba to potwierdzić.

Analogowe voltage/current inputs mają określony zakres ADC i scaling. Podanie napięcia akumulatora bez dzielnika uszkodzi MCU. Nawet właściwy power module wymaga ustawienia parametrów mnożnika i porównania z miernikiem.

Na CAN terminatory powinny znaleźć się na dwóch końcach magistrali, nie w każdym urządzeniu. Odgałęzienia muszą być krótkie odpowiednio do bitrate. Zasilanie CAN peripherals potrzebuje własnego budgetu i ochrony zwarciowej.

Montaż mechaniczny i termiczny#

IMU mierzy przyspieszenie obudowy. Montaż ma bezpośredni wpływ na estymację. Zbyt sztywne połączenie przenosi harmoniczne napędu; zbyt miękkie tworzy rezonans i ruch względny. Wewnętrzne damping w produkcie nie zwalnia z oceny całej struktury.

Wymagania montażu:

• jednoznaczna orientacja osi;
• środek możliwie blisko środka obrotu;
• odległość od przewodów wysokoprądowych, magnesów i nadajników;
• brak naprężenia connectorów;
• zabezpieczenie modułu PAB;
• kontrola rezonansu mountu;
• dostęp do microSD/USB/debug;
• ochrona przed wilgocią bez zamknięcia ciepła;
• oznaczona pozycja i torque elementów.

H7 i RT1176 generują ciepło zależne od obciążenia. Zamknięta obudowa może podnieść temperaturę IMU i regulatorów. Kalibracja termiczna pomaga biasom, ale nie rozwiązuje przekroczenia ratingu. Test thermal soak powinien działać z docelowym logowaniem, Ethernetem, CAN i peryferiami.

Barometr potrzebuje ochrony przed światłem, prop wash i zmianami ciśnienia w obudowie. Pianka tłumi szybkie zaburzenia, lecz może opóźniać odpowiedź i chłonąć wilgoć. Vent i membrana muszą być częścią testu wysokości.

Bring up nowej konstrukcji#

Bezpieczna kolejność dla gotowego produktu albo własnego carriera:

visual inspection
→ resistance/short checks
→ current-limited power
→ rail measurements
→ bootloader identification
→ approved firmware target
→ console and board ID
→ sensor enumeration/orientation
→ storage and logging
→ communications
→ outputs without actuators
→ one peripheral at a time
→ full bench test

Pierwszy boot powinien zapisać:

• board ID i hardware revision;
• bootloader version;
• MCU device ID i silicon revision;
• detected sensors oraz bus/address/device ID;
• power rails i reset reason;
• SD/FRAM status;
• firmware commit/build ID;
• default parameters checksum.

Jeśli jedno z trzech IMU nie jest wykryte, nie należy po prostu obniżać wymaganej liczby i kontynuować. Trzeba ustalić, czy produkt ma inną rewizję, sterownik nie obsługuje sensora, występuje błąd zasilania czy uszkodzenie.

Test outputs wykonuje się bez śmigieł i najlepiej bez aktywnego napędu. Mapowanie MAIN/AUX i kolejność motorów musi zostać potwierdzona fizycznie. Safety switch, arm state i I/O failsafe testuje się przed podłączeniem wysokiej energii.

Kwalifikacja i testy#

Funkcjonalne#

• boot cold/warm i update/rollback;
• wszystkie instancje IMU/baro/mag;
• GNSS, UART, CAN, Ethernet, USB;
• microSD przy maksymalnym log rate;
• analog voltage/current;
• RC i telemetry failsafe;
• FMU/IO output mapping;
• watchdog i reset reason.

Fault injection#

• odłączenie jednego power input;
• zapad i wolny spadek napięcia;
• zwarcie/peripheral overcurrent na chronionym porcie;
• utrata jednego IMU;
• stuck SPI/I2C;
• brak microSD i pełny filesystem;
• restart FMU przy aktywnym I/O;
• utrata FMU–I/O link;
• CAN bus-off;
• nieprawidłowy firmware image.

Środowiskowe#

• vibration sweep i losowe drgania;
• thermal cold/hot soak;
• cykle temperatury;
• wilgoć/kondensacja według zastosowania;
• EMI emissions/immunity;
• ESD na dostępnych złączach;
• mechaniczny retention kabli;
• długotrwały burn-in.

Software#

• CPU load i latency przy najgorszym zestawie modułów;
• RAM/stack margin;
• log drop rate;
• estimator failover;
• timestamp consistency;
• parameter migration;
• SITL/HIL dla misji i failsafe;
• zgodność z GCS i provisioning.

Kwalifikacja powinna dotyczyć BOM/revision. Zmiana IMU, regulatora lub connectora wymaga impact assessment i regresji. „Ten sam model” na obudowie może nie wystarczyć do zachowania certyfikacji wewnętrznej.

Migracja między generacjami#

Migracja z FMUv3/v5 do v6X nie jest operacją plug-and-play tylko dlatego, że oba urządzenia mają port GPS1 i TELEM1.

Checklist:

• pinout i kable;
• napięcia oraz power modules;
• orientation kontrolera;
• target i bootloader;
• mapping MAIN/AUX;
• typ i numer instancji sensorów;
• bus order i device IDs;
• CAN node configuration;
• serial protocol/baud;
• kalibracje analogów;
• parameter rename/default changes;
• log format i narzędzia;
• behavior failsafe;
• mechanical resonance;
• thermal envelope.

Parametry należy migrować selektywnie. Airframe, PID, mission settings i serial configuration mogą być przeniesione po przeglądzie. Kalibracje IMU, compass offsets, board-specific rotations, voltage scaling i thermal compensation zwykle wykonuje się od nowa.

Porównanie A/B wymaga tych samych warunków: śmigła, masa, mount, firmware release i logging. Niższe vibration na nowym kontrolerze może wynikać z innego mountu, nie lepszego IMU.

Typowe błędy#

Pixhawk jako synonim PX4#

Hardware standard, firmware, protokół i GCS są osobnymi warstwami. Każda ma wersję i własną zgodność.

Kupowanie po numerze generacji#

FMUv6C i v6X mają inne profile. Najpierw wymagania interfejsów, redundancy i carrier, potem generacja.

Zakładanie zgodności po wyglądzie złącza#

Identyczny connector może mieć inny pinout lub napięcie. Każdy kabel wymaga dokumentacji obu stron.

Mylenie produktu ze standardem#

Parametry jednego Pixhawk 6X nie opisują automatycznie wszystkich implementacji FMUv6X.

Brak wersji hardware#

Substitution sensora może zmienić driver, zakres i zachowanie. Rewizja musi być w ewidencji.

Redundancja liczona elementami#

Trzy IMU współdzielą część common-mode. Należy analizować domeny zasilania, magistrale, estimator i mechanikę.

Wgranie podobnego targetu#

Zgodny MCU nie oznacza zgodnego board config. Błąd może dotknąć wyjść i zasilania sensorów.

Kopiowanie pełnych parametrów#

Nadpisuje kalibracje i ustawienia board-specific. Migracja powinna być kontrolowana i selektywna.

Pominięcie I/O#

Obecność lub brak procesora I/O zmienia mapowanie wyjść i zachowanie awaryjne. Test MAIN/AUX jest obowiązkowy.

Brak testu carrier board#

Zgodny moduł na błędnym carrierze nie jest zgodnym systemem. Trzeba kwalifikować power, signal integrity, EMI i mechanikę razem.

Używanie strony produktu jako normy#

Do implementacji służy właściwy dokument DS i rewizja. Strona producenta opisuje produkt, nie wszystkie wymagania standardu.

Pixhawk daje producentom wspólny język sprzętowy i dojrzały ekosystem. Jego największą wartością nie jest konkretny mikrokontroler, lecz możliwość oddzielenia sprawdzonej architektury FMU, firmware i carrierów — pod warunkiem, że zgodność jest weryfikowana na podstawie dokumentów, a nie nazwy na obudowie.

Powiązane tematy#

• Flight controller — jak działa
• STM32 w flight controllerach
• PX4 — architektura i ścieżka startowa
• Redundancja sensorów w kontrolerze lotu
• Architektura zasilania flight controllera
• CAN w UAV
• Cube Autopilot — rodzina kontrolerów
• Holybro Durandal — profil techniczny

Przypisy#

1. Pixhawk, oficjalne repozytorium „Pixhawk Standards” — lista dokumentów DS, statusy i pliki normatywne.
2. Pixhawk.org, „Reference Standards” — zakres Autopilot, Connector, Payload Bus i pozostałych rodzin interfejsów.
3. PX4, „Reference Flight Controller Design” — generacje FMU, zgodność binarna i podział FMU/I/O.
4. PX4, „Pixhawk Series” — statusy wsparcia, charakterystyka generacji, porównanie FMUv6 i licencjonowanie.
5. Pixhawk.org, „Qualified Designs and Products” — oficjalna lista produktów przedstawianych jako zgodne konstrukcje.
6. STMicroelectronics, dokumentacja rodziny STM32H743/753 — szczegóły MCU używanych w generacjach FMUv6X i FMUv6C.

Powiązane tematy

Flight controller — jak działaPrzekrojowa techniczna anatomia kontrolera lotu: sprzęt, domeny czasu, sensory, estymacja stanu, regulatory kaskadowe, alokacja sterowania, wyjścia, zasilanie, odporność na awarie, logowanie i uruchomienie platformy.STM32 w flight controllerachPorównanie rodzin STM32 z perspektywy FC: magistrale, DMA, cache, TCM, timery, FPU, pamięć i pułapki deterministyczności.PX4 — architektura i ścieżka startowaJak czytać i rozszerzać PX4: przepływ sensor–estimator–controller–actuator, komunikacja uORB i wybór między taskiem a work queue.Redundancja sensorów w flight controllerzeRedundancja bez liczenia samych układów: niezależność zasilania i magistral, wykrywanie stuck/noise/bias, voting, równoległe estymatory i kontrolowane failover.Architektura zasilania flight controlleraOd baterii i power module do rdzenia MCU: budżet mocy, ideal-diode ORing, priorytety źródeł, inrush, filtracja, sekwencjonowanie, load switch i obserwowalność.CAN i CAN FD w UAVCAN jako deterministyczna magistrala współdzielona: identyfikatory, arbitraż bez utraty ramki, bit stuffing, ACK/CRC, transceiver, terminacja i fault confinement.Cube Autopilot — rodzina kontrolerówRodzina Cube rozłożona na moduł i carrier: generacje STM32F427/F777/H753/H757, aktualne oraz EOL warianty, fixed i vibration-isolated IMU, ogrzewanie oraz wspólne przyczyny awarii, 14 wyjść FMU/IO, SPI/I2C/CAN/UART, szczegółowa architektura main/aux/USB/servo power, ADS-B carrier, kompatybilność 80-pin DF17 i praktyczny proces doboru, integracji, migracji oraz testów fault injection.Holybro Durandal — profil technicznyKonkretny profil Durandal: STM32H743 i STM32F100/F103 I/O, dwa IMU Bosch/InvenSense, heater i mechaniczna izolacja, magnetometr IST8310 i barometr MS5611, pamięć/logowanie, UART–I2C–SPI–CAN, dual power monitor i servo rail, ograniczenia grup wyjściowych oraz ujawniona sprzeczność producenta i ArduPilot co do liczby PWM. Artykuł kończy się procedurą bring-up, testów brownout, wibracji, failover i wersjonowania dokumentacji.

Źródła z centralnego rejestru

1. Pixhawk Standards — official specification repository [repozytorium standardów open hardware]
2. Pixhawk: Reference Standards overview [oficjalny opis standardów]
3. PX4 Guide: Reference Flight Controller Design [dokumentacja projektu]
4. PX4 Guide: Pixhawk Series [dokumentacja projektu]
5. Pixhawk: Qualified Designs and Products [oficjalny katalog zgodnych konstrukcji]
6. STMicroelectronics: STM32H743/753 documentation [producent]