CAN w UAV może jednocześnie przenosić dane GNSS, magnetometru, airspeed, baterii, serw i ESC. Jego sygnał różnicowy, arbitraż i fault confinement są znacznie odporniejsze niż długa magistrala I²C, ale nie eliminują błędów instalacji. Jedna dodatkowa terminacja, gwiazda z długimi odgałęzieniami, wspólny spadek zasilania albo konflikt node ID może dać objawy od pojedynczych retransmisji po utratę wszystkich węzłów i stan bus-off.[1][2][6]

Diagnostyka ma dwie odrębne warstwy. CAN odpowiada za bity, ramki, ACK, CRC i liczniki błędów. DroneCAN/Cyphal odpowiadają za identyfikatory transferów, typy danych, node status, dynamic allocation, subskrypcje i konfigurację węzłów. Poprawna ramka CAN nie gwarantuje, że autopilot subskrybuje właściwą wiadomość; widoczny węzeł DroneCAN nie gwarantuje, że jego sensor publikuje poprawne dane.

Spis treści#

Warstwy problemu#

Praktyczny stos:

funkcja UAV: GNSS / ESC / bateria / airspeed
DroneCAN: typ danych, transfer-ID, node status, usługi
CAN 2.0B: ID, DLC, dane, CRC, ACK, error frames
kontroler CAN: FIFO, filtry, TEC/REC, bus-off
transceiver: dominant/recessive, common-mode, standby
wiązka: CAN_H, CAN_L, masa/zasilanie, terminatory

Każdy objaw przypisuje się do najniższej warstwy, na której dowody przestają być poprawne. Jeżeli między H i L przy wyłączonym zasilaniu nie ma oczekiwanej rezystancji, nie zaczyna się od zmiany subskrypcji GPS. Jeżeli sygnał i ramki są poprawne, a NodeStatus przychodzi, wtedy analizuje się typ publikowanych wiadomości i konfigurację autopilota.

Ważne rozróżnienia:

  • node offline — brak aktualnego statusu/transferów;
  • node online, health warning/error — komunikacja działa, urządzenie zgłasza problem;
  • node online, sensor absent — warstwa protokołu działa, ale funkcja nie publikuje lub nie jest subskrybowana;
  • bus-off kontrolera — transceiver/controller wycofał się po nadmiarze błędów;
  • brak ACK — nadajnik może być jedynym aktywnym uczestnikiem lub inni nie rozpoznają ramek z powodu bit timingu/fizyki.

Sygnał różnicowy#

CAN reprezentuje stan dominant i recessive przez różnicę między CAN_H i CAN_L. Odbiornik reaguje głównie na:

[ V{diff} = V{CANH} - V_{CANL} ]

Zakłócenie wspólne podnoszące obie linie podobnie powinno częściowo się skasować. To wymaga skręconej pary, właściwego transceivera i utrzymania common-mode w zakresie odbiornika.

Sygnał różnicowy nie znosi dowolnej różnicy potencjałów mas. Transceiver ma dopuszczalny common-mode. Długi UAV z silnymi prądami może mieć spadek masy między końcami; przewód odniesienia/ekran i architektura zasilania muszą być zgodne z zaleceniami hardware DroneCAN.[5]

CAN nie używa modelu „jeden TX, jeden RX” jak UART. Wszystkie węzły słuchają wspólnej pary, a dominant wygrywa nad recessive. Zwarcie jednej linii, uszkodzony transceiver albo stale dominant może wyłączyć całą domenę.

CAN H, CAN L i common-mode#

W typowym high-speed CAN stan recessive ma obie linie blisko wspólnego poziomu, a dominant rozsuwa je: CAN_H rośnie, CAN_L maleje. Dokładne poziomy i progi bierze się z datasheet transceivera, nie z jednego wykresu internetowego.

Mierzy się:

  • napięcie każdej linii do lokalnej masy;
  • sygnał różnicowy H–L;
  • common-mode ((V_H+V_L)/2);
  • overshoot i undershoot;
  • ringing po zboczu;
  • różnicę między początkiem i końcem wiązki;
  • napięcie zasilania transceiverów.

Multimetr na aktywnym busie pokazuje wartości uśrednione. Dwie „sensowne” wartości nie dowodzą poprawnego różnicowego przebiegu. Oscyloskop z matematycznym CH1–CH2 albo sondą różnicową jest właściwym narzędziem.

Terminacja#

Klasyczna magistrala liniowa ma 120 Ω na obu fizycznych końcach, co przy wyłączonym zasilaniu daje około:

[ R_{HL} = 120\,\Omega \parallel 120\,\Omega \approx 60\,\Omega ]

PX4 również opisuje dwa terminatory 120 Ω na końcach łańcucha.[6] Niektóre FC i GNSS mają terminację wbudowaną, czasem konfigurowalną. Należy zinwentaryzować faktyczny stan, nie liczbę wtyczek.

Interpretacja pomiaru orientacyjnego:

CAN_H–CAN_L, power off Możliwa sytuacja
około 60 Ω dwa terminatory 120 Ω
około 120 Ω jeden terminator
około 40 Ω trzy terminatory
bardzo wysoko/open brak terminacji lub przerwa
blisko 0 Ω zwarcie albo nietypowy układ ochronny

Pomiar może być zmieniony przez aktywne terminatory, transceivery, TVS i inne ścieżki. Dokumentacja urządzeń rozstrzyga. Terminator nie powinien znajdować się „przy każdym urządzeniu”.

Brak terminacji powoduje odbicia; za dużo terminacji nadmiernie obciąża nadajniki i zmniejsza amplitudę. Oba przypadki mogą działać na krótkim stole przy małym bitrate, a zawodzić po dodaniu wiązki.

Topologia i stuby#

CAN projektuje się jako liniowy trunk z krótkimi odgałęzieniami. Dwa porty w peryferium ułatwiają daisy-chain, ale elektrycznie są zwykle połączone równolegle. Gwiazda ze splittera tworzy kilka stubów i punkty odbicia.

Znaczenie długości stubu rośnie z bitrate i szybkością zbocza. Nie wystarczy porównać z długością całej ramy; ważny jest czas propagacji względem bit time oraz położenie sample point. Zalecenia DroneCAN ograniczają topologię i wymagają terminacji końców.[5]

Typowe błędy:

  • FC w środku ma wbudowany terminator, a oba końce również;
  • GNSS z włączonym terminatorem jest bocznym stubem, nie końcem;
  • pasywny hub tworzy gwiazdę;
  • redundantne CAN1 i CAN2 przypadkowo zwarte przez adapter;
  • długi odcinek do payloadu kończy się bez terminacji;
  • ekran podłączony w sposób tworzący pętlę prądową.

Przewody i złącza#

CAN_H i CAN_L powinny tworzyć kontrolowaną skręconą parę. Zasilanie urządzeń może iść tym samym złączem, lecz prąd zasilania nie powinien płynąć sygnałową parą ani powodować dużej różnicy mas.

JST-GH w standardzie Pixhawk ma mały rozmiar i blokadę, ale jakość zacisku jest krytyczna. Pojedyncza żyła częściowo wyrwana może dawać błędy tylko przy drganiach. Test ciągłości bez poruszania wiązką nie wykrywa tego.

Kontrola:

  • pinout obu końców — różni producenci mogą użyć innej kolejności;
  • skręt nieprzerwany długo przy złączu;
  • strain relief;
  • brak równoległego prowadzenia przy fazach silnika;
  • promień gięcia i ścieranie;
  • ekran zgodny z projektem EMC;
  • prąd i spadek napięcia zasilania peryferiów;
  • brak zasilania wstecznego przez CAN/ESD.

Bitrate i sample point#

Wszystkie węzły na jednym segmencie muszą używać zgodnego nominalnego bitrate. CAN nie przesyła zegara osobną linią; odbiorniki synchronizują się ze zboczami. Bit timing obejmuje prescaler, segmenty czasowe, sample point i SJW.[1][2]

Zły bitrate zwykle daje lawinę error frames, brak ACK i wzrost liczników. Zbliżony, ale niezgodny sample point może działać na krótkiej wiązce, a zawodzić przy temperaturze lub długości.

Autobaud w bootloaderze DroneCAN może dobrać prędkość na podstawie ruchu, ale pusty bus bez nadajnika nie daje wzorca. Bootloader i aplikacja mogą mieć różne zachowanie. Przy diagnostyce zapisuje się bitrate na FC, węzłach i narzędziu sniffera.

CAN FD dodaje data phase bitrate i inne wymagania transceivera. DroneCAN v0 używa klasycznego CAN 2.0B; nie zakłada się FD tylko dlatego, że kontroler MCU je obsługuje.

Arbitraż#

Węzły mogą rozpocząć transmisję jednocześnie. Dominant bit o niższym numerycznie ID wygrywa, a przegrywający przestaje nadawać bez uszkodzenia ramki zwycięzcy.[1]

Konsekwencje:

  • ID pełni funkcję priorytetu;
  • wysoki bus load zwiększa latency ramek o niższym priorytecie;
  • „brak kolizji” nie oznacza stałego czasu dostarczenia;
  • błędny flood wysokopriorytetowych ramek może zagłodzić inne funkcje;
  • sniffer musi rejestrować timestampy i rozkład ID.

DroneCAN koduje priorytet i informacje transferu w 29-bitowym identyfikatorze. Nie przypisuje się dowolnych CAN ID bez rozumienia transport layer.[4]

ACK i retransmisja#

Nadajnik wysyła recessive w ACK slot, a co najmniej jeden poprawnie odbierający węzeł ściąga dominant. Brak ACK nie oznacza, że odbiornik aplikacyjny „nie lubi wiadomości”; ACK jest na warstwie CAN i potwierdza poprawną ramkę.

Jeżeli na busie jest tylko jeden aktywny węzeł, jego ramki nie dostaną ACK. Controller retransmituje, zwiększa TEC i może wejść bus-off. Pasywny sniffer w silent/listen-only nie ACKuje — to celowe, ale nadajnik potrzebuje innego aktywnego uczestnika.

Brak ACK może wynikać z:

  • inne węzły bez zasilania/standby;
  • zły bitrate;
  • uszkodzona para/terminacja;
  • filtr/tryb transceivera nie ma wpływu na podstawowy ACK, ale listen-only ma;
  • jedyny drugi węzeł również nie rozpoznaje ramek;
  • złe FD/classic mode.

Error frames#

CAN wykrywa bit error, stuff error, CRC error, form error i ACK error.[1] Węzeł error-active sygnalizuje active error flag, przerywając błędną ramkę. Nadajnik spróbuje ponownie.

Sniffer może pokazać:

  • pojedyncze error frames po uruchomieniu;
  • regularne błędy przy konkretnym ID;
  • burst errors po włączeniu ESC;
  • ciąg ACK errors bez innych węzłów;
  • stuff/form errors przy złym bitrate/EMI.

Sam licznik ramek poprawnych może pozostać wysoki mimo rosnącej liczby retransmisji. Latency i bus occupancy pogarszają się zanim funkcja przestanie działać. Dlatego error counters są metryką zdrowia.

TEC, REC i fault confinement#

Kontroler utrzymuje Transmit Error Counter i Receive Error Counter. Reguły przyrostu/spadku zależą od rodzaju błędu i roli węzła; Bosch M_CAN implementuje te stany i raportuje liczniki/status.[2]

Interpretacja:

  • rośnie głównie TEC jednego węzła — jego transmisje nie są ACKowane lub sam wysyła błędnie;
  • rośnie REC wielu węzłów równocześnie — wspólna fizyka/EMI/bit timing;
  • jeden węzeł ma REC, inne czyste — lokalny transceiver/odgałęzienie;
  • counters wracają po poprawnych ramkach — transient, ale trend nadal istotny;
  • TEC osiąga próg bus-off — węzeł odłącza transmisję, by nie niszczyć sieci.

Warto logować maksimum i przyrost na minutę, nie tylko stan końcowy. Reset kontrolera zeruje liczniki i może ukryć historię.

Error-active, error-passive i bus-off#

Fault confinement ogranicza wadliwy węzeł:

ERROR_ACTIVE -> ERROR_PASSIVE -> BUS_OFF

Error-passive nadal uczestniczy, ale używa passive error flag i ma ograniczenia. Bus-off przestaje zakłócać sieć. Powrót wymaga warunków określonych przez kontroler/firmware i obserwacji wystarczającej liczby recessive bitów.[1][2]

Automatyczny natychmiastowy restart po bus-off może stworzyć pętlę reset–błąd–reset. Lepsza polityka:

  • zapisać przyczynę, TEC/REC i timestamp;
  • odczekać kontrolowany czas bus idle;
  • wykonać limitowaną liczbę prób;
  • po powtórzeniu oznaczyć interfejs failed;
  • przełączyć redundancję lub failsafe zależnie od funkcji;
  • utrzymać maintenance flag po lądowaniu.

Obciążenie magistrali#

Bus load obejmuje nie tylko payload bytes, ale ID, control, CRC, ACK, intermission, bit stuffing i retransmisje. Przybliżenie liczy liczbę bitów wszystkich ramek w oknie do bitrate.

Wysokie obciążenie powoduje:

  • większe opóźnienie niskopriorytetowych transferów;
  • kolejki TX/FIFO overflow;
  • utratę deadline sensorów;
  • dłuższe aktualizacje firmware;
  • większy koszt każdej retransmisji;
  • zagłodzenie NodeStatus/diagnostyki.

PX4 zaleca osobny interfejs dla DroneCAN ESC, ponieważ ruch sterujący i telemetria mogą nasycać bus i zagłodzić inne węzły.[7] Krytyczne komendy napędu nie powinny dzielić niezaplanowanego bandwidth z dużym streamem danych payloadu.

DroneCAN node ID#

Node ID identyfikuje uczestnika w transferach DroneCAN. Statyczne ID muszą być unikalne. Dwa węzły o tym samym ID mogą generować niepoprawne sekwencje transfer-ID, konflikty usług i pozornie „migające” dane.

Node ID nie jest tożsamy z fizycznym portem ani numerem silnika. ESC mapping ma osobną semantykę. Nie zmienia się ID, by „dopasować kolejność”, jeśli protokół/firmware ma właściwy parametr indeksu aktora.

Inwentaryzacja floty powinna przechowywać:

  • node ID;
  • unikalny hardware UID/serial;
  • vendor/model;
  • hardware/firmware version;
  • funkcje (GPS, mag, ESC itd.);
  • port CAN1/CAN2;
  • stan terminacji.

PX4 potrafi logować device information, w tym serial i wersje, co wspiera traceability i diagnostykę.[6]

Dynamic node allocation#

Węzeł z ID 0 może poprosić allocator o przydział na podstawie unikalnego ID. Bootloader DroneCAN często również korzysta z dynamic allocation.[7]

Problemy:

  • allocator nie działa/nie ma wymaganej pamięci;
  • dwa allocatory lub błędna konfiguracja;
  • węzeł nie ma poprawnego unique ID;
  • bus load/opóźnienie przerywa sekwencję;
  • bootloader dostaje ID, aplikacja startuje inaczej;
  • statyczny konflikt po migracji z dynamic.

PX4 w starszych konfiguracjach wymagał sprawnej karty SD dla DNA i aktualizacji; stan należy sprawdzać dla używanej wersji. Nie przenosi się ślepo instrukcji v1.14 na main/stable.

NodeStatus#

DroneCAN uavcan.protocol.NodeStatus niesie uptime, health, mode, submode i vendor-specific status. PX4 mapuje to na DronecanNodeStatus z poziomami OK/WARNING/ERROR/CRITICAL oraz trybami OPERATIONAL, INITIALIZATION, MAINTENANCE, SOFTWARE_UPDATE i OFFLINE.[8]

Diagnostyczne wzorce:

  • uptime regularnie wraca do zera → reset/power dip/watchdog;
  • health WARNING przy ciągłej komunikacji → błąd funkcjonalny, nie bus;
  • node zostaje w INITIALIZATION → brak konfiguracji/sensora;
  • MAINTENANCE po locie → tryb kalibracji/bootloader;
  • status znika, inne węzły działają → lokalna gałąź/zasilanie;
  • wszystkie statusy znikają → wspólny bus/FC.

Vendor-specific code trzeba dekodować z dokumentacji producenta. Nie prezentuje się go jako uniwersalnego błędu DroneCAN.

Subskrypcje i publikacje#

W PX4 podłączenie węzła nie automatycznie włącza wszystkie strumienie. Parametry UAVCAN_SUB_* i UAVCAN_PUB_* kontrolują subskrypcje/publikacje; dokumentacja wskazuje m.in. GPS, MAG, BARO, range, flow, battery, RTCM i arming status.[7]

Objaw „węzeł widać w uavcan status, ale GPS nie działa” może oznaczać:

  • subskrypcja GPS wyłączona;
  • node publikuje inny typ;
  • sensor wewnątrz node nie wystartował;
  • data rate zero;
  • instance mapping odrzuca źródło;
  • estimator nie fuzuje mimo poprawnego topicu.

Kolejność dowodów:

  1. NodeStatus online;
  2. transfery odpowiedniego data type na busie;
  3. topic w autopilocie aktualizuje się;
  4. sensor health poprawny;
  5. estimator source/fusion aktywna.

Firmware i bootloader#

DroneCAN wspiera aktualizacje firmware po busie. Bootloader musi rozpoznać bitrate, uzyskać node ID, znaleźć plik i uruchomić zweryfikowaną aplikację.[7]

Problemy:

  • node pozostaje w bootloaderze;
  • plik dla złego hardware ID;
  • update zapętla się po utracie zasilania;
  • aplikacja i bootloader mają niezgodne parametry CAN;
  • flota ma różne wersje publikujące inne message semantics;
  • jednoczesny update zwiększa bus load.

Nie aktualizuje się wszystkich ESC przed lotem bez planu rollback i testu pojedynczej sztuki. Asset tracking pozwala wykryć niespójność wersji.[6]

Redundancja CAN#

Drugi CAN zwiększa odporność tylko wtedy, gdy urządzenia mają dwa niezależne interfejsy/transceivery, wiązki i sensowną logikę failover. PX4 opisuje opcjonalną redundantną sieć na CAN2.[6]

Wspólne przyczyny nadal mogą obejmować:

  • jedno zasilanie wszystkich węzłów;
  • wspólny MCU aplikacyjny w urządzeniu;
  • przewody CAN1/CAN2 w tej samej uszkodzonej wiązce;
  • ten sam błąd firmware;
  • obie terminacje skonfigurowane niepoprawnie;
  • jedna wtyczka łącząca obie domeny.

Test failover fizycznie rozłącza jedną parę i sprawdza ciągłość danych/latency. Sam fakt obecności dwóch portów nie jest dowodem.

Objaw: zero węzłów#

Sprawdź w kolejności:

  1. czy driver CAN/DroneCAN jest włączony na właściwym porcie;
  2. zasilanie FC i peryferiów z baterii, nie tylko USB;
  3. pinout i zamianę H/L;
  4. rezystancję H–L przy power off;
  5. idle/common-mode i aktywność oscyloskopem;
  6. bitrate;
  7. standby/enable transceivera;
  8. czy controller nie jest bus-off;
  9. uavcan status / bus monitor;
  10. jeden znany węzeł na krótkiej wiązce.

Zamiana H/L w high-speed CAN zwykle uniemożliwia komunikację, choć poziomy do masy mogą wyglądać „żywo”. Pomiar różnicowy i dokumentacja pinów rozstrzygają.

Jeśli FC wysyła, ale nie ma drugiego aktywnego węzła, zobaczysz ACK errors i retransmisje. Jeśli nie wysyła nic, problem jest w konfiguracji/driverze/trybie transceivera.

Objaw: jeden węzeł znika#

Porównaj NodeStatus uptime przed zniknięciem. Jeśli po powrocie uptime jest niski, node się zresetował. Jeśli uptime kontynuuje, możliwy jest transient bus, queue lub filtr.

Testy:

  • zamiana portów/przewodu z działającym węzłem;
  • pomiar rail przy węźle;
  • poruszanie złączem pod monitoringiem;
  • lokalny terminator off/on zgodnie z pozycją;
  • error counters transceivera/controllera;
  • temperatura i reset reason;
  • firmware version.

Nie zakładaj, że „CAN jest wspólny, więc wszystkie muszą znikać”. Uszkodzony stub może odcinać lokalny węzeł bez pełnego collapse, zwłaszcza przy przerwie, a nie zwarciu.

Objaw: działa na stole, nie działa z napędem#

Równocześnie rejestruj:

  • CAN_H/L i różnicę;
  • common-mode;
  • rail zasilający node/transceiver;
  • throttle/RPM/prąd;
  • TEC/REC/error frames;
  • NodeStatus uptime.

Jeśli uptime resetuje się — zasilanie/watchdog. Jeśli uptime trwa, ale error frames rosną z RPM — EMC/topologia. Jeśli tylko jeden node ma problem — lokalna gałąź/masa. Jeśli wszystkie — trunk/common power.

Zmniejszenie bitrate może chwilowo zwiększyć margines, ale nie jest wystarczającą naprawą dla zwarcia, złej terminacji czy rail dip. Wynik służy jako eksperyment diagnostyczny.

Objaw: rosną błędy bez utraty danych#

To wczesne ostrzeżenie. Retransmisja ukrywa błąd przed aplikacją, ale zwiększa latency i bus load. Ustal:

  • typ error frame;
  • które ID/transmitter;
  • położenie w czasie;
  • TEC/REC per controller;
  • zależność od temperatury/RPM;
  • margines amplitudy i ringing.

Acceptance criteria powinny określać maksymalny error rate w teście, a nie tylko „brak utraty node”. Dla krytycznej sieci nieoczekiwane błędy w nominalnych warunkach wymagają wyjaśnienia.

Objaw: bus-off#

Bus-off jest skutkiem, nie przyczyną. Przed resetem zachowaj:

  • last error code/protocol status;
  • TEC/REC;
  • timestamp i tryb lotu;
  • bitrate i controller instance;
  • error frame trace;
  • rail/min voltage;
  • lista online nodes.

Jeżeli natychmiastowy restart wraca bus-off, odłącz transmisję i przejdź do failover/failsafe. W locie nie można bez końca restartować CAN sterującego ESC. Polityka zależy od tego, czy napęd ma redundancję i jak zachowa się po utracie komend.

Po lądowaniu sprawdź 60 Ω, wiązkę i jeden węzeł. Reset logu bez danych pre-fault uniemożliwia RCA.

Objaw: węzeł jest online, danych brak#

NodeStatus dowodzi tylko warstwy zarządzania. Sprawdź:

  • health i mode;
  • czy node publikuje oczekiwany data type ID;
  • częstotliwość transferów;
  • transfer-ID rośnie;
  • multi-frame CRC poprawny;
  • subskrypcja autopilota;
  • instance/device ID;
  • sensor status w node;
  • estimator fusion.

PX4 nie subskrybuje wszystkich message types domyślnie, by nie obciążać busu.[7] Włączenie subskrypcji może ujawnić parametry/funkcję dopiero po reboot.

Objaw: konflikt node ID#

Możliwe symptomy:

  • jedna pozycja w liście z danymi dwóch modeli;
  • uptime skacze wstecz bez resetu zasilania;
  • service response trafia do złego urządzenia;
  • transfer-ID discontinuities;
  • aktualizacja firmware niewłaściwego node;
  • naprzemienne serial numbers.

Rozwiązanie: odłączać urządzenia pojedynczo, odczytać UID i ustawić unikalne static ID lub wrócić do sprawnego dynamic allocation. PX4 dokumentuje zakres 1–127 i ostrzega przed duplikatami static ID.[7]

Narzędzia#

  • schemat i pinout całej sieci;
  • multimetr;
  • oscyloskop 2–4 kanały/sonda różnicowa;
  • aktywny interfejs CAN z możliwością listen-only;
  • DroneCAN GUI/bus monitor lub narzędzia autopilota;
  • zasilacz z limitem prądu;
  • breakout JST-GH;
  • terminatory 120 Ω o znanej wartości;
  • fixture do przerwy/zwarcia/fault injection;
  • logger NodeStatus/device info/error counters.

Interfejs USB-CAN nie może dodawać trzeciej terminacji bez świadomości. Wiele adapterów ma przełączany terminator. Tryb listen-only nie ACKuje; tryb normalny wpływa na sieć i może maskować brak innych odbiorników.

Multimetr#

Przy power off:

  • H–L resistance;
  • H/GND, L/GND pod kątem zwarć;
  • ciągłość trunk i stubów;
  • izolacja CAN1/CAN2.

Przy power on:

  • rail na każdym końcu;
  • idle H/L do masy;
  • spadek masy między końcami (ostrożnie i zgodnie z architekturą);
  • prąd segmentu.

Nie mierzy się rezystancji na zasilonym busie. Kondensatory/TVS mogą chwilowo zmieniać wskazanie; poczekaj na stabilizację i porównaj z dokumentacją.

Oscyloskop różnicowy#

Najlepiej mierzyć H, L, H–L i rail. Punkty przy obu końcach ujawniają odbicia. Trigger:

  • amplituda poniżej progu;
  • długi dominant;
  • rail dip;
  • error flag pattern;
  • burst po włączeniu ESC.

Sonda różnicowa musi mieć właściwy common-mode i bandwidth. Dwie sondy pasywne wymagają identycznych ustawień oraz krótkich mas; funkcja odejmowania może wzmacniać błąd niezrównoważonych kanałów.

Ocenia się:

  • amplitudę dominant;
  • poziom recessive;
  • crossing/symetrię;
  • ringing do sample point;
  • czas propagacji;
  • common-mode shift;
  • zbocza przy różnych node/transmitter.

Interfejs CAN i sniffer#

Capture powinien zawierać raw CAN ID, DLC, payload, timestamp, error frames i bus load. Następnie dekoder DroneCAN interpretuje transfery.

Tryby:

  • listen-only — brak ACK i transmisji, minimalny wpływ;
  • normal — ACKuje i może wysyłać usługi;
  • loopback — test lokalnego kontrolera, nie wiązki;
  • silent loopback — zależny od kontrolera.

Jeżeli jedyny node nadaje i sniffer jest listen-only, zobaczysz retransmisje/ACK error. Dodanie normalnego adaptera „naprawi” ACK, ale nie dowiedzie obecności docelowego odbiornika.

Procedura diagnostyczna#

1. Inwentaryzacja#

Narysuj fizyczny trunk, stuby, terminatory, porty, zasilanie, node ID, wersje firmware i bitrate.

2. Power-off checks#

R_HL, przerwy, H/L swap, CAN1–CAN2 isolation.

3. Minimalna sieć#

FC + jeden znany node + dwa właściwe terminatory + krótka para.

4. Warstwa fizyczna#

Oscyloskop: dominant/recessive, common-mode, ringing, ACK/error frames.

5. Kontroler#

Driver enabled, bitrate, TEC/REC, protocol status, bus-off state.

6. CAN trace#

Czy są poprawne ramki, jakie ID, bus load i retransmisje.

7. DroneCAN#

NodeStatus, node ID, uptime, health, mode, data types, transfer rates.

8. Autopilot#

Subskrypcje, topics, sensor health, estimator/actuator mapping.

9. Skalowanie#

Dodawaj węzły i docelowy ruch. Mierz load i latency.

10. Środowisko#

Napęd, wibracje, temperatura, RF i movement wiązki.

11. Fault injection#

Przerwa, node reset, odłączenie CAN1, bus-off w symulatorze/fixture — zgodnie z safety plan.

Recovery#

Recovery CAN jest inny niż I²C. Nie generuje się „dziewięciu zegarów”. Controller wykonuje procedurę wyjścia bus-off po spełnieniu warunków idle, ponownie inicjalizuje filtry/FIFO i weryfikuje NodeStatus.

Maszyna stanów:

ACTIVE
 -> ERROR_WARNING
 -> ERROR_PASSIVE
 -> BUS_OFF
 -> WAIT_IDLE
 -> REINIT_ATTEMPT_n
 -> ACTIVE or FAILED

Każde przejście loguje counters. Po powrocie:

  • nie uznawaj danych za healthy po jednej ramce;
  • wymagaj stabilnego NodeStatus i streamu przez czas;
  • sprawdź uptime, wersję i mapping;
  • wykonaj bumpless source/actuator reintegration;
  • utrzymaj maintenance alert.

Testy fault injection#

Bezpieczne stanowisko/HIL:

  • odłączenie jednego node;
  • reset/power-cycle node;
  • przerwa CAN_H lub CAN_L;
  • usunięcie terminatora;
  • dodatkowy terminator;
  • konflikt static node ID;
  • flood niskopriorytetowych ramek;
  • flood wysokopriorytetowych ramek;
  • zły bitrate jednego node;
  • bus-off controllera przez kontrolowany fixture;
  • utrata CAN1 przy redundant CAN2;
  • update firmware przerwany zasilaniem na development node.

Nie zwiera się losowo aktywnej magistrali latającego statku. Fixture ma ograniczenie prądu i odseparowane aktory. Celem jest sprawdzenie logiki, nie narażenie ludzi.

Kryteria:

  • czas detekcji;
  • poprawny failsafe/failover;
  • brak blokady scheduler;
  • bounded recovery;
  • identyfikowalny log;
  • brak automatycznego ponownego uzbrojenia aktora;
  • powtarzalność po N cyklach.

Logowanie i maintenance#

Per interface:

  • TEC/REC/current error state;
  • bus-off count;
  • last error code;
  • RX/TX/error frame counts;
  • FIFO overflow;
  • bus load/max latency;
  • recovery count/result;
  • bitrate i interface ID.

Per node:

  • node ID i unique hardware ID;
  • uptime, health, mode, vendor code;
  • last-seen age;
  • firmware/hardware version;
  • expected vs actual publications;
  • reset count;
  • sensor/ESC-specific fault codes.

Fleet maintenance porównuje wersje i trendy. Jeden node z rosnącym REC może mieć pogarszający się transceiver/złącze, zanim zacznie znikać. PX4 device information może utrwalać serial/wersje w logach.[6]

Typowe błędy#

  1. Terminator przy każdym urządzeniu. Efektywna rezystancja jest za niska.
  2. Jeden terminator, bo „bus jest krótki”. Margines zależy od topologii i bitrate.
  3. Gwiazda z długich stubów. Odbicia trafiają w sample point.
  4. Pomiar tylko multimetrem. Nie pokazuje różnicowego przebiegu i error frames.
  5. Listen-only sniffer jako jedyny drugi node. Nie daje ACK.
  6. NodeStatus = poprawne dane. To tylko health/mode warstwy node.
  7. Węzeł online, subskrypcja wyłączona. Autopilot nie tworzy funkcji automatycznie.[7]
  8. Dwa static node ID takie same. Transfery i usługi konfliktują.
  9. ESC i wszystkie sensory na nasyconym busie. Krytyczne ramki mają latency.
  10. Natychmiastowy reset po bus-off bez limitu. Powstaje pętla awarii.
  11. CAN1 i CAN2 w jednej wspólnej parze. Redundancja jest pozorna.
  12. Zasilanie node tylko z USB FC. Peryferia mogą nie mieć rail podczas testu.
  13. Zamiana H/L. Aktywność napięciowa nie oznacza dekodowalnej ramki.
  14. Firmware update całej floty bez inventory/rollback. Utrata zgodności funkcji.
  15. Brak logowania TEC/REC. Retransmisje ukrywają rozwijającą się usterkę.

Powiązane tematy#

Przypisy#

  1. Bosch, „CAN Specification Version 2.0” — ramki, arbitraż, ACK, wykrywanie błędów i fault confinement.
  2. Bosch, „M_CAN Controller Area Network User’s Manual” — liczniki błędów, protocol status, error-passive i bus-off kontrolera.
  3. DroneCAN, „Specification” — model node, wiadomości i usługi.
  4. DroneCAN, „CAN bus transport layer” — 29-bit ID, transfer-ID, ramki wieloczęściowe i CRC.
  5. DroneCAN, „Hardware design recommendations” — transceivery, topologia, terminacja i okablowanie.
  6. PX4, „CAN (DroneCAN & Cyphal)” — bieżąca architektura portów, daisy-chain, dwa terminatory i redundancja; sprawdzono 16 sierpnia 2026 r.
  7. PX4, „DroneCAN” — subskrypcje/publikacje, konfiguracja urządzeń, oddzielny bus ESC i firmware node; sprawdzono 16 sierpnia 2026 r.
  8. PX4, DronecanNodeStatus — pola uptime, health, mode, submode i vendor-specific status.

Powiązane tematy

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.DroneCAN, UAVCAN v0 i CyphalRozróżnienie rodzin protokołu oraz praktyczna anatomia DroneCAN: message/service transfers, 29-bit CAN ID, multi-frame CRC, DSDL, node health, dynamic allocation i redundancja.Diagnostyka magistrali I²C w UAVPraktyczna diagnostyka I²C w flight controllerze: warstwa elektryczna open-drain i obliczanie pull-up, pojemność i rise time, START/STOP/ACK/NACK, clock stretching i arbitration, adresy 7-bit, i2cdetect, oscyloskop i analizator logiczny, bus occupancy, stuck SDA/SCL, dziewięć impulsów bus clear, reset/power-cycle peryferium, segmentacja magistral, fault containment i analiza błędów sensorów w logach.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.Przewody i złącza w UAVProjekt wiązki UAV od bilansu prądowego i spadków napięcia przez dobór złączy i zacisków po ekranowanie, odciążenie mechaniczne, kontrolę jakości oraz dokumentację pinoutów.EMI/EMC w kontrolerze lotuEMI/EMC flight controllera jako problem obwodów i pól: pętle di/dt, węzły dv/dt, powroty prądów, sprzężenia przewodzone i promieniowane, ochrona portów oraz plan testów przedzgodnościowych.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ść.Diagnostyka logów i wibracjiPraktyczny proces diagnostyczny: synchronizacja czasu, setpoint kontra measurement, widmo drgań, saturacja i rozróżnianie awarii mechanicznej od problemu regulatora.

Źródła z centralnego rejestru

  1. Bosch: CAN Specification Version 2.0 [specyfikacja protokołu]
  2. Bosch M_CAN Controller Area Network User’s Manual [dokumentacja kontrolera CAN/CAN FD]
  3. DroneCAN Specification [specyfikacja protokołu]
  4. DroneCAN: CAN bus transport layer [specyfikacja transportu]
  5. DroneCAN: Hardware design recommendations [zalecenia sprzętowe protokołu]
  6. PX4 Guide: CAN (DroneCAN & Cyphal) [dokumentacja projektu open source]
  7. PX4 Guide: DroneCAN configuration and subscriptions [dokumentacja projektu open source]
  8. PX4 uORB: DronecanNodeStatus message [dokumentacja modelu danych projektu]