Holybro Durandal — profil techniczny

Holybro Durandal jest zintegrowanym kontrolerem lotu klasy H7, zaprojektowanym przed ujednoliceniem bieżących wariantów FMUv6. Łączy STM32H743 jako główny FMU, osobny procesor I/O, dwa IMU różnych producentów, ogrzewanie sensorów i mechaniczny układ izolacji drgań. Jest wspierany przez PX4 i ArduPilot, ale w dokumentacji znajduje się kilka rozbieżności — dlatego profil konkretnego egzemplarza trzeba ustalić z pinoutu, hardware revision, boot logu i testu, a nie z jednej tabeli w Internecie.

Durandal nie jest modułem PAB ani Cube. Ma własną obudowę i komplet złączy, dzięki czemu integrator otrzymuje gotowy controller, lecz nie może wymienić samego FMU na nowszą generację przy zachowaniu baseboardu. W porównaniu z lekkimi FC dla FPV jest większy i cięższy, za to oferuje osobny I/O, rozbudowane porty, dwa power monitor inputs oraz mechaniczną i termiczną kontrolę sensorów.

Spis treści#

Pozycja produktu
Dane podstawowe
Rozbieżności w dokumentacji
Procesor FMU
Procesor IO
IMU ICM 20689 i BMI088
Izolacja drgań
Ogrzewanie IMU
Barometr i magnetometr
Pamięć i logowanie
Porty szeregowe
I2C SPI i CAN
Wejścia RC
Wyjścia i grupy timerów
DShot i DMA
GPIO i capture
Zasilanie kontrolera
Servo rail
Power modules i pomiar baterii
Zasilanie peryferiów
PX4 i ArduPilot
Montaż mechaniczny
Plan portów
Bring up
Testy sensorów
Testy zasilania
Testy wyjść i failsafe
Lifecycle i utrzymanie
Kryteria doboru
Typowe błędy
Powiązane tematy
Przypisy

Pozycja produktu#

Durandal jest klasyfikowany przez PX4 jako kontroler manufacturer-supported, a nie Pixhawk Standard Autopilot.[7] To nie ocena jakości: PX4 wyjaśnia, że produkty manufacturer-supported mogą być równie dobre lub lepsze, lecz ich utrzymanie i testowanie nie jest tym samym zobowiązaniem co platform referencyjnych.[7]

Holybro podaje wsparcie PX4 od v1.11 i ArduPilot od 4.0.[3] Są to minimalne historyczne wersje, nie rekomendacja użycia ich obecnie. Dla nowej integracji należy wybrać bieżące stabilne wydanie, sprawdzić target Durandal i release notes.

Typowe zastosowania:

większy multirotor z wieloma portami i power monitors;
fixed-wing lub VTOL wymagający osobnego I/O;
platforma laboratoryjna z PX4/ArduPilot;
pojazd wymagający mechanicznie izolowanych i ogrzewanych IMU;
UGV/USV, jeśli masa i obudowa nie są ograniczeniem.

Mniej odpowiedni jest dla mikro-UAV, gdy 68 g i wymiary około 80 × 45 × 20,5 mm są nadmierne, albo dla nowego produktu wymagającego modularnego PAB/Ethernet/secure element dostępnych w innych rodzinach.[1]

Dane podstawowe#

Według bieżącej strony producenta:[1]

Element	Specyfikacja deklarowana przez Holybro
FMU	STM32H743 Cortex-M7, do 480 MHz
RAM / flash	1 MB / 2 MB
I/O	STM32F100/F103 family
IMU 1	ICM-20689 accel/gyro
IMU 2	ICM-20602 lub BMI088 zależnie od dokumentu/rewizji
magnetometr	IST8310
barometr	MS5611
serial	5 general-purpose, 3 z flow control
I2C	3
CAN	do 2
wymiary	80 × 45 × 20,5 mm
masa	68,8 g na stronie producenta
max input controller	6 V

ArduPilot podaje 400 MHz i 64 g, podczas gdy Holybro 480 MHz i 68,8 g.[1][4] STM32H743 może pracować do 480 MHz w odpowiedniej rewizji i konfiguracji, ale rzeczywista częstotliwość w firmware należy odczytać z targetu/logu. Masa może różnić się między rewizją, obudową i zestawem kabla. W katalogu technicznym dane powinny być oznaczone źródłem oraz datą.

Rozbieżności w dokumentacji#

Najistotniejsze sprzeczności:

Pole	Holybro product page	ArduPilot overview	Wniosek
taktowanie FMU	do 480 MHz	400 MHz	zależne od rewizji/konfiguracji, sprawdzić runtime
drugi IMU	ICM-20602 / BMI088	BMI088	możliwe rewizje/substitution
liczba PWM	13: 8 I/O + 5 FMU	16 w tabeli, dalej opis AUX 1–8	pinout i hwdef są rozstrzygające
masa	68,8 g	64 g	mierzyć egzemplarz/zdefiniować zestaw

ArduPilot w sekcji GPIO omawia osiem AUX outputs, podczas gdy producent wymienia pięć FMU outputs. Strona ArduPilot podaje też 16 PWM, choć klasyczna suma z product page wynosi 13.[1][4] Te dane nie powinny być arbitralnie ujednolicane. Przy integracji należy:

pobrać aktualny Durandal pinout od Holybro;
sprawdzić hardware revision na egzemplarzu;
odczytać hwdef właściwego targetu ArduPilot/PX4;
wyliczyć fizyczne kanały i timer groups;
potwierdzić je oscyloskopem/logic analyzer bez napędu.

Informacja wymaga dodatkowej weryfikacji dla konkretnej rewizji: pełna liczba fizycznie wyprowadzonych PWM i mapowanie dodatkowych AUX względem opisów obu źródeł.

Ta jawna niepewność jest ważniejsza niż pozornie kompletna tabela. Błąd o trzy kanały może zmienić wybór kontrolera dla VTOL albo wieloserwowego fixed-wing.

Procesor FMU#

STM32H743 jest Cortex-M7 z double-precision FPU, cache, wieloma magistralami i peryferiami. W Durandal producent podaje 2 MB internal flash i 1 MB RAM.[1][5]

FMU wykonuje:

sterowniki sensorów;
estimator EKF;
attitude/rate/position controllers;
nawigację i misję;
MAVLink/DroneCAN;
logging;
scripting i dodatkowe moduły zależnie od firmware;
komunikację z procesorem I/O.

H7 ma istotnie większy zapas niż starsze F4/F7, ale wymaga poprawnej konfiguracji DMA i cache. Buffer używany przez peripheral DMA musi znajdować się w odpowiedniej pamięci lub mieć obsłużoną spójność cache. To zadanie board support package, lecz custom driver może je zepsuć.

W kwalifikacji mierzy się:

średni i maksymalny CPU load;
najdłuższe scheduler slip;
stack high-water marks;
heap/DMAMEM margin;
log drops;
latency sensor-to-controller;
zachowanie przy pełnym CAN/UART traffic.

Nominalne 480 MHz nie jest argumentem bez tych pomiarów.

Procesor IO#

STM32F100/F103-class I/O obsługuje część wyjść, RC i funkcje bezpieczeństwa. Jest oddzielony od FMU, więc może utrzymać zdefiniowane output behavior podczas krótkiej awarii lub restartu FMU.

RC inputs ───────────────→ I/O MCU ─→ IO PWM group
                            ↑
FMU control/mixer ──────────┘

sensors → H743 FMU → FMU PWM group

I/O nie jest redundantnym autopilotem. Nie zna pełnej pozycji i nie wykonuje misji. Jego rola zależy od firmware I/O, mixer/output protocol i parametrów failsafe.

Testy muszą objąć:

utratę FMU–I/O communication;
watchdog reset FMU;
boot FMU przy aktywnym servo rail;
RC failsafe;
armed/disarmed values;
safety switch;
aktualizację firmware I/O;
zgodność output rate grup.

Nie wystarcza sprawdzić, że serwo „nie drgnęło” raz. Należy zapisać waveform wszystkich krytycznych kanałów przez pełny reset.

IMU ICM 20689 i BMI088#

Durandal łączy sensory InvenSense i Bosch. Różnorodność producentów zmniejsza część ryzyka wspólnego błędu komponentu. ICM-20689 i BMI088 różnią się zakresem, noise, filter chain, FIFO, temperature behavior i clipping.

Holybro w bieżącym opisie wymienia ICM-20689 oraz ICM-20602/BMI088, natomiast ArduPilot wymienia ICM-20689 i BMI088.[1][4] Sterownik powinien identyfikować urządzenie po WHO_AM_I/device ID, a incoming inspection zapisywać wynik.

Redundancja dwóch IMU może wykrywać:

utratę jednego SPI/device;
bias divergence;
clipping jednego zakresu;
stale data;
nadmierne innovations jednej lane;
wzrost noise.

Nie chroni w pełni przed:

wspólną awarią zasilania;
błędnym board orientation;
wspólną wibracją obudowy;
błędem estimator software;
EMI sprzęgającym się do obu;
uszkodzeniem MCU.

Estimator policy powinna określać primary sensor, lane switching i maksymalny dopuszczalny attitude jump. Log trzeba analizować per instance.

Izolacja drgań#

Holybro deklaruje wbudowany vibration isolation system filtrujący drgania wysokoczęstotliwościowe.[1] Konstrukcja wewnętrzna tworzy mechanical low-pass, ale jego charakterystyka nie jest idealna.

Transmissibility układu drugiego rzędu zależy od:

r = excitation_frequency / natural_frequency
ζ = damping ratio

Poniżej rezonansu sensor podąża za obudową. W okolicy rezonansu amplitude może wzrosnąć. Powyżej odpowiedniego r izolacja tłumi. Zakres zależy od masy płytki i elastomeru.

Podwójne izolowanie całej obudowy miękką pianką może:

obniżyć rezonans do pasma sterowania;
dodać rocking mode;
zwiększyć delay i cross-axis;
powodować kontakt obudowy w dużym udarze;
utrudniać odpływ ciepła.

Dlatego zaczyna się od montażu zgodnego z producentem, a dopiero log PSD decyduje o zmianie. Diagnostyka logów i wibracji opisuje metodę analizy.

Ogrzewanie IMU#

Heater utrzymuje sensory w stabilnym zakresie temperatury. Bias MEMS jest funkcją temperatury; ogrzewanie powyżej większości ambient ogranicza zmiany w locie.

Wymagania operacyjne:

czas warm-up przed kalibracją/uzbrojeniem;
heater target dla firmware;
stabilność bez oscylacji;
pobór mocy cold start;
zachowanie w hot ambient;
gradient między dwoma IMU;
thermal compensation odpowiadająca tej samej konfiguracji.

Test cold chamber:

schłodzić nieuzbrojony zestaw zgodnie z ratingiem laboratorium;
włączyć primary power i rejestrować prąd, temperature, gyro bias;
zmierzyć czas do tolerance band;
sprawdzić overshoot i steady-state;
powtórzyć z maksymalnym obciążeniem peryferiów;
wykonać hot case, w którym heater nie ma możliwości chłodzenia.

Deklarowany przez ArduPilot zakres pracy −40…85°C jest oznaczony jako claimed.[4] Nie oznacza, że kompletny UAV, karta SD, connectors i power module są zakwalifikowane w tym zakresie.

Barometr i magnetometr#

MS5611 jest pojedynczym onboard barometrem według obu głównych źródeł.[1][4] Brak drugiego barometru oznacza, że redundancję wysokości trzeba uzyskać z external barometer/rangefinder/GNSS lub zaakceptować pojedynczy sensor.

Barometr wymaga:

ochrony przed światłem i prop wash;
pianki/vent o znanej odpowiedzi;
testu pressure step;
korelacji z temperaturą heatera;
kontroli kondensacji;
kalibracji offset przy starcie.

IST8310 jest onboard magnetometrem. Blisko power wires i current loops może być zakłócany. Dla większego UAV preferowany jest external compass z GNSS, odsunięty od napędu. Onboard compass może być wyłączony lub zapasowy po compass-motor test.

Nie należy zakładać, że dwa IMU oznaczają dwa magnetometry i dwa barometry. Redundancja jest asymetryczna.

Pamięć i logowanie#

Durandal ma microSD i FRAM zgodnie z architekturą wspieraną przez target; dokładny rozmiar FRAM należy potwierdzić w datasheet/pinout rewizji. ArduPilot DataFlash logs oraz PX4 ULog umożliwiają analizę sensorów, outputów i power flags.

Karta microSD powinna być przemysłowa lub high-endurance o kwalifikowanym temperature range i latency. Test zapisuje maksymalny log profile przez czas dłuższy niż planowana misja.

Mierzyć:

drop count;
worst write latency;
filesystem errors;
boot bez karty;
zachowanie pełnej karty;
power cut podczas zapisu;
retencję card connector w vibration;
wpływ logowania na scheduler.

Log musi zawierać device IDs obu IMU, temperature, clipping, innovations, power status, reset reason i output commands. Bez tego redundancja jest trudna do audytowania.

Porty szeregowe#

Holybro wymienia pięć general-purpose serial ports, z czego trzy z hardware flow control.[1] Dodatkowo dostępny jest debug/console zależnie od pinoutu. ArduPilot również podaje pięć serial plus debug.[4]

Plan UART powinien zapisać:

Port fizyczny	Funkcja	Protocol	Baud	Flow control	Zasilanie	Failsafe
TELEM1	modem/companion	MAVLink 2	projektowe	RTS/CTS	osobna grupa limitu	link-loss policy
TELEM2	radio backup	MAVLink/RC	projektowe	wg urządzenia	wspólna grupa	backup C2
GPS1	GNSS	vendor/NMEA	projektowe	zwykle nie	5 V port	position loss
GPS2/UART	second GNSS	vendor	projektowe	wg pinout	port	voting
debug	console	shell	target	n/a	bench	production lock

Port z flow control wymaga połączenia RTS/CTS po obu stronach i właściwej polaryzacji. Jeśli urządzenie nie używa flow control, parametry muszą to odzwierciedlać.

TELEM1 ma według producenta osobny current limit 1,5 A; pozostałe porty dzielą limit 1,5 A.[1] To nie jest rekomendacja zasilania companion o poborze 1,5 A ciągłym. Inrush i regulator thermal margin wymagają osobnego budgetu.

I2C SPI i CAN#

I2C#

Trzy porty I2C dają elastyczność dla magnetometrów, airspeed i rangefinderów. I2C jest podatny na pojemność kabla, stuck-low i EMI. Długie wiązki powinny korzystać z CAN albo specjalnych extenderów po kwalifikacji.

Sprawdzić pull-up voltage, combined resistance i recovery. Dwa urządzenia o tym samym adresie muszą być na różnych busach albo za muxem.

SPI#

Holybro opisuje cztery magistrale, w tym high-speed sensor bus, low-noise bus, FRAM i external SPI.[1] W tekście product page znajduje się placeholder „dedicated for XXX”, co wskazuje, że fragment dokumentacji nie jest kompletny. Nie należy na tej podstawie przypisywać funkcji; pinout i schematic/hwdef są źródłem rozstrzygającym.

External SPI wymaga krótkich połączeń. Chip select, DRDY, voltage i mode muszą być zgodne. Dla external sensor w pojeździe lepszy jest DroneCAN.

CAN#

Dwa CAN pozwalają rozdzielić propulsion i navigation peripherals albo zbudować redundantną topologię. Producent wspomina individual silent control/ESC RX mux.[1] Firmware support i mapping należy sprawdzić.

CAN design obejmuje dwa terminatory, trunk, krótkie stubs, common ground, bitrate i node IDs. Porty nie tworzą automatycznie redundancji, jeśli oba biegną w jednej wiązce i z jednego zasilania.

Wejścia RC#

Durandal ma dedykowane wejścia dla Spektrum/DSM oraz CPPM/S.Bus, S.Bus servo output i analog/PWM RSSI według producenta.[1]

RC integration wymaga:

ustalenia voltage i connector pinout;
ustawienia protocol detection/manual selection;
receiver failsafe output;
channel mapping;
frame loss timeout;
backup link priority;
testu odłączenia sygnału i zasilania;
logowania RSSI/LQ/failsafe flags.

S.Bus input, S.Bus output i RSSI mogą dzielić zasoby/piny zależnie od board design. Nie należy podłączać urządzeń tylko po nazwie connectora.

RC failsafe nie powinien polegać na stałej wartości kanału generowanej przez odbiornik, jeśli autopilot może rozpoznawać frame loss. Testuje się utratę RF, utratę kabla i utratę zasilania odbiornika osobno.

Wyjścia i grupy timerów#

Holybro podaje 13 PWM: osiem z I/O i pięć z FMU.[1] ArduPilot opisuje 16 PWM i osiem AUX GPIO, co jest sprzeczne. Do czasu sprawdzenia pinoutu nie należy deklarować wymagającej liczby kanałów.

Grupy timerów oznaczają, że kanały w jednej grupie muszą używać zgodnej częstotliwości/protokołu. ArduPilot wymienia m.in. PWM5–6 jako jedną grupę, PWM7–8 jako inną, z ograniczeniami DMA/DShot dla ostatniej.[4]

Macierz output:

channel → physical pin → MCU timer/channel → DMA stream
        → IO or FMU domain → allowed protocols → failsafe owner

Przed podłączeniem aktuatorów:

odczytać mapping targetu;
ustawić SERVOx_FUNCTION/actuator config;
sprawdzić waveform;
potwierdzić group rates;
testować armed/disarmed;
odłączyć FMU link i obserwować I/O;
zapisać wyniki w konfiguracji pojazdu.

Serwo pobiera energię z servo rail, a pin output dostarcza tylko sygnał logiczny.

DShot i DMA#

DShot wymaga precyzyjnego timingu i często DMA. Kanały bez dostępnego DMA mogą nie wspierać DShot albo wspierać tylko ograniczone tryby. ArduPilot podaje, że określone ostatnie kanały grupy nie mają DMA/DShot.[4]

Nie można mieszać PWM i DShot dowolnie w tej samej timer group. Jeśli jeden kanał przełącza grupę na DShot, pozostałe mogą wymagać tego samego protokołu.

Bidirectional DShot dodatkowo wymaga odwrócenia kierunku pinu i capture timing. Wsparcie zależy od targetu, output group i firmware. Sprawdza się w bieżącej dokumentacji, nie w ogólnym artykule o H7.

Test:

logic analyzer decode każdego kanału;
motor test bez śmigieł;
telemetry error rate;
CPU/DMA load;
zachowanie przy logowaniu;
failsafe frame;
mixed protocol rejection.

GPIO i capture#

Producent wymienia sześć dedicated PWM/capture inputs na FMU oraz additional analog inputs.[1] ArduPilot pozwala przekształcać część AUX PWM w GPIO; sposób konfiguracji zmienił się w nowszych wersjach z globalnego BRD_PWM_COUNT na indywidualne SERVOx_FUNCTION=-1 i SERVO_GPIO_MASK w określonych przypadkach.[4]

Instrukcja musi być przypięta do wersji firmware. Stary poradnik z BRD_PWM_COUNT może nie odpowiadać bieżącej wersji.

GPIO nie są high-current drivers. Do relay, LED strip lub solenoid potrzebny jest tranzystor/MOSFET, flyback diode i oddzielne zasilanie. Pin MCU nie może bezpośrednio sterować obciążeniem indukcyjnym.

Capture input przydaje się do RPM, PPS i pomiaru pulse width. Trzeba znać voltage, edge polarity, timer resolution, filtering i maksymalną częstotliwość.

Zasilanie kontrolera#

Holybro podaje operating power około 4,9–5,5 V w dokumentacji ArduPilot i max 6 V; USB 4,75–5,25 V.[1][4] Primary i secondary power module inputs umożliwiają dual source oraz pomiar dwóch baterii.

Należy ustalić:

czy oba wejścia logicznie OR-ingują zasilanie;
który source ma priorytet;
zakres pod obciążeniem;
reverse/backfeed protection;
power-good thresholds;
peripheral rail current limit;
brownout reset threshold;
event logging w I/O/FM U;
USB interaction.

Dwa wejścia nie są redundancją, jeśli power modules są na tej samej baterii i jednym connectorze. Analiza common-cause obejmuje cells, main connector, fuse, wire, BEC i ground.

Power module musi dostarczyć prąd kontrolera, heatera i peryferiów z marginem. Cold-start heater może podnieść peak. Napięcie mierzy się przy Durandal, nie tylko na wyjściu BEC.

Servo rail#

Producent podaje servo rail input do 36 V, a ArduPilot wyraźnie zaznacza, że servo rail nie zasila autopilota.[1][4] Wysoki limit dotyczy izolacji/driverów i header, nie oznacza, że dowolne serwo przyjmie 36 V.

Servo rail voltage wybiera się według actuator rating. Typowe serwa mają 5–8,4 V, a ESC signal ground musi być wspólna. Zasilanie rail wymaga BEC o odpowiednim current, transient response i ochronie.

Niebezpieczne założenia:

„Durandal toleruje 36 V, więc serwa też” — fałsz;
„servo rail zasili kontroler jako backup” — źródła temu przeczą;
„sygnał PWM dostarcza prąd serwa” — fałsz;
„wszystkie grounds są idealne” — spadek na masie może zakłócić signal threshold.

Test stall current serw wykonuje się na osobnym fixture, nie przez blokowanie mechanizmu w latającym UAV. BEC powinien wytrzymać sumę peak i regenerative current albo mieć absorpcję.

Power modules i pomiar baterii#

Durandal ma dwa 6-pin power monitor ports dla voltage/current dwóch baterii.[4] Holybro oferuje zestawy z PM02 12S i PM06 14S, lecz konfiguracja scaling zależy od konkretnego modułu.[1]

Każdy port wymaga:

poprawnego connector pinout;
input voltage 5 V w dozwolonym zakresie;
analog voltage/current sense range;
parametrów multiplier/offset/amps-per-volt;
porównania z kalibrowanym miernikiem;
sprawdzenia direction current;
testu max pack voltage bez przekroczenia ADC;
oznaczenia battery instance.

Nie należy kopiować parametrów PM02 do PM06. Nawet dwa egzemplarze mają tolerancję shunt i divider. Kalibracja obejmuje kilka punktów prądu.

Dual battery monitor nie decyduje automatycznie, która bateria zasila którą gałąź. Energy/failsafe policy musi wiedzieć, czy packs są równolegle, osobno dla napędu/payload czy primary/backup.

Zasilanie peryferiów#

Holybro podaje osobny limiter 1,5 A dla TELEM1 i łącznie 1,5 A dla pozostałych portów.[1] Budżet trzeba traktować jako limit szczytowy układu, nie docelowy ciągły punkt pracy.

Tabela budżetu powinna zawierać:

Peryferium	Port	średni	peak/inrush	source group	akcja po odłączeniu
GNSS	GPS1	pomiar	pomiar	shared	position degrade
telemetry radio	TELEM1	pomiar	pomiar	private	link failsafe
second GNSS	port	pomiar	pomiar	shared	voting change
rangefinder	I2C/CAN	pomiar	pomiar	shared/separate	terrain failsafe

Modem LTE, SBC i radio video powinny mieć osobny regulator, jeśli peak jest wysoki. Signal lines wymagają common reference lub izolacji. Backfeeding przez UART/USB należy sprawdzić przy power sequencing.

PX4 i ArduPilot#

Holybro deklaruje wsparcie obu stosów.[3] PX4 listuje Durandal w manufacturer-supported controllers.[7] ArduPilot ma szczegółowy hardware page, target i obsługę ChibiOS.[4]

Różnice integracyjne:

nazwy i mapping wyjść;
metoda GPIO;
sensor priority/EKF lanes;
log format;
parameter naming;
bootloader/update;
GCS;
DShot support per channel;
scripting;
safety switch i prearm.

Nie należy utrzymywać jednej instrukcji konfiguracji dla obu stosów. Wspólne są elektryka i mechanika, lecz firmware procedures są oddzielne.

Przy PX4 trzeba sprawdzić aktualny board page/target w używanej stabilnej wersji, bo manufacturer-supported status oznacza inną odpowiedzialność utrzymania. Przy ArduPilot użyć aktualnej hardware page oraz hwdef.

Montaż mechaniczny#

Wymiary 80 × 45 × 20,5 mm i masa około 64–68,8 g wpływają na layout.[1][4] Kontroler powinien być zamontowany:

zgodnie z arrow lub z poprawnym board rotation;
możliwie blisko środka obrotu;
z dala od PDB, phase wires, magnesów i RF PA;
bez naprężania obudowy i złączy;
z dostępem do SD/USB;
z ventem barometru;
w thermal envelope;
z cable strain relief.

Wewnętrzna izolacja oznacza, że obudowa powinna być zwykle mocowana zgodnie z zaleceniem producenta, nie zawieszana na bardzo miękkich damperach. Po montażu analizuje się vibration spectra obu IMU.

Przewody nie mogą tworzyć sprężyny ciągnącej kontroler. Ciężki kabel USB/telemetry powinien być podparty na ramie.

Onboard magnetometer wymaga compass-motor test w finalnym miejscu. Jeśli interference rośnie z throttle/current, external compass jest potrzebny.

Plan portów#

Przed okablowaniem tworzy się dokument:

PORT_PLAN revision
  TELEM1 → primary C2, MAVLink2, RTS/CTS, external regulator
  TELEM2 → backup telemetry
  GPS1   → GNSS1 + external compass
  GPS2   → GNSS2
  CAN1   → propulsion nodes, termination at FC/end
  CAN2   → navigation sensors
  I2C1   → short local sensor only
  MAIN   → safety-critical actuators
  AUX    → DShot/GPIO according to timer groups

Do każdego wpisu dodaje się connector part, cable drawing, voltage, current, protocol, baud/bitrate, termination, failure effect i test.

Plan ujawnia konflikty przed zakupem. Przykład: trzy urządzenia wymagają flow-control UART, a tylko trzy porty je mają; external SPI wymaga krótkiej wiązki, ale sensor jest na ogonie; DShot channels kolidują z timer group serw.

Bring up#

Sekwencja:

Sprawdzić model, serial i hardware revision.
Obejrzeć obudowę, connectors i SD slot.
Zweryfikować cable pinouts.
Zasilić z laboratoryjnego 5,1 V current-limited source przez właściwy power port.
Zmierzyć cold/warm current i temperaturę.
Odczytać bootloader, board ID i firmware target.
Wgrać zatwierdzony stable build.
Zapisać device IDs: ICM/BMI, baro, mag.
Sprawdzić heater warm-up i sensor health.
Przetestować SD/FRAM/log.
Podłączać jedno peryferium naraz.
Sprawdzić wszystkie outputy logic analyzerem bez aktuatorów.

Baseline inventory rozstrzyga, czy egzemplarz ma BMI088 czy ICM-20602. Nieznany sensor albo brak drugiej instancji blokuje produkcję do wyjaśnienia.

Testy sensorów#

Statyczne#

gyro/accel noise i Allan deviation;
bias repeatability po 10 restartach;
orientation każdej instancji;
heater warm-up;
barometer noise;
magnetometer offsets.

Dynamiczne#

motor-by-motor;
throttle sweep;
shaker sweep;
clipping i sample drop;
timestamp skew;
estimator innovations;
primary/secondary switch.

Termiczne#

cold start;
hot soak;
heater disabled/fault jeśli test fixture pozwala;
bias vs temperature;
thermal recovery po airflow change.

Fault injection#

simulated IMU stale data;
bias ramp;
SPI timeout;
barometer freeze;
compass jump;
logger stall.

Kryteria są ilościowe: noise PSD, max clipping, max attitude jump, switch time i brak utraty control loop deadline.

Testy zasilania#

Macierz:

Test	Obserwacja
primary only	rails, current, power flag
secondary only	identyczna funkcja lub jawne ograniczenie
source handover	droop, reset, log event
slow ramp down	brownout threshold i reset reason
1–20 ms dips	ride-through i estimator continuity
peripheral overload	current limit bez FMU reset
USB attach/detach	backfeed i source priority
heater cold start	peak i regulator temperature
servo rail high voltage	isolation od FMU 5 V

Testy wykonuje się fixturem z programowalnym supply/electronic load i oscyloskopem. Wartości max nie są punktami testu destrukcyjnego. Nie przekracza się ratingu 6 V wejścia kontrolera.

Brownout powinien prowadzić do identyfikowalnego reset reason. Jeśli I/O pozostaje aktywne, rejestruje zachowanie outputs do powrotu FMU.

Testy wyjść i failsafe#

Najpierw dummy loads i logic analyzer, potem serwa/ESC bez śmigieł.

Scenariusze:

arm/disarm;
safety engaged/released;
RC loss;
telemetry loss;
FMU watchdog reset;
I/O communication loss;
battery failsafe;
servo rail loss;
output protocol error;
mixed timer group configuration;
DShot telemetry loss.

Każdy krytyczny actuator ma zdefiniowane safe, hold last, neutral lub platform-specific behavior. Hold-last może być groźny, np. przy dużym throttle. Wartość powinna wynikać z hazard analysis.

Po restarcie FMU actuator nie może przejść przez niekontrolowany pulse. Bootloader, I/O i main firmware muszą mieć spójną politykę.

Lifecycle i utrzymanie#

Durandal nadal znajduje się w sklepie Holybro, ale część bundle variants na stronie ma status unavailable, a produkt jest starszy niż generacje Pixhawk 6.[1] Dostępność pojedynczego SKU nie gwarantuje długiego lifecycle.

Utrzymanie powinno przechowywać:

serial i hardware revision;
supplier/lot;
firmware/bootloader build;
sensor device IDs;
baseline current i temperature;
calibration dates;
flight hours i reset count;
SD replacement;
connector inspections;
RMA/incident history.

Przed zakupem dla floty zapytać o PCN/EOL, dozwolone sensor substitutions i gwarancję identycznego pinoutu. Retention sample każdej partii ułatwia analizę.

Migracja do Pixhawk 6X/Cube Orange wymaga nowego mountu/cables i pełnej rekwalifikacji. H7 w obu nie oznacza identycznej architektury.

Kryteria doboru#

Durandal jest dobrym wyborem, gdy:

13 lub zweryfikowana liczba outputów wystarcza;
potrzebny jest osobny I/O;
dwa różne IMU odpowiadają fault model;
heater i internal isolation są pożądane;
masa/wymiary są akceptowalne;
wymagane są dwa power monitors i wiele serial/CAN;
istnieje dojrzały target w wybranym stosie.

Wymaga alternatywy, gdy:

potrzeba trzech IMU/barometrów;
potrzebny PAB lub wymienny module/carrier;
wymagany Ethernet/secure element;
masa jest krytyczna;
liczba PWM po weryfikacji nie wystarcza;
wymagany jest formalny status reference standard;
lifecycle produktu nie pokrywa projektu.

Porównanie nie powinno bazować na MHz. Durandal H743 może mieć podobną moc do nowszego 6C, lecz inny sensor set, porty, wyjścia, status wsparcia i mechaniczną integrację.

Typowe błędy#

Uznanie wszystkich danych z Internetu za zgodne#

Źródła różnią się taktowaniem, masą i liczbą PWM. Pinout, hwdef i egzemplarz są rozstrzygające.

Wybranie kanałów DShot bez timer mapy#

Nie każdy kanał ma DMA. Cała grupa może wymagać jednego protokołu.

Zasilenie kontrolera z servo rail#

Servo rail nie zasila FMU. Potrzebny jest właściwy 5 V power input.

Podanie napięcia powyżej 6 V na power input#

Max 6 V nie oznacza tolerancji baterii 2S. Stosuje się power module/BEC.

Zasilenie dużego SBC z TELEM1#

Limit 1,5 A nie jest zalecanym continuous load. Inrush i thermal margin mogą zresetować system.

Dodatkowa miękka izolacja#

Wbudowany system ma własny rezonans. Modyfikację uzasadnia log PSD, nie intuicja.

Założenie pełnej redundancji sensorów#

Dwa IMU, jeden barometr i jeden magnetometr dają asymetryczny fault coverage.

Kopiowanie parametrów między PX4 i ArduPilot#

Warstwa hardware jest wspólna, ale konfiguracja i output semantics nie.

Brak ewidencji rewizji#

Drugi IMU może różnić się między dokumentami/partiami. Device inventory musi być zapisany.

Testowanie outputów z założonymi śmigłami#

Mapowanie i failsafe zawsze sprawdza się najpierw na logic analyzer/dummy load.

Durandal pozostaje technicznie użytecznym H7 autopilotem, szczególnie dla ArduPilot i systemów wymagających osobnego I/O. Jego właściwa ocena wymaga jednak traktowania dokumentacji jako wersjonowanego zestawu źródeł, a nie jednej bezbłędnej karty katalogowej.

Powiązane tematy#

Przypisy#

Holybro, „Durandal” — bieżąca strona produktu, parametry, porty, zasilanie i zestawy.
Holybro Documentation, „Durandal” — dokumentacja, pinout i pliki techniczne producenta.
Holybro Documentation, „Supported Firmware” — minimalne historyczne wersje PX4 i ArduPilot.
ArduPilot, „Holybro Durandal” — target, sensory, porty, grupy wyjść, GPIO i power monitoring.
STMicroelectronics, dokumentacja STM32H743/753 — architektura MCU i zasoby.
Bosch Sensortec, BMI088 — specyfikacja jednego z IMU występujących w Durandal.
PX4, „Pixhawk Series” i „Flight Controller Selection” — klasyfikacja standardowych oraz manufacturer-supported controllerów.

Źródła z centralnego rejestru

Holybro: Durandal product page and current technical specification [dokumentacja producenta]
Holybro Documentation: Durandal [dokumentacja producenta]
Holybro Documentation: Durandal supported firmware [dokumentacja producenta]
ArduPilot: Holybro Durandal overview [dokumentacja projektu]
STMicroelectronics: STM32H743/753 documentation [producent]
Bosch Sensortec: BMI088 [datasheet]
PX4 Guide: Pixhawk Series [dokumentacja projektu]