Urmărirea mișcării pacienților care suferă de boala Parkinson folosind senzori inerțiale [306738]

[anonimizat],

TÎRGU-MUREȘ

SPECIALIZAREA CALCULATOARE

Urmărirea mișcării pacienților care suferă de boala Parkinson folosind senzori inerțiale

Proiect DE DIplomă

Coordonator științific: Absolvent: [anonimizat]. Vajda Tamás László Tamás Levente

2017

Urmărirea mișcării pacienților care suferă de boala Parkinson folosind senzori inerțiale

Extras

A dolgozat 1 oldalas kivonata román nyelven.

SAPIENTIA ERDÉLYI MAGYAR TUDOMÁNYEGYETEM

MAROSVÁSÁRHELYI KAR

SZÁMÍTÁSTECHNIKA SZAK

Parkinson-kóros betegek mozgásának követése inerciális szenzorokkal

DIPLOMADOLGOZAT

Témavezető: Végzős hallgató:

Dr. Vajda Tamás László Tamás Levente

2017

Kivonat

A dolgozat magyar kivonata 150-200 szó között.

Kulcsszavak: mozgáskövetés, IMU, szinkronizácíó, emberi modell

Abstract

Angolul a kivonat 150-200 szó között.

Keywords: [anonimizat], synchronization, human model

Tartalomjegyzék

1 Bevezető 10

2 Bibliográfiai tanulmány 11

3 Elméleti megalapozás 12

3.1 Transzformációk 12

3.1.1 Elemi transzformációk 12

3.1.2 Homogén transzformációs mátrix 14

3.1.3 Kvaternion 14

3.2 Emberi modell 15

3.3 Kommunikáció 15

3.3.1 I2C 15

3.3.2 UDP 17

3.4 RBS (Reference Broadcast Time Synchronization) szinkronizáció 18

3.5 Gyorsulásmérő 18

3.6 Giroszkóp 19

3.7 IMU (Inertial measurement unit) 20

4 A rendszer specifikációi és architektúrája 21

4.1 A rendszer gépigénye és követelményei 21

4.2 A rendszer általános nézete 21

4.3 A rendszer architektúrája 22

4.4 IMU szenzor blokkdiagramja 23

4.5 Protokoll terv 23

4.5.1 Csomag felépítése 24

4.6 Inerciális eszközök időszinkronizálása 25

5 Kivitelezés 27

5.1 Hardver 27

5.1.1 Adafruit BNO055 27

5.1.2 Adafruit Feather HUZZAH ESP8266 Wi-Fi modul 29

5.1.3 Fizikai megvalósítás 30

5.2 Szoftver 31

5.2.1 IMU 31

5.2.2 Alkalmazás osztálydiagramjai 36

6 Üzembe helyezés és kísérleti eredmények 44

6.1 Felmerült problémák és megoldásaik 44

6.2 Kísérleti eredmények 44

6.2.1 Szinkronizáció 44

6.2.2 Hálózat forgalmának változása, a szenzorok számának növekedésével 45

6.2.3 Első kísérleti modellezés 46

7 A rendszer felhasználása 47

8 Következtetések 48

10 Irodalomjegyzék 49

11 Függelék 50

Ábrajegyzék

Ábra 3-1 Z tengely körüli elemi forgatás 12

Ábra 3-2 RPY szögek 13

Ábra 3-3 Emberi csuklok 15

Ábra 3-4 Időzítés és adatátvitel 16

Ábra 3-5 I2C kapcsolása 16

Ábra 3-6 Háromtengelyes gyorsulásmérő tengelyei 19

Ábra 3-7 Háromtengelyes giroszkóp tengelyei 20

Ábra 4-1 A rendszer általános nézete 21

Ábra 4-2 Rendszer architektúrája 22

Ábra 4-3 Inerciaszenzor blokkdiagramja/kapcsolása 23

Ábra 5-1 Adafruit BNO055 abszolút orientációs szenzor 27

Ábra 5-2 Adafruit Feather HUZZAH ESP8266 29

Ábra 5-3 IMU belső felépítése 30

Ábra 5-4 IMU dobozolása 30

Ábra 5-5 Kommunikáció IMU és az alkalmazás között 31

Ábra 5-6 Inerciális szenzorok aktivitás diagramja 33

Ábra 5-7 MyPreciseTimer osztálydiagramja 36

Ábra 5-8 Writer osztálydiagrammja 37

Ábra 5-9 DataGram osztálydiagramja 39

Ábra 5-10 Imu osztálydiagramja 41

Ábra 6-1 Mérés időszinkronizáció nélkül 44

Ábra 6-2 Mérés időszinkronizációval 45

Ábra 6-3 Hálozat terhelése 45

Ábra 6-4 Kísérleti mérés, láb modellezés 46

Bevezető

A dolgozat célja egy inerciális szenzorhálóból kialakított mérő egység segítségével követni az ember mozgását, illetve ennek elérése céljából megoldani a felmerülő problémákat, mint például egy emberi modell felépítése robotirányításoknál használt direkt kinematika segítségével, szenzorok idő szinkronizációja, megfelelő vezeték nélküli hálózat kialakítása.

Napjainkban a számítástechnikai eszközök, rendszerek rohamos fejlődésének köszönhetően több iparágban jelentkeztek olyan igények, amelyek megkövetelik az emberi mozgás minél természetesebb modellezését. Ilyen iparágak a filmipar, digitális játékok ipara, ahol a különböző effektusok elérése érdekében fontos szerepet játszik az animálni kívánt digitális karakter vagy modell minél természetesebb mozgatása, illetve az emberi testen végzett kutatások orvosi célok érdekében. Különböző betegségek tanulmányozása és nyomon követése, mozgás sérült betegek rehabilitációjának nyomon követése illetve Parkinson kóros betegek remegéseinek vizsgálata.

Az emberi mozgás követésére több megoldás található, ilyen a mechanikai mozgáskövetés, amely egy külső váz emberhez igazítását feltételezi, ezt nehézkes hordani és úgy beállítani, hogy a külső csuklók ugyanúgy mozogjanak, mint a követni kívánt belső, emberi csukló. Akusztikus vagy optikai mozgáskövetés, ezek time of flight méréseket végeznek. A módszernek hátránya a korlátozott látási terület. Inerciális mozgáskövetés, a módszer alapja szög illetve lineáris gyorsulások mérésének segítségével következtet a test elfordulására illetve pozíciójára. Ezek a szenzorok pontossága korlátozott, főleg az olcsó kategóriájú érzékelők esetén. Ám a technológia fejlődésével több jobbnál jobb érzékelők jelennek meg, amelyek már különböző szűrő illetve fúziós algoritmusokat futtatnak le a méréseken, mielőtt a felhasználóhoz kerülne a mért adat.

Bibliográfiai tanulmány

XSens, iSEN

Elméleti megalapozás

Transzformációk

Elemi transzformációk

Orientáció leírása térben

Az orientáció egy test térbeli leírására szolgál. Ezt egy referencia koordinátarendszerhez képest mondja meg. A testhez kell rendelni egy saját koordinátarendszert, amely ehhez van rögzítve, majd ennek segítségével mondjuk meg a két koordinátarendszer relatív helyzetét. Ezt a rotációs mátrix segítségével szokták leírni.

Elemi forgatások

A fenti ábrán (Ábra 3-1) látható Y tengely körüli, úgynevezett síkbeli forgatás B szöggel. Az elforgatott koordinátarendszer egységvektorai:

i’=cos(B)i +0j+ sin(B)k

j’=0i+1j+0k

k’=-sin(B)i + 0j + cos(B)

Ennek megfelelő rotációs mátrix:

Rot(y,B)=

Forgatás x tengely körül B szöggel

Rot(x,B)=

Forgatás z tengely körül B szöggel

Rot(z,B)=

RPY (Roll-Pitch-Yaw) szögek

A Roll-Pitch-Yaw szögek, magyar megfelelője Billenés-Bólintás-Elfordulás, az orientáció leírására szolgáló szöghármas. Főként repülőgép illetve hajóirányításban alkalmazzák, de a robotikában is elterjedt módszer, így az emberi modellemben is ezzel próbálkoztam.

Adott koordinátarendszerből egy másikba, közös origó esetén, három egymás utáni elemi forgatás segítségével lehet eljutni. Az első forgatás x (Roll) tengely körül történik, amíg az y (Pitch) merőleges lesz a második koordinátarendszer z (Yaw) tengelyére ez lesz a fi szög. A második forgatás a jelenlegi koordináta rendszerben y (Pitch) körül történik, amíg a két z (Yaw) tengely egybe nem esik ez lesz a theta szög. A harmadik forgatás z (Yaw) körül történik, amíg a két y tengely egybe nem esik, ez lesz a pszi szög.

Gimbal lock (szabadsági fok elvesztése)

Az Euler szögek egyik hátránya az, hogy a pitch szög bizonyos értékeiben szingularitás lép fel, amelyet a szakirodalomban Gimbal locknak neveznek. Ez a jelenség akkor következik be, amikor két tengely egybeesik, azaz párhuzamos lesz egymással. Ennek következtében nem lehet különbséget tenni a két tengely forgásai között. Erre egy megoldás az, hogy ha a szingularitás környékén van a rendszer, akkor a forgatásokat egy más sorrendben valósítjuk meg, vagy ha a rendszer hajlamos gyakran szingularitásba ütközni, akkor olyan reprezentációt kell alkalmazni, amelyre nem érvényes ez a jelenség, például kvaternion algebra. Egy másik hátránya az Euler szögeknek az, hogy csak bizonyos tartományokban folytonos. A függvény szakadásokat nehezen lehet programból kezelni.

Homogén transzformációs mátrix

Háromdimenziós ábrázolások esetén a transzformációs mátrix egy 4×4-es mátrix, amely tartalmazza a különböző műveleteket pontokkal, eltolás, forgatás, skálázás. Ezeket külön külön 4×4-es mátrix formájában írjuk le, majd mátrix szorzással jön létre a végső homogén transzformációs mátrix.

Trans eltolás mátrix:

Trans (t)=Trans (tx,ty,tz)

Ezt a mátrixot alkalmazva, egy tetszőleges P pontot a P’ pontba tolhatunk, ahol:

P=[Px,Py,Pz,1]T homogén koordinátái mátrixos alakban.

P’=Trans*P=

Rot forgatási mátrix x, y illetve z tengelyek körül

Rot(x,)=

Rot(y,)=

Rot(z,)=

A rotációs mátrix tulajdonságai:

A bal felső 3×3-as mátrix főátlóján elhelyezkedő tagok összege konstans 1+2*cos

Ortogonális mátrix, inverze egyenlő a mátrix transzponáltjával: Rot-1=RotT

A mátrix determinánsa mindig 1

RPY ábrázolásban forgatás a három tengely mentén, illetve egy eltolás homogén transzformációs mátrixát ugy kapjuk, hogy a megfelelő sorrendben összeszorozzuk a mátrixokat.

T=Rot(x,)*Rot(y,)*Rot(z,)*Tran(x,y,z)

Kvaternion

Emberi modell

A fenti ábrán (Ábra 2-1) egy ember fontosabb csuklói látszódnak, amelyek mentén el tud mozdulni. Ezek piros pontokkal vannak szemléltetve. A pontokat összekötő egyenesek pedig a csontrendszerét ábrázolja az embernek, minden csont között egy csukló helyezkedik el.

Az ember matematikai modellezését robotikai utón közelítettük meg, úgy próbáltam modellezni, mint egy robotot és forward kinematikával kiszámolni minden csukló pozícióját illetve orientációját a szenzorok által küldött adatokból kiindulva.

Minden inerciális szenzor a fölötte lévő csukló elmozdulását méri, például az alkarra elhelyezett imu, a könyök mozgását követi.

Kommunikáció

I2C

Az I2C angol megnevezésén Inter-Integrated Circuit egy multi-master, multi-slave soros sín, amelyet az NXP Semiconductors fejlesztett ki. A sin tipikusan rövidtávon használjak, általában két vagy több hardvert, mikrokontrollert csatolnak össze, kommunikáció céljából. Előnye más interfészekhez képest az, hogy csak két általános célú ki-bemenetet használ. Az egyik az SCL (serial clock), amelyen a mester előállítja az órajelet, az üzeneteket szinkronizálásához szükséges. A másik láb az SDA (serial data). Ezen a sínen kerülnek továbbküldésre az adatok, bitenként az órajelre szinkronizálva, általában felmenő élre kell az adatot kirakni a sínre, amíg az órajel logikai 1-ben van, az adat vonalon stabilan kell tartani a szintet, ezt csak az órajel negatív felén szabad változtatni.

A fenti diagramon (Ábra 2-3) látható két mester illetve két szolga kapcsolása az I2C sínre. Mivel több mester is lehet a sínre kötve, ezért biztosítani kell azt, hogy egyszerre csak egy mester kommunikáljon a sínen. Ez huzalozott és-el valósul meg. Ha két mester elkezdi kirakni a megcímezni kívánt eszköz címet, az fog veszíteni, amelyik hamarabb teszt 1-est és a másik 0-os értéket. Ezt követően a vesztes mester megáll a cím kiküldésével.

A kommunikáció két keretre van bontva, amely a fenti diagramon (Ábra 2-2) látható. Az első tartalmazza a 7bites címet a második pedig az adatot.

Kommunikációs lépések:

Start: Az SDA vonalat le kell húzni logikai nullába az SCL előtt.

Cím keret: Ez tartalmazza a 7bites címet, a legnagyobb helyértékű bittel kezdve, majd ezt követően egy R/W bit, olvasás eseten logikai nulla, írás eseten logikai egyre kell beállítani. Ezt követően a megcímzett eszköznek, ha sikerült dekódolni az üzenetet, le kell húznia az SDA vonalat nullába még mielőtt megérkezne a kilencedik órajel.

Adat keret: a cím kiküldése után a mester folyamatosan generálja az órajelet és a adatvonalra kerülnek fel az adat bitek a mester vagy szolga által, a másik fél pedig jelzi az ACK bit lehúzásával, hogy megkapta az adatokat minden kilencedik órajel előtt.

Stop: kommunikáció végét úgy jelzik, hogy az SDA vonalon generálódik egy felmenő él egy lemenő él után az SCL vonalon.

UDP

Az internet két fontos szállítási rétegbeli protokollja a TCP (Transmission Control Protocol) illetve az UDP (User Datagram Protocol). Az UDP összeköttetés nélküli, ez a csomag továbbításán kívül nem nyújt semmiféle más szolgáltatást, a felhasználónak a felelőssége erre egy olyan saját protokollt építeni, amelyre szüksége van. Ezzel szemben a TCP összeköttetés alapú, ami azt jelenti, hogy két pont között összeköttetéseket hoz létre, újraküldést biztosít, forgalomirányítást és torlódáskezelést, így a felhasználó ezek alul mentesül.

Az UPD fejrész 32bit mezőből áll, és tartalmazza a forrás port számát illetve a cél port számát. A forrást annak érdekében, hogy ha választ vár az adott csomagra, akkor ezt a fogadó egyszerűen átmásolja a cél portba és válaszolhat is a csomagra. Ez még kiegészül az IPv4 álfejrésszel, ami tartalmazza a forrás illetve a cél IP címét.

Az UDP protokoll hátránya a TCP-vel szemben az, hogy nem garantálja a csomagok megérkezését a célhoz, illetve ennek sorrendben való megérkezését sem, ám ezek hatása elhanyagolható, ha megbízható alacsony forgalmú hálózaton keresztül történik a kommunikáció. Előnye pedig az, hogy viszonylag kisméretű a fejrész miatt gyors a feldolgozása, könnyebb programozni.

RBS (Reference Broadcast Time Synchronization) szinkronizáció

Az idő szinkronizácíó az egyik alapvető probléma egy osztott rendszerben. Szenzorhálózatok is egy osztott rendszert alkotnak, ahol az idő szinkronizáció fontos szerepet játszik a mérések szinkronizálásában. Minden méréshez egy időbélyeget kell rendelni, amelyet majd az összes szenzor adataival együtt dolgoz fel egy rendszer.

Mivel a szenzor hálózatók általában kis teljesítményű akkumulátorral ellátott mikro vezérlőkből állnak, amelyek kevés memóriával es számítási kapacitással rendelkeznek, ezért a hagyományos időszinkronizácíós megoldások, mint például az NTP (Network Time Protocol) vagy a GPS (Global Positioning System) nem felelnek meg, mivel nagy komplexitású algoritmusok futtatását feltételezi. Ebből a célból fejlesztettek az RBS szinkronizációs protokollt, amely egy szerverből és több kliensből áll. A protokoll működési elve az, hogy a szerver üzenetszórással kiküld egy szinkronizácíós csomagot, mikor a kliensek megkapják a csomagot, lekérnek egy időbélyeget a saját belső órájuk szerint, majd ezt az időbélyeget szétküldik egymásnak, így minden egység ki tudja számolni, hogy mennyire van eltérve az órája a többi egységhez képest.

Gyorsulásmérő

A gyorsulásmérő egy elektromechanikai egység, amely objektumok lineáris gyorsulását méri, azaz a sebesség változását. Ezt m/s2-ben vagy g-ben mérik. Leggyakoribb gyorsulásmérő típus a kapacitív. Ennek belsejében találhatók rögzített illetve miniatűr rugóval ellátott kapacitív lemezek, amely gyorsulás esetén elmozdulnak a rögzített lemezhez viszonyítva, ebből kifolyólag változik a kapacitás. A kapacitás feszültséggé alakítás után kerül a felhasználóhoz analóg gyorsulásmerő esetén, digitálisnál viszont valamilyen soros protokoll segítségével (SPI vagy I2C), vagy PWM jellel szolgáltatja a mérést. Legtöbb gyorsulásmerőnek változtatható a mérési skálája ±1g-től akár ±250g-ig, szenzorfüggő. Az alábbi képen (Ábra 2-4) látható egy gyorsulásmérő áramkör tokozásához viszonyítva az alapértelmezett koordináta rendszer, amely mentén méri a gyorsulást.

Giroszkóp

A MEMS (micro electromechanical system) giroszkóp az objektumok szögsebességét méri fok per másodpercben (°/s) vagy fordulat per másodpercben (RPS). Ezeket a méréseket nem befolyásolja az objektumok lineáris gyorsulása. Egyik gyakran használt típusa a rezgő szerkezetes giroszkóp, ez egy rezgő szerkezetet tartalmaz, amely a szögsebesség változása miatt eltolódik a megfelelő irányba. Ezt a mozgást alacsony áramú elektromos jellé alakítják, majd erősítők segítségével felerősítik, majd küldik a felhasználónak különböző interfész segítségével. Analóg szenzor esetén, a szögsebességgel arányos feszültségszinttel, digitálisnál pedig különböző soros kommunikációs protokoll (SPI vagy I2C) segítségével. Az alábbi ábrán (Ábra 2-5) látható egy giroszkóp tokozásához viszonyítva az alapértelmezett koordinátarendszer.

IMU (Inertial measurement unit)

Röviden a három szenzor által mért adatokról írni, Kálmán szűrű, a szenzorban levő fúziós algoritmusról par sort.

A rendszer specifikációi és architektúrája

A rendszer gépigénye és követelményei

A szoftver optimális működése érdekében Windows 8.1 vagy Windows 10 típusú, 64bites architektúrájú operációs rendszerre van szükség, amelyen megtalálható a .Net 4.5.2 keretrendszer. Továbbá a rendszer processzora legalább Intel i7 3GHz dual-core kell legyen, ezt a Kinect szenzor követeli meg. Az adatok feldolgozása érdekében legalább 8GB RAM-ra van szükség és minimum 10GB tárhelyre. Az inerciális szenzorokkal való kommunikációhoz a számítógépnek rendelkeznie kell egy wireless kártyával, mivel a mért adatok vezeték nélküli hálózaton érkeznek meg. Fizikai követelmények közé tartozik egy wireless router, amelyre minden inerciális szenzor és a szoftvert futtató számítógép is fel kell csatlakozzon.

A rendszer általános nézete

A fenti ábrán (Ábra 3-1) látható a rendszer egy általános nézete, amelyet még két kollégával fejlesztettünk ki. A rendszer egy számítógépes alkalmazásból áll, amely felelős a különböző moduloktól érkezett adat feldolgozásával, a mérési folyamat irányításával. Az emberi mozgáskövetéshez három különböző csatornát használtunk. Az egyik egy webkamera, amely csak egy vizuális képet nyújt a vizsgált személy mozgásáról. A második a Kinect szenzor, amely kép alapú mozgáskövetést végez, illetve nem utolsó sorban az inerciális szenzor alapú mozgáskövetés, amellyel én foglalkozom. A rendszer működéséhez szükség van egy vezeték nélküli hálózatra, amelyre úgy a számítógép, amelyen fut a szoftver, mint az inerciális szenzorok fel kell csatlakozzanak. Látható, hogy az első két csatornán egyirányú az adat közlés, míg az inerciális szenzorok esetén kétirányú a szinkronizációhoz szükséges adatszórások miatt. A teljes emberi mozgáskövetést 12 IMU-val már meg lehet valósítani, amelyeket a megfelelő helyre kell elhelyezni.

KEP A HALOZATBA HELYEZETT IMUKROL

A rendszer architektúrája

A fenti ábrán (Ábra 3-2) látható a teljes rendszerünk osztály diagramja. Zöld színnel van ábrázolva Kakucs Gergő kollégám munkája , kék színnel pedig Bala Zsolt kollégám munkája , vörössel pedig az én részem.

IMU szenzor blokkdiagramja

A fenti diagramon (Ábra 3-3) látható a mérő egység blokkdiagramja, illetve kapcsolási rajza. Az akkumulátort egy kétállású kapcsolón keresztül csatlakoztattam az ESP8266 modul JS-2 típusú csatlakozójához. A wifi modul rendelkezik 3.3V kimeneti táppal, amelyet felhasználtam a BNO055 inerciális szenzor táplálásához. Az I2C kommunikációhoz pedig az ábrán látható lábakat kellett bedrótozni.

Protokoll terv

Az alkalmazás protokollja UDP (User Datagram Protocol) alap szabványra épül, a minél gyorsabb adatátvitel érdekében illetve az adatszórás szükséglete miatt. Az UDP szabvány az internet protokoll egyik alap szabványa. Ez rövid csomagok, úgynevezett datagrammok küldésére volt kifejlesztve. Egyszerűségéből adódóan ez a megoldás nagyon gyors, ám nem garantálja a csomagok megérkezését, időben-sorban megérkezését, csomagok többszörözését. Mivel az alkalmazás valós idejű méréseket igényel, szükség volt a nagy sebességre illetve a szenzor hálóval járó időszinkrónizációhóz szükséges üzenetszorásra, ezért döntöttem e protokoll mellett. Az említett hátrányok kiküszöböléséhez, egy saját protokoll réteget építettem fölé, amely segítségével az alkalmazásban ki lehet küszöbölni a csomagok többszörözését, illetve a nem sorrendben való megérkezését.

Annak érdekében, hogy az IMU-k egy időben kezdjenek el mérni, az alkalmazás (szerver) adatszórással (broadcast) küldi ki a kontroll illetve a szinkron csomagokat a mérő egységeknek (kliens). Ennek egy jobb megoldása a multicast típusú adat továbbítás, am ezt a módszert sok router nem támogatja, vagy ki van kapcsolva. Előnye a broadcast-hez képest az, hogy ki lehet választani, hogy melyik egységeknek küldjük a csomagokat.

Csomag felépítése

A csomag adat kódolása ASCII karakterekként van kódolva. Ami azt jelenti, hogy minden karakter egy bájtot foglal el. Előnye az, hogy teszteléskor könnyedén ki lehet olvasni a csomag tartalmát, hátránya az RTU kódolással szemben pedig az, hogy a csomag mérete jelentősen megnő. Minden mezőt ‘;’ karakterrel választ el az IMU mérési csomagjának elválasztó karatere pedig a ‘>’ karakter. Szükségesnek bizonyult elválasztó karaktert használni, mivel az adatok hossza változhat, így nem lehetne dekódolni a beérkezett csomagot.

Az alkalmazás által küldött csomag típusok

A fenti táblázatban (Táblázat 1) látható a protokoll csomag típusai, amelyeket az alkalmazás küld a szenzorok felé. Mérés előtt az alkalmazás teszteli a hálózaton lévő szenzorokat. Sikeres teszt után létrejön egy tömb a hálózaton aktív szenzorok szoftver azonosítójával.

Az IMU által küldött csomag felépítése

A fenti táblázatban (Táblázat 2) látható egy példa mérési csomagra, amelyet az IMU küld az alkalmazás fele. Csomag elején látható a szenzorazonosító jelen esetben 8, a csomagszámláló, amely minden elküldött csomag után egyet nő, ezzel lehet nyomon követni az elvesztődött vagy nem jó sorrendben megérkezett csomagokat. Ezt követi a szinkronizációs időbélyeg, majd a mérés ideje és a szinkronizációs időbélyeg megérkezése között eltelt idő milliszekundumban, végül a kvaternion adatai W, X, Y, Z.

Inerciális eszközök időszinkronizálása

Emberi mozgás követésénél fontos a szenzorok pontossága illetve szinkrónizációja. Ezt úgy lehet elérni, ha a szenzorok egyszerre, egy időben mérik a mozgást. Mivel a mérőegységek egy osztott rendszert alkotnak, és minden egységnek megvan a saját belső órajele, nem fognak egy időben mérni, még ha egyszerre is indítanánk el őket.

Ennek megoldásához a szenzorok idejét a szerver idejéhez kell szinkronizálni. A mérések megkezdésekor a szerver küld egy start csomagot, ami tartalmazza a lokális időbélyegét. A csomag megérkezésekor, minden szenzor elmenti a saját időbélyegét (bekapcsolástól eltelt idő, milliszekundumban kifejezve). Ezt követően, minden mérési ciklusban kiszámolnak egy dT idő intervallumot milliszekundumban kifejezve, a csomag érkezése illetve a mérés időpontja között eltelt időből.

A kezdeti időbélyeget az alkalmazás 10ms időközönként szinkron csomagok segítségével frissíti, amelyek tartalmazzák a pillanatnyi időbélyeget.

A dT idő intervallumot mindig a legfrissebb szinkron csomag idejéhez viszonyítva számolódik ki.

A módszernek köszönhetően a szenzorok átlagosan 1-2 milliszekundum szinkronizációs hibával rendelkeznek.

Kivitelezés

Hardver

A rendszer fontos részét képezik az inerciális szenzorok illetve a kommunikációs modul, amely segítségével hálózatba lehet helyezni a szenzorokat. A végső mérő egységet, a piacon kapható, kész modulokból raktuk össze.

Adafruit BNO055

A mozgáskövetéshez a fenti ábrán (Ábra 4-1) látható az Adafruit által gyártott áramkört használjuk. Ennek fő komponense a BNO055 intelligens 9 tengellyel rendelkező abszolút orientációs szenzor, amely egy háromdimenziós 16 bites giroszkópból, háromdimenziós 14 bites gyorsulásmérőből és egy háromdimenziós geo mágneses érzékelőből áll. Az említett szenzorok nyers adatait, egy 32 bites cortex M0+ mikrokontroller valós időben dolgozza fel a Bosh Sensortec szenzor fúziós szoftver segítségével, és szolgáltatja a felhasználónak I2C protokollon keresztül. A szenzor a következő feldogozott adatokat képes küldeni:

Euler (RPY) szögek

Kvaternion

Szögsebesség vektor

Gyorsulás vektor

A modul fontosabb lábai:

Vin – tápfeszültség, amely 3.3-5V között kell legyen

3vo kijövő feszültség 3V, 50mA áramerőséget tud biztosítani

GND – közös föld

SDA – az I2C szabvány adat kimeneti lába, ez képes 3 illetve 5V logikával is kommunikálni

SCL – az I2C szabvány órajel bemenete, ez képes 3 illetve 5V logikával is kommunikálni

RST – az áramkör reset bemenete

A különböző szenzorok kalibrálása automatikusan történik, a felhasználónak csak egy pár lépést kell tennie a helyes kalibrálás érdekében. A gyorsulásmérőt mérés kezdete előtt hat különböző stabil helyzetbe kell helyezni, a pozícióváltások között lassan kell átmenni. Fontos hogy a orientáció változtatása közben legalább egyszer par huzamos legyen mindenik tengellyel A lépések következtében a szenzor kalibrálódik, majd ezt követően lehet méréseket végezni. A giroszkópot stabil helyzetbe kell helyezni pár másodpercig, amíg a kalibrálás sikeresen lefut. A magnetométert kalibrálásához pedig random mozgatásokra van szükség.

A szenzor két üzemmódban tud dolgozni, az egyik a nem fúziós mód a második pedig fúziós. Nem fúziós módban a szenzor nyer adatokat szolgáltat a felhasználó számára, fúziós módban pedig feldolgozott es kiértékelt adatokat vagy Kvaternion vagy Euler szögek formájában (RPY).

Adafruit Feather HUZZAH ESP8266 Wi-Fi modul

Az adatok begyűjtése illetve továbbítása a számítógépes alkalmazás felé fenti ábrán (Ábra 4-2) látható modul segítségével valósul meg. Ennek fő komponense az ESP8266 típusú WiFi mikrokontroller, amely egy teljes körű vezeték nélküli hálózati kommunikációt biztosít. A modul tartalmaz egy USB-soros átalakítót, amely lehetővé teszi az eszköz gyors programozását Arduino Studio IDE vagy bármely más programozó IDE-vel. A nagyobb mobilitás érdekében rendelkezik egy lítium polimer akkumulátortöltő áramkőrrel, amely 100mA-es töltési áramerősséggel képes tölteni a hozza csatolt akkumulátort. A tápellátása két módón történhet, 3.7V-os lítium polimer akkumulátorral vagy USB-n keresztül. Mikor USB-re van csatlakozva, automatikusan tölti a hozzá csatolt akkumulátort, ezt egy sárga színű leddel jelzi. Továbbá rendelkezik 9 GPIO lábbal, ezek között megtalálható az I2C illetve az SPI kommunikációs protokollhoz szükséges lábak is, illetve egy analóg bemenetű lábat, erre a lábra csatolt feszültség 0-1V intervallumon belül lehet, nagyobb feszültség mérésekor ezt az említett intervallumba kell hozni. Ezt a bementi lábat továbbfejlesztés céljából arra használnám, hogy mérjem az akkumulátor töltési szintjét, így jelezni lehet az alkalmazásnak, ha merül az akkumulátor, még mielőtt lemerülne és kikapcsol a szenzor.

Fizikai megvalósítás

Fizikai megvalósítása az inerciális szenzoroknak a fenti ábránkon (Ábra 4-4,Ábra 4-3) látható. Az első képen a merő berendezés külalakja látszik. A tok fizikai mérete 40x78x21 milliméter. Az emberi testre való rögzítése az ábrán látható tépőzáras pánt segítségével valósul meg, amelyre rögzül a szenzor. A dobozon megtalálható egy kapcsoló, amely a modul tápellátását kapcsolja ki vagy be, és egy nyílás ahol elérhető a modul USB csatlakozója, ezen keresztül lehet programozni illetve tölteni az akkumulátort.

A második ábrán látható az érzékelő belső szerkezete a doboz alján az ESP8266 wifi modul van rögzítve, majd erre került rá az BNO055 inerciális szenzor. Az érzékelő tápellátását a képen látható 3.7V 500mAh lítium polimer akkumulátorral valósul meg, amely a doboz fedő lapjára van rögzítve. Ennek a pozitív huzalját szakítja meg a kétállású kapcsoló, ebből kifolyólag, a szenzorok töltésekor be kell kapcsolni az érzékelőket.

Fontos szerepet játszott a dobozban való elhelyezése a szenzornak. Fontos volt egyformán beragasztani a szenzorokat a dobozba, hogy csökkentsük a statikus hibát. Mivel az inercia szenzort rá kellett cinezni az esp8266 modul fölé, egy vastagabb réz huzalt használtam, amelyet cinezés után úgy lehetett görbíteni, hogy a szenzor párhuzamos legyen a wifi modullal.

Szoftver

IMU

Az inerciális szenzorok programja Arduino Studio-ban készült C/C++ programozási nyelvben, felhasználva az Adafruit cég által megírt Adafruit_BNO055, Adafruit_Sensor könyvtárakat a bno055 inerciális szenzor konfigurálásához illetve a mért adatok lekéréséhez használtam, illetve az esp8266 könyvtárat, amelyet az ESP8266 Community közösség fejleszt. Ezt az ESP8266 modul programozásához használtam, a vezeték nélküli kommunikáció implementálásánál.

A fenti diagramon (Ábra 4-6) látható a szenzorok illetve az alkalmazás közötti csomagküldés, illetve egy mérési folyamat lebonyolítása. A szenzorok bekapcsolása után csatlakoznak a rendelkezésre álló vezeték nélküli hálózatra és várják az első csomagot az alkalmazástól.

Minden mérési folyamatot megelőz egy tesztelési folyamat. A tesztelési folyamatot az alkalmazás indítja egy TEST csomaggal. Adatszórással kiküldi a hálózatnak, majd várja a szenzorok válaszát, amely tartalmazza a szenzor azonosítóját. Mivel UDP szabványt használok, és ez nem garantálja a csomagok sikeres megérkezését a szenzoroknál, ezért ezt a folyamatot négyszer ismétli meg az alkalmazás 500ms időközönként. Így a tesztelési folyamat 2 másodpercig tart. Ennek végeredménye az alkalmazáson belül egy tömb, amely tartalmazza azokat a szenzorokat, amelyek sikeresen válaszoltak legalább egy teszt csomagra, ezzel jelezve azt hogy képesek mérni.

A tesztelési folyamat után, az alkalmazásban ki lesznek választva azok a szenzorok amelyekkel mérni szeretnénk. Majd a mérési folyamat indításakor, az alkalmazás kiküldi a START csomagot, amely tartalmazza a mérni kívánt szenzorok azonosítóját, illetve egy időbélyeget, amely segítségével szinkronizálom a mérések idejét a szenzorok között. Ezt a csomagot is négyszer küldi ki az alkalmazás, annak érdekében, hogy biztos megkapja minden IMU. Start csomagot megkapva, a szenzorok elkezdenek mérni, majd minden 20 mérés után, egy csomagba elküldik a mért adatokat.

A mérési folyamat közben az alkalmazás 30ms időközönként szinkron csomagokat küld, amelyek tartalmaznak egy új időbélyeget. Ezt a szenzorok lementik, illetve lekérnek egy saját, belső időbélyeget. Minden mérés után pedig, újra lekérnek egy saját belső időbélyeget, és a kettő különbségét beteszik a mérési csomagba. Ezzel a módszerrel sikerült a méréseket 1-2ms pontosságra hozni.

A mérés végét az alkalmazás a STOP csomaggal jelzi, amelyet úgyszintén négyszer küld ki 200ms időközönként. Mikor a szenzorok megkapják ezt a csomagot, elküldik a még el nem küldött pufferelt méréseket, majd egy STOP Response csomagot, ami azt jelzi az alkalmazásnak, hogy az adott szenzor sikeresen megállt. Miután elküldte e csomagot, az IMU beáll a kezdeti állapotba és várja az újabb tesztelési csomagot az alkalmazástól.

Az alábbi diagramon (Ábra 4-5) látható az ESP8266 modul aktivitás diagramja. Az eszközök bekapcsoláskor egy inicializáláson mennek át, amely során beállítják a soros kommunikációhoz szükséges adatokat, illetve a BNO055 modul címét, amely az I2C interfészen való kommunikációhoz kell. Ezt követően a modul csatlakozik a rögzített SSID illetve jelszóval rendelkező vezeték nélküli hálózatra. Ez egy végtelen ciklusban fut, 500ms időközönként újra próbálkozik csatlakozni a hálózatra, amíg sikeresen megtörténik a csatlakozás.

Sikeres csatlakozás után figyelni kezdi a hálózaton érkező UDP csomagokat a megadott porton (4210), ha érkezik csomag, akkor azt dekódolja és a tartalma függvényében négy üzemmódba állhat be.

Test üzemmód:

A test üzemmód egy válasz csomag elküldéséből áll, amely tartalmazza az adott egység azonosítóját és azt, hogy a csomag test response típusú csomag.

Start üzemmód:

A start csomag érkezésekor a szenzor dekódolja a csomag tartalmat és leellenőrzi, ha az azonosítók között megtalálható a saját azonosítója is. Ha igen, akkor az adat mezöböl elmenti az kezdeti szinkronizációs időbélyeget és egy időbélyeget kér le a saját órajele alapján ezt követően elkezdődik a mérési folyamat, amely során elsö megközelítésben az esp8266 folyton lekéri a bno055 szenzor által mért adatokat, felépíti a megfelelő csomagot es kiküldi a szervernek. Ezen javítottak, mivel megterhelő volt a hálózatnak, ha minden szenzor minden milliszekundumban küldene egy csomagot, ezért a mérési fázisban 15-20 mérést küldünk el egyszerre, így csökkentve az adatforgalmat a hálózaton.

Stop üzemmód:

Stop csomag érkezésekor az inerciális szenzor elküldi az utolsó adatait, amit a belső pufferében tartott, majd befejezi a mérést és visszaáll a kezdeti állapotába, ahol figyelni kezdi a hálózatón érkező csomagokat.

Szinkronizációs üzemmód

Ebben az üzemmódban, a szenzoroknak annyi a feladata, hogy a csomagban kódolt új időbélyeget elmentse, a mérések szinkronizálása érdekében.

A modulban futó program felépítése a már megszokott mikrokontrollerekhez hasonlít. Bekapcsolás után lefut az inicializáló függvény, setup(), amely egyszer hívódik meg, ebben inicializálódnak a változok, konfigurálódik a soros kommunikációhoz szükséges objektum, ennek meg kell adni a Baud Rate értékét. Ezt debug céljából használtam. Ezután egy végtelen ciklusban 500ms időközönként csatlakozni próbál a vezeték nélküli hálózatra, amelyet az Esp8266 WiFi osztálya segítségével tesz, majd I2C interfész segítségével konfigurálja az inerciális szenzort, ha létezik a megadott című eszköz. Sikeres inicializálás után, meghívódik a loop() végtelen függvény, ez a főprogramja a rendszernek. A mikrokontroller ezt a programreszt hajtsa végre, amíg ki nem kapcsolják.

A program fontosabb függvényei:

decodeInputBuffer()

Ez a függvény dekódolja a beérkező UDP csomagokat (char tömb) a protokoll szerint és annak függvényében, hogy mi a csomag tartalma beállítja a modul üzemmódját.

createMeasurementPacket()

A függvény szerepe az, hogy lekérje a BNO055 modultól a mért adatokat és építse fel a csomagot a protokoll szerint.

sendOutPutData()

Létrehozza az UDP csomagot a megfelelő IP címmel és port-al, amelyet az alkalmazástól kapott csomagból szedi ki, átmásolja a program által felépített csomagot az UDP csomag adat területére majd elküldi a csomagot.

Alkalmazás osztálydiagramjai

A fenti ábrán (Ábra 4-7) a MyPreciseTimer osztály osztálydiagramja látható. Egyetlen egy atributuma van, egy multimedia timer, amelyet a microsoft feljelszt. Ez egy nagyon pontos időzítést biztosit.

A fenti ábrán (Ábra 4-8) a Writer osztály osztálydiagramja látható. Ennek fő feladata a szenzoroktól megérkezett adatok fájlba való írása, majd utólagos feldolgozása illetve rendezése.

Az osztály fontosabb attribútumai:

writerThread, amely a fájlba való írásnak a szállja

buffer, amelybe irodának a megérkezett adatok, mielőtt fájlba íródnának

enable engedélyezi a fájlba való írást

filePath az útvonal, ahova a fájlok le lesznek mentve

fileStream egy folyam arra a közös fájlra, amelybe kerülnek a mérések mérési folyamat közben

activeSensors az a tömb, amelybe kerülnek az aktív szenzorok azonosítói tesztelési fázis után

lastSteps változó jelzi a threadnek, hogy az utolsó mentés következik, és ezután fel tudja húzni azt az eseményt, amely jelzi a fő szálnak, hogy a mentés befejeződött.

A Writer osztály metódusai:

Writer(): az osztály konstruktora, ebben inicializálódnak a fontosabb attribútumok. Létrehozza a könyvtárat, amely a filePath-ben van tárolva, majd létrehozza a fileStream objektumot a megadott útvonalra. Ezt követően meghívja az initializeThread metódust.

initializeThread(): az osztály egyetlen privát metódusa, feladata az, hogy létrehozza azt a szálat, amely a fájlba való írásért felel. Ez egy végtelen ciklusban fut, amelyet a ThreadController osztály tart életben, egy bool változó segítségével. Itt, mikor az enable változót beállítják igazra, akkor a buffer tartalmát kiírja a fileStream segítségével az output.txt fájlba.

pushData(byte[]): a metódusnak egy paramétere van, amely tartalmaz egy mérési csomagot. Itt egy számláló segítségével tölti fel a buffer tömböt a beérkező mérésekkel, mikor ez a számláló eléri az 1024-et akkor meghívja az onTimeWriteing() metódust és lenullázza a számlálót meg a buffer tartalmát is.

onTimeWriteing(): a metódusnak, csak annyi a feladata hogy az enable változó értékét igazra állítsa.

sorter(): mérési folyamat befejezése után, ez a metódus hívódik meg. Ennek feladata, hogy a közös fájlt, amiben az összes szenzor mérése van, szétszedje annyi fájlra, ahány szenzor jelen volt a mérésben, illetve elvégezze a szinkronizációt, az időbélyegek illetve a csomagban tárolt időeltérésekből. Létrehozza a szenzorok nevével ellátott fájlokat, majd egy ciklusban olvassa a közös fájlból a sorokat. A for cikluson belül egy mérési csomagot szed szét > karaktereknél, elvégzi a szinkronizációt majd felépíti a kimeneti stringet, amely tartalmazza a mérés kezdetétől eltelt időt milliszekundumban, majd a kvaternion négy értékét w,z,y,z sorrendben.

A fenti ábrán (Ábra 4-9) a DataGram osztály osztálydiagramja látható. Ennek fő feladata a hálózati kommunikáció lebonyolítása. Küldeni UDP csomagokat a szenzorok fele, illetve fogadni ezek válaszát, majd feldolgozni azokat.

Az osztály fontosabb attribútumai:

port, attribútum tartalmazza azt a port számot, amelyen keresztül valósul meg a hálózati kommunikáció

fromIPEP, segítségével fogad csomagokat a hálózatból, ez úgy van beállítva, hogy bármilyen IP címről érkező csomagokat beolvassa. Azért volt szükség erre, mivel a szenzorok IP címét nem ismerjük.

BroadcastIP, tartalmazza a hálózaton belüli adatszórásra szánt IP címet. Az alkalmazás csak adatszórással küld üzenetet a szenzorok fele, annak érdekében, hogy minden szenzor egyszerre kapja meg az üzenetet.

writer, egy referencia a Writer osztályra, amelynek metódusait ebben az osztályban is használok

receiverThread, az a szál, amely felel a csomagok fogadásáért. Szükség volt ra, mivel az UDP.Receive() metódus blokkolásos, amíg nem jön csomag, addig nem tér vissza, így megszakítaná a főprogram futását is.

UDP, a hálózati kommunikáció ezen az objektumon keresztül valósul meg.

A DataGram osztály metódusai:

DataGram(int): az osztály konstruktora, ennek paramétere egy int típusú változó, amely tartalmazza a hálózati sockethez szükséges port értéket. Itt lekérem a hálózati interfészek közül a wireless kártya IP címét, tehát az alkalmazást futtató számítógép wireless IP címét, majd az felépítem az adatszóráshoz szükséges IP címet. Inicializálja az UDP illetve writer attribútumokat és meghívja a recvFrom() metódust.

recvFrom(): a metódus feladata létrehozni és elindítani a csomagok fogadásához szükséges receiverThread szálat. Ebben egy végtelen ciklus fut, amelyet a ThreadController osztály egy bool változó segítségével állíthat le. A ciklus egy UDP.Receive() függvényhivással indul, amely blokkolódik mindaddig, amíg érkezik egy csomag. A csomag érkezése után leellenőrzi, hogy ha a csomag adatszórással érkezett vagy nem. Ha nem, akkor a writer osztály pushData() metódusát hívja meg, és paraméterként adja át a beérkezett csomagot.

sendToALL(byte[]): metódus feladata elküldeni a paraméterül kapott csomagot adatszórással

flushBuffer(): metódus feladata az, hogy a mérés befejezte után a writer osztály pufferében felgyűlt, de még ki nem irt adatokat kiírja, majd egy eseményt generáljon ami azt jelzi a főprogramnak, hogy a fájlba írás sikeresen megtörtént, így ez le tudja állítani a különböző szálakat.

sorter(): metódus egy event handler, amelyet a writer osztály húz fel, miután sikeresen befejezte a közös fájlba való mentést. Ezt követően a handler meghívja a writer osztály sorter() metódusát.

getLocalIPv4(NetworkInterfaceType): ez a metódus a paraméterül kapott interfész IP címét kéri le a rendszertől, majd visszatéríti a konstruktornak.

A fenti ábrán (Ábra 4-10) az Imu osztály osztálydiagramja látható. Az osztály az IHardwareOnline interfészt implementálja. Ennek négy metódusa van. Az osztály feladata a szenzorok tesztelése, mérési folyamatok kezelése, lebonyolítása.

Az osztály fontosabb attribútumai:

syncTimer, MyPreciseTimer típusú objektum, amely tartalmazza a szinkronizációhoz szükséges időzítést, ez 10 milliszekundumonként generál egy esemény, amelynek hatására az onSyncTimer() metódus hívódik meg.

testTimer, ugyancsak MyPreciseTimer típusú objektum, ezt az időzítőt a szenzorok tesztelésekor használom, ez 500 milliszekundumonként generál egy eseményt, amelynek hatására az onTestTimer() event handler hívódik meg.

stopTimer, ezt az időzítőt a mérés befejezésekor használom, a stop csomagok kiküldése érdekében. Ez 200 milliszekundumonként generál egy eseményt, amelynek hatására az onStopTimer() eseménykezelő hívódik meg.

dtGramm, DataGram típusú objektum, amelynek felelőssége, a már fent említett UDP hálózati kommunikáció lebonyolítása.

isStarted, attribútum jelzi a DataGramm osztály receiverThread szálnak, ha megkezdődött a mérés vagy nem, ennek függvényében ír fájlba vagy nem a Writer osztály.

activeSensors, tömb tartalmazza a tesztelés után azokat az szenzor azonosítókat, amelyek sikeresen válaszoltak az alkalmazás által kiküldött teszt csomagokra.

activatedSensors, short típusú változó, ez a felhasználó által kiválasztott szenzorok azonosítóit kódolja, amelyek a mérést szeretné végezni. Ennek minden bitje a szenzor azonosítót jelenti, például az első bit, az LSB ha egyes, azt jelenti, hogy az 1-es azonosítóval rendelkező szenzorral mérni szeretne a felhasználó.

Az Imu osztály fontosabb metódusai:

Imu(int): az osztály konstruktora, ennek egy paramétere van, a port, amelyen a hálózati kommunikáció megvalósul. A konstruktorban beállítódik a port, inicializálódik az activeSensors tömb, illetve létrejön a dtGram objektum az adott portal.

testHardware(): a metódus feladata lezérózni a tesztelési számlálót, létrehozni a testTimer időzítőt 1ms rezolúcióval, 500ms időzítéssel, majd elindítani ezt.

startSaving(): feladata elindítani a mérési folyamatot. Létrehozza a Start csomagot a megfelelő szenzor azonosítókkal illetve a kezdeti időbélyeggel. dtGram objektum segítségével elküldi a szenzorok fele, illetve elindítja a syncTimert, amely 10 milliszekundumonként meghívja az onSyncTimer() eseménykezelőt.

stopSaving(): feladata megállítani a mérési folyamatot, a syncTimert illetve létrehozni a szenzorok megállításához szükséges stopTimer időzítőt.

onTestTimer(): eseménykezelő a testTimer időzítő hívja meg, feladata létrehozni a teszt csomagot illetve átadni azt a dtGram osztálynak, amely adatszórással elküldi a szenzorok fele. Ezt négyszer hívódik meg, negyedik alkalommal a testTimer időzítőt megállítja és felemel egy eseményt, amely jelzi a főprogramnak, hogy a tesztelési fázis sikeresen befejeződött.

onSyncTimer(): eseménykezelő, a syncTimer időzítő hívja meg. Ennek feladata, minden 10ms időközönként lekérni a rendszer időbélyeget, felépíteni a Sync csomagot és a dtGram segítségével.

onStopAquisitionTimer():eseménykezelő a stopTimer időzítő hívja meg, feladata létrehozni a stop csomagot illetve átadni azt a dtGram osztálynak, amely adatszórással elküldi a szenzorok fele. Ezt négyszer hívódik meg, negyedik alkalommal a stopTimer illetve syncTimer időzítőket megállítja.

Üzembe helyezés és kísérleti eredmények

Felmerült problémák és megoldásaik

Elvesztődött az IP futás közben, az szenzorok nem kommunikáltak

Szinkronizáció

Különböző threadek szinkronizálása és időzítése

Kísérleti eredmények

Szinkronizáció

Egymásra rögzítettünk két szenzort, annak érdekében, hogy együttesen mozogjanak. Ideális esetben a két IMU mérési eredményeit ábrázolva, ezek egymásra kellene tevődjenek, nagy pontossággal illetve idő szinkronizációval.

Elindítottunk egy mérési folyamatot, amely során a két szenzor által küldött adatokat, két külön fájlba mentettünk. Ezt követően az adatok közül kinyertük azokat, amelyeket figyeltük, jelen esetben a Z tengely körüli forgást. Matlab segítségével ábrázoltuk az adatokat. Az alábbi diagramon (Ábra 5-1) látható, hogy a szenzorok idő szinkronicáció nélkül, pár másodperc múlva, mar el vannak csúszva egymáshoz képest, ez pontatlanná teszi a mérésünket feldolgozás után.

Az alábbi diagramon (Ábra 5-2) ugyanaz a mérés látható, ám itt figyelembe vettem a szinkronizációt is. Az idő tengelyen való eltolódás mértéke jelentősen csökkent, ez a hiba 2ms alá csökkent . A két szenzor ugyanazt a mozgást követi, mikor egyik maximum amplitúdón van, akkor a másik szenzor is.

Hálózat forgalmának változása, a szenzorok számának növekedésével

Ábra 6-3 Hálozat terhelése

A fenti ábrán (Ábra 5-3) az látható, hogy hogyan változik a hálózat terheltsége a szenzorok számának növelésével. Kezdetben elindítottam egy mérési folyamatot, amikor csupán egy inercia szenzort használtam. Így a hálózat terheltsége 130 csomag/másodperc volt. Látható, hogy a szenzor számának növelésével lineárisan növekszik a hálózat terheltsége, körülbelül 30 csomag/másodperccel.

A csomagokat WireShark segítségével vételeztem és a beépített analizátorát használtam a hálózat terhelésének vizsgálatához, úgy hogy csak azokat a csomagokat vettem figyelembe, amelyet a szenzorok illetve az alkalmazás között volt.

Első kísérleti modellezés

A fenti ábrán (Ábra 5-4) látható az első kísérleti modellezése egy lábnak. A modell Matlab-ban van implementálva, amely a vételezett adatok alapján kiszámítja a megfelelő csukló koordinátákat és iterációnként kirajzolja. A méréshez három inercia szenzorra volt szükség, egyiket bázisként használtuk és a derékra volt rögzítve, a második felső combra, a harmadik pedig boka föle volt rögzítve.

A rendszer felhasználása

A rendszernek széleskörű felhasználhatósága van, úgy a szórakoztató iparban, animációkban, játékkarakterek mozgatásában, mint az orvostudományban. A rendszer Parkinson kóros betegeken volt tesztelve, ezek remegéseinek a vizsgálatára, annak érdekében, hogy egy jobb diagnózist lehessen felállítani a betegség súlyosságáról.

Következtetések

Függelék

DECLARAȚIE,

Subsemnatul, ………………………………………………………………………………………………………………………………………

student la specializarea CALCULATOARE, Facultatea de ȘTIINȚE TEHNICE și UMANISTE din TÂRGU-MUREȘ, de la FUNDAȚIA SAPIENTIA – UNIVERSITATEA SAPIENTIA din CLUJ-NAPOCA, certific că am luat la cunoștință de cele prezentate mai jos și îmi asum, în acest context, originalitatea lucrării mele de diplomă/licență/disertație cu:

titlul…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………

coordonator ……………………………………………………………………………………………………………………………………….

prezentată în sesiunea …iunie 2017

La elaborarea lucrării de diplomă/licență/disertație, se consideră plagiat una dintre următoarele acțiuni:

– reproducerea exactă a cuvintelor unui alt autor, dintr-o altă lucrare, în limba română sau prin traducere dintr-o altă limbă, dacă se omit ghilimelele și referința precisă;

– redarea cu alte cuvinte, reformularea prin cuvinte proprii sau rezumarea ideilor din alte lucrări dacă nu se indică sursa bibliografică;

– prezentarea unor date experimentale obținute sau a unor aplicații realizate de alți autori fără menționarea corectă a acestor surse;

– însușirea totală sau parțială a unei lucrări în care regulile de mai sus sunt respectate, dar care are alt autor.

Data:…………………………………………… Semnătura………………………………………….

Notă: Se recomandă:

– plasarea între ghilimele a citatelor directe și indicarea referinței într-o listă corespunzătoare la sfârșitul lucrării;

– indicarea în text a reformulării unei idei, opinii sau teorii și corespunzător în lista de referințe a sursei originale de la care s-a făcut preluarea;

– precizarea sursei de la care s-au preluat date experimentale, descrieri tehnice, figuri, imagini, statistici, tabele etc.;

– precizarea referințelor poate fi omisă dacă se folosesc informații sau teorii arhicunoscute, a căror paternitate este unanim acceptată.

UNIVERSITATEA SAPIENTIA DIN CLUJ-NAPOCA

FACULTATEA DE ȘTIINȚE TEHNICE ȘI UMANISTE, TÎRGU-MUREȘ

SPECIALIZAREA CALCULATOARE

Vizat decan Vizat șef catedră

Ș. l. .Dr. ing Kelemen András Dr. ing. Domokos József