Z akcelerometru v zadnym pripade clovek nedostane rychlost, jak se tvrdi v clanku. Rychlost by se dala urcit prubeznymi vypocty (numerickou integraci meniciho se vektoru zrychleni - po zapocteni rotaci urcenych gyrem), ale to je prakticky "dead reckoning" s narustajici chybou.
Serial je celkove zajimavy, sem zvedavy, jak se autor popasuje se stabilizaci a reakcemi na ovladani - v podstate jde o tvorbu fly-by-wire systemu. Tak hodne stesti, chci videt tu mrsku ve vzduchu! :)
Tady si dovolim nesouhlasit, protoze ziskavani rychlosti a take drahy integraci dat z akcelerometru je velice bezny postup, pouzivany v realnem zivote. "Chyba" je zavisla od vhodneho stanoveni pocatecnich podminek, ovsem kdyz zacinam "v klidu" (rychlost a vzdalenost v case 0 je taky 0), neni zadnej duvod aby chyba narustala.
Numericka integrace je samozrejme zatizena nakou odchylkou, jenze jeji "smer" je nahodny, tudiz pri dostatcne dlouhem mericim intervalu (a dostatecne kratkem integracnim intervalu) spis statisticky klesa.
Pravdu máte tak trochu oba.
- Opravdu se to v reálném světě používá, ale
- opravdu je to učebnicový příklad "dead reckoning".
Počáteční podmínky jsou sice důležité, ale nevyřeší systematickou chybu nepřesnosti měření zrychlení (a jeho elektrického zpracování).
Záleží na aplikaci, jak precizně si s tím rozhodnete vyhrát a jak budete mít celý systém proměřen v různých podmínkách (může docela záležet na teplotě) a jak budete ve zpracování dynamicky potlačovat ty nepřesnosti.
Pokud má být získaná rychlost/poloha opravdu důležitá, tak se na akcelerometry rozhodně nespoléhá a doplní se to jiným systémem - např. GPS nebo inerciální navigace založená na gyroskopech. Respektive takto: dobré a drahé inerciální navigace obsahují i akcelerometry i gyroskopy.
Kdepak, dokonce ani v případě zcela náhodné chyby nelze přesnost udržet: http://en.wikipedia.org/wiki/Random_walk
Těch důvodů proč narůstá je mnoho. Stačí pohled do datasheetu jakéhokoli MEMS akcelerometru (změna zero g offsetu, gain, nelinearity, atd.).
MPU-6050 neobsahuje magnetometr takže chybí část informace k určení orientace v prostoru - raději bych zvolil MPU9150. Pak ale přibude problém kalibrace magnetometru.
Pokud chce autor integrovat GPS pro inerciální navigaci, čeká jej ještě hodně práce. A pokud nemá zkušenosti se zpracováním sigálů (a Kalmanovým filtrem wiki), ať rovnou zkusí nějaké hotové řešení. Už jen z důvodu bezpečnosti :).
Dokonce i Kalmanuv filtr predpoklada, ze chyba ma normalni rozdeleni.
PS: jinak doporucuju
Kdyby jen rychlost.. dokonce i poloha! :-) Samozřejmě nepřímo a v kombinaci s dalším čidlem. Sám používám akcelerometr + senzor tlaku na přesné měření výšky. Stačí to, co se změřilo akcelerometrem prohnat dvojí integrací a sloučit to se senzorem tlaku komplementárním filtrem (dolní propust na talkové čidlo, horní na akcelerometr), když chce být někdo víc hardcore místo komplementárního filtru na to poštve Kalmana. Chodí to hezky i s tím kompl. filtrem +-1cm. Samozřejmě nemusí jít jen o výšku, jde to zkombinovat podobným způsobem i s GPSkou, na to se teprve chystám.
K autorovi článku: Koukám, že někdo rozchodil DMP na MPU6050, to když jsem začínal programovat, tak to ještě nebylo. Předpokládám, že to je nějaký reverz engineering, protože pochybuju, že by k tomu Invensense pustil nějakou dokumentaci, když se k tomu neměl už tenkrát. Nevíš jak je to s tím externím magnetometrem přes slave I2C rozhraní? Rozchodil to někdo? Funguje to jen s nějakými?
Samozrejme :)
Na co sem narazel v puvodnim prispevku je, ze ve clanku je to uvedeno, jakoby k vycteni rychlosti doslo primo z akcelerometru. Coz je samozrejme blbost.
Nicmene vybavuji si, ze autor do toho casem hodla zakomponovat i GPS a podobny pristup kombinovani dat by byl urcite velice uzitecny.