Získání polohy, orientace, vektoru rychlosti a zrychlení TF-R1

[roman-dvorak]

Na střechu auta by bylo vhodné připevnit autopilota, který bude vyčítat senzory (např. airspeed), bude určovat home-position. Dále z něj můžou být ovládány další věci jako odpojování magnetu pro TF-R1 a start ze střechy, odjišťování ventilů pístů a podobné věci.

Autopilot by pak měl být přes sériovku připojen do palubního PC, kde bude pomocí mavlink-routered připojen do UDP sítě. Autopilot bude mit vlastní mavlink ID.

[kaklik]

Musí to být skutečně HW autopilota? Nestačí, když bude pixhawk běžet na palubním počítači s připojenými odpovídajícími senzory?

[roman-dvorak]

Toto řešení mi příjde také dobré. Jen nevím, co vše to obnáší a kolik to zabere času rozfungovat. Jestli by pak nebylo lepší (rychlejší) naučit se posílat mavlink pakety z pythonu a vyčítat senzory pyMLABem.

[kaklik]

Myslím, že je vhodnější mít v autě v řetězci co nejméně hardware, který musí fungovat. Takže bych byl asi proto firmware autopilota na střeše auta nahradit software v palubním počítači auta.

Jedinný závažný argument pro použití hardware autopilota by byl, použít jeho PWM výstupy pro ovládání ventilů platformy. Na to asi PC se standardnim linuxem asi nebude dost real-time.

[kaklik]

Pokud máme na měřící systém tyhle požadavky:

• Získat polohu a orientaci a rychlosti TF-R1 v prostoru
• Umožnit řízení externích komponent
• Publikování dat do lokální sítě
• Možnost relativní navigace UAV oproti autu

Splnění těchto požadavků má pomoci vyřešit následující issue:

• Automatické odpojení vlečného lana PX4-Autopilot#20
• Automatic autogyro takeoff procedures PX4-Autopilot#3

Z aktuálního průzkumu vyplývají tyhle možnosti.

Pixhawk autopilot namontovaný na desku auta

Namontovat na střechu auta hardware autopilota (CUAV 5, HKPILOT32), je asi nejpřímější řešení. K palubnímu počítači se hardware autopilota pak musí připojit přes USB/seriový port a nějaký existující software.

Toto řešení má výhodu v tom, že by z něj mělo být v budoucnu možné pulzně ovládat ventily šestiosé platformy.

IMU snímače připojené k ROS

ROS umožňuje připojit různé IMU snímače a získat z nich navigační informace.

Nevýhodou tohoto řešení je, že by bylo potřeba vyřešit nějaké rychlé a realtime připojení SPI senzorů k palubnímu počítači.

Některé jednodeskové počítače ale mají SPI vyvedeno jako periferii.
Je to případ i Turris MOX, avšak zatím není jasné zda je toto rozhraní volné pro uživatelské použití.
Takovou možnost ovšem má Turris Omnia.

RTK GPS

RTK je navigační mód, který kromě souřadnic umožňuje přímo na přijimaném signálu měřit i rychlosti a zrychlení.
Je k tomu ovšem potřeba GNSS přijímač, který takový režim umožňuje. Podle dokumentace PX4 jsou to například NEO-M8P a Trimble MB-Two

Řešením by zřejmě bylo použití více přijímačů NEO-M8P a jejich sfůzování přes RTKlib.

Dada produkovaná výpočtem RTKlib by pak nebyla redundantní k datům poskytovaným přes gpsd z několika přijímačů.
ROS má několik možností pro připojení k RTKlib

• https://github.com/Fraunhofer-IIS/gnss/blob/master/README.md
• https://github.com/MapIV/rtklib_ros_bridge

Výhodou tohoto řešení je že jde především o algoritmický problém. Vyřešení RTK navigace by však umožnilo použít přijímače auta pro vytváření korečních dat pro UAV pro DGPS navigaci vůči autu.

Získání polohy a náklonu z více GNSS přijímačů a antén je zřejmě akademický problém, který nemá instantní řešení.
Možnost je zřejmě pouze použít realtime RTK pro měření rychlosti.

Pan doc. Kovář považuje za pravděpodobné, že by šel použít přijímač NEO-M8P, neboť poskytuje fázové měření.
Problém ale je s počáteční konvergencí měření, kdy kvůli vypočítání neurčitostí je nutné, aby se družice významně pohnuly. Vzhledem k obezne dobe druzice která je zhruba 12 hod to z princiu konverguje za po nekolika desitkach minut. Dále tam dela potize multipath šíření na fazi. To to cele zpomaluje.

K vypoctu orientace a polohových úhlů se pouzivaji dve strategie.

1. Kalkuluje se s polohou anten. Toto je lepsi, ale musel byste to delat sam.
2. Resi se vzajemna poloha anten. To dela RTK Lib. Pro orientaci se pouzivaji dve usecky.

Polohu lze i trackovat, ale pri sledování nemůže dojit k vypadkum signalu. Kdyz projedete pod mostem, tak se sledování přeruší nebo dojde k masivnim cycle-slipum a musite znovu.

RTK lib tak funguje. Resi se vektor mezi dvema prijimaci. Orientace je nutne spocitat ze dvou vektoru.

U prvni metody se pouzivaji algoritmy jako MUSIC, LAMBDA. Je tam problem, ze kazdy prijimac ma svoje hodiny, takze se obavam, ze se to musi delat z druhych diferenci, takze to je jednak slozite, vzroste sum a zkrati se jednoznacnost.

Problem byl jiz mockrat teoreticky vyresen. Prakticky je tam moc problemu.

Co vim, tak vsichni to delaji druhou metodou.

[slimonslimon]

Jen komentář ke staršímu postu - pustit PX4 na PCčku a připojit si senzory po I2C přes malb modul jde.

ale to je asi už outdated.

[kaklik]

Jen komentář ke staršímu postu - pustit PX4 na PCčku a připojit si senzory po I2C přes malb modul jde.

Ano, to by bylo asi realizovatelné docela snadno. Ale I²C je moc pomalé, ty snímače je potřeba vyčítat tak rychle, aby bylo alespoň trochu možné filtrovat vibrace.

[slimonslimon]

A SPI je rychlé dost? Možná by se dalo zkusit, zda stejným způsobe není možné pracovat se SPI... Tedy pokud by to k něčemu bylo.

[kaklik]

A SPI je rychlé dost? Možná by se dalo zkusit, zda stejným způsobe není možné pracovat se SPI... Tedy pokud by to k něčemu bylo.

Ano s SPI se dá v linuxu pracovat podobně jako s I²C, je ovšem trochu větší problém SPI rozhraní sehnat, nebo vyrobit, protože nejsou device tree drivery do linuxového kernelu třeba na nějaký USB-SPI převodník. Jsou tyhle možnosti.

[kaklik]

@ChroustJan na RTK lib se szřejmě dá vykašlat. Ublox podoruje Moving Baseline RTK Configuration. Zkusíme to nakonfigurovat do tohoto módu. Je to popsané zde.

Staci jedna base a dva rovery. Z vektoru se orientace uz spocita. Pro UAV je to až zbytečně předimenzované. Protože tam zřejmě stačí počítat vektor mezi UAV a TF-R1.