WS-Gesture: een toestandsbewuste afstandsbediening Kristof Vandermeeren, Rob Vanden Meersche

WS-Gesture: een toestandsbewuste afstandsbediening Kristof Vandermeeren, Rob Vanden Meersche

Promotoren: prof. dr. ir. Filip De Turck, prof. dr. ir. Bart Dhoedt Begeleiders: Gregory Van Seghbroeck, Stijn Verstichel Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen Academiejaar 2009-2010

WS-Gesture: een toestandsbewuste afstandsbediening Kristof Vandermeeren, Rob Vanden Meersche

Promotoren: prof. dr. ir. Filip De Turck, prof. dr. ir. Bart Dhoedt Begeleiders: Gregory Van Seghbroeck, Stijn Verstichel Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen Academiejaar 2009-2010

Voorwoord We zouden graag iedereen bedanken die rechtstreeks of onrechtstreeks heeft bij gedragen tot het maken van deze thesis. Vooraleerst professor De Turck en professor Dhoedt voor het onderwerp en hun interesse erin. Onze begeleiders Gregory en Stijn voor hun postitieve inbreng en voor de vrijheid die ze ons gelaten hebben bij de invulling van ons onderwerp. Bovendien speciale dank aan Gregory om ons te helpen met het zien van het bos door de Web service standaarden. Ook zouden we graag onze ouders bedanken voor hun steun en hulp die ze opgebracht hebben, niet alleen tijdens dit laatste jaar, maar tijdens onze ganse studiecarrière. Voor de kans die we kregen om te studeren en ons te verdiepen in wat ons interesseert. Stijn, Klaas en Wim omdat ze ons voorzien hebben van testdata door (soms tot hun verveling toe) met onze SunSPOT te komen zwaaien en Joris voor het nalezen van het inleidend hoofdstuk. Stijn en Klaas zouden we bovendien graag nog eens specifiek bedanken omdat we de laatste jaren zowat een vast kwartet vormden. Projecten maken of feest vieren, samenvattingen uitwisselen of flipperen op café, zowat alles deden we samen. Onze thesis zou er bovendien ook niet geweest zijn zonder een regelmatige dosis ontspanning. Daarom zouden we ook graag David Lynch en Mark Frost bedanken voor het maken van Twin Peaks, wat al snel een gevestigde waarde werd na een lange werkdag. Ook zonder muziek zou het werken heel wat minder vlot gegaan zijn. Deze thesis werd voornamelijk geschreven op muziek van Michael Jackson, Daft Punk, Santana en The Knife. En de muziek van J´ ohann J´ ohannsson heeft ons met succes door de laatste week gesleurd.

Rob Vanden Meersche Kristof Vandermeeren mei 2010

Toelating tot bruikleen “De auteurs geven de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de masterproef 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 masterproef.” “The authors 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.”

Rob Vanden Meersche Kristof Vandermeeren mei 2010

WS-Gesture: een toestandsbewuste afstandsbediening door Rob VANDEN MEERSCHE en Kristof VANDERMEEREN Scriptie ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Afstudeerrichting: software-engineering Academiejaar 2009–2010 Promotoren: Prof. Dr. Ir. Filip DE TURCK en Prof. Dr. Ir. Bart DHOEDT Scriptiebegeleiders: Gregory VAN SEGHBROECK en Stijn VERSTICHEL Faculteit Toegepaste Wetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. Daniël DE ZUTTER

Samenvatting In dit werk wordt een oplossing gezocht voor de overdaad aan afstandsbedieningen die tegenwoordig in een huis te vinden zijn. Het doel is, aan de hand van een SunSPOT, een universele afstands” bediening” te maken die voor ieder toestel in huis kan gebruikt worden, zonder het te overladen met toetsen. Dit laatste proberen we te bereiken door de toestellen aan te sturen met bewegingen. Ten eerste moet bewegingsherkenning onderzocht worden en waar dit het best uitgevoerd kan worden, op de afstandsbediening, die een beperkte rekenkracht heeft, of op een aparte rekenserver. Vervolgens moet het ook mogelijk zijn toestellen dynamisch in het netwerk te plaatsen, te ontdekken en aan te sturen. Dit proberen we te bereiken met de Web service standaarden die voor dit doel ontwikkeld zijn. Een bijkomend probleem hierbij is echter dat niet ieder toestel dezelfde communicatietechnologie gebruikt. Zo zullen bijvoorbeeld sommige toestellen communiceren via Bluetooth en anderen via Ethernet. Er moet dus een brug geslagen worden tussen de verschillende technologieën. Een derde aspect is rekening houden met het feit dat een beweging afhankelijk kan zijn van de toestand waarin een toestel zich bevindt. Uiteindelijk moeten de bekomen resultaten uitvoerig getest worden om te zien of ze accuraat, in het geval van bewegingsherkenning, en snel genoeg zijn teneinde de eindgebruiker een aanvaardbare real-time ervaring te bieden.

Trefwoorden bewegingsherkenning, Web services, afstandsbediening, domotica, toestandsbewust

WS-Gesture: a state-aware remote control Kristof Vandermeeren, Rob Vanden Meersche Supervisor(s): Filip De Turck, Bart Dhoedt, Gregory Van Seghbroeck, Stijn Verschichel Abstract—This article presents the architecture for a ubiquitous system, letting a user control the devices available in the system not via a regular remote control, but via 3D gestures. All communication within the distributed system happens via Web services, more specifically by using the Devices Profile for Web Services (DPWS) standard. Test results regarding both accuracy of gesture recognition and performance of the platform are discussed. Keywords—gesture recognition, Web services, remote control, home automation, state-aware

I. I NTRODUCTION T is a very common situation in a household today to have a lot of small appliances that are controlled with a remote control. When a home automation system is installed, the number of remote controls also potentially rises. Although commercial universal remotes exist, their operation is often complicated, due to the large amount of buttons, and most of the time they require a lot of configuration. This abstract explains the design and implementation of a prototype that addresses these issues. The main idea is to discover different devices that should be controlled, select a device, initiate a pairing with it and control the device by performing a gesture with the controller. For all communication between the different components in the system, Web service standards were implemented. In practice this means that the WS-Discovery standard is used for the discovery of the devices; the WS-Eventing standard is used to initiate a pairing and control devices by sending events; and the WS-Transfer standard takes care of sending and receiving metadata between the different components. A SunSPOT, a wireless sensor node developed by Sun Microsystems, acts as the controller. This sensor node uses the Squawk Java ME Virtual Machine and is equipped with a 3D accelerometer.

I

II. A RCHITECTURE AND COMMUNICATION PLATFORM A. Architecture Starting from the idea of a perfect world in which all components can communicate directly with each other, an architecture is designed. Issues regarding to different communication protocols will be addressed later in section IV. In the architecture, five main components can be identified, which will all communicate using Web service messages: • Controller: Contains all components associated with the selection of a device, the recognition of gestures and sending an event to a device. Although in practice these components can be placed on different physical machines, we chose to implement them both on the SunSPOT. The reason for this choice and the complications it lead to are discussed later in section III.

Trainer: All functionality regarding gesture recognition that can be executed off-line and does not impact the performance of controlling a device is contained in this component. This functionality, the training phase, will be discussed in section III. • Device(s): A component that acts as a bridge between physical devices and the rest of the platform. A device can register itself to receive events and send a command to a physical device whenever an appriopriate event is received. • Mapper: Contains mappings from gestures to actions. These mappings are unique per device and per user. Since they can be based on the state of the device, this component ensures the state-awareness aspect of our platform. • Configuration: This component contains functionality for configuration (e.g. management of devices or users) and acts as a central data source (e.g. for storing gestural data). All this data was stored in a database and can be accessed by other components or by users via a web based application that was implemented in Ruby on Rails. •

B. Communication A communication platform is designed to cope with difficulties regarding the integration of components communicating via different protocols. This design is based on the microkernel pattern, very well-suited to be used in situations with continuous evolving hardware and software and in which applications have to be easily portable and modifiable [1]. Using the microkernel pattern ensures that drivers for different communication protocols could be easily added and removed at development time or enabled and disabled at runtime. It also makes a loose coupling possible between the communication framework itself and the components that use it. A second requirement is that it has to be possible to add devices to the system at run-time, if they are already compatible with it, and this without the need for restarting other components withing the system. This requirement is automatically achieved by implementing Web service standaards as WS-Discovery and WS-Evening. It is also the main advantage of using Web service standards. III. G ESTURE RECOGNITION Gesture recognition is implemented as a pattern classifcation algorithm, which is typically performed in two stages: a training phase and a recognition phase. A. The training phase The training phase, which is performed in advance (off-line), is rather computationally intensive. Because of this it cannot be executed on a SunSPOT. It consists of training a Hidden Markov Model (HMM) for each gesture type by using several instances of that gesture type. HMMs are used widely for these types of pattern classification [2].

B. The recognition phase The recognition phase is done each time a gesture is made (on-line). Perfoming this phase on a server would require sending the data that was received from the SunSPOT’s accelerometer over the wireless Zigbee connection. According to our own measurements it would take 1 to 3 seconds, depending on the length of the gesture, to send this data. This is an intolerable delay. Because of this the decision was made to implement the recognition phase on the SunSPOT, which should be possible according to [3]. C. Performance When testing an early implementation of gesture recognition, it took about 3 to 4 seconds to recognize a gesture on the SunSPOT. The reason for this is that recognition depended heavily on matrix multiplications of floating-point numbers while the SunSPOT processor handles these multiplications very slowly [4]. As a consequence the conclusions made in [3], about being able to do gesture recognition on mobile processors, do not hold for the SunSPOT. To tackle this problem, the input data of samples has to be drastically simplified. This is achieved by applying the k-means clustering algorithm, which is described in [5], to the input samples used for gesture recognition. The resulting implementation runs approximately 25 times faster than the original, depending on the number of states in the HMM. D. Accuracy Several filters are applied to the sampled data to improve the accuracy of our gesture recognition implementation. These include an idle-state filter and a directional-equivalence filter, which are discussed in [6]. A second important technique to increase accuracy is by adding artificially generated noise instances for each gesture type. Why this works is explained in [7] and it is also applied in [3], amongst others. Since k-means clustering was needed to improve performance, the standard techniques for generating noise can not be used, so it was necessary to develop an algorithm to do this. Finally the gesture recognition algorithms is extensively tested to determine a usable set of parameters for our prototype implementation. Starting from a set of six primary gestures, which are located along the axes of the 3-D coordinate system (left, right, up, down, push and pull), the implementation achieve an average accuracy of 99,81% correct recognitions out of 8000 recognitions, as pictured in figure 1. This impressive result was achieved by using 10 clusters in the k-means clustering algorithm. Adding 4 other gestures (square, circle clockwise, circle counterclockwise and play) to the set resulted in a maximal average accuracy of 94%. IV. I MPLENTATION Finally a prototype of the platform is implemented. A SunSPOT is used as a controller and some virtual devices are implemented as Java programs, for example one that can control Winamp. Because in this real-life situation the controller uses Zigbee and the devices Ethernet to communicate, an extra component is added. This component, the gateway, performs

Fig. 1. Accuracy of gesture recognition for a set of six primary gestures as a function of the number of clusters in the k-means clustering algorithm. Each datapoint represents the average percentage of correct recognitions out of a total of 8000 recognitions. The fluctuations in this graph can be explained by the fact that the optimal amount of clusters is very specific to each situation. Adding a cluster to an optimal situation leads to a suboptimal distribution of the samples in clusters.

translations between different communication protocols and has some advanced routing functionality. Afterwards, performance testing is done on this implementation. The results show that it takes about half a second for an event to be sent and the corresponding action to be executed. Approximately 60% of this time is spent by sending the event message via the wireless Zigbee connection from the SunSPOT. V. C ONCLUSION In this article the design of an architecture for and implementation of a prototype platform that is used to discover, select and control different devices by means of Web service-based communication was discussed. The architecture and the communication platform were designed by using appropriate architectural patterns to ensure important quality attributes like modifiability and performance. It has been shown that the implementation of gesture recognition is fast, accurate and can be used in real-time applications. Although it might seem that sending events to a device is quite slow, this latency could easily be cut in half by reducing the message size as much as possible, which can be achieved by using another communication technology than Web services. Another approach could be using a controller that has a faster way of wireless communication at it’s disposal. R EFERENCES [1] F. Buschmann, Pattern-oriented software architecture: a system of patterns, Wiley, 2002 [2] R.R. Lawrence, A. Rabiner, A tutorial on hidden Markov models and selected applications in speech recognition Proceedings of the IEEE, vol. 77, no. 2, pp. 257-286, 1989 [3] Z. Prekopcsak, Accelerometer Based Real-Time Gesture Recognition, Poster, 2008 [4] Systronix, BenchMark 1.1d www.practicalembeddedjava.com/ benchmark/11a/benchmark 11d.html, 2009 [5] S. Lloyd, Least squares quantization in PCM IEEE Transactions on Information Theory, vol. 28, no. 2, pp. 129-137, 1982 [6] T. Schlömer, B. Poppinga, N. Henze, S. Boll, Gesture recognition with a Wii controller Proceedings of the 2nd international conference on Tangible and embedded interaction, pp. 11-14, ACM, 2008 [7] S. Kay, Can detectability be improved by adding noise? IEEE signal processing letters, vol. 7, no. 1, pp. 8-10, 2000

INHOUDSOPGAVE

i

Inhoudsopgave Glossary

vi

1 Introductie 1.1

1.2

1.3

1.4

1

Opgave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.1.1

Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.1.2

Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

De SunSPOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2.1

SunSPOT hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2.2

Squawk virtuele machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

Web service standaarden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.3.1

WS-Addressing: organisatie van de communicatie . . . . . . . . . . . . . . . .

5

1.3.2

WS-Discovery: ontdekken van toestellen . . . . . . . . . . . . . . . . . . . . .

5

1.3.2.1

Ad-hoc mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.3.2.2

Managed mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.3.2.3

Bespreking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

1.3.3

WS-Eventing: opzetten van een koppeling en sturen van events . . . . . . . .

8

1.3.4

WS-Transfer: versturen en ontvangen van (meta)data . . . . . . . . . . . . .

8

Gesture recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2 Use case scenario’s en quality attributes 2.1

10

Scenario’s in verband met gesture recognition . . . . . . . . . . . . . . . . . . . . . . 11 2.1.1

De gebruiker traint het systeem . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.2

Gebruiker herkennen en inloggen met behulp van zijn persoonlijke beweging . 13

2.1.3

De gebruiker maakt, voor een bepaald toestel, een mapping van gestures op acties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1.4

De gebruiker maakt een beweging en die wordt herkend door de gesture recognizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2

Scenario’s met betrekking tot communicatie . . . . . . . . . . . . . . . . . . . . . . . 16 2.2.1

Ontdekken van target services door de controller . . . . . . . . . . . . . . . . 16

2.2.2

Koppelen van controller en gewenste target service . . . . . . . . . . . . . . . 17

INHOUDSOPGAVE

2.2.3 2.3

2.4

ii

Aansturen van een target service . . . . . . . . . . . . . . . . . . . . . . . . . 18

Optionele scenario’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.3.1

Aansturen van toestellen die een continue besturing vereisen . . . . . . . . . 19

2.3.2

Koppelen van de controller met meerdere toestellen

. . . . . . . . . . . . . . 20

Quality Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.4.1

Modifiability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.2

Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4.3

Performance

2.4.4

Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Architectuur

23

3.1

Eerste niveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2

Tweede niveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.3

3.2.1

Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.2

Mapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.3

Trainer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.4

Configuratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.2.5

Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Toewijzing van use-case scenario’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 Communicatie

33

4.1

Nood aan een flexibel communicatiesysteem . . . . . . . . . . . . . . . . . . . . . . . 33

4.2

Ontwerp van de communicatiecomponent . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2.1

Het microkernelpatroon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.2

Uitwerking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.2.3

Gevolgen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5 Gesture Recognition 5.1

5.2

5.3

38

Gesture recognition met behulp van een accelerometer . . . . . . . . . . . . . . . . . 39 5.1.1

Karakterisatie van de input data . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1.2

Leren en herkennen van bewegingen met behulp van Hidden Markov Models

40

5.1.2.1

Trainingsfase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.2.2

Herkenningsfase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Verhogen van de accuraatheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.2.1

Effect van tilting minimaliseren . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2.2

Idle-state filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2.3

Directional-equivalence filter . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2.4

Toevoegen van noise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2.5

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Verhogen van de performantie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

INHOUDSOPGAVE

5.4

5.5

5.3.1

Performantie van de SunSPOT . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.3.2

K-means clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.3.3

Noise in combinatie met k-means clustering . . . . . . . . . . . . . . . . . . . 52

Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.4.1

Libraries en third-party code . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.4.2

Formaat van modeldata voor de herkenning . . . . . . . . . . . . . . . . . . . 54

5.4.3

De herkenningsfase met Jahmm in J2ME . . . . . . . . . . . . . . . . . . . . 54

Bepalen van werkbare parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.5.1

Bespreking van de parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.5.2

Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.5.3

Testresultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.5.4 5.6

iii

5.5.3.1

Vertrekparameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.5.3.2

Effect van het aantal noise gesture instances . . . . . . . . . . . . . 58

5.5.3.3

Effect van het aantal originele gesture instances . . . . . . . . . . . 58

5.5.3.4

Effect van het aantal clusters . . . . . . . . . . . . . . . . . . . . . . 60

5.5.3.5

Effect van het aantal toestanden in het HMM . . . . . . . . . . . . 63

5.5.3.6

Effect van de SNR van noise . . . . . . . . . . . . . . . . . . . . . . 63

5.5.3.7

Reduceren van de dataset . . . . . . . . . . . . . . . . . . . . . . . . 65

Conclusies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6 Implementatie

72

6.1

Proxy Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.2

De gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.3

De controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.4

De mapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 6.4.1

Afbeelden van bewegingen op acties . . . . . . . . . . . . . . . . . . . . . . . 77

6.4.2

Het koppelingsmechanisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.4.3 6.5

6.6

6.4.2.1

GestureEvent en DeviceEvent . . . . . . . . . . . . . . . . . . . . . 78

6.4.2.2

WS-Eventing in het kort . . . . . . . . . . . . . . . . . . . . . . . . 78

6.4.2.3

Prototype implementatie . . . . . . . . . . . . . . . . . . . . . . . . 78

Het sturen van events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

De configuratiecomponent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.5.1

Het configureren van het systeem . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.5.2

De configuratiecomponent als centrale databron . . . . . . . . . . . . . . . . . 83

6.5.3

Ruby on Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

6.5.4

Gebruikersinterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Communicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.6.1

Een bericht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

INHOUDSOPGAVE

6.6.2

6.6.3

6.7

iv

Componenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 6.6.2.1

Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

6.6.2.2

Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

6.6.2.3

Routing table

6.6.2.4

Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

6.6.2.5

Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Specifieke communicatiemechanismen . . . . . . . . . . . . . . . . . . . . . . 91 6.6.3.1

Opstarten van de controller . . . . . . . . . . . . . . . . . . . . . . . 92

6.6.3.2

Inloggen op de controller . . . . . . . . . . . . . . . . . . . . . . . . 92

6.6.3.3

Ontdekken van devices . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.6.3.4

Opzetten van een koppeling met en aansturen van een device . . . . 93

Performantie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 6.7.1

Snelheid van het communicatieraamwerk . . . . . . . . . . . . . . . . . . . . . 94 6.7.1.1

Werkwijze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.7.1.2

Het versturen en ontvangen van berichten over Zigbee . . . . . . . . 94

6.7.1.3

Marshallen en unmarshallen van berichten op de SunSPOT . . . . . 97

6.7.2

De duurtijd van het herkennen van een beweging op de controller . . . . . . . 99

6.7.3

Betrouwbaarheid van het Zigbee-protocol . . . . . . . . . . . . . . . . . . . . 99

6.7.4

Praktische analyse van de berichten . . . . . . . . . . . . . . . . . . . . . . . 101 6.7.4.1

Probe vanuit de controller

. . . . . . . . . . . . . . . . . . . . . . . 102

6.7.4.2

Opvragen van het login model . . . . . . . . . . . . . . . . . . . . . 102

6.7.4.3

Opvragen van het gebruikersmodel bij inloggen . . . . . . . . . . . . 102

6.7.4.4

Versturen van een EventingInit bij het koppelen van de controller en een device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.7.4.5

Versturen van een Event bij het aansturen van een device . . . . . . 103

7 Conclusie

104

A Web service berichten

107

A.1 Probe en ProbeMatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 A.2 Resolve en ResolveMatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 A.3 EventingInit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 A.4 Subscribe en SubscriptionResponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 A.5 SubscriptionEnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 A.6 GestureEvent en DeviceEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 A.7 GetDeviceState (Get, WS-Transfer) en DeviceState (GetResponse, WS-Transfer) . . 112 A.8 FeedbackIdentifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 A.9 StartCollection en StopCollection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 A.10 Opvragen van de modeldata (Get, WS-Transfer) . . . . . . . . . . . . . . . . . . . . 114

INHOUDSOPGAVE

v

A.11 Bericht met modeldata (GetResponse, WS-Transfer) . . . . . . . . . . . . . . . . . . 115 A.12 Starten van de training (Get, WS-Transfer) . . . . . . . . . . . . . . . . . . . . . . . 116 Appendices

107

Bibliografie

119

Lijst van figuren

122

Lijst van tabellen

123

Glossary

Glossary CRC cyclic redundancy check. 88 CRUD Create, Read, Update and Delete. 8 CVE Centrale Verwerkings Eenheid. 94, 97 DNS Domain Name System. 6, 90 EMG Elektromyografie. 38 HMM Hidden Makrov Model. 42–44, 49, 51–55, 57, 63, 64, 70, 92, 120, 121, 123 HTTP Hypertext Transfer Protocol. 6, 8, 83, 90 ID Identifier. 77, 80, 81, 83, 93 IP Internet Protocol. 83, 90 J2ME Java 2 Micro Edition. 54 J2SE Java 2 Standard Edition. 54 MVC Model-View-Controller. 31, 36 OPDF Observation Probability Distribution Function. 43, 54 REST Representational State Transfer. 8, 83 SNR Signal-to-noise ratio. 48, 52, 55, 57, 63–66, 69, 121, 123 SOAP Simple Object Access Protocol. 5, 84 SVM Support Vector Machine. 42 UDP User Datagram Protocol. 89

vi

Glossary

UI User Interface. 11, 30, 106 UPnP Universal Plug and Play. 73 URI Uniform Resource Identifier. 5, 81, 84, 90 URL Uniform Resource Locator. 6, 83 UUID Universally Unique Identifier. 6, 77, 78, 80, 83, 84, 90 XML Extensible Markup Language. 8, 25, 30, 40, 53

vii

INTRODUCTIE

1

Hoofdstuk 1

Introductie Put seatbelts on your ears, Roy, because I’m about to take them for the ride of their life! Maurice Moss, The IT Crowd

1.1 1.1.1

Opgave Probleemstelling

Bij vele elektrische toestellen (hi-fi, TV, DVD speler, ...) die men aankoopt krijgt men tegenwoordig een afstandsbediening. Als in huis nu ook nog eens één of meerdere domoticasystemen (veiligheidscamera, automatische verlichting, zonnewering, ...) zijn ge¨ınstalleerd, komen er mogelijk nog afstandsbedieningen bij. Het is ongetwijfeld beter al deze aparte afstandsbedieningen te vervangen door één enkel toestel. Dit kan al voor elektrische toestellen met een universele afstandsbediening, maar als we hier nu ook de domoticasystemen mee willen aansturen, schiet het infraroodsignaal van de universele afstandsbediening tekort. Verder zijn dergelijke afstandsbedieningen ook meestal overladen met toetsen om zo universeel mogelijk te zijn. Dit zorgt bij veel gebruikers voor verwarring en frustratie.

1.1.2

Doelstelling

Deze scriptie heeft drie belangrijke onderzoeksopdrachten. Eerst zullen we communicatie via Web services onderzoeken. In een volgend stadium zal onderzocht worden hoe een 3D-beweging via een SunSPOT, een sensornode die beschikt over een accelerometer en die draadloos kan communiceren via het Zigbee-protocol, kan herkend worden. Vervolgens zullen we een architectuur ontwerpen die het ontdekken van toestellen ondersteunt, het opzetten van een koppeling met een toestel, het doorsturen van configuratiedata en het starten van een actie op een toestel met behulp van een 3D-beweging mogelijk maakt.

1.2 De SunSPOT

2

Figuur 1.1: Een SunSPOT Een laatste belangrijk aspect is rekening houden met de toestand van het toestel dat aangestuurd wordt. De betekenis van een beweging kan immers verschillen naarmate het toestel zich in een andere toestand bevindt. Zo zou het bijvoorbeeld mogelijk zijn dat, bij het aansturen van een DVD-speler, een opwaartse beweging maken terwijl het toestel uitgeschakeld kan dienen om het toestel in te schakelen, terwijl dezelfde opwaartse beweging een menu zou kunnen openen wanneer het toestel reeds ingeschakeld is. Een onderdeel in ons systeem zal dus moeten instaan voor de afbeelding van bewegingen op acties, rekening houdend met de toestand van het aangestuurde toestel.

1.2

De SunSPOT

SunSPOT staat voor Sun Small Programmable Object Technology” en is een hardware en software ” platform voor gebruik in een draadloos sensornetwerk, gemaakt door Sun Microsystems. Op het apparaat draait de Squawk virtuele machine, wat het mogelijk maakt om er toepassingen voor te ontwikkelen in Java.

1.2.1

SunSPOT hardware

Een SunSPOT bestaat uit verschillende borden met elk hun functionaliteiten: • Main Board – 180 MHz 32 bit ARM920T core - 256K RAM/2M Flash – Chipcon CC2420 802.15.4 radio – Ge¨ıntegreerde antenne – Dubbele connector om boards te kunnen stapelen

1.2 De SunSPOT

3

stereoketen

camera

DVD speler desktop PC

gaming console televisie

SunSPOT

Figuur 1.2: Visualisatie van doelstelling

domotica server

1.2 De SunSPOT

4

– Kan stroomvoorziening krijgen van verscheidene type bronnen – Inclusief 1.5V batterij – Heeft 25-90mA aan stroom nodig, afhankelijk van werking – Grootte van 35x25 mm • Sensor Board – 2G/6G 3-assen accelerometer – Temperatuur sensor – Licht sensor – 8 RGB-LEDs – 6 analoge inputs – 2 drukknoppen – 5 I/O aansluitingen voor algemeen gebruik en 4 output aansluitingen die hoge stromen aankunnen.

1.2.2

Squawk virtuele machine

Op de SunSPOT draait de Squawk virtuele machine die ook ontwikkeld is door Sun Microsystems. Dit is een open source virtuele machine voor Java die hoofdzakelijk in Java zelf geschreven is, in tegenstelling tot de meeste commerciële virtuele machines, die meestal in programmeertalen van lager niveau geschreven zijn, zoals C of assembler. Het doel hiervan is de virtuele machine drastisch te vereenvoudigen. Deze opbouw is ge¨ıllustreerd in figuur 1.3. Bovendien is Squawk ook hoofdzakelijk gericht op diverse kleine toestellen met beperkte resources, wat makkelijker is met een eenvoudigere virtuele machine. De SunSPOT is op dit moment de hoofdtoepassing voor Squawk. [1]

Figuur 1.3: Opbouw van de Squawk virtuele machine [1]

1.3 Web service standaarden

1.3

5

Web service standaarden

Vooraleerst zullen we in deze sectie bespreken hoe communicatie met de verschillende apparaten (zoals bijvoorbeeld een televisietoestel of een stereoketen) kan verlopen. De component die instaat voor de communicatie moet de volgende taken kunnen uitvoeren: • Organisatie van de effectieve communicatie tussen apparaat en controller. • Ontdekken van apparaten die aangesloten zijn op het systeem en het selecteren van deze toestellen. • Opzetten van een communicatiekanaal tussen een apparaat en de controller, wat in ons geval de SunSPOT is, en het versturen van events van de controller naar het apparaat. • Verzenden en ontvangen van allerlei (meta)data. Zoals vermeld in sectie 1.1.2 is het onze bedoeling om de bovenstaande functionaliteiten te verwezenlijken met behulp van Web services. De eigenlijke communicatie wordt georganiseerd via Simple Object Access Protocol (SOAP) in combinatie met de WS-Addressing [2]-standaard. Voor het ontdekken van toestellen hebben we WS-Discovery [3] onderzocht, voor het opzetten van een koppeling tussen de controller en een apparaat en voor het verzenden van events de WS-Eventingstandaard [4] en voor het doorzenden van allerlei (meta)data de WS-Transfer -standaard [5]. In de volgende secties zullen we deze functionaliteiten uitgebreider bespreken.

1.3.1

WS-Addressing: organisatie van de communicatie

WS-Addressing is een gestandariseerde manier om routeringsinformatie voor Web service-berichten te plaatsen in de header van een SOAP-bericht. Enkele voorbeelden van dergelijke routeringsinformatie zijn een Uniform Resource Identifier (URI) die de bestemmeling identificeert, een URI die het huidige bericht identificeert en een URI die verwijst naar het bericht waar het huidige een antwoord op is. Dit mechanisme laat toe dat een systeem gebaseerd op Web services zijn eigen routeringen kan beheren en dus geen afhankelijk heeft heeft van transport op de netwerklaag. Berichten die voldoen aan de WS-Discovery-, WS-Eventing- en WS-Transfer -standaarden voldoen dus per definitie ook aan de WS-Addressing-standaard.

1.3.2

WS-Discovery: ontdekken van toestellen

Ten eerste zullen we de mogelijkheden voor het ontdekken van toestellen en de impact ervan op ons ontwerp bespreken. Het is echter niet de bedoeling om de volledige WS-Discovery specificatie [3] hier te herformuleren. Het opzet is eerder een algemeen overzicht te geven. Een implementatie van WS-Discovery kan opgebouwd zijn op basis van twee verschillende modes: ad-hoc mode en managed mode. Het is belangrijk op een degelijk gefundeerde wijze een keuze


6

te maken uit één van beide modes aangezien ze beide een specifieke impact op de opbouw van ons systeem hebben. We zullen in de secties 1.3.2.1 en 1.3.2.2 beide modes bespreken. In deze bespreking maken we gebruik van de volgende terminologiën uit de WS-Discovery specificatie: • Target service: Een service die we willen bereiken. In ons geval kan dit onder andere een apparaat zijn (zoals een televisie of een stereoketen) of meerdere toestellen die samenwerken en zo een service aanbieden. • Client: Het toestel dat verbinding wil maken met de target service(s). In ons geval is dit de onder andere de SunSPOT. 1.3.2.1

Ad-hoc mode

Ad-hoc mode is een mode van WS-Discovery waarbij alle toestellen rechtstreeks met elkaar communiceren. In deze mode zal een client berichten dus rechtstreeks naar target services verzenden. Deze berichten, die dienen ter ontdekking van target services, worden Probe-berichten genoemd. Een dergelijke Probe kan een lijst van zoekparameters bevatten, zoals het type van de toestellen die ontdekt moeten worden. Alle target services die aan deze parameters voldoen zullen vervolgens rechtstreeks een antwoord sturen naar de client met daarin onder andere hun type, metadata en hun Universally Unique Identifier (UUID). Een UUID kan echter niet noodzakelijk gebruikt worden om de target service op de transportlaag te adresseren. Om dit adres, meestal op een later tijdstip na de discovery, te verkrijgen moet nog een Resolve-bericht verstuurd worden. De target service die zijn UUID herkent, antwoordt dan met een bericht dat zijn transportlaagadres bevat. Dit mechanisme is te vergelijken met het Hypertext Transfer Protocol (HTTP) protocol over een IP-gebaseerd transportnetwerk waarin het IP-adres via Domain Name System (DNS) request verkregen wordt op basis van een gegeven Uniform Resource Locator (URL). Merk ook op dat Probeen Resolve-berichten in multicast verstuurd worden op het netwerk. Wanneer de ontdekking voltooid is, verloopt de communicatie tussen client en target service vanzelfsprekend ook rechtstreeks. Een visualisatie van de werking van ad-hoc mode is weergegeven in een sequentiediagram in figuur 1.4. 1.3.2.2

Managed mode

Managed mode is een mode van WS-Discovery waarbij alle toestellen elkaar via een proxy server, de zogenaamde discovery proxy, ontdekken. Hier is het belangrijk dat een target service via Helloen Bye-berichten zijn status aan de discovery proxy kenbaar maakt1 . Deze status kan elementen bevatten zoals onder andere de types die ondersteund worden door het toestel of het transportadres. De discovery proxy houdt deze informatie bij in een tabel en updatet die informatie bij ontvangst van een nieuw statusbericht. 1

Deze berichten worden in unicast verzonden naar de discovery proxy


7

Figuur 1.4: Ontdekken van toestellen in ad-hoc mode: sequentiediagram In managed mode zal de client zijn Probe- en Resolve-berichten niet meer rechtstreeks naar de target services sturen, maar zal hij ze in unicast naar de discovery proxy sturen. Deze antwoordt dan met alle nodige informatie over alle target services die voldoen aan het Probe- of Resolve-bericht. Opnieuw is het doel van deze communicatie dat er een koppeling opgezet wordt tussen de client en één of meerdere target services. Hoewel het ontdekkingsproces via een discovery proxy verloopt, verloopt de eigenlijke communicatie tussen client en target service, waarin de services van de target service worden aangesproken, echter rechtstreeks. Een visualisatie van de werking van deze mode is weergegeven in een sequentiediagram in figuur 1.5.

Figuur 1.5: Ontdekken van toestellen in managed mode: sequentiediagram


1.3.2.3

8

Bespreking

Het grote voordeel van werken in ad-hoc mode is dat er geen extra server in het netwerk aanwezig moet zijn, terwijl managed mode een discovery proxy vereist. Het gebruik van managed mode kan er echter voor zorgen dat het aantal berichten dat verzonden moet worden over het netwerk drastisch lager ligt in vergelijking met ad-hoc mode. Dit komt omdat het aantal berichten in multicast lager ligt en inkomende probe matches gegroepeerd kunnen worden in de proxyserver en als een geaggregeerde boodschap naar de client gezonden worden. Omdat we onze architectuur, en dus ons gehele systeem, zo eenvoudig mogelijk willen houden, opteren we voor de ad-hoc mode.

1.3.3

WS-Eventing: opzetten van een koppeling en sturen van events

Om het mogelijk te maken dat een beweging die gemaakt werd met de controller kan leiden tot het uitvoeren van een actie op een toestel, hebben we de WS-Eventing standaard onderzocht. Deze specificatie definieert een protocol zodat een entiteit (de subscriber ) zich kan registreren (een subscription) bij een andere (de event source) met als doel dat de subscriber berichten ontvangt bij bepaalde events (dit zijn notifications of ook wel event messages). Eigenlijk is de WS-Eventing niets meer en niets minder dan het alom bekende Publisher-Subscriber patroon [6]. Als we een eventingmechanisme in onze context toepassen, moeten we wel opmerken dat de SunSPOT de taak van event source op zich zal nemen, terwijl de target services de subscribers zijn. Het gevolg van deze constructie is dat er een signaal gestuurd zal moeten worden naar een target service opdat deze zich zou inschrijven bij de controller. Deze manier van werken lijkt op het eerste zicht nogal tegenintu¨ıtief maar we hebben er toch voor gekozen om de WS-Eventing standaard zo nauwkeurig mogelijk te kunnen implementeren. Het gevolg van een implementatie die zeer getrouw is aan een standaard is dat ze makkelijker op te splitsen valt en makkelijker te integreren met andere applicaties die de standaard respecteren.

1.3.4

WS-Transfer: versturen en ontvangen van (meta)data

Het versturen of opvragen van allerlei (meta)data gebeurt volgens de WS-Transfer -standaard. Deze specificatie definieert een mechanisme om Extensible Markup Language (XML)-gebaseerde representaties van entiteiten te verkrijgen met behulp van de Web service infrastructuur. De standaard definieert de operaties Get, Put, Delete en Create, wat eigenlijk voorstellingen zijn van Create, Read, Update and Delete (CRUD), de vier basisfuncties van persistente dataopslag. Deze manier van werken is ook vergelijkbaar met Representational State Transfer (REST) uit het HTTP-protocol.

1.4 Gesture recognition

1.4

9

Gesture recognition

Een volgend belangrijk aspect in dit werk is het uitvoeren van bewegingsherkenning, een activiteit die in de literatuur aangeduid wordt met de term gesture recognition. We zullen in hoofdstuk 5 een uitgebreide bespreking formuleren over gesture recognition. Het enige wat hieromtrent nu dient uitgelegd te worden is dat gesture recognition traditioneel uitgevoerd wordt in twee fasen: een trainingsfase en een herkenningsfase [7]. Tijdens de trainingsfase, die een rekenintensieve fase is en typisch off-line uitgevoerd wordt [8], worden wiskundige modellen opgebouwd aan de hand van een aantal voorbeeldbewegingen. Deze modellen kunnen vervolgens tijdens de herkenningsfase gebruikt worden om een ongekende beweging te herkennen.

USE CASE SCENARIO’S EN QUALITY ATTRIBUTES

10

Hoofdstuk 2

Use case scenario’s en quality attributes Leonard Hofstadter: Ah, no, we turned ” our stereo down by sending a signal around the world via the Internet.” Penny: Ohhhh. You know, you can just ” get one of those universal remotes from RadioShack. They’re really cheap.” The Big Bang Theory

Vooraleer we kunnen beginnen met het uitwerken van een architectuur voor ons platform, moeten we eerst de functionele scenario’s bespreken waarvan we willen dat ze door de architectuur ondersteund zullen worden. Bovendien worden ook, later in dit hoofdstuk, de verscheide quality attributes, die ons platform moet ondersteunen, besproken. Daarna wordt dan, in hoofdstuk 3, een architectuur opgesteld met deze use-case scenario’s en quality attributes als basis. Voor de eenvoud spreken we in de scenario’s over de applicatie” indien we de configuratie” component bedoelen. Zoals de naam doet vermoeden is dit de component die instaat voor de configuratie van het hele systeem en het bijhouden van de nodige data hiervoor. De andere compontenten kunnen hier terecht indien ze die data nodig hebben. Meer gedetaileerde informatie hierover volgt onder andere in sectie 3.2.4 en sectie 6.5 maar op dit moment volstaat de zonet vermeldde informatie.

2.1 Scenario’s in verband met gesture recognition

2.1

11

Scenario’s in verband met gesture recognition

2.1.1

De gebruiker traint het systeem

Dit scenario komt overeen met het uitvoeren van de trainingsfase van gesture recognition en komt eigenlijk neer op de verschillende types gestures, die men wenst te gebruiken, aan te leren aan het systeem. Main Success Scenario 1. De gebruiker selecteert zijn gebruikersprofiel. 2. De gebruiker klikt op de Train gestures” knop in de UI. ” 3. De gebruiker maakt voor ieder type beweging een aantal trainingsgestures aan. 4. De gebruiker klikt op Opslaan” ” 5. Het systeem slaat de bewegingen op en overschrijft eventueel reeds bestaande trainingsgestures. 6. Het systeem laat dan de modellen die later gebruikt zullen worden voor herkenning trainen bij de trainer. Extensions [3] Het systeem waarschuwt de gebruiker indien een trainingsgesture niet bruikbaar is en de gebruiker maakt de beweging opnieuw. Een oorzaak van het onbruikbaar zijn kan bijvoorbeeld een te korte of een te snelle beweging zijn. [3] De gebruiker klikt op Annuleren”. Hierdoor worden geen nieuwe trainingsgestures opgesla” gen of oude overschreven. [5] Eventueel is het ook mogelijk om trainingsgestures toe te voegen aan een bepaalde beweging. Bovendien moet het steeds mogelijk blijven om opgeslagen trainingsgestures te verwijderen indien de gebruiker niet tevreden is over de werking ervan, zoals bijvoorbeeld een te lage nauwkeurigheid. Triggers 1. De gebruiker selecteert zijn gebruikersprofiel en klikt op de Train gestures” knop in de User ” Interface (UI). Pre-Condition 1. De gebruiker heeft de applicatie gestart en er is een connectie tussen de applicatie en de te gebruiken controller, in ons geval de SunSPOT. 2. De gebruiker heeft een gebruikersprofiel aangemaakt voor zichzelf.


12

Post-Condition 1. De persoonlijke trainingsgestures zijn opgeslagen en beschikbaar voor verder gebruik. 2. Bij het selecteren van het bijhorende gebruikersprofiel worden de trainingsgestures gebruikt bij het trainen van de herkenningsmodules.


2.1.2

13

Gebruiker herkennen en inloggen met behulp van zijn persoonlijke beweging

Main Success Scenario 1. De gebruiker drukt op een knop om in te loggen. 2. De gebruiker maakt zijn persoonlijke beweging. 3. Die beweging wordt door de gesture recognizer herkend en het juiste gebruikersprofiel, met bijhorende herkenningsmodule opgebouwd aan de hand van de persoonlijke trainingsgestures, wordt ingeladen. Extensions [3] De beweging wordt niet met genoeg zekerheid herkend of is te kort en de gebruiker wordt hiervan op de hoogte gebracht. Hij moet zijn of beweging opnieuw maken. Triggers 1. De gebruiker drukt op een knop om in te loggen. Pre-conditions 1. Er is nog geen gebruiker ingelogd. 2. De applicatie is ingeschakeld, alsook de controller, en er is een verbinding tussen de controller en de applicatie mogelijk. 3. De gebruiker moet een getraind profiel hebben, zoals beschreven in scenario 2.1.1, en een persoonlijke beweging ingesteld hebben op de configuratiecomponent. Post-conditions 1. De gebruiker is ingelogd. 2. Zijn of haar persoonlijke trainingsgestures zijn gebruikt bij het trainen van de herkenningsmodule en de gesture recognizer zal nu de bewegingen van deze gebruiker optimaal herkennen.


2.1.3

14

De gebruiker maakt, voor een bepaald toestel, een mapping van gestures op acties

Main Success Scenario 1. De applicatie verzamelt een lijst van beschikbare toestellen. 2. De gebruiker klikt op Maak mapping” voor een bepaald toestel. ” 3. Het systeem maakt een verbinding met het geselecteerde toestel en vraagt de ondersteunde acties op (bijvoorbeeld via WDSL). 4. De gebruiker maakt voor iedere toestand waarin het toestel zich kan bevinden een mapping tussen de gestures en de acties en definieert bij iedere actie een toestandsverandering indien van toepassing. 5. De gebruiker klikt op Opslaan” en de nieuwe mapping wordt opgeslagen en vanaf nu gebruikt ” door het systeem. Extensions [6] De gebruiker klikt op Annuleren” en de standaard of vroeger gedefinieerde mapping blijft ” geldig. De wijzigingen worden niet opgeslagen. Triggers 1. De gebruiker klikt op Maak mapping”. ” Pre-conditions 1. De gebruiker heeft het te configureren toestel aangesloten en het is beschikbaar voor de applicatie. 2. De gebruiker heeft de applicatie gestart. Post-conditions 1. De nieuwe mapping is opgeslagen en zal bij verder werken gebruikt worden, zie 2.2.3.


2.1.4

15

De gebruiker maakt een beweging en die wordt herkend door de gesture recognizer

Main Success Scenario 1. De gebruiker drukt op een knop om de bewegingsherkenning starten. 2. De gebruiker maakt een beweging. 3. De beweging wordt herkend door de gesture recognizer. Extensions [3] Indien een beweging niet met voldoende zekerheid herkend kan worden of indien de beweging te kort is, wordt dit aan de gebruiker meegedeeld. Triggers 1. De gebruiker drukt op een knop om de bewegingsherkenning starten. Pre-conditions 1. Het correcte gebruikersprofiel moet geselecteerd zijn. Met andere woorden, de gebruiker moet ingelogd” zijn. ” 2. De training moet uitgevoerd zijn, zoals beschreven in scenario 2.1.1. Post-conditions 1. De beweging wordt herkend en kan verder gebruikt worden door het systeem om een toestel aan te sturen.

2.2 Scenario’s met betrekking tot communicatie

2.2

16

Scenario’s met betrekking tot communicatie

2.2.1

Ontdekken van target services door de controller

Main Success Scenario 1. De gebruiker vraagt de controller (SunSPOT) om de beschikbare en aanstuurbare target services te ontdekken en weer te geven. 2. De controller zal via WS-Discovery de beschikbaare target services ontdekken en weergeven aan de gebruiker. Extensions [1] Eventueel kan ook een bepaald type target service, zoals een toestel dat audio kan afspelen, opgegeven worden. Zo wordt de lijst met beschikbare target services meteen gereduceerd en is het voor de gebruiker eenvoudiger de gewenste target service te selecteren. [2] Hier zijn er zoals eerder vermeld 2 mogelijkheden binnen de WS-Discovery standaard: ad-hoc mode en managed mode. Deze opties werden reeds eerder besproken in sectie 1.3.2. Bij voorkeur wordt de ad-hoc mode gebruikt. Triggers 1. De gebruiker wil de beschikbare target services ontdekken en vraagt dit aan de controller. Pre-conditions 1. Het juiste gebruikersprofiel moet ingeladen zijn. Met andere woorden, de gebruiker moet ingelogd” zijn. ” 2. Indien gebruik gemaakt wordt van managed mode moet ook de discovery proxy ingeschakeld zijn. Post-conditions 1. De gebruiker kan uit de lijst van target services de target service (het toestel) kiezen dat hij wenst aan te sturen.


2.2.2

17

Koppelen van controller en gewenste target service

In dit scenario wordt de effectieve koppeling tussen de controller (in ons geval dus de SunSPOT) en de gewenste target service tot stand gebracht. Main Success Scenario 1. De gebruiker kiest een target service die hij wil aansturen uit de lijst van beschikbare target services. 2. Het systeem zorgt ervoor dat de target service zich als subscriber registreert bij de event source. De reden voor deze, op het eerste zicht omgekeerde, constructie werd besproken in sectie 1.3.3. Extensions Niet van toepassing. Triggers 1. De gebruiker kiest een target service om aan te sturen. Pre-conditions 1. Scenario 2.2.1 moet eerst succesvol uitgevoerd worden. Post-conditions 1. Er is nu een koppeling, oftewel een pairing, tussen de controller en de aan te sturen target service. Deze koppeling kan nu gebruikt worden om de target service aan te sturen. Deze handeling wordt besproken in scenario 2.2.3.


2.2.3

18

Aansturen van een target service

Hier maakt de gebruiker een beweging als aansturing voor de gepairde target service. Het is natuurlijk de bedoeling dat deze target service correct reageert. We kunnen bij dit scenario opmerken dat het eigenlijk een overkoepelende functie heeft en dat het dus grotendeels een combinatie is van andere, reeds beschreven, scenario’s. Main Success Scenario 1. De gebruiker drukt op een knop om de bewegingsherkenning te starten. 2. De gebruiker maakt een beweging. 3. De beweging wordt door de gesture recognizer herkend als een beweging van een bepaald type, zoals beschreven in scenario 2.1.4. 4. De gepairde target service ontvangt deze beweging. 5. Deze target service reageert nu op de beweging zoals beschreven in de mapping. Ook dit werd reeds eerder behandeld, in scenario 2.1.3. Extensions [3] De opgegeven beweging is te kort of kan niet met voldoende zekerheid herkend worden. Bijgevolg laat het systeem dit weten aan de gebruiker, zonder dat er een actie wordt uitgevoerd met als resultaat dat de gebruiker zijn beweging opnieuw moet maken. De reden hiervoor is om foutieve acties als gevolg van verkeerd ge¨ınterpreteerde bewegingen zoveel als mogelijk te minimaliseren. Triggers 1. De gebruiker drukt op een knop om de bewegingsherkenning te starten. 2. De gebruiker maakt een beweging. Pre-conditions 1. Scenario 2.2.2 moet eerst succesvol uitgevoerd zijn. Post-conditions 1. De target service voert de correcte actie uit en gaat indien nodig over naar een andere toestand. 2. De target service wacht op de volgende instructie.

2.3 Optionele scenario’s

2.3

19

Optionele scenario’s

2.3.1

Aansturen van toestellen die een continue besturing vereisen

Voorlopig zijn we er steeds van uit gegaan dat een toestel aangestuurd wordt door middel van een beweging die eerst volledig uitgevoerd wordt voordat het commando naar het apparaat gestuurd wordt. In sommige situaties kan echter een continue vorm van aansturing handiger zijn. Met een continue besturing bedoelen we het continu samplen van de accelerometer en aan de hand van de bekomen waarden een continue stroom van opdrachten sturen naar het toestel in plaats van bewegingen in hun geheel te interpreteren en één commando per beweging te versturen. Main Success Scenario 1. De gebruiker maakt een koppeling met een target service die continue besturing vereist. 2. Het systeem herkent deze eigenschap en de herkenningscomponent schakelt over van gesture recognition naar continue besturing. Extensions Niet van toepassing Triggers 1. Er wordt een koppeling gemaakt met een target service die continue besturing vereist. Pre-conditions 1. De target service moet ontdenkt zijn via de discovery stap, zie 2.2.1. Post-conditions 1. De gebruiker kan nu via continue aansturing de target service besturen.

2.3 Optionele scenario’s

2.3.2

20

Koppelen van de controller met meerdere toestellen

De gebruiker zal bij het ontdekken van beschikbare target services een service ontdekken die bestaat uit een samenwerking van meerdere toestellen en hiermee willen koppelen. Main Success Scenario 1. De gebruiker start de ontdekking van target services van op de controller zoals beschreven in scenario 2.2.1. 2. De gebruiker start de koppeling tussen de gewenste target service en de controller zoals beschreven in scenario 2.2.2. Extensions Niet van toepassing. Triggers 1. De gebruiker wil een koppeling maken met een target service die bestaat uit een samenwerking van meerdere toestellen. Pre-conditions 1. De gewenste target service is beschikbaar. 2. De gebruiker is ingelogd in het systeem. Zijn persoonlijke bewegingsmodellen zijn ingeladen. Post-conditions 1. Er is nu een koppeling tussen de controller en de gewenste target service en die kan aangestuurd worden zoals beschreven in scenario 2.2.3.

2.4 Quality Attributes

2.4

21

Quality Attributes

In deze sectie bespreken we informeel en in het algemeen de belangrijkste kwaliteitseisen waaraan ons systeem moet voldoen. De meest voorkomende quality attributes zijn performance, modifiability, usability, scalability, availability, security en testability [9]. Wij zullen ons bij het ontwerpen van onze architectuur en onze proof of concept-applicatie focussen op de eerste drie quality attributes die we zonet vermeld hebben.

2.4.1

Modifiability

Modifiability, of anders gezegd aanpasbaarheid, slaat op de mogelijkheid om het systeem snel aan te passen aan veranderingen in software, hardware, data en de voorstelling van die data, veranderende systeemeisen zoals performantie, enzovoorts. Bovendien moet dit alles kunnen at development time of at runtime. Wij concentreren ons vooral op veranderende hardware en de mogelijkheid om het systeem at development time aan te passen. Het systeem moet dus voor een programmeur gemakkelijk te porteren zijn naar de nieuwe hardware. Wat zijn de mogelijke hardwarewijzigingen? Er kan bijvoorbeeld een andere controller gebruikt worden. Als dit een controller is die zelf geen berekeningen kan uitvoeren (zoals bijvoorbeeld een Wii Remote), zal de herkenning op een rekenserver moeten gebeuren. Bovendien moet ook het bevragen van de sensoren op een andere manier gebeuren. Het is van cruciaal belang dat het systeem snel aan te passen is aan een dergelijke veranderende situatie. Een ander voorbeeld van een veranderende situatie is een wijziging in het communicatiekanaal. Het platform moet ontwikkeld worden zodat het onafhankelijk is van de fysieke manier van communicatie tussen target service en controller.

2.4.2

Usability

We willen natuurlijk ook dat het systeem gebruiksvriendelijk is. Eén voorbeeld hiervan is het plaatsen van zo weinig mogelijk knoppen op de controller om de bediening zo simpel mogelijk te houden. Indien we immers veel knoppen op de controller zouden plaatsen, valt het voordeel ten opzichte van een gewone universele afstandsbediening weg. Een tweede voorbeeld van gebruiksvriendelijkheid is zorgen voor een vlotte ontdekking van, koppeling met en aansturing van toestellen, zodat de gebruiker geen storende vertragingen ondervindt. Ook de snelheid van de gesture recognition heeft hierop een invloed en deze eis is dus ook gelinkt aan de quality attribute die hierop volgt, namelijk performance. Een derde aspect van usability is het ontwikkelen van een eenvoudige gebruikersinterface voor de configuratie van het platform en de trainingsfase van gesture recognition. Zo kunnen we bijvoorbeeld kiezen om ons platform te laten configureren via een web-based applicatie. Op die manier hoeft de gebruiker geen extra software op zijn computer te installeren en kan hij van iedere PC in zijn netwerk de applicatie bedienen. Het zou zelfs mogelijk zijn de configuratieapplicatie van elders (via

2.4 Quality Attributes

22

het internet) aan te spreken.

2.4.3

Performance

Een derde belangrijke factor is de performantie die, zoals zonet vermeld werd, ook een invloed heeft op de bruikbaarheid. Zo moet het herkennen van een beweging, het doorspelen van die beweging aan het juiste toestel en de daaropvolgende actie vlot uitgevoerd worden. Het is onaanvaardbaar als de gebruiker bijvoorbeeld meer dan een seconde moet wachten vooraleer er een reactie zichtbaar is op zijn beweging. Bovendien moet ook het ontdekken van toestellen en het koppelen ermee vlot verlopen. We verwachten echter wel dat het verzekeren van een performante implementatie van gesture recognition niet zozeer een grote impact zal hebben op de architectuur, maar eerder technisch van aard is. Hiermee bedoelen we dat de snelheid ervan eerder af zal hangen van de gekozen algoritmes om de bewegingsherkenning uit te voeren, eerder dan van de architectuur en beslissingen omtrent het ontwerp.

2.4.4

Conclusie

Zoals we merken heeft het goed ontwerpen van gesture recognition een grote invloed op twee van de drie quality attributes die we hier besproken hebben. Later in deze thesis hebben we een volledig hoofdstuk gewijd aan ons onderzoek naar een performante implementatie van gesture recognition, namelijk hoofdstuk 5.

ARCHITECTUUR

23

Hoofdstuk 3

Architectuur The loftier the building, the deeper must the foundation be laid. Thomas Kempis

In dit hoofdstuk zullen we de architectuur uitwerken van ons platform, gebaseerd op de use-case scenario’s en de quality attributes die we in het vorige hoofdstuk besproken hebben.

3.1

Eerste niveau

In onze architectuur identificeren we vijf basiscomponenten: de controller, de trainer, één of meerdere devices, de mapper en een component die instaat voor de configuratie van het volledige systeem. Hieronder beschrijven we de verschillende basiscomponenten en hun functionaliteit.1 : • Controller: Alle functionaliteit die op logische wijze verband houdt met de afstandsbediening en dus een hoge graad van interactiviteit met de gebruiker vereist. – Bewegingslogica: alle logica die nodig is om een gesture te herkennen alsook de componenten die instaan voor het omgaan met de hardware (zoals het bevragen van een accelerometer). Dit omvat dus de herkenningsfase van gesture recognition. – Functionaliteit die het de gebruiker mogelijk maakt in te loggen alsook het toestel te selecteren dat hij of zij wenst aan te sturen. • Trainer: Bevat deze onderdelen van gesture recognition die off-line dienen te gebeuren en geen impact hebben op het real-time karakter ervan (zoals bijvoorbeeld de trainingsfase). 1

Merk op dat deze vijf componenten niet noodzakelijk op vijf afzonderlijke fysieke systemen uitgevoerd moeten

worden. De afweging hieromtrent is een kwestie van deployment en implementatie. Het is dus bijvoorbeeld niet per se zo dat de architecturale controller -component volledig overeen komt met de fysieke afstandsbediening die gebruikt wordt. Als men gebruik maakt van een afstandsbediening met beperkte mogelijkheden, kan het zijn dat bepaalde onderdelen van de controller -component noodgedwongen zich elders zullen bevinden.

3.1 Eerste niveau

24

Figuur 3.1: Architectuur: Eerste niveau Meer informatie hierover is terug te vinden in hoofdstuk 5, dat volledig handelt over gesture recognition. • Device(s): Een device is een softwarecomponent die een brug zal slaan tussen fysieke toestellen en de rest van ons systeem. Het kan op het toestel zelf draaien of op een andere machine die dan als proxy voor het toestel kan werken. Een device kan één of meerdere toestellen tegelijk vertegenwoordigen alsook meerdere toestellen die samenwerken als 1 service. Een meer gedetailleerde en praktische aanpak vindt u in sectie 6.1. Het is onze bedoeling de hoeveelheid logica in devices zo laag mogelijk te houden. • Mapper: Deze component bevat de afbeelding van bewegingen op acties van toestellen. Deze afbeelding kan afhankelijk zijn van verschillende toestanden van het aan te sturen toestel. Door deze abstractie is het mogelijk om op een later tijdstip de contextinformatie makkelijk te wijzigen. • Configuratie: Het doel van deze component is de gebruiker de mogelijkheid geven het systeem makkelijk te installeren en naar zijn wensen aan te passen. Dit configuratiepaneel zal gebruikt kunnen worden om bewegingen te trainen, devices te configureren, gebruikers te beheren, enzovoorts. Alle communicatie tussen de verschillende componenten zal gebeuren volgens de Web servicestandaarden. De vijf ge¨ıdentificeerde componenten hebben we gevisualiseerd in figuur 3.1. Om onze architectuur zo duidelijk mogelijk te kunnen bespreken, zullen we in dit hoofdstuk alle aspecten inzake

3.2 Tweede niveau

25

Figuur 3.2: Architectuur: Eerste niveau, verdere uitwerking met de situatie waarbij events rechtstreeks naar de devices gestuurd worden (zie sectie 3.2.2) communicatie tussen de verscheidene componenten buiten beschouwing laten. We zullen later, in Hoofdstuk 4, verder hierop ingaan. Voor de verdere uitwerking wordt er een perfecte wereld verondersteld waarin alle componenten, ongeacht hun communicatiemogelijkheden, met elkaar kunnen communiceren. Een meer gedetailleerde uitwerking van de vijf basiscomponenten is te zien in figuur 3.2. In dit diagram hebben we ook de specifieke vormen van communicatie (dus de gebruikte Web service standaarden) vermeld. Waar in het diagram geen Web service standaarden vermeld zijn, zullen XML-berichten verzonden worden die voldoen aan de WS-Addressing standaard.

3.2

Tweede niveau

In deze sectie behandelen we de verschillende componenten, die we hierboven ge¨ıdentificeerd hebben, afzonderlijk. We beginnen met het verder uitwerken van de controller en zijn subcomponenten, daarna gaan we over naar de mapper, de trainer, de configuratiecomponent en we eindigen met een bespreking van de devices.

3.2 Tweede niveau

3.2.1

26

Controller

Een meer gedetailleerde voorstelling van de bewegingslogicacomponent is voorgesteld in figuur 3.3. In de bewegingslogica onderscheiden we de volgende subcomponenten: • Hardware Management hebben we onderverdeeld met behulp van een simpel layers-patroon [6] bestaande uit twee lagen. De functionaliteit bestaat er uit de sensoren van de controller aan te spreken en deze data te verwerken zodat ze bruikbaar is voor de client. Eén laag zal instaan voor communicatie met de hardware en een andere voor de verwerking. Op deze manier wordt afhankelijkheid van de hardware vermeden. • De Recognition Manager is eigenlijk de koppeling tussen Hardware Management en de Gesture Recognizer. Die zorgt ervoor dat de hardware op het juiste moment wordt aangesproken en de verkregen data correct doorgegeven wordt naar de herkenner. Eigenlijk kan deze component dus gezien worden als het instappunt van de applicatie. • De Gesture Recognizer : Deze component staat in voor het herkennen van een beweging. We hebben binnen deze component gekozen voor het pipes en filters-patroon [6]. Enkele redenen hiervoor zijn uitwisselbaarheid van filters en de mogelijkheid om een filter aan te passen zonder andere filters te be¨ınvloeden. De specifieke functionaliteiten van de filters worden in Hoofdstuk 5 uitgebreid besproken. Binnen het pipes en filters-patroon krijgen twee componenten specifieke benamingen toegewezen: de data source (het begin van de pipe, waarvan de data afkomstig is) en de data sink (het einde van de pipe, waar de verwerkte data aan afgeleverd wordt). In ons geval is de Recognition Manager de data source en de herkenner de data sink. In figuur 3.3 is de Gesture Recognizer uitgewerkt aan de hand van een activity-diagram. • De User Manager zorgt voor het trainen van de herkenner wanneer een gebruiker inlogt2 . Er moet vanuit deze component een verbinding gemaakt worden met de configuratiecomponent om de trainingsmodellen in te laden3 .

3.2.2

Mapper

Zoals reeds eerder besproken zal de mapper mogelijke bewegingen afbeelden op acties van toestellen. De gekozen actie kan afhankelijk zijn van de toestand waarin het aangestuurde toestel zich op dat moment bevindt. De architectuur van de mapper is op zich triviaal en zal enkel bestaan uit een component waarin de afbeeldingen worden opgeslagen en een component die instaat voor communicatie met de andere delen van het systeem. Wat echter wel belangrijk is, is de manier waarop de mapper aangesproken zal worden. Om dit te verduidelijken gaan we uit van een situatie waarbij er een beweging herkend wordt op de controller en een event met de juiste actie naar het 2 3

Dit is ook de reden waarom deze component bij bewegingslogica ondergebracht is De data van de trainingsmodellen zal doorgezonden in een bericht dat voldoet aan de WS-Transfer standaard

3.2 Tweede niveau

Figuur 3.3: Architectuur: Tweede niveau, bewegingslogica in de controller

27

3.2 Tweede niveau

28

Figuur 3.4: Architectuur: Tweede niveau, Mapper: situatie waarbij events rechtstreeks naar de devices gestuurd worden aan te sturen device gezonden moet worden. Op het eerste zicht liggen er dan twee mogelijkheden voor de hand om de mapper in te passen in ons platform: • Events worden rechtstreeks naar de devices gestuurd (voorgesteld in figuur 3.4). In deze situatie zal de controller, wanneer hij een event wil verzenden eerst de mapper moeten contacteren. De mapper zal op zijn beurt de huidige toestand aan het device moeten opvragen en de correcte actie teruggeven aan de controller. Ten slotte kan de controller dan een event met de correcte actie naar het device verzenden. Deze situatie zit ook vervat in figuur 3.2. Hoewel dit misschien de meest voor de hand liggende methode lijkt, is er een probleem met deze aanpak. In dit geval zorgt het aansturen van een device er namelijk iedere keer voor dat er twee berichten verzonden en één bericht ontvangen wordt door de controller. In de praktijk zullen deze berichten echter over een draadloos medium, dat mogelijks traag is, gestuurd worden. Bovendien kan het verzenden en ontvangen van berichten op de controller zorgen voor heel wat batterijverbruik. • De controller zendt alle events naar de mapper (voorgesteld in figuur 3.5). In dit geval zal de mapper de toestand opvragen aan het device en het event met de correcte actie aanpassen om ten slotte het event door te sturen. Deze situatie zit ook vervat in figuur 3.6. Deze optie geniet onze voorkeur aangezien het draadloze communicatiekanaal van de controller minder zwaar belast zal worden en in de praktijk de verbinding tussen mapper en device wel over een bekabeld netwerk (zoals bijvoorbeeld Ethernet) zal plaatsvinden en dus veel sneller kan zijn. De keuze voor deze laatste optie heeft ook een invloed op de implementatie van ons eventing-systeem. In sectie 1.3.3 vermeldden we dat we een eventing-mechanisme omgekeerd zouden

3.2 Tweede niveau

29

Figuur 3.5: Architectuur: Tweede niveau, Mapper: situatie waarbij events naar de mapper gestuurd worden

Figuur 3.6: Architectuur: Eerste niveau, verdere uitwerking met de situatie waarbij events naar de mapper gestuurd worden (zie sectie 3.2.2)

3.2 Tweede niveau

30

Figuur 3.7: Architectuur: Tweede niveau, herkenningstrainer in de server toepassen en dat een device zich zou moeten inschrijven bij de controller om events te kunnen ontvangen. Het gevolg van de plaatsing van de mapper als een soort proxy voor events is dat de devices zich nu zullen moeten inschrijven bij de mapper en dat de controller het adres van de mapper nodig heeft om events te sturen.

3.2.3

Trainer

Deze component is zeer analoog aan de Gesture Recognizer component uit de controller die we besproken hebben in sectie 3.2.1. Ook hier hebben we gekozen voor een pipes en filters-patroon. De grootste verschillen zijn de componenten die de data source en de data sink voorstellen. De data is namelijk opgeslagen op de configuratieserver (zie sectie 3.2.4) als een XML-document en moet uiteindelijk verwerkt worden in de trainer. Dit wordt gevisualiseerd in figuur 3.7. Zowel de trainingsfase van gesture recognition als de verschillende filters worden later in deze scriptie, meerbepaald in hoofdstuk 5, uitgebreid besproken.

3.2.4

Configuratie

Deze component zal alle logica bevatten die van toepassing is op verscheide taken zoals het configureren van de devices, aanmaken van gebruikersaccounts en het beheren van het trainingsmechanisme. Verder dient deze component ook als centrale dataopslag voor bijvoorbeeld afbeeldingen van bewegingen op acties, trainingsgestures, ... Deze component zal dus eigenlijk uit twee layers bestaan: een laag met de achterliggende logica (de business logic) en een laag die een gebruikersinterface (de UI) bevat. In de praktijk zijn we van plan de gebruikersinterface te implementeren als een webapplicatie in Ruby on Rails. Het gevolg hiervan is dat, conceptueel gezien, deze component op een aparte

3.3 Toewijzing van use-case scenario’s

31

machine uitgevoerd kan worden. 4 . Een bijkomend voordeel van gebruik maken van Ruby on Rails is dat een implementatie automatisch voldoet aan het Model-View-Controller (MVC)-patroon.

3.2.5

Devices

Ook de architectuur van een device is triviaal. De reden hiervoor is dat we de logica op een toestel tot een minimum willen beperken. Een toestel moet slechts de volgende acties kunnen uitvoeren: • Zich inschrijven bij de mapper nadat het hier de opdracht voor heeft gekregen. Dit is nodig om events te kunnnen ontvangen. • Een binnenkomend event behandelen en de actie uitvoeren die er in vermeld is. • Antwoorden wat de toestand van het toestel is wanneer de mapper dit vraagt. • Verwerken van parameters die afkomstig zijn van de configuratiecomponent. Een praktijkvoorbeeld hiervan is het vastleggen van een manier waarop het toestel door de gebruiker gedentificeerd kan worden.

3.3

Toewijzing van use-case scenario’s

Ten slotte geven we ter volledigheid een lijst van de use-cases, toegewezen aan de verschillende componenten. • Controller – De gebruiker traint zijn gestures (scenario 2.1.1) – De gebruiker maakt een beweging en die wordt herkend door de gesture recognizer (scenario 2.1.4) – De gebruiker logt met zijn persoonlijke beweging in via de controller (scenario 2.1.2) – Ontdekken van target services door de controller (scenario 2.2.1) – Koppelen van controller en gewenste target service (scenario 2.2.2) – Aansturen van een target service (scenario 2.2.3) • Trainer – De gebruiker traint zijn gestures (scenario 2.1.1) • Configuratie – De gebruiker traint zijn gestures (scenario 2.1.1) 4

Ookal is het in de praktijk mogelijk ze op dezelfde server te draaien als de trainer. Dit is echter een afweging

inzake deployment en is niet zozeer van invloed op de architectuur

3.3 Toewijzing van use-case scenario’s

32

– De gebruiker maakt, voor een bepaald toestel, een context-gevoelige afbeelding van gestures en acties (scenario 2.1.3) – Gebruiker herkennen en inloggen met behulp van zijn persoonlijke beweging (scenario 2.1.2) • Devices – De gebruiker maakt, voor een bepaald toestel, een context-gevoelige afbeelding van gestures en acties (scenario 2.1.3) – Ontdekken van target services door de controller (scenario 2.2.1) – Koppelen van controller en gewenste target service (scenario 2.2.2) – Aansturen van een target service (scenario 2.2.3) • Mapper – De gebruiker maakt, voor een bepaald toestel, een context-gevoelige afbeelding van gestures en acties (scenario 2.1.3) – Aansturen van een target service (scenario 2.2.3)

COMMUNICATIE

33

Hoofdstuk 4

Communicatie I can wire anything directly into anything - I’m the professor! Professor Farnsworth, Futurama

In Hoofdstuk 3, dat handelde over de architectuur, hebben we een uitgebreid overzicht gegeven van de verschillende componenten waaruit ons platform opgebouwd is. Om tot een werkbaar systeem te komen, moeten al deze gedefiniëerde componenten natuurlijk ook in staat zijn met mekaar te communiceren. In dit hoofdstuk beschrijven we het raamwerk dat de componenten gebruiken om met elkaar te communiceren. Herinner dat we in Hoofdstuk 3 van de veronderstelling uit gingen dat we in een perfecte wereld leven waar alle toestellen rechtstreeks met mekaar kunnen communiceren. Ook het uiteen zetten van de architectuur en dit hoofdstuk gebeurde onder deze aanname.

4.1

Nood aan een flexibel communicatiesysteem

In sectie 2.4, waar we de kwaliteitseisen van de applicatie besproken, hebben we modifiability ge¨ıdentificeerd als belangrijkste quality attribute. Deze quality attribute heeft enkele belangrijke consequenties voor het communicatieraamwerk. • Het ontwerp van het communicatieraamwerk moet protocol- en hardwareonafhankelijk zijn. Dit betekent dat wanneer er een component toegevoegd zou worden, die op een andere fysieke manier communiceert, het systeem makkelijk at development time hieraan aangepast moet kunnen worden. In de praktijk kan een dergelijke situatie zich voordoen wanneer we bijvoorbeeld in een netwerk, waar momenteel de communicatie gebeurt via Ethernet, een device toevoegen dat enkel kan communiceren via Bluetooth.1 . 1

Hierbij is het belangrijk op te merken dat de huidige devices in dat netwerk de mogelijkheid hebben om via

Bluetooth te communiceren maar dit gewoon nog niet deden. De situatie waarbij de huidige devices evenwel niet via Bluetooth kunnen communiceren wordt besproken in hoofdstuk 6

4.2 Ontwerp van de communicatiecomponent

34

• Toevoegen en verwijderen van devices die reeds compatibel zijn met het systeem moet mogelijk zijn at runtime, dus zonder dat andere componenten binnen het systeem hiervoor herstart moeten worden. Aan deze eis is echter automatisch voldaan wanneer correct gebruik gemaakt wordt van de Web service-standaarden zoals WSDiscovery en WSEventing.

4.2

Ontwerp van de communicatiecomponent

We hebben de communicatiecomponent ontworpen aan de hand van het microkernelpatroon [6]. We zullen eerst het microkernelpatroon zelf toelichten, het vervolgens toepassen op onze situatie en uiteindelijk verduidelijken hoe we de doelen die we gesteld hebben in sectie 4.1 bereiken aan de hand van het microkernelpatroon.

4.2.1

Het microkernelpatroon

De Microkernel is een architecturaal patroon dat van toepassing is op softwaresystemen die onderhevig zijn aan veranderlijke systeemeisen. Het scheidt een minimale functionele kern en specifieke onderdelen van mekaar [6]. Volgens [6] biedt het microkernelpatroon een oplossing in de volgende situaties: • Het applicatieplatform krijgt te maken met voortdurende hardware- en software-evolutie. • Het applicatieplatform moet overdraagbaar zijn en aanpasbaar om gemakkelijke integratie van nieuwe technologieën te ondersteunen. Zoals we besproken hebben in sectie 4.1 zijn beide eisen van toepassing op ons platform. Denk maar aan het toevoegen van nieuwe devices en het feit dat de communicatiecomponent moet werken op heel wat verschillende en heterogene apparaten (zoals devices, de controller of de mapper ). Het microkernelpatroon bestaat uit de volgende componenten [6]: • Microkernel : Implementeert atomaire diensten die we mechanismes noemen. Deze mechanismes dienen als een basis waarop meer complexe functionaliteit, de zogenaamde policies, wordt gebouwd. Verder voorziet de microkernel ook in de communicatiefaciliteiten en zorgt hij voor afscherming van hardwareafhankelijke delen. Een voorbeeld van een atomaire dienst kan een bericht versturen” zijn. ” • Internal Server : Bevat functionaliteit die niet in de microkernel geplaatst kan worden zonder diens grootte of complexiteit onnodig te vergroten. Ze kunnen, net zoals de microkernel, afhankelijkheden van de onderliggende hardware encapsuleren. Een goed voorbeeld hiervan zijn device drivers. Het moet mogelijk zijn deze internal servers at runtime in te laden wanneer dit vereist is en terug uit het geheugen te verwijderen wanneer ze niet meer nodig zijn. Internal servers kunnen dus gezien worden als uitbreidingen van de microkernel, en enkel de microkernel kunnen deze internal servers rechtstreeks aanspreken.


35

Figuur 4.1: Een theoretische voorstelling van het microkernelpatroon [6] • External Server : Implementeert zijn eigen policy aan de hand van de mechanismes die aangeboden worden door de microkernel en maakt daarvoor gebruik van de interfaces die de microkernel voorziet. • Client: Communiceert met de external servers op basis van de communicatievoorzieningen die aangeboden worden door de microkernel. • Adapter : Een optionele component die instaat voor een losse koppeling tussen client en external server. Een theoretische voorstelling van het microkernelpatroon is weergegeven in figuur 4.1.

4.2.2

Uitwerking

Al deze onderdelen, besproken in sectie 4.2.1, kunnen zonder probleem toegepast worden in ons communicatieraamwerk. • Kernel : In onze implementatie biedt de microkernel, zoals beschreven in het patroon [6], een set operaties aan die aangesproken kunnen worden door de external servers. Dit zullen voornamelijk operaties zijn die gebruikt kunnen worden voor het verzenden van berichten, zoals bijvoorbeeld een broadcast of een unicast. De kernel zal ook instaan voor het beheren van de instanties van de external servers en van de internal servers. Meer informatie over de kernel wordt gegeven in sectie 6.6.2.2. • Drivers: Dit zijn de internal servers van het patroon [6]. Iedere driver zorgt voor de ondersteuning van één fysiek communicatiekanaal. Meer informatie over de drivers wordt gegeven in sectie 6.6.2.1 .


36

Figuur 4.2: Het microkernelpatroon toegepast op onze situatie • Services: Dit zijn de external servers van het patroon [6] en aangezien external servers collecties van specifieke functionaliteit voorstellen, zijn dit bij ons groeperingen van functionaliteit die op semantisch vlak samen horen. Ze bevatten de algoritmes, logica en policies die gevolgd moeten worden voor discovery, eventing, pairing, overdracht van data en communicatie met de configuratiecomponent. Zo hebben we bijvoorbeeld een service voor berichten die te maken hebben met WS-Discovery, een service voor WS-Eventing-berichten, enzovoorts. Meer informatie over de services wordt gegeven in sectie 6.6.2.4 . • Client: De clients kunnen in ons platform eigenlijk gezien worden als de delen van het programma die gebruik maken van het communicatieframework. In de praktijk zal een client zich kunnen registreren bij een service om bepaalde berichten te ontvangen2 en zal een client gebruik kunnen maken van services om berichten te verzenden. Een client kan een instantie van een service opvragen aan de kernel. Meer informatie over de clients wordt gegeven in sectie 6.6.2.5 • Adapter : Wij hebben ervoor gekozen de adapter niet letterlijk te implementeren, maar op een andere manier te zorgen voor een losse koppeling tussen client en external server. Dit wordt later verder uitgelegd in sectie 6.6.2. Een schematische voorstelling van de manier waarop we het microkernelpatroon toegepast hebben, is weergegeven in figuur 4.2.

4.2.3

Gevolgen

Gebruik maken van het microkernelpatroon heeft enkele interessante gevolgen: • Aangezien we drivers implementeren als internal servers (en dus niet als een laag in de kernel), kunnen meerdere communicatiekanalen tegelijk actief zijn. 2

Let wel, dit heeft niks te maken met WS-Eventing maar is eerder een callback -mechanisme. De client registreert

zich bij een service en stelt via een interface één of meerdere methodes beschikbaar waarlangs berichten waarvoor hij zich geregistreerd heeft kunnen doorgegeven worden. Dit is analoog aan de werking van het MVC patroon.


37

• Drivers zijn gemakkelijk at runtime in en uit te schakelen. • Hoewel alle onderdelen die gemeenschappelijk zijn identiek zijn, kan de samenstelling van de communicatiecomponent verschillen naargelang de fysieke plaats waar hij actief is. Zo zal bijvoorbeeld de communicatiecomponent op een SunSPOT geen driver voor Bluetooth nodig hebben. Het gebruik van het microkernelpatroon vergemakkelijkt het nastreven van deze eisen, aangezien het makkelijk is internal servers en external servers toe te voegen of te verwijderen. • Ook clients kunnen makkelijk toegevoegd of verwijderd worden. Dit betekent dat het een kleine moeite is om bepaalde toestellen of functionaliteit aan het systeem te koppelen. We kunnen dus besluiten dat aand de eis van protocol- en hardwareonafhankelijkheid, vermeld in sectie 4.1, voldaan is.

GESTURE RECOGNITION

38

Hoofdstuk 5

Gesture Recognition For God’s sake, shake me. Shake me like a British nanny. Stewie Griffin, Family Guy

Een volgende groot onderdeel van onze thesis is het herkennen van bewegingen, of beter gezegd, herkennen van gebaren die gemaakt worden door een gebruiker. Gesture recognition kan gebeuren op verscheidene manieren. Ten eerste kan men gebruik maken van één of meerdere camera’s die de bewegingen van een gebruiker detecteren. Een andere aanpak is gebruik maken van sensoren. Enkele voorbeelden van deze technieken zijn: • Motion capture: Een techniek die gekend is van de film- en gamingindustrie en die vooral gebruikt wordt bij het animeren van computergegenereerde karakters. Eén van de vele manieren om aan motion capture te doen is op het lichaam verscheidene leds plaatsen en deze volgen met camera’s. [10] • Elektronische componenten: Bewegingen kunnen geregistreerd worden door middel van een aantal elektronische componenten zoals een accelerometer en/of een gyroscoop. De data die deze component produceert kan vervolgens gebruikt worden voor het herkennen van patronen die dan gekoppeld kunnen worden aan bepaalde gebaren. Een bekend en actueel voorbeeld hiervan is de besturing van een Nintendo Wii spelconsole. • Muscle-sensing: Met behulp van sensoren op bijvoorbeeld de bovenarm wordt een Elektromyografie (EMG) uitgevoerd om de spieractiviteit te meten. Uit variaties in de spieractiviteit en het herkennen van patronen kunnen vervolgens bewegingen afgeleid worden. [11] De bovengenoemde technieken zijn slechts enkele voorbeelden van gesture recognition die we tegengekomen zijn tijdens ons onderzoek en ons vermeldens waard leken omdat ze zo vaak voorkwamen of omdat we ze origineel vonden.

5.1 Gesture recognition met behulp van een accelerometer

39

Figuur 5.1: De 3 assen van de accelerometer aangeduid op een SunSPOT [14]

Ons voornemen is het gebruiken van een SunSPOT als voorbeeld voor een afstandsbediening van een domoticasysteem. Zoals eerder vermeld in sectie 1.2, bevat een SunSPOT een accelerometer, een elektronische component die gebruikt kan worden voor het herkennen van gebaren. We zullen in eerste instantie onderzoek doen naar gesture recognition met behulp van een accelerometer. Bovendien zullen we onderzoeken of het mogelijk is om de berekeningen die nodig zijn om een beweging te herkennen, uit te voeren op de SunSPOT zelf. We zullen deze situatie vergelijken met het doorsturen van de data naar een server, om vervolgens daar de gesture recognition te doen.

5.1 5.1.1

Gesture recognition met behulp van een accelerometer Karakterisatie van de input data

De accelerometer van de SunSPOT wordt aan een vaste frequentie ν bevraagd (oftewel gesampled ), een parameter waar we later dieper op in zullen gaan. Voorlopig kunnen we onze gedachten vestigen op een frequentie van ν = 25 Hz, een waarde die ook naar voren geschoven wordt in [12] en [13]. Iedere sample σt , genomen op tijdstip t, wordt voorgesteld door een een 3-dimensionele vector met xt -, yt - en zt -componenten die de gemeten versnelling voorstellen volgens de respectivelijke assen (zoals gevisualiseerd op figuur 5.1):   xt    σ t =  yt   zt

(5.1)

Eén enkele beweging kan dus voorgesteld worden door een reeks van samples, d.i. een reeks van vectoren. Een dergelijke reeks kan gezien worden als een instantie van een bepaalde beweging. Om die reden hebben we dit dan ook een gesture instance genoemd. Een instantie I bestaande uit n samples kan dus als volgt voorgesteld worden: I = σ0 , σ1 , σ2 , · · · , σn−1

(5.2)


Gesture Instance

Sample

x x x x

y y y y

40

z z z z

x x x x

y y y y

z z z z

x x x x

y y y y

z z z z

...

x x x x

y y y y

z z z z

...

...

...

... x

y

z

x

y

z

x

y

z

x

y

z

x x x x

y y y y

z z z z

x x x x

y y y y

z z z z

x x x x

y y y y

z z z z

x x x x

y y y y

z z z z

Gesture

...

z

x

y

z

x

y

x x x x

y y y y

z z z z

x x x x

y y y y

z z z z

x x x x

y y y y

z

x

z

x

z

x

y

z

z z z z

x x x x

y y y y

z z z z

...

y

...

...

...

... x

y

...

y

...

y

...

... x

...

z

x

y

z

Figuur 5.2: Organisatie van de input data Zoals we later zullen vermelden (in sectie 5.1.2.1), zal het noodzakelijk zijn om van ieder type beweging (gesture) G verschillende instanties (gesture instances) I op te slaan. We hebben ervoor gekozen de data hiervan op te slaan in een databank in XML-formaat. De structuur hiervan hebben we vastgelegd in een XML Schema (zie listing 5.1). Ter verduidelijking hiervan hebben we ook een visuele voorstelling gemaakt van de organisatie van deze data (in figuur 5.2).

5.1.2

Leren en herkennen van bewegingen met behulp van Hidden Markov Models

Onze bedoeling is op basis van de ruwe input data (de samples) van een gesture instance te kunnen beslissen tot welk type gesture deze gesture instance behoort. Dit probleem willen we oplossen met behulp van patroonherkenning. Patroonherkenning kan gedefinieerd worden als ontvangen ” van ruwe data en vervolgens bepalen tot welke categorie deze data behoort” [15], wat ook ons doel is. De herkenner maakt een beslissing op basis van kennis die hij reeds bezit. Deze kennis kan a priori aanwezig zijn, of deze kennis kan op een eerder tijdstip aangeleerd zijn. Wij zullen uitgaan


< xs:schema xmlns:xs =" http: // www . w3 . org /2001/ XMLSchema " targetNa me sp a ce =" thesis3DInput " xmlns =" thesis3DInput " e le me n t F o r m D e f a u l t =" qualified " >

< xs:element name =" GestureXML " > < xs:compl exType > < xs:sequence > < xs:element name =" Gestures " maxOccurs ="1" > < xs:comp lexType > < xs:sequence > < xs:element name =" Gesture " type =" GestureType " maxOccurs =" unbounded "/ >

< xs:element name =" GestureType " > < xs:compl exType > < xs:sequence > < xs:element name =" Instance " type =" InstanceType " maxOccurs =" unbounded "/ > < xs:attribute name =" type " type =" xs:string " use =" required "/ >

< xs:element name =" InstanceType " > < xs:compl exType > < xs:sequence > < xs:element name =" Sample " type =" SampleType " maxOccurs =" unbounded "/ >

< xs:element name =" SampleType " > < xs:compl exType > < xs:sequence > < xs:element name =" x " type =" xs:decimal "/ > < xs:element name =" y " type =" xs:decimal "/ > < xs:element name =" z " type =" xs:decimal "/ >

Listing 5.1: XML Schema voor input data

41


42

van de laatstgenoemde situatie, omdat dit in onze toepassing, met input data van relatief hoge complexiteit, een natuurlijkere aanpak is. We kunnen dus twee fasen onderscheiden: de trainingsfase en de herkenningsfase. In de trainingsfase wordt een interne toestand opgebouwd door middel van een aantal gesture instances van ieder type gesture. Tijdens de herkenningsfase wordt een geregistreerde beweging getoetst aan de interne toestand en wordt berekend met welk type gesture de nieuwe geregistreerde beweging met de grootste waarschijnlijkheid overeenkomt. Er zijn in de literatuur verscheidene manieren besproken om bewegingen te herkennen met behulp van patroonherkenning. Zo wordt bijvoorbeeld de ene keer een uitgebreide preprocessing toegepast op de input data alvorens deze te gebruiken, terwijl andere papers stellen dat de input data in het ruwe formaat geschikt is. Ook de wiskundige modellen die intern gebruikt worden verschillen enorm. Enkele voorbeelden hiervan zijn Hidden Makrov Model (HMM)s, Support Vector Machine (SVM)s, neurale netwerken en Bayesiaanse netwerken. Het is geenszins onze bedoeling om al deze verschillende technieken te proberen en de meest optimale te vinden, maar eerder om een proof of concept” van gesture recognition op de SunSPOT de ontwikkelen. We zullen de ” volledige applicatie wel ontwikkelen op een zo modulair mogelijke manier, zodat eventueel later op een relatief makkelijke wijze van aanpak veranderd kan worden. Aangezien we gemerkt hebben dat HMMs op zeer regelmatige basis terugkomen in de literatuur en er dus heel wat documentatie over te vinden is, hebben we voor deze aanpak gekozen. Bovendien is het aangetoond dat een implementatie van de herkenningsfase van gesture recognition met behulp HMMs in real-time kan functioneren op een mobiel toestel [12]. Ook is er een uitgebreide bibliotheek beschikbaar voor het programmeren van HMMs in Java, namelijk Jahmm [16]. In de volgende twee secties zullen we in het kort een algemeen overzicht geven van de trainingsen de herkenningsfase. Het is echter niet de bedoeling om tot in het kleinste detail uit te leggen hoe HMMs werken. Daarvoor verwijzen we de lezer naar een zelfstudiecursus over HMMs, ge¨ıllustreerd met een toepassing in de spraakherkenning [17]. 5.1.2.1

Trainingsfase

Tijdens de trainingsfase wordt voor iedere type gesture een aantal gesture instances gebruikt om een HMM te trainen. Voor ieder type gesture is er dus één HMM. Tijdens de herkenningsfase (zie sectie 5.1.2.2) moet de geregistreerde beweging getoetst worden aan alle HMMs. Een HMM kan gekarakteriseerd worden door de volgende parameters: • Het aantal interne toestanden, N . • Initiële probabiliteiten Πi voor iedere toestand i. • Transitieprobabiliteiten Ai,j tussen iedere 2 toestanden i en j. Deze transitieprobabiliteiten


43

kunnen dus voorgesteld worden als een N × N matrix T : 

A0,0

A0,1

A0,2

...

A0,N −2

A0,N −1



   A1,0 A1,1 A1,2 ... A1,N −2 A1,N −1      A2,1 A2,2 ... A2,N −2 A2,N −1   A2,0   T = . .. .. .. .. ..   ..  . . . . .   A   N −2,0 AN −2,1 AN −2,2 ... AN −2,N −2 AN −2,N −1 

(5.3)

AN −1,0 AN −1,1 AN −1,2 ... AN −1,N −2 AN −1,N −1 • De gebruikte Observation Probability Distribution Function (OPDF) die een probabiliteitsfunctie of een probabiliteitsdistributie van observaties representeert in Jahmm. We gaan verder hier niet in op de specifieke functionaliteiten van een OPDF. Daarvoor verwijzen we naar de documentatie over Jahmm [18]. De globale structuur van een herkenningssysteem met behulp van HMMs bestaat dus uit een verzameling van getrainde HMMs (λ0 , λ1 , λ2 , · · · , λM −1 ) waarbij λi een getrainde HMM voorstelt voor gesture type Gi en M het aantal verschillende types Gesture [7]. We maken gebruik van een left-to-right HMM, een keuze die vaak genomen wordt bij het modelleren van tijdsreeksen wiens eigenschappen sequentieel wijzigen in de tijd [7]. Bij een left-to-right HMM is de transitieprobabiliteit Ai,j = 0 indien j < i of indien j > (i + 1). Met andere woorden, er zijn enkel transities mogelijk naar de eigen of naar de volgende toestand. Een voorbeeld hiervan is ge¨ıllustreerd in figuur 5.3 Bijgevolg kunnen we de uitdrukking van de transitieprobabiliteiten in (5.3) voor een left-to-right HMM vereenvoudigen tot:

 A0,0 A0,1 0   0 A1,1 A1,2   0 A2,2  0 T = .. ..  ..  . . .   0 0 0  0 0 0

...

0

...

0

... .. .

0 .. .

... AN −2,N −2 ...

0

0



    0   ..   .  AN −2,N −1   1 0

Figuur 5.3: Een left-to-right HMM met 5 toestanden

(5.4)


44

Voordat de training start, moeten we initiële waarden kiezen voor alle probabiliteiten. Dit doen we op de meest eenvoudige manier, namelijk door de probabiliteiten uniform te verdelen:

Πi = 1/N, ∀i ∈ [0, N − 1]    0.5, ∀(i, j) ∈ [0, N − 1]2 ∧ i = j − 1     0.5, ∀(i, j) ∈ [0, N − 1]2 ∧ i = j 6= N − 1 Ai,j =  1, ∀(i, j) ∈ [0, N − 1]2 ∧ i = j = N − 1      0, otherwise

(5.5)

(5.6)

(5.7) De verschillende HMMs worden getraind door middel van het Baum-Welch algoritme, dat ge¨ıntroduceerd werd in [19]. Dit is een iteratief algoritme met als doel een schatting te maken van de parameters van een HMM, uitgaande van een eindige sequentie van trainingsdata. Het BaumWelch algoritme bepaalt geen globaal, maar een lokaal optimum [17]. De uitkomst ervan is dus niet gegarandeerd optimaal, wel werkbaar. Het aantal iteraties van Baum-Welch die uitgevoerd worden, is een parameter die de accuraatheid kan be¨ınvloeden. Het is echter ook belangrijk het aantal iteraties van het trainingsalgoritme niet te hoog op te drijven, aangezien dit kan leiden tot overfitting, waar de accuraatheid van de herkenning onder kan lijden. [7] Aangezien de trainingsfase in theorie slechts één keer moet worden uitgevoerd, en dus geen effect heeft op het real-time karakter van de applicatie, maar toch zeer rekenintensief is [8], wordt deze best uitgevoerd op een krachtige machine en niet op de SunSPOT. 5.1.2.2

Herkenningsfase

De input data voor de herkenningsfase is een geregistreerde beweging, met andere woorden een gesture instance waarvan onbekend is tot welk type gesture deze instantie behoort. Het doel van de herkenningsfase is dus dit type gesture met een zo hoog mogelijke waarschijnlijkheid af te leiden. De herkenning zelf gebeurt aan de hand van het Viterbi -algoritme. [20] Het Viterbi -algoritme berekent de probabiliteit dat een reeks van observaties (d.i. in ons geval een gesture instance) gegenereerd zou kunnen worden door een bepaalde HMM. Herinner dat we in de trainingsfase voor ieder type gesture een HMM opgebouwd hebben. Nu zullen we dus, met behulp van het Viterbi -algoritme, een geregistreerde beweging (waarvoor het type gesture bepaald moet worden) toetsen aan iedere HMM. De HMM waarvoor we de hoogste probabiliteit meten tijdens de herkenningsfase, zal het type gesture bepalen. Een andere mogelijke aanpak kan het Forward-Backward -algoritme [21] zijn dat ook voorkomt in de literatuur en dezelfde probabiliteiten aflevert [12]. In principe is het mogelijk om de herkenningsfase op één van twee mogelijke plaatsen in ons systeem uit te voeren: op een rekenserver of op de SunSPOT zelf. Het voordeel van het uitvoeren

5.2 Verhogen van de accuraatheid

45

van de herkenningsfase op een rekenserver is dat we heel wat meer rekenkracht ter beschikking hebben, terwijl een nadeel kan zijn dat het verzenden van de input data van de accelerometer naar de server heel wat tijd in beslag kan nemen. Bij het uitvoeren op de SunSPOT is de rekenkracht dan weer beperkt maar de input data moet niet meer verzonden worden naar de server. Om een zicht te krijgen op dit dilemma hebben we klein programma geschreven voor de SunSPOT dat de input data rechtstreeks doorstuurt naar een toepassing op een PC. We hebben geconstateerd dat het doorsturen van een relatief complexe beweging toch al vlug een aanzienlijke tijd in beslag neemt die nefast zou zijn voor het real-time karakter van onze applicatie. Zo hebben we bijvoorbeeld een cirkel als beweging opgenomen aan een frequentie van 25 Hz, wat resulteerde in ongeveer 5500 bytes aan data wanneer deze gestructureerd werd zoals beschreven in listing 5.1. Het doorsturen van deze hoeveelheid data met de SunSPOT over het Zigbee-protocol duurt ongeveer 2,5 seconden. We zullen later (in sectie 6.7.1) verder ingaan op meer uitgebreide metingen hieromtrent, maar het valt nu al in te zien dat het sturen van één gesture instance ongeveer 1 ` a3 seconden zal duren, afhankelijk van de duurtijd van de beweging. Een dergelijk grote vertraging, die telkens zou optreden wanneer een toestel aangestuurd wordt, is onaanvaardbaar. Een tweede probleem is dat het draadloos verzenden van grote hoeveelheden data de batterijduur zeer nadelig be¨ınvloedt [22]. Indien we een werkbare implementatie willen ontwikkelen, zullen we dus alles in het werk moeten stellen om de herkenning uit te voeren op de SunSPOT, aan een voldoende hoge snelheid en met een aanvaardbare accuraatheid. Nu moet er nog een laatste keuze gemaakt worden met betrekking tot de herkenning, namelijk of de herkenning op een continue manier zal gebeuren of op een gesegmenteerde manier. Met andere woorden, wordt de accelerometer constant bevraagd om bewegingen te registreren en te herkennen of moet de gebruiker op een knop drukken om het begin van een beweging aan te duiden en de knop terug loslaten om het einde aan te duiden. De eerste keuze heeft als grootste voordeel dat er geen knop ingedrukt hoeft te worden. De twee nadelen hierbij zijn net de continue bevraging van de accelerometer en het feit dat bewegingen nu niet enkel herkend moeten worden maar ook gedetecteerd moeten worden in een continue stroom van samples. Beide zorgen voor een hoger energieverbruik, iets wat vermeden moet worden. Daarom wordt er verder gebruik gemaakt van een gesegmenteerde herkenning.

5.2

Verhogen van de accuraatheid

Volgens [13] is de input data in zijn ruw formaat (dit zijn dus samples) geschikt, mits een algoritme ge¨ımplementeerd wordt om het effect van tilting 1 te minimaliseren (voor meer uitleg hierover, zie 5.2.1). Ook [12] maakt deze opmerking, en vermeldt dat dit zelfs geldt voor mobiele toestellen. Met onze implementatie zijn we echter tot de constatatie gekomen dat deze redenering in ons geval niet helemaal opgaat. In onze experimenten kwamen we, zonder implementatie van extra algoritmes, uit op een gemiddelde accuraatheid van ongeveer 75%. 1

Dit is de term die in de literatuur gebruikt wordt om kantelen” aan te duiden. ”


46

We zijn dus op zoek moeten gaan naar algoritmes om de accuraatheid te verhogen. Deze verschillende algoritmes hebben we vervolgens ge¨ımplementeerd om hun effect te bestuderen en worden hier besproken. De eerste drie zijn filters en die zijn van toepassing op zowel de trainingsfase als de herkenningsfase. Het toevoegen van noise wordt enkel gebruikt in de trainingsfase.

5.2.1

Effect van tilting minimaliseren

Een accelerometer meet de versnelling volgens drie assen. Deze versnelling wordt in het geval van de SunSPOT uitgedrukt in g, waarbij g gelijk is aan de valversnelling op aarde (9.81 sm2 ). Wanneer de SunSPOT volledig vlak en stil ligt, verwachten we een theoretische waarde van 0 op de x- en de y-as en een waarde van 1 op de z-as. Deze waarde van 1 op de z-as valt te verklaren als de versnelling van de zwaartekracht, die volgens de z-as gericht is en 1 g bedraagt. Wanneer een bepaalde beweging meerdere keren uitgevoerd wordt, maar telkens met de SunSPOT licht verschillend gekanteld, kan dit voor wijzigingen zorgen die de accuraatheid negatief be¨ınvloeden. De reden hiervoor is dat de zwaartekracht niet meer enkel en volledig van toepassing is op de z-as. In figuur 5.4 wordt dit gevisualiseerd.

(a)

(b)

Figuur 5.4: Effect van tilting op de verdeling van de assen van de accelerometer. Figuur (a) toont de standaardsituatie, bij figuur (b) werd de SunSPOT licht gekanteld volgens de x-as. Het effect van de zwaartekracht op de assen werd aangeduid in het rood. Om het effect hiervan te minimaliseren hebben we een algoritme ge¨ımplementeerd dat uitvoerig besproken wordt in [13]. Het doel van dit algortime is een transformatie bepalen die op een gesture instance kan worden toegepast zodat het resultaat ervan de situatie, waarbij de zwaartekracht volledig in de richting van de z-as ligt, dichter benadert.

5.2.2

Idle-state filter

Het doel van de idle-state filter is samples van een gesture instance die bijna geen beweging voorstellen (d.i. kort bij [x = 0, y = 0, z = 1] liggen) te verwijderen. Meestal zullen deze betekenisloze samples zich bevinden aan het begin en aan het eind van een instance omwille van het te vroeg indrukken en het te laat loslaten van de knop. Het resultaat van deze filter is bijgevolg een gesture instance die enkel uit beweging bestaat en geen kleine rustpauzes aan het begin en aan het einde


47

bevat. De essentie van de beweging blijft dus over, samples die er geen deel van uitmaken worden verwijderd. Dit zorgt voor een grotere accuraatheid want eventuele ruis en onzuiverheden die in wezen niks met de beweging zelf te maken hebben, worden weggeknipt. Verder heeft deze filter ook een positief effect op de rekentijd, die lineair is in het aantal samples. De implementatie kan als volgt gebeuren. We nemen één sample σ. Van de z-waarde van σ trekken we 1 af:

  0   0  σ =σ− 0 1

(5.8)

Dit omdat wanneer de SunSPOT stil ligt de waarde van de accelerometer op de z-as gelijk is aan 1, zoals beschreven in 5.2.1. Daarna wordt de absolute waarde van σ 0 berekend: 0 q σ = σx02 + σy02 + σz02

(5.9)

Indien |σ 0 | kleiner is dan s wordt σ verwijderd uit de gesture instance. Hierbij is s de gevoeligheid van de filter. Hoe hoger s, hoe vlugger een sample verwijderd zal worden. In [23] werd een zeer gelijkaardige filter ge¨ımplementeerd en werd de waarde van s vastgelegd op 0,1 en goed werkend bevonden. Ook wij hebben bijgevolg gebruik gemaakt van deze waarde voor de parameter s.

5.2.3

Directional-equivalence filter

Het doel van deze filter is om samples die te veel op elkaar lijken te verwijderen. Op die manier verwijderen we redundante informatie die mogelijks opnieuw kleine hoeveelheden ongewenste ruis bevat. Verder levert deze filter ook prestatiewinst aangezien hij, net als de idle-state filter, het totaal aantal samples verkleint. Deze filter kan heel eenvoudig als volgt ge¨ımplementeerd worden. De filter zal een sample componentsgewijs vergelijken met de vorige sample. Als het verschil in 1 van de componenten van beide samples groter is dan s, dan blijft deze sample in de gesture instance, zoniet dan wordt hij verwijderd. Hierbij is s opnieuw de gevoeligheid. Hoe groter s, hoe meer de samples moeten verschillen om niet verwijderd te worden. Deze filter werd ook ge¨ımplementeerd in [23] en de waarde van s werd vastgelegd op 0,2 en goed werkend bevonden. Bijgevolg hebben ook wij deze filter ingesteld met dezelfde gevoeligheid s.

5.2.4

Toevoegen van noise

Een techniek die vaak toegepast wordt tijdens de trainingsfase, onder andere in [24], is naast originele gesture instances ook artificiëel gegenereerde instances te gebruiken. De bedoeling is dat deze instances licht afwijken van de originelen, en wij zullen ze dan ook noise instances noemen, wat de gangbare term hiervoor is in de literatuur. Het gebruik van noise (ruis) om de accuraatheid te verhogen is een techniek die al geruime tijd gekend is en uitgelegd wordt in [25]. Een dergelijke noise instance kan op een eenvoudige manier bekomen worden uit een originele gesture instance.

5.3 Verhogen van de performantie

48

Zoals vermeld in (5.2) kunnen we een originele gesture instance als volgt voorstellen: Iorig = σ0 , σ1 , σ2 , · · · , σn−1

(5.10)

Voor de nieuwe noise instance gebruiken we hetzelfde aantal samples als in de originele gesture instance. De noise instance kan als volgt voorgesteld worden: 0 Inoise = σ00 , σ10 , σ20 , · · · , σn−1

(5.11)

Iedere σi0 uit de noise instance wordt berekend uit σi van de originele gesture instance. σi0 = σi + ρ

(5.12)

ρ is een driedimensionele vector die de toegevoegde noise voorstelt en die voor iedere σi0 willekeurig gegenereerd wordt. Uitgebreider kan bovenstaande uitdrukking als volgt geschreven worden:     x0i xi + ρ1      y 0  =  yi + ρ2  (5.13) i     zi + ρ3 zi0 Een dergelijke ρj hebben we als volgt gedefiniëerd: ρj =

(Rj ∗ 2a) − a s

(5.14)

Waarbij Rj een willekeurig getal voorstelt tussen 0 en 1, a de grenzen van het interval [−a, a] waarop Rj gemapt moet worden en s een parameter die de sterkte van de noise weergeeft2 . Het interval [−a, a] kan gezien worden als het bereik van mogelijke waarden van de accelerometer, in ons geval dus [−2, 2]3 . Het toevoegen van noise wordt toegepast na de drie eerder besproken filters.

5.2.5

Besluit

Uit metingen, die later uitgebreid beschreven zullen worden in sectie 5.5, is het duidelijk dat het toepassen van de zonet beschreven filters en het toevoegen van noise een positief effect heeft op de accuraatheid. Zelfs de eerste meting waar deze algoritmen gebruikt worden en die uitgevoerd wordt met geschatte waarden voor de verschillende parameters geraakt al vlot boven de 80% tot 85% correct herkende bewegingen, terwijl dit eerder nog maar 75% was.

5.3

Verhogen van de performantie

Aangezien onze bewegingsherkenning moet dienen als aansturing van een domoticasysteem, is naast accuraatheid ook performantie een factor waar rekening mee gehouden moet worden. Het is immers niet aanvaardbaar dat een gebruiker na elke beweging enkele seconden zou moeten wachten alvorens het aangestuurde toestel hierop reageert. 2

In dit geval kan s eigenlijk gezien worden als een voorstelling van de Signal-to-noise ratio (SNR). In sectie 5.5

zullen we een goede waarde hiervoor bepalen. 3 want de accelerometer van de SunSPOT heeft een gevoeligheid van ±2 g


5.3.1

49

Performantie van de SunSPOT

Eén van de doelstellingen van deze thesis is onderzoeken of gesture recognition, en dan specifiek de herkenningsfase, op een SunSPOT ge¨ımplementeerd kan worden. In sectie 5.1.2.2 hebben we reeds aangewezen dat een implementatie waarbij de herkenningsfase uitgevoerd wordt op een server niet optimaal is wegens vertragingen en de impact op de batterijduur omwille het verzenden van grote hoeveelheden data. Een implementatie op de SunSPOT zelf lijkt bijgevolg de enige aanvaardbare oplossing, en geniet ook onze voorkeur. We hebben vervolgens een prototype implementatie van de herkenningfase ontwikkeld. Uitvoerige testen wijzen uit dat een beweging herkend wordt in 5 tot 10 ms. Deze testen zijn uitgevoerd op een laptop4 . Rekening houdend met het feit dat de SunSPOT een processor heeft van 180 Mhz en als we de uitvoeringstijd normaliseren naar de snelheid van de processor van de SunSPOT, vermoeden we een herkenningstijd die in de buurt van de 100ms zal liggen. Dit is aanvaardbaar voor real-time toepassingen [26]. Bovendien liggen onze resultaten in dezelfde lijn als die uit het onderzoek in [12]. Toen we echter dit prototype poortten naar de SunSPOT 5 bleek de snelheid veel lager uit te vallen. Een complexe

6

beweging herkennen, wat op de laptop ongeveer 10 ms in beslag nam,

duurde al gauw 3 tot 4 seconden, wat een onwerkbare vertraging is. De deductie die zowel wij als [12] maakten, bleek dus niet op te gaan voor de SunSPOT. Om de oorzaak hiervan te vinden hebben we onze applicatie geprofileerd. Hieruit bleek dat veruit het grootste gedeelte van de rekentijd gespendeerd werd aan matrixvermenigvuldigingen die noodzakelijk zijn voor het Viterbi -algoritme. Meteen merkten we dat het aantal matrixvermenigvuldigingen lineair is met het aantal toestanden dat gekozen wordt in het HMM (d.i. de parameter N , besproken in sectie 5.1.2.1) . Het aantal toestanden reduceren had al een positief effect (zonder ten koste te gaan van de accuraatheid, zie figuur 5.5), maar de snelheidswinst was nog niet voldoende. Een complexe beweging werd nu in 1 tot 2 seconden herkend. Bovendien verklaarde dit ook de reden nog niet waarom het u ¨berhaupt zo traag ging. Vervolgens zochten we naar benchmarks van de SunSPOT en daar merkten we dat de SunSPOT ongeveer 1,6 miljoen vermenigvuldigingen van gehele getallen kan uitvoeren per seconde, wat een te verwachten prestatie is voor een processor van 180 Mhz. Uit de benchmarks bleek echter dat de SunSPOT slechts 500 000 vermenigvuldigingen van floating point-getallen in dezelfde tijdspanne kan uitvoeren [27]. Bij benchmarks met oudere versies van de SunSPOT -firmware, haalde men zelfs slechts 200 000 floating point-vermeningvuldigingen per seconde [28]. Ook de matrixvermenigvuldigingen die wij uitvoeren bestaan volledig uit floating point-vermeningvuldigingen. Dit gegeven verklaart natuurlijk volledig de vertraging. Deze matrixvermenigvuldigingen zijn nodig omdat we met driedimensionele vectoren werken als ingangsdata. Aangezien we met probabiliteiten rekenen, is het niet mogelijk om de floating4

Intel Core2 Duo P8400, 2.26Ghz met 3 GiB RAM meer informatie over dit proces is terug te vinden in sectie 5.4 6 dus een langdurige 5


50

pointbewerkingen op zich te vermijden. We kunnen dus concluderen dat, of we nu de berekening op de SunSPOT maken, of we sturen de data door naar een server, in beide gevallen zal de input data drastisch vereenvoudigd moeten worden om de implementatie bruikbaar te maken. En dit bovendien liefst met een zo klein mogelijke impact op de accuraatheid.

5.3.2

K-means clustering

Wij hebben ervoor gekozen om de input data te vereenvoudigen door er k-means clustering, wat besproken werd in [29], op toe te passen. Dit is een methode met als doel een reeks van n observaties7 te partitioneren in k clusters. De bedoeling van het algoritme is de objectieffunctie J te minimaliseren:

J=

k X n

2 X

(j)

σi − cj

(5.15)

j=0 i=0 (j)

waarbij σi

een sample voorstelt die toegewezen is aan cluster j en cj de centro¨ıde voorstelt van

cluster j. Minimaliseren van J komt dus neer op het minimaliseren van de afstand van iedere sample tot de centro¨ıde van de cluster waaraan de sample is toegewezen. De manier waarop wij het algoritme ge¨ımplementeerd hebben, kan als volgt beschreven worden: 1:

Schat een beginwaarde voor de centro¨ıden van alle clusters.

2:

iterate()

3:

while ((Laatste iteratie wijzigde de clusters) and (Totaal aantal iteraties < 50)) do

4:

iterate()

5:

end while De methode iterate() stelt 1 iteratie voor van het k-means clustering algoritme en kan in pseu-

docode als volgt voorgesteld worden: 1: 2:

for all sample σ in de gebruikte samples in de trainingsfase do bereken dichtsbijzijnde cluster voor σ

3:

end for

4:

for all cluster C do

5: 6:

bereken de centro¨ıde van C end for De toevoeging van k-means clustering zorgde in onze prototype implementatie al voor een

enorme tijdswinst. Om een indicatie te hebben van de snelheidswinst hebben we een testopstelling opgezet waarbij de accelerometer gesampled werd aan 40 Hz en geen van de algoritmes besproken in sectie 5.2 om te accuraatheid te verhogen, geactiveerd werd. Vervolgens werd op een laptop8 7

in ons geval de unie van alle samples van alle gesture instances die gebruikt worden tijdens de trainingsfase,

oftewel een reeks van n samples 8 Intel Core2 Duo P8400, 2.26Ghz met 3 GiB RAM


51

Figuur 5.5: Effect van het gebruik van k-means clustering op de performantie. De tijd om 40 gesture instances te herkennen in functie van het aantal toestanden in het HMM. de tijd gemeten om 40 gesture instances te herkennen in functie van het aantal toestanden in het HMM. Het resultaat van de tijdsmetingen is samengevat in figuur 5.5, wat dus een mooi zicht geeft op de performantiewinst bij het gebruik van k-means clustering. Bovendien zijn de metingen gebeurd op een laptop met een processor die wel geoptimaliseerd is voor floating pointbewerkingen, in tegenstelling tot de SunSPOT. Op de SunSPOT verwachten we dus in verhouding een nog grotere versnelling. Omdat snelheidswinst zinloos is wanneer we accuraatheid zouden verliezen, hebben we ook gecontroleerd hoeveel van de 40 bewegingen in beide situaties (met of zonder k-means clustering) correct herkend werden, opnieuw in functie van het aantal toestanden in de HMM. Het resultaat hiervan valt te bekijken in figuur 5.6. We merken op dat k-means clustering de accuraatheid niet nadelig be¨ınvloed. Integendeel zelfs, in dit kleinschalig experiment is de accuraatheid zelfs hoger wanneer k-means clustering toegepast wordt. We merken ook op dat in dit geval het aantal toestanden in de HMM geen spectaculaire invloed heeft op de accuraatheid, maar deze parameter zullen we later uitvoerig bespreken in sectie 5.5.3.5. Op het eerste zicht lijkt het misschien dat de accuraatheid in het algemeen onaanvaardbaar laag is (aangezien het zich voornamelijk situeert tussen 25 en 30 correct herkende bewegingen op 40). Het is hierbij wel belangrijk op te merken dat we geen van de algoritmes besproken in 5.2 geactiveerd hebben voor deze test. Uitgebreidere testen waarbij deze algoritmes wel werden geactiveerd, zijn terug te vinden in sectie 5.5.


52

Figuur 5.6: Effect van het gebruik van k-means clustering op de accuraatheid. Het aantal correct herkende gesture instances van 40 herkenningen in functie van het aantal toestanden in het HMM.

5.3.3

Noise in combinatie met k-means clustering

Gebruik maken van k-means clustering heeft wel een belangrijk gevolg. De implementatie van ruis zoals we deze besproken hebben in 5.2.4, is namelijk niet meer bruikbaar in combinatie met k-means clustering. De reden hiervoor valt makkelijk intu¨ıtief aan te voelen. Een kleine wijziging in de samples van een noise instance zal er immers voor zorgen dat het merendeel van deze samples wordt afgebeeld op dezelfde cluster als de overeenkomstige sample in de originele instantie. Het is dus noodzakelijk ruis op een andere manier te implementeren zodat noise gebruikt kan worden in samenwerking met k-means clustering. We hebben bijgevolg zelf een eenvoudig algoritme berekend om een noise instance Inoise te berekenen op basis van een originele gesture instance Iorig . Het basisidee van ons algoritme is eigenlijk iedere sample verplaatsen naar zijn meest nabije buurcluster, met een kans die afhankelijk is van de afstand tot die buurcluster. Net zoals in sectie 5.2.4 gaan we ervan uit dat R een willekeurig getal voorstelt tussen 0 en 1 en dat s een parameter is die de sterkte van de noise weergeeft en dus eigenlijk een voorstelling is van de SNR. 1:

for all sample σi in Iorig do

2:

Cown = cluster waar σi toe behoort

3:

Cclosest = dichtsbijzijnde cluster voor σi , uitgezonderd Cown

4:

down = afstand tot centro¨ıde van Cown

5:

dclosest = afstand tot centro¨ıde van Cclosest

6:

ratio = down /dclosest

7:

prob = ratio/s

5.4 Implementatie

if R < prob then

8:

ken σi0 in Inoise to aan Cclosest

9:

else

10:

ken σi0 in Inoise to aan Cown

11:

end if

12: 13:

53

end for

5.4

Implementatie

Zoals reeds eerder vermeld is het ook de bedoeling een prototype implementatie te ontwikkelen voor gesture recognition op de SunSPOT. We hebben dit op een zodanige manier ge¨ımplementeerd dat de trainingsfase uitgevoerd wordt op een PC of server (een SunSPOT Host Application) en de herkenningsfase op de SunSPOT zelf (een SunSPOT Client Application). De implementatie werd gemaakt conform met de in sectie 3.2.1 en sectie 3.2.3 voorgestelde architectuur

5.4.1

Libraries en third-party code

Voor onze implementatie hebben we beroep gedaan op een aantal bibliotheken en programmacode van anderen die beschikbaar is onder open source licenties. • Jahmm [16]: een Java-implementatie van HMM-gerelateerde algoritmen, waaronder BaumWelch en Viterbi, twee algoritmen die we gebruiken in respectievelijk de trainingsen de herkenningsfase. We hebben het gebruik hiervan respectievelijk besproken in sectie 5.1.2.1 en sectie 5.1.2.2. Bovendien is Jahmm van Belgische makelij aangezien het ontwikkeld is door Jean-Marc Fran¸cois [16], voormalig onderzoeker aan de universiteit van Luik. • JAMA [30]: een Java-bibliotheek voor matrixbewerkingen die wij vooral gebruiken voor de implementatie van het algoritme voor het minimaliseren van tilting, besproken in sectie 5.2.1. • JDOM [31]: Een bibliotheek om XML in Java op een eenvoudige manier te manipuleren. Wij gebruiken dit vooral om op de ruwe data van de accelerometer op de slaan. • Jaxen [32]: Een open source XPath bibliotheek, die we gebruiken in combinatie met JDOM om de XML data te bevragen. • Wiigee [33]: Een bibliotheek voor gesture recognition in Java met behulp van een Nintendo Wii Remote, uitgegeven onder de GNU Lesser General Public License [34]. We hebben onze implementatie van de idle-state filter (zie sectie 5.2.2) en van de directional-equivalence filter (zie sectie 5.2.3) gebaseerd op de gelijknamige filters in Wiigee.

5.4 Implementatie

5.4.2

54

Formaat van modeldata voor de herkenning

De herkenner, die op de SunSPOT uitgevoerd wordt, moet beschikken over de informatie met betrekking tot de HMMs, die opgebouwd werd tijdens de trainingsfase. De manier waarop en wanneer deze gegevens doorgestuurd worden, zullen we bespreken in 6.6.3.2. De volgende data wordt voor ieder type beweging doorgestuurd. Deze data is grosso modo gelijk aan de HMM parameters die we eerder besproken hebben in sectie 5.1.2.1. • Type beweging • Het aantal interne toestanden in de HMM van de beweging, N . • Initiële probabiliteiten Πi voor iedere toestand i. • Transitieprobabiliteiten Ai,j tussen iedere 2 toestanden i en j. • Alle informatie met betrekking tot de gebruikte OPDF.

5.4.3

De herkenningsfase met Jahmm in J2ME

Jahmm is een bibliotheek die geschreven is voor de standaardversie van Java, Java 2 Standard Edition (J2SE). Op de SunSPOT draait echter Java 2 Micro Edition (J2ME). Aangezien echter de implementatie van de algoritmen in Jahmm betrouwbaar zijn, de broncode van de bibliotheek vrijgegeven is en het ons heel wat tijd zou sparen in vergelijking met een eigen implementatie, wilden we jahmm toch proberen te gebruiken op de SunSPOT. Om dit te realiseren hebben we het gedeelte van Jahmm dat we nodig hadden, moeten poorten naar J2ME. Hiervoor voerden we de volgende ingrepen uit. • Verwijderen van het gebruik van genericiteit: Aangezien de J2ME versie op onze SunSPOT nog een Java 1.4-versie was, wordt genericiteit nog niet ondersteund. Al deze voorkomens hebben we dus moeten omvormen naar mechanismen die gebruik maken van casting. Bovendien hebben we ook alle for-each-lussen moeten omvormen. • Converteren van het gebruik van Collections (zoals ArrayList) naar Vector: In J2ME is de klasse Vector de enige beschikbare Collection. Al het gebruik van andere Collections moest dus omgevormd worden naar het gebruik van de klasse Vector. • J2ME ondersteunt slechts een gedeelte van de operaties uit de Math-klasse van Java. Zo wordt bijvoorbeeld een machtsverheffing niet ondersteund. In een meegeleverde bibliotheek van de SunSPOT zit echter wel een MathUtils-klasse die de operaties implementeert die in de standaard Math-klasse van J2ME ontbreken. We moesten dus deze operaties in de broncode van Jahmm omzetten zodat ze gebruik maken van de MathUtils klasse. • Verwijderen van in J2ME niet ondersteunde Interfaces zoals Serializable en Cloneable. Bijgevolg hebben we dus ook operaties die aan klonen doen manueel moeten implementeren.

5.5 Bepalen van werkbare parameters

5.5

55

Bepalen van werkbare parameters

Aangezien we de besproken techniek voor gesture recognition willen gebruiken in onze prototype implementatie, moeten we een verzameling van parameters bepalen die daarvoor bruikbaar is. Het is belangrijk te vermelden dat dit geen doorgedreven benchmarking betreft, maar dat ons doel enkel is een werkbaar prototype te verkrijgen. De hoeveelheid parameters is namelijk zo groot dat het ons veel te ver zou leiden alle combinaties hiervan te testen, wat trouwens ook geen doel is van deze thesis.

5.5.1

Bespreking van de parameters

De verschillende mogelijke parameters van gesture recognition zoals wij die ge¨ımplementeerd hebben, zijn: • De IdleStateFilter (zie sectie 5.2.2) aan of uit. • De DirectionalEquivalenceFilter (zie sectie 5.2.3) aan of uit. • De TiltNeutralization (zie sectie 5.2.1) aan of uit. • Aantal noise gesture instances. • SNR van noise. • Aantal originele gesture instances. • Aantal toestanden in het HMM. • Aantal clusters in k-means clustering. • Aantal iteraties in het Baum-Welch algoritme. • De frequentie waaraan de samples opgenomen worden.

5.5.2

Testopstelling

Om testdata te verzamelen hebben we enkele vrienden gevraagd om tien verschillende types bewegingen (zie figuur 5.7) elk zes maal te vormen met de SunSPOT. De samples werden opgenomen aan een frequentie van 25 Hz. De frequentie wordt niet beschouwd als parameter aangezien uit de literatuur duidelijk blijkt dat 25 Hz goede resultaten levert en een hogere frequentie weinig of niets verbetert [13]. Bijgevolg hebben we voor ieder type gesture zes instances ter beschikking en hiervan nemen we n instances om de trainingsfase uit te voeren. We kunnen dan met de overige 6 − n instances de herkenner aansturen. Aangezien er een willekeurige factor in het spel is (namelijk bij van het genereren van noise instances, wat uitgelegd werd in sectie 5.2.4), hebben we het trainen en


Figuur 5.7: Types gestures gebruikt bij testen

Figuur 5.8: Onder andere Klaas was zo vriendelijk ons te voorzien van testdata.

56


57

herkennen voor iedere test telkens 100 maal herhaald en vervolgens de gemiddelde accuraatheid x ¯ en de standaardafwijking σ hierop berekend. De reden waarom σ telkens vermeld werd is om aan te tonen dat de bekomen resultaten nergens zwaar fluctueren en we ze dus kunnen gebruiken om gegronde conclusies te trekken. Bovendien werd ook telkens de gemiddelde accuraatheid procentueel uitgedrukt.

5.5.3 5.5.3.1

Testresultaten Vertrekparameters

Om een werkbare invulling te bepalen voor deze parameters, zijn we vertrokken van een geschatte set parameters gebaseerd op intu¨ıtie, wat ervaring van bij het implementeren van gesture recognition en inspiratie uit de literatuur [12] [24] [25] [23] [7]. Deze geschatte invulling van de parameters, die we besproken hebben in sectie 5.5.1, is: • IdleStateFilter : aan • DirectionalEquivalenceFilter : aan • De TiltNeutralization: uit • Aantal noise gesture instances: 4 • SNR van noise: 10 • Aantal originele gesture instances: 4 • Aantal toestanden in het HMM: 4 • Aantal clusters in k-means clustering: 12 • Aantal iteraties in het Baum-Welch algoritme: 9 • De frequentie waaraan de samples opgenomen worden: 25 Hz Wanneer we de tests laten draaien met deze parameters, verkrijgen we een gemiddeld aantal correct herkende bewegingen van 65,97 op 80 (wat neerkomt op een nauwkeurigheid van 82,4625%) met een standaardafwijking van 2,0854. We zullen nu proberen geleidelijk deze accuraatheid op te drijven door de parameters te laten variëren. Enkele parameters zullen we echter niet beschouwen. Dit zal het geval zijn voor de frequentie waaraan de samples opgenomen worden (de reden hiervoor werd vermeld in 5.5.2). Ook het aantal iteraties in het Baum-Welch algoritme zullen we steeds op 9 laten staan want dit is de standaardinstelling in de Jahmm-bibliotheek [16] en het laten variëren van deze parameter zou ons te ver leiden.


58

Figuur 5.9: Effect van noise op de nauwkeurigheid van gesture recognition 5.5.3.2

Effect van het aantal noise gesture instances

Als eerste testen we het effect van noise op de nauwkeurigheid. Hiervoor gaan we uit van de verzameling parameters vermeld in sectie 5.5.3.1, maar laten we het aantal noise gesture instances variëren van 0 tot 15. Dit zijn dus 16 testen, waarbij in elke test 100 keer 80 herkenningen worden uitgevoerd. De resultaten van deze metingen zijn terug te vinden in tabel 5.1 en gevisualiseerd in figuur 5.9. Zoals we zien blijft de nauwkeurigheid stijgen naarmate we meer noise instances toevoegen. We merken wel op dat er enige stagnatie optreedt en we vermoeden dat nog veel meer noise instances toevoegen weinig zin zal hebben. Bovendien moeten we ook opmerken dat de rekentijd lineair stijgt wanneer het aantal instances verhoogt [12]. Aangezien we merken dat de nauwkeurigheid slechts zeer gering stijgt, zouden we een zeer groot aantal noise instances moeten toevoegen om een zeer hoge nauwkeurigheid te verkrijgen, wat zou leiden tot lange uitvoertijden. Onze bedoeling is echter een werkbare set parameters bepalen zonder hierdoor de performantie sterk nadelig te be¨ınvloeden. Daarom kunnen we best een afweging maken en als we kijken naar de tabel, zien we dat bijvoorbeeld 6 noise instances een mogelijke kandidaat is. Uit deze resultaten zouden we ook kunnen opmerken dat TiltNeutralization zonder meer een positief effect heeft. Deze conclusie kunnen we echter niet zomaar trekken. We zullen op dit fenomeen dieper ingaan in sectie 5.5.3.4. 5.5.3.3

Effect van het aantal originele gesture instances

Als volgende zullen we het effect van het aantal gebruikte originele gesture instances in de trainingsfase op de nauwkeurigheid testen. Voor deze test wordt het resultaat bekomen in sectie 5.5.3.2, namelijk 6 noise gesture instances, gebruikt. Aangezien we beschikken over 6 opgenomen gesture

TN aan

TN uit

2,04

86,38

1,25

0,00

68,00

85,00

0,00

σ

x ¯

x ¯%

σ

69,10

75,70

71,25

x ¯%

60,56

1

57,00

0

x ¯

Noise instances

1,52

88,40

70,72

1,99

80,39

64,31

3

1,67

89,59

71,67

2,30

82,03

65,62

4

1,47

89,64

71,71

2,25

83,46

66,77

5

1,64

90,76

72,61

2,00

84,59

67,67

6

1,58

91,10

72,88

1,91

85,48

68,38

7

1,44

91,65

73,32

1,84

86,44

69,15

8

1,57

92,01

73,61

1,72

86,99

69,59

9

1,48

91,96

73,57

1,73

87,55

70,04

10

11

1,18

92,28

73,82

1,88

87,73

70,18

Tabel 5.1: Effect van noise op de nauwkeurigheid van gesture recognition

1,45

87,54

70,03

2,23

78,39

62,71

2

1,24

92,58

74,06

1,56

88,35

70,68

12

1,27

92,79

74,23

1,46

88,61

70,89

13

1,13

93,23

74,58

1,52

89,03

71,22

14

1,24

93,43

74,74

1,44

89,00

71,200

15

5.5 Bepalen van werkbare parameters 59


60

Aantal originelen

1

2

3

4

5

x ¯%

47,98

76,92

84,34

90,65

95,82

σ

5,48

3,34

2,16

1,64

0,80

Tabel 5.2: Effect van het aantal originele gesture instances op de nauwkeurigheid van gesture recognition

Figuur 5.10: Effect van het aantal originele gesture instances op de nauwkeurigheid van gesture recognition instances per persoon en per type gesture, kunnen we slechts maximaal 5 gesture instances gebruiken om de training uit te voeren9 . De resultaten werden verzameld in tabel 5.2 en gevisualiseerd in figuur 5.10 Uit de meetresultaten valt duidelijk af te leiden dat de nauwkeurigheid stijgt naarmate het aantal originele bewegingen toeneemt. We moeten echter opmerken dat het opdrijven van het aantal originele gesture instances kan leiden tot overfitting [7] en de uitvoertijd verhoogt. Omwille van die redenen en het feit dat de gebruiker niet te sterk belast mag worden door het trainen zullen we dus verder werken met 4 originele gesture instances en proberen de nauwkeurigheid in deze situatie zo hoog mogelijk te krijgen door andere parameters aan te passen. 5.5.3.4

Effect van het aantal clusters

Vervolgens onderzoeken we het effect van het aantal clusters dat gebruikt wordt in het k-means clustering algoritme (zie sectie 5.3.2). Hiervoor maken we opnieuw gebruik van de standaardparameters uit sectie 5.5.3.1. Vervolgens voeren we nog een tweede reeks metingen uit waarbij we het aantal noise instances op 6 instellen, zoals bepaald in sectie 5.5.3.2. Bovendien worden beide tests 9

want anders zouden we er geen meer over houden om aan herkenning te doen


61

Figuur 5.11: Effect van het aantal clusters in k-means clustering met 4 noise instances op de nauwkeurigheid van gesture recognition

Figuur 5.12: Effect van het aantal clusters in k-means clustering met 6 noise instances op de nauwkeurigheid van gesture recognition uitgevoerd met en zonder TiltNeutralization. De meetresultaten zijn samengevat in tabel 5.3 en gevisualiseerd in figuren 5.11 en 5.12. Het valt uit de tabel met meetresultaten en uit de grafieken af te leiden dat er slechts weinig verschil is tussen het gebruik maken van 4 of 6 noise instances. We merken wel dat 6 noise instances consequent tot wat hogere accuraatheid leidt, zoals ook reeds af te leiden viel uit de metingen in sectie 5.5.3.2. Wat we hier wel duidelijk merken is dat TiltNeutralization niet altijd zorgt voor een hogere nauwkeurigheid. Het is dus afhankelijk van het aantal clusters of TiltNeutralization een positief effect heeft of niet. Zoals we uit deze meetresultaten kunnen afleiden, scoort de situate met TiltNeutralization voor 12 clusters heel wat hoger dan die zonder TiltNeutralization. Aangezien we voor de metingen uit sectie 5.5.3.2 gebruik maakten van 12 clusters, verklaart dit waarom daar TiltNeutralization leidde tot een heel wat hogere nauwkeurigheid. De hoogste nauwkeurigheid die we in deze metingen hebben kunnen vaststellen is een gemiddeld

TN aan

TN uit

Clusters

1,93 70,63 1,76 71,64 2,11 73,34 2,35

1,95

39,47

49,34

2,35

38,83

48,54

2,52

38,69

48,36

2,29

σ

x ¯

x ¯%

σ

x ¯

x ¯%

σ

x ¯

x ¯%

σ

58,67

57,31

56,50

69,92

48,94

x ¯%

55,94

39,15

x ¯

3

1,93

84,40

67,52

2,12

83,46

66,77

1,11

83,35

66,68

1,26

82,94

66,35

4

1,80

90,89

72,71

1,80

90,01

72,01

1,62

85,39

68,31

1,57

84,04

67,23

5

1,55

89,38

71,50

2,13

87,59

70,07

1,56

87,27

69,82

1,96

86,03

68,82

6

1,05

85,86

68,69

1,40

84,84

67,87

1,69

90,31

72,25

1,51

89,11

71,29

7

1,24

93,74

74,99

1,65

92,29

73,83

1,56

92,71

74,17

1,76

91,55

73,24

8

1,54

88,61

70,89

1,57

87,29

69,83

1,38

89,74

71,79

1,62

87,75

70,20

9

1,92

90,96

72,77

1,90

89,56

71,65

1,78

88,48

70,78

1,81

87,54

70,03

10

2,06

86,54

69,23

2,11

83,87

67,10

1,63

90,33

72,26

1,85

88,59

70,87

11

1,54

90,65

72,52

1,52

89,50

71,60

2,07

84,67

67,74

2,06

81,81

65,45

12

1,63

90,70

72,56

1,94

88,81

71,05

1,85

85,20

68,16

2,02

82,33

65,86

13

Tabel 5.3: Effect van het aantal clusters in k-means clustering op de nauwkeurigheid van gesture recognition

instances

6 noise

instances

4 noise

instances

6 noise

instances

4 noise

2

1,37

88,34

70,67

1,64

86,60

69,28

2,01

89,31

71,45

1,87

86,41

69,13

14



Toestanden in HMM

63

1

2

3

4

5

6

7

8

x ¯

58,28

69,28

72,86

74,07

72,61

70,35

71,53

71,83

x ¯%

72,85

86,60

91,08

92,59

90,76

87,94

89,41

0,90

σ

1,58

1,56

1,13

1,44

1,50

1,72

1,47

1,32

Tabel 5.4: Effect van het aantal toestanden in het HMM op de nauwkeurigheid van gesture recognition aantal correct herkende bewegingen van 74,99 op 80 (wat neerkomt op een nauwkeurigheid van 93,74%) met een standaardafwijking van 1,24 en werd bereikt met TiltNeutralization en gebruik makende van 6 noise instances en 8 clusters. Deze nauwkeurigheid is op zich al hoger dan de hoogste nauwkeurigheid uit de testen in sectie 5.5.3.2, waar we gebruik moesten maken van 15 noise instances om een accuraatheid van 93,43% te halen. Bovendien is het ook belangrijk op te merken dat wanneer we geen TiltNeutralization gebruiken we bij 8 clusters en 6 noise instances nog steeds een accuraatheid halen van 92,71%. Volgens onze metingen echter kan de uitvoeringstijd van het algoritme voor TiltNeutralization oplopen tot 10% van de totale rekentijd voor de herkenningfase op de SunSPOT. Deze overhead weegt volgens ons niet op tegen de slechts kleine verbetering in nauwkeurigheid die we opmerken als gevolg van TiltNeutralization. We zullen bijgevolg vanaf nu alle volgende testen uitvoeren zonder TiltNeutralization. 5.5.3.5

Effect van het aantal toestanden in het HMM

Als volgende parameter testen we het aantal toestanden in het HMM. Hiervoor gaan we uit van de hierboven bepaalde parameters (8 clusters en 6 noise gestures) en de overige parameters uit sectie 5.5.3.1 en laten we het aantal toestanden variëren van 1 tot 8. De meetresultaten worden opgelijst in tabel 5.4 en gevisualiseerd in figuur 5.13. We merken op dat de hoogste nauwkeurigheid behaald wordt voor 4 toestanden in het HMM, wat ook de parameter was die we origineel gekozen hadden. We zullen deze parameter verder blijven gebruiken bij de volgende tests. 5.5.3.6

Effect van de SNR van noise

Als laatste parameter nemen we de SNR van de gegenereerde noise onder de loep. De manier waarop we de noise toegevoegd hebben en de SNR werden besproken in sectie 5.3.3. Bij deze metingen maken we opnieuw gebruik van de standaardparameters, met uitzondering van het aantal clusters (8) en het aantal noise gestures (6). We laten de SNR variëren van 1 tot 10. De meetresultaten worden opgelijst in tabel 5.5 en gevisualiseerd in figuur 5.14. De hoogste accuraatheid die we in deze metingen halen is 94% bij een SNR van 3, wat vrij hoog is voor een dataset van 10 trainingsbewegingen en rekening houdende met de toegevingen inzake performantie die we gemaakt hebben in sectie 5.5.3.2 en 5.5.3.3.


64

Figuur 5.13: Effect van het aantal toestanden in het HMM op de nauwkeurigheid van gesture recognition SNR

1

2

3

4

5

6

7

8

9

10

x ¯

73,06

74,78

75,20

75,16

74,97

74,74

74,49

74,34

74,39

74,16

x ¯%

91,33

93,48

94,00

93,95

93,71

93,42

93,11

92,93

92,99

92,70

σ

1,21

1,19

1,11

1,22

1,19

1,54

1,43

1,48

1,43

1,52

Tabel 5.5: Effect van de SNR van de noise op de nauwkeurigheid van gesture recognition

Figuur 5.14: Effect van de SNR van de noise op de nauwkeurigheid van gesture recognition


SNR

65

1

2

3

4

5

6

7

8

9

10

x ¯

67,90

68,46

68,09

67,78

67,63

67,51

67,22

67,07

67,03

66,69

x ¯%

94,31

95,08

94,57

94,14

93,93

93,76

93,36

93,15

93,10

92,63

σ

0,77

0,64

0,60

0,56

0,64

0,70

0,82

0,92

0,84

1,15

Tabel 5.6: Effect van de SNR van de noise op de nauwkeurigheid van gesture recognition zonder het gesture type square in de dataset Clusters zonder square

met square

6

7

8

9

10

x ¯

63,05

68,13

68,07

66,93

68,62

x ¯%

87,57

94,62

94,54

92,96

95,31

σ

1,02

0,89

0,64

0,72

1,24

x ¯

70,77

73,06

75,14

74,68

72,65

x ¯%

88,46

91,33

93,93

93,35

90,81

σ

1,50

1,29

1,21

0,53

1,24

Tabel 5.7: Effect van het aantal clusters in k-means clustering op de nauwkeurigheid van gesture recognition met en zonder het gesture type square in de dataset 5.5.3.7

Reduceren van de dataset

De bovenstaande metingen werden bereikt met een verzameling van 10 gesture types om de trainingsfase uit te voeren, namelijk deze getoond in figuur 5.7. In de praktijk zijn 10 verschillende types gestures al behoorlijk veel en bovendien meer dan voldoende in ons prototype. Het valt bovendien te verwachten dat de nauwkeurigheid zal stijgen als we met een kleiner aantal gesture types werken. Uit eigen ervaring met het testen van gesture recognition en het werken met ons prototype, hebben we gemerkt dat, wanneer een beweging fout herkend wordt, deze vaak als een gesture van het type square herkend wordt. Aangezien het bovendien een beweging is die beduidend groter is dan de anderen, en dus minder handig is om te vormen, besloten we om enkele testen te doen waarbij square verwijderd werd uit de dataset. Bijgevolg is het maximaal aantal correct herkenbare bewegingen nu 72. Ten eerste hebben we de meting uit sectie 5.5.3.6 herhaald waar we de SNR lieten variëren van 1 tot 10. De resultaten worden getoond in tabel 5.6 en gevisualiseerd in figuur 5.15. Uit de meetresultaten valt af te leiden dat het verwijderen van square voor een verhoging zorgt in de nauwkeurigheid. We merken ook op dat in deze situatie een SNR van 2 beter presteert, terwijl dit in de metingen uit sectie 5.5.3.6 het geval was bij een SNR van 3. Om het effect van het gesture type square nog wat verder te kunnen beoordelen, hebben we vervolgens een test gedaan waarbij we opnieuw het aantal clusters in k-means clustering laten variëren terwijl we voor de SNR 3 nemen. Deze resultaten zijn samengevat in tabel 5.7 en gevisualiseerd in figuur 5.16.


66

Figuur 5.15: Effect van de SNR van de noise op de nauwkeurigheid van gesture recognition zonder het gesture type square in de dataset

Figuur 5.16: Effect van het aantal clusters in k-means clustering op de nauwkeurigheid van gesture recognition met en zonder het gesture type square in de dataset


67

Figuur 5.17: Effect van het aantal clusters in k-means clustering op de nauwkeurigheid van gesture recognition met enkel de bewegingen langs de hoofdassen in de dataset Uit deze metingen valt iets zeer interessants af te lezen. Het optimaal aantal clusters is verschoven van 8 naar 10 wanneer we het gesture type square uit de dataset verwijderen. De reden hiervoor valt niet zomaar te verklaren, maar we zullen verder ingaan op dit fenomeen na de volgende meting. Ten slotte hebben we ook nog een meting gedaan op een dataset die enkel de zes bewegingen langs de hoofdassen bevat (left, right, up, down, push en pull) en waarbij we het aantal clusters opnieuw hebben laten variëren, maar dit maal van 4 tot 18. In dit geval is 48 het maximum aantal correct herkenbare bewegingen. De resultaten van deze metingen zijn terug te vinden in tabel 5.8 en gevisualiseerd in figuur 5.17. We merken uit de meetresultaten dat kiezen voor 10 clusters, in plaats van de eerder bekomen 8, ook in dit geval een zeer hoge nauwkeurigheid oplevert (99,81%). De reden hiervoor valt informeel als volgt te verklaren. De data, dus de samples, die geclusterd wordt, wordt verkregen bij het maken van bewegingen. Er zijn twee parameters die er voor zorgen dat er verschillende clusters te identificeren zijn in die data. • Ten eerste de richting van de beweging. Die zal bepalen langs welke as we een versnelling waarnemen en dit is meteen ook de meest voor de hand liggende parameter. • De tweede parameter is de snelheid waarmee de beweging gemaakt wordt. Dit valt eenvoudig te verklaren doordat we werken met een accelerometer. Die meet niet alleen de richting waarin er een beweging gemaakt wordt, maar ook de versnelling waarmee dit gebeurt. Met deze kennis is het dus duidelijk dat een beweging toevoegen of verwijderen ervoor kan zorgen dat bepaalde richtingen worden toegevoegd aan of verdwijnen uit de data. In dit geval

1,55

1,16

σ

0,90

92,33

44,32

6

0,45

97,63

46,86

7

0,63

92,25

44,28

8

0,89

95,00

45,60

9

0,29

99,81

47,91

10

0,51

91,54

43,94

11

1,14

94,17

45,20

12

0,86

97,75

46,92

13

0,48

92,31

44,31

14

0,84

95,94

46,05

15

1,11

95,42

45,80

16

0,77

94,54

45,38

17

0,96

88,85

42,65

18

hoofdassen in de dataset

Tabel 5.8: Effect van het aantal clusters in k-means clustering op de nauwkeurigheid van gesture recognition met enkel de bewegingen langs de

92,25

85,90

x ¯%

44,28

5

41,23

4

x ¯

Clusters



69

verdwijnen er dus bepaalde richtingen, en dus één of meerdere groepen gelijkaardige samples, uit de dataset. Dit kan als gevolg hebben dat bepaalde clusters sterk gereduceerd worden of zelfs volledig verdwijnen. Hierdoor kan er een verschuiving ontstaan in de optimale verdeling van de data in clusters. In dit geval uit zich dat in een verhoogd ideaal aantal clusters maar dit had ook omgekeerd kunnen zijn. De enige goede conclusie die we hieruit kunnen afleiden is dat het optimaal aantal clusters onder andere bepaald is door de gebruikte types bewegingen. We kunnen echter nog altijd niet het optimaal aantal clusters voor een set bewegingen bepalen. Dit omdat het optimaal aantal clusters ook afhankelijk is van wie de bewegingen heeft gemaakt of beter gezegd, van hoe de bewegingen werden gemaakt. De ene persoon maakt zijn bewegingen al sneller dan de andere persoon en wat veel erger is, de ene beweging kan sneller gemaakt worden dan de andere waardoor het optimaal aantal clusters weer kan verhogen ten opzichte van een uniforme snelheid in iedere beweging. We verduidelijken dit met een concreet voorbeeld. Wanneer de beweging up wordt gemaakt zijn er ruwweg twee groepen samples. Eén groep die de versnelling naar boven vertegenwoordigt bij het begin van de beweging en één groep die de versnelling naar onder vertegenwoordigt bij het einde van de beweging (minder snel naar boven beginnen bewegen uit zich in een versnelling naar onder). Dit geeft ons dus ook twee clusters. Wanneer men nu met dezelfde snelheid de beweging down maakt dan komen die twee groepen samples terug naar boven maar in omgekeerde volgorde. Dit resulteert in de twee zelfde clusters als diegene die we verkregen bij het maken van de beweging up. Wanneer men echter de beweging down sneller of trager maakt dan up, dan zijn de richtingen van de twee resulterende samplegroepen nog altijd dezelfde, maar de grootte van de versnellingen zal verschillen en dit zal resulteren in twee nieuwe clusters. Het is dus duideljk dat één cluster meer of minder het verschil kan maken tussen een optimale of suboptimale verdeling. In figuur 5.17 wordt dit (voor het gebied van 6 t.e.m. 15 clusters) weerspiegeld door een fluctuatie die zich telkens bijna exact herhaalt. Wanneer een piek in nauwkeurigheid wordt bereikt (en dus een optimale verdeling in clusters is bekomen), zorgt het toevoegen van een extra cluster meteen voor een suboptimale verdeling.

5.5.4

Conclusies

De verzameling waarden voor de parameters die we bekomen zijn door middel van de hierboven vermeldde metingen ziet er als volgt uit: • De IdleStateFilter (zie sectie 5.2.2) aan. • De DirectionalEquivalenceFilter (zie sectie 5.2.3) aan. • De TiltNeutralization uit. • Aantal noise gesture instances: 6. • SNR van noise: 3.

5.6 Future work

70

• Aantal originele gesture instances: 4. • Aantal toestanden in het HMM: 4. • Aantal clusters in k-means clustering: 10. • Aantal iteraties in het Baum-Welch algoritme: 9. • De frequentie waaraan de samples opgenomen worden: 25 Hz. We zullen dus in onze prototype implementatie deze parameters gebruiken alsook de laatst besproken gereduceerde set bewegingen.

5.6

Future work

Onze bedoeling was slechts een prototype implementatie ontwerpen voor gesture recognition, zoals we reeds meerdere malen hebben vermeld. Het gevolg hiervan is dat onze implementatie nog niet geschikt is om als eindproduct te gebruiken en er ook nog verdere optimalisaties nodig zijn. In deze sectie geven we een overzicht van mogelijke verbeteringen en uitbreidingen die we reeds ge¨ıdentificeerd hebben. • De invloed van andere types noise kan nog getest worden want [7] vermeldt ook dat gaussisch verdeelde noise nog beter kan presteren dan uniform verdeelde noise. • Op de manier waar we gesture recognition momenteel ge¨ımplementeerd hebben, zal tijdens de herkenningsfase een opgegeven beweging altijd afgebeeld worden op een gekende beweging. Er zijn echter situaties denkbaar waar we dit niet willen maar wel de input willen negeren en de gebruiker vragen de beweging nogmaals te maken. Dit zou bijvoorbeeld aanvaardbaar zijn in een situatie waar een te herkennen beweging niet echt goed uitgevoerd werd en de probabiliteiten dat de beweging matcht tegen meerdere gekende gestures te kort bij elkaar liggen. In een dergelijke situatie is er dus een hoge kans dat we een foute beslissing zouden nemen en is het beter geen beslissing te nemen. • Aangezien het vormen van bewegingen persoonlijk is, moet het systeem voor iedere gebruiker apart getraind worden. Het is ook makkelijk in te zien dat omwille van deze reden de optimale waarden voor de parameters die we beschreven hebben bij het testen (zie 5.5.1) ook zullen verschillen van persoon tot persoon. Om die reden zou het nuttig zijn om tijdens de trainingsfase een systeem in te bouwen dat een zo goed mogelijke schatting maakt van de parameters voor een bepaalde verzameling training gestures. • Op dit moment worden de centro¨ıden aan het begin van het k-means algoritme willekeurig gekozen uit de trainingssamples. Een optimalisatie zou er uit kunnen bestaan de centro¨ıden op voorhand in te schatten zodat ze matchen met de hoofdrichtingen van de bewegingen die

5.6 Future work

71

gemaakt worden. Bijvoorbeeld: als de bewegingen in een 2D-vlak gemaakt worden kunnen er 8 centro¨ıden gekozen worden zodat de hoofdrichtingen die erdoor bepaald worden min of meer overeen komen met de 8 windrichtingen. • In onze huidige beschrijving van gesture recognition worden artificiële noise gestures op een eenvoudige, willekeurige manier gegenereerd, zoals besproken in 5.2.4 en 5.3.3. Een mogelijke optimalisatie zou zijn een genetisch algoritme te gebruiken om deze noise gestures te genereren. Verder onderzoek is nodig om te bepalen of dit een positief effect zou hebben op de nauwkeurigheid.

IMPLEMENTATIE

72

Hoofdstuk 6

Implementatie Homer: Don’t worry son, I’ll build you a new treehouse–One so grand it’ll be an affront to God himself. Bart: Can it have a ladder you can pull up after you? Homer: Only if it’s an affront to God. The Simpsons

We hebben in de vorige hoofdstukken uitgebreid uitgelegd hoe we de architectuur van ons systeem ontworpen hebben, op welke manier de communicatiecomponent gestructureerd zal zijn en de werking van gesture recognition besproken. In dit hoofdstuk zullen we nader ingaan op een prototype implementatie van het platform. Hierbij zullen we zowel bepaalde praktische ingrepen bespreken die nodig waren om de architectuur gerealiseerd te krijgen, alsook enkele problemen behandelen die we hebben moeten overwinnen. We zullen beginnen met een praktische bespreking van de reeds voorgestelde componenten in het systeem (sectie 3.2) en een extra component, de gateway. Daarna wordt ook het communicatieraamwerk vanuit een praktisch oogpunt hernomen. Als laatste bespreken we de performantie van de prototype implementatie. De belangrijkste zaken hierbij zijn de snelheid waarbij een beweging herkend wordt op de controller en de snelheid en betrouwbaarheid van het communicatiesysteem.

6.1

Proxy Devices

In het ideale geval zouden alle toestellen met behulp van Web services moeten kunnen communiceren. Bij de meeste toestellen is dit echter nog niet het geval. Om het communiceren met deze toestellen te vereenvoudigen maken we gebruik van het proxy device, dat een brug slaat tussen de rest van het systeem en het toestel op zich. Zo wordt het heel eenvoudig om een nieuw toestel compatibel te maken met en te laten integreren in het platform. Standaard bevat een proxy device enkel het volledige communicatieframework. Het enige wat nog moet gebeuren om een toestel in

6.2 De gateway

73

te pluggen in het systeem is de klasse Client uitbreiden tot een virtueel toestel” en dit virtueel ” toestel inschrijven bij de juiste services om bepaalde berichten (events, aanvraag voor toestand van het toestel,...) te ontvangen. Wanneer een virtueel toestel dan op deze manier acties of requests ontvangt, kan het deze acties of requests doorspelen aan het fysieke toestel zelf of antwoorden in de plaats van het fysieke toestel. Op deze manier kunnen meerdere toestellen, of zelfs volledige netwerken zoals bijvoorbeeld Universal Plug and Play (UPnP)-netwerken, vlot aan elkaar gekoppeld worden terwijl ze voor het platform voorkomen als één virtueel toestel. Of één proxy device kan meerdere fysieke toestellen vertegenwoordigen door meerdere implementaties van de abstracte klasse Client, en dus meerdere virtuele toestellen, te onderhouden. Het WS-Gesture-raamwerk zal deze groep van fysieke toestellen dan kunnen ontdekken en controleren alsof het één fysiek toestel is. Meer uitleg hierover is te vinden in sectie 6.6.2.5. Verder wordt er ook nog de mogelijkheid voorzien om virtuele toestellen visueel te herkennen via de feedback identifier. In deze implementatie is dit een kleur voor de leds op de SunSPOT. Deze kleur is in te stellen via de configuratiecomponent. Om de eenvoud te bewaren gebruiken we in de rest van dit hoofdstuk de term device” om de ” collectie van alle virtuele toestellen aan te duiden die geregistreerd zijn in dat proxy device.

6.2

De gateway

We zijn bij het ontwerpen van de architectuur (zie hoofdstuk 3) en de communicatiecomponent (zie hoofdstuk 4) van het idee uit gegaan dat alle componenten rechtstreeks via hetzelfde netwerkprotocol met mekaar kunnen communiceren. In de praktijk zal deze aanname niet steeds gelden. Dit is bijvoorbeeld al het geval in onze prototype implementatie, waarbij de controller communiceert via het Zigbee-protocol en de andere componenten (zoals de mapper en de devices) communiceren via Ethernet. Het gevolg hiervan is dat er een component in het systeem toegevoegd moet worden die functionaliteit bevat voor het vertalen van berichten tussen alle verschillende protocollen. Deze nieuwe component hebben we de gateway genoemd en het spreekt voor zich dat de gateway, naast vertaler, ook als router zal werken in ons systeem. De gateway zal ook de antwoorden die van verschillende kanalen komen, aggregeren alvorens die terug te sturen. Het principe is eenvoudig en kan, zonder aan algemeenheid te verliezen, gemakkelijk worden verduidelijkt met volgend concreet voorbeeld (te volgen in figuur 6.1). In de prototype implementatie kan de controller enkel communiceren via het Zigbee-protocol en de devices enkel via Ethernet. Toch moet de controller de devices kunnen ontdekken via een Probe-bericht (zie appendix A.1). Hier komt de gateway in actie. De controller zal een multicast

6.3 De controller

74

Figuur 6.1: Sequentiediagram van een Probe, gestuurd vanuit de controller om devices te ontdekken

Figuur 6.2: Sequentiediagram van het ontdekken van devices met een Probe vanuit de configuratieapplicatie Probe-bericht sturen over Zigbee. Wanneer dit aankomt bij de gateway zal die het bericht over alle kanalen, behalve het kanaal waarop het binnenkwam, doorsturen. Concreet zal dit dus over Ethernet zijn. Vervolgens krijgen alle devices het Probe-bericht binnen en kunnen ze er op reageren indien nodig. De devices sturen hun antwoord, een ProbeMatches-bericht (zie appendix A.1), terug naar de gateway. Die aggregeert dan alle antwoorden en stuurt dit door naar de controller. Devices die toch via het Zigbee-protocol kunnen communiceren, zullen dan direct antwoorden zonder tussenkomst van de gateway. Verder zal ook alle communicatie tussen de configuratiecomponent en de rest van het systeem via de gateway verlopen. De reden hiervoor is dat de configuratiecomponent in een ander netwerk, bijvoorbeeld op een publieke server op het internet, geplaatst kan worden. Dit betekent bijvoorbeeld dat wanneer de configuratiecomponent een Probe-bericht wil versturen, dit naar de gateway wordt gestuurd. De gateway zal dit bericht op zijn beurt als multicast sturen over alle kanalen, de antwoorden aggregeren en die doorsturen naar de configuratiecomponent. Deze werkwijze wordt gevisualiseerd in figuur 6.2.

6.3

De controller

De controller werd volledig ge¨ımplementeerd zoals voorgesteld in sectie 3.2.1. Praktisch gezien werken de recognition manager en de user manager echter heel nauw samen. Wanneer er bijvoorbeeld

6.3 De controller

75

Figuur 6.3: Toestandsdiagram van het controlesysteem op de controller. nog geen gebruiker ingelogd is en de juiste knop wordt ingedrukt, moet de recognition manager data opvragen aan de accelerometer en die daarna doorgeven aan de gesture recognizer om de beweging te herkennen. Aan de hand van die beweging zal de gebruiker dan ingelogd worden en worden de juiste trainingsmodellen ingeladen, wat dan weer het werk is van de user manager. Verder moet ook alle functionaliteit die in de controller thuis hoort aangestuurd kunnen worden met slechts twee knoppen aangezien we gebruik maken van een SunSPOT. Om dit toe te laten werd een controlesysteem, gebaseerd op toestanden, uitgewerkt. Zo kunnen de twee knoppen in iedere toestand een andere actie starten en kunnen ze dus in iedere toestand herbruikt worden. Dit is analoog aan de toestandsafhankelijke afbeelding van een beweging op een actie en zo wordt het aantal nodige knoppen (bewegingen) sterk gereduceerd. Het enige verschil is dat de controller slechts één toestand tegelijk kan hebben. Hieronder worden de toestanden met hun visuele herkenning, mogelijke acties in iedere toestand en overgangen tussen toestanden besproken. Dit wordt ook verduidelijkt in figuur 6.3.

6.3 De controller

76

1. Initializing: De controller komt in deze toestand bij het opstarten. De leds knipperen blauw. De gebruiker kan nog niet in interactie treden met de controller. • De communicatiecomponent wordt ge¨ınitialiseerd. • De controller blijft zoeken naar een gateway en een mapper tot hij ze gevonden heeft. De respectievelijke verklaringen hiervoor worden gegeven in sectie 6.2 en sectie 3.2.2. • Hierna vraagt de controller de modeldata voor het inloggen van een gebruiker met een beweging op (zie scenario 2.1.2). • Eens dit gebeurd is gaat de controller naar de toestand Started. 2. Started: De controller komt na initialisatie automatisch in deze toestand. De leds knipperen groen. Vanaf nu kan de gebruiker in interactie treden met de controller. • In deze toestand kan de configuratiecomponent het trainen van bewegingen voor een willekeurige gebruiker starten. Hierdoor gaat de controller naar de toestand Training. • De gebruiker kan anderzijds ook inloggen door knop 1 ingedrukt te houden terwijl hij zijn loginbeweging maakt. Hierdoor zal de user manager de gebruiker inloggen en zijn modeldata voor het herkennen van zijn persoonlijke bewegingen opvragen. De controller gaat naar de toestand Logged in. 3. Training: de controller is gekoppeld met de configuratiecomponent om bewegingen te trainen. De leds knipperen geel. • Bewegingen die als trainingsdata zullen worden doorgestuurd, worden gemaakt door op knop 1 te drukken tijdens het maken van de beweging. In deze toestand worden geen andere acties toegelaten behalve processen die constant op de achtergrond draaien, zoals het antwoorden op een Probe of Resolve bericht. Na het trainen komt de controller terug in de toestand Started. • Door op knop 2 te drukken kan de training geannuleerd worden vanuit de controller. Ook hierdoor komt de controller terug in de toestand Started. 4. Logged in: In deze toestand is een gebruiker ingelogd. De leds knipperen drie keer blauw. • De gebruiker kan nu door op knop 1 te drukken het zoeken naar toestellen starten. Wanneer er minstens één toestel gevonden wordt, gaat de controller naar de toestand Probed. • De gebruiker kan ook uitloggen door op knop 2 te drukken. Hierdoor vraagt de controller de modeldata voor het inloggen van een gebruiker met een beweging opnieuw op en gaat hij terug naar de toestand Started. 5. Probed: In deze toestand heeft de controller reeds minstens 1 toestel ontdekt. De leds blinken drie keer geel.

6.4 De mapper

77

• De gebruiker kan bladeren door de ontdekte toestellen door op knop 1 te drukken. Telkens wordt de identificatiekleur van het toestel getoond. • De gebruiker kan een koppeling opzetten met het geselecteerde toestel door op knop 2 te drukken. Dit zorgt er ook voor dat het device zich inschrijft bij de mapper om events met acties in te ontvangen. Meer detail hierover is te vinden in sectie 6.4.2. Na het koppelen komt de controller in de toestand Paired terecht. • De gebruiker kan ook terug naar de Logged in toestand gaan om de ontdekking van toestellen opnieuw te doen door knop 1 gedurende drie seconden in te drukken. 6. Paired: Er is een koppeling met een toestel en het aansturen ervan kan nu gebeuren. De leds blinken drie keer groen. • De gebruiker kan nu een beweging maken door knop 1 ingedrukt te houden. De beweging wordt herkend en samen met de UUID van het toestel, de Identifier (ID) van de gebruiker en de subscriptionID als een event verstuurd naar de mapper. Meer detail hierover is te vinden in sectie 6.4.2. • De gebruiker kan ook de koppeling met het toestel verbreken door op knop 2 te drukken. De controller gaat hierdoor terug naar de toestand Logged in.

6.4

De mapper

6.4.1

Afbeelden van bewegingen op acties

Zoals reeds gezegd in het hoofdstuk over de architectuur (hoofdstuk 3) zal de mapper een beweging afbeelden op een actie, afhankelijk van de toestand waarin het aan te sturen toestel zich bevindt. Om deze functionaliteit te bieden zijn er minstens twee mogelijkheden: • Een regelgebaseerd systeem met regels die rekening houden met de gemaakte beweging en de toestand van het toestel. Deze toestand kan gemakkelijk uitgebreid of veranderd worden, op zichzelf een verzameling van meerdere toestanden zijn, ... Een bijkomend voordeel is dat wanneer een beweging in iedere toestand dezelfde actie teweeg moet brengen, dit maar éénmalig gedefinieerd hoeft te worden in een regel. • Een toestandsdiagram waarin iedere toestand een toestand van het aan te sturen toestel voorstelt en iedere actie een overgang van toestand met zich meebrengt. Dit systeem is zeer eenvoudig te implementeren, maar het heeft enkele nadelen. Wanneer een toestel veel toestanden heeft, of wanneer een toestel meerdere toestanden tegelijk kan hebben, dan wordt het toestandsdiagram hopeloos ingewikkeld door een explosie aan toestanden. Elke combinatie van toestanden zal immers als een nieuwe toestand in het toestandsdiagram voorgesteld worden. En als een beweging in iedere toestand dezelfde actie teweeg moet brengen dan moet dit ook in iedere toestand gedefinieerd worden.

6.4 De mapper

78

Een toestandsmachine heeft in dit geval duidelijk enkele nadelen, vooral met betrekking tot de quality attribute modifiability, ten opzichte van een regelsysteem. Uiteindelijk hebben we ervoor gekozen gebruik te maken van een regelgebaseerd systeem, meerbepaald het pakket Drools [35]. Dit pakket maakt het mogelijk snel een regelbestand op te stellen, een regelbestand at runtime te compileren en te gebruiken bij het bepalen van de juiste actie. Een voorbeeld van een dergelijk regelbestand is weergegeven in listing 6.1

6.4.2

Het koppelingsmechanisme

Een tweede belangrijk punt bij de mapper is de manier waarop inschrijvingen voor events beheerd worden. Om dit beter te begrijpen worden de twee verschillende types events, GestureEvent (zie appendix A.6) en DeviceEvent (zie appendix A.6), besproken en waar die hun oorsprong vinden. Vervolgens geven we een korte schets van het WS-Eventing mechanisme om dan uiteindelijk de concrete invulling hiervan in onze prototype implementatie te bespreken. 6.4.2.1

GestureEvent en DeviceEvent

In sectie 3.2.2 werd er voor gekozen om herkende bewegingen naar de mapper te sturen en de mapper de juiste actie te laten doorsturen naar het aan te sturen device. In onze prototype implementatie worden de herkende bewegingen als GestureEvents naar de mapper gestuurd. De events met de uit te voeren actie in, die van de mapper naar devices gestuurd worden, worden DeviceEvents genoemd. 6.4.2.2

WS-Eventing in het kort

De twee belangrijkste componenten in het WS-Eventing-mechanisme zijn de subscribers en de event source. De subscriber is diegene die zich wil inschrijven bij de event source om berichten van een bepaald type te ontvangen. Hij kan dit doen door een gepast Subscribe-bericht (zie appendix A.4) te sturen naar de event source. In dit bericht staat informatie zoals de UUID van de ontvanger van de events. Indien alles goed verloopt, zal de event source deze gegevens opslaan, antwoorden met een SubscriptionResponse-bericht (zie appendix A.4) met daarin de UUID van de SubscriptionManager en een SubscriptionID, en in de toekomst zal de event source de events waarvoor de subscriber zich registreerde nu ook doorsturen naar deze subscriber. Dit is dus een push-systeem. De SubscriptionManager is de component die instaat voor het verdere beheer (verlengen, beëindigen,...) van een inschrijving en valt in de prototype implementatie samen met de event source. De SubscriptionID wordt gebruikt om een inschrijving uniek te identificeren. Een meer uitgebreide uitleg hierover is te vinden in de WS-Eventing standaard [4]. 6.4.2.3

Prototype implementatie

Zoals in de vorige sectie werd vermeld, zijn de twee belangrijkste componenten in WS-Eventing de subscribers en de event source. In de prototype implementatie zijn dit respectievelijk de devices en de mapper. De standaard kan echter niet zonder meer ge¨ımplementeerd worden.

6.4 De mapper

package be . ugent . ibcn . wsgesture . mapper ;

rule " Gesture is play and state is playing "

when g : MapperGesture ( type == " play " && state == " playing " ) then g . setAction ( " pause " ); end

rule " Gesture is square and state is playing "

when g : MapperGesture ( type == " square " && state == " playing " ) then g . setAction ( " stop " ); end

rule " Gesture is play and state is paused "

when g : MapperGesture ( type == " play " && state == " paused " ) then g . setAction ( " play " ); end

rule " Gesture is play and state is stopped "

when g : MapperGesture ( type == " play " && state == " stopped " ) then g . setAction ( " play " ); end

rule " Gesture is right "

when g : MapperGesture ( type == " right " ) then g . setAction ( " next " ); end

rule " Gesture is left "

when g : MapperGesture ( type == " left " ) then g . setAction ( " previous " ); end

Listing 6.1: Voorbeeld van een regelbestand voor de aansturing van een muziekspeler

79

6.4 De mapper

80

Figuur 6.4: Sequentiediagram van de koppeling tussen controller en device • In sectie 6.3 wordt vermeld dat de controller de inschrijving van een device moet kunnen initiëren en zo ook een koppeling opzetten tussen de controller en het device. Dit is echter niet voorzien in de WS-Eventing standaard. • De mapper moet ook de ID van de op de controller ingelogde gebruiker kennen om het correcte regelbestand aan de configuratiecomponent op te vragen1 . Ook dit wordt niet voorzien in de WS-Eventing standaard. Om deze twee problemen op te lossen werd er een nieuw type bericht gecreëerd, het EventingInit-bericht (zie appendix A.3), dat aan de eerder geschetste werking van WS-Eventing vooraf zal gaan. Figuur 6.4 verduidelijkt de werking van het geheel. Voor de eenvoud zijn Resolve-berichten weggelaten. Verder is het ook nodig te weten dat in de prototype implementatie de mapper en de gateway in dezelfde applicatie, en dus zeker op dezelfde machine, werken. Het EventingInit-bericht wordt bij het starten van de koppeling tussen de controller en het device gestuurd van de controller naar het device en bevat: • De UUID van de event source. • Het type van de event source. In de prototype implementatie is dit Mapper”. ” • De ID van de gebruiker die ingelogd is op de controller. 1

want een regelbestand is uniek per toestel en per gebruiker

6.5 De configuratiecomponent

81

Wanneer het device dit bericht ontvangt zal het deze informatie gebruiken om een Subscribebericht op te stellen en naar de mapper te sturen. Dit bericht bevat: • De URI van de component waar het SubscriptionEnd -bericht (zie appendix A.5) naartoe gestuurd moet worden bij het beëindigen van de inschrijving vanuit de mapper. • De URI van het device dat de DeviceEvents moet ontvangen. • De ID van de op de controller ingelogde gebruiker. Wanneer dit Subscribe-bericht nu aankomt bij de mapper zal die het regelbestand voor het toestel dat de aanvraag stuurde, en voor de juiste gebruiker, opvragen bij de configuratiecomponent. Na compilatie zal de mapper de regels opslaan met als sleutel de URI van het toestel dat de aanvraag stuurde en de ID van de ingelogde gebruiker. Als dit lukt zal de mapper ook een element toevoegen in zijn lijst met inschrijvingen. Hierin komt alle nodige info over het toestel en de gebruiker alsook een subscriptionID die gebruikt moet worden om de inschrijving, en dus ook de koppeling tussen de controller en het device, uniek te identificeren. Deze subscriptionID wordt dan meegestuurd in de SubscriptionResponse zodat de controller die ook krijgt. Nu is het device ingeschreven bij de event source (de mapper ) en is de koppeling tussen de controller en het device een feit.

6.4.3

Het sturen van events

Vervolgens kan de controller een GestureEvent sturen naar de mapper. De twee belangrijkste stukjes informatie in dat event zijn de gemaakte beweging en de subscriptionID. Op basis van dit ID kan de mapper de inschrijving uniek identificeren, het juiste regelbestand gebruiken om de beweging op een actie af te beelden en de actie in een DeviceEvent naar het juiste device sturen. Dit proces wordt voorgesteld in figuur 6.5. Wanneer een inschrijving beëindigd moet worden dan wordt een SubscriptionEnd (zie appendix A.5) naar de mapper gestuurd, met daarin opnieuw de subscriptionID. De mapper kan dan eenvoudig de bijhorende inschrijving uit zijn lijst verwijderen. Op deze manier kan het device geen events meer ontvangen van de controller waar de gebruiker op ingelogd was tot er een nieuwe koppeling wordt gemaakt.

6.5

De configuratiecomponent

De bedoeling van de configuratiecomponent is tweevoudig. Enerzijds zal deze vanzelfsprekend instaan voor de configuratie van het systeem. Anderzijds wordt deze component gebruikt als een centrale databron binnen het systeem.


82

Figuur 6.5: Sequentiediagram van het sturen van een event van de controller naar een device

6.5.1

Het configureren van het systeem

• Configureren van devices. Dit omvat de volgende functies: – Ontdekken en opslaan van devices. De configuratiecomponent moet dus ook een Probebericht kunnen sturen. – Instellen van de feedback identifier van een toestel. In ons geval zal dit dus de kleur zijn waarmee het toestel ge¨ıdentificeerd kan worden. De configuratiecomponent moet dus ook een FeedbackIdentifier -bericht (zie appendix A.8) kunnen sturen. – Bewerken van het regelbestand dat bij een toestel hoort. Hiervoor moet er uiteraard een gebruiker ingelogd zijn op de configuratiecomponent, aangezien de regelbestanden gebruikersafhankelijk zijn. • Ontdekken en opslaan van controllers. • Specifiëren welke types bewegingen er gebruikt worden binnen het systeem. • Gebruikersbeheer waarbij onder andere iedere gebruiker een beweging kan selecteren die hij wenst te gebruiken om in te loggen. • Een belangrijk doel van de configuratiecomponent is ook een visuele omgeving aan te bieden om de trainingsfase van gesture recognition (die we besproken hebben in 5.1.2.1) uit te voeren. Dit omvat de volgende functionaliteiten: – Trainingsdata verzamelen die gegenereerd wordt met een controller. Dit betekent dus dat de configuratiecomponent de StartCollection- en StopCollection-berichten (zie appendix A.9) moet kunnen verzenden naar de controller. De ontvangen trainingsdata wordt


83

opgeslagen in de databank en gekoppeld aan een gebruiker en een trainingsprofiel. Een gebruiker kan meerdere profielen aanmaken en selecteren welke er door de applicatie gebruikt zal worden. – Het trainen van een trainingsprofiel. Hiervoor wordt de opgeslagen trainingsdata doorgezonden naar de trainer en wordt de verkregen modeldata opgeslagen. • Algemene configuratie-instellingen zoals Internet Protocol (IP)-adres en poort van de gateway en de trainer.

6.5.2

De configuratiecomponent als centrale databron

Zoals eerder vermeld zien we de configuratiecomponent ook als een centrale databron. De verscheidene componenten binnen het platform zullen deze databron kunnen gebruiken om informatie te verkrijgen. De voornaamste data die zo opgevraagd kan worden is: • Het regelbestand van een toestel op basis van diens UUID en de ID van de gebruiker die ingelogd is op de controller. • De modeldata van de bewegingen die dienen om gebruikers van de controller in te loggen. • De modeldata van alle bewegingen van één gebruiker. Dit gebeurt allemaal conform de WS-Transfer standaard.

6.5.3

Ruby on Rails

We hebben ervoor gekozen de configuratiecomponent te implementeren als webapplicatie en hiervoor gebruik te maken van Ruby on Rails. De functionaliteit van de configuratiecomponent is te raadplegen via REST2 . Laten we er van uitgaan dat het IP-adres van de configuratiecomponent 192.168.0.1 is en dat deze draait op poort 3000. Stel dat we bijvoorbeeld het regelbestand van een toestel met urn:uuid:8F969CE4-3331-4035-9E98-E2FB726C645E/Device/Dummy als UUID willen opvragen voor een gebruiker met 8 als ID, dan kan dit door een HTTP GET -bevraging te sturen naar de URL: http://192.168.0.1:3000/externals/rulesheet.drl?user_id=8&device_uuid= urn:uuid:8F969CE4-3331-4035-9E98-E2FB726C645E/Device/Dummy.

6.5.4

Gebruikersinterface

In sectie 2.4 hebben we ook usability ge¨ıdentificeerd als een belangrijke quality attribute. Eén aspect hiervan is het ontwerpen van een gebruiksvriendelijke interface voor de configuratiecomponent. Aangezien we deze component ge¨ımplementeerd hebben als een web-based applicatie, hoeft de gebruiker geen extra software te installeren op zijn computer. Hij kan gewoon met iedere PC in zijn netwerk, of zelfs van elders via het Internet, de configuratiecomponent bereiken via zijn webbrowser. 2

Een oproep via REST is eigenlijk gewoon een HTTP-GET, PUT, POST of UPDATE oproep

6.6 Communicatie

84

We hebben ook aandacht besteed aan het ontwikkelen van een gebruikersvriendelijke layout voor de configuratie van ons prototype applicatie. Een sfeerbeeld van onze configuratiecomponent is weergegeven in figuur 6.6.

6.6

Communicatie

Om in staat te zijn de concrete invulling van het communicatieraamwerk, zoals besproken in hoofdstuk 4, te verduidelijken, is het noodzakelijk eerst de algemene structuur van een bericht uit te leggen. Daarna kan er overgegaan worden tot het bespreken van de verschillende componenten zoals die in sectie 4.2.2 werden besproken. Als laatste worden dan de belangrijkste berichtsequenties besproken, samen met hun performantie en, als die er al zijn, de bottlenecks.

6.6.1

Een bericht

Het is de bedoeling, zoals vermeld in 1.1.2, dat zo veel mogelijk van de communicatie in de prototype implementatie zal verlopen volgens de Web service-standaarden. In appendix A zullen we verder ingaan op de verschillende types berichten, maar voorlopig volstaat het een algemeen Web servicebericht te bespreken. Een Web service-bericht is in eerste instantie een SOAP-bericht dat, in onze implementatie, voldoet aan de WS-Addressing standaard. Deze standaard definieert de inhoud en de semantiek van verschillende SOAP-headers. We zullen nu een overzicht geven van de belangrijkste headers. • To: Bevat een URI die de identificatie is van de ontvanger van het bericht. Dit is een verplicht element. • ReplyTo: Een URI die de endpoint identificeert waar het antwoord op het huidige bericht naartoe gestuurd moet worden. • Action: Dit is opnieuw een verplicht element dat de semantiek van het bericht beschrijft. Ook dit is een URI. • MessageID: Een unieke URI die het bericht identificeert en gebruikt kan worden om ernaar te refereren. Wij zullen voor hiervoor meestal een UUID genereren. Dit is een verplichte header indien er een antwoord verwacht wordt op het bericht. • RelatesTo: Als het huidige bericht een antwoord is op een ander, bevat dit element de UUID uit het MessageID van het originele bericht. In listing 6.2 hebben we een voorbeeld geplaatst van een Web service-bericht dat voldoet aan de WS Addressing-standaard. Dit is meerbepaald een Probe en bevat de elementen Action, MessageID en To in de SOAP-Header.

Figuur 6.6: De configuratiecomponent die een lijst weergeeft van de devices die op het netwerk aangesloten zijn

6.6 Communicatie 85

6.6 Communicatie

86

< s12:Envelope xmlns:wsa =" http: // www . w3 . org /2005/08/ addressing " xmlns:wsd =" http: // docs . oasis - open . org / ws - dd / ns / discovery /2009/01" xmlns:s12 =" http: // www . w3 . org /2003/05/ soap - envelope " >

< s12:Header > < wsa:Action > http: // docs . oasis - open . org / ws - dd / ns / discovery /2009/01/ Probe < wsa:MessageID > urn:uuid:E9E127B1 -29 E4 -4448 - BC7C -9 EE8796968EB < wsa:To > IP: // be . ugent . ibcn . wsgesture . gateway

< s12:Body > < wsd:Probe > < wsd:Types > Device

Listing 6.2: Voorbeeld van een Probe

6.6.2 6.6.2.1

Componenten Drivers

Een instantie van een type driver heeft gedurende de werking van het systeem altijd een vaste poort waarop geluisterd kan worden en een vaste poort waarop berichten verstuurd worden. Zoals vermeld in sectie 4.2.2 hebben we de drivers voor de verschillende protocollen ingepast in het microkernelpatroon als internal servers. Bijgevolg is het dus mogelijk om nieuwe drivers te implementeren wanneer een nieuw communicatiekanaal moet kunnen worden gebruikt. De enige voorwaarde is dat ze een voorziene abstracte klasse Driver uitbreiden. Een driver moet broadcasts en unicasts kunnen sturen, en dit synchroon of asynchroon, en berichten kunnen ontvangen. Iedere driver bevat bovendien een lijst MessageHandlers. Telkens wanneer een bericht ontvangen wordt door de driver, zal dit aan iedere MessageHandler die zich geregisteerd heeft bij de driver afgeleverd worden. In de praktijk is het de bedoeling dat een service de Interface MessageHandler implementeert en zich via de kernel registreert bij een driver om berichten, ontvangen op de poort van de driver, te krijgen. Deze interface bevat de methode handleRequest waarlangs het ontvangen bericht door de driver kan doorgegeven worden aan de service. Voor ons prototype applicatie werden bijgevolg twee drivers ontwikkeld: één voor Zigbee en één voor Ethernet. Hierbij diende er rekening gehouden te worden met enkele belangrijke technische aspecten die we hier kort zullen toelichten. De Zigbeedriver De SunSPOT Owner’s Manual [36] vermeldt een belangrijke complicatie met betrekking tot het verzenden van berichten in broadcast mode met de SunSPOT. Om een broadcast bericht te sturen wordt het radiogram protocol3 gebruikt. Het wordt afgeraden om berichten 3

Het radiogram protocol voorziet communicatie gebaseerd op datagrams tussen twee toestellen zonder garantie

over de volgorde waarin fragmenten aankomen. De SunSPOT ondersteunt ook een radiostream protocol, dat een

6.6 Communicatie

87

groter dan 200 byte in broadcast mode te versturen. De maximale pakketgrootte van een bericht in broadcast is 1260 bytes aan payload, tevens de maximale groote van een gewoon radiogram, maar de grootte van een 802.15.4 radio fragment bedraagt ongeveer 100 bytes (afhankelijk van de aanwezige headers). Een bericht dat groter is dan 100 bytes zal dus automatisch gefragmenteerd worden. Berichten in broadcast mode die resulteren in twee fragmenten zijn redelijk betrouwbaar te versturen. Berichten die worden gefragmenteerd in drie fragmenten (die dus groter zijn dan 200 bytes) zullen waarschijnlijk aan verlies onderhevig zijn. Bij berichten die in meer dan drie fragmenten gebroken worden zullen er bijna zeker fragmenten verloren gaan. De reden van dit probleem is dat de ontvanger zijn ontvangstbuffer niet tijdig kan ledigen voordat het volgende fragment aankomt en dat het radiogram protocol in broadcast mode geen zekerheid van ontvangst kan garanderen. Het probleem kan nog vergroot worden wanneer de ontvanger regelmatig garbage collection uitvoert of een groot aantal actieve threads heeft. [36] De SunSPOT Owner’s Manual [36] raadt aan dat de applicatie de lengte van zijn berichten in broadcast mode beperkt zodat deze niet resulteren in meer dan drie fragmenten. Ook toevoegen van een pauze van 20 ms tussen het zenden van twee berichten heeft een positief effect. Aangezien wij zullen werken met Web service-berichten, zijn onze berichten heel wat groter dan 200 bytes. Zo is het voorbeeldbericht uit listing 6.2 506 bytes lang. Het is dus zeer waarschijnlijk dat we dataverlies zullen oplopen wanneer we gebruik maken van de standaardvoorzieningen van de SunSPOT. Dit heeft ons doen besluiten zelf een fragmentatiealgoritme te ontwikkelen voor het zenden van berichten over het radiogram protocol. Voor het verzenden van berichten in broadcast besloten we de berichten op te delen in stukken van 100 bytes, bestaande uit een zelfgemaakte header van 2 bytes en een payload van 98 bytes4 , zodat die in één fragment zouden passen. Bovendien wachten we 20 ms tussen het verzenden van twee stukken. De header is als volgt opgebouwd en de samenstelling ervan is gevisualiseerd in figuur 6.7: • isFragmented: Deze bit staat op 1 wanneer het stuk deel uit maakt van een verdeeld bericht. Wanneer het bericht volledig in de payload van één stuk past, staat deze vlag dus op 0. • isLastPart: Een vlag die aangeeft of het stuk het laatste is. • partNumber: Deze 6 bits stellen een natuurlijk getal voor dat het volgnummer van het huidige stuk aanduidt. Deze waarde kan gebruikt worden om te detecteren of een bepaald stuk verloren gegaan is of om te detecteren dat stukken out of order zijn aangekomen. • 1 bit die nog ongebruikt is. Deze hebben we toegevoegd om toekomstige uitbreiding van deze header mogelijk te maken. betrouwbare en gebufferde communicatie gebaseerd op streams voorziet. Dit is in deze applicatie echter niet bruikbaar aangezien beide communicerende entiteiten op voorhand elkaars adres moeten kennen en er dus een vaste connectie moet zijn. [37] Dit maakt dat het radiostream protocol niet flexibel en dynamisch genoeg is voor deze applicatie en dit is ook de reden waarom wij het radiogram protocol gekozen hebben voor alle communicatie. 4 We verdelen dus eigenlijk het oorspronkelijk bericht in stukken van 98 bytes.

6.6 Communicatie

88

Figuur 6.7: Header van een stuk van een bericht in broadcast over Zigbee • Een cyclic redundancy check (CRC) van 7 bits lang die berekend is over de payload van het volledige, originele bericht. Voor het berekenen van deze CRC-7 gebruiken we x7 + x3 + 1 (ook wel voorgesteld als 0x09) als polynoom. Deze polynoom wordt onder andere gebruikt bij de SD geheugenkaarten [38]. Deze CRC zorgt ervoor dat stukken die afkomstig zijn van verschillende berichten van elkaar onderscheiden kunnen worden, wanneer ze door elkaar ontvangen zouden worden. Bovendien is het ook mogelijk met deze CRC transmissiefouten in de payload te ontdekken. We hebben geprobeerd de header zo compact mogelijk te houden, aangezien de grootte van het totale bericht slechts 100 bytes mag zijn. Dit is ook de reden waarom we op bitniveau gewerkt hebben. Het gevolg is dat onze header slechts een overhead van 2% inneemt. Aangezien we 6 bits gebruiken om het nummer van het stuk aan te duiden, kunnen we maximaal 64 stukken doorsturen. En aangezien er 98 bytes in de payload kunnen, kunnen we bijgevolg een bericht met een maximale lengte van 6272 bytes doorzenden. Dit is ruim voldoende. De Probe die als voorbeeldbericht getoond werd in listing 6.2 is immers representatief qua lengte voor berichten die in broadcast gezonden zullen worden5 . Mocht deze grens in de toekomst toch te laag blijken, dan is het mogelijk de voorlopig ongebruikte bit aan te wenden om het partNumber uit te breiden naar 7 bits. Indien dat nog niet voldoende blijkt, kan natuurlijk een extra byte aan de header toegevoegd worden. Het is mogelijk om aan de hand van de informatie die zich in deze header bevindt een robuust communicatiesysteem te maken. In onze prototype implementatie hebben we de Zigbeedriver zo ge¨ımplementeerd dat deze een bericht als verloren beschouwt wanneer er fouten gedetecteerd worden aan de hand van partNumber of de CRC. Wanneer het ontvangen van een bericht gestoord wordt doordat er stukken van een ander bericht tegelijk ontvangen worden, worden deze genegeerd en gaat het originele bericht verloren. Dit is een zeer rudimentair algortime maar voor ons prototype is deze werkwijze zeker bruikbaar. Voor een robuuste commerciële applicatie, waar meerdere controllers tegelijk werken en in het algemeen meerdere gebruikers, moet hier zeker nog extra aandacht aan besteed worden. Voor het zenden van berichten in unicast gebruiken we ook het radiogram protocol, maar in deze mode is de fragmentatie van berichten op de SunSPOT wel betrouwbaar6 . We gebruiken echter wel nog ons eigen fragmentatiesysteem bij unicasts, maar in dit geval kunnen we de grootte van de 5

Een ander type bericht dat in broadcast verzonden zal worden is een Resolve (zie appendixA.2). Dit bericht is

gelijkaardig aan de Probe qua lengte. 6 De reden hiervoor is een onderliggende implementatie aan de hand van een systeem met ACKs [36].

6.6 Communicatie

89

payload vergroten naar 1200 bytes. Het gevolg hiervan is dat we berichten kunnen verzenden met een maximale grootte van 76800 bytes, wat veel groter is dan de standaard maximale berichtgrootte van 1260 bytes [36]. Dit is opnieuw ruim voldoende voor de prototype implementatie. De Ethernetdriver Bij het implementeren van de driver voor Ethernet waren er minder complicaties. Het enige probleem dat we hebben moeten oplossen is ervoor zorgen dat de driver broadcasts negeert die van zichzelf afkomstig zijn. Het is ook belangrijk te vermelden dat we voor de implementatie van deze driver in Java enkel gebruik maken van DatagramPackets die verzonden worden over een DatagramSocket (voor unicast) of een MulticastSocket. Bijgevolg verloopt alle communicatie via User Datagram Protocol (UDP). 6.6.2.2

Kernel

De kernel is onze implementatie van de microkernel uit het gelijknamige patroon dat we uitvoerig besproken hebben in sectie 4.2.1. De kernel is de centrale component die basisfunctionaliteit aanbiedt met betrekking tot het zenden en ontvangen van berichten, zowel in broadcast als in unicast en gebruikt daarvoor de drivers. De kernel is de enige component in het systeem die de drivers rechtstreeks aanspreekt en hij gebruikt de routing table om de correcte driver te selecteren die gebruikt moet worden om het bericht te verzenden. De routing table bespreken we uitgebreider in sectie 6.6.2.3. We willen ook nog opmerken dat we de kernel ge¨ımplementeerd hebben volgens het Singleton-patroon [39]. Een tweede belangrijke functionaliteit is het beheer van de services. De kernel bevat een instantie van alle services en het is de bedoeling dat een client een referentie opvraagt van de service die hij wenst te gebruiken. Om ervoor te zorgen dat de kernel niet telkens gewijzigd moet worden wanneer er een nieuwe service geprogrammeerd wordt, werden de referenties opgeslagen in een map die het Class-object van de service afbeeldt op een instantie ervan. Om deze implementatie te verduidelijken tonen we er een vereenvoudigde implementatie van in listing 6.3. Een instantie van een service kan dan verkregen worden zoals getoond in listing 6.4. public Service getService ( Class service ) {

if (! services . containsKey ( service )) { services . put ( service , service . newInstance ()); }

return ( Service ) services . get ( service ); }

Listing 6.3: Vereenvoudigde implementatie van opslag van services in de kernel (( WSDiscovery ) Kernel . getService ( WSDiscovery . class ))

Listing 6.4: Voorbeeld van het opvragen van de WSDiscovery service

6.6 Communicatie

6.6.2.3

90

Routing table

De routing table bewaart instanties van de drivers op een gelijkaardige manier als de kernel de services beheert. Dit wil dus zeggen dat drivers dynamisch (at runtime) of at development time in en uit het geheugen geladen kunnen worden. Zoals gezegd in sectie 6.6.2.1 heeft iedere instantie van een type driver zijn eigen poort waar hij op luistert naar binnenkomende berichten en die hij gebruikt om berichten op te verzenden. Drivers worden dus ge¨ındexeerd op hun type, zoals ook het geval was bij services, en op hun poort. Verder heeft elk device een uniek protocolID. Er zijn twee manieren waarop een driver door de kernel kan worden opgevraagd aan de routing table: 1. Met het protocolID en het poortnummer. 2. Met het type driver en het poortnummer. Een andere belangrijke functie van de routing table is de URI, die in het to-headerblock staat van ieder bericht (zie sectie 6.6.1), op een XAddress7 afbeelden. Een device kan namelijk meerdere toestellen vertegenwoordigen. Met de URI kan het toestel ge¨ıdentificeerd worden, maar dit kan niet gebruikt worden als transportadres. Met behulp van de routing table kan dit bijhorende transportadres opgezocht worden. Dit is volledig analoog met een DNS-server die HTTP-adressen kan afbeelden op IP-adressen. De routing table wordt gaandeweg ingevuld door het versturen van Probe- en Resolve-berichten. De kernel kan bijgevolg van de routing table gebruik maken om het fysiek adres van een endpoint op de vragen op basis van diens URI (bijvoorbeeld een UUID). 6.6.2.4

Services

De services zijn onze implementaties van de external servers uit het microkernelpatroon en moet naast de Interface MessageHandler (zie sectie 6.6.2.1) ook de klasse Service uitbreiden. Deze klasse zorgt ervoor dat Clients zich kunnen registeren om berichten van een bepaald type te ontvangen. Een service bevat een groepering van functionaliteit die semantisch gezien samen hoort. Zo hebben we onder andere de functionaliteit van de verschillende Web service standaarden in aparte services ge¨ımplementeerd. Hieronder volgt een korte oplijsting van de verschillende services met hun functionaliteit. • WSDiscovery – Verzenden van een Probe. – Verzenden van een Resolve. – Verzenden van een ProbeMatch als antwoord op een Probe. – Verzenden van een ResolveMatch als antwoord op een Resolve. 7

Dit is in de WS-Addressing standaard de benaming voor een fysiek adres dat bruikbaar is bij het verzenden van

bericht op een transportkanaal. Een voorbeeld hiervan is een IP-adres.

6.6 Communicatie

91

• WSEventing – Verzenden van een Subscribe. – Verzenden van een SubscriptionResponse. – Verzenden van een SubscriptionEnd. – Verzenden van een event. Dit is in ons raamwerk een GestureEvent of een DeviceEvent. • WSTransfer – Opvragen van regelbestanden. – Opvragen van modeldata. – Opvragen van ... Een laatste service die werd gemaakt is de WSGesture service. Die staat in voor het versturen van EventingInit-berichten en alle berichten die te maken hebben met de configuratie van het systeem. 6.6.2.5

Clients

Clients zijn de implementatie van de gelijknamige componenten uit het microkernelpatroon dat we besproken hebben in sectie 4.2.1. Deze clients stellen componenten voor binnen het platform die gebruik maken van het communicatieframework. Zo hebben we bijvoorbeeld de mapper ge¨ımplementeerd als een client en ook op een proxy device wordt gebruik gemaakt van clients om een toestel aan te sturen. In onze implementatie moet een client de abstracte klasse Client uitbreiden. Vervolgens kan een client zich registreren bij een service en een type bericht specifiëren waar hij ge¨ınteresseerd in is. Alle berichten van een bepaald type die door de service ontvangen worden, worden na parsen aan alle clients afgeleverd die zich voor dit type bericht geregistreerd hebben. Zo zal bijvoorbeeld een client die de aansturing van een device beheert8 moeten reageren op DeviceEvent-berichten (komende van de WSEventing service) en DeviceState-berichten (komende van de WSGesture service). Aangezien meerdere clients zich kunnen registreren bij iedere service en één client een virtueel toestel voorstelt, is het mogelijk meerdere virtuele toestellen” aan te sturen binnen één device” instantie. Zo hebben we bijvoorbeeld bij de implementatie van ons prototype één proxy device (die een device voorstelt) die twee clients bevat: één om Winamp aan te sturen en één om PowerPoint te bedienen.

6.6.3

Specifieke communicatiemechanismen

In deze sectie beëindigen we de bespreking van het communicatieraamwerk met een overzicht van de belangrijkste berichtsequenties die voorkomen tijdens het normale aansturen van een device en 8

dit is dus een virtueel toestel

6.6 Communicatie

92

Figuur 6.8: Sequentiediagram van het opvragen van het loginmodel door de controller die dus van groot belang zijn voor het real-time karakter en het gebruiksgemak van de prototype implementatie. 6.6.3.1

Opstarten van de controller

Wanneer de gebruiker de controller start zal deze na initialisatie blijven zoeken naar een gateway en een mapper tot hij ze gevonden heeft. Hij doet dit door middel van een Probe-bericht, zoals te zien is in figuur 6.1. Daarna zal hij de modeldata opvragen die gebruikt wordt om gebruikers te herkennen aan de hand van hun persoonlijke beweging. Dit proces wordt gevisualiseerd in figuur 6.8. De controller stuurt de aanvraag naar de gateway en die stuurt de aanvraag door naar de configuratiecomponent. Deze zoekt voor iedere gebruiker de inlogbeweging op, haalt de overeenkomstige data uit de trainingsbewegingen van de gebruiker en stuurt deze geaggregeerde trainingsdata naar de trainer die de HMM-modellen traint aan de hand van deze data. Het is niet mogelijk deze login modeldata te aggregeren uit de modeldata van de verschillende gebruikers aangezien voor deze modeldata tijdens het trainingsalgoritme telkens, per gebruiker, andere clusters opgebouwd werden (zie sectie 5.3.2). Een beschrijving van de modellen wordt dan naar de configuratiecomponent gestuurd en die stuurt deze beschrijving, via de gateway, terug naar de controller. Nu kan een gebruiker inloggen op de controller door het maken van zijn persoonlijke beweging. De reden waarom deze login model data elke keer opnieuw moet getraind worden is omdat de gebruiker te allen tijde zeer eenvoudig via de configuratiecomponent zijn inlogbeweging kan aanpassen. 6.6.3.2

Inloggen op de controller

De gebruiker zal zijn persoonlijke beweging maken om zich in te loggen op de controller. Die zal na het herkennen van de persoonlijke beweging een aanvraag sturen naar de configuratiecomponent

6.7 Performantie

93

om de modeldata van de gebruiker die bij de beweging hoort te verkrijgen. Dit is heel analoog aan het sequentiediagram in figuur 6.8. Het verschil is hier dat de modeldata niet telkens opnieuw getraind hoeft te worden. Dit hoeft slechts één maal te gebeuren, net na het opnemen van de trainingsbewegingen van een gebruiker, zoals beschreven in scenario 2.1.1, en heeft geen invloed op het real-time karakter van het aansturen van een device. Hierna is de controller in het bezit van de modeldata om bewegingen van de gebruiker te herkennen en van de ID van de gebruiker. 6.6.3.3

Ontdekken van devices

Na inloggen zal de gebruiker, via de controller, de devices ontdekken die hij kan aansturen. Dit werd reeds beschreven in sectie 6.1. Hierna kan de gebruiker door de beschikbare devices bladeren en het device dat hij wil aansturen uitkiezen. 6.6.3.4

Opzetten van een koppeling met en aansturen van een device

Het opzetten van een koppeling tussen de controller en het gekozen device, en het bijhorende inschrijven van dat device bij de mapper om DeviceEvents te ontvangen, werd reeds uitgebreid besproken in sectie 6.4.2, alsook het sturen van een event vanuit de controller naar het gekoppelde device.

6.7

Performantie

We sluiten dit hoofdstuk af met een overzicht van verschillende performantiemetingen over: 1. De snelheid van het communicatieframework: • Het versturen van berichten over Zigbee vanuit de controller (een toestel met beperkte rekenkracht) en de gateway (een toestel met een veel grotere rekenkracht). • Het ontvangen van berichten over Zigbee op de controller en op de gateway. • Het marshallen en unmarshallen van berichten op de controller. 2. Het herkennen van een beweging op de controller. 3. De betrouwbaarheid van het Zigbee-protocol in combinatie met ons eigen fragmentatiealgoritme. Er werden ook metingen uitgevoerd op het versturen en ontvangen van berichten over Ethernet en op het marshallen en unmarshallen van berichten op de gateway, maar de bekomen waarden waren onbeduidend klein in vergelijking met de resultaten die we kregen bij de hierboven opgesomde metingen. Ze zijn dus niet van belang bij het bepalen van de performantie van het volledige systeem. Daarna worden deze metingen gebruikt in een praktische analyse van de berichten die belangrijk zijn voor het real-time karakter van de applicatie (zie sectie 6.6.3).

6.7 Performantie

6.7.1 6.7.1.1

94

Snelheid van het communicatieraamwerk Werkwijze

Om de nodige data te verzamelen stuurden we berichten van verschillende en oplopende grootte van de controller naar de gateway en omgekeerd. Er werd gestart bij een berichtgrootte van 500 bytes en in stappen van 500 bytes werd de grootte opgedreven tot 5000 bytes. Ondertussen werd de tijd die nodig was voor het versturen en ontvangen van berichten gemeten. Daarnaast werd ook de tijd nodig om berichten te marshallen en te unmarshallen gemeten. Hiervoor werden twee aparte applicaties ontwikkeld die gezien kunnen worden als een uitgeklede controller en gateway. Dit om zo weining mogelijk interferentie te krijgen van andere processen of threads tijdens het uitvoeren van de testen. 6.7.1.2

Het versturen en ontvangen van berichten over Zigbee

Eerst en vooral is het noodzakelijk een onderscheid te maken tussen multicast- en unicast-berichten. Dit omdat ons fragmentatiealgoritme multicast-berichten in veel kleinere stukken verdeelt (100 bytes) dan de unicast-berichten (1200 bytes) en er tussen het verzenden van ieder stuk 20 ms tijd gelaten wordt (zie sectie 6.6.2.1). In figuur 6.9 zien we de zendtijden en in figuur 6.10 zien we de ontvangsttijden voor multicast-berichten op de SunSPOT. Er is een heel duidelijk lineair verband op te merken tussen de berichtgrootte en de tijd nodig om het bericht te verzenden of te ontvangen, wat enigszins te verwachten was. We zien ook dat het ontvangen en verwerken van een bericht iets minder lang duurt dan het verzenden. Dit kan pas verklaard worden wanneer we de tijden van de gateway ook weten en daar zal dan ook een verklaring gegeven worden. Figuren 6.11 en 6.12 tonen ons respectievelijk de zenden ontvangsttijden voor unicast-berichten op de SunSPOT. We zien opnieuw het lineaire verband tussen de berichtgrootte en de zenden ontvangsttijd maar een belangrijkere conclusie is de snelheidswinst die gemaakt wordt ten opzichte van multicast-berichten. Dit is te wijten aan het fragmentatiealgoritme dat unicast-berichten in grotere stukken verdeelt, en dus minder pauzes van 20 ms zal inlassen in vergelijking met het versturen van multicast-berichten. Vervolgens kunnen we overgaan naar de meetresultaten van de gateway voor het versturen van berichten over Zigbee. Deze resultaten zijn zeer gelijkaardig aan die van de SunSPOT. Ook hier zien we overal een lineair verband tussen de berichtgrootte en de zenden ontvangsttijd. Figuren 6.13 en 6.14 tonen respectievelijk de zenden ontvangsttijden voor multicast-berichten en figuren 6.15 en 6.16 doen hetzelfde voor unicast-berichten. Het eerste wat hier opvalt is dat de zendtijden bij de gateway heel wat lager liggen dan bij de controller. Dit komt voornamelijk omdat de gateway meer rekenkracht heeft dan de SunSPOT. Hierdoor heeft hij bij het verzenden minder last van andere processen of threads die Centrale Verwerkings Eenheid (CVE)-tijd opeisen.

6.7 Performantie

Figuur 6.9: Zendtijden voor multicast-berichten over Zigbee op de SunSPOT

Figuur 6.10: Ontvangsttijden voor multicast-berichten over Zigbee op de SunSPOT

95

6.7 Performantie

Figuur 6.11: Zendtijden voor unicast-berichten over Zigbee op de SunSPOT

Figuur 6.12: Ontvangsttijden voor unicast-berichten over Zigbee op de SunSPOT

96

6.7 Performantie

97

Figuur 6.13: Zendtijden voor multicast-berichten over Zigbee op de gateway Het tweede wat sterk opvalt is dat de ontvangsttijden bij de gateway amper of zelfs niet lager liggen dan de zendtijden. De reden hiervoor is gelijkaardig aan de reden waarom het ontvangen op de SunSPOT zo veel sneller gaat dan het verzenden. De ontvanger kan eenvoudigweg niet sneller ontvangen dan de snelheid waaraan de zender kan verzenden. Concreet: • De SunSPOT kan door een beperkte rekenkracht minder snel verzenden dan de gateway. Hierdoor kan de gateway natuurlijk niet snel ontvangen. • De gateway kan op zijn beurt dan weer een stuk sneller verzenden dan de SunSPOT waardoor de data er veel sneller binnen komt dan op de gateway. Een algemene conclusie die we nu al kunnen trekken, en die we ook verwachtten, is dat het versturen van data over Zigbee voor een behoorlijk grote delay zorgt. Dit was dan ook een reden voor beslissingen, zoals diegene genomen in sectie 3.2.2, die er voor zorgen dat er zo weining mogelijk berichten gestuurd hoeven te worden over het Zigbee-kanaal. 6.7.1.3

Marshallen en unmarshallen van berichten op de SunSPOT

In figuren 6.17 en 6.18 staan de marshall en unmarshal tijden van berichten in functie van de berichtgrootte. Opnieuw zien we hier een logisch en verwacht lineair verband. Bij unmarshallen zien we bij hogere berichtgroottes iets meer variatie. Dit valt volledig te verklaren door andere processen of threads, zoals garbage collection die op dat moment ook CVE-tijd opeisen. We kunnen stellen dat de invloed van het marshallen en unmarshallen van berichten op de performantie van

6.7 Performantie

Figuur 6.14: Ontvangsttijden voor multicast-berichten over Zigbee op de gateway

Figuur 6.15: Zendtijden voor unicast-berichten over Zigbee op de gateway

98

6.7 Performantie

99

Figuur 6.16: Ontvangsttijden voor unicast-berichten over Zigbee op de gateway het communicatieraamwerk heel wat kleiner zal zijn dan het versturen van de berichten, maar dat deze invloed toch niet genegeerd mag worden.

6.7.2

De duurtijd van het herkennen van een beweging op de controller

De duurtijd van een herkenning hangt af van de duurtijd van de beweging, en dus de hoeveelheid samples die verwerkt moeten worden bij de herkenning. Na enkele tests bleek de duurtijd voor de gebruikte set van bewegingen te variëren tussen 150 ms en 200 ms. Dit heeft dus bij het aansturen van een device nog altijd een belangrijke invloed.

6.7.3

Betrouwbaarheid van het Zigbee-protocol

Gezien radiograms zekerheid van afleveren of een foutmelding geven indien berichten in unicast gezonden worden moet hiervan de betrouwbaarheid niet gecontroleerd worden. Waar we tijdens het ontwikkelen wel, zij het zelden, mee geconfronteerd werden, zijn multicast-berichten die soms niet aankomen. Dit gaf aanleiding tot een onderzoek naar de betrouwbaarheid van broadcasts, zoals een Probe-bericht, in combinatie met ons eigen fragmentatiesysteem. Hiervoor werden 2000 berichten van 2475 byte, ofwel 26 pakketten in ons eigen fragmentatiesysteem, verzonden. Slechts 1 pakket, en dus 1 bericht, ging hierbij verloren. We kunnen hieruit met zekerheid concluderen dat het broadcasten van berichten betrouwbaar is. Herinner dat de standaardimplementatie reeds onbetrouwbaar was vanaf drie pakketten.

6.7 Performantie

100

Figuur 6.17: Marshaltijden voor berichten op de SunSPOT

Figuur 6.18: Unmarshaltijden voor berichten op de SunSPOT

6.7 Performantie

6.7.4

101

Praktische analyse van de berichten

Als laatste geven we de analyse van de berichtsequenties, opnieuw in volgorde van voorkomen (zoals in sectie 6.6.3), zonder uit te wijden over de semantiek van de berichten. We bespreken hierbij enkel de duurtijd van de sequentie. Zoals eerder vermeld bespreken we hierbij de vertragingen door het versturen van een bericht over Ethernet, of het marshallen of unmarshallen op een krachtige machine zoals de gateway niet. Deze vallen immers in het niets bij de vertragingen die Zigbee en de SunSPOT opleveren. Voor we beginnen bespreken we eerst nog de notatie op de figuren: • Pijlen (berichten) van de controller naar de gateway: (berichtgrootte, tijd om te marshallen, zendtijd). • Pijlen (berichten) van de gateway naar de controller : (berichtgrootte, zendtijd, tijd om te unmarshallen). De tijden zijn zoals steeds uitgedrukt in milliseconden. De conclusies van dit werk, en vooral van deze metingen zullen we bespreken in het volgende en laatste hoofdstuk.

6.7 Performantie

6.7.4.1

102

Probe vanuit de controller

Figuur 6.19: Sequentiediagram van een Probe vanuit de controller met relevante tijdswaarden

6.7.4.2

Opvragen van het login model

Figuur 6.20: Sequentiediagram van het opvragen van het login model met relevante tijdswaarden

6.7.4.3

Opvragen van het gebruikersmodel bij inloggen

Figuur 6.21: Sequentiediagram van het opvragen van het gebruikersmodel met relevante tijdswaarden

6.7 Performantie

6.7.4.4

Versturen van een EventingInit bij het koppelen van de controller en een device

Figuur 6.22: Sequentiediagram van een EventingInit met relevante tijdswaarden

6.7.4.5

103

Versturen van een Event bij het aansturen van een device

Figuur 6.23: Sequentiediagram van een Event met relevante tijdswaarden

CONCLUSIE

104

Hoofdstuk 7

Conclusie Yes, now we know. At least we know what we sought in the beginning. But there is still the question: why? And this question will go on and on until the final answer comes. Then the knowing is so full, there is no room for questions. The Log Lady, Twin Peaks

In dit afsluitende hoofdstuk vergelijken we onze originele doelen met de behaalde resultaten, te beginnen bij gesture recognition. In het kader van de quality attributes performance en usability is het cruciale punt voor onze prototype implementatie inzake gesture recognition de herkenning. Een beweging moet met een aanvaardbare vertraging herkend worden op de SunSPOT, een toestel met beperkte rekencapaciteiten, terwijl de accuraatheid van de herkenning werkbaar moet blijven. De metingen in secties 5.5 en 6.7.2 tonen aan dat we in dit opzet geslaagd zijn. Hoewel de vertraging die de herkenning met zich mee brengt nog licht merkbaar is, is deze zeker werkbaar. Bovendien werden er ook enkele aandachtspunten ge¨ıdentificeerd waar rekening mee gehouden moet worden bij het implementeren van een commerciële oplossing. Een tweede doel in dit werk was het ontwerpen van een architectuur die het toe zou laten at runtime dynamisch toestellen te ontdekken en te selecteren, een koppeling op te zetten met een toestel en vervolgens dit toestel aan te sturen. Dit werd mogelijk gemaakt door het gebruik van de geschikte Web service standaarden. Verder moest het ook mogelijk zijn om vlot het systeem at development time aan te passen wanneer toestellen, die gebruik maken van een nog niet ondersteund communicatiekanaal, toegevoegd worden. Aan deze eis werd voldaan door het ontwerp van een communicatieraamwerk aan de hand van het microkernelpatroon. Op deze manier werden ook de eisen omtrent de quality attribute modifiability vervuld.

CONCLUSIE

105

Met betrekking tot performance en usability hebben we ook testen uitgevoerd op het communicatieraamwerk. De belangrijkste berichtensequenties hierbij zijn diegene die zorgen voor de koppeling met een toestel en het aansturen ervan. Hierbij kunnen twee factoren onderscheiden worden die samen voor bijna 100% van de vertraging zorgen: • De herkenning van een beweging op de SunSPOT. Dit geldt uiteraard enkel voor het aansturen van een toestel. Hieraan kunnen we niet veel meer verbeteren. Er werd reeds veel in het werk gesteld om een goede balans te vinden tussen performantie en accuraatheid. • Het marshallen en unmarshallen van een bericht samen met het versturen ervan. De oorzaak van de vertragingen hier ligt uiteraard bij de grootte van de berichten die over Zigbee verstuurd moeten worden. Werken met de Web service standaarden is in dit geval een afweging tussen snelheid en genericiteit. Men zou er hier dan ook voor kunnen kiezen om met meer compacte berichten te werken. Dit houdt wel het risico in de quality attribute modifiability, die als zeer belangrijk werd bestempeld, te schenden. Een bijkomend effect van het gebruik van Web services is dat de verschillende componenten binnen ons systeem losjes gekoppeld zijn. Dit heeft op zich een positief effect op schaalbaarheid. In onze prototype implementatie is het echter wel zo dat alle data van de ontdekte toestellen verzonden moet worden over het Zigbee-kanaal naar de SunSPOT. Dit heeft als gevolg dat de zendtijd van dit bericht (het ProbeMatches-bericht) lineair zal oplopen met het aantal toestellen (zie sectie 6.7.1.2). Dit heeft op zich echter geen invloed op het aansturen van de toestellen zelf. Een laatste doelstelling was het verwezenlijken van een toestandsafhankelijke afbeelding van bewegingen op acties. Dit werd gerealiseerd door gebruik te maken van een regelgebaseerd systeem. Het gevolg hiervan is dat een toestel meerdere toestanden tegelijk kan hebben, dat een beweging in iedere toestand dezelfde betekenis kan hebben en dat toestanden gemakkelijk gewijzigd kunnen worden zonder dat het beheer hiervan hopeloos ingewikkeld wordt. Het is dus duidelijk dat alle vooropgestelde doelen gehaald werden. Toch blijven er zeker nog heel wat mogelijkheden open om de prototype applicatie verder te ontwikkelen en te verbeteren en eventueel klaar te maken voor commercieel gebruik. Als laatste worden dan ook nog enkele van die mogelijkheden ge¨ıdentificeerd en voorgesteld. • Zoals op het einde van het hoofdstuk over gesture recognition werd gezegd, zijn er zeker nog mogelijkheden tot verbetering. Onder die mogelijkheden identificeren we onder andere het toevoegen van andere types noise, noise berekenen met een genetisch algoritme, het bepalen van de ideale parameters voor iedere gebruiker afzonderlijk,... Meer informatie over deze voorstellen is te vinden in sectie 5.6. • Er zou ook nog kunnen worden onderzocht of er een compacter formaat mogelijk is als alternatief voor Web services, met als voorwaarde dat de huidige behaalde doelstellingen met

CONCLUSIE

106

betrekking tot modifiability en genericiteit behouden blijven. • Het zelfgemaakte fragmentatiealgoritme voor berichten over Zigbee staat nog in zijn kinderschoenen. Om een vlottere en flexibelere werking toe te laten moet dit algoritme zeker nog uitgebreid worden met bijvoorbeeld het herordenen van pakketten die in de verkeerde volgorde aankomen. • Op dit moment kunnen regelbestanden enkel gemaakt en aangepast worden in hun pure tekstvorm. Het zou voor een gebruiker heel wat aangenamer zijn om hierbij geassisteerd te worden door de UI. Zo zou men kunnen aan een toestel zijn toestanden opvragen, samen met de acties mogelijk in iedere toestand, zodat de gebruiker enkel nog bewegingen aan acties in toestanden moet toekennen. Hieruit zou dan automatisch het regelbestand opgesteld worden. • De applicatie zou de gebruiker ook kunnen assisteren bij het koppelen van twee (of meerdere) toestellen. Uit hun regelbestand zouden dan acties en toestanden kunnen gedestilleerd worden die compatibel zijn. Na het toekennen van bewegingen aan acties kan er dan een nieuw regelbestand, en eventueel ook een nieuw virtueel toestel, gegenereerd worden. In dit werk werd er aangetoond dat de ontworpen architectuur en de prototype implementatie aan de vooropgestelde quality attributes voldoen. Wij zijn er dus vast van overtuigd dat er, rekening houdende met deze werkpunten, een applicatie gemaakt kan worden die zijn ingang kan vinden in veel gezinnen en een einde kan maken aan de irritaties die de schier eindeloos grote collectie afstandsbedieningen met zich meebrengt. Wij hebben in ieder geval het voorbije academiejaar met veel interesse en enthousiasme aan deze scriptie gewerkt. We zijn vooral fier op de diepgang die we gebracht hebben in gesture recognition en het ontwerp van het communicatieraamwerk. Ook zijn we trots op de manier waarop we gedurende dit laatste academiejaar samen gewerkt hebben. Conflicten zijn er tussen ons nauwelijks geweest en de verstandhouding en productiviteit was van een constant hoog niveau. Het was, ondanks het harde werken, een zeer memorabel academiejaar.

Rob Vanden Meersche Kristof Vandermeeren mei 2010 Not every end is the goal. The end of a melody is not its goal, and yet if a melody has not reached its end, it has not reached its goal. A parable. Friedrich Nietzsche

WEB SERVICE BERICHTEN

Bijlage A

Web service berichten A.1

Probe en ProbeMatch

< s12:Envelope xmlns:s12 =" http: // www . w3 . org /2003/05/ soap - envelope " xmlns:wsa =" http: // www . w3 . org /2005/08/ addressing " >

< s12:Header > < wsa:Action > http: // docs . oasis - open . org / ws - dd / ns / discovery /2009/01/ Probe < wsa:MessageID > urn:uuid:7ED42224 - DB36 -498 E - B899 -20 AA2E988DF2 < wsa:To > urn:docs - oasis - open - org:ws - d d : n s : d i s c o v e r y : 2 0 0 9 : 0 1

< s12:Body xmlns:wsd =" http: // docs . oasis - open . org / ws - dd / ns / discovery /2009/01" > < wsd:Probe > < wsd:Types > Mapper

Listing A.1: Voorbeeld van een Probe-bericht < s12:Envelope xmlns:wsd =" http: // docs . oasis - open . org / ws - dd / ns / discovery /2009/01" xmlns:s12 =" http: // www . w3 . org /2003/05/ soap - envelope " xmlns:wsa =" http: // www . w3 . org /2005/08/ addressing " >

< s12:Header > < wsa:Action > http: // docs . oasis - open . org / ws - dd / ns / discovery /2009/01/ ProbeMatches < wsa:MessageID > urn:uuid:76D90C3A -839 A -4642 - B63C -94 D4FD3CA26A < wsa:To > http: // www . w3 . org /2005/08/ addressing / anonymous < wsa:RelatesTo w s a : R e l a t i o n s h i p T y p e =" http: // www . w3 . org /2005/08/ addressing / reply " > urn:uuid:7ED42224 - DB36 -498 E - B899 -20 AA2E988DF2

< s12:Body > < wsd:ProbeMatches > < wsd:Prob eMatch > < wsa:EndpointReference > < wsa:Address > urn:uuid:78D741A2 - D704 -417 D -8 B49 -06 F54251F89E < mex:Metadata xmlns:mex =" http: // schemas . xmlsoap . org / ws /2004/09/ mex " >

107

A.2 Resolve en ResolveMatch

108

< mex:MetadataSection mex:Dialect =" http: // www . ibcn . intec . ugent . be / wsgesture / ledcolorid " > < wsgesture:LEDColorIdentifier x ml ns :w s ge st u re =" http: // www . ibcn . intec . ugent . be / wsgesture " >0 255

0

< wsd:Types > Gateway Mapper Trainer < wsd:Scopes > Kelder < wsd:XAddrs > Zigbee: //0014.4 F01 .0000.6 D99 < w s d : M e t a d a t a V e r s i o n > 1274197566459

Listing A.2: Voorbeeld van een ProbeMatches-bericht

A.2

Resolve en ResolveMatch


< s12:Header > < wsa:Action > http: // docs . oasis - open . org / ws - dd / ns / discovery /2009/01/ Resolve < wsa:MessageID > uuid:D70FA1F4 - A3CC -4283 - A924 - BF6A6E4B6FA1 < wsa:To > urn:docs - oasis - open - org:ws - d d : n s : d i s c o v e r y : 2 0 0 9 : 0 1

< s12:Body xmlns:wsd =" http: // docs . oasis - open . org / ws - dd / ns / discovery /2009/01" > < wsd:Resolve > < wsa:EndpointReference > < wsa:Address > urn:uuid:8F969CE4 -3331 -4035 -9 E98 - E2FB726C645E / Device / Winamp

Listing A.3: Voorbeeld van een Resolve-bericht < s12:Envelope xmlns:wsd =" http: // docs . oasis - open . org / ws - dd / ns / discovery /2009/01" xmlns:s12 =" http: // www . w3 . org /2003/05/ soap - envelope " xmlns:wsa =" http: // www . w3 . org /2005/08/ addressing " >

< s12:Header > < wsa:Action > http: // docs . oasis - open . org / ws - dd / ns / discovery /2009/01/ Resol veMatche s < wsa:MessageID > urn:uuid:05D7029A -6 ED1 -467 F - B614 -886408 E01713 < wsa:To > http: // www . w3 . org /2005/08/ addressing / anonymous < wsa:RelatesTo w s a : R e l a t i o n s h i p T y p e =" http: // www . w3 . org /2005/08/ addressing / reply " > uuid:D70FA1F4 - A3CC -4283 - A924 - BF6A6E4B6FA1

A.3 EventingInit

109

< s12:Body > < wsd:ResolveMatches > < wsd:ResolveMatch > < wsa:EndpointReference > < wsa:Address > urn:uuid:8F969CE4 -3331 -4035 -9 E98 - E2FB726C645E < wsd:Types > Device / Winamp Device / Dummy < wsd:XAddrs > IP: //172.1 6.65.14 < w s d : M e t a d a t a V e r s i o n > 1274190962140

Listing A.4: Voorbeeld van een ResolveMatch-bericht

A.3

EventingInit

< s12:Envelope x ml ns : ws ge st u re =" http: // www . ibcn . intec . ugent . be / wsgesture " xmlns:s12 =" http: // www . w3 . org /2003/05/ soap - envelope " xmlns:wsa =" http: // www . w3 . org /2005/08/ addressing " >

< s12:Header > < wsa:Action > http: // www . ibcn . intec . ugent . be / wsgesture / EventingInit < wsa:MessageID > urn:uuid:462258C3 - BF3E -4 FD2 -90 BF - D56890DB6A9B < wsa:To > urn:uuid:8F969CE4 -3331 -4035 -9 E98 - E2FB726C645E / Device / Winamp

< s12:Body > < wsgesture:EventingInit > < w s g e s t u r e : E v e n t S o u r c e T y p e > Mapper < w s g e s t u r e : E v e n t S o u r c e U U I D > urn:uuid:78D741A2 - D704 -417 D -8 B49 -06 F54251F89E < w s g e s t u r e : U s e r I D >8

Listing A.5: Voorbeeld van een EventingInit-bericht

A.4 Subscribe en SubscriptionResponse

A.4

Subscribe en SubscriptionResponse

< s12:Envelope xmlns:wse =" http: // schemas . xmlsoap . org / ws /2004/08/ eventing " xmlns:s12 =" http: // www . w3 . org /2003/05/ soap - envelope " xmlns:wsa =" http: // www . w3 . org /2005/08/ addressing " >

< s12:Header > < wsa:Action > http: // schemas . xmlsoap . org / ws /2004/08/ eventing / Subscribe < wsa:MessageID > urn:uuid:0FE9823E -30 C0 -4052 - ADCE -555 B2D4A8AC5 < wsa:To > urn:uuid:78D741A2 - D704 -417 D -8 B49 -06 F54251F89E / Mapper

< s12:Body x ml n s: ws g es tu re =" http: // www . ibcn . intec . ugent . be / wsgesture " > < wse:Subscribe > < wse:EndTo > < wsa:Address > urn:uuid:8F969CE4 -3331 -4035 -9 E98 - E2FB726C645E / Device < wse:Delivery > < wse:NotifyTo > < wsa:Address > urn:uuid:8F969CE4 -3331 -4035 -9 E98 - E2FB726C645E / Device / Winamp < w s g e s t u r e : U s e r I D >8

Listing A.6: Voorbeeld van een Subscribe-bericht < s12:Envelope xmlns:s12 =" http: // www . w3 . org /2003/05/ soap - envelope " xmlns:wsa =" http: // www . w3 . org /2005/08/ addressing " >

< s12:Header > < wsa:Action > http: // schemas . xmlsoap . org / ws /2004/08/ eventing / S u b s c r i b e R e s p o n s e < wsa:MessageID > urn:uuid:36FDDC5A -71 D2 -4 D8D - B1A2 - C6E0BBA39B99 < wsa:To > http: // www . w3 . org /2005/08/ addressing / anonymous < wsa:RelatesTo w s a : R e l a t i o n s h i p T y p e =" http: // www . w3 . org /2005/08/ addressing / reply " > urn:uuid:0FE9823E -30 C0 -4052 - ADCE -555 B2D4A8AC5

< s12:Body xmlns:wse =" http: // schemas . xmlsoap . org / ws /2004/08/ eventing " > < wse:SubscribeResponse > < wse:SubscriptionManager > < wsa:Address > urn:uuid:78D741A2 - D704 -417 D -8 B49 -06 F54251F89E < wsa:ReferenceParameters > < wse:Iden tifier > uuid:9F99B28B -879 A -4 FD9 -985 C - E88913B27208

Listing A.7: Voorbeeld van een SubscriptionResponse-bericht

110

A.5 SubscriptionEnd

A.5

111

SubscriptionEnd

< s12:Envelope xmlns:s12 =" http: // www . w3 . org /2003/05/ soap - envelope " xmlns:wsa =" http: // www . w3 . org /2005/08/ addressing " xmlns:wse =" http: // www . w3 . org /2009/09/ ws - evt " >

< s12:Header > < wsa:Action > http: // www . w3 . org /2009/09/ ws - evt / Su bs c ri pt io n En d < wsa:To > http: // www . example . com / MyEventSink

< s12:Body > < wse:SubscriptionEnd > < wse:Status > w s e : S o u r c e S h u t t i n g D o w n < wse:Iden tifier > uuid:9F99B28B -879 A -4 FD9 -985 C - E88913B27208

Listing A.8: Voorbeeld van een SubscriptionEnd -bericht

A.6

GestureEvent en DeviceEvent


< s12:Header > < wsa:Action > http: // www . ibcn . intec . ugent . be / wsgesture / GestureEvent < wsa:MessageID > urn:uuid:D90BCA0E - BA45 -47 EB -8285 - A25D7C9CF28C < wsa:To > urn:uuid:78D741A2 - D704 -417 D -8 B49 -06 F54251F89E / Mapper

< s12:Body x ml n s: ws g es tu re =" http: // www . ibcn . intec . ugent . be / wsgesture " xmlns:wse =" http: // schemas . xmlsoap . org / ws /2004/08/ eventing " > < wsgesture:GestureEvent > < w s g e s t u r e : G e s t u r e T y p e > play < w s e : S u b s c r i p t i o n I d > uuid:9F99B28B -879 A -4 FD9 -985 C - E88913B27208

Listing A.9: Voorbeeld van een GestureEvent-bericht < s12:Envelope xmlns:s12 =" http: // www . w3 . org /2003/05/ soap - envelope " xmlns:wsa =" http: // www . w3 . org /2005/08/ addressing " >

< s12:Header > < wsa:Action > http: // www . ibcn . intec . ugent . be / wsgesture / DeviceEvent < wsa:MessageID > urn:uuid:4F798A49 - CDC2 -4 F00 -8 C84 -23 C11BB927CC < wsa:To > urn:uuid:8F969CE4 -3331 -4035 -9 E98 - E2FB726C645E / Device / Winamp

< s12:Body x ml n s: ws g es tu re =" http: // www . ibcn . intec . ugent . be / wsgesture " >

A.7 GetDeviceState (Get, WS-Transfer) en DeviceState (GetResponse, WS-Transfer)

112

< w s g e s t u r e : D e v i c e E v e n t > pause

Listing A.10: Voorbeeld van een DeviceEvent-bericht

A.7

GetDeviceState (Get, WS-Transfer) en DeviceState (GetResponse, WS-Transfer)


< s12:Header > < wsa:Action > http: // schemas . xmlsoap . org / ws /2004/09/ transfer / Get < wsa:MessageID > uuid:72E4B48B - EA72 -47 CF - A96B - A944E402FFF2 < wsa:To > urn:uuid:8F969CE4 -3331 -4035 -9 E98 - E2FB726C645E / Device / Winamp

< s12:Body xmlns:wxf =" http: // schemas . xmlsoap . org / ws /2004/09/ transfer " xmlns:mex =" http: // schemas . xmlsoap . org / ws /2004/09/ mex " x ml ns :w s ge st ur e =" http: // www . ibcn . intec . ugent . be / wsgesture " > < wxf:Get mex:Dialect =" http: // www . ibcn . intec . ugent . be / wsgesture / deviceState " / >

Listing A.11: Voorbeeld van een GetDeviceState-bericht < s12:Envelope xmlns:s12 =" http: // www . w3 . org /2003/05/ soap - envelope " xmlns:wsa =" http: // www . w3 . org /2005/08/ addressing " >

< s12:Header > < wsa:Action > http: // schemas . xmlsoap . org / ws /2004/09/ transfer / GetResponse < wsa:MessageID > uuid:979739BA - E482 -4 C8F -9 C26 - CA0A1584725D < wsa:To > http: // www . w3 . org /2005/08/ addressing / anonymous < wsa:RelatesTo w s a : R e l a t i o n s h i p T y p e =" http: // www . w3 . org /2005/08/ addressing / reply " > uuid:72E4B48B - EA72 -47 CF - A96B - A944E402FFF2

< s12:Body xmlns:wxf =" http: // schemas . xmlsoap . org / ws /2004/09/ transfer " x ml ns :w s ge st ur e =" http: // www . ibcn . intec . ugent . be / wsgesture " > < wxf :G e tR es po n se > < w s g e s t u r e : D e v i c e S t a t e > playing

Listing A.12: Voorbeeld van een DeviceState-bericht

A.8 FeedbackIdentifier

A.8

FeedbackIdentifier

< s12:Envelope xmlns:s12 =" http: // www . w3 . org /2003/05/ soap - envelope " xmlns:wsa =" http: // schemas . xmlsoap . org / ws /2004/08/ addressing " xml ns :w s ge st u re =" http: // www . ibcn . intec . ugent . be / wsgesture " >

< s12:Header > < wsa:Action > http: // www . ibcn . intec . ugent . be / wsgesture / F e e d b a c k I d e n t i f i e r < wsa:MessageID > urn:uuid:54AD7A6E -5 A74 -4 ABC - BA29 -2 D0CCA5EC6BD < wsa:To > urn:uuid:8F969CE4 -3331 -4035 -9 E98 - E2FB726C645E / Device / Dummy

< s12:Body > < wsgesture:FeedbackIdentifier > < w s g e s t u r e : F e e d b a c k C o l o r > 255 0 0

Listing A.13: Voorbeeld van een FeedbackIdentifier -bericht

A.9

StartCollection en StopCollection


< s12:Header > < wsa:Action > http: // www . ibcn . intec . ugent . be / wsgesture / S t ar tC ol l ec ti o n < wsa:MessageID > urn:uuid:2785BA73 -9 E24 -42 D0 - B828 -305505 B19408 < wsa:To > 0014.4 F01 .0000.6 D27 / Controller

< s12:Body > < wsgesture:StartCollection > < w s g e s t u r e : T r a i n i n g I D > 14

Listing A.14: Voorbeeld van een StartCollection-bericht

113

A.10 Opvragen van de modeldata (Get, WS-Transfer)


< s12:Header > < wsa:Action > http: // www . ibcn . intec . ugent . be / wsgesture / Stop Collecti on < wsa:MessageID > urn:uuid:D471342B -8312 -4 BBA -91 B6 -309 BC42969A7 < wsa:To > 0014.4 F01 .0000.6 D27 / Controller

< s12:Body >

Listing A.15: Voorbeeld van een StopCollection-bericht

A.10

Opvragen van de modeldata (Get, WS-Transfer)


< s12:Header > < wsa:Action > http: // schemas . xmlsoap . org / ws /2004/09/ transfer / Get < wsa:MessageID > uuid:CDAF13B7 -42 D7 -4 FB7 - B47E -8 EBD9604E822 < wsa:To > urn:uuid:78D741A2 - D704 -417 D -8 B49 -06 F54251F89E / Gateway

< s12:Body xmlns:wxf =" http: // schemas . xmlsoap . org / ws /2004/09/ transfer " xmlns:mex =" http: // schemas . xmlsoap . org / ws /2004/09/ mex " mlns: wsgestu re =" http: // www . ibcn . intec . ugent . be / wsgesture " > < wxf:Get mex:Dialect =" http: // www . ibcn . intec . ugent . be / wsgesture / loginModel " / >

Listing A.16: Voorbeeld van een GetLoginModelData-bericht < s12:Envelope xmlns:s12 =" http: // www . w3 . org /2003/05/ soap - envelope " xmlns:wsa =" http: // www . w3 . org /2005/08/ addressing " >

< s12:Header > < wsa:Action > http: // schemas . xmlsoap . org / ws /2004/09/ transfer / Get < wsa:MessageID > uuid:2576DA22 -2192 -4 B75 -87 F9 -9366477 C1304 < wsa:To > urn:uuid:78D741A2 - D704 -417 D -8 B49 -06 F54251F89E / Gateway

< s12:Body xmlns:wxf =" http: // schemas . xmlsoap . org / ws /2004/09/ transfer " xmlns:mex =" http: // schemas . xmlsoap . org / ws /2004/09/ mex " x ml ns :w s ge st ur e =" http: // www . ibcn . intec . ugent . be / wsgesture " > < wxf:Get mex:Dialect =" http: // www . ibcn . intec . ugent . be / wsgesture / userLogi nModel " > < w s g e s t u r e : U s e r G e s t u r e > square

114

A.11 Bericht met modeldata (GetResponse, WS-Transfer)

115

Listing A.17: Voorbeeld van een GetUserModelData-bericht

A.11

Bericht met modeldata (GetResponse, WS-Transfer)


< s12:Header > < wsa:Action > http: // schemas . xmlsoap . org / ws /2004/09/ transfer / GetResponse < wsa:MessageID > uuid:5E772EDE -527 B -4 C1C - A0AF - A240746E3B91 < wsa:To > http: // www . w3 . org /2005/08/ addressing / anonymous < wsa:RelatesTo w s a : R e l a t i o n s h i p T y p e =" http: // www . w3 . org /2005/08/ addressing / reply " > urn:uuid:58289EC8 -4 DD0 -4242 - AE8B -2 D183D98444B

< s12:Body xmlns:wxf =" http: // schemas . xmlsoap . org / ws /2004/09/ transfer " x ml ns :w s ge st ur e =" http: // www . ibcn . intec . ugent . be / wsgesture " > < wxf :G e tR es po n se > < wsgesture:ModelData > < wsgesture:Gestures > < wsgesture:Gesture > square 4 12 0 . 9 9 9 7 6 5 5 2 3 2 9 2 8 8 9 9 2 . 3 4 4 7 6 7 0 7 1 0 9 5 8 6 8 8 E -4 2 . 2 8 8 9 3 9 0 6 2 4 0 4 9 0 7 7 E -17 1 . 0 6 4 2 5 6 8 0 2 3 0 5 5 1 2 E -55 0 . 4 1 1 0 3 4 2 7 6 3 7 4 2 9 6 3 0 . 5 8 8 9 6 5 7 2 3 6 2 5 7 0 3 7 0.0 0.0;0.0 0 . 7 9 5 7 3 2 2 6 9 8 3 0 5 6 4 2 0 . 2 0 4 2 6 7 7 3 0 16 94 3 57 0.0;

...

< wsgesture:Clusters > < w s g e s t u r e : C l u s t e r > 0 . 0 5 1 0 8 7 6 5 2 8 8 4 5 1 2 -0.04528409899383 -1.1313077572148 < w s g e s t u r e : C l u s t e r > -0.7842074883884 -0.24367982527192 -1.1623500436849 < w s g e s t u r e : C l u s t e r > -0.059853378616255 0 . 4 9 8 9 2 3 5 5 64 5 9 4 6 -0.7031048814154

...

< w s g e s t u r e : C l u s t e r > -0.003971104708389 -0.40389904184665 -0.4708755208678

Listing A.18: Voorbeeldbericht van een GetResponse met modeldata in

A.12 Starten van de training (Get, WS-Transfer)

A.12

116

Starten van de training (Get, WS-Transfer)

< s12:Envelope xmlns:s12 =" http: // www . w3 . org /2003/05/ soap - envelope " xmlns:wsa =" http: // schemas . xmlsoap . org / ws /2004/08/ addressing " xmlns:wxf =" http: // schemas . xmlsoap . org / ws /2004/09/ transfer " xml ns :w s ge st u re =" http: // www . ibcn . intec . ugent . be / wsgesture " >

< s12:Header > < wsa:Action > http: // schemas . xmlsoap . org / ws /2004/09/ transfer / Get < wsa:MessageID > urn:uuid:7D154034 -0 A1E -4296 -88 E0 -0 A1312400C37 < wsa:To > IP: // be . ugent . ibcn . wsgesture . trainer

< s12:Body > < wxf:Get Dialect =" http: // www . ibcn . intec . ugent . be / wsgesture / training " > < ![ CDATA [ < GestureXML > < Gestures > < Gesture type =" square " > < Instance > < Sample > <x > 0 . 2 0 6 7 6 6 9 1 7 2 9 3 2 3 3 1 0 . 6 6 8 6 3 5 8 7 5 4 0 2 7 9 2 8 0 . 8 2 4 3 8 2 3 8 4 5 3 2 7 6 0 5 < Sample > <x > 0 . 2 7 1 2 1 3 7 4 8 6 5 7 3 5 7 7 0 . 7 0 0 8 5 9 2 9 1 0 8 4 8 5 5 0 . 9 2 6 4 2 3 2 0 0 8 5 9 2 9 1 2 < Sample > <x > 0 . 3 4 6 4 0 1 7 1 8 5 8 2 1 6 9 7 0 . 8 2 9 7 5 2 9 5 3 8 1 3 1 0 4 2 1 . 0 2 3 0 9 3 4 4 7 9 0 5 4 7 8

...

< Sample > <x > 0 . 5 6 6 5 9 5 0 5 9 0 7 6 2 6 2 1 0 . 4 9 6 7 7 7 6 5 8 4 3 1 7 9 3 8 1 . 3 7 7 5 5 1 0 2 0 4 0 8 1 6 3 4 ]] >

Listing A.19: Voorbeeldbericht voor het starten van de training gestart vanuit de configuratiecomponent

BIBLIOGRAFIE

117

Bibliografie [1] Sun Microsystems, “squawk: Squawk overview,” 2007. https://squawk.dev.java.net/index-more.html. [2] W3C (MIT, ERCIM, Keio), “Web services addressing 1.0 - core,” 2006. http://www.w3.org/TR/ws-addr-core/. [3] OASIS, “Web services dynamic discovery (ws-discovery) version 1.1,” 2009. http://docs.oasis-open.org/ws-dd/discovery/1.1/wsdd-discovery-1.1-spec.html. [4] BEA Systems Inc. and Computer Associates International Inc. and International Business Machines Corporation and Microsoft Corporation Inc and TIBCO Software Inc, “Web services eventing (ws-eventing),” 2006. http://www.w3.org/Submission/WS-Eventing/. [5] W3C (MIT, ERCIM, Keio), “Web services transfer (ws-transfer),” 2010. http://www.w3.org/TR/ws-transfer/. [6] F. Buschmann, Pattern-oriented software architecture: a system of patterns. Wiley, 2002. [7] J. M¨ antyj¨ arvi, J. Kela, P. Korpipää, and S. Kallio, “Enabling fast and effortless customisation in accelerometer based gesture interaction,” in Proceedings of the 3rd international conference on Mobile and ubiquitous multimedia, p. 31, ACM, 2004. [8] A. Wilson and A. Bobick, “Realtime online adaptive gesture recognition,” in wecwis, p. 1270, Published by the IEEE Computer Society, 2000. [9] P. Clements and R. Kazman, Software Architecture in Practice. Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, 2003. [10] D. Sturman, “A brief history of motion capture for computer character animation,” SIGGRAPH 94, Character Motion Systems, Course notes, 1994. [11] T. Saponas, D. Tan, D. Morris, and R. Balakrishnan, “Demonstrating the feasibility of using forearm electromyography for muscle-computer interfaces,” 2008. [12] Z. Prekopcsak, “Accelerometer Based Real-Time Gesture Recognition,” 2008.

BIBLIOGRAFIE

118

[13] T. Pylv¨ an¨ ainen, “Accelerometer based gesture recognition using continuous HMMs,” Pattern Recognition and Image Analysis, pp. 639–646, 2005. [14] Sun Microsystems, Inc., Sun SPOT Theory of Operation Red Release 5.0. 2009. [15] R. Duda, P. Hart, and D. Stork, Pattern classification. Citeseer, 2001. [16] J.-M. Fran¸cois, “jahmm: An implementation of hidden markov models in java,” 2009. http://code.google.com/p/jahmm/. [17] R. Lawrence and A. Rabiner, “A tutorial on hidden Markov models and selected applications in speech recognition,” Proceedings of the IEEE, vol. 77, no. 2, pp. 257–286, 1989. [18] J.-M. Fran¸cois, “Jahmm v0.6.1,” 2006. http://jahmm.googlecode.com/files/jahmm-0.6.1-userguide.pdf. [19] L. Baum, T. Petrie, G. Soules, and N. Weiss, “A maximization technique occurring in the statistical analysis of probabilistic functions of Markov chains,” The Annals of Mathematical Statistics, vol. 41, no. 1, pp. 164–171, 1970. [20] A. Viterbi, “Error bounds for convolutional codes and an asymptotically optimum decoding algorithm,” IEEE transactions on Information Theory, vol. 13, no. 2, pp. 260–269, 1967. [21] R. Dugad and U. Desai, “A tutorial on hidden markov models,” 1996. [22] M. Ghazvini, M. Vahabi, M. Rasid, R. Abdullah, and W. Musa, “Low Energy Consumption MAC Protocol for Wireless Sensor Networks,” in Sensor Technologies and Applications, 2008. SENSORCOMM’08. Second International Conference on, pp. 49–54, 2008. [23] T. Schl¨ omer, B. Poppinga, N. Henze, and S. Boll, “Gesture recognition with a Wii controller,” in Proceedings of the 2nd international conference on Tangible and embedded interaction, pp. 11–14, ACM, 2008. [24] J. Kela, P. Korpip¨ a¨ a, J. Mäntyjärvi, S. Kallio, G. Savino, L. Jozzo, and S. Marca, “Accelerometer-based gesture control for a design environment,” Personal and Ubiquitous Computing, vol. 10, no. 5, pp. 285–299, 2006. [25] S. Kay, “Can detectability be improved by adding noise?,” IEEE signal processing letters, vol. 7, no. 1, pp. 8–10, 2000. [26] J. Nielsen, “Usability Engineering, Morgan Kaufmann,” San Francisco, 1994. [27] Systronix, “Benchmark 1.1d,” 2009. http://www.practicalembeddedjava.com/benchmark/11a/benchmark_11d.html. [28] Systronix, “Benchmark 1.1b,” 2007. http://www.practicalembeddedjava.com/benchmark/11a/benchmark_11b.html.

BIBLIOGRAFIE

119

[29] S. Lloyd, “Least squares quantization in PCM,” IEEE Transactions on Information Theory, vol. 28, no. 2, pp. 129–137, 1982. [30] The MathWorks and the National Institute of Standards and Technology (NIST), “Jama : A java matrix package,” 2005. http://math.nist.gov/javanumerics/jama/. [31] J. Hunter, “Jdom,” 2009. http://www.jdom.org/. [32] Codehaus, “jaxen: universal java xpath engine,” 2008. http://jaxen.codehaus.org/. [33] B. Poppinga, “wiigee: A java-based gesture recognition library for the wii remote,” 2008. http://www.wiigee.org/. [34] Free Software Foundation, Inc, “Gnu lesser general public license,” 2007. http://www.gnu.org/licenses/lgpl.html. [35] JBoss Community, Red Hat, “Drools expert - jboss community,” 2010. http://www.jboss.org/drools/drools-expert.html. [36] Sun Microsystems, Inc., Sun SPOT Owners Manual Red Release 5.0. 2006-2009. [37] Sun Microsystems, Inc., Sun SPOT Developers Guide Red Release 5.0. 2009. [38] SanDisk Corporation, SanDisk Secure Digital Card Product Manual Version 1.9. 2003. [39] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design patterns: elements of reusable object-oriented software. Addison-wesley Reading, MA, 1995.

LIJST VAN FIGUREN

120

Lijst van figuren 1.1

Een SunSPOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2

Visualisatie van doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.3

Opbouw van de Squawk virtuele machine [1] . . . . . . . . . . . . . . . . . . . . . . .

4

1.4

Ontdekken van toestellen in ad-hoc mode: sequentiediagram . . . . . . . . . . . . . .

7

1.5

Ontdekken van toestellen in managed mode: sequentiediagram

7

3.1

Architectuur: Eerste niveau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2

Architectuur: Eerste niveau, verdere uitwerking met de situatie waarbij events recht-

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

streeks naar de devices gestuurd worden (zie sectie 3.2.2) . . . . . . . . . . . . . . . 25 3.3

Architectuur: Tweede niveau, bewegingslogica in de controller . . . . . . . . . . . . . 27

3.4

Architectuur: Tweede niveau, Mapper: situatie waarbij events rechtstreeks naar de devices gestuurd worden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.5

Architectuur: Tweede niveau, Mapper: situatie waarbij events naar de mapper gestuurd worden

3.6

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Architectuur: Eerste niveau, verdere uitwerking met de situatie waarbij events naar de mapper gestuurd worden (zie sectie 3.2.2) . . . . . . . . . . . . . . . . . . . . . . 29

3.7

Architectuur: Tweede niveau, herkenningstrainer in de server . . . . . . . . . . . . . 30

4.1

Een theoretische voorstelling van het microkernelpatroon [6] . . . . . . . . . . . . . . 35

4.2

Het microkernelpatroon toegepast op onze situatie . . . . . . . . . . . . . . . . . . . 36

5.1

De 3 assen van de accelerometer aangeduid op een SunSPOT [14] . . . . . . . . . . . 39

5.2

Organisatie van de input data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.3

Een left-to-right HMM met 5 toestanden . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.4

Effect van tilting op de verdeling van de zwaartekracht op de assen van de accelerometer 46

5.5

Effect van het gebruik van k-means clustering op de performantie. De tijd om 40 gesture instances te herkennen in functie van het aantal toestanden in het HMM. . . 51

5.6

Effect van het gebruik van k-means clustering op de accuraatheid. Het aantal correct herkende gesture instances van 40 herkenningen in functie van het aantal toestanden in het HMM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.7

Types gestures gebruikt bij testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

LIJST VAN FIGUREN

121

5.8

Onder andere Klaas was zo vriendelijk ons te voorzien van testdata. . . . . . . . . . 56

5.9

Effect van noise op de nauwkeurigheid van gesture recognition . . . . . . . . . . . . . 58

5.10 Effect van het aantal originele gesture instances op de nauwkeurigheid van gesture recognition

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.11 Effect van het aantal clusters in k-means clustering met 4 noise instances op de nauwkeurigheid van gesture recognition . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.12 Effect van het aantal clusters in k-means clustering met 6 noise instances op de nauwkeurigheid van gesture recognition . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.13 Effect van het aantal toestanden in het HMM op de nauwkeurigheid van gesture recognition

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.14 Effect van de SNR van de noise op de nauwkeurigheid van gesture recognition . . . . 64 5.15 Effect van de SNR van de noise op de nauwkeurigheid van gesture recognition zonder het gesture type square in de dataset . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.16 Effect van het aantal clusters in k-means clustering op de nauwkeurigheid van gesture recognition met en zonder het gesture type square in de dataset . . . . . . . . . . . 66 5.17 Effect van het aantal clusters in k-means clustering op de nauwkeurigheid van gesture recognition met enkel de bewegingen langs de hoofdassen in de dataset . . . . . . . . 67 6.1

Sequentiediagram van een Probe, gestuurd vanuit de controller om devices te ontdekken 74

6.2

Sequentiediagram van het ontdekken van devices met een Probe vanuit de configuratieapplicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.3

Toestandsdiagram van het controlesysteem op de controller. . . . . . . . . . . . . . . 75

6.4

Sequentiediagram van de koppeling tussen controller en device . . . . . . . . . . . . 80

6.5

Sequentiediagram van het sturen van een event van de controller naar een device . . 82

6.6

De configuratiecomponent die een lijst weergeeft van de devices die op het netwerk aangesloten zijn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.7

Header van een stuk van een bericht in broadcast over Zigbee . . . . . . . . . . . . . 88

6.8

Sequentiediagram van het opvragen van het loginmodel door de controller . . . . . . 92

6.9

Zendtijden voor multicast-berichten over Zigbee op de SunSPOT . . . . . . . . . . . 95

6.10 Ontvangsttijden voor multicast-berichten over Zigbee op de SunSPOT . . . . . . . . 95 6.11 Zendtijden voor unicast-berichten over Zigbee op de SunSPOT . . . . . . . . . . . . 96 6.12 Ontvangsttijden voor unicast-berichten over Zigbee op de SunSPOT . . . . . . . . . 96 6.13 Zendtijden voor multicast-berichten over Zigbee op de gateway . . . . . . . . . . . . 97 6.14 Ontvangsttijden voor multicast-berichten over Zigbee op de gateway . . . . . . . . . 98 6.15 Zendtijden voor unicast-berichten over Zigbee op de gateway . . . . . . . . . . . . . 98 6.16 Ontvangsttijden voor unicast-berichten over Zigbee op de gateway . . . . . . . . . . 99 6.17 Marshaltijden voor berichten op de SunSPOT . . . . . . . . . . . . . . . . . . . . . . 100 6.18 Unmarshaltijden voor berichten op de SunSPOT . . . . . . . . . . . . . . . . . . . . 100 6.19 Sequentiediagram van een Probe vanuit de controller met relevante tijdswaarden . . 102

LIJST VAN FIGUREN

122

6.20 Sequentiediagram van het opvragen van het login model met relevante tijdswaarden 102 6.21 Sequentiediagram van het opvragen van het gebruikersmodel met relevante tijdswaarden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.22 Sequentiediagram van een EventingInit met relevante tijdswaarden . . . . . . . . . . 103 6.23 Sequentiediagram van een Event met relevante tijdswaarden . . . . . . . . . . . . . . 103

LIJST VAN TABELLEN

123

Lijst van tabellen 5.1

Effect van noise op de nauwkeurigheid van gesture recognition . . . . . . . . . . . . . 59

5.2

Effect van het aantal originele gesture instances op de nauwkeurigheid van gesture recognition

5.3

Effect van het aantal clusters in k-means clustering op de nauwkeurigheid van gesture recognition

5.4

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Effect van het aantal toestanden in het HMM op de nauwkeurigheid van gesture recognition

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.5

Effect van de SNR van de noise op de nauwkeurigheid van gesture recognition . . . . 64

5.6

Effect van de SNR van de noise op de nauwkeurigheid van gesture recognition zonder het gesture type square in de dataset . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.7

Effect van het aantal clusters in k-means clustering op de nauwkeurigheid van gesture recognition met en zonder het gesture type square in de dataset . . . . . . . . . . . 65

5.8

Effect van het aantal clusters in k-means clustering op de nauwkeurigheid van gesture recognition met enkel de bewegingen langs de hoofdassen in de dataset . . . . . . . . 68

WS-Gesture: een toestandsbewuste afstandsbediening Kristof Vandermeeren, Rob Vanden Meersche

Recommend Documents