Wim Mistiaen, Sander Van Schoote

sensoren3D-visualisaties met behulp van wearable MEMSBewegingsherkenning en -adaptatie geschikt voor

Academiejaar 2009-2010Faculteit IngenieurswetenschappenVoorzitter: prof. dr. ir. Jan Van CampenhoutVakgroep Elektronica en informatiesystemen

Master in de ingenieurswetenschappen: elektrotechniekMasterproef ingediend tot het behalen van de academische graad van

Begeleider: Charles HollemeerschPromotoren: prof. dr. ir. Rik Van de Walle, prof. dr. ir. Jan Vanfleteren

Wim Mistiaen, Sander Van Schoote

sensoren3D-visualisaties met behulp van wearable MEMSBewegingsherkenning en -adaptatie geschikt voor

Academiejaar 2009-2010Faculteit IngenieurswetenschappenVoorzitter: prof. dr. ir. Jan Van CampenhoutVakgroep Elektronica en informatiesystemen

Master in de ingenieurswetenschappen: elektrotechniekMasterproef ingediend tot het behalen van de academische graad van

Begeleider: Charles HollemeerschPromotoren: prof. dr. ir. Rik Van de Walle, prof. dr. ir. Jan Vanfleteren

I

Dankwoord

Wij wensen iedereen te bedanken die ons geholpen heeft deze masterproef te verwezenlijken.

Dit zijn onder meer, maar niet uitsluitend, volgende personen:

• Vooraleerst bedanken wij onze beide begeleiders, ir. Benoıt Huyghe en lic. Charles-

Frederik Hollemeersch, om ons steeds van de nodige hulp en informatie te voorzien.

Elke vraag werd zo spoedig mogelijk beantwoord en op elk verzoek om een afspraak

werd zonder probleem ingegaan. Bovendien hebben zij ons steeds voorzien van kriti-

sche feedback over zowel het werk als de tekst wat geleid heeft tot een beter resultaat.

• prof. dr. ir. J. Vanfleteren en prof. dr. ir. R. Van de Walle, voor het mogelijk maken

van deze thesis in de vakgroep.

• Onze ouders, broers en zussen, om steeds interesse te tonen voor ons werk. Ook gaat

speciale dank naar hen uit naar omwille van de mogelijkheid tot het afmaken van

deze studies. Dit was ongetwijfeld niet gelukt zonder hun steun, zowel moreel als

financieel.

En uiteraard alle anderen die ons onrechtstreeks of rechtstreeks hebben geholpen bij het

realiseren van onze masterproef. In het bijzonder onze vriendinnen Dorien en Ine, voor

hun luisterend oor en de talloze aanmoedigingen.

II

Toelating tot bruikleen

”De auteurs geven de toelating deze scriptie voor consultatie beschikbaar te stellen en

delen van de scriptie te kopieren voor persoonlijk gebruik.

Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met

betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van

resultaten uit deze scriptie.”

”The author(s) gives (give) permission to make this master dissertation available for

consultation and to copy parts of this master dissertation for personal use.

In the case of any other use, the limitations of the copyright have to be respected, in

particular with regard to the obligation to state expressly the source when quoting results

from this master dissertation.”

27 mei 2010, Sander Van Schoote en Wim Mistiaen

III

Bewegingsherkenning en -adaptatie geschikt voor3D-visualisaties met behulp van wearable MEMS sensoren

door

Sander Van Schoote en Wim Mistiaen

Afstudeerwerk ingediend tot het behalen van de graad van Master in de ingenieursweten-

schappen: elektrotechniek - afstudeerrichting elektronische circuits en systemen

Academiejaar 2009–2010

Universiteit Gent

Faculteit Toegepaste Wetenschappen

Vakgroep Elektronica en Informatiesystemen

Voorzitter: prof. dr. ir. J. Van Campenhout

Promotor: prof. dr. ir. J. Vanfleteren en prof. dr. ir. R. Van de Walle

Thesisbegeleider: ir. Benoıt Huyghe en lic. Charles-Frederik Hollemeersch

Samenvatting

Bij motion capturing worden de bewegingen van een of meerdere personen vele keren per

seconde bemonsterd. Deze gegevens worden vervolgens verwerkt om daarna geprojecteerd

te worden op een 3D-model dat de bewegingen van de acteur zo goed mogelijk volgt. De

meeste hedendaagse systemen zijn van het optische type: intelligente camera’s capteren de

bewegingen en trianguleren de orientatie van de verschillende lichaamsdelen. Het spreekt

voor zich dat dit systeem enkel geschikt is voor gebruik door grote filmstudio’s en zich

niet leent tot gebruik door de eindgebruiker. De kosten zowel als de omvang van dergelijk

systeem zijn namelijk aanzienlijk.

In deze masterproef zal motion capturing aan de hand van accelero- en magnetometerdata

uit de doeken gedaan worden. Er wordt getracht om real-time een realistische representatie

van de acteur te bekomen aan de hand van deze gegevens. Om dit te bekomen moet worden

rekening gehouden met allerhande fouten intrinsiek aanwezig in dit systeem. Bovendien

zal een algoritme worden toegepast dat bepaalde bewegingen herkent uit deze constante

stroom van gegevens. Deze resultaten kunnen dan verder aangewend worden ter versterking

van de interactie tussen de acteur en de virtuele wereld.

Trefwoorden: motion capturing, accelerometer, bewegingsherkenning, Euler hoeken

Motion Recognition and -Adaption Suitable for3D-Visualization using Wearable MEMS Sensors

Sander Van Schoote, Wim Mistiaen

Supervisor(s): C. Hollemeersch, B. Huyghe, R. Van de Walle and J. Vanfleteren

Abstract— In motion capture sessions, movements of one or more ac-tors are sampled many times per second. This animation data is mappedto a 3D-model so that the model performs the same actions as the actor.Most systems used today are optical systems. Data captured from imagesensors is used to triangulate the 3D-position of a subject between two ormore cameras calibrated to provide overlapping projections. While thistechnique works well for big movie productions, small movie productionsand video games cannot benefit due to constraints in operating space andhigh cost. Recent developments in the domain of MEMS allow to apply ac-celerometers for 3D-motion capturing. Albeit this technique has promisingprospects, it still has problems to be solved. This abstract will explain theimplementation of a software renderer capable of visualizing full-body ac-celerometer data onto a human skeleton form. To address errors, a numberof constraints in body movement is proposed, tested and found to be stat-isfactory. In addition, certain gestures of the actor can be recognized andused for interactivity between the actor and a virtual world.

Keywords—Motion capturing, accelerometer, gesture recognition, Eulerangles, Dynamic Time Warping (DTW)

I. INTRODUCTION

VIDEO games these days are played with a variety of con-trollers. Among these devices we find mice, keyboards,

joysticks, gamepads, etc. These traditional controllers domi-nated the video gaming industry ever since it was created. Re-cently, there has been a shift towards a more natural input: con-trollers supplied with accelerometers or cameras supported bycomplex software algorithms are used to capture the movementof players. Consumers expect to play games in a natural wayas they would perform actions in real life. While simple con-trollers of this ’new generation’ exist, their use is limited andthey cannot capture full body movement.

The purpose of this thesis was to investigate wether relativelycheap accelerometers [1] attached to the human body could beused for controlling avatars in 3D-video games. While simplyintegrating the accelerometer data would result in the sensorlocation, the sensor data contains lots of noise and makes thistechnique very prone to errors. In addition this technique wouldrequire an advanced calibration method.

Hence other methods were considered. One such a techniquemakes use of the accelerometer as a tilt sensor [2]. The ac-celerometer is accompanied by a magnetometer and assumedto be in a static context. Only gravitational force is exertedupon the sensor and from here the tilt angle with reference tothe earths ground plane can be extracted. Using these orien-tation angles, a skeleton can be constructed from a single rootpoint from where subsequent bones leave into the correspondingdirections. This technique is far less prone to errors due to thelack of integration but has the disadvantage that it only coversorientation and no body movement. As movement of the playeris rather limited due to restrictions in room space we further dis-regard this issue.

II. PROBLEMS

While using the accelerometers as tilt sensors, we assumedthat the only force exerted upon the accelerometer was gravi-tational force. While the actor performs certain gestures, the

accelerometers inevitably are subject to other accelerations andtherefore to other forces. These gestures disturb the actual ori-entation of the sensor. This can be seen as glitches in the skele-ton representation while moving. After performing the action,the orientation of the skeleton converges back to normal. Fur-thermore, sensors will give rise to a wrong representation of thebone as they’re not rotating the exact same angle as the boneitself. The explanation can be found in several phenomena.Firstly, due to the elasticity of the flesh and skin attached tothe bone, the surfuce of, say an arm, will not rotate as much asthe underlying bone. Secondly, depending on the location of thesensor on the bone, the rotation measured will differ. Thirdly,clothing will also influence the rotation of the sensor, analog tothe flesh and skin. All of these undesirable phenomena weresolved by introduction of tolerant motion constraints.

III. MOTION CONSTRAINTS

A straightforward method for solving the acceleration issues,is applying a lowpass filter onto the sensor data. A 2nd orderIIR filter was used. Altough representation looks more realis-tic using this filter, certain gestures remain erroneous. A sec-ond measure taking advantage of the limits of the human bodywas used. To this end, constraints on direction of the individ-ual bones were included. Each bone was assigned a parentbonealong with a type. Depending on both the type and the directionof the parent, the position of the childbone was confined to acertain space.

To create a realistic visualization of the skeleton, 4 types ofbones were used. First of, free bones (lower torso) are bones thatdon’t have constraints. The bones are drawn in the exact direc-tion defined by the sensordata. Similarly, fixed bones (shouldersand hips) are bones inheriting the direction of their parent, re-gardless of their own sensordata (if any). Next to the free andfixed bones, there are two types of bones that do need constrain-ing, namely the single plane and multiple plane bones. The sin-gle plane bones (lower arms and legs) are bones physically at-tached to their parent bone by means of a hinge joint. It is clearthat, once the orientation of the parentbone has been calculated,the position of the childbone is confined to a plane in space, ormore precisely a half-plane. This particular plane contains theparent bone and is perpendicular to the axis defined by the joint.Constraints are applied by projecting the bone onto the plane.This is visualized in fig. 1(a). The fourth type of bones, mul-tiple plane bones (upper legs, upper arms and upper torso), arebones physically attached to their parent bone by means of a balland socket joint. As for these bones, forbidden areas relative totheir parentbone are defined. When a bone enters such a forbid-den area according to its sensordata, constraints are applied bymeans of projection on the nearest border of the area.

IV. TOLERANCE

It is clear to the reader that a bone relies, amongst other, on itsparent’s position to determine its own position. This means that

when a bone has an erroneous representation of the real bone,its error will propagate further into the skeleton and thus lead toa representation diverging from reality. Measures to minimizethis propagation have been taken.

For the single plane bones, the axis of the joint is no longerfixed in place, but can rotate up to several degrees towards anydirection. For example, when the joint specifies the bone hasto be in the XZ-plane, but lies in another plane according tothe sensordata, it will be displayed in a plane making a smallangle with the XZ plane, closer to the position according to thedata. This offset will make up for most of the the errors made bydifferences between the actual and the measured position. Thiscorrection has been visualized in fig. 1(b)

Making up for the errors in multiple plane bones has beenrealized by allowing them to be drawn into the forbidden areas,without complete disregard to these areas though. A bone insuch a forbidden area is first projected on the side of the nearest’wall’, as it is done when tolerances aren’t accounted for. Then,it is ’dragged into’ the forbidden area, towards the unconstrainedbone. An elasticity factor is used to determine how far in a boneshould be dragged.

(a)Single-plane constraint. The anglebetween the parentbone and the uncon-strained bone is clearly less obtuse thanits corrected counterpart. When look-ing parallel to the Y-axis, both bones willseemingly overlap.

(b)Tolerance on single-plainconstraint. The rotation axisdefined by the hinge-jointcoincides with the Y-axis, yetthe imaginary axis defined bythe unconstrained bone isn’t.The axis of the corrected bonewill be rotated towards thesensor-axis.

Fig. 1. SPB correction.

V. MOTION RECOGNITION

Another challenge is the interaction of the player with thevirtual world. A few examples are: pressing a button, kick-ing enemies, picking up objects, etc. As all these actions arestrict sequences of subsequent sensordata we make use of thedynamic time warping algorithm (DTW). Dynamic time warp-ing is an algorithm for measuring similarity between two se-quences which may vary in time or speed. It allows to find anoptimal match between two given sequences. The sequences arewarped non-linearly in the time dimension to determine a mea-sure of their similarity independent of certain non-linear varia-tions in the time dimension. This similarity is expressed as acost number. Similarity can be found in two ways: by assumingall sensordata to be synchronous in time and thus using a uniquewarping path for all sensors, or by warping each sensor inde-pendently of the others. Results show the latter being far moreaccurate, implying decorrelation of sensor signals in time.

Reference gestures were recorded and used for comparisonagainst real-time data. Various gestures were applied and an ex-ample of this cost output is depicted in fig. 2. In this example

the actor first performed random movements with both arms fol-lowed by three subsequent boxing movements. By introducingan appropriate threshold reference, a usefull detection methodwas obtained. The same simulations were run for actions that

Fig. 2. Cost output of the DTW algorithm used with a right-handed boxingsequence. The horizontal line is the threshold value.

contained waving and kicking. The results are similar. Interfer-ence between these three gestures was investigated and found tobe negligible. It should be noted that with the addition of moregestures this interference will rise significantly and thus shouldbe carefully investigated.

VI. IMPLEMENTATION

The visualization and recognition routines were implementedin the Motion Sense software. This C#.NET application gives auser the possibility for customizing certain detection and correc-tion parameters, adding gestures, ... In addition the constraintsalgorithm can be visually checked for correct operation.

VII. CONCLUSION

The goal was both to represent the position of the actor ina 3D-environment and detect certain gestures made, while thedata available being inaccurate. On fast changes, sensor dataremains erroneous, and bones will most likely end up in an im-possible position. By partially correcting this position to a morefeasible one, a realistic skeleton can still be built up. As soonas the actor assumes a more or less static position, sensor datawill be accurate again as equilibrium is restored, and the skele-ton will attain a very good representation of the actual positionof the actor. The effect caused by skin and clothing introduceserrors, but it was proven it can be accounted for. Introducinga certain tolerance, propagation of these errors throughout theskeleton was greatly reduced.

Results show that by implementing constraints based on thehuman physiology, animations captured look sufficiently realis-tic. Finally the DTW gesture recognition algorithm was foundto be a robust and effective way for detection.

ACKNOWLEDGMENTS

The authors would like to thank Rik Van de Walle for the op-portunity to do this research, as well as Charles-Frederik Holle-meersch, and Benoıt Huyghe for helping the authors to achievethese results.

REFERENCES

[1] Bart Kuyken, Wouter Verstichel, Frederick Bossuyt, Jan Vanfleteren,Michiel Demey, and Marc Leman, “The HOP sensor : wireless motionsensor,” 2008.

[2] Benoıt Huyghe, Jan Doutreloigne, and Jan Vanfleteren, “3D Orientationtracking based on unscented Kalman filtering of accelerometer and magne-tometer data,” 2009.

VI

Inhoudsopgave

Dankwoord I

Toelating tot bruikleen II

Samenvatting III

Abstract IV

Inhoudsopgave VI

1 Inleiding 1

2 Werkingsprincipes 4

2.1 Integratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.2 Tekortkomingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Tiltsensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.2 Tekortkomingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Problemen 10

3.1 Verstoring van statica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Onmogelijkheid tot verplaatsing . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 Permanent aanwezige fout . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Avatar animatie 13

4.1 Van Euler hoeken naar avatar . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1.1 Interpretatie Euler hoeken . . . . . . . . . . . . . . . . . . . . . . . 13

4.1.2 Opbouw skelet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1.3 OpenGL implementatie . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2 Preprocessing: laagdoorlaat filter . . . . . . . . . . . . . . . . . . . . . . . 17

INHOUDSOPGAVE VII

4.2.1 Eerste poging: moving average . . . . . . . . . . . . . . . . . . . . . 17

4.2.2 Tweede poging: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3 Correctie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3.1 Standaardconstraints . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3.2 Free bone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3.3 Fixed bone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.3.4 Single plane constraint bone . . . . . . . . . . . . . . . . . . . . . . 22

4.3.5 Multiple plane constraint bone . . . . . . . . . . . . . . . . . . . . . 23

4.4 Tolerantie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Bewegingsherkenning 27

5.1 Dynamic Time Warping . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.1.1 Werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.1.2 Afstandsmetriek . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1.3 DTW in meerdere dimensies . . . . . . . . . . . . . . . . . . . . . 30

5.2 Boksbeweging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2.1 Referentiebeweging . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2.1.1 Tijdsdomein . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2.1.2 Frequentiedomein . . . . . . . . . . . . . . . . . . . . . . . 32

5.2.2 Testsequentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2.2.1 Tijdsdomein . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2.2.2 Boksherkenning . . . . . . . . . . . . . . . . . . . . . . . . 34

5.3 Wuifbeweging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.3.1 Referentiebeweging . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.3.1.1 Tijdsdomein . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.3.1.2 Frequentiedomein . . . . . . . . . . . . . . . . . . . . . . . 35

5.3.2 Testsequentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.3.2.1 Tijdsdomein . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.3.2.2 Wuifherkenning . . . . . . . . . . . . . . . . . . . . . . . . 37

5.4 Schopbeweging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.4.1 Referentiebeweging . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.4.1.1 Tijdsdomein . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.4.1.2 Frequentiedomein . . . . . . . . . . . . . . . . . . . . . . . 38

5.4.2 Testsequentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.4.2.1 Tijdsdomein . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.4.2.2 Schopherkenning . . . . . . . . . . . . . . . . . . . . . . . 42

5.5 Interferentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.5.1 Wuif-boks interferentie . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.5.2 Boks-wuif interferentie . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.6 Orientatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

INHOUDSOPGAVE VIII

5.7 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6 Implementatie 48

6.1 Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.2 Datastroom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.2.1 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.2.2 Ringbuffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.2.3 DTW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.2.4 Constraints algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.3 Grafische interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.3.1 Consolevenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.3.2 Sensoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.3.3 Recording . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.3.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

7 Resultaten 58

7.1 Motion constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.1.1 MPB sprongen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.1.2 SPB sprongen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.2 Bewegingsherkenning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

8 Besluit 63

8.1 Voltooid werk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

8.2 Toekomstige mogelijkheden . . . . . . . . . . . . . . . . . . . . . . . . . . 64

8.2.1 Verfijnen correctiemethodes . . . . . . . . . . . . . . . . . . . . . . 64

8.2.2 Uitbreiden DTW algoritme . . . . . . . . . . . . . . . . . . . . . . 64

8.2.2.1 Toevoegen herkenbare bewegingen . . . . . . . . . . . . . 64

8.2.2.2 Adaptief algoritme . . . . . . . . . . . . . . . . . . . . . . 65

8.2.2.3 Avatar aanpassen in functie van bewegingen . . . . . . . . 65

Bibliografie i

Lijst van figuren iii

1

Hoofdstuk 1

Inleiding

De Wii, Xbox, Playstation, PSP, DS, . . . iedereen kent ze wel, de verschillende gameplat-

formen. Allen zijn ze op zich technologische hoogstandjes met maar een doel: ontspanning

door het spelen van videogames. Het succes van deze producten is voornamelijk te danken

aan de huidige technologie [1]. Door de honderden grafische effecten, duizenden polygonen,

miljoenen kleuren en pixels, zien recente games er meer dan ooit uiterst realistisch en spec-

taculair uit. Het is dus vooral dankzij de technologie dat deze markt een enorme groei en

aanhang kent. Bovendien willen gebruikers steeds meer. Innovatie is dan ook broodnodig

om in deze industrie aan de top te blijven.

De afgelopen jaren lag de trend vooral in het verbeteren van het grafisch aspect. Het aan-

tal pixels is met gemak verhonderdvoudigd, er is een overstap gemaakt van 2D naar 3D,

rasterisatie wordt vervangen door veelbelovende raytracing technieken, het kleurenpalet is

geevolueerd van twee bit naar vierenzestig bit, enzovoort. De grafische pracht en praal

van het videogame is echter slechts een aspect van het grotere geheel. Een ander aspect

beslaat de besturing van de verschillende onderdelen van het spel: de invoer van de ge-

bruiker naar de game-engine. Sinds het ontstaan van deze industrie is de manier om aan

deze invoergegevens te komen min of meer hetzelfde gebleven, namelijk door eenvoudige

knoppen. Zowel voor handhelds als gameconsoles en PC-games. Deze vorm van invoer is

echter eerder onnatuurlijk en er is dus nog ruimte voor verbetering.

Een direct gevolg hiervan is dan ook dat de laatste jaren een verschuiving optreed van het

onderzoek: er wordt meer en meer aandacht besteed aan alternatieve, meer natuurlijke in-

voermethodes [2]. Men poogt hierbij de bewegingen van een persoon continu op te nemen,

te verwerken en verder te gebruiken in het spel. Zo kan bijvoorbeeld een boksbeweging

uitgevoerd worden door in werkelijkheid te slaan, in plaats van op een bepaalde knop te

HOOFDSTUK 1. INLEIDING 2

duwen. Bovendien bestaat ’de’ boksbeweging niet meer, maar worden meerdere boksbe-

wegingen mogelijk. Afhankelijk van hoe de gebruiker in werkelijkheid beweegt zal de slag

een andere invalshoek en snelheid hebben. De speler zal zo niet langer de indruk hebben

dat steeds dezelfde animatie afgespeeld wordt. Naast het overduidelijk voordeel voor de

gebruiker, biedt dit ook voor de ontwikkelaar meerdere mogelijkheden. Allerlei parameters

die vroeger ontbraken kunnen nu worden aangewend ten behoeve van meer spelvariatie.

Zo kan het spel nu bijvoorbeeld afgestemd worden op de eigenschappen van de geleverde

slag. Dit brengt niet alleen meer variatie in het spel maar er wordt bovendien ook meer

creativiteit en inzicht van de speler in rekening gebracht. Belangrijk hierbij is wel dat deze

bewegingen uitermate correct worden gedetecteerd. Een speler die zijn arm even uitstrekt

heeft daarom nog geen slagbeweging uitgevoerd.

De hierboven besproken manier van input staat beter bekend onder de naam ’motion

capturing’. Ze wordt reeds enkele jaren succesvol toegepast in de filmindustrie, waar ze

gebruikt wordt om onder meer animatiefilms te regisseren. Het succes van de technologie is

onmiskenbaar maar helaas beperkt tot de grote filmstudio’s. Deze studio’s maken namelijk

gebruik van optische systemen aan de hand van meerdere camera’s die alle bewegingen van

een persoon opnemen. Deze beelden worden via complexe algoritmes uit de computervisie

omgezet naar locaties en orientaties van de gewenste lichaamsdelen. Het is duidelijk dat

een dergelijk systeem niet geschikt is voor de consument omwille van de hoge kostprijs [3]

en de aanzienlijke omvang.

Een alternatieve manier om aan motion capturing te doen is met behulp van sensormo-

dules. Deze modules worden voorzien van MEMS accelerometers en magnetometers. Het

zijn lightweight en low cost onderdelen, wat hen uitstekend geschikt maakt voor massa-

productie. Het is dan ook op basis hiervan dat de controllers van morgen zullen gemaakt

worden. Hiervan zijn de beginselen reeds te zien in bv. de Wii Remote van Nintendo [4].

Deze masterproef richt zich op het onderzoek naar het gebruik van motion capturing in

videogames. Verschillende sensormodules zijn reeds voorhanden en werden ontwikkeld

bij de CMST-onderzoeksgroep van de Universiteit Gent [5]. Deze module is te zien op

figuur 1.1. Zoals men kan zien zijn deze modules uitgerust met een accelerometer en

magnetometer.

Een normale opstelling omvat dan een tiental sensormodules in combinatie met een draad-

loze ontvanger. De sensormodules sturen hun gegevens draadloos door naar de ontvanger,

waarna deze de gegevens inkapselt in UDP-pakketten. Deze UDP-pakketten worden ver-

3

Figuur 1.1: De sensormodules ontwikkeld bij de CMST-onderzoeksgroep. [6]

zonden en netjes uitgepakt aan de computerzijde waarna deze beschikbaar zijn voor verdere

verwerking. Uitgaande van de constante stroom aan gegevens die deze verschillende sensor-

modules doorsturen wordt een zo realistisch mogelijke weergave van een menselijke avatar

opgebouwd alsook gepoogd specifieke bewegingen te detecteren. Deze bewegingen kunnen

dan later worden ingezet voor het besturen van videogames [7].

Figuur 1.2: Een sensormodule aangebracht op de rechter bovenarm van een menselijk lichaam.

4

Hoofdstuk 2

Werkingsprincipes

De sensormodules die de bewegingen opnemen en doorsturen meten de bewegingen van

een speler aan de hand van accelerometers. Deze accelerometers zijn in staat om de ver-

schillende versnellingscomponenten waaraan de sensormodule onderhevig is op te meten.

Om een computergestuurde avatar te animeren die deze bewegingen volgt zullen deze ver-

snellingen eerst moeten worden omgezet naar een positiebepalend datatype. In wat volgt

worden twee manieren besproken die deze omzetting realiseren. Tot slot worden de voor-

en nadelen van beide technieken besproken.

2.1 Integratie

2.1.1 Principe

Een accelerometer meet de versnelling waaraan hij onderhevig is. Deze waarden kunnen

in principe rechtstreeks gebruikt worden om een absolute positiebepaling te bekomen door

dubbele integratie

~r(t) = ~rref + ~vref t+

∫ t

tref

[∫ t

tref

~a(t) dt

]dt. (2.1)

Hierbij wordt er van een zeker referentiepunt ~rref en een gekende beginsnelheid ~vref uit

gegaan.

2.1.2 Tekortkomingen

Het probleem van deze methode is dat accelerometers componenten zijn met enorm veel

ruisfactoren [8]. Daardoor zullen de gemeten accelerometerwaarden bestaan uit een werke-

lijke versnellingscomponent en een ruiscomponent. Dit zorgt ervoor dat vergelijking (2.1)

2.2. TILTSENSOR 5

wordt gewijzigd in

~r(t) = ~rref + ~vref t+

∫ t

tref

[∫ t

tref

(~a(t) + ~w(t)) dt

]dt, (2.2)

waarbij ~w(t) de ruisbijdrage van de accelerometer voorstelt. Het gevolg is dan ook dat de

positiebepaling van de sensor via deze methode niet alleen een uitgebreide calibratieperiode

vergt, maar bovendien ook enorm onnauwkeurig is. Een volgend voorbeeld illustreert dit.

Veronderstel dat de acceleratiefout constant is en om redenen van eenvoud bevindt de

sensor zich op tijdstip tref in de oorsprong en dit zonder beginsnelheid. Met behulp van

vergelijking (2.2) vertaalt zich dit dan in

~r(t) = ~rref + ~vref t+

∫ t

tref

[∫ t

tref

(~a(t) + ~w) dt

]dt, (2.3)

~r(t) =

∫ t

tref

[∫ t

tref

~a(t) dt

]dt+

~w(t− tref )2

2, (2.4)

~r(t) = ~rcorrect +~w(t− tref )2

2. (2.5)

Een constante acceleratiefout resulteert in een positiefout die kwadratisch met het tijdsin-

terval waarover gemeten wordt oploopt. Een (overdreven) voorbeeld van dit probleem is

te zien op figuur 2.1. Er moet ofwel getracht te worden deze integratiefout te compenseren

ofwel de positiebepaling te beperken in de tijd. Geen van beide opties is echter voor gaming

toepasbaar. Compensatie blijkt in de praktijk uiterst complex en onvoorspelbaar. Boven-

dien zal voor onze doeleinden de meettijd behoorlijk lang zijn, De speler zou daardoor

na elke beweging bijvoorbeeld terug in een bepaalde rustpose moeten gaan staan. Het is

evident dat deze methode alles behalve een prettige spelervaring zal opleveren.

2.2 Tiltsensor

2.2.1 Principe

Een andere methode bestaat erin om de accelerometer te gebruiken als tiltsensor [9]. Hierbij

zal de accelerometer zijn orientatie bepalen ten opzichte van een referentie assenstelsel. De

avatar wordt daarbij opgebouwd vanuit een centraal punt. Elk bot wordt dan aangehecht

aan het bot dat voorafgaat in de menselijke anatomie, te beginnen vanuit het centrale

punt. De hoek waaronder het bot wordt aangehecht is dan de berekende orientatie van de

tiltsensor.

HOOFDSTUK 2. WERKINGSPRINCIPES 6

(a) Skeletvorm met werkelijke weer-

gave.

(b) Skeletvorm met verschillende posi-

tiefouten.

Figuur 2.1: Het probleem van positiedrift.

Deze orientatie kan worden berekend door een driedimensionale accelerometer. Deze kan de

gravitatievector bepalen als de acceleratie die hij ondervindt verwaarloosbaar klein is. Een

accelerometer meet immers de totale versnelling ~atot = ~a+~g of enkel ~g als ~a verwaarloosbaar

klein is. In het (x,y,z) assenstelsel kan ~g dus bepaald worden. De transformatie tussen deze

twee assenstelsels kan uitgedrukt worden als

A′ = RA, (2.6) x′

y′

z′

=

r1,1 r1,2 r1,3

r2,1 r2,2 r2,3

r3,1 r3,2 r3,3

x

y

z

. (2.7)

De negen elementen rij van R moeten nu worden bepaald om zo de coordinatentransformatie

volledig vast te leggen en de orientatie van de sensor te kunnen bepalen. Om dit te doen,

rijst de nood aan 9 onafhankelijke vergelijkingen.

1. Aangezien het gaat om een transformatie tussen twee orthonormale assenstelsels, kan

een eerste set vergelijkingen bekomen worden. Bovendien bestaat de transformatie

enkel uit rotaties en geen translaties. Translaties kunnen dus niet gedetecteerd wor-

den op deze manier. Door dit alles uit te drukken, zijn reeds 6 van de benodigde 9

2.2. TILTSENSOR 7

voorwaarden gekend. Een mogelijke matrix die aan deze voorwaarden voldoet, is

R = ZYX, (2.8)

R =

cosφ − sinφ 0

sinφ cosφ 0

0 0 1

cos θ 0 sin θ

0 1 0

− sin θ 0 cos θ

1 0 0

0 cosψ − sinψ

0 sinψ cosψ

, (2.9)

R =

cos θ cosφ sinψ sin θ cosφ− cosψ sinφ cosψ sin θ cosφ+ sinψ sinφ

cos θ sinφ sinψ sin θ sinφ+ cosψ cosφ cosψ sin θ sinφ− sinψ cosφ

− sin θ sinψ cos θ cosψ cos θ

.Bij gebruik van deze matrix wordt veronderstelt dat er respectievelijk een rotatie

rond de x-as, y-as en z-as uitgevoerd wordt. De grootte van deze rotaties, (ψ, θ, φ),

zijn nu de drie resterende onbekenden.

2. Om het probleem voorhanden te vereenvoudigen, wordt ~g volgens de x-as georienteerd.

Ook dit mag zonder de algemeenheid te schenden.

gx′

gy′

gz′

=

r1,1 r1,2 r1,3

r2,1 r2,2 r2,3

r3,1 r3,2 r3,3

g

0

0

, (2.10)

r1,1 = cos θ cosφ =gx′

g, (2.11)

r2,1 = cos θ sinφ =gy′

g, (2.12)

r3,1 = − sin θ =gz′

g. (2.13)

Deze drie voorwaarden zijn echter niet onafhankelijk van elkaar en zijn dus op zich

niet voldoende om de drie rotaties te berekenen. De grootte van de rotatie rond de x-

as (ψ) blijft onbekend. In de praktijk manifesteert zich dit als de mogelijkheid voor de

sensormodule om verschillende posities aan te nemen bij een zekere set ontbindingen

in het (x’,y’,z’) stelsel. Figuur 2.2 illustreert dit.

3. Om de laatste rotatie te bepalen wordt gebruik gemaakt van de magnetometer aan-

wezig op de sensormodule. Deze zal aan de hand van het permanent aanwezig mag-

netisch veld van de aarde ~m de orientatie van de sensor mee bepalen. Indien veron-

dersteld wordt dat de magnetische noordpool van de aarde altijd in het vlak van de

HOOFDSTUK 2. WERKINGSPRINCIPES 8

x- en z-as ligt, worden de vergelijkingen mx′

my′

mz′

=

r1,1 r1,2 r1,3

r2,1 r2,2 r2,3

r3,1 r3,2 r3,3

mx

0

mz

, (2.14)

mx′ = r1,1mx + r1,3mz, (2.15)

my′ = r2,1mx + r2,3mz, (2.16)

mz′ = r3,1mx + r3,3mz, (2.17)

bekomen. Merk op dat de laatste vrijheidsgraden nu zijn uitgeput en de posities van

de assenstelsels ten opzichte van elkaar gekend zijn.

Vergelijkingen (2.11) en (2.14) gecombineerd maken het in theorie mogelijk de transforma-

tie eenduidig te bepalen. In de praktijk echter, zal de relatieve positie van ~atot en ~m ten

opzichte van elkaar niet dezelfde blijven. Dit komt door enerzijds de ruis in de metingen

en anderzijds het feit dat ~a niet altijd verwaarloosbaar klein is. De tegenstrijdigheid in

de meting levert een strijdig stelsel op. Om toch de juiste beslissing te maken omtrent de

rotatie rond de z-as, wordt een Kalman filter ingeschakeld [10].

Uit de rotatiematrix kunnen de Euler hoeken geextraheerd worden die in dit werk gebruikt

worden. Een uiteenzetting van hoe dit precies gebeurt valt buiten de scope van dit werk.

Wel wordt er graag verwezen naar [11].

(a) Een mogelijke

orientatie.

(b) Een andere mogelijke

orientatie.

Figuur 2.2: Ambiguiteit zonder magnetometer.

2.3. CONCLUSIE 9

2.2.2 Tekortkomingen

Met deze methode is het niet mogelijk om op elk tijdstip een correcte orientatie bepalen.

De accelerometer mag naast de valversnelling immers geen noemenswaardige versnelling

ondergaan (zie vergelijking (2.11)). Bij het uitvoeren van bepaalde spelacties is dit na-

tuurlijk duidelijk wel het geval. Dit zal leiden tot een tijdelijk foutieve rotatiematrix en

bijgevolg Euler hoeken.

Bovendien is er nog een belangrijke consequentie verbonden aan deze methode. Doordat het

opbouwen gebeurt vanuit een centraal punt kan de avatar enkel bewegingen uitvoeren rond

dit centraal punt. Hierdoor worden een aantal bewegingen zoals onder andere wandelen

en springen onmogelijk. Dit is tenzij er een zekere intelligentie ingebouwd wordt die deze

bewegingen herkent en vervolgens hiernaar kan handelen. Dit kan bijvoorbeeld zijn door

het startpunt waaruit het skelet wordt opgebouwd, omhoog en omlaag te laten bewegen

wanneer een sprong is gedetecteerd.

2.3 Conclusie

Beide werkingsprincipes hebben belangrijke tekortkomingen. De methode via directe inte-

gratie geeft ons alle mogelijkheden maar blijkt in de praktijk niet of nauwelijks toepasbaar.

Via de werking als tiltsensor kan een zeer accurate weergave worden opgebouwd. Dit kan

echter niet op elk moment en niet alle bewegingen kunnen hiermee worden getoond zonder

meer. De problemen die zich voordoen bij de tiltsensor zijn echter weg te werken aan de

hand van software. Voor foutieve posities kan gecorrigeerd worden. Bovendien kunnen

bewegingen die problematisch zijn om weer te geven, gedetecteerd worden om zo de root

waaruit de avatar wordt opgebouwd te verplaatsen of dergelijke. Deze thesis spitst zich

toe op beide aspecten: correctie en detectie.

10

Hoofdstuk 3

Problemen

In hoofdstuk 2 werd het gebruik van de accelerometer als tiltsensor uitgelegd. Deze techniek

werd het meest geschikt gevonden voor de omzetting van de gemeten versnellingen naar een

weergave van het menselijk lichaam. Er zijn echter nog enkele belangrijke tekortkomingen

die aan de basis liggen van een onnauwkeurige weergave van het geheel. In dit hoofdstuk

wordt dieper ingegaan op de beschrijving van deze problemen. Hoofdstuk 4 zal dan weer

handelen over het corrigeren van deze fouten door de avatar aan te passen wanneer deze

een onrealistische pose aanneemt.

3.1 Verstoring van statica

Een eerste probleem beslaat het optreden van fouten in de weergave door de verstoring

van de statica. Wanneer een speler bepaalde bewegingen uitvoert zijn er inherent andere

versnellingen aanwezig naast de valversnelling. Wanneer op dat moment de orientatie

van de accelerometer berekend wordt, bezit deze een aanzienlijke afwijking tegenover de

werkelijke orientatie. Wanneer de inkomende data dan zonder enige modificaties gebruikt

wordt om een avatar te animeren, zijn foute bewegingen nog steeds duidelijk zichtbaar.

Deze fouten kunnen zich manifesteren in verschillende vormen. Enkele voorbeelden zijn:

1. Kortstondige foutieve positie bij snelle bewegingen van de speler. Deze glitches wor-

den veroorzaakt door de grote versnelling die inwerkt op de sensor.

2. Tijdelijk aannemen van onmogelijke houdingen omwille van een schok op alle sen-

soren, zoals het geval is bij bijvoorbeeld springen en lopen. Het schokken zal een

grote acceleratie uitoefenen op de sensoren, waardoor diens meting niet tot de juiste

orientatie leidt.

3.2. ONMOGELIJKHEID TOT VERPLAATSING 11

De invloed van deze verstoring op de uiteindelijke weergave kan beperkt worden door

gebruik van een op maat gemaakt laagdoorlaatfilter. Na het uitvoeren van de beweging zal

de avatar immers steeds terugkeren naar de juiste orientatie. De speler zal na een snelle

actie namelijk vaak een tragere beweging maken. Op dat moment van bijna-rust zijn er

geen extra versnellingscomponenten meer aanwezig, waardoor de sensor de juiste orientatie

kan bepalen. Sectie 4.2 bespreekt deze lowpass filter.

3.2 Onmogelijkheid tot verplaatsing

Zoals reeds aangehaald, zal de avatar opgebouwd worden rond een centraal punt, genaamd

de root. De sensoren brengen enkel data voort die voorziet in de orientatie van de verschil-

lende bones en niet hun absolute positie. Hierdoor is het onmogelijk de root af te stemmen

op deze data, met andere woorden, de root zal een vast punt in de ruimte zijn. Om de

avatar toch de mogelijkheid te geven te bewegen in een 3D-wereld, kan echter gebruik

gemaakt worden van motion recognition: in de data van de sensoren zal naar patronen

gezocht worden die een bepaalde beweging definieren. Eens een beweging gedetecteerd is

kan de root hiernaar aangepast worden. Zo kan wanneer bijvoorbeeld een sprong is gede-

tecteerd, de root mee omhoog en omlaag verplaatst worden. De methode die deze detectie

uitvoert wordt omschreven in hoofdstuk 5. Merk wel op, de bewegingen die gedetecteerd

kunnen worden na afloop van deze thesis, zijn wuiven, schoppen en boksen. Ze zullen de

root niet beınvloeden. De stap naar bewegingen die de root wel beınvloeden is echter niet

ver af.

3.3 Permanent aanwezige fout

Een derde probleem dat de kop opsteekt bij gebruik van accelerometers is een permanente

aanwezigheid van een fout. Deze fout heeft verschillende oorzaken. Zo zal een sensor

aangebracht bovenop de kledij niet dezelfde rotatie ondergaan als zijn onderliggend bone.

Door de elasticiteit van huid, kledij en dergelijke, zal de rotatie van de sensor steeds kleiner

zijn dan de werkelijke rotatie van het overeenstemmend bot. Een soortgelijk effect treedt

op omwille van de plaatsing van de sensor : een sensor geplaatst tegen de elleboog zal een

grotere rotatie ondergaan dan een sensor geplaatst aan de schouder. Dit komt omdat de

schouder vrijwel niet beweegt wanneer de bovenarm bewogen wordt. In principe is het

dus beter de sensor zo ver mogelijk van een vast punt te plaatsen. Op deze plaats is de

versnelling waaraan de sensor onderhevig is natuurlijk steeds groter in vergelijking met

HOOFDSTUK 3. PROBLEMEN 12

een locatie dichter bij het vaste punt. Dit is overduidelijk een nadeel aangezien de statica

verstoord wordt. Een”ideale” locatie is er dus niet echt.

Ook met de permanent aanwezige fout zal moeten rekening gehouden worden opdat een

realistische avatar bekomen wordt. In sectie 4.4 wordt uitgelegd hoe deze compensatie

precies in zijn werk gaat.

13

Hoofdstuk 4

Avatar animatie

In dit hoofdstuk volgt een uiteenzetting over de manier waarop de avatar wordt opge-

bouwd, vertrekkende van enkel de Euler hoeken. De manier waarop de desbetreffende

hoeken bekomen zijn brengt inherent problemen met zich mee (zie hoofdstuk 3). Concreet

komt dit neer op foutieve Euler hoeken. Deze fouten vertalen zich als foutieve houdingen

en bewegingen van de avatar. De compensatie van deze fouten wordt in dit hoofdstuk uit

de doeken gedaan. Vooraleer correctie toegepast kan worden, dient natuurlijk een onge-

corrigeerde beginpositie te worden aangenomen. Het eerste deel van dit hoofdstuk zal dan

ook betrekking hebben tot het tot stand komen van dit ’raw’ skelet.

4.1 Van Euler hoeken naar avatar

Zoals reeds aangehaald, zijn enkel de Euler hoeken van alle relevante lichaamsdelen ter

beschikking. Het ligt vrij voor de hand om uit deze dataset een gepast skelet te vormen.

De richting van elk lichaamsdeel is namelijk eenduidig bepaald door de overeenkomstige

hoek en de lengtes van de ledematen zijn gekend. Het is nu een kwestie van de verschillende

lichaamsdelen met elkaar te verbinden.

4.1.1 Interpretatie Euler hoeken

De data afkomstig van de sensoren is reeds omgevormd tot Euler hoeken. Er zijn echter

verschillende conventies omtrent de interpretatie van deze waarden [12]. Ze kunnen betrek-

king hebben tot relatieve zowel als absolute assen. Bovendien kan het gaan om rotaties

rond respectievelijk de x, y en z-as, maar andere keren dan weer rond x, z en nogmaals

de x-as. In dit geval gaat het om rotaties rond respectievelijk de x-as, y-as en z-as van

HOOFDSTUK 4. AVATAR ANIMATIE 14

een absoluut assenstelsel. Let wel, het referentie-assenstelsel gebruikt om de hoeken in te

bepalen is verschillend van dit gehanteerd door OpenGL [13][14]. Een vergelijking van de

twee is te zien in figuur 4.1. Om OpenGL de rotatie correct te laten uitvoeren rijst de

nood aan de volgende conversie

XOpenGL = Xdata, (4.1)

YOpenGL = Zdata, (4.2)

ZOpenGL = −Ydata. (4.3)

Bovendien dienen de rotaties niet langer rond respectievelijk de x, y en z-as uitgevoerd te

worden, maar rond de x, z en y-as.

(a) data. (b) OpenGL.

Figuur 4.1: Gebruikte assenstelsels.

4.1.2 Opbouw skelet

Om een skelet te bekomen, dient vooraleerst ergens een startpunt gedefinieerd te zijn

waarrond het skelet wordt opgebouwd. Vanuit dit punt kan dan vertrokken worden om

zo alle bones van het skelet te tekenen. Dit punt wordt de root genoemd. Van hieruit

vertrekken de LT en UT bones. Beide bones worden getekend volgens de richting die hun

respectievelijke Euler hoeken definieren. Aangezien hun startpunt (de root), hun lengte

zowel als hun richting gekend is, is ook het uiteinde van dit bot gekend. Vanuit dit punt

is het dan mogelijk al de childbones te tekenen op analoge manier.

Een overzicht van de gebruikte lichaamsdelen, hun afkorting, lengte en parentbones is terug

te vinden in tabel 4.1. De lengte is slechts de initieel ingestelde lengte, ze kan eenvoudig

aangepast worden indien dit nodig zou zijn voor bijvoorbeeld gebruik bij kinderen. Normaal

4.1. VAN EULER HOEKEN NAAR AVATAR 15

zou dit echter niet noodzakelijk zijn aangezien enkel de relatieve lengtes van tel zijn en niet

de absolute (merk ook op dat er dan ook geen eenheid bij de lengte staat). Aangezien

de verhoudingen bij grote zowel als kleine mensen quasi dezelfde zijn, zijn de gekozen

standaardwaarden meer dan waarschijnlijk geschikt. Tabel 4.1 is de conventie die wordt

gehanteerd doorheen de rest van deze tekst.

Tabel 4.1: Overzicht gebruikte bones.

lichaamsdeel afkorting lengte parentbone

Upper torso UT 11 root

Lower torso LT 11 root

Hip HIP 11 LT

Left upper leg LUL 14 HIP

Right upper leg RUL 14 HIP

Left lower leg LLL 15 LUL

Right lower leg RLL 15 RUL

Shoulders SHOULDERS 12 UT

Left upper arm LUA 12 SHOULDERS

Right upper arm RUA 12 SHOULDERS

Left lower arm LLA 11 LUA

Right lower arm RLA 11 RUA

4.1.3 OpenGL implementatie

De implementatie van bovenstaande werkwijze in OpenGL is vrij voor de hand liggend.

Hier en daar zijn er echter wel aandachtspunten en dienen maatregelen genomen te worden.

Zo bepalen de Euler hoeken bijvoorbeeld wel de richting van een bot, maar niet de zin.

Bovendien dient er een startpositie van de sensor gedefinieerd te zijn, want met welke

orientatie komen bijvoorbeeld de hoeken (0, 0, 0) overeen?

Welnu, inherent aan het ontwerp van de sensoren is deze startpositie. Wanneer de ontvan-

gen Euler hoeken (0, 0, 0) zijn, zal de desbetreffende sensor gelegen zijn in het horizontale

vlak, in de richting van de positieve z-as (zie figuur 4.2). Hieruit zou foutief kunnen beslo-

ten worden dat ook de zin van een bone eenduidig bepaald is met een set Euler hoeken.

Alhoewel er enige waarheid in schuilt, mag hier niet van uitgegaan worden. Zo zullen

de Euler hoeken (0, π, 0) wel degelijk de richting van het bone omdraaien en het in de

HOOFDSTUK 4. AVATAR ANIMATIE 16

Figuur 4.2: Startpositie sensor, hoeken (0, 0, 0).

negatieve z-richting laten wijzen, maar wat als de sensor omgekeerd aan het lichaam is

vastgehecht? Hoewel het bone in de ene zin wijst, zal de sensor de andere zin aanduiden.

Om dergelijke ambiguıteiten te voorkomen, dient dus een conventie in acht genomen te

worden. Deze bepaald dat bij een lichaam in rust, de output van elke sensor in de Euler

hoeken (π/2, 0, 0) moet resulteren. Met andere woorden, de sensor wijst neerwaarts op een

lichaam in rust. Bij bones waarbij de effectieve rustpositie hiervan verschilt, dient deze

expliciet opgegeven te worden zodat hiervoor gecompenseerd kan worden. Bones van dit

type zijn bijvoorbeeld UT (opwaarts), schouders en heupen (zijwaarts)1.

Om de bones correct te orienteren wordt hun rotatiematrix berekend. Deze matrix drukt de

transformatie uit die ervoor zorgt dat een bone van zijn beginpositie naar zijn eindpositie

geroteerd wordt. Zoals reeds eerder aangehaald in (4.5) wordt dit geımplementeerd door

drie aparte rotaties te concateneren, zijnde de rotaties rond de x, z en y-as:

R = XZY, (4.4)

R =

1 0 0

0 cos θx − sin θx

0 sin θx cos θx

cos θz − sin θz 0

sin θz cos θz 0

0 0 1

cos θy 0 sin θy

0 1 0

− sin θy 0 cos θy

. (4.5)

De rotatiematrix wordt verder ook gebruikt om de constraints aan te passen. De constraints

van een bone worden op dezelfde manier getransformeerd als de parentbone. Een elleboog

zal bijvoorbeeld de bewegingsruimte van de onderarm wel bepalen, maar zijn positie wordt

zelf bepaald door de bovenarm.

1Verder in de tekst zal blijken dat schouders en heupen fixed bones zijn die aan hun parentbone vast

zitten en dus niet hun eigen sensor hebben. Ze nemen eenvoudigweg de relatieve rotatie van hun parent

over.

4.2. PREPROCESSING: LAAGDOORLAAT FILTER 17

4.2 Preprocessing: laagdoorlaat filter

Wanneer het skelet getekend wordt zonder enige modificatie van de Euler hoeken, wordt

ruis zichtbaar. Deze ruis manifesteert zich in de vorm van een ’bevend’ skelet. Bovendien

zullen er fouten in de Euler hoeken zijn door snelle bewegingen van de speler. Beide

fenomenen zijn vooral dominant in de hogere frequenties. Door de Euler hoeken te filteren

met een laagdoorlaat filter zullen beide effecten grotendeels onderdrukt worden zodat een

beter skelet bekomen wordt.

4.2.1 Eerste poging: moving average

Een eerste poging bestond uit het gebruik van een moving average filter met 8 taps. De

motivatie voor dit type filter ligt in het volgende:

1. Lowpass filter, zodat de bevingen uitgedempt worden.

2. Acht taps, om de real-time verwerking te garanderen. Een complexe filterstructuur

zou een te grote vertraging impliceren wat de erg storend is tijdens het gamen.

3. Visuele controle gaf voldoening.

In figuur 4.3 is transfertkarakteristiek van dit filter samen met de frequentie-inhoud van

de data te zien2. Het is duidelijk dat de hoge frequenties (hoofdzakelijk ruis) onderdrukt

worden, terwijl de lage frequenties er bijna onverzwakt doorkomen. Het grote nadeel van

dit filter is dat de snelle bewegingen vrijwel onverzwakt zijn. Er treden dus nog steeds

glitches op. Een bijkomend nadeel is dat de vertraging bij 8 taps reeds merkbaar was.

Voor gaming is dit een potentieel probleem, een nog groter filter zou te grote vertragingen

impliceren.

4.2.2 Tweede poging:

Om de nadelen van het moving average filter te voorkomen, is een tweede filter ontworpen.

Dit maal gaat het om een tweede orde IIR filter [15] met als transferfunctie

H(z) =b1 + b2z

−1 + b3z−2

a1 + a2z−1 + a3z−2. (4.6)

De waarden van de filtercoefficienten zijn getabelleerd in tabel 4.2. De BIBO stabiliteit

2De gebruikte data om het frequentiespectrum te bekomen is een boksbeweging. Zoals later zal blijken

hebben echter alle bewegingen quasi dezelfde spectrale inhoud.

HOOFDSTUK 4. AVATAR ANIMATIE 18

0 5 10 15 20 25 30 35 40 45 50−70

−60

−50

−40

−30

−20

−10

0

f (Hz)

A(dB)

Data

Filter

Figuur 4.3: Transfertkarakteristiek moving average filter en frequentie-inhoud data.

Tabel 4.2: Filtercoefficienten.

i ai bi

1 1 0.81472481463460056

2 1.6154492898716899 -0.52980798866291201

3 0.71232497355444402 0.81349179915980696

van dit filter is gegarandeerd, zoals duidelijk te zien is in figuur 4.4(b) [16]. Tot slot wordt

nog de transfertkarakteristiek van dit filter weergegeven in figuur 4.4(a).

Ook dit filter wordt geschikt geacht na visuele controle. De ruis is nog steeds goed on-

derdrukt, maar ook de snelle glitches zijn nu grotendeels weggewerkt. Bovendien is de

vertraging veroorzaakt door dit filter minimaal: bij het aanleggen van een stap duurt het

ongeveer 70 ms om de eindwaarde te bereiken, waarna een uitslingergedrag wordt vertoond

van ongeveer 150 ms. Het stapantwoord is te zien in figuur 4.4(c).

4.3 Correctie

Om tot de finale houding van de avatar te komen, dienen nog enkele correcties doorgevoerd

te worden. Indien dit niet gebeurt, zal de avatar onrealistische en soms zelfs onmogelijke

poses aannemen (zie figuur 4.5 voor een vergelijking tussen een skelet met en zonder cor-

rectie in dergelijke situatie). Hiertoe zijn constraints of beperkingen ingevoerd, ze zorgen

4.3. CORRECTIE 19

0 5 10 15 20 25 30 35 40 45

−40

−35

−30

−25

−20

−15

−10

−5

0

Frequency (Hz)

Magnitude(dB)

(a) Transfertkarakteristiek.

−1 −0.5 0 0.5 1

−1

−0.8

−0.6

−0.4

−0.2

0

0.2

0.4

0.6

0.8

1

Real Part

Imaginary

Part

(b) Pole zero plot.

0 10 20 30 40 50

0.2

0.4

0.6

0.8

1

Samples

Amplitude

Step Response

(c) Stapantwoord.

Figuur 4.4: Het IIR filter.

ervoor dat de mogelijke positie van een bone beperkt wordt tot een subset van de ruimte.

Aan de hand van de fysiologie van het menselijk lichaam kunnen de constraints voor

bepaalde lichaamsdelen bepaald worden. Zo kan een onderarm bijvoorbeeld niet verder

dan 180◦ plooien ten opzichte van de bovenarm.

Het spreekt voor zich dat de mogelijke posities waarin een ledemaat zich kan bevinden

rechtstreeks afhankelijk zijn van het lichaamsdeel waaraan het vast hangt, met andere

woorden zijn parent bone. Dit brengt als nadeel met zich mee dat wanneer het parentbone

foutief georienteerd is, de fout kan propageren via de child bones en zo een nefaste invloed

hebben op de rest van het skelet. Het is dus essentieel dat een bone correct geplaatst

wordt alvorens verder te gaan naar zijn eventuele child bones. Omdat een correctie op het

skelet echter nooit een perfecte nabootsing van de werkelijkheid kan garanderen, zal ook

hiermee moeten rekening gehouden worden, er zal als het ware een zekere tolerantie op de

HOOFDSTUK 4. AVATAR ANIMATIE 20

(a) ongecorrigeerd. (b) gecorrigeerd.

Figuur 4.5: Vergelijking gecorrigeerd en ongecorrigeerd skelet.

constraints nodig zijn.

Concreet worden de bones in vier klassen opgedeeld. Elke klasse heeft zijn eigen manier

om de constraints toe te passen. Zo zijn er free bones, dewelke helemaal geen beperkingen

hebben. Ze worden getekend in overeenstemming met de ontvangen Euler hoek. Het enige

vrije bone is het LT.

Een tweede soort bones zijn de fixed bones. Deze bones hangen vast aan hun parent. Hun

relatieve positie ten opzichte van elkaar verandert niet. Deze bones hebben dan normaal

gezien ook geen eigen sensor toegewezen. Het gaat hier meer bepaald over de heupen en

schouders.

Een derde manier om constraints toe te passen is via single plane constraint bones of SPB.

Dit zijn bones die vast hangen aan hun parent door een scharniergewricht. Ze kunnen enkel

bewegen in het vlak gedefinieerd door dit scharniergewricht en hun parent3. Bovendien is

hun beweging beperkt tot ruwweg 180◦ in dit vlak. Bones van dit type zijn de onderarmen

en -benen.

3Het vlak staat loodrecht op de scharnieras en bevat de parent bone.

4.3. CORRECTIE 21

Als vierde en laatste type zijn er de multiple plane constraint bones of MPB. Dit zijn bones

die kunnen bewegen in meerdere vlakken, zij het niet de volledige ruimte. Er zijn als het

ware ’verboden gebieden’ waarin ze niet kunnen gelegen zijn. Bovenarmen, bovenbenen en

upper torso zijn van dit type.

Figuur 4.6 visualiseert de single en multiple plane constraint bones.

(a) Single plane. (b) Multiple plane.

Figuur 4.6: Visualisatie single en multiple constraints.

4.3.1 Standaardconstraints

Er is reeds een standaard set van constraints voorzien, afgestemd op een eerder lenig per-

soon. Indien deze standaardwaarden niet voldoen, kunnen ze eenvoudig aangepast worden.

Er is in de mogelijkheid voorzien om per bone criteria toe te voegen en te verwijderen.

Om een beeld te krijgen van de gebruikte constraints bestaat de mogelijkheid erin ze te

visualiseren. De visualisatie voor de SPB constraints tekent de as waarrond een bone kan

roteren terwijl het voor de MPB de vlakken tekent die het verboden gebied afbakenen.

4.3.2 Free bone

Zoals reeds vermeld is, zal bij bones van dit type geen correctie toegepast worden. De

orientatie ervan is rechtstreeks bepaald door de sensorwaarden zonder meer. Het enige bot

waarop dit toegepast wordt is de LT, omdat dit bone vertrekt vanuit de root. Men zou

HOOFDSTUK 4. AVATAR ANIMATIE 22

kunnen verwachten dat ook UT van dit type is. Dit is echter niet het geval aangezien er

nog een beperking is van de orientatie van de LT en UT ten opzichte van elkaar.

4.3.3 Fixed bone

Bones van dit type negeren hun eventuele sensorwaarden en nemen de (gecorrigeerde)

rotatie van hun parent rechtstreeks over. Op die manier wordt een star lichaam bestaande

uit meerdere segmenten bekomen. De toepassing van dit type wordt terug gevonden bij

de heup en schouders, zij hangen namelijk ook vast aan de LT respectievelijk UT in het

menselijk lichaam. De verwezenlijking hiervan gebeurd door simpelweg de rotatiematrix

van de parent over te nemen.

4.3.4 Single plane constraint bone

Bij deze bones wordt hun bewegingsruimte beperkt tot een halfvlak (vanaf nu het correc-

tievlak genaamd) dat de parentbone bevat en met als normaalvector de scharnieras van

het gewricht. Wanneer een bone buiten dit vlak valt volgens zijn sensor (zie figuur 4.7(a)),

zal correctie toegepast worden.

Een eerste manier om deze correctie toe te passen was door het bone te roteren rond de as

gedefinieerd door de parentbone. De hoek tussen de bone en zijn parent bleef dus dezelfde

voor en na correctie. Deze manier werkte, maar gaf geen voldoening. In sommige gevallen

nam het skelet nog steeds een onrealistische houding aan. Dit viel vooral voor wanneer

de hoek tussen het vlak dat de parentbone en het ongecorrigeerd bone bevat, vanaf nu

het sensorvlak genaamd, en het correctievlak, naar 90◦ naderde. Een voorbeeld van deze

correctiemethode toegepast is te zien in figuur 4.7(b).

De tweede en finale correctiemethode bestaat eruit het bone te projecteren naar het cor-

rectievlak. Aangezien dit vlak reeds gekend is, dient enkel nog de hoek tussen het gecorri-

geerde bot en zijn parent γcor berekend te worden. De hoek wordt berekend op de manier

hieronder uiteengezet.

1. Bereken de normaalvector Nsens van het sensorvlak.

2. Bereken de hoek αsens tussen de bone en zijn parent.

3. Bereken de hoek βas tussen Nsens en de scharnieras Nschar.

4.3. CORRECTIE 23

4. Indien βas groter is dan 90◦, betekend dit dat de arm in het verboden halfvlak zal

liggen na projectie. Zoniet, sla de volgende 2 stappen over.

5. Wanneer αsens kleiner is dan 90◦, wordt γcor=0◦.

6. Wanneer αsens groter is dan 90◦, wordt γcor=180◦.

7. Indien βas kleiner is dan 90◦, projecteer het bone op het correctievlak volgens formules

(4.7) en (4.8).

αsens < 90◦ ⇒ γcor = arctan

(sin(αsens) cos(βas)

cos(αsens)

), (4.7)

αsens > 90◦ ⇒ γcor = 180◦ − arctan

(− sin(αsens) cos(βas)

cos(αsens)

). (4.8)

Het resultaat van deze correctie is te zien in figuur 4.7(c).

(a) Foutieve positie. (b) Eerste correctiemethode. (c) Tweede correctieme-

thode.

Figuur 4.7: SPB correcties. De hoek tussen sensor- en correctievlak bedraagt 85◦.

4.3.5 Multiple plane constraint bone

Om een multiple plane bone te corrigeren wordt gebruik gemaakt van verboden zones.

Wanneer een bone in dergelijke zone gepositioneerd wordt volgens de sensordata, zal deze

gecorrigeerd worden (zie figuur 4.6(b)). Dit gebeurt door projectie op het kortst bijgelegen

randgebied. Volgende stappen worden doorlopen om de correctie uit te voeren. figuren

4.8(a) en 4.8(b) illustreren deze methode.

HOOFDSTUK 4. AVATAR ANIMATIE 24

• Voor een verboden zone bestaande uit n hoekpunten, wordt gecontroleerd of het

bone gesitueerd is in een van de n− 2 subzones die de volledige zone opbouwen. Dit

gebeurt door volgende stappen uit te voeren voor elke subzone.

1. Bereken de normaalvector Nv op het vlak gedefineerd door de oorsprong en twee

van de drie hoekpunten van de subzone.

2. Bereken het scalair product van Nv en de vector vertrekkend vanuit de oorsprong

naar het derde hoekpunt (Vhoek).

3. Bereken het scalair product van Nv en de vector vertrekkend vanuit de oorsprong

naar de eindpositie van het bone (Vsens).

4. Indien beide producten hetzelfde teken hebben, liggen ze aan dezelfde kant van

het vlak.

5. Herhaal deze procedure voor de overige twee vlakken.

6. Indien stap 4 drie maal waar evalueert, ligt de bone in de subzone.

• Indien het bone in een van de subzones ligt, ligt het logischer wijs ook in de volledige

zone. Nu wordt het dichtstbijzijnde grensvlak gezocht door volgende stappen te

herhalen voor elk van deze vlakken.

1. Bereken de normaalvector op het grensvlak.

2. Bereken het scalair product van deze normaalvector en de vector vertrekkend

uit de oorsprong en gaande naar het eindpunt van de bone (Vsens).

• Het grensvlak waarvan dit resultaat de kleinste absolute waarde heeft, ligt het dichtst-

bij.

• Roteer het bone van zijn ongecorrigeerde positie naar de rand van dit vlak.

De laatste stap kan overbodig lijken, de projectie is reeds de correcte orientatie van het

bone. Dit klopt in zekere mate: de positie is dezelfde, maar de rotatie rond de eigen as

(hiermee wordt de as die samenvalt met het bone zelf bedoeld) niet. De informatie over de

rotatie hierrond gaat verloren. Om deze informatie te behouden dient er dus vertrokken

te worden van het ongecorrigeerde bone, om zo tot een geschikte correctie te komen. Deze

fout is niet meteen zichtbaar op het bone zelf, maar zal zeker zijn invloed hebben op zijn

children.

4.4. TOLERANTIE 25

(a) Subzones en randgebieden. De volledige ver-

boden zone heeft hier 5 hoekpunten. De grens-

vlakken zijn transparant violet, de subzones af-

gebakend door de groene driehoeken.

(b) Ingezoomd op 1 subzone. In de oorsprong

komt de parentbone toe en vertrekt het child-

bone zelf. Deze zijn weggelaten om overzicht te

bewaren.

Figuur 4.8: Illustraties bij correctiemethode MPB.

4.4 Tolerantie

Tot slot van dit hoofdstuk wordt de oplossing voor de problemen aangehaald in sectie

3.3 besproken. Opdat de fout veroorzaakt door kledij, huid en plaatsing niet verder zou

propageren doorheen het skelet, wordt een tolerantie op de constraints ingevoerd. Deze

tolerantie is toepasbaar op SPB en MPB types en compenseert als het ware een altijd

aanwezige fout in de sensorwaarden. De manier waarop ze geımplementeerd wordt is

verschillend voor beide types bones.

Bij de single plane constraint bones kan de scharnieras afwijken van zijn theoretische lig-

ging. Hij zal over een zekere hoek α gedraaid zijn naar de scharnieras volgens de sensor-

waarden toe. De maximum toegelaten verdraaiing αmax van deze as is standaard ingesteld

op 20◦, maar kan zonder probleem aangepast worden. Indien het verschil tussen de the-

oretische scharnieras en deze volgens de sensorwaarden, kleiner is dan αmax, zal er geen

correctie toegepast worden, en de bone getekend worden volgens zijn sensorwaarden. In-

dien de hoek groter is dan αmax, wordt de theoretische as verdraaid over deze αmax naar

de as volgens de sensorwaarden toe. Vervolgens wordt er correctie toegepast volgens sectie

4.3.4. Omdat figuren soms meer zeggen dan woorden, wordt in figuur 4.9 de tolerantie

grafisch weergegeven.

HOOFDSTUK 4. AVATAR ANIMATIE 26

Figuur 4.9: Tolerantie bij SPB. De dunne stippellijnen horen bij correctie zonder tolerantie, de

volle rode lijn is correctie waarbij rekening gehouden is met tolerantie.

Bij de multiple plane constraint bones wordt de tolerantie geımplementeerd door de ge-

corrigeerde versie toch toe te laten in een verboden gebied, weliswaar niet zonder rekening

te houden met eerdere correcties. Wat gebeurt is het volgende. Wanneer een bone in een

verboden gebied geplaatst wordt volgens de sensoren, treedt correctie op volgens 4.3.5. De

volgende stap is om nu deze correctie over een afstand te verplaatsen naar het ongecorri-

geerd bone toe. Het komt zo echter in het verboden gebied te liggen. De afstand tussen de

correctie en het grensvlak is proportioneel met de afstand tussen de ongecorrigeerde bone

en het grensvlak. Deze proportionaliteitsfactor Γ is standaard ingesteld op 0.2, maar kan

ook hier eenvoudig aangepast worden. Figuur 4.10 illustreert dit alles.

Figuur 4.10: Tolerantie bij MBP. Dit is een bovenaanzicht van de verboden zone. Groen is het

ongecorrigeerd bone, oranje de correctie zonder tolerantie en rood de correctie met

tolerantie.

27

Hoofdstuk 5

Bewegingsherkenning

In vorig hoofdstuk werd beschreven hoe de weergave van de avatar op het scherm tot stand

komt. In dit hoofdstuk komt het herkennen van specifieke bewegingen in deze weergave aan

bod. Hierdoor ontstaat de mogelijkheid om de speler van het videospel interactief te laten

deelnemen aan de virtuele wereld rondom hem. Een aantal voorbeelden van zo’n bewe-

gingen zijn onder andere: op een knop drukken, vijanden schoppen, bepaalde voorwerpen

oprapen, ... Teneinde deze bewegingen te kunnen herkennen wordt gebruik gemaakt van

het principe van Dynamic Time Warping. In wat volgt wordt er steeds vanuit gegaan

dat de ontvangen data reeds werd omgezet in Euler hoeken. De bemonsteringsfrequentie

bedraagt 100Hz.

5.1 Dynamic Time Warping

Dynamic Time Warping of kortweg DTW is een algoritme dat gelijkenissen opspoort tussen

twee sequenties van gegevens die verschillen in snelheid [17]. Het algoritme zoekt dan

een optimaal verband tussen deze twee sequenties waardoor deze op elkaar geprojecteerd

kunnen worden. Dit gebeurt meestal op een sterk niet-lineaire manier. Deze methode zoekt

dus de gelijkenis tussen twee sequenties onafhankelijk van (niet-lineaire) variaties in de

tijdsdimensie. Om bewegingen te herkennen zal een referentiedatabase worden opgebouwd

die een referentiesequentie bevat voor elke beweging. Deze referentiesequentie wordt dan

vergeleken met de ontvangen data.

HOOFDSTUK 5. BEWEGINGSHERKENNING 28

5.1.1 Werking

Stel dat de referentiesequentie sref een lengte n heeft. De ontvangen sequentie srec heeft

een lengte m. Beschouw nu de kostmatrix K met elementen ki,j,i=1..n en j=1..m:

K =

k1,1 k1,2 · · · k1,m

k2,1. . .

......

. . . kn−1,m

kn,1 · · · kn,m−1 kn,m

. (5.1)

Deze matrix wordt als volgt opgebouwd: voor elk element van sref wordt een afstandsme-

triek (zie sectie 5.1.2) berekend met elk element van srec. Zo wordt voor het i-de element

van sref de afstandsmetriek bepaalt met het j-de element van srec. Dit resultaat wordt

opgeslagen in ki,j.

Eens de totale kostmatrix is opgevuld, wordt een pad bepaald dat de twee sequenties op

elkaar zal projecteren. Hiervoor wordt vertrokken vanuit het k1,1 element. Achtereenvol-

gens wordt nu het volgende element gekozen dat de kleinste metriek zal opleveren. De

elementen die kunnen worden gekozen zijn de elementen k1,2, k2,2 en k2,1. Ofwel rechts,

links en diagonaal van het vorige element. De kleinste metriek wordt nu bijgehouden en

vanuit het nieuwe element wordt dit herhaald en de kleinste metriek bij de eerder gevon-

den metriek opgeteld. Dit gebeurt zo verder uiteindelijk het punt kn,m bereikt wordt. De

opeenvolging van elementen die doorlopen werden, vormt het pad dat de projectie van

de twee sequenties vastlegt. De eindwaarde die bereikt werd door het optellen van alle

metrieken vormt een maat voor de gelijkenis die tussen de twee sequenties bestaat. Deze

maat wordt gedefinieerd als de kost tussen beide sequenties.

Een voorbeeld van twee gelijkaardige sequenties is te vinden op figuur 5.1(a). In dit voor-

beeld wordt een referentiepuls (blauw) vergeleken met een ontvangen puls (rood). De

ontvangen puls is een artifciele puls waarbij een zekere willekeur is toegevoegd aan de

amplitude en frequentie. Het DTW-algoritme berekent het meest optimale pad en het

resultaat is te zien op figuur 5.1(b). De rode lijn geeft het meest optimale pad aan. De

achtergrond is donkerder naarmate de waarde in de kostmatrix groter is. Uit deze figuur

kan men afleiden dat de beginpunten van de ontvangen sequentie gealigneerd worden met

ongeveer het honderdste punt van de ontvangen sequentie. Daarna is de mapping redelijk

lineair tot aan het punt zeshonderd. Vanaf hier wordt de projectie iets steiler. Controleert

men deze redenering visueel op de figuur bovenaan dan voelt men ook intuıtief aan dat deze

5.1. DYNAMIC TIME WARPING 29

(a) Voorbeeld van 2 sequenties. (b) DTW van 2 sequenties.

Figuur 5.1: DTW algoritme bij 2 voorbeeldsequenties.

projectie optimaal is. Merk op dat de kostmatrix hierbij werd opgebouwd van linksonder

naar rechtsboven.

5.1.2 Afstandsmetriek

In paragraaf 5.1.1 werd de werking van het DTW algoritme besproken. Een belangrijke

keuze bij het implementeren van dit algoritme is de afstandsmetriek. Hiervoor zijn ver-

schillende mogelijkheden, waaronder de meest eenvoudige wordt gegeven door

dabs(A(i), B(j)) = |A(i)−B(j)|. (5.2)

Deze keuze leidt echter niet tot het gewenste effect bij onze toepassing. Het probleem dat

hierbij aan de basis ligt is het Kalmanfilter. Dit filter steunt heel sterk op de continuıteit

van de invoergegevens. De Euler hoeken die berekend worden liggen normaal in het bereik

[0, 360[. Dit komt omdat deze hoeken modulo 360◦ worden bepaald. Een modulo-operatie

is echter een sterk niet-lineaire operator en dus niet geschikt voor gebruik in combinatie

met het Kalmanfilter. Om het Kalmanfilter alsnog te kunnen gebruiken zullen de hoeken

doorlopen buiten het bereik [0, 360[. Stel dat men nu functie (5.2) wil gebruiken als af-

standsmetriek wordt een andere metriek bekomen voor hoeken die 360◦ groter zijn maar

fysiek dezelfde betekenis hebben. Om deze problemen te adresseren wordt de afstandsme-

triek gewijzigd in

dang(A(i), B(j)) = Bgcos [cos(A(i)).cos(B(j)) + sin(A(i)).sin(B(j)))] . (5.3)

Dit is niets anders dan de kleinste fysieke hoek berekenen tussen de hoeken A(i) en B(j).

HOOFDSTUK 5. BEWEGINGSHERKENNING 30

5.1.3 DTW in meerdere dimensies

In paragraaf 5.1.1 werd de werking van het DTW algoritme voor scalaire grootheden be-

sproken. De gegevens afkomstig van de sensormodules zijn Euler hoeken en dus niet scalair.

Stel k de kost en n het aantal sensoren. Er ontstaan nu verschillende mogelijkheden:

1. Het DTW-algoritme wordt uitgevoerd op de verschillende dimensies afzonderlijk en

dit voor elke sensor. De totale kost wordt gesommeerd over de verschillende dimensies

en sensoren.

k =n∑

t=1

∑u=x,y,z

kt,u, (5.4)

d(A(i), B(j)) = dang(A(i), B(j)). (5.5)

2. Het DTW-algoritme wordt uitgevoerd per sets van 3 Euler hoeken. De afstandsme-

triek is nu de som van de afzonderlijk metrieken. De totale kost wordt gesommeerd

over de verschillende sensoren.

k =n∑

t=1

kt, (5.6)

d(A(i), B(j)) =∑

u=x,y,z

dang(Au(i), Bu(j)). (5.7)

3. Het DTW-algoritme wordt uitgevoerd op de som van de sensorwaarden en afzon-

derlijk voor elke dimensie. De totale kost wordt gesommeerd over de verschillende

dimensies.

k =∑

u=x,y,z

ku, (5.8)

d(A(i), B(j)) = dang

(n∑

t=1

At(i),n∑

t=1

Bt(j)

). (5.9)

4. Het DTW-algoritme wordt uitgevoerd op de som van de sensorwaarden en per Euler

hoek. De uitkomst hiervan is dan de totale kost

k = k, (5.10)

d(A(i), B(j)) =∑

u=x,y,z

dang

(n∑

t=1

At,u(i),n∑

t=1

Bt,u(j)

). (5.11)

5.2. BOKSBEWEGING 31

Mogelijkheid 1 en 3 worden onmiddellijk verworpen. Bij het uitvoeren van de bewegingen

hangen de x,y en z componenten aan elkaar vast. Het is dus fysisch gezien incorrect om deze

waarden los te koppelen van elkaar en dan het meest optimale pad te bepalen. Bewegingen

die in hun geheel niet op het origineel gelijken kunnen alsnog gematched worden door een

andere tijdsindeling van hun dimensies. Mogelijkheid 2 en 4 worden verder in dit hoofdstuk

getest op bruikbaarheid.

In bovenstaande methodes kunnen ook nog kleine variaties ingevoerd worden. Zo kan

men de sommaties bijvoorbeeld vervangen door een gewogen som. Dit kan nuttig zijn

wanneer sommige sensormodules weinig specifieke informatie over de beweging leveren.

De sensoren of dimensies die belangrijk zijn krijgen dan een hogere wegingscoefficient en

zijn meer doorslaggevend voor het eindresultaat. Zo kunnen de vergelijkingen horend bij

methode 2 algemeen geschreven worden als

k =

n∑t=1

gtkt

n∑t=1

gt

(5.12)

en

d(A(i), B(j)) =

∑u=x,y,z

gudang(Au(i), Bu(j))∑u=x,y,z

gu. (5.13)

waarbij gt en gu de wegingscoeffecienten voorstellen van respectievelijk de sensormodules

en de dimensies. Tenzij anders vermeld wordt in wat volgt een eenheidsgewicht aan elk

van de coefficienten toegekend.

5.2 Boksbeweging

5.2.1 Referentiebeweging

5.2.1.1 Tijdsdomein

Als basisbeweging voor het spelen van videogames wordt vertrokken van de boksbeweging.

Vier sensormodules werden aangebracht in het midden van de boven- en onderarmen van

een testspeler. De boksbeweging werd vervolgens rechtshandig uitgevoerd en het resultaat

hiervan kan u zien in figuur 5.2 waarbij de afkortingen conform tabel 4.1 zijn. De waarden

die worden bekomen zijn de X, Y en Z component van de Euler hoeken die voor elke sensor

berekend werden. In het tijdsdomein zijn er duidelijk veranderingen aanwezig, vooral in

HOOFDSTUK 5. BEWEGINGSHERKENNING 32

(a) RUA sequentie (b) LUA sequentie

(c) RLA seqentie (d) LLA sequentie

Figuur 5.2: De rechtshandige boksbeweging.

de rechter bovenarm en de linker onderarm. De linker bovenarm bezit weinig informatie

en blijft relatief constant.

5.2.1.2 Frequentiedomein

In het frequentiedomein ziet deze sequentie er dan uit zoals op figuur 5.3. Deze grafieken

werden bekomen met een Hanning window met een venstergrootte van 64 elementen. Zoals

men kan zien in de verschillende grafieken bezit het frequentiedomein niet veel specifieke

informatie over de boksbeweging. Buiten een sterke dc-component zijn er verder geen

noemenswaardige effecten te bespeuren. Het onderzoek zal zich dan ook toespitsen op

analyse in het tijdsdomein.

5.2. BOKSBEWEGING 33

(a) RUA sequentie (b) LUA sequentie

(c) RLA seqentie (d) LLA sequentie

Figuur 5.3: De rechtshandige boksbeweging in het frequentiedomein.

5.2.2 Testsequentie

5.2.2.1 Tijdsdomein

Om meer inzicht in deze materie te bekomen werd een beweging uitgevoerd waarbij eerst

met de armen voor zich uit werd gezwaaid om daarna drie achtereenvolgende boksbewe-

gingen uit te voeren. De eerste twee boksbewegingen werden aan een normaal tempo

uitgevoerd, de laatste iets sneller. Het resultaat is te zien op figuur 5.4. Op deze figuur kan

men visueel heel duidelijk de verschillende boksbewegingen herkennen. De exacte locatie

kan men terugvinden in tabel 5.1. De analyse in het frequentiedomein leverde net zoals bij

de referentiebeweging geen verdere informatie op.

HOOFDSTUK 5. BEWEGINGSHERKENNING 34

(a) RUA sequentie (b) LUA sequentie

(c) RLA seqentie (d) LLA sequentie

Figuur 5.4: Testsequentie van opeenvolgende boksbewegingen.

5.2.2.2 Boksherkenning

Er wordt nu onderzocht wat de uitkomst is van het DTW-algoritme op deze opeenvolgende

boksbewegingen. Een venster van 300 waarden wordt telkens met 20 elementen opgescho-

ven. Het DTW-algoritme berekent de gelijkenis die dit venster en de referentiesequentie

met elkaar hebben. De berekening gebeurt zowel via methode 2 (vergelijking (5.7)) als

via methode 4 (vergelijking (5.11)). Het resultaat hiervan is de zogenaamde kost en is te

bekijken op figuur 5.5. Zoals men kan zien volgen beide curves zeer nauwkeurig de verschil-

lende boksbewegingen. Hoe correcter het tijdstip waarover het venster geplaatst wordt,

hoe lager de kostfunctie wordt. In de grafieken kan men ook hypothetisch een drempel-

waarde aanbrengen. Wanneer de kost onder deze drempelwaarde komt, kan men van een

gedetecteerde boksbeweging spreken. In figuur 5.5(a) is het dynamisch bereik tussen de

berekende kostwaarden veel groter dan in figuur 5.5(b). Bijgevolg geniet deze methode dan

5.3. WUIFBEWEGING 35

Tabel 5.1: Bewegingen aanwezig in de testsequentie.

beweging snelheid begin eind duur

1 traag 7,73 9,67 1,94s

2 traag 12,55 14,89 2,34s

3 snel 17,33 18,24 0,91s

ook de voorkeur daar zij minder gevoelig zal zijn aan de drempelwaarde.

(a) Kost via methode 2. (b) Kost via methode 4.

Figuur 5.5: De kost i.f.v. de tijd bij de boksbeweging.

5.3 Wuifbeweging

5.3.1 Referentiebeweging

5.3.1.1 Tijdsdomein

Analoog aan de boksbeweging werden nu twee sensormodules aangebracht in het midden

van de rechter boven- en onderarm van een testspeler. Vervolgens werd een keer gezwaaid

met de rechterhand. Het resultaat hiervan kan u zien in figuur 5.6 waarbij de afkortingen

conform tabel 4.1 zijn.

5.3.1.2 Frequentiedomein

In het frequentiedomein ziet deze sequentie er dan uit zoals op figuur 5.7. Deze grafieken

werden bekomen met een Hanning window met een venstergrootte van 64 elementen. Het

HOOFDSTUK 5. BEWEGINGSHERKENNING 36

(a) RUA sequentie (b) RLA sequentie

Figuur 5.6: De rechtshandige wuifbeweging.

is duidelijk dat er in het frequentiedomein alweer niet veel specifieke informatie over de

wuifbeweging te halen valt. Buiten een sterke dc-component zijn er verder geen noemens-

waardige effecten te bespeuren. Het onderzoek zal zich dan ook toespitsen op analyse in

het tijdsdomein.

(a) RUA sequentie (b) RLA seqentie

Figuur 5.7: De rechtshandige wuifbeweging in het frequentiedomein.

5.3. WUIFBEWEGING 37

5.3.2 Testsequentie

5.3.2.1 Tijdsdomein

Een testsequentie werd opgenomen waarbij driemaal een wuifbeweging uitgevoerd werd.

Het resultaat is te zien op figuur 5.8. Op deze figuur zijn de verschillende wuifbewegingen

zeer duidelijk te herkennen. De exacte locatie kan men terugvinden in tabel 5.2. De analyse

in het frequentiedomein leverde net zoals bij de referentiebeweging geen verdere informatie

op.

(a) RUA sequentie (b) RLA sequentie

Figuur 5.8: Testsequentie van drie opeenvolgende wuifbewegingen.

Tabel 5.2: Bewegingen aanwezig in de testsequentie.

beweging snelheid begin eind duur

1 normaal 2,47 3,97 1,50s

2 normaal 3,97 5,93 1,96s

3 normaal 5,93 7,62 1,69s

5.3.2.2 Wuifherkenning

Analoog aan de boksbeweging wordt er nu onderzocht wat de uitkomst is van het DTW-

algoritme op deze opeenvolgende wuifbewegingen. Een venster van 200 waarden wordt

telkens met 20 elementen opgeschoven. Het DTW-algoritme berekent de gelijkenis die dit

venster en de referentiesequentie met elkaar hebben. Het resultaat hiervan is de kost en

is te bekijken op figuur 5.9. Zoals men kan zien volgen beide curves zeer nauwkeurig de

HOOFDSTUK 5. BEWEGINGSHERKENNING 38

verschillende wuifbewegingen. Hoe correcter het tijdstip waarover het venster geplaatst

wordt, hoe lager de kostfunctie wordt. In de grafieken kan men ook hypothetisch een

drempelwaarde aanbrengen. Wanneer de kost onder deze drempelwaarde komt, kan men

van een gedetecteerde wuifbeweging spreken. Het het dynamisch bereik in beide figuren is

gelijkaardig. De prestaties van beide methodes zijn dan ook gelijkaardig.

(a) Kost via methode 2 (b) Kost via methode 4

Figuur 5.9: De kost i.f.v. de tijd bij de wuifbeweging.

5.4 Schopbeweging

5.4.1 Referentiebeweging

5.4.1.1 Tijdsdomein

Een derde beweging die onderzocht wordt voor het spelen van videogames is de schopbewe-

ging. Vier sensormodules werden aangebracht in het midden van de boven- en onderbenen

van een testspeler. De schopbeweging werd vervolgens rechtsvoetig uitgevoerd en het re-

sultaat hiervan kan u zien in figuur 5.10 waarbij de afkortingen conform tabel 4.1 zijn.

5.4.1.2 Frequentiedomein

In het frequentiedomein ziet deze sequentie er uit zoals op figuur 5.11. Deze grafieken

werden bekomen met een Hanning window met een venstergrootte van 64 elementen.

5.4. SCHOPBEWEGING 39

(a) RUL sequentie (b) LUL sequentie

(c) RLL seqentie (d) LLL sequentie

Figuur 5.10: De rechtsvoetige schopbeweging.

Alweer is het duidelijk dat er in het frequentiedomein niet veel specifieke informatie

over de schopbeweging te halen valt. Het onderzoek zal zich hier dan ook weer toespitsen

op analyse in het tijdsdomein.

5.4.2 Testsequentie

5.4.2.1 Tijdsdomein

Om meer inzicht in deze materie te bekomen werd een beweging uitgevoerd waarbij eerst

met de benen voor zich uit werd bewogen en rondgewandeld om daarna drie achtereen-

volgende schopbewegingen uit te voeren. De eerste twee schopbewegingen werden aan een

normaal tempo uitgevoerd, de laatste iets sneller. Het resultaat is te zien op figuur 5.12.

HOOFDSTUK 5. BEWEGINGSHERKENNING 40

(a) RUL sequentie (b) LUL sequentie

(c) RLL seqentie (d) LLL sequentie

Figuur 5.11: De rechtsvoetige schopbeweging in het frequentiedomein.

Op deze figuur is het visueel minder duidelijk om de verschillende schopbewegingen her-

kennen. Dit komt omdat de hoeken hier duidelijk doordraaien tot ver boven de 360◦. Zoals

eerder aangehaald komt dit komt door het Kalmanfilter. De exacte locatie kan men echter

terugvinden in tabel 5.3.

5.4. SCHOPBEWEGING 41

(a) RUL sequentie (b) LUL sequentie

(c) RLL seqentie (d) LLL sequentie

Figuur 5.12: Testsequentie van opeenvolgende boksbewegingen.

Tabel 5.3: Bewegingen aanwezig in de testsequentie.

beweging snelheid begin eind duur

1 traag 10,16 12,23 2,07s

2 traag 14,60 16,96 2,36s

3 snel 18,68 20,15 1,47s

HOOFDSTUK 5. BEWEGINGSHERKENNING 42

5.4.2.2 Schopherkenning

Analoog aan de boksbeweging wordt er nu onderzocht wat de uitkomst is van het DTW-

algoritme op deze opeenvolgende schopbewegingen. Een venster van 350 waarden wordt

telkens met 20 elementen opgeschoven. Het DTW-algoritme berekent de gelijkenis die dit

venster en de referentiesequentie met elkaar hebben. Het resultaat hiervan is de kost en

is te bekijken op figuur 5.13. Zoals men kan zien volgen beide curves zeer nauwkeurig de

verschillende schopbewegingen. Hoe correcter het tijdstip waarover het venster geplaatst

wordt, hoe lager de kostfunctie wordt. In de grafieken kan men ook hypothetisch een

drempelwaarde aanbrengen. Wanneer de kost onder deze drempelwaarde komt, kan men

van een gedetecteerde schopbeweging spreken. In figuur 5.13(a) is het dynamisch bereik

tussen de berekende kostwaarden veel groter dan in figuur 5.13(b). Bijgevolg geniet deze

methode dan ook de voorkeur daar zij minder gevoelig zal zijn aan de drempelwaarde.

(a) Kost via methode 2. (b) Kost via methode 4.

Figuur 5.13: De kost i.f.v. de tijd bij de schopbeweging.

5.5 Interferentie

In vorige paragrafen werd met succes gepoogd verschillende bewegingen te herkennen. Het

DTW-algoritme werkt naar behoren en door het aanleggen van een testsequentie is het mo-

gelijk om een correcte drempelwaarde te bepalen. Hoewel deze methode dus werkt wanneer

men de juiste bewegingen maakt, is het ook belangrijk om te testen of het algoritme werkt

wanneer incorrecte bewegingen worden gemaakt. Bij het maken van verkeerde bewegingen

zal de kost dus boven de ingestelde drempelwaarde moeten liggen.

5.5. INTERFERENTIE 43

5.5.1 Wuif-boks interferentie

In de wuifbeweging wordt gebruik gemaakt van de rechter boven- en onderarm. De boks-

beweging maakt ook gebruik van deze sensoren en dus kan een boksbeweging ook als een

wuifbeweging worden gedetecteerd. Er wordt nu onderzocht wat de kost is als men drie

achtereenvolgende boksbewegingen projecteert op een wuifbeweging. Het resultaat is te

bekijken in figuur 5.14. Zoals men in de figuren kan waarnemen zal de drempelwaarde niet

moeten worden aangepast. De kost blijft steeds hoger dan de eerdere ingestelde drempel-

waarde.

(a) Kost via methode 2 (b) Kost via methode 4

Figuur 5.14: Wuif-boks kost i.f.v. de tijd.

5.5.2 Boks-wuif interferentie

Analoog aan vorige paragraaf wordt nu onderzocht wat de kost is als men drie achtereen-

volgende wuifbewegingen projecteert op een boksbeweging. Het resultaat is te bekijken in

figuur 5.15. Zoals men in de figuren kan waarnemen zal de drempelwaarde ook hier niet

moeten worden aangepast.

Er dient wel opgemerkt te worden dat de boksherkenning nu werd uitgevoerd op slechts twee

sensormodules. In de praktijk kan de kost dan ook sterk varieren omdat de andere sensoren

dan ook in rekening worden gebracht. Wanneer een wuifbeweging wordt uitgevoerd waarbij

met de linkerarm een beweging wordt uitgevoerd die op de boksbeweging lijkt zal deze

kost mogelijk toch nog onder de drempelwaarde dalen. Niettegenstaande deze beweging

onwaarschijnlijk lijkt, is het bestaan hiervan een potentieel probleem. Om dit probleem te

HOOFDSTUK 5. BEWEGINGSHERKENNING 44

(a) Kost via methode 2. (b) Kost via methode 4.

Figuur 5.15: Boks-wuif kost i.f.v. de tijd.

analyseren wordt het worst-case scenario bekeken. Hierbij zullen de sensormodules van de

linkerarm, steeds een kost van 0 opleveren. Deze onrealistische situatie zal ervoor zorgen

dat de kost in figuur 5.15 gehalveerd wordt. De toevoeging van 2 sensormodules zorgt in

vergelijking (5.12) immers voor een verhoging van de teller van 2 naar 4 zonder dat de

teller toeneemt. Deze situatie is voorgesteld in figuur 5.16.

(a) Worst-case kost via methode 2. (b) Worst-case kost via methode 4.

Figuur 5.16: Worst-case boks-wuif kost i.f.v. de tijd.

Hoewel dit worst-case scenario een probleem blijkt te zijn, werd de drempelwaarde maar

lichtjes overschreden. Aangezien het hier om een kunstmatige situatie gaat wordt aange-

nomen dat, indien het verschijnsel zich al zou voordoen, deze situatie uiterst zeldzaam zal

5.6. ORIENTATIE 45

zijn. Een enkele verkeerde detectie zal op zich dan ook niet tot noemenswaardig verlies

aan spelkwaliteit leiden.

5.6 Orientatie

In voorgaande situaties werd de beweging telkens uitgevoerd naar het noorden. Bijgevolg

was het mogelijk om elke situatie zonder meer met het DTW algoritme te vergelijken.

In een echte omgeving zal elke beweging echter uitgevoerd worden naar een willekeurige

windrichting. De z-informatie van de sensormodules zal dus niet langer absoluut moeten

worden bekeken, maar relatief ten opzichte van de windrichting waarnaar de speler staat.

Hiervoor dient men de referentiebewegingen te normaliseren in de windrichting. De op-

genomen beweging zal in de z-richting worden genormaliseerd naar het noorden door op

elk tijdstip van de z-waarde een referentiewaarde af te trekken. Deze referentiewaarde

wordt bekomen door een zogenaamde referentiemodule te kiezen. Deze referentiemodule

bepaalt dus hoe de speler georienteerd staat. De verschillende referentiemodules die bij

elke beweging horen vindt men terug in tabel 5.4.

(a) Boksbeweging

gericht naar het zuiden.

(b) Boksbeweging ge-

richt naar het noor-

den.

Figuur 5.17: Avatar in verschillende orientaties.

HOOFDSTUK 5. BEWEGINGSHERKENNING 46

Tabel 5.4: Relatieve bewegingen.

beweging orientatie

kloppen upper torso

wuiven upper torso

boksen lower torso

5.7 Conclusie

Alle bewegingen kunnen goed worden herkend. In de berekeningen van de kost met verschil-

lende methodes profileert methode 2 zich als de meest performante vanwege het hoger dy-

namisch bereik. Dit bewijst eigenlijk dat bij de uitvoering van enkele dezelfde bewegingen

de verschillende ledematen niet altijd op dezelfde wijze tegenover elkaar gesynchroniseerd

zijn.

Als voorbeeld kan men hiervoor de boksbeweging aanhalen. Wanneer men een rechtshan-

dige boksbeweging uitvoert zal men de linker vuist voor de borst brengen om daarna met

de rechterhand de denkbeeldige opponent een slag toe te brengen. De tijd tussen het om-

hoog brengen van de linkerarm en het slaan met de rechterarm zal bij de ene boksbeweging

iets meer bedragen dan bij de andere. Bijgevolg is er dus een verlies aan synchronisatie

tussen de verschillende sensormodules en de verschillende bewegingen. Methode 4 houdt

geen rekening met dit verschijnsel en werkt beduidend minder goed dan methode 2, welke

hiermee wel rekening houdt.

Dit verschijnsel wordt nog meer bevestigd door de wuifbeweging. Bij deze beweging wordt

enkel gebruik gemaakt van de rechterarm. De twee aangebrachte sensormodules op onder-

en bovenarm zijn zeer sterk gecorreleerd door hun fysieke afhankelijkheid van elkaar. Bijge-

volg zal de synchronisatie tussen de verschillende sensormodules nu zeer sterk zijn. Methode

2 en methode 4 presteren hier dan ook gelijkaardig. Omdat methode 2 steeds gelijkaar-

dige of betere prestaties neerzet wordt deze methode dan ook gebruikt in de praktische

implementatie (zie hoofdstuk 6).

Bij de drie bewegingen die in dit hoofdstuk onderzocht werden, werden de empirisch vast-

gelegde drempelwaarden niet overschreden bij het invoeren van andere bewegingen. Deze

voorwaarde is essentieel om een goede herkenning te kunnen garanderen. Er dient echter

opgemerkt te worden dat bij toevoeging van extra bewegingen deze interferentie steeds

groter zal worden. Men zal dan moeten overgaan naar meer geavanceerde technieken, zo-

5.7. CONCLUSIE 47

als geavanceerde triggering i.p.v. het continu monitoren van de laatste n waarden. Het

algoritme zal dan bv. pas een kost berekenen wanneer bepaalde sensorwaarden zich in

een bepaald gebied bevinden. Hiermee kunnen mogelijk foute detecties alsnog vermeden

worden. Desondanks wordt geconcludeerd dat voor een beperkte set bewegingen de voor-

gestelde methode afdoende is.

48

Hoofdstuk 6

Implementatie

Tot nog toe werd in hoofdstuk 4 een methode voorgesteld om een meer realistische visua-

lisatie van een avatar te bekomen. In hoofdstuk 5 werd dan een techniek geıntroduceerd

die het mogelijk maakt om verschillende bewegingen te extraheren uit de invoerstroom

aan gegevens. In deze paragraaf worden beide technieken klaargemaakt voor de praktijk

door middel van een praktische implementatie. Het resultaat van deze versmelting is de

zogenaamde Motion Sense software.

Figuur 6.1: Plaats van de Motion Sense software in de hierarchie.

6.1 Platform

Het Motion Sense softwarepakket werd ontwikkeld in Microsoft Visual Studio 2008 en

C#.NET [18]. Omdat het .NET framework standaard geen OpenGL functionaliteit on-

dersteunt, werd gebruik gemaakt van het Tao framework [19]. Het Tao Framework is een

C# bibliotheek dat .NET ontwikkelaars toegang geeft tot populaire graphics en gaming

bibliotheken zoals OpenGL en SDL. In deze masterproef werd gebruik gemaakt van de

laatste versie, zijnde 2.1.

6.2. DATASTROOM 49

Daar het .NET framework standaard geen OpenGL ondersteunt lijkt dit platform op het

eerste zicht dan ook een vreemde keuze. Een aantal redenen liggen aan de basis voor deze

beslissing:

• Goede kennis van C# aanwezig bij de auteurs.

• Uitgebreide set aan bibliotheken aanwezig in het .NET platform.

• Snellere ontwikkeltijd dan native C++.

6.2 Datastroom

De opbouw van de Motion Sense software is geıllustreerd in figuur 6.2. In wat volgt wordt

elk deel van dit datastroomschema kort toegelicht.

UDPClient

UDPPacketparser

Visualization

DTWGesturetemplates

In-gameaction recognition

Ringbuffer

Constraintsalgorithm

Low-passfiltering

Figuur 6.2: Overzicht van de Motion Sense software.

HOOFDSTUK 6. IMPLEMENTATIE 50

6.2.1 UDP

Het UDP-gedeelte beslaat de udpclient en de packet parser. De UDP-client zal de UDP-

pakketten ontvangen die afkomstig zijn van de receivermodule die de data doorstuurt van N

sensoren. Deze pakketten hebben een vorm zoals in tabel 6.1. Hierbij is n het volgnummer

van een sensor en zijn t, x, y en z de 4 componenten van het quaternion [20].

Tabel 6.1: Het formaat van een UDP-pakket.

byte nr data

0 pakketnummer

1+10n nodenummer

2+10n t byte high

3+10n t byte low

4+10n x byte high

5+10n x byte low

6+10n y byte high

7+10n y byte low

8+10n z byte high

9+10n z byte low

10+10n dummybyte

Er wordt opgemerkt dat er een dummy byte aanwezig is per sensornode. Deze dummy-

byte is aanwezig vanwege compatibiliteitsredenen met verschillende softwareversies van de

sensormodules. Sommige versies sturen 3 accelerometerwaarden van 1 byte en 3 mag-

netometerwaarden van 2 bytes. Andere sturen dan weer rechtstreeks de quaternionen.

Omdat de eerste versie 9 bytes per node in beslag neemt en de tweede slechts 8, werd een

dummybyte geıntroduceerd om de compatibiliteit te vrijwaren.

De extractie van de Euler hoeken uit deze gegevens gebeurt door de packetparser. De pac-

ketparser zal in eerste instantie de verschillende bytes van de 4 quaternionen samenvoegen

volgens

t = −((th&80H) >> 6) + (th&7FH)/(1 << 6) + tl/(1 << 14). (6.1)

Het eerste bit is dan een tekenbit en bepaalt een offset van -2 of 0. De overige twee termen

zijn dan de omrekening naar de effectieve waarde, waarbij het bereik van de componenten

van het quaternion naar [-2,2[ gebracht werd.Dit is bewust zo gekozen om overflow te

6.2. DATASTROOM 51

vermijden. De omrekening van quaternionen naar Euler hoeken gebeurt volgens [21]: ψ

θ

φ

=

Bgtan2(2(tx+ yz), 1− 2(x2 + y2))

Bgsin(2(ty − zx))

Bgtan2(2(tz + xy), 1− 2(y2 + z2))

. (6.2)

6.2.2 Ringbuffer

Bij de werking van het DTW-algoritme in hoofdstuk 5 is uiteengezet hoe twee sequen-

ties met elkaar op gelijkenis kunnen worden getest. Hierbij wordt verondersteld dat beide

sequenties een bepaalde beweging bevatten en bijgevolg een eindig aantal elementen bezit-

ten. De invoer is in de praktijk echter een constante stroom aan gegevens afkomstig van

de verschillende sensormodules. Deze stroom zal op een bepaalde manier gesegmenteerd

moeten worden als men deze wil aanwenden voor gebruik in het DTW-algoritme.

Omdat een boksbeweging slechts een eindige duur omvat, moet niet de hele stroom aan ge-

gevens gebruikt worden in het DTW-algoritme. Dit is bovendien ook praktisch onmogelijk.

Daarom zal gebruik worden gemaakt van een ringbuffer [22]. In een ringbuffer wordt op

circulaire wijze data toegevoegd. Een n-elementen ringbuffer houdt dus steeds de laatste

n waarden van de stroom bij. Alle uitgevoerde bewegingen duren maximaal een vijftal

seconden. Snellere uitgevoerde bewegingen duren aanzienlijk korter. Daarom wordt een

ringbuffer gebruikt die data van vijf seconden kan bevatten. Dit resulteert in een buffer van

n = 500 elementen indien men rekening houdt met een bemonsteringsperiode van 10ms.

Figuur 6.3: De ringbuffer.

In deze toepassing wordt gebruik gemaakt van maximaal 10 sensormodules. Hiervan

zijn er 4 voor de benen, 4 voor de armen en 1 voor zowel upper als lower torso. Bijgevolg

is de ringbuffer in de praktijk een array van 10 enkelvoudige ringbuffers. Elk element van

HOOFDSTUK 6. IMPLEMENTATIE 52

de ringbuffer bevat dan de φ, θ en ψ component van de Euler hoeken overeenkomstig met

de desbetreffende sensor.

6.2.3 DTW

Het DTW gedeelte beslaat de implementatie van het Dynamic Time Warping algoritme.

De templates van de verschillende bewegingen worden bijgehouden en periodisch vergeleken

met de inhoud van de ringbuffer. De kost die berekend werd, wordt gevisualiseerd in een

grafiek en afhankelijk van de waarde van de kost wordt een beslissing genomen. Onder de

drempelwaarde spreekt men van een gedetecteerde beweging en deze informatie kan dan

aangewend worden voor acties in een virtuele spelomgeving.

De verschillende berekeningen die aan bod komen bij het bepalen van de kost werden zoveel

mogelijk geparallelliseerd. Voor elke sensornode wordt een aparte thread aangemaakt.

Deze threads worden in een wachtrij gezet en serieel uitgevoerd wanneer mogelijk [23]. De

resultaten worden bij afloop bijgehouden.

DTW Sensor A

DTW Sensor B

DTW Sensor CRequests queue

Thread pool

Thread 1

Thread 2

Figuur 6.4: Threadpool werking voor het DTW algoritme.

6.2.4 Constraints algorithm

De avatar wordt opgebouwd uit meerdere bones. Wanneer het skelet een nieuwe dataset

onder de vorm van Euler hoeken toe krijgt, zal het deze verdelen en naar de overeenstem-

mende bones sturen. Deze bones berekenen vervolgens eerst en vooral hun constraints.

Dat gebeurt door ze te roteren met de rotatiematrix van hun parent. Daarna wordt hun

positie volgens de inkomende Euler hoeken berekend en geevalueerd of de bone al dan

6.3. GRAFISCHE INTERFACE 53

niet moet gecorrigeerd worden. Indien dat het geval is, zal correctie plaats vinden op de

manier uitgelegd in hoofdstuk 4. Van deze correcte positie wordt de overeenstemmende

rotatiematrix berekend.

SkeletonSettings

Bone LUL Bone RLA Bone H...

Eulerhoeken

Figuur 6.5: Het constraints algoritme.

6.3 Grafische interface

Wanneer de Motion Sense software opgestart wordt, wordt het venster afgebeeld in figuur

6.6 weergegeven. Dit hoofdvenster biedt toegang tot de verschillende mogelijkheden van

de Motion Sense software.

In dit venster zijn bovenaan 3 grafieken te zien. Deze grafieken representeren de kost

in functie van de tijd voor elke beweging. De groene lijn is de drempelwaarde voor elke

beweging. Onderaan zijn twee avatars te zien. De linker avatar is een ongecorrigeerde

versie met gevisualiseerde vlakken en assen die van toepassing zijn voor de constraints.

Rechts bevindt zich dan de gecorrigeerde, gefilterde versie. De gecorrigeerde ledematen

zijn hierbij groen gekleurd. Door deze simultane weergave is de invloed van de constraints

op een intuıtieve manier aan te voelen. Tenslotte bevinden zich helemaal bovenaan een

aantal menu’s met een aantal nuttige opties welke in volgende paragrafen kort zullen worden

toegelicht.

HOOFDSTUK 6. IMPLEMENTATIE 54

Figuur 6.6: De Motion Sense GUI.

6.3.1 Consolevenster

Het consolevenster geeft allerlei technische statusinformatie weer. Dit kan handig zijn voor

foutdiagnose. Een voorbeeld van een consolevenster is te bekijken in figuur 6.7. In de

console worden gebeurtenissen over o.a. de visualisatie en de herkenning getoond.

6.3.2 Sensoren

Het sensorvenster laat toe de verschillende sensormodules te verbinden met de juiste le-

dematen. Zo kunnen de sensormodules overal op het lichaam worden aangebracht en kan

via dit venster de juiste toewijzing gebeuren met de ledematen van de avatar. Het sen-

sorvenster is te bekijken in figuur 6.8(a). Ook een mogelijkheid om de sensorwaarden te

visualiseren is voorzien. Een voorbeeld hiervan is te zien in figuur 6.8(b).

6.3. GRAFISCHE INTERFACE 55

Figuur 6.7: Het consolevenster.

6.3.3 Recording

Via het sensorsmenu kan men ook de optie record aanspreken. Zoals de naam doet ver-

moeden kan hiermee een bepaalde sequentie worden opgeslagen.

6.3.4 Constraints

Bij het corrigeren van de bones wordt rekening gehouden met settings van het programma

zoals de tolerantiehoek en de elasticiteitsfactor. Bovendien bestaat de mogelijkheid erin

om de constraints aan te passen in run-time. Zowel voor MPB als SPB kunnen de gegevens

over de constraints opgevraagd, aangepast en opgeslagen worden.

Ook bestaat de mogelijkheid erin om constraints grafisch weer te geven. Voor elk bone

apart kan bepaald worden of zijn as (SPB) of vlakken (MPB) weergegeven dienen te worden

(zoals te zien is op figuur 6.6. De verschillende opties zijn toegankelijk via de vensters zoals

getoond in figuur 6.10.

HOOFDSTUK 6. IMPLEMENTATIE 56

(a) De sensortoewijzing. (b) De sensorwaarden.

Figuur 6.8: De sensoropties.

Figuur 6.9: Opnemen van een bepaalde sequentie.

6.3. GRAFISCHE INTERFACE 57

(a) Visualiseren van de constraints. (b) Aanpassen van de toleran-

ties.

Figuur 6.10: De constraintopties.

58

Hoofdstuk 7

Resultaten

Bij het uittesten van het geheel is duidelijk geworden dat de toegepaste methodes hun doel

niet missen. Zowel correctie als detectie gebeurt grotendeels volgens plan. Bij het evalueren

van de software in zijn geheel is echter wel duidelijk geworden dat er nog werkpunten zijn.

In dit hoofdstuk worden zowel de resultaten en de resterende problemen besproken.

7.1 Motion constraints

Na het toepassen van constraints wordt meestal een realistische avatar bekomen. Ook

de vertraging veroorzaak door het IIR filter is bijna niet op te merken. Figuur 7.1 geeft

twee avatars weer: de eerste (linkse) zonder constraints, de tweede (rechts) met. Om

overzichtelijkheid te bewaren zijn enkel de constraints voor SPBs getekend. Uit de figuren

blijkt dat de correctie duidelijk werkt zoals verwacht.

Wat niet duidelijk is uit de figuren, en wat ook niet evident is om vast te leggen in dergelijke

figuren, zijn de nog aanwezige fouten. Volgende paragrafen zullen deze fouten bespreken

en een mogelijke oplossing voorstellen.

7.1. MOTION CONSTRAINTS 59

(a) De onderbenen. (b) De rechter onderarm.

(c) De linker onderarm. (d) De linker bovenarm.

Figuur 7.1: Constraints algoritme in werking.

HOOFDSTUK 7. RESULTATEN 60

7.1.1 MPB sprongen

Bij het corrigeren van de MPB bones kan het voorvallen dat een bone plots van posi-

tie verandert. Dit komt omdat hij geprojecteerd wordt op het dichtsbijzijnde grensvlak.

Wanneer de bone zich rond de bissectrice van de hoek ingesloten tussen twee van deze

vlakken bevindt, kan het gebeuren dat bij een kleine verandering van positie van het un-

constrained bone, het constrained bone springt van het ene vlak naar het andere. Figuur

7.2 verduidelijkt dit.

Een mogelijke oplossing kan zijn door bijvoorbeeld te onthouden op welk vlak geprojecteerd

wordt, en op dit vlak te blijven projecteren. Pas wanneer de bone vrij dicht bij een ander

vlak komt, kan het hierop geprojecteerd worden. Op deze manier zullen sprongen nog

steeds voorkomen, maar ze zullen minder frequent en minder groot zijn.

Een andere manier is om de grensvlakken aan te passen. In de huidige configuratie vormen

deze een piramide. Door deze piramide te vervangen door een kegel, kunnen enkel nog

snelle bewegingen van de projectie voorkomen wanneer de bone zich rond het centrum van

de kegel bevindt. Sprongen zijn op deze manier wel volledig uitgesloten.

Figuur 7.2: Sprong van MPB.

7.1.2 SPB sprongen

Net zoals bij MPB, kunnen ook bij SPB sprongen voorkomen. Waarom dit voorkomt wordt

uitgelegd aan de hand van een voorbeeld met de linker onderarm.

Wanneer de LLA ”overstrekt” is, zal de hoek die het gecorrigeerde bone maakt met zijn

parent steeds vastgelegd worden op 0◦ of 180◦, afhankelijk van hoeveel hij overstrekt is.

Wanneer de hoek tussen de LLA en LUA minder dan 90◦ bedraagt, zal de gecorrigeerde

bone terugplooien op zijn parent, zijnde de LUA. Wanneer de hoek groter is dan 90◦,

wordt deze hoek 180◦. Het lijkt alsof de arm helemaal gestrekt is. Ook hier kan een kleine

beweging van de onderarm een grote sprong van zijn gecorrigeerde versie teweegbrengen.

7.2. BEWEGINGSHERKENNING 61

Dit is het geval wanneer de onderarm en de bovenarm een hoek van 90◦ maken in een

overstrekte positie.

Er zijn enkele mogelijke oplossingen voor deze problemen.

• Bij normale bewegingen zal de overstrekking nooit 90◦ naderen en stelt er zich dus

geen probleem. Het is pas wanneer er snelle bewegingen gemaakt worden dat de

Euler hoeken dusdanig foutief zijn, dat de orientatie sterk kan afwijken en deze 90◦

naderen. Om deze snelle bewegingen te onderdrukken kan het laagdoorlaatfilter fijn

geregeld worden. Dit is echter een delicate zaak aangezien de vertraging niet te

hoog mag oplopen. Nog kritischer is het feit dat snelle bewegingen gemaakt door

de persoon zelf nog steeds moeten kunnen weergegeven worden. Het is duidelijk dat

het fijnregelen van dit filter een waar huzarenstukje is en enkel kan bekomen worden

door trial and error.

• Een tweede manier om dit probleem op te lossen is de orientatie van de eerste correctie

te onthouden en deze aan te houden zolang het bone een onmogelijke positie blijft

aannemen.

7.2 Bewegingsherkenning

De bewegingsherkenning blijkt effectief. Verschill ende bewegingen worden juist gedetec-

teerd en zonder interferentie naar andere bewegingen toe. De orientatie afhankelijkheid

werd succesvol weggewerkt en geımplementeerd in de software. Hoewel deze afhankelijkheid

in de praktijk werkt, blijkt uit metingen dat kleine variaties op de referentiesensormodule

een grote impact hebben op de kost. De kost wordt hierbij wel louter voorzien van een

offset zodat de detectie alsnog mogelijk blijft. Alleen zal de drempelwaarde echter dyna-

misch moeten opschuiven om voor dit effect te compenseren. Dit effect werd nog niet in

rekening gebracht in de praktische implementatie.

De rekentijd van het DTW algoritme bleef beperkt. Verschillende simulaties tonen aan dat

er nog meerdere bewegingen kunnen worden toegevoegd. Door het parallelle karakter van

de code is de toepassing ook uitermate geschikt voor hedendaagse processoren.

HOOFDSTUK 7. RESULTATEN 62

Tabel 7.1: Rekentijd op een Core i7 860 (2,80Ghz) met 4GB RAM.

Beweging Gemiddelde DTW rekentijd

Boksen 111,06ms

Wuiven 61,06ms

Schoppen 108,66ms

7.3 Software

De functionaliteit van de software reikt tot waar nodig. Er kan gesteld worden dat ze voor

dit doel meer dan geschikt is. Er is, daar waar mogelijk, gebruik gemaakt van generische

klassen en algoritmen zodat niet vanaf nul moet begonnen worden om ze uit te breiden

naar meerdere sensoren.

63

Hoofdstuk 8

Besluit

Na afloop van deze masterproef is de opgave vervuld: er is voorzien in zowel een correc-

tiemethode als patroonherkenning. Er is echter nog toekomstperspectief, de mogelijkheid

bestaat erin op dit werk verder te bouwen naar meer geavanceerde technieken.

8.1 Voltooid werk

Zoals reeds vermeld zijn de doelstellingen behaald. Door toepassing van constraints wordt

een realistische avatar gegenereerd. Na enkele correctiemethodes geevalueerd te hebben is

een besluit gemaakt: de visueel meest voldoening gevende methode wordt gebruikt. De

methode bestond erin de data te filteren aan de hand van een IIR filter en ze vervolgens

onder te verdelen in 4 types: free, fixed, single plane constraint en multiple plain constraint.

Afhankelijk van het type, worden constraints op een andere manier gecorrigeerd.

Bij de free bones zijn er geen constraints toegepast. De fixed bones daarentegen zijn dan

weer volledig afhankelijk van hun parentbone. Bij single constraint plane bones wordt de

positie van de parentbone bekeken en op basis daarvan bepaald in welk vlak hij mag ge-

tekend worden. Bij multiple constraint plane bones zijn ruimtehoeken gedefinieerd waarin

de bone niet mag getekend worden. Wanneer correctie nodig is, zal een bone geprojecteerd

worden op het dichtstbijzijnde randgebied tussen de toegelaten en verboden zone.

Omwille van de fysieke locatie van de sensor op de bones en de elasticiteit van kledij en

huid en dergelijke, zal er steeds een fout aanwezig zijn in de sensorwaarden. Door enige

tolerantie op de positie van de bones te implementeren, is ook dit probleem van de baan

geruimd. Dit wordt bekomen door van het enkele vlak waarin een SPB mag bewegen

uit te breiden naar een vlakkenwaaier. Bij een MPB wordt er dan weer toegelaten om de

HOOFDSTUK 8. BESLUIT 64

bones in het verboden gebied te tekenen. Bovendien bestaat de mogelijkheid erin het skelet

eenvoudig uit te breiden met meerdere bones. Na tests is het echter duidelijk geworden

dat er nog ruimte is voor verbetering. Zo treden nog steeds sprongen van gecorrigeerde

bones op in bepaalde situaties.

Ook het herkennen van bepaalde bewegingen zoals schoppen, is gelukt. Door gebruik te

maken van dynamic time warping (DTW), worden patronen op elkaar gematched met

een bepaalde kost. Van zodra deze kost onder een bepaalde drempelwaarde zakt, wordt er

gesproken van een detectie. De geımplementeerde bewegingen dusver zijn wuiven, schoppen

en boksen. Uitbreiding naar andere bewegingen is vrij voor de hand liggend (zie sectie

8.2.2.1).

8.2 Toekomstige mogelijkheden

Op de reeds behaalde algoritmes kan verder gewerkt worden om zo geavanceerdere toepas-

singen te ontwerpen. Enkele mogelijke opties worden gegeven.

8.2.1 Verfijnen correctiemethodes

Zoals aangehaald in secties 7.1.1 en 7.1.2, is het correctiealgoritme nog niet op punt ge-

steld. De aangehaalde methodes om het algoritme te verbeteren kunnen in de toekomst

geımplementeerd worden. Om sprongen te voorkomen kan bijvoorbeeld gebruik gemaakt

worden van een kegel in plaats van een piramide bij MPB. Op die manier worden sprongen

onmogelijk. Ook bij SPB is het mogelijk de correctiemethode te verfijnen om sprongen te

vermijden. Zo kan onthouden worden in welke positie een SPB zich het eerst bevind na

correctie, en deze positie aangehouden worden tot geen correctie meer nodig is.

8.2.2 Uitbreiden DTW algoritme

Een ander mogelijk werk voor de toekomst is de uitbreiding van het DTW algoritme. Dit

door zowel het aantal herkenbare bewegingen te vermeerderen als door het adaptief maken

ervan.

8.2.2.1 Toevoegen herkenbare bewegingen

Vooraleerst kan het mogelijk gemaakt worden om extra bewegingen zoals bijvoorbeeld

springen, wandelen, ontwijken en blokkeren van slagen te herkennen. Meerdere bewegingen

8.2. TOEKOMSTIGE MOGELIJKHEDEN 65

kunnen geımplementeerd worden analoog aan de reeds voltooide bewegingen. Een nadeel

dat de kop op steekt wanneer het aantal te detecteren bewegingen vermeerderd, is het risico

op interferentie van de bewegingen. Om dit te omzeilen dient de drempelwaarde van de

kost dus nauwgezet in de gaten gehouden te worden en eventueel zelfs real-time aangepast

worden. Ook een adaptief algoritme (zie sectie 8.2.2.2) kan reeds een groot deel van de

oplossing zijn om deze interferentie te voorkomen.

8.2.2.2 Adaptief algoritme

Een tweede uitbreiding op het reeds bestaande herkenningsalgoritme is het adaptief maken

ervan. Een adaptief algoritme zal bij elke detectie de doorlopen sequentie incorporeren in

het gebruikte sjabloon. Hierdoor zal telkens een bepaalde beweging gedetecteerd wordt,

de referentiebeweging aangepast worden. Dit heeft als voordeel dat het initieel gebruikte

referentiepatroon geen dramatische invloed meer heeft op de resultaten van de detectie.

Bovendien zal iedere speler zijn eigen versie van bijvoorbeeld schoppen hebben, die lichtjes

verschilt van de referentiebweging. Met een adaptief algoritme kan de referentiebeweging

aangepast worden aan de speler om een betere detectie te bekomen.

Een mogelijke manier om tot een adaptief algoritme te komen is het uitmiddelen van

patronen. Zo kunnen beide patronen (het referentiepatroon en de uitgevoerde beweging)

gematched worden op elkaar en vervolgens een gewogen gemiddelde genomen worden. Tot

nu toe was er bij deze matching steeds 1 constant. De andere sequentie werd steeds

vervormt tot een minimale kost bekomen werd. Bij een adaptief algoritme kan de matching

van de twee sequentie kan nu gebeuren door beide patronen naar elkaar toe te vervormen

met de laagste kost vooraleer ze uit te middelen.

8.2.2.3 Avatar aanpassen in functie van bewegingen

Nog een mogelijkheid bestaat erin om de avatar te laten bewegen in functie van de detecties.

Dit is reeds aangehaald in sectie 3.2. Zo kan wanneer een sprong gedetecteerd wordt, de

root omhoog en omlaag verplaatst worden, of bij detectie van stappen en lopen, de root

vooruit verplaatst worden. Bij deze laatste is het uit overduidelijke redenen ook mogelijk

om een zekere beweging te herkennen als lopen of stappen, en hier naar te handelen. De

speler moet zich daarom niet effectief verplaatsen, maar kan een afgesproken beweging

uitvoeren die dan geınterpreteerd wordt als wandelen.

i

Bibliografie

[1] D. Voth. Evolutions in Gaming. IEEE Pervasive Computing, 6(2):7–10, Apr-Jun

2007.

[2] T. Cantrell. Thanks for the MEMS. Circuit Cellar, (208):80–1, 83–5, November 2007.

[3] Shih-Pin Chao, Yi-Yao Chen, and Wu-Chou Chen. The Cost-Effective Method to De-

velop a Real-Time Motion Capture System. In 2009 Fourth International Conference

on Computer Sciences and Convergence Information Technology, pages 494–8, 2009

2009.

[4] Nintendo. The wii console. http://www.nintendo.com,.

[5] B. Kuyken, W. Verstichel, F. Bossuyt, J. Vanfleteren, M. Demey, and M. Leman. The

HOP Sensor : Wireless Motion Sensor, pages 229–231. Casa Paganini, 2008.

[6] Vanfleteren J. Doutreloigne J. Huyghe, B. SAS 2009 - IEEE Sensor Applications

Symposium, Proceedings, pages 1963–6. IEEE, 2009.

[7] Chiang Tay and R. Green. Human Motion Capture and Representation 3D-avatar

Interaction. In D. Bailey, editor, Proceedings of the 2009 24th International Conference

Image and Vision Computing New Zealand (IVCNZ 2009), pages 209–14, 2009.

[8] Karabi Biswas, Siddhartha Sen, and Pranab Kumar Dutta. MEMS Capacitive Acce-

lerometers. Sensor Letters, 5(3-4):471–484, Sep-Dec 2007.

[9] Huiyu Zhou and Huosheng Hu. Reducing Drifts in the Inertial Measurements of

Wrist and Elbow positions. IEEE Transactions on Instrumentation and Measurement,

59(3):575–85, March 2010.

[10] Doutreloigne J. Huyghe, B. and J. Vanfleteren. 3D Orientation Tracking Based on

Unscented Kalman Filtering of Accelerometer and Magnetometer Data, 2009.

BIBLIOGRAFIE ii

[11] Gregory G. Slabaugh. Computing euler angles from a rotation matrix. http://

gregslabaugh.name/publications/euler.pdf.

[12] Eric R. Bachmann Robert B. McGhee and Michael J. Zyda. Rigid body dynamics,

inertial reference frames and graphics coordinate systems: A resolution of conflicting

conventions and terminology, 2000.

[13] Opengl transformations faq. http://www.opengl.org/resources/faq/technical/

transformations.htm,.

[14] Opengl viewing faq. http://www.opengl.org/resources/faq/technical/viewing.

htm,.

[15] Monson H. Hayes. Theory and Problems of Digital Signal Processing, chapter 9.

McGraw-Hill, 1999.

[16] An-Najah National University. Convolution, fir systems and iir systems.

[17] Xun Lin, Yong Zhou, and Yuan Xue. A Research on the Sequential Pattern Simila-

rity of Time Series. In Zhou, QH, editor, 2009 international forum on information

technology and applications, vol. 2, proceedings, pages 247–250, 2009.

[18] A. Troelsen. Pro c# 2008 and the .net 3.5 platform.

[19] Het Tao-framework. http://taoframework.com/.

[20] Jack B. Kuipers. Quaternions and rotation sequences. http://www.emis.ams.org/

proceedings/Varna/vol1/GEOM09.pdf.

[21] Conversion between quaternions and euler angles. http://en.wikipedia.org/wiki/

Conversion_between_quaternions_and_Euler_angles.

[22] De ringbuffer. http://en.wikipedia.org/wiki/Circular_buffer,.

[23] Thread pool pattern. http://msdn.microsoft.com/en-us/library/system.

threading.threadpool.aspx.

iii

Lijst van figuren

1.1 De sensormodules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Een sensormodule aangebracht op de arm. . . . . . . . . . . . . . . . . . . 3

2.1 Het probleem van positiedrift. . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Ambiguiteit zonder magnetometer. . . . . . . . . . . . . . . . . . . . . . . 8

4.1 Gebruikte assenstelsels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2 Startpositie sensor, hoeken (0, 0, 0). . . . . . . . . . . . . . . . . . . . . . . 16

4.3 Transfertkarakteristiek moving average filter en frequentie-inhoud data. . . 18

4.4 Het IIR filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.5 Vergelijking gecorrigeerd en ongecorrigeerd skelet. . . . . . . . . . . . . . . 20

4.6 Visualisatie single en multiple constraints. . . . . . . . . . . . . . . . . . . 21

4.7 SPB correcties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.8 Illustraties bij correctiemethode MPB. . . . . . . . . . . . . . . . . . . . . 25

4.9 Tolerantie bij SPB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.10 Tolerantie bij MPB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.1 DTW algoritme bij 2 voorbeeldsequenties. . . . . . . . . . . . . . . . . . . 29

5.2 De rechtshandige boksbeweging. . . . . . . . . . . . . . . . . . . . . . . . . 32

5.3 De rechtshandige boksbeweging in het frequentiedomein. . . . . . . . . . . 33

5.4 Testsequentie van opeenvolgende boksbewegingen. . . . . . . . . . . . . . . 34

5.5 De kost i.f.v. de tijd bij de boksbeweging. . . . . . . . . . . . . . . . . . . 35

5.6 De rechtshandige wuifbeweging. . . . . . . . . . . . . . . . . . . . . . . . . 36

5.7 De rechtshandige wuifbeweging in het frequentiedomein. . . . . . . . . . . 36

5.8 Testsequentie van drie wuifbewegingen. . . . . . . . . . . . . . . . . . . . . 37

5.9 De kost i.f.v. de tijd bij de wuifbeweging. . . . . . . . . . . . . . . . . . . . 38

5.10 De rechtsvoetige schopbeweging. . . . . . . . . . . . . . . . . . . . . . . . . 39

5.11 De rechtsvoetige schopbeweging in het frequentiedomein. . . . . . . . . . . 40

LIJST VAN FIGUREN iv

5.12 Testsequentie van opeenvolgende boksbewegingen. . . . . . . . . . . . . . . 41

5.13 De kost i.f.v. de tijd bij de schopbeweging. . . . . . . . . . . . . . . . . . . 42

5.14 Wuif-boks kost i.f.v. de tijd. . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.15 Boks-wuif kost i.f.v. de tijd. . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.16 Worst-case boks-wuif kost i.f.v. de tijd. . . . . . . . . . . . . . . . . . . . . 44

5.17 Avatar in verschillende orientaties. . . . . . . . . . . . . . . . . . . . . . . 45

6.1 Plaats van de Motion Sense software in de hierarchie. . . . . . . . . . . . . 48

6.2 Overzicht van de Motion Sense software. . . . . . . . . . . . . . . . . . . . 49

6.3 De ringbuffer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.4 Threadpool werking voor het DTW algoritme. . . . . . . . . . . . . . . . . 52

6.5 Het constraints algoritme. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.6 De Motion Sense GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.7 Het consolevenster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.8 De sensoropties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.9 Opnemen van een bepaalde sequentie. . . . . . . . . . . . . . . . . . . . . . 56

6.10 De constraintopties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7.1 Constraints algoritme in werking. . . . . . . . . . . . . . . . . . . . . . . . 59

7.2 Sprong van MPB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60