STIC:STIC III (2020)/Jump Analyser
Introduction
Dans le cadre de mes entraînements personnel ainsi que des entraînements d'équipe de volleyball dont je suis l'entraîneur, nous sommes toujours en train de nous battre avec la gravité pour pouvoir s'élever plus haut et ainsi mieux smasher la balle lors d'une attaque. Cependant nous n'avons pas vraiment de moyen de calculer notre performance ni de pouvoir se comparer avec d'autres afin d'envisager des changements de comportement dans le saut pour optimiser celui-ci. Ce projet vise donc à offrir des données qui peuvent être analysées pour mieux pouvoir conseiller les joueurs sur leur apprentissage de la course d'élan au volleyball en maximisant leur détente verticale.
Problème
Depuis quelques semaines, j'entraîne la course d'élan qui permet l'attaque au Volleyball. Je n'ai jamais eu de coach en équipe pour me dire ce que je fait de juste ou non, j'ai tout appris sur le tas. Étant donné que je coach d'autres joueurs, c'est de ma responsabilité de connaître tous les détails liés à cette prise d'élan. La problématique vient surtout du manque de matériel de mesure, que ce soit en terme de hauteur de saut, de vitesse appliquée dans les derniers pas de la course ou de la force retenue par le pied de bloc. Je ne peux donc enseigner à mes joueurs en me basant uniquement sur ce que je vois et c'est souvent impossible de tout remarquer en même temps.
Cahier des charges
Le contexte
Dans le cadre d'entraînements de volleyball, je dois coacher des joueurs et leurs transmettre mes connaissances sur ce sport. Une partie importante de ce sport repose sur la course d'élan dans le vue de réaliser une attaque (un smash). C'est aussi, selon moi, la partie la plus difficile à transmettre en tant que coach. Chaque joueur a sa propre course d'élan, ses propres habitudes et capacités. A l'oeil, il y a beaucoup d'éléments à observer lors d'une course d'élan comme par exemple l'angle d'approche, la vitesse, les pas, la position du centre de gravité, l'utilisation des bras, le positionnement par rapport au filet, ... Difficile de prendre en compte autant d'information en l'espace d'une poignée de secondes et de pouvoir donner un retour complet à l'athlète.
Le public
Le public ciblé par cette solution est évidemment composé de joueurs de volleyball et de moi-même en tant que coach. Les joueurs peuvent donc être de tout âge et composé d'hommes et/ou de femmes. Dans le cadre de mon équipe, les joueurs/joueuses sont âgé(e)s entre 20 et 32 ans.
Les objectifs du projet
L'objectif principal est d'apporter des données sur la hauteur du saut. Cela permettra d'ajouter une dimension supplémentaire dans la vue globale que le coach a d'une course d'élan en particulier afin de proposer des changements à réaliser pour l'athlète afin d'optimiser sa course.
Les besoins et contraintes du projet
Les spécificités du projet sont que la solution doit être légère et non encombrante afin de ne pas gêner l'athlète dans ses mouvements et ne pas altérer ses performances. La mesure ne doit pas forcément être la plus précise tant que celle-ci est la même pour l'ensemble des joueurs (cela permet la comparaison entre les différents sauts d'une même personne ou entre plusieurs personnes). Le dispositif est initialement prévu d'être porté au niveau de la cheville de la jambe gauche.
Les apports théoriques
D'après mes premières recherches, il y a plusieurs moyens de calculer la hauteur d'un saut. La méthode la plus simple, et celle que je vais utiliser par contrainte matérielle, est le calcul selon le temps passé en air. Grâce à la gravité exerçant une accélération constante, il est possible de déterminer la hauteur d'un saut selon le temps passé dans les airs par un joueur. Au moyen d'un accéléromètre, il est possible de pouvoir déterminer le moment du décollage (Take-Off) et le moment de l'atterrissage (Landing).
La présentation du projet
Je pense construire une sorte de bande velcro avec le dispositif à l'intérieur afin de pouvoir l'enlever et le remettre rapidement sans devoir enlever la chaussure. Cela facilitera son usage au sein d'un entraînement. Et c'est surtout plus hygiénique que de partager une même chaussette ;)
Le dispositif tiendra dans une boîte imprimée en 3D et permettant le passage de la sangle à l'intérieur. La batterie sera quant à elle cousue directement sur la sangle. Au moyen d'une application pour android/iOS, le dispositif transmettra les données de son accéléromètre directement sur le smartphone afin de pouvoir, au niveau de l'application, déterminer la hauteur du saut de l'utilisateur.
Solution
Le premier aspect que j'ai pris en compte lors de ma réflexion autour du projet fût la manière de faire tenir mon dispositif sur un joueur ainsi que du meilleur emplacement où le mettre. J'ai décidé instinctivement d'attacher mon dispositif au niveau des chevilles afin d'avoir le meilleur emplacement pour la prise de données sans pour autant devoir créer des chaussures sur mesure. De plus, cet emplacement ne dérange pas le joueur dans sa course d'élan et dans ses mouvements, ce qui conforte mon idée initiale.
L'interrogation évidente qui vient ensuite concerne le fait de faire tenir mon dispositif. Ma première idée fût une espèce de chaussette où le dispositif serait cousu ou une attelle avec le dispositif attaché dessus.
Ces deux idées ont soulevés plusieurs aspects que je n'avais pas prit initialement en compte. Tout d'abord l'utilisabilité au sein d'un entraînement où plusieurs joueurs voudront utiliser le projet. Dans ce cas des questions d'hygiènes se posent et pourraient offrir une expérience négative. Autre aspect utilisabilité, si chaque joueur doit enlever une chaussure pour pouvoir mettre le dispositif en place puis l'enlever à nouveau pour le retirer, cela n'est pas pratique dans le cas d'un grand groupe de joueur.
A partir d'ici, j'ai plutôt imaginé un bandeau élastique où l'on pourrait passer au travers le pied avec la chaussure. Cela m'a inquiété sur le point de la stabilité de celui-ci. Vu que le saut entraînera des forces multidirectionnelles et de grandes forces verticales, il se pourrait que le bandeau se déplace et perturbe les données.
Ma dernière réflexion porte sur une sangle velcro sur laquelle le dispositif serait reliée au moyen d'un petit boîtier imprimé en 3D en nylon afin de ne pas avoir une structure trop rigide et inconfortable.
Le boîtier n'étant pas encore imprimé, il est représenté par ce rectangle blanc issu de son modèle
Problèmes rencontrés
Lors de mes essais de développement avec l'Arduino Nano 33 BLE, j'ai en premier lieu tenter de faire fonctionner le BlueTooth afin de pouvoir tester des applications smartphone permettant de récupérer des informations par ce biais. C'est ici que j'ai pris connaissance de la différence entre le BlueTooth dit "Classique" et le BlueTooth basse consommation (En Anglais BLE pour BlueTooth Low Energy). En effet, ces deux types de connexion ne fonctionnent pas de la même manière. Le BlueTooth classique va chercher à se lier (pair) entre les périphériques afin d'établir une connexion. Cette connexion peut être protégée par un mot de passe. A l'inverse, le BLE va fonctionner selon un principe central et périphérique où le dispositif central va scanner afin de trouver des dispositifs périphériques. La plupart des applications développées et disponibles sur le Play Store utilisant le BlueTooth classique, mon nano n'était jamais détecté et disponible pour se lier.
J'ai dû creuser afin de pouvoir connecter via le BLE mon nano et mon smartphone. Au final, au moyen de l'App Inventor du MIT et d'une extension expérimentale, la transmission a pu se faire. Le débit de donnée n'était cependant pas optimal car je n'obtenais pas assez de données à la seconde. J'ai heureusement pu modifier des paramètres dans le code afin d'amplifier un peu cela (voir les settings dans le code du Nano).
Second problème concernant la batterie sélectionnée, les embranchements n'était pas compatibles avec mon Nano. De ce fait je ne pouvais utiliser mon Nano uniquement lorsqu'il était branché à l'ordinateur via micro-usb. Un changement de batterie et une connexion via les pins est envisagée afin de pouvoir alimenter mon dispositif sans ordinateur. Cela implique également de revoir la boîte que j'avais prévue pour le maintient des différentes pièces du dispositif. J'ai donc opté pour un lilypad alimenté par une pile 3V qui sera reliée via des câbles et sera directement cousue sur la sangle.
Les applications disponibles ne prenant quasiment jamais en charge le Bluetooth BLE, j'ai dû développer une application pour smartphone permettant de réaliser mes besoins. Ainsi, au moyen du MIT app Inventor, j'ai pu réaliser une application. Cela m'a demandé pas mal de temps supplémentaire pour le développement c'est pour cela que j'ai mis de côté la vitesse de course et la force appliquée au pied de bloc. pour me concentrer sur la hauteur du saut.
Le problème majeur que j'ai rencontré fût la précision des données. Afin de pouvoir mesurer précisément la hauteur d'un saut selon la technique citée précédemment, il faut réussir à obtenir le temps où l'utilisateur quitte le sol et le temps où il rentre à nouveau en contact avec celui-ci. La première étape est de déterminer ces instants précisément. L'exemple suivant montre comment j'ai procédé pour choisir ces instants (id et ia pour instant décollage et instant atterrissage) :
Les données obtenues représentent des accélérations et se présente sous un tableau de valeurs. Chaque tableau représente un axe (x, y, z). Pour cet exemple je ferai uniquement référence à l'axe qui calcule la hauteur. Ainsi avec des valeurs fictives suivantes : [-16,-16,-15, -40, 3, 1, 0, 1, 3, 1, -54, -20, -16] Il est possible de remarquer ces deux instants grâce aux valeurs élevées (-40 et -54). Ainsi il est possible de déterminer le temps passé en l'air si on récupère le temps t de ces instants et que l'on soustrait le temps t1 au temps t2. Jusqu'ici pas de problème. Le problème vient de la fréquence des données. Les données reçues par le dispositif arrivent entre 90 et 130ms. Cela implique donc qu'il y a une marge d'erreur maximale de 258ms si id est mesuré parfaitement au début du saut et ia parfaitement à l'instant du contact au sol ou à l'inverse que les instants soient mesurés juste après la fin d'une mesure pour id et à la dernière milliseconde d'une mesure pour ia. Ainsi un saut ayant une durée de 300ms (11cm) seraient mesurés de la même manière qu'un saut de 558ms (38cm). Cela paraît peu en terme de temps mais cela représente une différence de 29cm sur le calcul final. Plus le saut est haut, plus la différence devient importante (par exemple 700ms (60cm) et 958ms (112cm) soit 52cm de différence).
Solution finale
La solution final se présente sous la forme d'une sangle velcro sur laquelle une batterie lilypad est cousue et reliée à l'Arduino Nano 33 BLE disposé dans sa boîte protectrice imprimée en 3D. Cette boîte protectrice est tirée de cette boîte réalisée par idee_design et modifiée par mes soins pour pouvoir être attachée sur ma sangle. La batterie est reliée au dispositif au moyen de câbles.
Une fois le dispositif en place, il suffit de lancer l'application et de connecter le tout via bluetooth. Dès que cette connexion est faite, le dispositif va envoyer les données au smartphone. Dès que le saut est réalisé, déconnecter le bluetooth au moyen du bouton "Stop" et afficher le résultat.
Lien de démonstration du dispositif : https://tecfaetu.unige.ch/etu-maltt/zelda/humbeja9/stic-3/JumpAnalyser/video_demo.mp4
Code de l'arduino
1 // Code modifié pour le projet Jump Analyser par Jérôme Humbert
2
3 // Ce code a été initialement écrit par :
4
5 ///////////////////////////////
6 // © 2020 Dmitriy Kharutskiy //
7 ///////////////////////////////
8
9 // BMA180 triple axis accelerometer sample code //
10 // http://www.geeetech.com/wiki/index.php/BMA180_Triple_Axis_Accelerometer_Breakout //
11
12 #include <Wire.h>
13 #include <ArduinoBLE.h>
14 #include <Arduino_LSM9DS1.h>
15
16 #define ACCELEROMETER_ADDRESS 0x6B // Address of the accelerometer
17 #define ACCELEROMETER_STATUS_REG 0x17 // (Page 49 of the datasheet for the LSM9DS1, STATUS_REG)
18 #define DATA_X 0x28 // (Page 56, OUT_X_L_XL)
19 #define DATA_Y 0x2A // (Page 56, OUT_Y_L_XL)
20 #define DATA_Z 0x2C // (Page 56, OUT_Z_L_XL)
21
22 //************************************************************
23 // General settings
24 //************************************************************
25
26 #define ACCELEROMETER_SETTINGS_ADDRESS 0x20 // (Page 51 of the datasheet for the LSM9DS1, CTRL_REG6_XL)
27 //#define ACCELEROMETER_SETTINGS B10100000 // B[101]00000 - 476 Hz, B110[00]000 - 2 G (Page 51-52 of the datasheet for the LSM9DS1, CTRL_REG6_XL)
28 //#define ACCELEROMETER_SETTINGS B10110000 // B[101]10000 - 476 Hz, B110[10]000 - 4 G
29 //#define ACCELEROMETER_SETTINGS B10111000 // B[101]01000 - 476 Hz, B110[11]000 - 8 G
30 #define ACCELEROMETER_SETTINGS B10101000 // B[101]01000 - 476 Hz, B110[01]000 - 16 G
31 //#define ACCELEROMETER_SETTINGS B10011000 // B[100]11000 - 238 Hz, B110[11]000 - 8 G
32 //#define ACCELEROMETER_SETTINGS B01111000 // B[011]11000 - 119 Hz, B110[11]000 - 8 G
33 //#define ACCELEROMETER_SETTINGS B11011000 // B[110]11000 - 952 Hz, B110[11]000 - 8 G // DOES NOT WORK. The test shows 476 Hz instead of 952 Hz.
34
35 #define ACCELEROMETER_RESET_ADDRESS 0x22 // (Page 53, CTRL_REG8)
36 #define ACCELEROMETER_RESET B00000101 // (Page 53, CTRL_REG8)
37
38 int16_t offx = 0;
39 int16_t offy = 0;
40 int16_t offz = 0;
41
42 const int bufferSize = 3; // For Bluetooth 4.2 and Bluetooth 5.0 https://punchthrough.com/maximizing-ble-throughput-part-3-data-length-extension-dle-2/
43 //const int bufferSize = 20; // For Bluetooth 4.0 https://punchthrough.com/maximizing-ble-throughput-part-3-data-length-extension-dle-2/
44 BLEService accelerometerService("31d98611-49de-4683-97ae-132bd1491ae5");
45 BLECharacteristic accelerometerDataChar("31d98612-49de-4683-97ae-132bd1491ae5", BLERead | BLENotify, bufferSize, true);
46
47 int dataLengthAfterMarker = bufferSize * 3;
48
49 //************************************************************
50
51
52 signed char ByteArr[bufferSize];
53 int i = 0;
54 int ii = 0;
55 int16_t AccelValue1 = 0;
56 int16_t AccelValue2 = 0;
57 int16_t AccelValue3 = 0;
58 int16_t LastAccelValue1 = 0;
59 int16_t LastAccelValue2 = 0;
60 int16_t LastAccelValue3 = 0;
61 uint16_t unsignedAccelValue = 0;
62 int16_t dValue1 = 0;
63 int16_t dValue2 = 0;
64 int16_t dValue3 = 0;
65 long previousMicros = 0;
66
67
68 void setup()
69 {
70 // put your setup code here, to run once:
71
72 Serial.begin(9600);
73
74 pinMode(LED_BUILTIN, OUTPUT); // initialize the built-in LED pin to indicate when a central is connected
75
76
77 Wire1.begin();
78 delay(50);
79
80
81 // Initializing sensors
82 initAccelerometer();
83
84 initBLE();
85
86
87 delay(500); // Pauses the program for the amount of time (in miliseconds) specified as parameter.
88 }
89
90 void loop()
91 {
92 // put your main code here, to run repeatedly:
93
94
95 // wait for a BLE central
96 BLEDevice central = BLE.central();
97
98
99 // if a central is connected to the peripheral:
100 if (central)
101 {
102 // turn on the LED to indicate the connection:
103 digitalWrite(LED_BUILTIN, HIGH);
104
105
106 // while the central is connected:
107 while (central.connected())
108 {
109 if (IMU.accelerationAvailable())
110 {
111 /*
112 // Sample rate testing
113 long currentMicros = micros();
114 Serial.println(currentMicros - previousMicros);
115 previousMicros = micros();
116 */
117 int x;
118 int y;
119 int z;
120 float x2, y2, z2;
121 IMU.readAcceleration(x2, y2, z2);
122 x = x2*100;
123 y = y2*100;
124 z = z2*100;
125 Serial.print(x);
126 Serial.print("\t");
127 Serial.print(y);
128 Serial.print("\t");
129 Serial.println(z);
130
131 ByteArr[ii] = x%256;
132 ii++;
133 ByteArr[ii] = y%256;
134 ii++;
135 ByteArr[ii] = z%256;
136 ii++;
137 sendBuffer();
138
139 }
140 }
141
142 // when the central disconnects, turn off the LED:
143 digitalWrite(LED_BUILTIN, LOW);
144 }
145 }
146
147 //************************************************************
148 // Functions
149 //************************************************************
150
151 // Initializing sensors
152 void initAccelerometer()
153 {
154 byte temp[1];
155 byte temp1;
156
157 // RESET
158 writeTo(ACCELEROMETER_ADDRESS, ACCELEROMETER_RESET_ADDRESS, 0x05);
159
160 // ACCELEROMETER SETTING: acceleration range, band width
161 writeTo(ACCELEROMETER_ADDRESS, ACCELEROMETER_SETTINGS_ADDRESS, ACCELEROMETER_SETTINGS);
162
163 delay(10);
164 }
165
166 // Initializing BLE
167 void initBLE()
168 {
169 // begin initialization
170 if (!BLE.begin())
171 {
172 while (1)
173 {
174 Serial.println("starting BLE failed!");
175 delay(1000);
176 }
177 }
178
179 BLE.setLocalName("Vibration_Analysis_App");
180 BLE.setAdvertisedService(accelerometerService); // add the service UUID
181 accelerometerService.addCharacteristic(accelerometerDataChar); // add the battery level characteristic
182 BLE.addService(accelerometerService); // Add the battery service
183
184 // start advertising
185 BLE.advertise();
186 }
187
188 // Writes val to address register on ACC
189 void writeTo(int DEVICE, byte address, byte val)
190 {
191 Wire1.beginTransmission(DEVICE); // start transmission to ACC
192 Wire1.write(address); // send register address
193 Wire1.write(val); // send value to write
194 Wire1.endTransmission(); // end transmission
195 }
196
197 // Reads num bytes starting from address register in to buff array
198 void readFrom(int DEVICE, byte address, int num, byte buff[])
199 {
200 Wire1.beginTransmission(DEVICE); // start transmission to ACC
201 Wire1.write(address); // send register address
202 Wire1.endTransmission(); // end transmission
203
204 Wire1.beginTransmission(DEVICE); // start transmission to ACC
205 Wire1.requestFrom(DEVICE, num); // request num byte from ACC
206
207 int n = 0;
208 while(Wire1.available()) // ACC may abnormal
209 {
210 buff[n] = Wire1.read(); // receive a byte
211 n++;
212 }
213 Wire1.endTransmission(); // end transmission
214 }
215
216
217 void sendBuffer()
218 {
219 long beforeMicros = micros();
220
221 accelerometerDataChar.writeValue(ByteArr, ii);
222
223 long afterMicros = micros();
224 //Serial.println(afterMicros - beforeMicros); // Testing delay when sending data
225
226 ii = 0;
227
228 if (i >= dataLengthAfterMarker) i = 0;
229 delay(100);
230 }
Code de l'application
Fichier:JumpAnalyserApplication.zip
Fichier:JumpAnalyser.zip
Note : Seul un axe étant utilisé pour la hauteur du saut, les derniers calculs en bas à gauche ne sont pas utilisés.
Test(s) de la solution
- Travail individuel: documentation dans votre page projet avec un cognitive walkthrough ou similaire pour le testing.
Afin de pouvoir tester mon dispositif, j'ai décidé d'utiliser une procédure Fluid project overview afin d'avoir une vue d'ensemble des tous les potentiels utilisateurs de mon projet.
Définitions des utilisateurs
Cela me permet de détailler les usagers en rapport à trois types d'utilisateurs :
- Le coach (ou celui qui va récupérer les données sur un smartphone)
- Le volleyeur effectuant une course d'élan (attaque)
- Le volleyeur effectuant un saut statique (simulation d'un bloc défensif)
Objectifs utilisateurs
Deux de ces utilisateurs possèdent le même objectif qui est de sauter le plus haut possible lors de leur actions respectives. Cependant, l'utilisateur effectuant une course d'élan aura beaucoup plus de paramètres (et donc de sous-objectifs) à prendre en compte notamment sa vitesse horizontale, sa puissance sur son pied de bloc et le temps passé sur ses derniers appuis par exemple. Cet utilisateurs là peut donc avoir des objectifs plus précis.
Le coach quant à lui va chercher à obtenir les informations de manière fiable et rapide afin de pouvoir les transmettre et offrir un conseil ou apporter des modifications à la course d'élan ou à la posture du joueur.
Étapes de réalisation de l'objectif
Volleyeurs
- Pour les cas des volleyeurs, la première étape est de mettre en place correctement le dispositif au niveau de la cheville. Le choix entre jambe droite et jambe gauche dépends de la course d'élan de l'attaquant mais devrait toujours se trouver sur le pied de bloc. Dans le cas d'un saut statique, cela n'a pas d'importance.
- Le joueur effectue son action de saut.
- Il se peut que le volleyeur refasse plusieurs tentatives, il est pas toujours aisé de faire son meilleur saut du premier coup. (Boucle sur 3)
- Enlever le dispositif lorsque le volleyeur ne souhaite plus prendre de mesures.
Coach
- Le coach installe l'application et se connecter au dispositif en Bluetooth
- Le coach aide à la mise en place du dispositif
- Le coach donne le signal au joueur que celui-ci peut réaliser son saut.
- Le coach analyse les données reçues et peut donner des conseils d'amélioration au joueur.
- Il se peut que le volleyeur refasse plusieurs tentatives, il est pas toujours aisé de faire son meilleur saut du premier coup. (Boucle sur 3-4)
- Déconnecter le dispositif et fermer l'application
Réalisation des tests
Pour chaque étape décrite si dessus, 4 questions doivent être posées :
- Est-ce que l'utilisateur sait ce qu'il doit faire ?
- Est-ce que c'est difficile de comprendre ce qu'il doit faire ?
- Est-ce que l'utilisateur sait s'il a bien réalisé ce qu'il devait réaliser ?
- Est-ce que le feedback est difficile à analyser ?
| Volleyeurs | ||||
|---|---|---|---|---|
| Est-ce que l'utilisateur sait ce qu'il doit faire ? | Est-ce que c'est difficile de comprendre ce qu'il doit faire ? | Est-ce que l'utilisateur sait s'il a bien réalisé ce qu'il devait réaliser ? | Est-ce que le feedback est difficile à analyser ? | |
| 1. Mise en place du dispositif | Dans la plupart des cas, les utilisateurs ont su mettre en place le dispositif et l'ont attaché à une cheville. Certains l'ont initialement attachés aux bras. Quelques uns se sont demandés sur quelle cheville l'attacher. Globalement, les utilisateurs ont su ce qu'ils fallait faire avec le matériel. | L'attacher est la partie simple de la réflexion, tout le monde sait utiliser une sangle en velcro. Cependant, il faut tout de même avoir une réflexion concernant l'endroit idéal où attacher le dispositif. | Le coach est censé assister l'utilisateur dans la bonne mise en place du dispositif (Coach 2.). L'utilisateur attendait la validation de celui-ci. | Non. Si le dispositif ne tient pas bien où qu'il renvoie des donnes erronées c'est que celui-ci est mal attaché. |
| 2. Le joueur effectue son action de saut. | Oui | Non | Chaque utilisateur possède sa propre définition d'un saut réussi. Mais tout le monde sait quand il rate un saut. | Non |
| 3. Réaliser plusieurs tentatives | Oui | Non | Oui | Non |
| 4. Retirer le dispositif | Oui | Non | Oui | Non |
| Coach | ||||
| Est-ce que l'utilisateur sait ce qu'il doit faire ? | Est-ce que c'est difficile de comprendre ce qu'il doit faire ? | Est-ce que l'utilisateur sait s'il a bien réalisé ce qu'il devait réaliser ? | Est-ce que le feedback est difficile à analyser ? | |
| 1. Installation de l'application et connexion au Bluetooth | Parmi le public ayant participé à ces tests, la moyenne d'âge était d'environ 26ans. De ce fait, chaque utilisateur savait comment installer une application et activer le Bluetooth. Cela peut être différent avec un public plus âgé. | Non | Oui | Non |
| 2. Le coach aide à la mise en place du dispositif | Oui | Non | Oui | Non |
| 3. Le coach donne un signal à l'utilisateur pour démarrer la réalisation des sauts | Oui | Non | Oui | Non |
| 4. Analyse des données reçues et conseils d'améliorations | Oui | Oui, il est difficile de voir tout les paramètres qui entrent en jeu lors d'une course d'élan ou d'un saut en général. L'application va aider le coach en donnant un résultat. Mais cela ne lui indique pas ce qui va ou ne va pas dans une course d'élan en particulier. | Le coach se doit d'avoir un esprit critique tout en gardant à l'esprit que l'utilisateur ne peut pas forcément "aller plus haut". C'est le point difficile de l'analyse. | Dépends de la réception de l'utilisateur concernant les commentaires et conseils donnés par le coach. |
| 5. Réaliser plusieurs tentatives | Oui | Non | Idem | Idem |
| 6. Déconnecter le dispositif et fermer l'application | Oui | Non | Oui | Non |
Discussion
Discussion du design
Si je devais refaire ce projet, j'aurais tout d'abord choisir un périphérique avec un Bluetooth traditionnel. Cela m'aurait éviter beaucoup de problèmes et de travail. Il existe de nombreuses applications déjà existantes permettant de recueillir les données issues d'un Arduino ou autre dispositif via le Bluetooth. Cela m'aurait éviter de devoir développer une application from scratch avec des outils que je ne maîtrisais pas jusqu'ici. Ce gain de temps m'aurait sans doute permis de pouvoir développer d'avantage de fonctionnalités que j'avais initialement prévues comme la mesure du pied de bloc et la vitesse de la course.
En terme de design, je ne pense pas que j'aurais changé grand chose. Le choix de la sangle en velcro est vraiment idéal car il permet d'attacher/détacher très facilement le dispositif. Ce que j'aurais peut-être changé c'est la connectivité entre la batterie et l'arduino où il est possible que du fil conducteur puisse être cousu entre les deux pour un meilleur maintien de la connexion.
Discussion des tests
Globalement, l'utilisation du dispositif s'est passé comme prévu lors des tests. Cela dit, ayant moi-même été le coach dans cette sessions, j'avais connaissance du projet et de son fonctionnement. Si ce projet avait été donné tel quel à une personne ignorant ses subtilités, je pense que le test aurait été bien plus contrasté en terme de compréhension du coach et donc indirectement des utilisateurs.
Les utilisateurs étaient très enthousiastes de pouvoir mesurer leurs sauts et potentiellement de pouvoir s'entraîner et voir leurs progrès sur le long terme.
Licence, fichiers et documentation
Cette œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale 4.0 International.
- Fichiers :
Insérer ici vos fichiers ou les liens vers vos fichiers
- Documentation :
Insérer ici une petite documentation pour l'utilisation de l'objet si nécessaire
Bibliographie
Insérer ici les références utilisées pour votre projet.