Podpora simulatoru FilghtGear pro SITL

[slimonslimon]

Ve verzi PX4 cca 1.4 býval nějak podporován simulátor FlightGear (dále jen FG). Podpora s novými stránkami PX4 zmizela, díky čemuž chybí tehdejší dokumentace.

Cíle tohoto issue je dosahnout spolupráce aktuálního FG s aktuální PX4, protože ve FG je hotový, funkční rotor.

Co se mi podařilo najít: FlightGear umí pomocí "Generic Communication" posílat a příjmat potřebná data ze simulace a do simulace. http://wiki.flightgear.org/Generic_protocol https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Docs/README.IO#l20

XML soubor, který definuje protokol a odkazuje na potřebné nody ve stromu konfigurací FG lze získat pomocí QGroundControl, který v HIL umí teoreticky spolupracovat s FG (v praxi nikoliv). Nebo v Ardupilotovi: https://github.com/dronekit/ardupilot-releases/tree/master/Tools/FlightGear Kde je i aplikace převádějící tyto zprávy seriové linky pro Hardware a možná i něco s Mavlinkem.

Co je dle mého názoru potřeba naprogramovat je aplikace, která se připojí na flightgear a dále na Mavlink PX4 (SITL) viz: https://dev.px4.io/v1.9.0/en/simulation/

příklad Mavlink komunikace s PX4 lze nalézt v pluginech Gazeba: https://github.com/ThunderFly-aerospace/sitl_gazebo/blob/autogyro-sitl/src/gazebo_mavlink_interface.cpp

[slimonslimon]

Plán boje:

zaklad:

• [x] Aktuální FG
• [x] Model letadla pro FG (http://wiki.flightgear.org/Rascal_110)
• [x] Test vypisující letové hodnoty (např GPS) z FG do konzole (vypis vyšky)
• [x] Test ovládání letadla z aplikace mimo FG (nastavení plynu prvního motoru)
• [x] Test Mavlink komunikace s SITL PX4
• [x] Prototyp aplikace
• [x] Skript na spuštění (přidání noveho simulatoru do build systemu)
• [x] Vyber modelu - konfigurace vystupu mixeru a nodu property tree
• [x] Upsampling dat ze senzoru
• [x] Vyřešit správný překlad Lockstep/Non-lockstep

Podpora Autogyro:

• [x] nový model Vírníku
• [x] mapování ovládacích prvků
• [ ] přenos otáček rotoru

[kaklik]

Možná, že zde by bylo možné najít spojence: https://github.com/PX4/Firmware/issues/10425 Je tam třeba @clolsonus, který vypadá, že by ti s tím rád pomohl.

[slimonslimon]

No vidíš to, já tohle "samozžejmě" četl, ale viděl jse datum 2016, nenapadlo mě, že @clolsonus na to reagoval letos...

spolupráci promyslím, zkusím kontaktovat... (dle levelu mojí asocíálnosti to bude tak do týdne)

[slimonslimon]

Poznámka: FG posílá data maximálně stejnou frekvencí jako má FrameRate, při dosažení FPS 60, se zdá, že data budí v QGC korelují s budíky ve FG od commitu: 0b99cf4e6055477d2d5a2168ad11a48d2c0dad3b

občas si PX4 stěžuje na TImeout akceleratoru, ale ne moc často.

[slimonslimon]

První lítatelná verze: 4ffc1f483b9416fd8b4474f72bd246d3f0d0a695

[kaklik]

Poznámka: FG posílá data maximálně stejnou frekvencí jako má FrameRate, při dosažení FPS 60, se zdá, že data budí v QGC korelují s budíky ve FG od commitu: 0b99cf4

občas si PX4 stěžuje na TImeout akceleratoru, ale ne moc často.

Podle popisu který je tady. si myslím. že je to tak. že FDM vždy běží na ~120Hz. Ale hodnoty se do property-tree zapisují skutečně jen podle FPS, takže se díky přenosu skrz property-tree zahazují některé výpočty. Podle toho odkazovaného popisu ale FDM samotný běží fixně na téměř přesně 120 Hz (problém nastává jen když FPS není soudělný se 120Hz), takže je celkem škoda, ze se v nejlepším případě zahazuje polovina výsledků výpočtu, protože FPS nemůže být více jak 60Hz.

[kaklik]

No vypadá to, že vyčerpávající odpovědí je toto vlákno na fg fóru. Update rate jednotlivých parametrů v property-tree je tak různý a lze ho ovlivnit nastavením.