HIL dla własnego flight controllera

Hardware-in-the-loop umieszcza prawdziwy flight controller w zamkniętej pętli z programowym modelem statku. Mikrokontroler wykonuje rzeczywisty scheduler, estymator, regulatory, watchdog i stos komunikacyjny; symulator zastępuje ruch platformy oraz sensory i odbiera komendy aktuatorów. Dzięki temu można wykryć problemy niewidoczne w desktopowym SITL: przeciążenie CPU, konflikty DMA, jitter ISR, ograniczenia pamięci, realne opóźnienie UART/CAN i zachowanie po resecie.

HIL nie oznacza jednak „prawie lotu”. Jeśli wyjścia silników pozostają fizycznie podłączone, stanowisko jest niebezpieczne. Jeśli model ma idealne IMU i natychmiastowy napęd, wynik może być bardziej optymistyczny niż SITL z lepszą fizyką. Dobre stanowisko zaczyna się od jawnej granicy systemu, blokady energii aktuatorów i zmierzonego budżetu czasu.

Spis treści#

Granica HIL
HIL, HITL, SIH i simulation-on-hardware
Architektura pętli
Bezpieczeństwo wyjść
Minimalny interfejs
MAVLink HIL
HIL_SENSOR
HIL_GPS
HIL_STATE_QUATERNION
HIL_ACTUATOR_CONTROLS
Protokół własny
Jednostki i układy osi
Czas jako część interfejsu
Fixed-step i lockstep
Free-running
Budżet opóźnienia
Jitter
Kolejki, drop i duplikaty
Rate poszczególnych sensorów
Modele IMU
GNSS, barometr i magnetometr
Modele aktuatorów
Start i inicjalizacja
Reset i watchdog
Heartbeat i supervision
Instrumentacja sprzętowa
Fault injection
Stuck, dropout, delay i bias
Awarie magistrali
Porównanie z SITL
Bring-up stanowiska
Testy regulatora
Testy estymatora
Testy failsafe
Rejestracja i replay
Automatyzacja regresji
Kryteria zaliczenia
Ograniczenia
Scenariusz referencyjny
Powiązane tematy
Przypisy

Granica HIL#

Najpierw rysuje się granicę między elementami prawdziwymi i symulowanymi. Przykładowa konfiguracja:

Element	Prawdziwy	Symulowany
MCU, RTOS/scheduler, firmware	tak	nie
wewnętrzne SPI i sterowniki IMU	opcjonalnie	często zastąpione wejściem HIL
estymator i regulatory	tak	nie
PWM/DShot/CAN output	generowany fizycznie i/lub raportowany	odbierany przez adapter
ESC, silnik, śmigło	nie	tak
dynamika ramy i środowisko	nie	tak
GCS/RC/telemetria	zależnie od testu	zależnie od testu

Im więcej rzeczywistego toru pozostaje, tym większe pokrycie integracji, ale rośnie złożoność. Wstrzyknięcie gotowego wektora IMU na poziomie uORB nie testuje drivera SPI. Emulator elektryczny sensora na SPI testuje znacznie więcej, lecz musi poprawnie odtwarzać timing, rejestry, przerwania i błędy układu.

Raport HIL musi mówić, gdzie dokładnie wstrzyknięto dane. Samo słowo „HIL” nie opisuje pokrycia.

HIL, HITL, SIH i simulation-on-hardware#

Nazewnictwo projektów różni się:

SITL — firmware skompilowany na komputer, z modelem programowym;
HITL/HIL zewnętrzny — prawdziwy FC, model fizyki na komputerze, dane przez interfejs;
SIH on hardware — model fizyki działa wewnątrz prawdziwego FC;
Simulation on Hardware ArduPilot — wbudowany model i symulowane sensory na autopilocie.

PX4 rozróżnia SYS_HITL=1 dla zewnętrznego symulatora po MAVLink i SYS_HITL=2 dla SIH na kontrolerze.[2][4] ArduPilot rozwija Simulation on Hardware wykorzystujące własne modele SITL wewnątrz firmware.[6]

Własny FC może użyć każdego wariantu. Zewnętrzny model daje bogatszą fizykę i wizualizację; wewnętrzny upraszcza połączenie i umożliwia test bez komputera, ale konkuruje o CPU z kodem lotu.

Architektura pętli#

model fizyki x(k)
   ↓ generacja sensorów y(k), timestamp k
transport/adapter
   ↓
flight controller hardware
   sensor drivers → estimator → controllers → mixer
   ↓ command u(k)
transport/adapter
   ↓
model aktuatora → integracja x(k+1)

Każdy krok potrzebuje jednoznacznego czasu i numeru sekwencji. Model nie powinien użyć komendy z przyszłości ani wielokrotnie integrować tego samego wyjścia.

W lockstep symulator wysyła sensory kroku k, czeka na komendę oznaczoną tym krokiem, a następnie przechodzi do k+1. W free-running obie strony biegną według zegarów, a adapter buforuje i interpoluje.

Bezpieczeństwo wyjść#

Najważniejsza zasada: HIL nie może zasilić prawdziwych śmigieł. Stosuje się kilka niezależnych barier:

brak baterii trakcyjnej,
fizycznie odłączone ESC/silniki,
adapter pomiarowy zamiast aktuatorów,
hardware inhibit lub safety relay rozłączający energię,
programowy tryb HIL blokujący wyjścia fizyczne,
procedura i oznaczenie stanowiska.

Bariera programowa nie wystarcza. Błąd konfiguracji, reset do defaults albo bootloader może wygenerować impulsy. Fizyczne rozłączenie energii jest nadrzędne.

Jeżeli test obejmuje prawdziwe serwo bez powierzchni, trzeba ograniczyć zakres ruchu, prąd i przestrzeń. Nawet małe serwo może zakleszczyć palec lub uszkodzić mechanizm.

Minimalny interfejs#

Minimalny multirotor potrzebuje:

czasu próbki,
trójosiowego przyspieszenia i prędkości kątowej,
opcjonalnie pola magnetycznego i barometru,
GNSS lub lokalnej pozycji zależnie od trybu,
wyjść co najmniej czterech silników,
stanu arm/mode albo sposobu jego wyprowadzenia,
heartbeat i statusu interfejsu.

Do wartościowego testu dodaje się temperaturę IMU, accuracy/variance, status fixa, napięcie baterii, RC input i eventy. Interfejs powinien zachować różne rate sensorów, a nie wysyłać wszystkiego w jednej idealnie synchronicznej ramce, jeśli prawdziwy system tak nie działa.

MAVLink HIL#

MAVLink common.xml definiuje standardowe wiadomości HIL. Pozwala połączyć wiele symulatorów i autopilotów bez własnego framingu.[1]

Typowy przepływ:

simulator → HIL_SENSOR / HIL_GPS / HIL_STATE_QUATERNION → FC
FC → HIL_ACTUATOR_CONTROLS → simulator

Nie każdy autopilot używa wszystkich wiadomości jednocześnie. Trzeba sprawdzić implementację używanej wersji. Message definition określa jednostki i pola, ale nie narzuca pełnej maszyny stanu startu, rate i timeoutów.

MAVLink po UART dodaje framing, bandwidth i latency bliższe realnemu interfejsowi; UDP na tym samym hoście jest wygodniejszy, ale nie testuje fizycznego portu FC.

HIL_SENSOR#

HIL_SENSOR przenosi dane IMU i części sensorów środowiskowych, wraz z timestamp oraz bitmapą fields_updated. Odbiornik powinien używać bitmapy, ponieważ nie wszystkie pola muszą być nowe w każdej wiadomości.[1]

Testuje się:

jednostki SI zgodne ze specyfikacją,
znaki osi i grawitację w spoczynku,
timestamp monotoniczny,
prawidłowe fields_updated,
zachowanie przy częściowej aktualizacji,
wartości NaN/Inf i poza zakresem,
timeout oraz recovery.

Wysyłanie wszystkich pól jako „zaktualizowane” przy 1 kHz, gdy barometr ma modelowo 50 Hz, tworzy nierealistyczny sensor i może ukryć problem asynchroniczności.

HIL_GPS#

HIL_GPS niesie czas, fix type, latitude/longitude/altitude, accuracy/DOP, prędkość, course i liczbę satelitów zależnie od wersji wiadomości.[1]

Trzeba zachować:

skalowanie integer (degE7, mm, cm/s zgodnie z definicją),
rozróżnienie altitude MSL i ellipsoid,
course over ground, nie yaw kadłuba,
sensowne accuracy/variance,
rate i latency GNSS,
utratę fixa bez zerowania pozycji do (0,0).

Idealne GNSS bez opóźnienia i multipath zawyża wyniki estymatora. Model powinien mieć co najmniej bias, noise, latency i warunki fixa odpowiadające testowi.

HIL_STATE_QUATERNION#

Wiadomość stanu prawdziwego jest przydatna jako ground truth i w części integracji jako wejście. Quaternion musi mieć określoną kolejność składowych oraz transformację. NED/ENU i FRD/FLU są częstą przyczyną pozornie niestabilnego regulatora.[1]

Ground truth nie powinien trafiać do estymatora, jeśli celem jest test estymacji z sensorów. Można go logować osobnym kanałem i porównywać offline.

Test osi: w spoczynku, roll +10°, pitch +10°, yaw +90° i kontrolowana prędkość. Każdy stan porównuje się z surowym IMU i outputem estymatora.

HIL_ACTUATOR_CONTROLS#

HIL_ACTUATOR_CONTROLS przenosi tablicę znormalizowanych wyjść, mode/flags i timestamp. Mapowanie indeksów do silników/serw jest zależne od konfiguracji.[1]

Adapter sprawdza:

liczbę aktywnych kanałów,
zakres i wartość disarmed/failsafe,
kolejność silników,
znaki serw,
timestamp i sekwencję,
timeout command,
zachowanie po arm/disarm/reset.

Model nie może utrzymywać ostatniej wysokiej komendy bez limitu po utracie linku, chyba że właśnie taki fault jest badany. Domyślnie powinien przejść do bezpiecznego stanu i oznaczyć przerwanie testu.

Protokół własny#

Własny protokół ma sens dla minimalnego MCU, SPI emulatora lub wymagań deterministycznych. Powinien mieć:

preambułę i wersję,
typ wiadomości,
długość,
sequence number,
timestamp próbki,
payload o jawnych jednostkach,
CRC,
target/source ID,
ACK lub mechanizm timeout dla kroków lockstep.

Nie używa się surowej struktury C przesłanej memcpy, ponieważ padding, endianess i rozmiary typów zmieniają się między kompilatorami. Format jest specyfikacją z test vectors.

Minimalna ramka:

magic | version | type | length | seq | sample_time_us | payload | CRC-32C

CRC wykrywa korupcję, ale nie duplikat ani opóźnioną poprawną ramkę — do tego służą sequence i timestamp.

Jednostki i układy osi#

Macierz transformacji musi być jawna:

v_body_FRD = R_world_to_body · v_world_NED

Najczęstsze pomyłki:

g vs m/s²,
deg/s vs rad/s,
gauss vs tesla,
Pa vs hPa,
MSL vs ellipsoid vs local z,
NED z dodatnim down vs ENU z dodatnim up,
body FRD vs FLU,
quaternion wxyz vs xyzw.

Test zerowy wykonuje się bez regulatora: ustawić znany stan modelu i sprawdzić dokładnie wszystkie pola na wejściu drivera. Następnie wykonać po jednym ruchu w każdej osi.

Grawitacja w akcelerometrze zależy od definicji specific force. Sensor stojący nieruchomo nie musi raportować wektora przyspieszenia geometrycznego, jak intuicyjnie oczekuje autor modelu.

Czas jako część interfejsu#

Trzeba rozróżnić:

czas modelu,
czas próbki sensora,
czas wysłania,
czas odbioru przez FC,
czas wykonania estymatora,
czas komendy aktuatora,
czas zastosowania jej w modelu.

Jedno pole timestamp nie opisuje wszystkich. Model powinien logować przynajmniej sample time i apply time. FC loguje odbiór oraz swoje przetwarzanie.

W HIL zegar MCU może dryfować względem hosta. Synchronizacja czasu nie może skakać wstecz. Jeżeli model steruje czasem, FC musi mieć sposób wykonywania kroków bez polegania na real-time peripherals, które pozostają free-running.

Fixed-step i lockstep#

W fixed-step model integruje zawsze Δt, np. 1 ms. Lockstep zapewnia, że kolejny krok nastąpi dopiero po przetworzeniu poprzedniego. Zaletami są deterministyczność, możliwość debug breakpoint i przyspieszanie/zwalnianie.

Protokół kroku:

SIM sends SENSORS(seq=k, t=k·dt)
FC processes and sends ACTUATORS(seq=k)
SIM applies u(k), integrates to k+1

Potrzebny jest timeout ścienny na wypadek zawieszenia FC. Timeout nie powinien jednak zmieniać stanu modelu; test kończy się z diagnostyką.

Problemem są zadania FC wyzwalane hardware timerem niezależnie od kroków. Jeśli MCU biegnie real-time, model nie może dowolnie przyspieszać ponad zdolność sprzętu. Lockstep pozostaje deterministyczny, ale najwyżej real-time lub wolniej.

Free-running#

Model i FC działają niezależnie. Adapter wysyła sensory według zegara hosta i używa najnowszej komendy. Jest prostszy dla istniejącego firmware, ale wprowadza zmienny phase delay.

Potrzebne są:

timestampy,
buffer policy,
pomiar latency distribution,
synchronizacja zegarów,
limit wieku komendy,
kontrola real-time factor.

Nie interpoluje się IMU i GNSS tak samo. IMU wymaga wysokiego rate; GNSS może być opóźniony i asynchroniczny. Free-running bardziej przypomina realny system, lecz trudniej uzyskać powtarzalność bit-for-bit.

Budżet opóźnienia#

Całkowite opóźnienie pętli:

T_loop = T_model_sensor + T_tx + T_driver + T_estimator
       + T_controller + T_output + T_rx + T_actuator_model

Każdy składnik mierzy się osobno. Średnia nie wystarcza; interesują median, percentile 95/99, maksimum i korelacja z obciążeniem.

Opóźnienie wpływa na zapas fazy. Stabilny controller w idealnym SITL może oscylować, gdy HIL dodaje 8 ms. Model nie powinien „cofać” czasu, aby ukryć transport; estymator może kompensować znane sensor latency, ale wyjście nadal działa później.

Budżet ma wymaganie, np. sensor sample → actuator frame ≤ 2.5 ms p99. Stanowisko sprawdza je GPIO i timestampami.

Jitter#

Jitter to zmienność opóźnienia lub okresu. Źródła:

scheduler hosta,
USB CDC buffering,
UART DMA chunks,
RTOS preemption,
cache i critical sections,
logowanie SD,
kolejki MAVLink,
garbage collection w narzędziu modelu.

Jitter modeluje się kontrolowanie dopiero po pomiarze baseline. Losowe sleep w skrypcie bez seed i logu nie tworzy powtarzalnego testu.

Wynik pokazuje histogram okresu IMU, czasu obliczeń i wieku komendy. Pojedynczy max może wynikać z startu loggera; trzeba zachować moment i korelację z task state.

Kolejki, drop i duplikaty#

Przepełnienie kolejki może zwiększać latency bez utraty danych — najgorszy wariant dla sterowania, bo FC przetwarza stare, ale poprawne próbki. Polityka „latest sample wins” często jest lepsza dla IMU niż niezawodne dostarczenie całego backlogu.

Adapter powinien liczyć:

gap sequence,
duplikaty,
out-of-order,
wiek przy odbiorze,
high-water mark kolejki,
CRC errors,
resynchronizacje framingu.

Po utracie próbki estymator musi wiedzieć o większym dt, a nie udawać regularnego rate. Duplikat z nowym timestampem jest szczególnie niebezpieczny.

Rate poszczególnych sensorów#

Przykładowa realistyczna architektura może mieć:

gyro 1–8 kHz wewnętrznie,
accelerometer 1–4 kHz,
mag 50–200 Hz,
barometr 25–100 Hz,
GNSS 5–20 Hz,
airspeed 50–100 Hz.

Wartości zależą od hardware; tabela nie jest zaleceniem. HIL powinien odtwarzać konkretną konfigurację oraz latency każdego toru.

Jeżeli transport nie mieści raw IMU 8 kHz, można emulować sensor na SPI, zwiększyć baud, agregować próbki albo wstrzykiwać na wyższym poziomie. Każda opcja zmienia pokrycie.

Modele IMU#

Minimalny model:

y = scale · R_misalignment · x_true + bias(T,t) + noise + quantization

Powinien uwzględnić:

white noise density i bandwidth,
bias oraz random walk,
scale factor i misalignment,
saturation/clipping,
quantization,
temperature dependence,
delay i sample-and-hold,
vibration/aliasing, jeśli badane.

Nie dodaje się wszystkich błędów naraz. Najpierw idealny model potwierdza znaki i pętlę, potem osobne przypadki zwiększają realizm.

Ground truth oraz sensor output loguje się oddzielnie. Dzięki temu można policzyć błąd estymatora i sprawdzić, czy awaria jest w modelu czy filtrze.

GNSS, barometr i magnetometr#

GNSS wymaga pozycji WGS84/local conversion, prędkości, accuracy i fixa. Barometr zależy od wysokości, pogody i propwash modelu. Magnetometr zależy od pola Ziemi, orientacji i zakłóceń.

Testy:

GNSS dropout, stuck, step, slow drift i latency,
barometer bias/ramp oraz pressure spike,
magnetometer rotation, hard/soft iron i interference zależne od throttle,
niezgodność jednego z redundantnych sensorów.

Własny model nie powinien oznaczać fałszywego GNSS jako „wysokiej dokładności”, jeśli generuje duży bias. Estymator używa variance do bramkowania.

Modele aktuatorów#

Najprostszy model command → force jest zbyt idealny. Dla silnika:

τ_m · dω/dt = ω_cmd - ω
T = k_T · ω²
Q = k_Q · ω²

Dodaje się dead zone, saturation, asymetrię spin-up/spin-down, battery voltage i limit. Dla serwa: rate limit, latency, backlash, saturation i obciążenie.

Model powinien używać rzeczywistej kolejności kanałów. Test jednostkowy pobudza każdy kanał osobno i sprawdza kierunek momentu. Nie uruchamia się pełnego regulatora, dopóki ta mapa nie jest poprawna.

Start i inicjalizacja#

Sekwencja HIL jest maszyną stanów:

POWER_OFF
→ FC_BOOT
→ LINK_DISCOVERY
→ SENSOR_STREAM_VALID
→ ESTIMATOR_READY
→ DISARMED_READY
→ ARMED_SIM
→ RUNNING
→ STOPPING

Symulator nie powinien wysyłać ruchomego stanu przed inicjalizacją bias gyro, chyba że test dotyczy startu w ruchu. FC nie powinien uzbroić się tylko dlatego, że HIL heartbeat istnieje.

Po boot trzeba potwierdzić firmware version, reset reason, konfigurację HIL, mapę wyjść i zdrowie estymatora. Start timeout zapisuje ostatnie stany obu stron.

Reset i watchdog#

Reset FC podczas lotu HIL musi mieć zdefiniowany skutek modelu. Możliwości:

zamrozić model i zakończyć test,
przejść do ballistic/unpowered dynamics,
utrzymać ostatnie wyjścia przez określony model ESC,
pozwolić FC ponownie się połączyć i badać recovery.

Nie wolno niejawnie resetować modelu do startu, bo ukrywa konsekwencje.

Watchdog powinien działać jak w flight build. Loguje się reset reason i boot counter. Stanowisko może celowo zatrzymać zadanie lub przeciążyć CPU, ale fault injection firmware musi być ograniczone do testowego buildu.

Po reboocie sequence/session ID zmienia się, aby stare pakiety nie zostały przyjęte.

Heartbeat i supervision#

Obie strony wysyłają heartbeat zawierający:

protocol version,
session ID,
current state,
last received sequence,
local time,
error flags,
queue depth,
build ID.

Supervision rozróżnia brak linku, brak postępu modelu i brak nowych sensorów. Sam UART otwarty nie oznacza zdrowia.

Timeout powinien prowadzić do bezpiecznego rozbrojenia modelu i zatrzymania testu. Automatyczne nieskończone reconnect może skleić dwa różne przebiegi.

Instrumentacja sprzętowa#

GPIO toggles pozwalają mierzyć:

wejście przerwania sensora,
początek/koniec odczytu,
start/koniec estymatora,
start/koniec control loop,
publikację aktuatora,
watchdog feed.

Logic analyzer rejestruje GPIO razem z UART/SPI/DShot. Daje niezależny czas sprzętowy i ujawnia jitter niewidoczny w logu, którego logger sam może być opóźniony.

Pin instrumentacyjny nie może zmieniać krytycznego timingu przez kosztowny driver. Używa się bezpośredniego, szybkiego toggle i dokumentuje narzut.

Fault injection#

Fault injection ma warstwy:

model — zmienia prawdziwy stan lub sensor output,
transport — drop, delay, reorder, corruption,
driver — timeout, status bit, przerwanie,
firmware — task stall, allocation failure, CPU overload,
zasilanie/reset — kontrolowany reset lub brownout emulator.

Wstrzyknięcie na niewłaściwej warstwie nie testuje zakładanego mechanizmu. Wyłączenie HIL_GPS nie testuje błędu UART GNSS drivera, jeśli driver jest omijany.

Każdy fault ma start trigger, duration, affected instance, seed, expected detection i recovery. Test rozpoczyna się od jednej awarii.

Stuck, dropout, delay i bias#

Te awarie różnią się diagnostycznie:

dropout/off — brak nowych próbek;
stuck — nowe ramki lub stale dostępny register z tą samą wartością;
delay — poprawne, ale stare próbki;
bias/step — świeże dane systematycznie błędne;
noise increase — rosnąca wariancja;
intermittent — okresowe przejścia good/bad.

Estimator może łatwo wykryć brak danych, trudniej płynny bias. Wszystkie przypadki wymagają osobnych kryteriów.

stuck nie powinien mieć zatrzymanego timestamp, jeśli celem jest sensor powtarzający wartość jako świeżą. Drugi wariant — zatrzymany timestamp — to timeout.

Awarie magistrali#

Jeśli HIL wstrzykuje dane nad driverem, magistrala pozostaje nieprzetestowana. Dla własnego FC warto zbudować emulator peryferium:

SPI slave/FPGA emulujący IMU register map,
CAN node publikujący DroneCAN,
UART GNSS z binarnym protokołem,
I²C emulator dla barometru.

Faults obejmują CRC/status, timeout, stuck bus, błędny node ID, restart peryferium i zmianę rate. Nie wprowadza się zwarć elektrycznych bez dedykowanego, zabezpieczonego fault-injection hardware.

Warstwa elektryczna wymaga oscyloskopu i bezpiecznych limitów napięcia/prądu.

Porównanie z SITL#

Ten sam scenariusz uruchamia się w SITL i HIL. Porównuje się:

trajectory i mode transitions,
estimator states/innovations,
actuator commands,
eventy i failsafe,
CPU/loop timing tylko w HIL,
latency transportu,
różnice wynikające z precision i scheduler.

Nie oczekuje się bitowej zgodności floating point między x86 i MCU. Ustala się tolerancje sygnałów i czasów. Duża systematyczna różnica wymaga wyjaśnienia.

HIL bez SITL baseline utrudnia ustalenie, czy błąd wynika z logiki, hardware czy adaptera.

Bring-up stanowiska#

Etap 1 — loopback transportu#

Bez FC wysłać test vectors przez adapter i potwierdzić framing, CRC, sequence, endianess i rate.

Etap 2 — FC bez regulatora#

Wstrzyknąć stan spoczynkowy, odczytać raw sensor topics i sprawdzić jednostki/osi.

Etap 3 — estymator#

Wykonać powolne ruchy jednej osi, porównać ground truth i estimate.

Etap 4 — wyjścia#

Pobudzić manual/test commands przy fizycznie odłączonych aktuatorach. Potwierdzić kanały i zakres.

Etap 5 — zamknięcie pętli#

Uruchomić regulator z idealnym modelem, małymi setpointami i limitami.

Etap 6 — realizm#

Dodać opóźnienie aktuatora, szum i warunki środowiska pojedynczo.

Etap 7 — faults#

Najpierw dropout jednego sensora, potem stuck/bias, dopiero na końcu kombinacje.

Testy regulatora#

Wymuszenia testowe:

mały step rate,
sweep częstotliwości o bezpiecznej amplitudzie,
gust/impuls momentu,
saturacja i powrót,
zmiana masy/inertia modelu,
utrata jednego aktuatora.

Mierzy się rise time, overshoot, settling, steady error, actuator saturation i phase delay. Sweep nie może pobudzać nierealnych częstotliwości poza pasmem modelu.

Tuning z HIL jest wiarygodny tylko po walidacji modelu napędu i inertia. W przeciwnym razie testuje implementację regulatora, nie wartości gain dla lotu.

Testy estymatora#

Scenariusze:

start statyczny i bias convergence,
kontrolowany obrót każdej osi,
GNSS latency/dropout/step,
magnetometer bias zależny od throttle,
barometer ramp,
IMU clipping i utrata jednej instancji,
przejście między source lanes.

Porównuje się estimate z ground truth oraz innovations/test ratios. Ground truth nie może przypadkowo trafiać do filter jako measurement.

Model noise powinien raportować variance spójną z generowanym błędem. Zbyt duża zadeklarowana dokładność wymusza nieuzasadnione odrzucenia innych sensorów.

Testy failsafe#

Maszyna stanów testu:

nominal → inject → detect → action → containment → recovery/end

Kryteria obejmują wszystkie przejścia. Przykład utraty HIL link:

heartbeat gap > limit,
FC oznacza sensors stale/unhealthy,
physical outputs pozostają inhibited,
model przechodzi do unpowered lub stop,
event zapisany,
recovery wymaga nowej sesji lub jawnego resetu.

Nie uznaje się testu za zaliczony tylko dlatego, że system się zresetował. Reset może być niekontrolowaną awarią, nie właściwym failsafe.

Rejestracja i replay#

Stanowisko loguje:

wszystkie wejściowe ramki wraz z czasem wysłania/odbioru,
output FC,
ground truth co najmniej z rate sterowania,
model parameters i seed,
log FC,
GPIO/logic analyzer trace dla wybranych testów,
eventy adaptera i queue metrics.

Replay może ponownie podać ten sam strumień sensorów do FC, lecz zamknięta pętla przestaje być zgodna po pierwszej różnicy output. Replay jest wartościowy dla parsera/estymatora; dla controller potrzebna jest resymulacja modelu.

Plik logu ma schema version i checksum. Nie używa się CSV bez dokładności timestamp i jednostek jako jedynego źródła.

Automatyzacja regresji#

Test runner:

sprawdza fizyczny inhibit,
resetuje FC kontrolowanym przekaźnikiem/USB,
weryfikuje build ID i reset reason,
negocjuje protocol/session,
ustawia model i seed,
czeka na estimator ready,
wykonuje scenario,
ocenia asercje online,
kończy/disarm,
pobiera logi i sprawdza asercje offline,
tworzy raport.

Każdy test ma timeout i teardown. Po błędzie wyjścia są fizycznie bezpieczne, model zatrzymany, a logi zachowane.

CI nie powinno współdzielić jednego FC między równoległymi jobami bez arbiter/lock. Build flashing i USB enumeration są zasobem stanowym.

Kryteria zaliczenia#

Interfejs#

zero nieoczekiwanych CRC, duplikatów i out-of-order,
drop/jitter poniżej jawnych limitów,
poprawne jednostki i osie dla test vectors,
timeout przechodzi do safe state,
nowe session odrzuca stare ramki.

Czas#

sensor period w tolerancji,
sample-to-actuator p99 poniżej budżetu,
brak timestamp regressions,
queue age nie narasta,
watchdog deadlines spełnione.

Lot/model#

estimator error i innovations w limitach,
controller tracking w envelope,
brak nieuzasadnionej saturacji,
fault detection/action w wymaganym czasie,
różnica SITL–HIL w ustalonej tolerancji.

Bezpieczeństwo#

energia trakcyjna fizycznie odłączona,
output inhibit potwierdzony pomiarem,
reset/boot nie generuje niebezpiecznej komendy,
teardown działa po timeout i crash runnera.

Ograniczenia#

HIL nie zastępuje:

testu z rzeczywistym IMU i wibracją, jeśli sensor jest emulowany nad driverem,
EMC/EMI i odporności zasilania,
termiki MCU/ESC,
mechanicznego napędu i śmigła,
RF link budget,
prób strukturalnych,
walidacji modelu aerodynamiki,
lotu w kontrolowanej obwiedni.

Stanowisko może wręcz ukryć błąd, jeśli adapter normalizuje niepoprawne dane lub zbyt idealnie synchronizuje sensory. Adapter jest elementem testowanym i musi mieć własne unit/integration tests.

Scenariusz referencyjny#

Cel#

Sprawdzić własny STM32 FC w pętli quadrotora: nominalny zawis, GNSS dropout, zamrożenie jednej IMU i reset FC. Aktuatory fizycznie odłączone.

Konfiguracja#

fixed-step 1 ms, lockstep,
IMU 1 kHz, mag 100 Hz, baro 50 Hz, GNSS 10 Hz + 120 ms latency,
model silnika pierwszego rzędu z time constant z hamowni,
dwa źródła IMU w firmware,
MAVLink lub wersjonowany protokół własny,
GPIO dla sensor IRQ, estimator i actuator publish.

Baseline#

Stan spoczynkowy 10 s, arm-sim, takeoff do 5 m, zawis 20 s, małe setpointy roll/pitch/yaw, land. Sprawdzić error, latency, jitter, saturację i log.

GNSS dropout#

W nowej sesji zatrzymać GNSS na 15 s podczas zawisu. Potwierdzić timeout, source state, drift, action i recovery. Nie zmieniać IMU równocześnie.

IMU stuck#

Zamrozić wartości pierwszej IMU z rosnącym timestamp. Potwierdzić innovations/consistency, przełączenie na drugą instancję i brak niekontrolowanego output.

Reset#

Zresetować FC podczas lotu modelowego. Model przechodzi do zdefiniowanego unpowered state. Potwierdzić physical inhibit, reset reason, nową session i brak przyjęcia starych ramek.

Raport#

build IDs FC/adapter/model,
spec protokołu i test vectors,
manifest modelu/seed,
log FC i ground truth,
trace GPIO/UART,
histogram latency/jitter,
expected/actual dla każdego przejścia,
ograniczenia pokrycia.

Powiązane tematy#

Przypisy#

MAVLink, Common Message Set — definicje HIL_SENSOR, HIL_GPS, HIL_STATE_QUATERNION i HIL_ACTUATOR_CONTROLS wraz z jednostkami i polami.
PX4, Hardware Simulation — rozróżnienie zewnętrznego HITL (SYS_HITL=1) i SIH na hardware (SYS_HITL=2).
PX4, Simulation — architektura SITL/HITL, time/lockstep i interfejs simulatora.
PX4, SIH Simulation — model fizyki wewnątrz PX4, uORB i zakres wspieranych pojazdów.
PX4, SIH on Flight Controller Hardware — uruchomienie modelu na rzeczywistym autopilocie i ograniczenia buildów.
ArduPilot, Simulation on Hardware — wbudowany model SITL na kontrolerze, symulowane sensory i zastosowania do misji/failsafe.
ArduPilot, Using Simulation Parameters to Control the Simulation — modele błędów, środowiska i parametry symulacyjne.
Sumit Sharma, Drone Development from Concept to Flight — architektura autopilota, pętle sterowania, sensory i stopniowa walidacja konstrukcji.

Źródła z centralnego rejestru

MAVLink Common Message Set: HIL_SENSOR, HIL_GPS, HIL_STATE_QUATERNION and HIL_ACTUATOR_CONTROLS [specyfikacja protokołu]
PX4 Guide: Hardware Simulation [dokumentacja projektu open source]
PX4 Guide: SIH Simulation [dokumentacja projektu open source]
PX4 Guide: SIH on Flight Controller Hardware [dokumentacja projektu open source]
PX4 Simulation [dokumentacja]
ArduPilot Dev: Simulation on Hardware [dokumentacja projektu open source]
ArduPilot: Using Simulation Parameters to Control the Simulation [dokumentacja]
Sumit Sharma, „Drone Development from Concept to Flight” [książka]