SITL uruchamia ten sam kod logiki autopilota jako proces na komputerze, ale zastępuje sprzęt i dynamikę pojazdu modelem programowym. Pozwala kompilować zmiany, wykonywać misje, rejestrować DataFlash i testować failsafe bez śmigieł, baterii ani ryzyka dla platformy. Nie dowodzi jednak poprawności sterowników sprzętowych, timingu magistral, odporności elektrycznej ani zgodności modelu aerodynamicznego z rzeczywistym statkiem.[3][4]

Laboratorium powinno być powtarzalne. Samo polecenie „uruchom SITL i kliknij mapę” nie wystarcza: trzeba zapisać commit ArduPilot, vehicle/frame, pliki parametrów, zawartość wirtualnego EEPROM, lokalizację, seed lub warunki symulacji, wersje narzędzi, komendy fault injection i kryteria wyniku.

Spis treści#

Co jest, a czego nie ma w SITL#

SITL obejmuje:

  • skompilowany kod ArduCopter, ArduPlane, Rover lub innego vehicle,
  • model dynamiki i środowiska,
  • emulowane sensory, aktuatory oraz część peryferiów,
  • parametry autopilota i parametry SIM_*,
  • interfejsy MAVLink do MAVProxy i GCS,
  • normalne logowanie DataFlash,
  • możliwość debugowania procesu natywnego.

Nie obejmuje automatycznie:

  • rzeczywistego MCU, cache, DMA i deadline sprzętowych,
  • szumów z konkretnego PCB i montażu,
  • brownoutu, EMI i błędów złączy,
  • dokładnej charakterystyki silnik–ESC–śmigło,
  • prawdziwego latency radia i sieci, jeśli go nie zamodelowano,
  • odkształceń, luzów, temperatury i zużycia,
  • błędów sterownika urządzenia, którego model omija warstwę sprzętową.

Wniosek z SITL brzmi więc „logika zachowała się tak w tym modelu”, a nie „rzeczywisty UAV jest bezpieczny”.

Architektura procesu#

Najczęstszy układ:

sim_vehicle.py
├── build przez waf
├── proces ArduCopter/ArduPlane SITL
│   ├── firmware logic
│   ├── model fizyki / sensory SIM
│   └── DataFlash log
└── MAVProxy
    ├── console + map
    ├── komendy/parametry
    └── forwarding MAVLink → dodatkowy GCS

sim_vehicle.py jest orkiestratorem: wybiera pojazd i frame, buduje kod, uruchamia binarium, przygotowuje argumenty oraz zwykle startuje MAVProxy.[4][7]

Proces autopilota i GCS są odrębne. Zamknięcie mapy nie musi zatrzymać symulatora, a połączenie kolejnego GCS nie tworzy nowego pojazdu. Przy diagnozie trzeba obserwować terminale obu procesów.

Wymagania i wersje#

Oficjalna dokumentacja opisuje Linux/Ubuntu i WSL2. Pakiety oraz obsługiwane wersje dystrybucji zmieniają się, dlatego nie należy utrzymywać ręcznie skopiowanej listy zależności bez sprawdzania skryptu projektu.[2][3]

Przed eksperymentem zapisuje się:

git rev-parse HEAD
git describe --always --dirty
python3 --version
./Tools/autotest/sim_vehicle.py --help

Stan dirty oznacza lokalne zmiany. Jeśli są zamierzone, do raportu dołącza się diff. Jeśli nie, wynik nie jest porównywalny z czystym commitem.

MAVProxy i pymavlink są rozwijane niezależnie. Ich wersje także należy zapisać. Aktualizacja narzędzia między testem bazowym i regresyjnym może zmienić parser albo zachowanie połączenia.

Klon repozytorium#

Repozytorium ArduPilot zawiera submoduły. Minimalny, jawny workflow:

git clone --recurse-submodules https://github.com/ArduPilot/ardupilot.git
cd ardupilot
git status --short
git rev-parse HEAD

Jeżeli repozytorium sklonowano bez submodułów:

git submodule update --init --recursive

Do laboratorium produkcyjnego wybiera się konkretny tag albo commit, a nie ruchomą nazwę gałęzi bez zapisu SHA. Przełączenie wersji wymaga synchronizacji submodułów zgodnie z repozytorium.

Nie należy uruchamiać przypadkowego sim_vehicle.py znalezionego wcześniej w PATH, jeśli na dysku jest kilka klonów. Oficjalna dokumentacja zaleca bezpośrednią ścieżkę w takim przypadku.[4]

Instalacja środowiska#

ArduPilot dostarcza skrypt przygotowujący zależności. Jego nazwa i opcje trzeba sprawdzić w aktualnym repozytorium oraz dokumentacji. Typowy workflow Ubuntu:

Tools/environment_install/install-prereqs-ubuntu.sh -y

Po wykonaniu skryptu otwiera się nową sesję terminala albo przeładowuje profil zgodnie z komunikatem instalatora. Następnie:

./waf configure --board sitl
./waf copter

Sam sim_vehicle.py potrafi uruchomić build, ale jawna kompilacja rozdziela błąd środowiska od błędu startu symulacji.

Nie uruchamia się instalatora zależności w ciemno na serwerze produkcyjnym. Najlepiej używać dedykowanej maszyny, kontenera lub obrazu CI, którego wersję można odtworzyć.

Pierwszy start Coptera#

Z katalogu głównego repozytorium:

./Tools/autotest/sim_vehicle.py \
  -v ArduCopter \
  -f quad \
  --console \
  --map \
  -w

-v wybiera vehicle, -f model/frame, a -w czyści wirtualny EEPROM i ładuje wartości domyślne. Pierwszy build może trwać dłużej. Po starcie powinny pojawić się heartbeat, parametry, status EKF i pozycja na mapie.[3][4]

Opcji -w nie używa się automatycznie przy każdym debugowaniu, ponieważ kasuje stan, który może być częścią reprodukcji. Stosuje się ją świadomie przy tworzeniu czystego baseline.

Polecenie:

./Tools/autotest/sim_vehicle.py --help

jest autorytatywną listą opcji dla bieżącego commitu.

Vehicle i frame#

Vehicle wybiera rodzinę firmware, a frame również model fizyki i zestaw parametrów. ArduPlane z parametrami QuadPlane nie jest równoważny uruchomieniu właściwego frame quadplane. Dokumentacja podkreśla, że wybór frame wpływa na fizykę symulacji.[4]

Przykłady:

./Tools/autotest/sim_vehicle.py -v ArduPlane -f plane --console --map -w
./Tools/autotest/sim_vehicle.py -v ArduPlane -f quadplane --console --map -w
./Tools/autotest/sim_vehicle.py -v Rover -f rover --console --map -w

Nazwy dostępnych frame zależą od wersji. Nie należy zakładać, że lista z artykułu jest kompletna; sprawdza się --help i pliki konfiguracji bieżącego repozytorium.

Lokalizacja startowa#

-L wybiera nazwane miejsce z Tools/autotest/locations.txt:

./Tools/autotest/sim_vehicle.py \
  -v ArduCopter -f quad \
  -L KSFO \
  --console --map -w

Lokalizacja zawiera szerokość, długość, wysokość MSL i heading. Własne miejsce powinno mieć jawny plik dołączony do scenariusza testowego, aby CI i inni inżynierowie używali tych samych danych.[4]

Wysokość MSL nie jest AGL. Błędne utożsamienie wpływa na start, terrain i misje.

Katalog instancji i eeprom.bin#

SITL zapisuje zmienione parametry w eeprom.bin w katalogu startowym/instancji. Dwa testy uruchomione z tego samego katalogu mogą więc wpływać na siebie, nawet jeśli polecenia wyglądają identycznie.[4][5]

Dobra struktura:

sitl-runs/
├── baseline-copter/
│   ├── eeprom.bin
│   ├── logs/
│   └── manifest.txt
├── gps-failsafe/
└── rc-failsafe/

Każdy scenariusz otrzymuje osobny katalog. Manifest zawiera commit, polecenie startu, param file i expected result. Nie usuwa się eeprom.bin przez przypadek; reset robi się -w lub przez przygotowanie nowego katalogu.

Reset i parametry domyślne#

Są trzy różne operacje:

  • -w — wyczyszczenie zapisanych zmian i start od domyślnych,
  • --add-param-file=<plik> — dodanie wartości jako warstwy domyślnej przy starcie,
  • param load <plik> w MAVProxy — ustawienie parametrów w działającym systemie.

Nie są równoważne. Niektóre parametry ujawniają kolejne pola dopiero po enable/reboot. Oficjalna dokumentacja opisuje możliwość ponownego param fetch, restartu lub użycia --add-param-file.[4][5]

Przykład powtarzalnego startu:

./Tools/autotest/sim_vehicle.py \
  -v ArduCopter -f quad \
  --add-param-file=tests/params/baseline.parm \
  --console --map -w

Po konfiguracji:

param save baseline-effective.parm

Zapis effective config dołącza się do wyników.

MAVProxy#

MAVProxy jest tekstowym GCS i routerem MAVLink. Podstawowe komendy:

status
mode
param show SIM_*
param show ARMING_*
module list
output

Prompt pokazuje bieżący mode. Polecenia mogą być wykonywane przed pełnym pobraniem parametrów, dlatego po starcie trzeba poczekać na gotowość systemu i komunikaty pre-arm.

Historia konsoli jest częścią wyniku. W zautomatyzowanym laboratorium zapisuje się stdout/stderr, nie tylko DataFlash.

Zewnętrzny GCS#

Można uruchomić SITL bez MAVProxy:

./Tools/autotest/sim_vehicle.py \
  -v ArduCopter -f quad \
  --no-mavproxy

Proces nasłuchuje zwykle połączenia TCP zgodnie z bieżącą konfiguracją sim_vehicle.py; dokumentacja podaje port 5760 dla podstawowej instancji.[4] QGroundControl lub Mission Planner łączy się jako TCP client.

Z MAVProxy dodatkowy GCS można zasilić przez forwarding:

output
output add 127.0.0.1:14552

Przed użyciem portu sprawdza się aktualne wyjścia. Dwa procesy konkurujące o ten sam port dają mylące objawy.

Porty i wiele instancji#

Wielopojazdowa symulacja wymaga unikalnych identyfikatorów, portów i katalogów danych. sim_vehicle.py ma opcje instancji; ich dokładną składnię sprawdza się w --help danego commitu.

Każda instancja powinna mieć:

  • unikalny SYSID_THISMAV,
  • unikalny zestaw portów,
  • osobny eeprom.bin i log directory,
  • świadomie przesuniętą pozycję startową,
  • nazwę w manifestach testu.

Wykrycie dwóch heartbeat o tym samym system ID przez GCS może prowadzić do mieszania stanów i komend.

Pierwszy lot sterowany poleceniami#

Po uzyskaniu pozycji i przejściu kontroli pre-arm:

mode GUIDED
arm throttle
takeoff 10

Przed arm należy przeczytać komunikaty i potwierdzić właściwy vehicle/frame. Po osiągnięciu wysokości można użyć mapy lub komend guided, a na końcu:

mode LAND

Nie wyłącza się kontroli arming tylko dlatego, że laboratorium nie startuje. Celem pierwszego ćwiczenia jest zrozumienie, który warunek blokuje start. Ominięcie checków tworzy inny scenariusz.

Zapisuje się moment arm, takeoff, osiągniętą wysokość, mode transitions i disarm. To baseline do dalszych awarii.

Misja waypointowa#

Misję można utworzyć w GCS albo zapisać w formacie obsługiwanym przez narzędzie. Powinna zawierać jawne:

  • home/start assumptions,
  • takeoff,
  • kilka waypointów o bezpiecznych odległościach,
  • zmianę wysokości lub prędkości potrzebną testowi,
  • RTL albo land,
  • acceptance corridor.

Po upload należy pobrać misję z powrotem i porównać liczbę oraz parametry elementów. Następnie:

mode AUTO
arm throttle

W zależności od vehicle i misji kolejność arming/mode może być inna. Kryterium nie brzmi „dron doleciał”, lecz: wszystkie itemy osiągnięte w kolejności, brak nieoczekiwanej zmiany mode, pozycja/prędkość w tolerancji i prawidłowe zakończenie.

Logi DataFlash i telemetria#

SITL tworzy standardowe logi DataFlash, które analizuje się tymi samymi narzędziami co lot. Lokalizacja zależy od katalogu instancji i argumentów. MAVProxy/GCS może równolegle zapisać tlog.[1][8]

Po teście zabezpiecza się:

  • binarny DataFlash log,
  • tlog,
  • stdout/stderr procesu,
  • effective parameters,
  • mission file,
  • manifest wersji i komendy,
  • expected/actual result.

W logu sprawdza się tryby, arming, EKF, pozycję, komendy aktuatorów, failsafe i eventy. Symulacja przechodząca wizualnie może zawierać niepożądany reset estymatora lub ostrzeżenie.

Speedup#

SIM_SPEEDUP przyspiesza lub zwalnia czas symulowany w obsługiwanych backendach:[5]

param set SIM_SPEEDUP 5

Duży speedup zwiększa ruch MAVLink i obciążenie hosta. Dokumentacja ostrzega, że MAVProxy może nie nadążać, co wywołuje timeouty GCS/RC niezwiązane z logiką badanego failsafe. Wynik trzeba porównać przy SIM_SPEEDUP=1.

Speedup nie przyspiesza wszystkich zależności identycznie. Usługa zewnętrzna używająca czasu ściennego może rozjechać się z czasem symulacji. Testy timing-sensitive powinny jawnie wybrać bazę czasu.

Parametry SIM#

Parametry SIM_* sterują środowiskiem i uszkodzeniami. Lista jest zależna od wersji:

param show SIM_*

Zmiany są zapisywane w wirtualnym EEPROM tak jak inne parametry. Po teście fault injection trzeba przywrócić je albo rozpocząć nową czystą instancję. Zapomniany SIM_GPS_DISABLE może sprawić, że kolejny scenariusz wygląda jak regresja.

Skrypt testowy powinien ustawiać pełny wymagany stan, nie zakładać wartości pozostawionych przez poprzednią sesję.

Wiatr i turbulencja#

Przykład dokumentacji:

param set SIM_WIND_DIR 180
param set SIM_WIND_SPD 10

Kierunek i znaczenie jednostek trzeba potwierdzić w opisie parametru bieżącej wersji. Pozostałe opcje:

param show SIM_WIND*

Scenariusz wiatru powinien obejmować fazę bez wiatru, rampę lub jawny skok, odcinek ustalony i zakończenie. Mierzy się błąd pozycji, saturację, przechylenie, prędkość oraz powodzenie misji.

Model wiatru nie odtwarza automatycznie lokalnej turbulencji budynku, propwash i elastyczności konstrukcji. Wynik służy do testu logiki oraz marginesu modelu, nie certyfikacji aerodynamicznej.

Utrata RC#

Oficjalny parametr:

param set SIM_RC_FAIL 1

symuluje utratę RC. Inne wartości mogą reprezentować neutralne kanały lub niski throttle zależnie od wersji.[5]

Przed wstrzyknięciem zapisuje się:

  • mode i pozycję,
  • parametry RC failsafe,
  • home oraz stan GNSS,
  • oczekiwaną akcję i timeout.

Po wstrzyknięciu mierzy się czas do detekcji, event, zmianę mode, trajektorię i zakończenie. Następnie przywraca się RC i sprawdza warunki odzyskania. Test tylko „pojazd zrobił RTL” nie sprawdza opóźnienia ani zachowania po powrocie linku.

Utrata GNSS#

Dokumentacja SITL podaje:

param set SIM_GPS_DISABLE 1

Wstrzyknięcie należy wykonać w określonej fazie i przy skonfigurowanym failsafe. Log powinien pokazać utratę danych, decyzję EKF, dostępność alternatywnych źródeł oraz reakcję vehicle.[5]

Nie należy testować jednocześnie utraty GNSS i RC w pierwszej próbie. Oddzielne scenariusze pozwalają zrozumieć każdą maszynę stanów, dopiero później bada się kombinacje.

Wyłączenie symulowanego GPS testuje brak danych, nie realistyczny multipath lub spoofing. Do błędnych, lecz ciągle publikowanych pomiarów potrzebny jest inny model lub wstrzyknięcie danych.

Szum i drgania sensorów#

Przykład z dokumentacji:

param set SIM_ACC_RND 3

dodaje szum przyspieszenia o parametrach opisanych w bieżącej wersji.[5] Należy odróżnić biały szum od biasu, random walk, harmonicznej i clipping. Jedna wartość random noise nie odtwarza drgań konstrukcji.

Scenariusz stopniowo zwiększa poziom i obserwuje innovations, clipping modelu, wysokość, sterowanie i failsafe. Wartość powinna wynikać z realnych logów lub planu testu, nie z arbitralnej liczby.

Awaria a reset scenariusza#

Po awarii:

  1. zapisać log przed zmianami,
  2. zapisać parametry SIM_*,
  3. przywrócić fault do zera,
  4. poczekać na recovery albo wykonać jawny restart,
  5. potwierdzić stan pre-arm/EKF,
  6. uruchomić test kontrolny.

Niektóre parametry wymagają restartu. Test recovery bez reboot i test zimnego startu po awarii są osobnymi przypadkami.

Najbezpieczniejszy automatyczny workflow tworzy nowy katalog instancji i startuje z -w oraz wersjonowanym param file dla każdego przypadku.

Simulated peripherals#

SITL potrafi emulować m.in. gimbal, rangefinder, beacon, RPM, OSD i inne urządzenia zależnie od wersji.[6] Przykład OSD:

./Tools/autotest/sim_vehicle.py \
  -v ArduPlane --console --map --osd

Emulacja peryferium może działać na poziomie wiadomości lub sterownika i nie zawsze odtwarza elektrykę interfejsu. Trzeba sprawdzić, czy test obejmuje parser, protokół, transport i model fizyczny.

Peryferia należy dodawać pojedynczo. Po każdym sprawdza się device detection, rate danych, parametry i zachowanie po utracie.

CAN i AP Periph#

Opcja opisana przez projekt:

./Tools/autotest/sim_vehicle.py \
  -v ArduPlane --console --map --can-peripherals

uruchamia wybrane sensory/aktuatory jako peryferia CAN zamiast wewnętrznych modeli.[6] Pozwala testować część zachowania DroneCAN/AP_Periph: discovery, node status, parametry i publikacje.

Nie symuluje impedancji, terminacji, common-mode, bit errors ani fizycznego bus-off bez dodatkowego modelu. Do warstwy elektrycznej potrzebny jest HIL lub stanowisko CAN.

Copter, Plane i QuadPlane#

Copter można bezpiecznie zatrzymać w zawisie i łatwo obserwować failsafe. Plane wymaga ciągłego ruchu, ma airspeed i inne ograniczenia energii. QuadPlane łączy dwa zestawy kontrolerów oraz przejścia.

Scenariusze nie są przenośne jeden do jednego:

  • utrata GNSS w Copter może prowadzić do Land/AltHold,
  • Plane potrzebuje strategii utrzymania lotu i nawigacji,
  • QuadPlane musi rozstrzygać dostępność napędu VTOL oraz fazę transition,
  • parametry failsafe i mode names różnią się.

W QuadPlane testuje się fault przed transition, w trakcie i po transition. Ten sam błąd może mieć inne skutki w każdej fazie.

Debugowanie GDB#

sim_vehicle.py wspiera uruchomienie procesu pod GDB zgodnie z --help. Typowy start:

./Tools/autotest/sim_vehicle.py \
  -v ArduCopter \
  --debug --gdb \
  --console

Opcje mogą różnić się między wersjami. Debug build zmienia optymalizację i timing, więc błąd wyścigu może zachowywać się inaczej. Breakpoint zatrzymuje autopilot, podczas gdy GCS może nadal liczyć czas ścienny i zgłosić utratę heartbeat.

Do raportu zapisuje się backtrace, dokładny ELF, commit i parametry. Adres z innego buildu nie jest użyteczny.

Sanitizery i Valgrind#

Natywny proces można badać narzędziami pamięci. sim_vehicle.py udostępnia opcje m.in. Valgrind w bieżącym kodzie projektu.[1] Test jest wolniejszy i może zmienić timing.

Wykryte naruszenie pamięci analizuje się na minimalnym scenariuszu. Brak błędu w SITL nie dowodzi braku problemu na MCU: rozmiary typów, układ pamięci, przerwania i sterowniki są inne.

Sanitizer/Valgrind to uzupełnienie unit tests i hardware tests, nie ich zamiennik.

Test automatyczny#

Minimalny test integracyjny ma etapy:

prepare clean run directory
start exact commit/frame/params
wait heartbeat and EKF healthy
upload/verify mission
arm and start
wait for checkpoint
inject fault
assert event/mode/trajectory within deadline
restore or finish
download logs and artifacts
terminate processes cleanly

Nie opiera się wyłącznie na sleep. Czeka na konkretne wiadomości i ma timeout. Po przekroczeniu timeout zapisuje stan oraz logi przed zatrzymaniem.

ArduPilot ma rozbudowane Tools/autotest i vehicle test suites. Nowy test powinien wykorzystywać istniejące helpery zamiast pisać własny router MAVLink bez potrzeby.[1]

Kryteria zaliczenia#

Kryterium musi być maszynowo mierzalne:

  • heartbeat pojawia się w N sekund czasu ściennego,
  • EKF i wymagane sensory są healthy przed arm,
  • arm przechodzi bez wyłączania checków,
  • pojazd osiąga wysokość/waypoint w tolerancji,
  • fault jest aktywowany w określonym stanie,
  • failsafe event pojawia się w określonym czasie symulowanym,
  • mode zmienia się na oczekiwany,
  • trajektoria pozostaje w envelope,
  • następuje lądowanie/disarm,
  • brak crash, assertion, watchdog i nieoczekiwanego resetu,
  • log zawiera wymagane pola.

„Mapa wygląda poprawnie” nie jest kryterium regresji.

Pułapki interpretacyjne#

Najczęstsze błędy:

  • użycie starego eeprom.bin bez świadomości,
  • uruchomienie innego klonu przez PATH,
  • frame niezgodny z parametrami pojazdu,
  • speedup powodujący timeout GCS,
  • test dwóch faultów naraz bez baseline,
  • brak rozróżnienia czasu symulacji i ściennego,
  • uznanie braku danych za błędną wartość sensora,
  • brak logu stdout i effective params,
  • nadmierna wiara w prosty model aerodynamiki,
  • przeniesienie wyniku SITL bez HIL i ground test.

Kolejny problem to tuning pod model. PID idealny w SITL może być zły na elastycznej, opóźnionej platformie. SITL służy najpierw do logiki i integracji; identyfikowany model jest potrzebny do ilościowego strojenia.

Od SITL do HIL i lotu#

Ścieżka walidacji:

  1. unit tests funkcji,
  2. SITL nominalny,
  3. SITL faults i kombinacje,
  4. replay rzeczywistych logów,
  5. HIL z prawdziwym FC i interfejsami,
  6. bench test aktuatorów bez śmigieł,
  7. restrained/hamownia zgodnie z procedurą,
  8. lot w ograniczonym envelope,
  9. rozszerzenie obwiedni.

Każdy etap ma inne pokrycie. HIL dodaje hardware timing, ale nadal może używać uproszczonej fizyki. Lot dodaje rzeczywisty model, lecz ma najmniejszą kontrolę fault injection.

Scenariusz laboratoryjny#

Cel#

Sprawdzić, czy Copter w AUTO po utracie RC kontynuuje lub przerywa misję zgodnie z konkretną konfiguracją failsafe, a po utracie GNSS przechodzi do oczekiwanej strategii bez niekontrolowanego odejścia.

Przygotowanie#

git rev-parse HEAD
./Tools/autotest/sim_vehicle.py \
  -v ArduCopter -f quad \
  -L KSFO \
  --add-param-file=tests/params/copter-failsafe.parm \
  --console --map -w

Po starcie:

param save effective-before.parm
param show SIM_*

Próba bazowa#

Wgrać krótką misję, wykonać ją bez faultu, potwierdzić waypointy, lądowanie i log. Bez udanego baseline nie przechodzić dalej.

RC fault#

W drugim czystym uruchomieniu aktywować w ustalonym punkcie:

param set SIM_RC_FAIL 1

Zanotować czas, event, mode i trajektorię. Po zakończeniu nie używać tego samego EEPROM do GNSS fault bez pełnego resetu.

GNSS fault#

W trzeciej instancji:

param set SIM_GPS_DISABLE 1

Sprawdzić surowy GPS, EKF, mode, failsafe i lądowanie. Przywrócić parametr tylko w osobnym teście recovery.

Artefakty#

  • commit i diff,
  • polecenie startu,
  • param file oraz effective params,
  • mission,
  • DataFlash i tlog,
  • terminal log,
  • tabela expected/actual z czasami,
  • wykres mode, GPS/EKF, RC, pozycji i wysokości.

Powiązane tematy#

Przypisy#

  1. ArduPilot, repozytorium projektu — kod sim_vehicle.py, Tools/autotest, vehicle test suites i build system.
  2. ArduPilot, Setting up the Build Environment on Linux/Ubuntu — oficjalny skrypt zależności i kompilacja przez waf.
  3. ArduPilot, Setting up SITL on Linux — pierwszy start, MAVProxy i wymagania środowiska.
  4. ArduPilot, Using SITL — vehicle/frame, lokalizacje, EEPROM, GCS, porty i opcje sim_vehicle.py.
  5. ArduPilot, Using Simulation Parameters to Control the Simulation — SIM_*, speedup, wiatr, RC/GNSS fault i szum sensorów.
  6. ArduPilot, Adding Simulated Peripherals to sim_vehicle — urządzenia, OSD i peryferia CAN.
  7. ArduPilot, Copter SITL/MAVProxy Tutorial — podstawowa obsługa Coptera, parametrów i misji przez MAVProxy.
  8. ArduPilot, Downloading and Analyzing Data Logs — pozyskanie i analiza DataFlash.
  9. MAVLink, Protocol Overview — heartbeat, system/component ID i transport telemetrii.

Powiązane tematy

ArduPilot — architektura i ścieżka startowaMapa stosu ArduPilot dla programisty: od uruchomienia SITL i parametrów przez bibliotekę AP_HAL po analizę logów i test zmian.Symulacja SITL, HITL i HILPorównanie poziomów symulacji i projektowanie testów, które rzeczywiście wykrywają błędy firmware, integracji oraz konfiguracji.MAVLink — architektura protokołuDokumentacyjny opis MAVLink 2: format on-wire, system/component ID, CRC_EXTRA, podpisywanie oraz semantyka usług parametrów i misji.Nawigacja waypoint UAVNawigacja waypointowa jako wykonanie wersjonowanego programu misji, a nie łączenie kropek: model pozycji i wysokości, semantyka MAV_CMD_NAV_WAYPOINT, acceptance/pass radius i przelotowe zakręty, pionowy profil i terrain frame, komendy NAV–DO–CONDITION, pętle, payload timing, transakcyjny upload, walidacja geofence/energii/łączności, pauza i wznowienie oraz logowanie i fault injection.Failsafe jako maszyna stanówFailsafe jako deterministyczny system decyzji: źródła faultów, persistence i hysteresis, priorytety reakcji, konflikty RC/GNSS/baterii, latch, recovery oraz macierz testowa.Analiza zdarzenia i crash logu UAVPowtarzalny workflow badania incydentu UAV: bezpieczeństwo miejsca, zabezpieczenie i hashowanie danych, dokumentacja wraku przed demontażem, synchronizacja zegarów i źródeł, weryfikacja kompletności logu, rekonstrukcja faz lotu, oddzielenie skutków uderzenia od przyczyny, analiza zasilania, estymatora, sterowania, aktuatorów, łącza, firmware i operatora, testowanie hipotez oraz raport z poziomem pewności i działaniami korygującymi.Testy firmware UAV: unit, integration, SITL i HILPraktyczna strategia testowania embedded flight stack: separacja HAL, fake clock, testy liczbowe i parserów, sanitizers, scenariusze SITL, HIL, fault injection oraz kwalifikacja sprzętu.Fault injection w testach UAVMetodyka fault injection dla UAV od wymagania i hipotezy awarii po automatyczną kampanię testową. Rozróżnia fault, error, failure i hazard, klasyfikuje stuck/off/delay/dropout/bias/drift/wrong-but-plausible oraz awarie aktuatorów, zasilania i łączy, pokazuje właściwe miejsce wstrzyknięcia, orkiestrację czasu, monitor/oracle, latency detekcji i recovery, deterministyczny reset, pokrycie fault space, common-cause i kombinacje. Zawiera praktyczne użycie mechanizmów PX4 i ArduPilot, ograniczenia SITL/HIL oraz bezpieczne kryteria przejścia do prób fizycznych.HIL dla własnego flight controlleraArchitektura stanowiska HIL dla własnego kontrolera: granica między prawdziwym hardware i modelem, bezpieczne odłączenie aktuatorów, pakiety sensorów oraz HIL actuator controls, układy osi i jednostki, timestamp/time authority, fixed-step i lockstep, budżet opóźnienia i jitteru, kolejki oraz utrata ramek, deterministyczny reset, watchdog i heartbeat, modele szumu/biasu/saturacji, fault injection, instrumentacja GPIO, porównanie SITL–HIL, plan bring-up oraz kryteria zaliczenia bez używania śmigieł.

Źródła z centralnego rejestru

  1. ArduPilot Autopilot Suite [repozytorium projektu open source]
  2. ArduPilot Dev: Setting up the Build Environment on Linux/Ubuntu [dokumentacja projektu open source]
  3. ArduPilot Dev: Setting up SITL on Linux [dokumentacja projektu open source]
  4. ArduPilot Dev: Using SITL [dokumentacja projektu open source]
  5. ArduPilot: Using Simulation Parameters to Control the Simulation [dokumentacja]
  6. ArduPilot Dev: Adding Simulated Peripherals to sim_vehicle [dokumentacja projektu open source]
  7. ArduPilot Dev: Copter SITL/MAVProxy Tutorial [dokumentacja projektu open source]
  8. ArduPilot: Downloading and Analyzing Data Logs [dokumentacja]
  9. MAVLink Protocol Overview [specyfikacja]