Bewegingsherkenning en -adaptatie geschikt voor 3D-visualisaties met behulp van wearable MEMS sensoren

Bewegingsherkenning en -adaptatie geschikt voor 3D-visualisaties met behulp van wearable MEMS sensoren Wim Mistiaen, Sander Van Schoote

Promotoren: prof. dr. ir. Rik Van de Walle, prof. dr. ir. Jan Vanfleteren Begeleider: Charles Hollemeersch Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: elektrotechniek

Vakgroep Elektronica en informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen Academiejaar 2009-2010

Bewegingsherkenning en -adaptatie geschikt voor 3D-visualisaties met behulp van wearable MEMS sensoren Wim Mistiaen, Sander Van Schoote

Promotoren: prof. dr. ir. Rik Van de Walle, prof. dr. ir. Jan Vanfleteren Begeleider: Charles Hollemeersch Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: elektrotechniek

Vakgroep Elektronica en informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen Academiejaar 2009-2010

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. CharlesFrederik 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 kritische 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 kopiëren 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 voor 3D-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 ingenieurswetenschappen: 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 oriëntatie 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 for 3D-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 actors are sampled many times per second. This animation data is mapped to a 3D-model so that the model performs the same actions as the actor. Most systems used today are optical systems. Data captured from image sensors is used to triangulate the 3D-position of a subject between two or more cameras calibrated to provide overlapping projections. While this technique works well for big movie productions, small movie productions and video games cannot benefit due to constraints in operating space and high cost. Recent developments in the domain of MEMS allow to apply accelerometers for 3D-motion capturing. Albeit this technique has promising prospects, it still has problems to be solved. This abstract will explain the implementation of a software renderer capable of visualizing full-body accelerometer data onto a human skeleton form. To address errors, a number of constraints in body movement is proposed, tested and found to be statisfactory. In addition, certain gestures of the actor can be recognized and used for interactivity between the actor and a virtual world. Keywords—Motion capturing, accelerometer, gesture recognition, Euler angles, Dynamic Time Warping (DTW)

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

I. I NTRODUCTION

III. M OTION CONSTRAINTS

IDEO games these days are played with a variety of controllers. Among these devices we find mice, keyboards, joysticks, gamepads, etc. These traditional controllers dominated the video gaming industry ever since it was created. Recently, there has been a shift towards a more natural input: controllers supplied with accelerometers or cameras supported by complex software algorithms are used to capture the movement of players. Consumers expect to play games in a natural way as they would perform actions in real life. While simple controllers of this ’new generation’ exist, their use is limited and they cannot capture full body movement. The purpose of this thesis was to investigate wether relatively cheap accelerometers [1] attached to the human body could be used for controlling avatars in 3D-video games. While simply integrating the accelerometer data would result in the sensor location, the sensor data contains lots of noise and makes this technique very prone to errors. In addition this technique would require an advanced calibration method. Hence other methods were considered. One such a technique makes use of the accelerometer as a tilt sensor [2]. The accelerometer is accompanied by a magnetometer and assumed to be in a static context. Only gravitational force is exerted upon the sensor and from here the tilt angle with reference to the earths ground plane can be extracted. Using these orientation angles, a skeleton can be constructed from a single root point from where subsequent bones leave into the corresponding directions. This technique is far less prone to errors due to the lack of integration but has the disadvantage that it only covers orientation and no body movement. As movement of the player is rather limited due to restrictions in room space we further disregard this issue.

A straightforward method for solving the acceleration issues, is applying a lowpass filter onto the sensor data. A 2nd order IIR filter was used. Altough representation looks more realistic using this filter, certain gestures remain erroneous. A second measure taking advantage of the limits of the human body was used. To this end, constraints on direction of the individual bones were included. Each bone was assigned a parentbone along with a type. Depending on both the type and the direction of the parent, the position of the childbone was confined to a certain space. To create a realistic visualization of the skeleton, 4 types of bones were used. First of, free bones (lower torso) are bones that don’t have constraints. The bones are drawn in the exact direction defined by the sensordata. Similarly, fixed bones (shoulders and hips) are bones inheriting the direction of their parent, regardless of their own sensordata (if any). Next to the free and fixed bones, there are two types of bones that do need constraining, namely the single plane and multiple plane bones. The single plane bones (lower arms and legs) are bones physically attached to their parent bone by means of a hinge joint. It is clear that, once the orientation of the parentbone has been calculated, the position of the childbone is confined to a plane in space, or more precisely a half-plane. This particular plane contains the parent 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, multiple plane bones (upper legs, upper arms and upper torso), are bones physically attached to their parent bone by means of a ball and socket joint. As for these bones, forbidden areas relative to their parentbone are defined. When a bone enters such a forbidden area according to its sensordata, constraints are applied by means of projection on the nearest border of the area.

V

II. P ROBLEMS While using the accelerometers as tilt sensors, we assumed that the only force exerted upon the accelerometer was gravitational force. While the actor performs certain gestures, the

IV. T OLERANCE It is clear to the reader that a bone relies, amongst other, on its parent’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 to a representation diverging from reality. Measures to minimize this propagation have been taken. For the single plane bones, the axis of the joint is no longer fixed in place, but can rotate up to several degrees towards any direction. For example, when the joint specifies the bone has to be in the XZ-plane, but lies in another plane according to the sensordata, it will be displayed in a plane making a small angle with the XZ plane, closer to the position according to the data. This offset will make up for most of the the errors made by differences between the actual and the measured position. This correction has been visualized in fig. 1(b) Making up for the errors in multiple plane bones has been realized by allowing them to be drawn into the forbidden areas, without complete disregard to these areas though. A bone in such 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 unconstrained bone. An elasticity factor is used to determine how far in a bone should be dragged.

the actor first performed random movements with both arms followed by three subsequent boxing movements. By introducing an appropriate threshold reference, a usefull detection method was obtained. The same simulations were run for actions that

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

contained waving and kicking. The results are similar. Interference between these three gestures was investigated and found to be negligible. It should be noted that with the addition of more gestures this interference will rise significantly and thus should be carefully investigated. VI. I MPLEMENTATION The visualization and recognition routines were implemented in the Motion Sense software. This C#.NET application gives a user the possibility for customizing certain detection and correction parameters, adding gestures, ... In addition the constraints algorithm can be visually checked for correct operation. VII. C ONCLUSION

(a)Single-plane constraint. The angle between the parentbone and the unconstrained bone is clearly less obtuse than its corrected counterpart. When looking parallel to the Y-axis, both bones will seemingly overlap.

(b)Tolerance on single-plain constraint. The rotation axis defined by the hinge-joint coincides with the Y-axis, yet the imaginary axis defined by the unconstrained bone isn’t. The axis of the corrected bone will be rotated towards the sensor-axis.

Fig. 1. SPB correction.

V. M OTION RECOGNITION Another challenge is the interaction of the player with the virtual world. A few examples are: pressing a button, kicking enemies, picking up objects, etc. As all these actions are strict sequences of subsequent sensordata we make use of the dynamic time warping algorithm (DTW). Dynamic time warping is an algorithm for measuring similarity between two sequences which may vary in time or speed. It allows to find an optimal match between two given sequences. The sequences are warped non-linearly in the time dimension to determine a measure of their similarity independent of certain non-linear variations in the time dimension. This similarity is expressed as a cost number. Similarity can be found in two ways: by assuming all sensordata to be synchronous in time and thus using a unique warping path for all sensors, or by warping each sensor independently of the others. Results show the latter being far more accurate, implying decorrelation of sensor signals in time. Reference gestures were recorded and used for comparison against real-time data. Various gestures were applied and an example of this cost output is depicted in fig. 2. In this example

The goal was both to represent the position of the actor in a 3D-environment and detect certain gestures made, while the data available being inaccurate. On fast changes, sensor data remains erroneous, and bones will most likely end up in an impossible position. By partially correcting this position to a more feasible one, a realistic skeleton can still be built up. As soon as the actor assumes a more or less static position, sensor data will be accurate again as equilibrium is restored, and the skeleton will attain a very good representation of the actual position of the actor. The effect caused by skin and clothing introduces errors, but it was proven it can be accounted for. Introducing a certain tolerance, propagation of these errors throughout the skeleton was greatly reduced. Results show that by implementing constraints based on the human physiology, animations captured look sufficiently realistic. Finally the DTW gesture recognition algorithm was found to be a robust and effective way for detection. ACKNOWLEDGMENTS The authors would like to thank Rik Van de Walle for the opportunity to do this research, as well as Charles-Frederik Hollemeersch, and Benoˆıt Huyghe for helping the authors to achieve these results. R EFERENCES [1] Bart Kuyken, Wouter Verstichel, Frederick Bossuyt, Jan Vanfleteren, Michiel Demey, and Marc Leman, “The HOP sensor : wireless motion sensor,” 2008. [2] Benoˆıt Huyghe, Jan Doutreloigne, and Jan Vanfleteren, “3D Orientation tracking based on unscented Kalman filtering of accelerometer and magnetometer data,” 2009.

VI

Inhoudsopgave Dankwoord

I

Toelating tot bruikleen

II

Samenvatting

III

Abstract

IV

Inhoudsopgave

VI

1 Inleiding

1

2 Werkingsprincipes 2.1 Integratie . . . . . . . 2.1.1 Principe . . . . 2.1.2 Tekortkomingen 2.2 Tiltsensor . . . . . . . 2.2.1 Principe . . . . 2.2.2 Tekortkomingen 2.3 Conclusie . . . . . . .

. . . . . . .

4 4 4 4 5 5 9 9

3 Problemen 3.1 Verstoring van statica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Onmogelijkheid tot verplaatsing . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Permanent aanwezige fout . . . . . . . . . . . . . . . . . . . . . . . . . . .

10 10 11 11

4 Avatar animatie 4.1 Van Euler hoeken naar avatar . . 4.1.1 Interpretatie Euler hoeken 4.1.2 Opbouw skelet . . . . . . 4.1.3 OpenGL implementatie . . 4.2 Preprocessing: laagdoorlaat filter

13 13 13 14 15 17

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . .

INHOUDSOPGAVE

4.3

4.4

VII

4.2.1 Eerste poging: moving average . 4.2.2 Tweede poging: . . . . . . . . Correctie . . . . . . . . . . . . . . . . . 4.3.1 Standaardconstraints . . . . . . 4.3.2 Free bone . . . . . . . . . . . . 4.3.3 Fixed bone . . . . . . . . . . . 4.3.4 Single plane constraint bone . . 4.3.5 Multiple plane constraint bone . Tolerantie . . . . . . . . . . . . . . . .

5 Bewegingsherkenning 5.1 Dynamic Time Warping . . . . . . 5.1.1 Werking . . . . . . . . . . . 5.1.2 Afstandsmetriek . . . . . . 5.1.3 DTW in meerdere dimensies 5.2 Boksbeweging . . . . . . . . . . . . 5.2.1 Referentiebeweging . . . . . 5.2.1.1 Tijdsdomein . . . . 5.2.1.2 Frequentiedomein . 5.2.2 Testsequentie . . . . . . . . 5.2.2.1 Tijdsdomein . . . . 5.2.2.2 Boksherkenning . . 5.3 Wuifbeweging . . . . . . . . . . . . 5.3.1 Referentiebeweging . . . . . 5.3.1.1 Tijdsdomein . . . . 5.3.1.2 Frequentiedomein . 5.3.2 Testsequentie . . . . . . . . 5.3.2.1 Tijdsdomein . . . . 5.3.2.2 Wuifherkenning . . 5.4 Schopbeweging . . . . . . . . . . . 5.4.1 Referentiebeweging . . . . . 5.4.1.1 Tijdsdomein . . . . 5.4.1.2 Frequentiedomein . 5.4.2 Testsequentie . . . . . . . . 5.4.2.1 Tijdsdomein . . . . 5.4.2.2 Schopherkenning . 5.5 Interferentie . . . . . . . . . . . . . 5.5.1 Wuif-boks interferentie . . . 5.5.2 Boks-wuif interferentie . . . 5.6 Oriëntatie . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

17 17 18 21 21 22 22 23 25

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27 27 28 29 30 31 31 31 32 33 33 34 35 35 35 35 37 37 37 38 38 38 38 39 39 42 42 43 43 45

INHOUDSOPGAVE 5.7

VIII

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Implementatie 6.1 Platform . . . . . . . . . . . . 6.2 Datastroom . . . . . . . . . . 6.2.1 UDP . . . . . . . . . . 6.2.2 Ringbuffer . . . . . . . 6.2.3 DTW . . . . . . . . . 6.2.4 Constraints algorithm 6.3 Grafische interface . . . . . . 6.3.1 Consolevenster . . . . 6.3.2 Sensoren . . . . . . . . 6.3.3 Recording . . . . . . . 6.3.4 Constraints . . . . . . 7 Resultaten 7.1 Motion constraints . . 7.1.1 MPB sprongen 7.1.2 SPB sprongen . 7.2 Bewegingsherkenning . 7.3 Software . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

46

. . . . . . . . . . .

48 48 49 50 51 52 52 53 54 54 55 55

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

58 58 60 60 61 62

8 Besluit 8.1 Voltooid werk . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Toekomstige mogelijkheden . . . . . . . . . . . . . . . . . . 8.2.1 Verfijnen correctiemethodes . . . . . . . . . . . . . . 8.2.2 Uitbreiden DTW algoritme . . . . . . . . . . . . . . 8.2.2.1 Toevoegen herkenbare bewegingen . . . . . 8.2.2.2 Adaptief algoritme . . . . . . . . . . . . . . 8.2.2.3 Avatar aanpassen in functie van bewegingen

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

63 63 64 64 64 64 65 65

Bibliografie Lijst van figuren

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

i iii

1

Hoofdstuk 1 Inleiding De Wii, Xbox, Playstation, PSP, DS, . . . iedereen kent ze wel, de verschillende gameplatformen. 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 spectaculair 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 aantal pixels is met gemak verhonderdvoudigd, er is een overstap gemaakt van 2D naar 3D, rasterisatie wordt vervangen door veelbelovende raytracing technieken, het kleurenpalet is geëvolueerd van twee bit naar vierenzestig bit, enzovoort. De grafische pracht en praal van het videogame is echter slechts één aspect van het grotere geheel. Een ander aspect beslaat de besturing van de verschillende onderdelen van het spel: de invoer van de gebruiker 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 invoermethodes [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 boksbewegingen 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 oriëntaties 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 sensormodules. Deze modules worden voorzien van MEMS accelerometers en magnetometers. Het zijn lightweight en low cost onderdelen, wat hen uitstekend geschikt maakt voor massaproductie. 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 draadloze 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 sensormodules 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 verschillende versnellingscomponenten waaraan de sensormodule onderhevig is op te meten. Om een computergestuurde avatar te animeren die deze bewegingen volgt zullen deze versnellingen eerst moeten worden omgezet naar een positiebepalend datatype. In wat volgt worden twee manieren besproken die deze omzetting realiseren. Tot slot worden de vooren nadelen van beide technieken besproken.

2.1 2.1.1

Integratie 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 # Z t "Z t ~r(t) = ~rref + ~vref t + ~a(t) dt dt. (2.1) tref

tref

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 werkelijke versnellingscomponent en een ruiscomponent. Dit zorgt ervoor dat vergelijking (2.1)

2.2. TILTSENSOR

5

wordt gewijzigd in Z

"Z

t

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

#

t

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

(2.2)

tref

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 # Z "Z t

t

tref

tref

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

t

"Z

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

t

~r(t) =

~a(t) dt dt + tref

tref

~r(t) = ~rcorrect +

w(t ~ − tref )2 . 2

w(t ~ − tref )2 , 2

(2.3) (2.4) (2.5)

Een constante acceleratiefout resulteert in een positiefout die kwadratisch met het tijdsinterval 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. Bovendien 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 2.2.1

Tiltsensor Principe

Een andere methode bestaat erin om de accelerometer te gebruiken als tiltsensor [9]. Hierbij zal de accelerometer zijn oriëntatie 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 oriëntatie van de tiltsensor.

HOOFDSTUK 2. WERKINGSPRINCIPES

6

(a) Skeletvorm met werkelijke weer- (b) Skeletvorm met verschillende posigave. tiefouten.

Figuur 2.1: Het probleem van positiedrift.

Deze oriëntatie 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 a~tot = ~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 A0 = RA,      r1,1 r1,2 r1,3 x x0    0    y  =  r2,1 r2,2 r2,3   y  . z0 r3,1 r3,2 r3,3 z

(2.6) (2.7)

De negen elementen rij van R moeten nu worden bepaald om zo de coördinatentransformatie volledig vast te leggen en de oriëntatie 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 worden 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)     cos φ − sin φ 0 cos θ 0 sin θ 1 0 0     R =  sin φ cos φ 0  0 (2.9) 1 0  0 cos ψ − sin ψ  , 0 0 1 − sin θ 0 cos θ 0 sin ψ cos ψ   cos θ cos φ sin ψ sin θ cos φ − cos ψ sin φ cos ψ sin θ cos φ + sin ψ sin φ   R =  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 georiënteerd. Ook dit mag zonder de algemeenheid te schenden.     g r1,1 r1,2 r1,3 gx0       gy0  =  r2,1 r2,2 r2,3   0  , 0 r3,1 r3,2 r3,3 gz0 0 gx , r1,1 = cos θ cos φ = g gy0 r2,1 = cos θ sin φ = , g gz0 r3,1 = − sin θ = . g 

(2.10) (2.11) (2.12) (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 xas (ψ) 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 aanwezig op de sensormodule. Deze zal aan de hand van het permanent aanwezig magnetisch veld van de aarde m ~ de oriëntatie van de sensor mee bepalen. Indien verondersteld 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 

    mx0 r1,1 r1,2 r1,3 mx       my0  =  r2,1 r2,2 r2,3   0  , mz0 r3,1 r3,2 r3,3 mz

(2.14)

mx0 = r1,1 mx + r1,3 mz ,

(2.15)

my0 = r2,1 mx + r2,3 mz ,

(2.16)

mz0 = r3,1 mx + r3,3 mz ,

(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 transformatie eenduidig te bepalen. In de praktijk echter, zal de relatieve positie van a~tot 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 geëxtraheerd 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 oriëntatie.

mogelijke

(b) Een andere mogelijke oriëntatie.

Figuur 2.2: Ambigui¨teit zonder magnetometer.

2.3. CONCLUSIE

2.2.2

9

Tekortkomingen

Met deze methode is het niet mogelijk om op elk tijdstip een correcte oriëntatie bepalen. De accelerometer mag naast de valversnelling immers geen noemenswaardige versnelling ondergaan (zie vergelijking (2.11)). Bij het uitvoeren van bepaalde spelacties is dit natuurlijk 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 integratie 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 oriëntatie van de accelerometer berekend wordt, bezit deze een aanzienlijke afwijking tegenover de werkelijke oriëntatie. 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 worden veroorzaakt door de grote versnelling die inwerkt op de sensor. 2. Tijdelijk aannemen van onmogelijke houdingen omwille van een schok op alle sensoren, 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 oriëntatie 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 oriëntatie. 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 oriëntatie 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 oriëntatie van de verschillende 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 definiëren. Eens een beweging gedetecteerd is kan de root hiernaar aangepast worden. Zo kan wanneer bijvoorbeeld een sprong is gedetecteerd, 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 opgebouwd, 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 ongecorrigeerde 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 betrekking 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 definiëren. 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

Upper torso UT Lower torso LT Hip HIP Left upper leg LUL Right upper leg RUL Left lower leg LLL Right lower leg RLL Shoulders SHOULDERS Left upper arm LUA Right upper arm RUA Left lower arm LLA Right lower arm RLA

4.1.3

lengte

parentbone

11 11 11 14 14 15 15 12 12 12 11 11

root root LT HIP HIP LUL RUL UT SHOULDERS SHOULDERS LUA RUA

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 oriëntatie komen bijvoorbeeld de hoeken (0, 0, 0) overeen? Welnu, inherent aan het ontwerp van de sensoren is deze startpositie. Wanneer de ontvangen 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 besloten 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


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 oriënteren 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,     1 0 0 cos θz − sin θz 0 cos θy 0 sin θy     R = 0 cos θx − sin θx   sin θz cos θz 0  0 1 0 . 0 0 1 − sin θy 0 cos θy 0 sin θx cos θx

(4.4) (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. 1

Verder 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

4.2

17

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 + b2 z −1 + b3 z −2 . a1 + a2 z −1 + a3 z −2

(4.6)

De waarden van de filtercoëfficiënten zijn getabelleerd in tabel 4.2. De BIBO stabiliteit 2

De gebruikte data om het frequentiespectrum te bekomen is een boksbeweging. Zoals later zal blijken hebben echter alle bewegingen quasi dezelfde spectrale inhoud.


18

0

−10

A (dB)

−20

−30

−40

−50

−60

Data Filter

−70 0

5

10

15

20

25

30

35

40

45

50

f (Hz)

Figuur 4.3: Transfertkarakteristiek moving average filter en frequentie-inhoud data. Tabel 4.2: Filtercoëfficiënten.

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 onderdrukt, 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 correctie in dergelijke situatie). Hiertoe zijn constraints of beperkingen ingevoerd, ze zorgen

4.3. CORRECTIE

19

1

0

0.8

−5 Imaginary Part

Magnitude (dB)

0.6

−10 −15 −20 −25 −30

0.4 0.2 0 −0.2 −0.4 −0.6

−35

−0.8

−40 0

−1

5

10

15

20 25 30 Frequency (Hz)

35

40

−1

45

−0.5

0

0.5

1

Real Part

(a) Transfertkarakteristiek.

(b) Pole zero plot. Step Response

1

Amplitude

0.8

0.6

0.4

0.2

0

10

20

30

40

50

Samples

(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 georiënteerd 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


(a) ongecorrigeerd.

20

(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. 3

Het 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 persoon. 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 oriëntatie 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


22

kunnen verwachten dat ook UT van dit type is. Dit is echter niet het geval aangezien er nog een beperking is van de oriëntatie 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 correctievlak 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 correctievlak. Aangezien dit vlak reeds gekend is, dient enkel nog de hoek tussen het gecorrigeerde 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

αsens > 90◦

⇒

γcor

sin(αsens ) cos(βas ) = arctan , cos(αsens ) − sin(αsens ) cos(βas ) ◦ = 180 − arctan . cos(αsens )

(4.7) (4.8)

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

(a) Foutieve positie.

(b) Eerste correctiemethode. (c) Tweede thode.

correctieme-

Figuur 4.7: SPB correcties. De hoek tussen sensoren 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.


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 dichtstbij. • 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 oriëntatie 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 verboden zone heeft hier 5 hoekpunten. De grensvlakken zijn transparant violet, de subzones afgebakend door de groene driehoeken.

(b) Ingezoomd op 1 subzone. In de oorsprong komt de parentbone toe en vertrekt het childbone 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 ligging. Hij zal over een zekere hoek α gedraaid zijn naar de scharnieras volgens de sensorwaarden 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 theoretische scharnieras en deze volgens de sensorwaarden, kleiner is dan αmax , zal er geen correctie toegepast worden, en de bone getekend worden volgens zijn sensorwaarden. Indien 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.


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 gecorrigeerde 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 ongecorrigeerd 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 bewegingen 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

5.1.1

28

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 .. . k2,1 .. .

···

kn,1 · · ·

kn,m−1

..

.

 k1,m  ..  . .  kn−1,m  kn,m

(5.1)

Deze matrix wordt als volgt opgebouwd: voor elk element van sref wordt een afstandsmetriek (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. Achtereenvolgens 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 gevonden 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 voorbeeld wordt een referentiepuls (blauw) vergeleken met een ontvangen puls (rood). De ontvangen puls is een artifciële 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

(a) Voorbeeld van 2 sequenties.

29

(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 verschillende 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 afstandsmetriek wordt een andere metriek bekomen voor hoeken die 360◦ groter zijn maar fysiek dezelfde betekenis hebben. Om deze problemen te adresseren wordt de afstandsmetriek 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).


5.1.3

30

DTW in meerdere dimensies

In paragraaf 5.1.1 werd de werking van het DTW algoritme voor scalaire grootheden besproken. 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. n X X

k =

kt,u ,

(5.4)

t=1 u=x,y,z

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 afstandsmetriek is nu de som van de afzonderlijk metrieken. De totale kost wordt gesommeerd over de verschillende sensoren. n X

k =

kt ,

(5.6)

t=1

X

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

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

(5.7)

u=x,y,z

3. Het DTW-algoritme wordt uitgevoerd op de som van de sensorwaarden en afzonderlijk voor elke dimensie. De totale kost wordt gesommeerd over de verschillende dimensies. k =

X

ku ,

(5.8)

u=x,y,z

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

n X

At (i),

t=1

n X

! Bt (j) .

(5.9)

t=1

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, X d(A(i), B(j)) = dang u=x,y,z

(5.10) n X t=1

At,u (i),

n X 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 wegingscoëfficiënt en zijn meer doorslaggevend voor het eindresultaat. Zo kunnen de vergelijkingen horend bij methode 2 algemeen geschreven worden als n P

k=

gt kt

t=1 n P

(5.12) gt

t=1

en

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

u=x,y,z

gu dang (Au (i), Bu (j)) P . gu

(5.13)

u=x,y,z

waarbij gt en gu de wegingscoëffeciënten voorstellen van respectievelijk de sensormodules en de dimensies. Tenzij anders vermeld wordt in wat volgt een eenheidsgewicht aan elk van de coëfficiënten 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


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 boksbewegingen 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.


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 opgeschoven. 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 verschillende boksbewegingen. 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 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 1 2 3

traag traag snel

7,73 12,55 17,33

eind

duur

9,67 1,94s 14,89 2,34s 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 één 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


(a) RUA sequentie

36

(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 noemenswaardige 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.


5.3.2.2

beweging

snelheid

begin

eind

duur

1 2 3

normaal normaal normaal

2,47 3,97 5,93

3,97 5,93 7,62

1,50s 1,96s 1,69s

Wuifherkenning

Analoog aan de boksbeweging wordt er nu onderzocht wat de uitkomst is van het DTWalgoritme 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


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 schopbeweging. Vier sensormodules werden aangebracht in het midden van de boven- en onderbenen van een testspeler. De schopbeweging werd vervolgens rechtsvoetig uitgevoerd en het resultaat 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 achtereenvolgende 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.


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 herkennen. 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.


beweging snelheid begin 1 2 3

traag traag snel

10,16 14,60 18,68

eind

duur

12,23 2,07s 16,96 2,36s 20,15 1,47s

HOOFDSTUK 5. BEWEGINGSHERKENNING 5.4.2.2

42

Schopherkenning

Analoog aan de boksbeweging wordt er nu onderzocht wat de uitkomst is van het DTWalgoritme 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.



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 mogelijk 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

5.5.1

43

Wuif-boks interferentie

In de wuifbeweging wordt gebruik gemaakt van de rechter boven- en onderarm. De boksbeweging 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 drempelwaarde.

(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 achtereenvolgende 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 variëren 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



44


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 aangenomen dat, indien het verschijnsel zich al zou voordoen, deze situatie uiterst zeldzaam zal

¨ 5.6. ORIENTATIE

45

zijn. Eén enkele verkeerde detectie zal op zich dan ook niet tot noemenswaardig verlies aan spelkwaliteit leiden.

5.6

Ori¨ entatie

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 opgenomen 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 georiënteerd staat. De verschillende referentiemodules die bij elke beweging horen vindt men terug in tabel 5.4.

(a) Boksbeweging gericht naar het zuiden.

(b) Boksbeweging gericht naar het noorden.

Figuur 5.17: Avatar in verschillende oriëntaties.


46

Tabel 5.4: Relatieve bewegingen.

5.7

beweging

oriëntatie

kloppen wuiven boksen

upper torso upper torso lower torso

Conclusie

Alle bewegingen kunnen goed worden herkend. In de berekeningen van de kost met verschillende methodes profileert methode 2 zich als de meest performante vanwege het hoger dynamisch 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 rechtshandige 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 omhoog 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 onderen bovenarm zijn zeer sterk gecorreleerd door hun fysieke afhankelijkheid van elkaar. Bijgevolg 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 gelijkaardige 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 vastgelegde 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 voorgestelde methode afdoende is.

48

Hoofdstuk 6 Implementatie Tot nog toe werd in hoofdstuk 4 een methode voorgesteld om een meer realistische visualisatie 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 hiërarchie.

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 ondersteunt, 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

Ringbuffer

Gesture templates

DTW

Low-pass filtering

Constraints algorithm In-game action recognition

Visualization

Figuur 6.2: Overzicht van de Motion Sense software.

HOOFDSTUK 6. IMPLEMENTATIE

6.2.1

50

UDP

Het UDP-gedeelte beslaat de udpclient en de packet parser. De UDP-client zal de UDPpakketten 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 dummybyte is aanwezig vanwege compatibiliteitsredenen met verschillende softwareversies van de sensormodules. Sommige versies sturen 3 accelerometerwaarden van 1 byte en 3 magnetometerwaarden 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 packetparser zal in eerste instantie de verschillende bytes van de 4 quaternionen samenvoegen volgens t = −((th &80H) >> 6) + (th &7F H)/(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 + y 2 ))     Bgsin(2(ty − zx))  θ  =  . 2 2 φ Bgtan2(2(tz + xy), 1 − 2(y + z ))

6.2.2

(6.2)

Ringbuffer

Bij de werking van het DTW-algoritme in hoofdstuk 5 is uiteengezet hoe twee sequenties met elkaar op gelijkenis kunnen worden getest. Hierbij wordt verondersteld dat beide sequenties een bepaalde beweging bevatten en bijgevolg een eindig aantal elementen bezitten. 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 gegevens 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


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

Thread 1

DTW Sensor B

DTW Sensor C Requests queue

Thread 2 Thread pool

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 overeenstemmende 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 geëvalueerd 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. Eulerhoeken

Skeleton

Settings

Bone LUL

Bone RLA

...

Bone H

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.


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 ledematen. 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 sensorvenster 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).


55

Figuur 6.7: Het consolevenster.

6.3.3

Recording

Via het sensorsmenu kan men ook de optie record aanspreken. Zoals de naam doet vermoeden 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.


(a) De sensortoewijzing.

56

(b) De sensorwaarden.

Figuur 6.8: De sensoropties.

Figuur 6.9: Opnemen van een bepaalde sequentie.


(a) Visualiseren van de constraints.

57

(b) Aanpassen van de toleranties.

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

(a) De onderbenen.

(c) De linker onderarm.

59

(b) De rechter onderarm.

(d) De linker bovenarm.

Figuur 7.1: Constraints algoritme in werking.

HOOFDSTUK 7. RESULTATEN

7.1.1

60

MPB sprongen

Bij het corrigeren van de MPB bones kan het voorvallen dat een bone plots van positie 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 unconstrained 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 oriëntatie 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 oriëntatie 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 gedetecteerd en zonder interferentie naar andere bewegingen toe. De oriëntatie 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 dynamisch 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.

7.3

Beweging

Gemiddelde DTW rekentijd

Boksen Wuiven Schoppen

111,06ms 61,06ms 108,66ms

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 correctiemethode 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 geëvalueerd 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 getekend 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 toepassingen 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 gesteld. 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 Develop 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 Accelerometers. 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 Similarity 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 1.2

De sensormodules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Een sensormodule aangebracht op de arm. . . . . . . . . . . . . . . . . . .

3 3

2.1 2.2

Het probleem van positiedrift. . . . . . . . . . . . . . . . . . . . . . . . . . Ambigui¨teit zonder magnetometer. . . . . . . . . . . . . . . . . . . . . . .

6 8

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10

Gebruikte assenstelsels. . . . . . . . . . . . . . . . . . . . . . . . . . . . Startpositie sensor, hoeken (0, 0, 0). . . . . . . . . . . . . . . . . . . . . Transfertkarakteristiek moving average filter en frequentie-inhoud data. Het IIR filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vergelijking gecorrigeerd en ongecorrigeerd skelet. . . . . . . . . . . . . Visualisatie single en multiple constraints. . . . . . . . . . . . . . . . . SPB correcties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Illustraties bij correctiemethode MPB. . . . . . . . . . . . . . . . . . . Tolerantie bij SPB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tolerantie bij MPB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

14 16 18 19 20 21 23 25 26 26

5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11

DTW algoritme bij 2 voorbeeldsequenties. . . . . . . . . De rechtshandige boksbeweging. . . . . . . . . . . . . . . De rechtshandige boksbeweging in het frequentiedomein. Testsequentie van opeenvolgende boksbewegingen. . . . . De kost i.f.v. de tijd bij de boksbeweging. . . . . . . . . De rechtshandige wuifbeweging. . . . . . . . . . . . . . . De rechtshandige wuifbeweging in het frequentiedomein. Testsequentie van drie wuifbewegingen. . . . . . . . . . . De kost i.f.v. de tijd bij de wuifbeweging. . . . . . . . . . De rechtsvoetige schopbeweging. . . . . . . . . . . . . . . De rechtsvoetige schopbeweging in het frequentiedomein.

. . . . . . . . . . .

. . . . . . . . . . .

29 32 33 34 35 36 36 37 38 39 40

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

LIJST VAN FIGUREN

iv

5.12 5.13 5.14 5.15 5.16 5.17

Testsequentie van opeenvolgende boksbewegingen. De kost i.f.v. de tijd bij de schopbeweging. . . . . Wuif-boks kost i.f.v. de tijd. . . . . . . . . . . . . Boks-wuif kost i.f.v. de tijd. . . . . . . . . . . . . Worst-case boks-wuif kost i.f.v. de tijd. . . . . . . Avatar in verschillende oriëntaties. . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

41 42 43 44 44 45

6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10

Plaats van de Motion Sense software in de hiërarchie. Overzicht van de Motion Sense software. . . . . . . . De ringbuffer. . . . . . . . . . . . . . . . . . . . . . . Threadpool werking voor het DTW algoritme. . . . . Het constraints algoritme. . . . . . . . . . . . . . . . De Motion Sense GUI. . . . . . . . . . . . . . . . . . Het consolevenster. . . . . . . . . . . . . . . . . . . . De sensoropties. . . . . . . . . . . . . . . . . . . . . . Opnemen van een bepaalde sequentie. . . . . . . . . . De constraintopties. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

48 49 51 52 53 54 55 56 56 57

7.1 7.2

Constraints algoritme in werking. . . . . . . . . . . . . . . . . . . . . . . . Sprong van MPB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59 60

Bewegingsherkenning en -adaptatie geschikt voor 3D-visualisaties met behulp van wearable MEMS sensoren

Recommend Documents