DroneCAN, UAVCAN v0 i Cyphal

DroneCAN jest otwartym protokołem sieci pokładowej działającym na rozszerzonych ramkach CAN 2.0B. Łączy autopilot z inteligentnymi ESC, GNSS, kompasami, modułami zasilania, czujnikami prędkości powietrznej i innymi węzłami bez centralnego switcha. Definiuje transport wieloramkowy, typy danych, usługi konfiguracyjne i podstawowe zachowanie węzła. Nie zapewnia jednak sam z siebie uwierzytelnienia, szyfrowania ani fizycznej redundancji.

Spis treści#

Nazwy: UAVCAN v0, DroneCAN i Cyphal
Model rozproszony
Node ID
Wiadomości i usługi
Identyfikator CAN i priorytet
Transfer i ramka
Tail byte
Transfer wieloramkowy i CRC
Transfer-ID i duplikaty
DSDL i typy danych
Podstawowe funkcje węzła
Dynamiczne przydzielanie Node ID
Parametry i aktualizacja firmware
Synchronizacja czasu
Klasy urządzeń UAV
Budżet magistrali
Implementacja bez dynamicznej alokacji
Warstwa sprzętowa
Redundancja
Interoperacyjność
Bezpieczeństwo systemowe
DroneCAN a MAVLink
DroneCAN a Cyphal
Diagnostyka i uruchomienie
Lista integracyjna
Powiązane tematy
Przypisy

Nazwy: UAVCAN v0, DroneCAN i Cyphal#

Pierwotny UAVCAN v0 stał się podstawą wdrożeń w autopilotach i urządzeniach lotniczych. Społeczność utrzymująca tę gałąź używa nazwy DroneCAN. Dokumentacja DroneCAN opisuje zgodność i rozwój ekosystemu v0.

Nowszy protokół, rozwijany wcześniej jako UAVCAN v1, nosi nazwę Cyphal. Ma przeprojektowany model danych i transporty nieograniczone wyłącznie do Classical CAN. Cyphal/CAN nie jest zgodny na przewodzie z DroneCAN. Wspólne pochodzenie i podobne pojęcia nie oznaczają, że węzeł jednego protokołu zdekoduje drugi.

W dokumentacji projektu trzeba więc zapisać konkretnie:

DroneCAN/UAVCAN v0;
Cyphal w określonej wersji regulowanej specyfikacją;
używany zestaw definicji DSDL;
bitrate i profil sprzętowy.

Samo określenie „UAVCAN” jest dziś niejednoznaczne. Przy zakupie sensora należy potwierdzić implementację, nie wnioskować z nazwy złącza.

Model rozproszony#

Każdy węzeł ma własny MCU, kontroler CAN i stos DroneCAN. Węzły publikują wiadomości i odpowiadają na usługi bez centralnego brokera. CAN rozstrzyga dostęp do przewodu według identyfikatora.

Typowy przepływ:

GNSS ── pozycja/czas ──┐
Air data ── ciśnienie ─┼── CAN ── Flight Controller
Power node ── U/I ─────┤
Flight Controller ── polecenia ── ESC

Flight controller może być logicznym koordynatorem lotu, ale nie jest przełącznikiem wymaganym do przesłania wiadomości między innymi węzłami. Węzeł GNSS może publikować dane, które odbierze kilka zainteresowanych urządzeń.

Rozproszenie ogranicza liczbę przewodów analogowych i umożliwia lokalną kompensację sensora. Dodaje jednak firmware w każdym module, wersjonowanie definicji danych i nowe tryby awarii: konflikt Node ID, przeciążenie magistrali, niezgodny DSDL albo częściową aktualizację floty węzłów.

Node ID#

DroneCAN używa Node ID z zakresu 1–127 dla zwykłych, skonfigurowanych węzłów. Wartość 0 oznacza węzeł anonimowy i ma ograniczone możliwości transportowe. Nie jest zwykłym „urządzeniem numer zero”.

Node ID identyfikuje instancję w bieżącej sieci, nie model ani trwałą tożsamość sprzętu. Dwa aktywne węzły z tym samym numerem mogą wysyłać ramki o identycznym CAN ID z różnym payloadem. Powoduje to bit errors po polu arbitrażu i może doprowadzić do stanów błędowych.

Trwałą identyfikację wspierają informacje węzła, w szczególności unikalny identyfikator. Konfigurator powinien kojarzyć rolę z unikalną tożsamością, a Node ID traktować jako adres sieciowy.

Statyczny plan adresów jest prosty w małym UAV. Dynamiczna alokacja ułatwia wymianę modułu, lecz wymaga działającego alokatora i poprawnej implementacji procedury. W obu przypadkach test przed lotem wykrywa duplikaty.

Wiadomości i usługi#

Message jest transmisją broadcast. Publisher nie wskazuje konkretnego odbiorcy; wszystkie węzły mogą ją zobaczyć, a filtry i subskrypcje wybierają potrzebne typy. Przykładem jest okresowa publikacja statusu lub pomiaru.

Service tworzy parę request/response między klientem i serwerem. Identyfikator zawiera cel, źródło oraz kierunek request/response. Usługi nadają się do odczytu informacji, zmiany parametru i operacji zarządzających.

Warstwa transportowa nie gwarantuje aplikacyjnego skutku. Odpowiedź usługi może potwierdzić wynik, natomiast sama obecność ACK CAN oznacza wyłącznie poprawny odbiór ramki przez co najmniej jeden kontroler.

Broadcast nie jest poleceniem „bez odbiorcy”. Polecenie ESC publikowane określonym typem danych nadal ma krytyczne znaczenie. Odbiorca waliduje indeks, długość, częstotliwość i timeout.

Identyfikator CAN i priorytet#

DroneCAN wykorzystuje rozszerzony identyfikator 29-bitowy. Koduje w nim priorytet i informacje transportowe potrzebne do rozróżnienia typu transferu, źródła oraz — dla usługi — celu i kierunku.

Niższa wartość w polu arbitrażu wygrywa na CAN. Priorytet protokołu jest więc realizowany sprzętowo, zanim payload trafi do odbiorcy. Krytyczna wiadomość może wyprzeć telemetrię, ale tylko jeśli identyfikatory i scheduler TX są poprawnie zbudowane.

Nie należy ręcznie traktować pełnego 29-bitowego CAN ID jako dowolnego numeru wiadomości. Jego pola są częścią specyfikacji. Błąd maski lub przesunięcia może zmienić priorytet, pomylić service z message albo przypisać niewłaściwy Node ID.

Sprzętowe filtry CAN można ustawić tak, by przepuszczały interesujące transfery. Filtry muszą uwzględnić, że pola źródła i celu zmieniają część identyfikatora. Zbyt agresywna maska wygląda jak brak publishera, mimo że ramki istnieją na przewodzie.

Transfer i ramka#

Transfer jest jednostką protokołu DroneCAN. Może zmieścić się w jednej ramce CAN albo zostać podzielony. Każda ramka Classical CAN przenosi do ośmiu bajtów, przy czym ostatni bajt payloadu CAN jest zarezerwowany jako tail byte transportu.

Dla transferu jednoramkowego zostaje zatem do siedmiu bajtów danych serializowanych. Dla większych danych fragmenty wykorzystują kolejne ramki, a transport odbiorcy składa je według identyfikatora, transfer-ID i toggle.

Pojęć nie należy mieszać:

ramka CAN — atomowa transmisja warstwy CAN;
transfer DroneCAN — jedna wiadomość lub request/response, z jednej albo wielu ramek;
typ danych — schemat interpretacji z DSDL;
publikacja/subskrypcja — relacja aplikacyjna.

Limit czasu kompletowania transferu zapobiega przetrzymywaniu niepełnego bufora bez końca. Utrata jednej ramki unieważnia cały transfer wieloramkowy.

Tail byte#

Ostatni bajt każdej ramki transportowej zawiera:

bit 7: start of transfer
bit 6: end of transfer
bit 5: toggle
bit 4..0: transfer-ID

W transferze jednoramkowym ustawione są start i end. W wieloramkowym pierwsza ramka ma start, ostatnia end, a toggle zmienia się między kolejnymi ramkami. Odbiorca wykrywa brak, duplikację lub zmianę kolejności fragmentów.

Transfer-ID ma pięć bitów, więc zawija po 31 do 0. Nie jest globalnym, nigdy niepowtarzalnym numerem. Stan śledzi się osobno dla właściwego deskryptora sesji: rodzaju transferu, typu, źródła i celu tam, gdzie ma zastosowanie.

Tail byte nie jest częścią danych DSDL. Sterownik transportu usuwa go przed deserializacją i dodaje przy nadawaniu.

Transfer wieloramkowy i CRC#

Transfer przekraczający pojemność jednej ramki otrzymuje 16-bitowe CRC transportowe. Algorytm CRC-16-CCITT-FALSE jest powiązany z sygnaturą typu danych, dzięki czemu odbiorca sprawdza nie tylko ciąg bajtów, ale również oczekiwany typ. Dokładną kolejność inicjalizacji i serializacji należy implementować według specyfikacji, nie według typowego CRC z przypadkowej biblioteki.

CRC jest umieszczone na początku strumienia wieloramkowego, a następnie fragmentowane razem z payloadem. Transfer jednoramkowy nie ma tego dodatkowego CRC transportowego — korzysta z CRC ramki CAN i ograniczeń typu.

Odbiornik po pierwszej ramce rezerwuje lub przypisuje bufor o maksymalnym rozmiarze danego typu. Kolejne fragmenty muszą mieć ten sam identyfikator CAN, prawidłowy transfer-ID i naprzemienny toggle. Timeout, nowy start albo błąd kolejności usuwa niedokończony stan.

Współbieżne transfery o tym samym pełnym CAN ID wymagają zachowania kolejności ramek. Stos TX nie może przeplatać dwóch wieloramkowych transferów tej samej sesji. Ogólny scheduler CAN uwzględnia tę własność przy pracy z kilkoma producentami danych.

Transfer-ID i duplikaty#

Publisher zwiększa transfer-ID kolejnych transferów danego typu i celu zgodnie z regułami specyfikacji. Odbiorca używa go do wykrywania duplikatów, przerw i porządku. Po długiej ciszy stan może wygasnąć, aby ponownie uruchomiony węzeł został zaakceptowany.

Nie wolno używać transfer-ID jako licznika pomiarów o nieograniczonym zakresie. Zawija szybko, a różne sesje mają osobne wartości. Jeżeli aplikacja potrzebuje numeru próbki lub czasu sensora, pole musi należeć do danych typu.

Retransmisja na poziomie usługi nie może ślepo powtarzać nieidempotentnej operacji. Klient, który nie dostał odpowiedzi, nie wie automatycznie, czy request nie dotarł, czy odpowiedź zginęła po wykonaniu. Projekt usługi powinien ograniczać skutki powtórzeń.

DSDL i typy danych#

DSDL opisuje pola, tablice, unity i zagnieżdżone struktury typów. Narzędzia generują kod serializacji/deserializacji dla konkretnych języków i MCU. To eliminuje ręczne przesunięcia bajtów, ale nie zwalnia z zarządzania wersją definicji.

Serializacja jest bitowo zwarta. Pola nie muszą zaczynać się na granicy bajtu. Zwykłe rzutowanie struktury C na uint8_t* jest błędne przez padding, endianowość i niezgodny układ bitów.

Data type signature identyfikuje strukturę typu i uczestniczy w ochronie transferu wieloramkowego. Dwa typy o podobnym payloadzie, ale innej definicji nie powinny być uznane za zgodne tylko dlatego, że „bajty wyglądają poprawnie”.

Tail Array Optimization w UAVCAN v0 pozwala w określonych warunkach pominąć jawne kodowanie długości ostatniej tablicy o zmiennej długości i wywnioskować ją z rozmiaru transferu. Generator DSDL powinien realizować regułę; ręczny dekoder musi znać kontekst i ograniczenia.

Typy vendor-specific umożliwiają innowację, ale ograniczają interoperacyjność. Produkt powinien używać standardowych typów tam, gdzie ich semantyka pasuje, a typ niestandardowy dokumentować i wersjonować.

Podstawowe funkcje węzła#

Węzeł operacyjny publikuje swój status okresowo, nie rzadziej niż wymaga specyfikacja. Status przekazuje uptime, health, mode i submode/vendor-specific status. Brak świeżego statusu jest sygnałem utraty węzła, lecz próg timeout musi uwzględniać obciążenie i restart.

Usługa GetNodeInfo dostarcza nazwę, wersję oprogramowania i sprzętu oraz unikalny identyfikator. Narzędzie integracyjne wykorzystuje ją do inwentaryzacji i sprawdzania zgodności firmware.

Poprawny węzeł ma maszynę stanów, nie tylko pętlę wysyłającą sensory. Przykładowe tryby INITIALIZATION, OPERATIONAL, MAINTENANCE i SOFTWARE_UPDATE mają znaczenie dla interpretacji danych. Pomiar opublikowany przy health ERROR nie powinien być traktowany identycznie jak nominalny.

Watchdog węzła monitoruje zarówno aplikację sensora, jak i postęp transportu. Sam fakt, że CAN IRQ działa, nie dowodzi aktualności danych fizycznych.

Dynamiczne przydzielanie Node ID#

Węzeł bez stałego Node ID może rozpocząć jako anonimowy i uczestniczyć w procedurze dynamic node ID allocation. Alokator wykorzystuje unikalny identyfikator urządzenia, aby przypisać wolny numer.

Procedura jest wieloetapowa ze względu na mały payload i ograniczenia anonimowego nadawcy. Implementację należy oprzeć na specyfikacji lub dojrzałej bibliotece; uproszczenie do „wyślij UID, odbierz adres” pomija arbitraż i fragmentację procesu.

W systemie potrzebna jest polityka trwałości:

czy przydział jest zachowywany w pamięci nieulotnej;
co dzieje się po wymianie alokatora;
jak wykrywa się dwa węzły ze skopiowanym UID;
jak przypisuje się funkcję fizyczną, np. lewy ESC, do tożsamości;
czy system może uzbroić napęd przed zakończeniem inwentaryzacji.

Na stanowisku testuje się start wszystkich nowych węzłów jednocześnie, restart alokatora i utratę odpowiedzi w każdym etapie.

Parametry i aktualizacja firmware#

Standardowe usługi parametrów umożliwiają odczyt i zapis nazwanych wartości oraz zapis do pamięci. Wersje urządzeń różnią się zakresem i semantyką parametrów, dlatego konfigurator odczytuje listę i waliduje wynik.

Zmiana parametru może być zaakceptowana w RAM, lecz nieważna po restarcie. Operacja zapisu trwałego jest osobnym krokiem. Brownout podczas zapisu nie może zniszczyć całej konfiguracji — węzeł potrzebuje atomowego formatu, kopii lub journalu.

Aktualizacja oprogramowania może używać usługi rozpoczęcia aktualizacji i protokołu plikowego, w którym węzeł pobiera fragmenty obrazu. Transfer jest niskiego priorytetu i może trwać długo. System nadal powinien utrzymywać status oraz bezpiecznie reagować na utratę zasilania.

DroneCAN nie zapewnia natywnego kryptograficznego potwierdzenia obrazu. Bootloader urządzenia powinien sam weryfikować podpis, wersję i zgodność sprzętową. Aktualizacja jest dozwolona tylko w kontrolowanym stanie serwisowym; przypadkowa komenda w locie nie może przełączyć krytycznego węzła do bootloadera.

Synchronizacja czasu#

Synchronizacja czasu pozwala węzłom odnieść pomiary do wspólnej osi. Jest ważna dla GNSS, wielu IMU i sensorów, których zmienne opóźnienie transmisji pogarsza fuzję.

Znacznik czasu utworzony po odebraniu kompletnego transferu opisuje chwilę odbioru, nie wykonania pomiaru. Sensor powinien timestampować próbkę możliwie blisko przerwania data-ready lub hardware capture, a protokół przekazuje ten czas we właściwym polu.

Wiadomość synchronizacyjna nie eliminuje offsetu i jitteru bez modelu. Węzeł estymuje różnicę zegarów, odrzuca skoki oraz obsługuje restart źródła. PPS GNSS może poprawić wspólną referencję, jeśli jest fizycznie rozprowadzony i prawidłowo skojarzony z czasem wiadomości.

Log powinien zachować czas lokalny odbioru, czas źródła i stan synchronizacji. Dzięki temu po locie można odróżnić ruch obiektu od opóźnienia sieci.

Klasy urządzeń UAV#

Ekosystem obejmuje standardowe typy danych dla typowych funkcji. W praktyce spotyka się:

GNSS: pozycja, prędkość, status rozwiązania i czas;
magnetometr: wektor pola oraz wariancja/status;
air data: ciśnienie statyczne i różnicowe, temperatura;
moduł zasilania/bateria: napięcie, prąd, energia, status;
ESC: polecenia oraz telemetria obrotów, prądu i temperatury;
serwa/aktuatory i wskaźniki;
urządzenia zarządzające parametrami i plikami.

Dokładne pola oraz jednostki wynikają z konkretnej definicji DSDL. Nazwa typu „battery info” nie uprawnia do przyjęcia, że prąd ma znak, jednostkę i częstotliwość identyczne jak w innym protokole.

Polecenie grupy ESC może mapować indeks tablicy na konkretny actuator. Ta mapa jest częścią konfiguracji bezpieczeństwa. Po zmianie Node ID lub przewodu nie wolno zakładać, że kolejność fizyczna sama się odtworzy.

Dane diagnostyczne węzła uzupełniają, ale nie zastępują monitorowania FC. ESC może raportować nominalną temperaturę, a równocześnie przestać aktualizować timestamp — odbiorca sprawdza wiek.

Budżet magistrali#

Obciążenie oblicza się na poziomie ramek CAN z arbitrażem, bit stuffingiem, CRC, ACK i przerwą, nie tylko z sumy payloadów DSDL. Transfer wieloramkowy dodaje tail byte do każdej ramki oraz CRC transportowe.

Lista ruchu powinna zawierać dla każdego subject/service:

Transfer	Okres/burst	Maks. rozmiar	Priorytet	Deadline	Zachowanie po utracie
status węzła	okresowy	z DSDL	niski/nominalny	sekundy	oznacz offline
dane sensora	okresowy	z DSDL	wysoki	zależny od EKF	odrzuć stare
polecenie aktuatora	okresowy	z DSDL	krytyczny	krótki	failsafe węzła
parametry	burst	zmienny	niski	serwisowy	retry z limitem
plik firmware	długi burst	wieloramkowy	bardzo niski	serwisowy	wznów/anuluj

Najgorszy przypadek obejmuje synchroniczny start wielu węzłów, retransmisje CAN i transfer pliku. Aktualizacja firmware lub odczyt parametrów nie może zagłodzić poleceń i statusu.

Priorytet CAN pomaga tylko przed rozpoczęciem ramki. Długi fragment już obecny na przewodzie blokuje nową wiadomość przez swój czas. Kluczowe typy powinny być małe, a duże transfery mieć ograniczenie rate.

Implementacja bez dynamicznej alokacji#

Mały węzeł MCU może działać bez heap. Na etapie generowania DSDL znane są maksymalne rozmiary transferów. Projekt przydziela stałe bufory tylko dla subskrybowanych typów i ograniczonej liczby równoległych sesji.

Tablica RX przechowuje klucz sesji, ostatni transfer-ID, oczekiwany toggle, deadline i wskaźnik do bufora. Po timeout wpis wraca do puli. Brak wolnego wpisu zwiększa licznik i odrzuca transfer najniższego znaczenia, zamiast uszkadzać pamięć.

TX potrzebuje serializacji DSDL, fragmentacji i kolejki respektującej CAN ID. Dwa transfery z identycznym ID nie mogą przeplatać ramek. Przerwanie CAN jedynie przekazuje ramki między kontrolerem a kolejką; składanie dużych danych działa z ograniczonym budżetem CPU.

Fuzz testy podają ramki z każdym układem start/end/toggle, zawiniętym transfer-ID, błędnym CRC, maksymalnym payloadem i timeoutem. Parser nie może czytać poza bufor, niezależnie od CAN CRC i filtrów.

Warstwa sprzętowa#

DroneCAN dziedziczy wymagania CAN: liniowa skrętka, krótkie odgałęzienia, transceivery o zgodnym bitrate oraz dokładnie dwa terminatory na końcach. Rekomendacje sprzętowe projektu podają 87,5% jako preferowany sample point i zestaw typowych bitrate; konkretny profil musi być wspólny dla całej sieci.

Maksymalna długość maleje ze wzrostem bitrate, ponieważ sygnał musi przejść do najdalszego węzła i wrócić w budżecie arbitrażu. Tabele specyfikacji są granicami projektowymi przy założonych opóźnieniach, a nie gwarancją dla dowolnego transceivera, izolatora i gwiazdy. W UAV przewód jest zwykle krótki, więc większym problemem bywają stuby, złącza, common-mode i EMI.

Złącza JST-GH, M8 albo D-sub występują w różnych ekosystemach, ale kształt nie gwarantuje wspólnego pinoutu ani napięcia. Przed integracją ustala się CAN_H, CAN_L, masę, napięcie i kierunek zasilania.

Zasilanie magistralowe nie jest obowiązkiem transportu. Moduł może pobierać energię z przewodu albo mieć własną domenę. Budżet uwzględnia inrush, spadek napięcia, zabezpieczenia i zachowanie węzła bez zasilania. Nie wolno łączyć dwóch aktywnych szyn tylko dlatego, że oba porty nazywają się CAN.

Redundancja#

Specyfikacja przewiduje użycie redundantnych interfejsów CAN. Ten sam transfer może być dostępny na kilku fizycznych magistralach, lecz aplikacja musi scalać duplikaty i utrzymywać stan sesji odpowiednio do redundancji.

Rzeczywista redundancja wymaga:

osobnych kontrolerów i transceiverów;
osobnych par przewodów i złączy lub przynajmniej rozdzielonych torów awarii;
przeanalizowanego zasilania obu interfejsów;
braku wspólnego pojedynczego terminatora aktywnego;
testu zwarcia jednej pary bez wpływu na drugą;
deduplikacji transferów i spójnych timeoutów.

Dwie magistrale w jednym wspólnym kablu mogą nadal zostać przecięte równocześnie. Dwa porty tego samego transceivera nie chronią przed jego brownoutem. Analiza FMEA opisuje common-cause, nie tylko liczbę linii na schemacie.

Przy częściowym podziale sieci mogą powstać dwie grupy z różnym obrazem stanu. Flight controller musi określić, które dane akceptuje i czy rozbieżne sensory są faulted.

Interoperacyjność#

Najczęstsze przyczyny braku współpracy mimo prawidłowego CAN to:

DroneCAN kontra Cyphal/CAN;
inny bitrate lub sample point;
konflikt Node ID;
odmienna wersja albo fork definicji DSDL;
standardowy typ użyty z inną interpretacją jednostek;
typ vendor-specific bez opublikowanej definicji;
brak wymaganej usługi parametrów/aktualizacji;
zbyt mały limit transferu lub liczby sesji w implementacji;
sprzętowy filtr odrzucający właściwe ID.

Macierz zgodności zapisuje wersję firmware autopilota, urządzenia, DSDL i narzędzi. Aktualizacja jednego elementu przechodzi test regresji na rzeczywistym sprzęcie.

Vendor-specific status w NodeStatus nie ma wspólnego znaczenia między producentami. Oprogramowanie nie powinno na jego podstawie podejmować krytycznej decyzji bez właściwego profilu urządzenia.

Automatyczna detekcja bitrate może ułatwić uruchomienie, lecz stan nasłuchu, czas detekcji i zachowanie przy pustej magistrali trzeba znać. Węzeł nie powinien emitować błędnych ramek podczas zgadywania.

Bezpieczeństwo systemowe#

DroneCAN v0 nie zapewnia natywnego uwierzytelnienia, poufności ani ochrony przed replay w sensie kryptograficznym. Transfer-ID jest mały i służy porządkowi transportowemu, nie bezpieczeństwu.

Sieć pokładowa jest zatem strefą zaufania. Dostępne z zewnątrz złącze serwisowe powinno być fizycznie kontrolowane, a gateway z radia lub komputera pokładowego przepuszczać tylko dozwolone operacje. Nie należy bezwarunkowo routować każdej wiadomości z telemetrii na CAN.

Obrona w głąb obejmuje:

autoryzowany stan serwisowy dla zapisu parametrów i aktualizacji;
kryptograficzną weryfikację firmware w bootloaderze;
limity rate i rozmiaru transferów;
allowlist typów oraz docelowych węzłów w gatewayu;
watchdog i sanity checks poleceń aktuatorów;
logowanie zmian konfiguracji i wersji;
bezpieczne wartości po timeout.

CRC wykrywa przypadkowe błędy transmisji, nie potwierdza nadawcy. Fizyczne CAN ID również nie jest tożsamością kryptograficzną.

DroneCAN a MAVLink#

DroneCAN jest przede wszystkim siecią urządzeń pokładowych o małych, typowanych transferach oraz sprzętowym arbitrażu. MAVLink jest protokołem komunikatów często używanym między pojazdem, GCS, radiem i komputerem towarzyszącym przez UART, UDP, TCP lub inne transporty.

Typowa architektura:

sensory/ESC ← DroneCAN → autopilot ← MAVLink → radio/GCS

Granica nie jest absolutna: istnieją urządzenia i mosty dla obu protokołów. Nie należy jednak bezpośrednio utożsamiać heartbeat, parametrów i adresowania. Most musi mapować semantykę, jednostki, rate i stan błędów.

CAN daje arbitraż i wykrywanie błędów w warstwie łącza, lecz payload jest mały. MAVLink ma bogaty ekosystem telemetryczny i działa po wielu łączach, ale jego zachowanie zależy od transportu. Wybór wynika z miejsca w architekturze, nie rankingu „lepszy protokół”.

DroneCAN a Cyphal#

Cyphal kontynuuje ideę otwartej, rozproszonej komunikacji czasu rzeczywistego, lecz ma nowy model portów, typów regulowanych i transportów. Cyphal/CAN wykorzystuje 29-bitowe CAN ID, ale jego układ, transport i serializacja różnią się od DroneCAN.

Migracja wymaga:

nowego stosu i wygenerowanych typów;
mapy semantycznej danych;
sprawdzenia identyfikatorów portów i rejestrów;
zgodności narzędzi konfiguracyjnych;
bramy, jeśli oba ekosystemy mają działać równocześnie;
testów timingowych i pamięciowych.

Nie wystarczy zmienić nazwę namespace z UAVCAN na Cyphal. Brama dekoduje jeden transfer do modelu danych i koduje drugi, zamiast przepisywać surowy CAN ID.

Dla istniejącego sprzętu autopilotów DroneCAN ma szeroką bazę urządzeń. Dla nowej architektury Cyphal może oferować bardziej współczesny model, ale decyzja powinna opierać się na kompatybilności produktu, zasobach MCU i cyklu życia.

Diagnostyka i uruchomienie#

Najpierw uruchamia się CAN jako warstwę fizyczną, potem transport, na końcu typy aplikacyjne. Narzędzie DroneCAN GUI lub analizator korzystający z właściwych DSDL może pokazać węzły i wiadomości. Surowy analizator CAN potwierdzi ID, DLC i timing, lecz bez definicji nie zinterpretuje payloadu.

Procedura integracyjna:

przy wyłączonym zasilaniu potwierdź około 60 Ω CAN_H–CAN_L;
sprawdź pinout, napięcie i polaryzację wszystkich złączy;
uruchom autopilot oraz jeden węzeł ze znanym bitrate;
obserwuj NodeStatus i pobierz GetNodeInfo;
porównaj UID, Node ID, firmware i nazwę;
sprawdź standardowe typy danych i jednostki;
zmierz częstotliwość, wiek oraz jitter transferów;
zwiększ liczbę węzłów i wykryj konflikty ID;
uruchom parametry i aktualizację tylko w trybie serwisowym;
nasyć sieć transferem niskiego priorytetu i mierz deadline krytyczne;
odłącz/restartuj pojedynczy węzeł i jedną magistralę;
zweryfikuj timeout, degradację, recovery i log po restarcie.

Przy braku danych sprawdza się kolejno: fizyczny CAN, liczniki błędów, bitrate, format rozszerzony, filtry, NodeStatus, DSDL i subskrypcję. Przeskoczenie od razu do parsera może ukryć brak ACK albo bus-off.

Log integracyjny powinien zawierać co najmniej Node ID, UID, nazwę i wersję węzła, czas ostatniego statusu, health/mode, liczniki błędów CAN, utracone transfery, CRC transportu, overflow puli i zajętość magistrali.

Lista integracyjna#

Nazwa protokołu jednoznacznie wskazuje DroneCAN/UAVCAN v0.
Wszystkie węzły używają zgodnego DSDL i bitrate.
Node ID są unikalne, a role związane z UID.
CAN ID buduje biblioteka zgodnie ze specyfikacją.
Transport waliduje start/end/toggle, transfer-ID, timeout i CRC.
Bufory mają granice wynikające z maksymalnych typów.
Dwa transfery o tym samym ID nie są przeplatane.
Status węzła, GetNodeInfo i wiek danych są monitorowane.
Duże transfery mają niski priorytet i limit pasma.
Polecenia aktuatorów mają jawny timeout i bezpieczny stan.
Parametry trwałe są odczytywane zwrotnie po restarcie.
Firmware jest weryfikowany przez bootloader niezależnie od CRC CAN.
Gateway ogranicza dostęp z łączy zewnętrznych.
Redundancja została przetestowana przez fizyczne uszkodzenie jednej gałęzi.
Raport przed lotem zapisuje inwentarz węzłów i wersji.

Powiązane tematy#

Przypisy#

DroneCAN, Introduction — model protokołu, węzły, wiadomości, usługi i zgodność UAVCAN v0.
DroneCAN, CAN bus transport layer — 29-bitowy identyfikator, tail byte, transfer-ID, fragmentacja i CRC.
DroneCAN, Hardware design recommendations — bitrate, sample point, topologia, terminacja i złącza.
OpenCyphal, Cyphal Specification — współczesny protokół Cyphal oraz podstawa rozróżnienia od DroneCAN/UAVCAN v0.
Robert Bosch GmbH, CAN Specification Version 2.0 — warstwa CAN 2.0B używana przez DroneCAN.

Utworzono: 15 sierpnia 2026. Ostatnia aktualizacja: 15 sierpnia 2026. Źródła zweryfikowano: 15 sierpnia 2026.

Źródła z centralnego rejestru

DroneCAN Specification [specyfikacja protokołu]
DroneCAN: CAN bus transport layer [specyfikacja transportu]
DroneCAN: Hardware design recommendations [zalecenia sprzętowe protokołu]
OpenCyphal: Cyphal Specification [specyfikacja protokołu]