bewegingsherkenning en -adaptatie geschikt voor 3d...
TRANSCRIPT
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