PX4 i Gazebo — laboratorium SITL

PX4 SITL z Gazebo uruchamia kod stosu lotu jako proces POSIX, natomiast Gazebo oblicza dynamikę świata, kontakt, sensory i ruch modelu. Bridge wymienia stany sensorów oraz komendy aktuatorów i synchronizuje czas. Taki układ pozwala testować misje, percepcję, modele SDF, wiele pojazdów i reakcje failsafe, ale nadal nie odtwarza elektryki flight controllera, realnych magistral, tolerancji wykonania ani całej aerodynamiki platformy.[3][4]

Nazwa „Gazebo” jest dziś niejednoznaczna. Aktualny Gazebo — wcześniej rozwijany jako Ignition i w bieżących wydaniach spotykany m.in. jako Gazebo Harmonic — używa targetów gz_*. Gazebo Classic ma osobne targety gazebo-classic_*, inne modele i schodzącą ścieżkę wsparcia w PX4. Nowe laboratorium powinno zaczynać od aktualnego Gazebo, chyba że konkretny model lub integracja nadal wymaga Classic.[3]

Spis treści#

Zakres laboratorium
Gazebo a Gazebo Classic
Architektura i lockstep
Wersje i manifest testu
Klon oraz submoduły
Środowisko deweloperskie
Pierwszy start modelu gz-x500
Konsola pxh
QGroundControl
Modele pojazdów
Worlds
Pozycja i orientacja startowa
Parametry sesji
ULog i artefakty
Pierwszy lot
Misja automatyczna
Headless CI
Speed factor
Standalone mode
Gazebo transport i diagnostyka
Kamera, depth i lidar
Własny model SDF
Masa, bezwładność i kolizje
Model napędu
Układy współrzędnych
Failure injection
Utrata GNSS
Usterka sensora
Utrata silnika
Test data-link failsafe
Multi-vehicle
ROS 2 i uXRCE-DDS
Automatyzacja przez MAVSDK
Kryteria zaliczenia
Typowe awarie środowiska
Ograniczenia modelu
Od SITL do HIL
Scenariusz laboratoryjny
Powiązane tematy
Przypisy

Zakres laboratorium#

Laboratorium prowadzi od czystego checkoutu do powtarzalnego testu:

identyfikacja commitu PX4 i wersji Gazebo,
build targetu px4_sitl,
uruchomienie x500 w kontrolowanym world,
połączenie QGroundControl i sprawdzenie preflight,
lot nominalny oraz misja,
zabezpieczenie ULog i parametrów,
uruchomienie headless z kontrolą czasu,
wstrzyknięcie wspieranej awarii,
sprawdzenie eventu, mode i trajektorii,
test regresyjny w czystej instancji.

Nie obejmuje strojenia rzeczywistego UAV na podstawie samego modelu. Do tego potrzebna jest identyfikacja parametrów, porównanie z lotem i dalsze etapy walidacji.

Gazebo a Gazebo Classic#

Rozróżnienie w poleceniach:

# Aktualny Gazebo
make px4_sitl gz_x500

# Gazebo Classic — osobna, starsza integracja
make px4_sitl gazebo-classic_iris

Modele nie są wymienne. Plik SDF/plugin z Classic może używać innych nazw bibliotek i API. Dokumentacja PX4 określa aktualny Gazebo jako domyślne rozwiązanie dla nowych projektów, a Classic jako ścieżkę community-supported/deprecating.[3][5]

Raport powinien podawać pełną wersję Gazebo, nie tylko słowo „Gazebo”. Polecenie gz sim --versions lub właściwe narzędzie danego wydania pozwala ustalić komponenty; dostępna składnia zależy od instalacji.

Jeśli projekt jest migrowany z Classic, najpierw odtwarza się baseline w starym środowisku, następnie sprawdza masę, inertia, sensory, pluginy i charakterystykę napędu w nowym. Podobny obraz nie dowodzi równoważnej fizyki.

Architektura i lockstep#

Podstawowy przepływ:

Gazebo physics/world
  ├── IMU/GNSS/baro/mag/camera
  └── model pose/velocity
          ↓ gz transport / PX4 bridge
PX4 SITL
  ├── drivers/uORB/EKF/controllers
  ├── actuator outputs
  ├── MAVLink → QGC/MAVSDK
  └── ULog
          ↓
Gazebo motor/servo systems

W lockstep PX4 i symulator przechodzą czas symulowany zgodnie z krokami fizyki. Zapobiega to sytuacji, w której kontroler oblicza kilka sekund podczas jednego kroku świata. Nie oznacza jednak, że host zawsze utrzyma real time; przy przeciążeniu real-time factor spada.[3][4]

Przy debug breakpoint czas symulowany może się zatrzymać, ale zewnętrzny GCS albo skrypt używający czasu ściennego może zgłosić timeout. Test musi jawnie określić bazę czasu.

Wersje i manifest testu#

Przed uruchomieniem:

git rev-parse HEAD
git describe --always --dirty
git submodule status --recursive
gz sim --version
cmake --version
python3 --version

dirty wymaga zapisania diff. Submoduł modeli Gazebo ma własny commit i wpływa na wynik równie mocno jak kod PX4.

Manifest powinien zawierać:

commit PX4 i submodułów,
system operacyjny i architekturę,
wersję Gazebo,
dokładny target make,
environment variables,
model/world i pose,
effective PX4 parameters,
mission i oczekiwane kryteria,
identyfikator logu.

Bez manifestu dwa polecenia make px4_sitl gz_x500 po aktualizacji repozytorium mogą reprezentować inne modele.

Klon oraz submoduły#

git clone --recursive https://github.com/PX4/PX4-Autopilot.git
cd PX4-Autopilot
git status --short
git submodule status --recursive

Jeżeli submodułów brakuje:

git submodule update --init --recursive

Do regresji wybiera się tag lub SHA. Po przełączeniu:

git submodule sync --recursive
git submodule update --init --recursive

Nie miesza się model repozytorium PX4-gazebo-models z przypadkową wersją bridge. Interfejs SDF i nazwy topiców mogą się zmienić.

Środowisko deweloperskie#

PX4 dostarcza skrypty instalacyjne i dokumentację dla obsługiwanych systemów. Pakiety Gazebo są zależne od dystrybucji, dlatego aktualna strona development environment jest źródłem nadrzędnym.[2]

Po instalacji pierwszy build weryfikuje cały toolchain:

make px4_sitl gz_x500

Nie należy ręcznie doinstalowywać losowych bibliotek po pierwszym błędzie linkera. Najpierw sprawdza się obsługiwaną kombinację system–release, stan submodułów i log skryptu instalacyjnego.

Kontener jest dobrym rozwiązaniem CI, ale GUI wymaga przekazania display/GPU. Dla testów logiki zwykle lepszy jest headless.

Pierwszy start modelu gz-x500#

Z katalogu głównego PX4:

make px4_sitl gz_x500

Target buduje px4_sitl, uruchamia PX4, Gazebo, bridge i model x500. Powinna pojawić się konsola pxh> oraz okno świata. PX4 publikuje MAVLink, dzięki czemu lokalny QGroundControl zwykle wykrywa pojazd automatycznie.[2][3]

Pierwszy start weryfikuje:

brak błędu build,
start gz server i GUI,
pojawienie się modelu,
dane sensorów w PX4,
poprawną inicjalizację EKF,
heartbeat w QGC,
zapis ULog.

Model stojący w GUI bez heartbeat nie jest poprawnym startem. Heartbeat bez ruchu modelu może oznaczać problem bridge lub złe topic names.

Konsola pxh#

Podstawowe polecenia:

ver all
param show SYS_AUTOSTART
listener sensor_gps
listener vehicle_local_position
listener vehicle_status
uorb top
work_queue status

listener potwierdza rate i wartości konkretnego topicu. Należy odróżnić sensor_* od przefiltrowanych vehicle_*. uorb top pomaga wykryć brak publikacji lub nadmierny rate.

Polecenia modułów zmieniają się z wersją; help i module help są nadrzędne. Output konsoli zapisuje się jako artefakt.

QGroundControl#

QGC powinien odebrać heartbeat po UDP. Przed takeoff sprawdza się:

właściwy airframe i system ID,
brak krytycznych preflight failures,
global/local position valid zgodnie z mode,
home position,
stan baterii symulowanej,
geofence oraz failsafe,
active flight mode.

Nie wyłącza się checków tylko po to, by polecenie takeoff zadziałało. Brak gotowości jest wynikiem diagnostycznym.

Jeśli QGC nie łączy się, sprawdza się proces mavlink, porty, interfejs sieciowy, firewall i czy inna instancja nie używa identycznego portu.

Modele pojazdów#

Lista targetów jest wersjonowana. Przykłady aktualnego Gazebo obejmują:

make px4_sitl gz_x500
make px4_sitl gz_x500_depth
make px4_sitl gz_standard_vtol
make px4_sitl gz_rc_cessna
make px4_sitl gz_rover_differential

Nie każdy target istnieje w każdym wydaniu. Aktualna dokumentacja vehicles i listy CMake są autorytatywne.[5]

Wybór modelu obejmuje nie tylko geometrię. Model może mieć inny airframe autostart, sensory, motor constants, mass/inertia i pluginy. Nie ładuje się parametrów x500 do samolotu tylko dlatego, że PX4 je przyjmuje.

Worlds#

World definiuje teren, obiekty, światło, wiatr i pluginy. Domyślny jest prosty świat, a projekt udostępnia m.in. środowiska walls, windy, aruco, moving platform i inne zależnie od wersji.[6]

Wybór:

PX4_GZ_WORLD=walls make px4_sitl gz_x500

lub target łączony opisany w danym wydaniu. PX4_GZ_WORLD jest ignorowany, jeśli proces podłącza się do już działającego świata; trzeba wtedy sprawdzić, który gz server rzeczywiście pracuje.[4]

World z przeszkodami nie aktywuje automatycznie obstacle avoidance. Model musi mieć sensor, PX4 lub companion musi odbierać dane, a właściwa logika musi być skonfigurowana.

Pozycja i orientacja startowa#

PX4_GZ_MODEL_POSE określa pozycję i orientację modelu:

PX4_GZ_MODEL_POSE="2,3,0.2,0,0,1.57" \
  make px4_sitl gz_x500

Składnia to x,y,z,roll,pitch,yaw, pozycja w metrach, kąty w radianach.[4] Trzeba uwzględnić wysokość podwozia, aby model nie startował w kolizji z podłożem.

Pose świata Gazebo nie jest bezpośrednio latitude/longitude. Bridge i spherical coordinates mapują lokalny świat do globalnej pozycji. Test geofencing wymaga sprawdzenia obu układów.

Moving platform ma własne parametry prędkości i heading zależne od world; model trzeba umieścić na właściwej wysokości.[6]

Parametry sesji#

Parametr PX4 można nadpisać dla startu:

PX4_PARAM_COM_ARM_WO_GPS=0 make px4_sitl gz_x500

Mechanizm PX4_PARAM_<name> jest wygodny w CI, lecz wszystkie nadpisania muszą znaleźć się w manifeście.[3]

Parametry są też zapisywane w katalogu rootfs/build instance. make clean może je zresetować, a ponowne użycie buildu może zachować. Test powinien jawnie kontrolować czystość oraz wyeksportować effective params.

Nie należy mylić parametrów PX4 z environment variables Gazebo i SDF properties. Zmiana MPC_* nie zmienia masy modelu.

ULog i artefakty#

PX4 zapisuje ULog w katalogu instancji SITL. Dokładna ścieżka zależy od buildu i sposobu uruchomienia. Po locie identyfikuje się plik po timestamp i zawartości, a nie tylko „najnowszym pliku”, jeśli kilka procesów działa równolegle.[10]

Pakiet artefaktów:

.ulg,
output pxh i Gazebo server,
manifest wersji,
param export,
mission plan,
model/world SDF lub commity,
skrypt testowy,
wynik expected/actual,
opcjonalnie rosbag/gz log.

ULog zawiera dane PX4, nie pełny stan fizyki Gazebo. Do diagnozy kontaktu lub pluginu potrzebny może być log symulatora.

Pierwszy lot#

Po gotowości i połączeniu GCS w pxh>:

commander takeoff

PX4 przechodzi przez arming i takeoff zgodnie z bieżącą konfiguracją. Lądowanie:

commander land

Po zakończeniu czeka się na disarm oraz zamknięcie logu przed zatrzymaniem procesu. Ctrl+C podczas zapisu może pozostawić plik bez końcowych rekordów, choć ULog jest projektowany do częściowej odzyskiwalności.

Baseline mierzy czas startu, wysokość, pozycję, attitude tracking, eventy i lądowanie. Dopiero po jego przejściu dodaje się world i faults.

Misja automatyczna#

Misję przygotowuje się w QGC albo przez MAVSDK/MAVLink. Minimalny plan zawiera takeoff, kilka waypointów, zmianę wysokości oraz land/RTL. Po upload sprawdza się liczbę elementów i home.

Kryteria:

mission mode został przyjęty,
wszystkie itemy osiągnięto w kolejności,
odchylenie pozycji i wysokości mieści się w tolerancji,
brak nieoczekiwanych mode changes i estimator resets,
zakończenie prowadzi do oczekiwanego land/disarm,
ULog zawiera pełny odcinek.

Wizualne przejście obok punktu nie wystarcza. Sprawdza się mission result i trajectory.

Headless CI#

Bez GUI:

HEADLESS=1 make px4_sitl gz_x500

Headless ogranicza wymagania renderingu i jest preferowany dla testów sterowania/failsafe.[4] Sensor kamery może jednak wymagać renderingu; „headless” może nadal potrzebować backendu renderowania albo osobnego trybu bez sensora.

CI musi mieć timeout, zbierać logi także po błędzie i poprawnie zakończyć procesy potomne. Pozostawiony gz server może sprawić, że kolejny test dołączy do starego world.

Kryterium startu nie powinno być stałym sleep 20; skrypt czeka na heartbeat, health i gotowość estymatora.

Speed factor#

PX4_SIM_SPEED_FACTOR=2 make px4_sitl gz_x500

ustawia żądany współczynnik szybkości. Lockstep utrzymuje spójność czasu symulowanego, lecz CPU/GPU może ograniczyć osiągalny real-time factor.[3][4]

Przy większym factor zewnętrzny QGC, MAVSDK i ROS 2 mogą nie nadążyć. Timeout oparty na czasie ściennym może wywołać fałszywy failsafe. Każdy test należy najpierw potwierdzić przy factor 1.

Raportuje się factor żądany i osiągnięty. Sama wartość environment variable nie dowodzi, że host ją utrzymał.

Standalone mode#

PX4 i Gazebo można uruchomić osobno:

PX4_GZ_STANDALONE=1 make px4_sitl gz_x500

PX4 czeka wtedy na wykrycie gz server. Tryb pozwala uruchamiać symulator na innym hoście i osobno zarządzać modelami/world.[4]

Zalety:

jawne logi obu procesów,
niezależny restart PX4 lub świata,
łatwiejsze custom resource path,
rozdzielenie obciążenia.

Ryzyka to wersje bridge/model, discovery sieciowe, firewall i opóźnienie. Komunikat o timeout wykrycia Gazebo oznacza brak kompatybilnego servera, nie awarię EKF.

Gazebo transport i diagnostyka#

Narzędzia gz topic, gz service i gz model pozwalają oglądać graf komunikacji, ale zestaw subcommands zależy od wydania. Typowe pytania:

czy world istnieje,
czy model ma oczekiwaną nazwę,
czy sensory publikują z rate,
czy actuator commands docierają,
czy simulation time postępuje,
czy real-time factor nie spadł do zera.

Porównuje się topic Gazebo z odpowiednim uORB. Dane w Gazebo, ale brak w listener, wskazują bridge/naming/config. Brak już w Gazebo wskazuje model/plugin/world.

Nazwy modelu mają znaczenie w multi-instance; nie należy hardcodować x500 bez uwzględnienia suffixu.

Kamera, depth i lidar#

Modele z kamerą/depth/lidar mają dodatkowe sensory i większe obciążenie. Przed testem percepcji potwierdza się:

pose sensora względem body,
intrinsics, rozdzielczość, FOV i rate,
depth units i invalid values,
timestamp względem PX4,
transport do ROS/companion,
latency oraz dropped frames.

Idealny obraz bez rolling shutter, motion blur i ekspozycji może zawyżać wyniki algorytmu. Do walidacji dodaje się realistyczny szum i porównuje z realnym datasetem.

Lidar musi mieć właściwy min/max range, update rate i collision geometry świata. Promień może przechodzić przez visual mesh, jeśli collision mesh jest inny.

Własny model SDF#

SDF opisuje linki, joints, inertial, collision, visual, sensors i systems/plugins. Minimalna kolejność:

skopiować najbliższy model zgodny z aktualnym Gazebo,
nadać unikalną nazwę,
ustawić masę, środek masy i tensor inertia,
zdefiniować collision osobno od visual,
umieścić silniki/serwa oraz ich osie,
skonfigurować sensory i pose,
dodać model do resource path,
uruchomić test bez PX4 i sprawdzić stabilność,
dopiero potem połączyć bridge/airframe.

Pliki w GZ_SIM_RESOURCE_PATH mogą być używane bez kopiowania do źródeł PX4, ale automatyczny target gz_<model>_<world> wymaga odpowiednich wpisów build w trybie zintegrowanym.[4]

Do repozytorium dołącza się źródłowy SDF i assety z licencjami, nie tylko cache pobrany przez Gazebo.

Masa, bezwładność i kolizje#

Masa nie wystarcza. Tensor inertia determinuje odpowiedź kątową:

τ = I · α + ω × (Iω)

Nierealistycznie mała inertia daje zbyt szybkie obroty i tuning nieprzenoszalny na sprzęt. Diagonalny tensor bez produktów bezwładności jest poprawny tylko w odpowiednio dobranych osiach głównych.

Środek masy musi być zgodny z geometrią aktuatorów. Collision mesh powinien być prostszy od visual, ale nie może przecinać podłoża przy spawn. Zbyt skomplikowana kolizja obniża real-time factor i generuje niestabilne kontakty.

Warto wykonać test swobodnego opadania, kontaktu, stałego ciągu oraz momentu przed autopilotem. Stabilny hover kontrolera może maskować błędny model.

Model napędu#

Model wirnika zwykle mapuje komendę na prędkość i siłę/moment z parametrami dynamiki. Trzeba sprawdzić:

stałą siły i momentu,
kierunek obrotu,
time constant spin-up/spin-down,
limit RPM,
położenie i oś,
drag/moment reaction,
zachowanie przy wyłączeniu.

Parametry powinny pochodzić z hamowni albo identyfikacji. Jeśli model ma natychmiastową odpowiedź, failsafe i tuning będą zbyt optymistyczne.

Gazebo nie symuluje automatycznie desync, termiki i spadku baterii zgodnie z konkretnym ESC. Potrzebne są dodatkowe modele lub osobne testy.

Układy współrzędnych#

Gazebo typowo operuje w ENU/world, PX4 wewnętrznie używa konwencji NED/FRD w wielu interfejsach. Bridge wykonuje transformacje. Błąd osi może wyglądać jak niestabilny kontroler.

Sprawdza się testem jednostkowym:

dodatnie przesunięcie world X/Y i wynik local position,
yaw 90° i heading,
pose sensora względem body,
wektor grawitacji w IMU,
kierunek siły każdego silnika.

Nie poprawia się znaku metodą prób w kontrolerze, jeśli przyczyna jest w SDF/bridge.

Failure injection#

PX4 ma moduł obsługujący MAV_CMD_INJECT_FAILURE. Włącza się go parametrem:

param set SYS_FAILURE_EN 1

Następnie w pxh> używa się polecenia failure <unit> <type>. Dokładną listę pokazuje pomoc bieżącej wersji. Dokumentacja podkreśla, że dostępność danego typu zależy od symulatora; zaakceptowane polecenie nie zawsze oznacza, że model rzeczywiście zastosował awarię.[7]

Test musi potwierdzić trzy rzeczy:

komenda została zaakceptowana,
surowy topic/symulator rzeczywiście zmienił zachowanie,
PX4 wykrył skutek i wykonał oczekiwaną reakcję.

Nie wystarcza komunikat „failure injected”.

Utrata GNSS#

Po SYS_FAILURE_EN=1:

failure gps off

zatrzymuje wspieraną publikację GNSS, stuck zamraża ostatnią wartość, a wrong generuje błędne dane w zakresie implementowanym przez symulator. Przywrócenie:

failure gps ok

Dokumentacja aktualnego PX4 podaje, że symulowany GPS wspiera tylko część typów. Test obserwuje sensor_gps, fusion flags, innovations, local/global position, event i flight mode.[7][8]

wrong jest testem odporności estymatora w symulacji, nie instrukcją radiowego spoofingu. Nie generuje sygnału RF i pozostaje bezpiecznym wstrzyknięciem programowym.

Usterka sensora#

Możliwe typy obejmują off, stuck, a zależnie od komponentu także inne. Przykładowa logika testu żyroskopu:

param set SYS_FAILURE_EN 1
failure gyro stuck

Przed testem trzeba wiedzieć, ile instancji IMU istnieje i która jest primary. Awaria wszystkich instancji bada inną maszynę stanów niż awaria jednej z redundancją.

Po fault sprawdza się raw topic, sensor selection, estimator lane, failsafe i możliwość recovery. Jeśli model publikuje tylko jedną instancję, nie można wnioskować o rzeczywistej redundancji sprzętowej.

Utrata silnika#

Failure injection może adresować silnik w konfiguracjach wspierających actuator failure. Składnia i wymagany CA_FAILURE_MODE zależą od wersji.[7]

Bezpieczny SITL pozwala sprawdzić:

wykrycie utraty ciągu,
response miksera/control allocation,
degradację quad vs hexa/octa,
ograniczenia yaw i saturację,
akcję failsafe oraz lądowanie.

Modelowe wyłączenie silnika jest idealne. Realna awaria może obejmować drag z zablokowanego śmigła, asymetryczne fragmenty, zwarcie szyny i wibracje. Wynik SITL jest dolnym poziomem weryfikacji.

Test data-link failsafe#

SITL ma ustawienia ułatwiające symulację, więc nie wszystkie realne failsafe są domyślnie aktywne. Dokumentacja opisuje m.in. NAV_DLL_ACT i fakt, że data-link loss jest związany z brakiem zewnętrznych danych MAVLink.[8]

Nie testuje się tego przez zamknięcie losowego okna bez sprawdzenia, czy inny klient nadal wysyła heartbeat. Należy:

policzyć aktywne MAVLink instances,
ustawić oczekiwaną akcję,
odłączyć jedyny kontrolowany link,
zmierzyć timeout i event,
sprawdzić trajektorię,
przywrócić link i ocenić recovery.

QGC, MAVSDK i ROS bridge mogą podtrzymywać link niezależnie.

Multi-vehicle#

Każdy pojazd wymaga unikalnego instance, MAV_SYS_ID, nazw modelu, portów i katalogu danych. PX4 dokumentuje multi-vehicle dla Gazebo i innych simulatorów.[9]

Problemy typowe:

dwa pojazdy mają ten sam system ID,
QGC scala lub myli heartbeat,
model names kolidują,
obie instancje zapisują do tego samego miejsca,
offboard command trafia do niewłaściwego target,
ROS namespace i DDS key nie odpowiadają instance.

Najpierw uruchamia się dwie instancje bez autonomii, weryfikuje osobne pozycje i identyfikatory, dopiero potem wspólną misję. Test skalowania mierzy real-time factor, dropped messages i CPU, nie tylko liczbę modeli w GUI.

ROS 2 i uXRCE-DDS#

PX4 może łączyć się z ROS 2 przez uXRCE-DDS. W multi-vehicle każda instancja potrzebuje unikalnego client key i namespace. Dokumentacja wiąże key z instance/system ID w przygotowanych workflow.[9]

Przed sterowaniem offboard sprawdza się:

agent i port,
namespace każdego pojazdu,
QoS,
timestamp/time sync,
rate setpointów,
offboard timeout,
target identity.

ROS topic widoczny w ros2 topic list nie dowodzi, że PX4 go subskrybuje albo że QoS pasuje.

Automatyzacja przez MAVSDK#

Test integracyjny powinien działać na stanach, nie sleep:

wait connection
wait health/global/local position as required
upload and verify mission
arm
start mission
wait checkpoint
inject supported failure
assert raw effect
assert PX4 event/mode within deadline
assert trajectory envelope
wait land/disarm
collect ULog and process logs

MAVSDK failure plugin mapuje programowo system failure injection.[7] Każde wywołanie sprawdza result code. Timeouty rozróżniają czas ścienny i symulowany.

Proces teardown musi zakończyć PX4 oraz gz server nawet po asercji. Inaczej kolejne uruchomienie nie jest izolowane.

Kryteria zaliczenia#

Przykładowe kryteria nominalne:

build i start kończą się bez error,
model pojawia się raz we właściwym pose,
heartbeat, IMU, GNSS i local position mają oczekiwany rate,
preflight przechodzi bez wyłączania checków,
takeoff i land mieszczą się w limitach czasu/pozycji,
brak estimator reset i unexpected mode change,
ULog jest kompletny.

Dla fault:

polecenie jest wspierane i zaakceptowane,
raw source pokazuje dokładnie wstrzyknięty typ,
detekcja następuje w określonym czasie,
event/failsafe action są zgodne z parametrami,
trajectory pozostaje w envelope,
recovery albo zakończenie jest jawne,
kolejny czysty baseline przechodzi.

GUI nie jest częścią kryterium, chyba że test dotyczy renderingu.

Typowe awarie środowiska#

`unknown target gz_x500`#

Sprawdzić commit, submoduły, aktualny generator i czystość build. Dokumentacja wymienia make distclean jako rozwiązanie dla części przypadków po zmianie konfiguracji, ale jest to operacja usuwająca build artifacts — należy zachować potrzebne logi przed jej wykonaniem.[4]

PX4 czeka na Gazebo#

W standalone to normalne do startu servera. W trybie zintegrowanym sprawdzić proces gz, resource path, wersje bibliotek i output bridge.

Model spada przez podłoże#

Sprawdzić collision geometry, pose Z, physics engine i jednostki. Visual mesh nie odpowiada za kontakt.

Model się przewraca przy arm#

Sprawdzić kierunki oraz osie silników, kolejność actuator mapping, center of mass i inertia. Nie korygować PID zanim model mechaniczny jest spójny.

QGC widzi kilka pojazdów#

Zatrzymać stare instancje, sprawdzić system IDs i porty. Nie testować komend na niejednoznacznym target.

Headless działa, kamera nie#

Sensor renderowany może potrzebować backendu GPU/EGL. Rozdzielić test sterowania od perception/rendering CI.

Ograniczenia modelu#

SITL/Gazebo nie dowodzi:

stabilności elektrycznej zasilania,
poprawności DMA, ISR i driverów MCU,
odporności CAN/UART na zakłócenia,
rzeczywistej termiki silnika/ESC,
wytrzymałości ramy i śmigła,
RF link budget,
wierności aerodynamiki poza skalibrowanym zakresem,
działania payloadu o zamkniętym firmware.

Model może być „dokładny” w zawisie i błędny przy szybkim locie, ground effect, transition albo kontakcie. Walidacja modelu wymaga porównania z hamownią i lotem.

Od SITL do HIL#

Ścieżka:

unit tests PX4/module,
SITL z prostym modelem,
Gazebo z docelowym world/sensors,
automated fault tests,
replay ULog i porównanie modelu,
HIL/SIH na realnym FC,
bench integration bez śmigieł,
zabezpieczony test napędu,
lot ograniczony,
rozszerzenie envelope.

HIL dodaje hardware timing, ale model fizyki nadal może być ten sam. Nie zastępuje EMC, termiki i prób strukturalnych.

Scenariusz laboratoryjny#

Cel#

Wykonać nominalną misję x500 w world walls, następnie w oddzielnych uruchomieniach sprawdzić GNSS off i GPS wrong. Potwierdzić surowy efekt, reakcję EKF, event i akcję failsafe.

Baseline#

PX4_GZ_WORLD=walls make px4_sitl gz_x500

W pxh>:

ver all
listener sensor_gps
listener vehicle_local_position
param show SYS_FAILURE_EN

Połączyć QGC, wgrać krótką misję, wykonać takeoff–waypoints–land. Zabezpieczyć ULog i parametry.

GPS off#

W czystej instancji z identycznymi parametrami:

param set SYS_FAILURE_EN 1
failure gps off

Sprawdzić zanik sensor_gps, flags estymatora, event, mode i trajectory. Po zakończeniu:

failure gps ok

Recovery analizować jako osobny etap.

GPS wrong#

W nowej czystej instancji:

param set SYS_FAILURE_EN 1
failure gps wrong

Sprawdzić, czy symulator faktycznie generuje błędne dane, czy EKF je odrzuca oraz czy failsafe jest zgodny z konfiguracją. Nie zakładać sukcesu na podstawie ACK polecenia.

Artefakty#

commit PX4/submodułów i Gazebo version,
target, world i environment,
mission/params,
osobne ULog dla baseline/off/wrong,
PX4/Gazebo stdout,
tabela czasów fault–detection–action,
wykres raw GPS, innovations, fusion flags, mode i position.

Powiązane tematy#

Przypisy#

PX4, repozytorium PX4-Autopilot — build targets, startup POSIX, bridge, testy i modele jako wersjonowane źródło implementacji.
PX4, Building PX4 Software — aktualny toolchain i pierwszy build make px4_sitl gz_x500.
PX4, Simulation — porównanie simulatorów, target syntax, lockstep, speed factor i pozycja Gazebo Classic.
PX4, Gazebo Simulation — headless, standalone, environment variables, pose, model/world i custom resources.
PX4, Gazebo Vehicles — wersjonowana lista wspieranych modeli i targetów.
PX4, Gazebo Worlds — worlds, pluginy i przykładowe środowiska testowe.
PX4, System Failure Injection — SYS_FAILURE_EN, units/types, instance addressing, MAVSDK plugin i ograniczenia wsparcia.
PX4, Simulate Failsafes — różnice konfiguracji SITL, data-link loss i przykłady GPS off/stuck/wrong.
PX4, Multi-Vehicle Simulation — wspierane symulatory, instancje i wymagania skalowania.
PX4, ULog File Format — struktura i interpretacja logów PX4.

Źródła z centralnego rejestru

PX4 Autopilot source repository [repozytorium open source]
PX4 Guide: Building PX4 Software [dokumentacja projektu open source]
PX4 Simulation [dokumentacja]
PX4 Guide: Gazebo Simulation [dokumentacja projektu open source]
PX4 Guide: Gazebo Vehicles [dokumentacja projektu open source]
PX4 Guide: Gazebo Worlds [dokumentacja projektu open source]
PX4: System Failure Injection [dokumentacja projektu]
PX4 Guide: Simulate Failsafes [dokumentacja projektu open source]
PX4 Guide: Multi-Vehicle Simulation [dokumentacja projektu open source]
PX4: ULog File Format [specyfikacja formatu]