Telefon helyzetének milliméter pontosságú meghatározása valós időben

A címben megfogalmazott igény számtalanszor felmerült már a felhasználók és a fejlesztők részéről is. Olyan cél ez, amit idővel mindenképpen el kell érnünk, hiszen több területen is hasznos lenne. Jól sejted kedves olvasó, a jelenlegi eszközeinkkel egyelőre nem megoldott a probléma, így e poszt témája valójában a miértek boncolgatása technológiai oldalról. Miért is lehet hasznos számodra egy „hogyan ne”, vagy egy „miért nem” jellegű írás?

Felhasználóként azért lehet érdekes számodra, hogy milyen jellegű appok keresésével ne töltsd a drága szabadidőd.
Megrendelőként jó, ha tisztában vagy a technológiai korlátokkal, hiszen félinformációkból könnyű hibás következtetéseket levonni és rossz irányba indulni egy alkalmazás tervezésénél. A témánkban felvetett probléma alapkoncepciókat képes romba dönteni, esetedben pedig már nem csak a szabadidőd a tét. Fejlesztőként sem érthetsz minden területhez, így az ilyen nem magától értetődő problémák bizony megfoghatnak téged is. Esetedben pedig nem csak az idő és a pénz a tét, hanem a szakmai jóhíred is, hiszen egy jó fejlesztő mindenhez ért (persze nem ¯\(ツ)/¯).

Többször illettek már azzal a kritikával, hogy csak az aktuális ötletre tudok ellenérveket mondani, hogy miért nem működhet, de valódi megoldási javaslatot nem adok a probléma megoldására. Esetünkben megpróbálok alternatív, kevésbé pontos, de használható megoldásokat adni, ezek azonban felhasználási terület és erőforrás függő megoldások.

Felhasználói igények

Felhasználóktól olvastam és személyesen is hallottam már az igényt, hogy szeretnék a telefonjukat távolságmérésre használni. Természetesen nem az esti futásukra gondoltak, hiszen arra számtalan appot ismer mindenki, hanem mondjuk egy szoba hosszának lemérésére, ahova centiméteres, de inkább milliméteres pontosságra lenne szükség, illetve működnie kellene az égre való rálátás nélkül. Hasonló probléma mondjuk az épületen belül történő navigáció, amire ugyancsak egyre nagyobb igény lenne.

A GPS korlátai

Az első dolog, ami mindenkinek az eszébe jut a GPS, ami tökéletesen jó kültéri navigációra, a telefonok esetén 3–10m körüli pontosságával. A Federal Aviation Administration saját adatai alapján a komolyabb eszközök 3,5 méternél nagyobb pontosságot biztosítanak, de mértek már 1 méter alatti pontosságot is. Természetesen a telefonokban használt chipek és antennák nem képesek erre a pontosságra még ideális körülmények között sem. Bár így a számok alapján nem tűnik nagynak a telefonok hátránya, ezeket az értékeket egy bizonyos valószínűség mellett adják meg, ami az FAA esetén 95%. Tehát a valós pozíció 95%-os bizonyossággal a mért pozíciótól számított kb. 3,5m-es sugarú körön belül található. Androidos készülékeknél az SDK-tól kapott pontosság érték esetén ez csak 68%.

Fix telepítésű földi GPS vevők adataival korrigálva (DGPS – Differential GPS) a GPS rendszer hibáit, a pontosság elérheti akár a 10cm-t is.

 Mint látod ez a pontosság még messze nem alkalmas arra, hogy a telefonnal helyettesítsd a mérőszalagot, ráadásul épületen belül eleve használhatatlan.

A gyorsulásmérő

A legtöbb telefonban ma már van egy halom érzékelő, melyeknek az adatait jobbnál jobb dolgokra tudjuk felhasználni. Ilyenek a gyorsulásmérő, a giroszkóp, a mágnesesség érzékelő, nyomásmérő stb. Egyes telefonokban némelyik hiányzik, ilyenkor több más szenzor adataiból származtatva helyettesítik. A gyorsulásmérő azonban minden modern okostelefonban helyet kapott. Fizika óráról még biztos sokaknak rémlik, hogy gyorsulásból és eltelt időből lehet számolni sebességet, sebességből és eltelt időből megtett utat, megtett útból és kezdő pozícióból pedig aktuális pozíciót. Ez elméletben jól hangzik ugyan, de a gyakorlatban ehhez elképesztően pontos mérésre van szükség. A felvezetőből gondolom már sejthető, hogy a telefonokban található gyorsulásmérő ehhez pontatlan.

Matematikai háttér

Ha a gyorsulásmérő adataiból (tételezzük fel, hogy elég pontos hozzá) szeretnél aktuális pozíciót számítani, akkor a következőket kell tudnod:

Elmozdulást mindig valamilyen más viszonyítási ponthoz képest értelmezünk. Szükség van egy vonatkoztatási rendszerre, amely esetünkben a jól ismert Descartes-féle derékszögű koordinátarendszer. Egy pont helyzetét a koordinátarendszerben egy vektorral (helyvektor) jellemezzük.

Az elmozdulásvektort két időpillanat között a pont helyvektorának változása adja, ami a gyakorlatban a két vektor különbsége.

A sebességet a helyvektor változási gyorsasága, tehát annak időszerinti deriváltja adja.

A gyorsulást a sebességvektor változási gyorsasága, tehát annak időszerinti deriváltja adja.

Mivel a gyorsulásvektorból szeretnénk kiindulni (hiszen ezt kapjuk meg a szenzortól), ezért a sebesség-idő függvényt a gyorsulás-idő függvényből integrálással kapjuk.

A hely-idő függvényt a sebesség-idő függvényből integrálással kapjuk.

Mivel diszkrét értékekkel dolgozunk, ilyenkor használható valamilyen numerikus integrálási formula. Ilyen esetben én a trapezoid módszert ajánlom.

A sebességvektor x komponense a t1 időpillanatban a következő:

A többi komponenst ugyan így számítjuk.

Jól látható a képlet alapján, hogy az aktuális sebesség vektor nem csak a gyorsulás vektoroktól, hanem az előző időállapotban számított sebességtől is függ. Ez a gyakorlatban azt jelenti, hogy ha a számításokba hiba csúszik, az onnantól halmozódva jelen lesz a teljes mérés során.

A sebességvektorból történő elmozdulás számítást hasonló módon végezzük, elég csak a fenti képletbe behelyettesíteni a gyorsulás helyére a sebességet, a sebesség helyére pedig az elmozdulást. A számítási és mérési hibák halmozódása természetesen ebben az esetben is igaz.

Milyen mérési hibák jelentkezhetnek?

Méréshatár

Készülékenként eltérő a gyorsulásérzékelő méréshatára. Általánosságban ±2g és ±8g méréshatárok között szokott előfordulni, ami kb. ±19 és ±78 m/s^2. Ha kevesebb gyorsulást mérünk, mert elértük a készülék határait, akkor kevesebb lesz a sebesség is amit mérünk, ami az előzőek ismeretében nyilvánvalóan komoly problémát jelent.

Zaj

Minden mérésnél találkozunk valamilyen szintű alapzajjal. A készülékemen, amin teszteltem a szenzort, mindhárom tengelyen ±0.2 m/s^2 között változik a mért gyorsulás, miközben a telefon az asztalon pihen. Mivel egymásra épülő számításokról van szó, a mintavételi frekvenciának megfelelő ütemben minden mérésnél halmozódik ez a hiba.

Mintavétel gyakorisága

Ilyen mérésnél az elérhető legnagyobb frekvenciával kell mintavételezni. Az én készülékemen ez 100 Hz, vagyis másodpercenként 100 mintavétel. Soknak hangzik ugye? A gyakorlatban ez rendkívül kevés, ha sebességet szeretnénk számolni belőle, majd abból pozíciót. Gondolj csak bele, ha a mozgás gyorsító fázisát elkapja a mintavétel, de a lassítás olyan gyorsan történik, hogy két mintavétel közé esik és már az utána beálló nyugalmi állapotot mérjük. Ebben az esetben azt érzékeljük, hogy az eszköz felgyorsult X sebességre, majd mivel nem volt lassulási fázis, X sebességgel halad tovább. Láthatjuk, hogy ez komoly probléma.

Mintavételi idő pontossága

Ez nagyjából magától értetődő, hiszen ha pontatlan a két mérés között eltelt idő, akkor egy újabb halmozódó hiba kerül a számításba.

Gyorsulásmérő valós felhasználása

Felmerülhet a kérdés, hogy ha ennyire pontatlan a szenzor, akkor mégis mire használható?
Ehhez tudnod kell, hogy Androidos készülékeken a gyorsulásmérő adatait többféle képpen is le lehet kérni. Rendelkezésre áll a nyers adat, amiben jelen van a mozgás okozta gyorsulás, valamint a gravitáció okozta fix gyorsulás. Lehetőség van lekérni a gravitációs gyorsulás kivonásával kapott, csak a mozgás okozta gyorsulás vektort, illetve külön csak a gravitációs gyorsulás vektorát. Valós felhasználásnál legtöbbször ez utóbbinak vesszük a legnagyobb hasznát, főleg a magnetométerrel kombinálva, hiszen ebből kiszámítható a készülék orientációja. Általában így szokták helyettesíteni a giroszkópot, amennyiben azt kispórolják a készülékből.

Csak a gravitáció okozta komponenst visszaadó szenzor lekérdezése Androidon:

private SensorManager mSensorManager;
private Sensor mSensor;
mSensorManager = (SensorManager) getSystemService(Context.SENSOR_SERVICE);
mSensor = mSensorManager.getDefaultSensor(Sensor. TYPE_GRAVITY);

A mozgás okozta komponens is használható, például lépésszámlálók fejlesztésénél, hiszen ilyenkor elégséges a mozdulat iránya, az elmozdulás nagyságát többnyire előre megadott adatok alapján (tesmagasság, nem stb.) a lépésszámból számítják.

Az Androidnak van származtatott szenzora a lépés érzékelésére, így nem kell annak implementálásával foglalkozni.

mSensor = mSensorManager.getDefaultSensor(Sensor.TYPE_STEP_DETECTOR);

Látható tehát, hogy kompromisszumokkal használható távolságmérésre, csak nem egészen olyan léptékben és pontossággal, ahogy mi szeretnénk.

Csak a mozgás okozta komponenst visszaadó szenzor lekérdezése androidon:

mSensor = mSensorManager.getDefaultSensor(Sensor.TYPE_LINEAR_ACCELERATION);

Szokás még a gyorsulásmérőt mozgás alapú vezérlésre is használni. Egyes készülékeken beállítható, hogy elhallgasson a csörgés, ha átfodítjuk a készüléket, vagy nem nyílik a képernyőzár, ha úgy érzékeli a telefon, hogy zsebben van és mozgásban vagyunk.

Navigáció épületen belül

Forrás: www.cisco.com

Említettem, hogy egyre nagyobb igény mutatkozik az épületen belüli navigációra, amire a GPS és a gyorsulásmérő szenzor is alkalmatlan. Ennek ellenére nem teljesen veszett ügy. Használható erre a célra a WiFi access pointok jelerőssége, amennyiben tudjuk azok pontos helyzetét, van elég számú access point, valamint kiküszöböljük a falak, illetve a padló és a plafon okozta veszteséget.

Így gondolják ezt az Apple szakemberei is, hiszen aktívan foglalkoznak a témával.
Több szenzor együttes használatával (mondjuk lépésszámláló és orientáció), illetve az épület alaprajzával (nyilván nem közlekedik falakon keresztül az ember) pontosítható a kapott pozíció. Természetesen ez a megoldás is távol áll a milliméteres pontosságtól, továbbra sem alkalmas valódi mérésre, de egy több emeletes több száz négyzetméteres kórházban, vagy plázában történő navigálásra már elégséges lehet.

Telefon elmozdulásának viszonylag pontos meghatározása

Ez sem lehetetlen feladat, de mint az előzőekben, itt is kompromisszumokra kényszerülünk. A telefon kamerájának képét is felhasználhatjuk néhány referencia pont, vagy ábra segítségével, az orientáció érzékelővel kiegészítve. A módszert többnyire kiterjesztett valóság applikációk fejlesztésénél használják, ahol a kamera képre két- és háromdimenziós elemeket helyeznek. Erre használja a jól ismert LEGO is.

Akkor lehet még hasznos a módszer, ha a telefont VR headsetként szeretnénk használni és nem csak a forgást szeretnénk érzékeltetni, hanem az elmozdulást is. Hátránya, hogy a kamerakép feldolgozása erőforrás igényes, ami az amúgy is korlátozott képességű készülékeken erősen behatárolja a megjelenített tartalom részletességét, hiszen ennek számítására kevesebb kapacitás marad.