Vlákno názorů k článku Stavíme kvadrokoptéru: řídicí jednotka od Kishiro - Arduino je velmi pěkný framework pro snazší programování...

Arduino je velmi pěkný framework pro snazší programování mikrokontrolérů Atmel Atmega, ale nehodí se pro stabilizaci letu. Aby regulátory svoji práci odváděly s úspěchem, musí frekvence aktualiace stabilizace letu byt vyšší jako frekvence vlivů (vítr, kmitání pi regulátoru, nepřesnost měření, 8bit čísla).

Na 8bit procesorech s frekvenci kolem 16MHz lze problem regulace úspěšně řešit absolutni kontrolou nad kódem a velmi optimalizovaným navrhem - použít assembler a použít jen ty periferie, které svým přesným a stabilním měřením přispějí k přesnostem vypočtu, barometr je zbytečné řešit na tak nízké úrovni, kde je třeba řešit hlavně, aby se kvadrokoptéra udržela ve vzduchu a stabilizace fungovala tolik přesně, aby byla možná správa letu počítačem. Človek s RC ovladačem je taky stabilizátorem letu a proto není třeba tak dokonalé řídící desky! Proto dostupná řešení stačí jen pro poletovaní, ale ne počítačem spravovaný let.

Pokud zde jde o vyuzití hotových řešení a manuální správu letu pilotem, šáhl bych alespoň po řídící desce KK2.1.5 s firmwarem od Steveis, následně bych upravil část věnující se vstupům z přijímače a upravil bych ji pro vstup z Raspberry Pi (jediné HW PWM jako PPM signal nebo přímo seriovou sběrnici, kde je ale problém s nároky na výkon a obsluhu přerušení). Ideální pro tuto úpravu, ale dražší, je např. řídící deska AfroFlight Naze32. Komerční profi řešení jsou tvořena příliš na pevno, jsou extrémně drahá a platí se za jejich nápad a značku.

Použít na stabilizaci pouze Raspberry Pi je úplné selhání při analýze. Chápu to nadšení pro Raspberry Pi, ale RPi se standardním OS není určeno pro realtime řízení a pokud je na to upraveno, nelze při této aplikaci (řízení stabilizace a letu) využít jeho potenciál, i v tomto případě je nějaká pravdepodobnost, že se RPi dostane do stavu, kdy znemožní stabilizaci na dost dlouho, aby došlo k pádu. Navíc by byl u RPi veškerý výkon vypotřebován na jednoduché stabilizaci letu. Hlavním problémem je, že OS neprovede to co po něm spuštěný program chce v ten moment, kdy to program chce. Nelze s přesností říct, kdy bude příkaz vykonán a je to dáno obsluhou přerušení, které musí systém vykonat jen pro svuj stabilni provoz.

Nicméně je zde Arduino nováček, který by tuhle práci zvládl nějakým způsobem řešit i s použitím Arduino frameworku. Jmenuje se Teensy 3.

Osobně se kloním k použití procesorů ST STM32 4.řady a vlastniho designu PCB. STM32 je tolik výkonné, že je výhodnější programovat v c/c++ a vyuzit std. knihoven. V praxi jsem STM32 použil pro realizaci stabilizace pohonu a jízdy, velmi přesnou odometrii a správu jízdy u pozemního robota. Nejjednoduššími úkoly při realizaci robota byla stavba a navigace. Míra úspěšnosti řešení závisí na tom, jak perfektně a jak předvídatelně dokážete součásti ovládat (mam na mysli regulaci motorů/pohonu jednotlivě i jako celek, jak směrodatná jsou data z senzorů, apod.), pak je správa jizdy/letu a navigace naprosto jednoduchá.

Dobrý den,

myslím, že přeceňujete nutnost RT řízení quadrocoptéry, nejspíš proto, že nevíte, jak vlastně její stabilizace funguje. Jak je napsáno v článku, těžko budete upravovat výkon motorů s frekvencí vyšší, než je 200 Hz, neboť víc neumožňuje MPU6050. To je celá myšlenková úvaha co se RT potřeb týče, všechno ostatní je nadbytečné.

(neboť k ničemu vám bude upravovat výkon s vyšší frekvencí než 200 Hz, když máte ponětí o orientaci quadrocoptéry právě s touto frekvencí a ne vyšší)

Ještě by stálo za zvážení úprava výkonu s dvojnásobnou frekvencí než je rychlost čtení náklonu, přecejen se dá náklon quadrocoptéry mezi jeho dvěma čteními do jisté míry aproximovat, ale otázka je, jestli by to stabilizaci něco přineslo.

Pokud upravím výkon, tak se náklon začne měnit. Aproximaxe posledních dvou čtení mi neřekne, jak moc moje změna výkonu upravila náklon. Dokud řízení spočívá ve změně výkonu, tak nedává smysl ho měnit, dokud nemám nové měření.

Pro výpočet výkonu samozřejmě má smysl použít několik posledních měření, spočítat diferenciály změn apod. Ale jakmile mi z té rovnice vyjde výkon, jaký mám nastavit, tak ho prostě nastavím. Dokud nepřijde nový údaj, tak mi ta rovnice lepší výsledek nedá.

Výstup z IMU na hobby řídící desce je jen jeden zdroj informací a stačí pro hobby použití, ale ne pro řízení počítačem. 200Hz je frekvence novych DMP dat v IMU, ale neznamená to, že jsou tyto data přesná. Ne vždy více cool informace (DMP) znamenají více přínosu, DMP neni bůhví jaká výhra. MPU6050 není zrovna přesné IMU a není dobré čist informace jen z DMP, data z jednotlivých senzorů lze přijimat rychleji a ne u všech pid regulatoru je třeba znát data z DMP, důležitá data jsou data z gyroskopu. Vůbec neuvažujete frekvenci aktualizace regulátorů motorů, normálně není rychlost otáčení motorů a další veličiny známé, protože je komunikace s regulátory jednosměrná. Některé regulátory motorů umožňují úpravu pro komunikaci např. po I2C. Programování řídící desky je jen jedna část soustavy regulátorů multikoptéry. Pro úplnou kontrolu nad letem musí být odezva na změny co nejrychlejší a hlavne správná, aby byla reakce včasná. Reagovat na stará data je kontraproduktivní. Pokud by se braly v úvahu jen DMP data, která jsou aktualizována pomalu, pak je naprosto důležité, aby odezva na vstup DMP dat byla okamžitá. Vzhledem k "rychlosti" aktualizace DMP dat je rozumné je použít jen pro absolutní orientaci letounu a pro stabilizaci letu použít přímá data z gyroskopu a akcelerometru (ideálně více jednotek na těle multikoptéry, např. páry IMU na protilehlých ramenech) a použit SPI misto I2C, moderní ARM procesory mají mnoho SPI rozhraní, takže není třeba sběrnice sdílet. Regulátory motorů pro multikoptéry aktualizují s frekvencí i 8kHz, tak je žádoucí minimalizovat bottleneck v řídící jednotce a využít plný potenciál soustavy.

Aktualizovat ESC co nejdříve po získání dat z DMP je rozhodně dobrá připomínka, ale nesouhlasím s tím co píšete ohledně DMP samotném. DMP provádí matematickou fůzi údajů z gyroskopu a akcelerometru a to z několika vzorků.

Nebudu moc bláhový, když se domnívám, že DMP není žádný bastl, ale provádí nejoptimálnější možnou matematickou operaci nad těmito daty.

Data z gyroskopu a akcelerometru můžete číst s mnohem vyšší frekvencí než z DMP, ale k čemu vám to bude? Jednotlivé vzorky jsou velice zašuměné, stějně je budete muset filtrovat = tak jako tak zkreslení výstupu. Tak proč se s tím štvát a nepoužít rovnou DMP?

Mám takový pocit, že mluvíte o IMU jako o něčem, z čeho se dá jasně určit pohyb kvadrokoptéry, ale to není možné kvůli načítající se chybě a troufnu si říct že je úplně jedno, jak sofistikované řešení použijete. Co je podle vás nutné k tomu, řídit kvadrokoptéru z počítače? K tomu se tak jako tak bude používat především zpracování obrazu.

Ano, filtrovat a kalibrovat je třeba každý výstup z IMU, to je naprosto základní. Nefiltrovaná a nekalibrovaná data jsou především u Invensense IMU téměř nepoužitelná (hlavně magnetometr, ale o ten tu momentálně nejde). Ideálním filtrem je optimalizovaný kalmanův filtr. DMP už určité filtrování obsahuje, takže není nutné filtrovat data z DMP jakoby trpěla nahodilostí, ale určitý filtr se hodí i zde. DMP v MPU6050 není stejně jako samotné IMU designováno pro použití v multikoptérách (spousty rušení elektromagnetického i mechanického), ale je tvořena pro nenáročné aplikace např. pro spotřební elektroniku, chytré telefony, atd. U psaní firmware pro řídící desky se programátoři potýkají s problémem, že se multikoptéra otáčí nebo pohybuje rychleji než dokáže IMU snímat, tím se naprosto zmate určování polohy. Řešením je zrychlit snímkovací frekvenci. Tato situace nastává např. při flipech a akrobacii. Ale pak není multikoptéra schopna se dobře vyrovnat s větrem nebo šumem systému bez náročného filtrování.

Možná si myslíte, že při běžném letu není možné se do takové situace dostat (jako jsou rychlé změny při flipech, ..). Ale např. při kontaktu s neznámou překážkou v dostatečné výšce s rychlým snímkováním IMU je multikoptéra schopná se stabilizovat. Kdyby bylo IMU nastavené na pomalé snímkování s vysokou přesností, pak je multikoptéra ztracena (pokud není užito nějaké samoopravné nebo pravděpodobnostní metody). Pokud záleží na rychlosti reakce, pak je rozumné umístit na multikoptéru alespoň dvě 6-osé IMU. Jedno pro rychlé reakce, druhé pro stanovení chyby při jemné stabilizaci. Jemná stabilizace je velmi důležitá pro zachování pozice při poryvech větru.

Pro počítačem navigované letouny je životně důležité, aby ony samy o sobě měli co nejvíce informací. Potřebují vědět o tom, kde se přibližně mohou nacházet (zde přichází v úvahu pravděpodobnostní odometrie, apod.), stejně tak potřebují vědět co nejlépe to, jak moc se jejich stav změnil oproti poslednímu zjišťování stavu, nebo alespoň vědět co nejpřesněji možnou chyby měření. Předpokládat, že multikoptéry dokáží létat maximálně 20 minut a průměrná multikoptéra léta maximálně 30km/h, a proto nedokáží nastřádat dost chyby, aby to mělo vliv na celkový let, je jako za dob procesorů 386 předpokládat, že počítače nebudou mít paměti větší než několik desítek mega a pak proč tedy designovat systém, který by uměl spravovat více ;) Multikoptéra se může dostat do velké množiny různých podmínek a přes vliv podmínek by její řídící systém měl dokázat ji stabilizovat na místě nebo při velmi rychlém letu a nebo alespoň by její systém měl vést záznam o tom jak moc změnila svoji polohu.

V detailech se skrývá ďábel a není radno je ignorovat. Pokud na multikoptéry budeme cpát počítač, pak jistě ponese i drahé zařízení a jistě nechceme, aby kvůli nedomyšlenosti spadla z 100 metrů přímo na beton ;) a nebo na nic netušící osobu nebo živočicha.

Nebudu Vám říkat, jak máte tvořit své pokusy :) Jen mám v tomto okruhu dosti praktických zkušeností a netvořím hračky. Čím robustnější a čím obecněji navržený systém, tím snáze přežije programátora, chyby i náhody.

... provádí nejoptimálnější možnou matematickou operaci nad těmito daty.

Eště optimálnější!

:-))))))

(Nápověda pro méně jazykově orientované: optimální vyjadřuje již samo o sobě třetí stupeň a nemá smysl ho dále stupňovat.)
Kdyby autor projevil nejminimálnější cit pro smysl slov, nemusel se projevit jako nejmaximálnější ucho.