Vertical wind velocity estimation

[kaklik]

Při diskusi s @povik jsme přišli na to, že TECS regulátor. Zřejmě obsahuje hodnotu kompenzace vertikální rychlosti. Hodnotě odpovídá integrace ve větvi označené jako Throttle compensation na následujícím diagramu.

Tato integrace se počítá na tomto řádku TECS regulátoru.

V případě vyvedení této hodnoty do uORB zprávy bychom mohli

• Určit rychlost vertikálního proudění v prostoru
• Změřit rychlost opadání vírníku během ustáleného letu (aerodynamickou účinnost).

Trochu problematické bude hodnotě "throttle_compensation" přiřadit fyzikální rozměr [m/s]. @povik si ale myslí, že správná cesta by měla vést přes přenásobení konstantou K_D, s tím že je potřeba uvažovat časovou odezvu regulátoru. Dynamika regulátoru tak převod komplikuje.

[povik]

Nevím, do jaké míry diagram odpovídá kódu v TECS.cpp, protože v kódu do integrace vstupuje (po škálování) _STE_rate_error, ale podle diagramu bych čekal spíš _STE_error. Nic to ale na té původní úvaze, ze které vyšlo, že "throttle compensation" obsahuje zajímavou informaci, nemění.

[kaklik]

K vyřešení tohoto issue, by zřejmě kromě vygenerování nové uOrb zprávy bylo potřeba, ještě naplnit hodnotou parametry "Z" MavLink zprávy WIND_COV.

Tato zpráva se z autopilota sice odesílá, ale pro hodnoty Z obsahuje nulové hodnoty

Zpráva se plní v této části kódu, kde jsou skutečně pro vertikální hodnoty hardcodované nulové hodnoty.

[kaklik]

Tak jsem u tohoto issue chtěl přidat logování throttle_compensation. A když jsem to začal dělat, tak jsem si všiml, že už existuje uOrb zpráva , která stejnou hodnotu obsahuje.

Při posledním letu z platformy je v ní tohle:

Vzniká z toho tak graf o kterém moc nevím co přesně znamená. Hlavně mi jsou podivné ty nespojistosti. Část toho grafu tak zřejmě obsahuje informaci o vertikálním proudění, ale zároveň chybí vazba, která by umožnila konkrétní interpretaci.

[kaklik]

Tak nespojistosti viditelné v grafu lze vysvětlit chybějícími daty. V režimu Stabilized TECS vůbec nefunguje a když se mód letu přepne ze Stabilized, do Position, tak se ta naintegrovaná hodnota vynuluje. Takže validní hodnoty jsou jen v Position, Loiter a částečně v Mission těsně po startu. Tam to je ale ještě pořád takeoff, takže záleží na tom, jak s tou naintegrovanou hodnotou zachází kód od @roman-dvorak. Aktuální mód je poznamenán ve zprávě vehicle_status/nav_state

Pokud se ale provede průzkum delšího letu, kde se mezi módy nepřechází. Tak hodnota throttle_integ od nějaké fáze letu spojitě roste. Zde je například záznam letu ze Silvestrovského meření prachu. Je vidět, že ke kontinuálnímu nárůstu throttle_integ dojde dříve než v maximální výšce letu. Zároveň ale bod začátku stoupání throttle_integ nelze jednoduše vysvětlit například poklesem napětí akumulátoru (pokud regulátor nemá nějaký zvláštní treshold v účinnosti a napájecím napětí).

[kaklik]

Nevím, do jaké míry diagram odpovídá kódu v TECS.cpp, protože v kódu do integrace vstupuje (po škálování) _STE_rate_error, ale podle diagramu bych čekal spíš _STE_error. Nic to ale na té původní úvaze, ze které vyšlo, že "throttle compensation" obsahuje zajímavou informaci, nemění.

Prošel jsem znovu kód a diagram a mám z toho dojem, že použití _STE_rate_error místo _STE_error je chyba. Nedává mi to smysl a je podivné že to nyní funguje.

Zároveň jedinné místo v kódu TECS, kde se používá _STE_error je řešení "uncommanded descent" Tedy propadání vlivem požadavku na nesplnitelnou rychlost letu.

Při průzkumu hodnot _throttle_integ_state ze záznamů více našich letů se ukazuje, že hodnota od nějaké fáze letu spojitě roste. Přesná příčina tohoto jevu zatím není známa, ale je dost možné, že se jedná o nějaký problém s pohonnou soustavou.

Celkový závěr ale je že hodnota "throttle compensation" respektive _throttle_integ_state možná obsahuje informaci o vertikální rychlosti proudění okolo vírníku včetně informace o propadání vírníku. Pokud tam ale taková informace je, tak je skryta mezi jinými "steady state errors", které je těžké separovat. Respektive nemám nápad jak to udělat.

Zkoušel jsem hledat jinde a například u Ardupilota podobnou problematiku řeší pouze za vypnutého motoru. Navíc mají předem změřené parametry rychlostní poláry, což úlohu značně zjednodušuje.

@povik nemáš náhodou nějaký další nápad, jak by se tohle dalo vyřešit?

[kaklik]

Na letu provedeném 16.9.2021 jsem zjistil, že hodnota throttle_integ může být i záporná

[kaklik]

Nevím, do jaké míry diagram odpovídá kódu v TECS.cpp, protože v kódu do integrace vstupuje (po škálování) _STE_rate_error, ale podle diagramu bych čekal spíš _STE_error.

@povik našel tenhle pull-request, kde zřejmě došlo k těmto zásadním změnám v konstrukci TECS, které jsou v rozporu s dokumentací (která od té doby nebyla aktualizována).

[kaklik]

Tak jsem překreslil TECS throttle controller podle aktuálního kódu. Moc to ale tohle issue k vyřešení neposunulo.

[kaklik]

Ono to řešení extrakce účinnosti letu a měření externího vertikálního proudění je vlastně celkem přímočarý. Jde o to zjistit, jaká je ztráta (total energy rate) v čase samotným letem versus total energy rate, která přibývá motorem. Ten tok energie z motoru by se asi dal považovat za lineární funkci throttle. Jen chybí konstanta, kterou se throttle přepočítá na energy rate. (tím by zřejmě dokonce šlo měřit absolutní účinnost motoru).

Pak následně, když se bude měnit total energy a nebude za to moct throttle. Tak je to externí vliv, který zřejmě nemůže být jiný než vertikální proudění. Může se to ale možná zkomplikovat ještě tím, že převod mezi kinetickou energií a potenciální energií má ztráty. Ztráty by ale zas v nějakém rozumném rozsahu měly být funkcí kvadrátu rychlosti.

Tím by řešení uvnitř TECS potřebovalo během letu stále fitovat několik konstant, které by byly na počátku zinicializované parametrem. Jako je to například teď u převodu mezi throttle a energy rate.