« STIC:STIC III (2020)/Jump Analyser » : différence entre les versions

De EduTech Wiki
Aller à la navigation Aller à la recherche
Ligne 45 : Ligne 45 :
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.   
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.   
<gallery>
<gallery>
Fichier:Attache chaussette.jpg
Fichier:Attache chaussette.jpg|Le boîtier n'étant pas encore imprimé, il est représenté par ce rectangle blanc issu de son modèle.
Fichier:Attache Velcro.jpg
Fichier:Attache Velcro.jpg
Fichier:Attache sangle.jpg
Fichier:Attache sangle.jpg

Version du 13 juin 2021 à 12:26

Projet réalisé par Jérôme Humbert

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, la vitesse de la course et la force d'arrêt du pied de bloc durant la course d'élan d'un joueur. 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).

Il faudra également calculer la vitesse de la course. Celle-ci pourra être déterminée en partant d'une vitesse nulle (joueur à l'arrêt) jusqu'au décollage. L'accéléromètre permettra de mesurer la variance de vitesse à une certaine fréquence et ainsi de montrer comment le joueur utilise la vitesse (qui normalement doit être de lent à très rapide).

Finalement, le calcul du pied de bloc se fera également au moyen de l'accéléromètre qui permettra de visualiser la différence de vitesse entre le point culminant de la vitesse et le décollage. Si le point culminant de la vitesse n'est pas proche de la fin de la course, cette mesure n'est dans tous les cas pas pertinente car le joueur ne profitera pas réellement de l'effet de levier du pied de bloc.

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 partage une même chaussette ;)

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.

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'est cependant pas encore optimal.

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.

Présentation de la solution finale:

  • Décrire le dispositif et son fonctionnement. Une petite documentation peut être réalisée à destination des utilisateurs-trices.
  • Réaliser et documenter le schéma final de votre circuit

La solution finale sera élaborée durant l'été et rendue pour début septembre.

Test(s) de la solution

  1. 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
  1. 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.
  2. Il faut se coordonner avec la personne récoltant les données pour que celle-ci aie l'application en marche et que la connexion Bluetooth soit active.
  3. Une fois le signal donné par le coach, le joueur effectue son action de saut.
  4. 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)
  5. Enlever le dispositif lorsque le volleyeur ne souhaite plus prendre de mesures.
Coach
  1. Le coach installe l'application et se connecter au dispositif en Bluetooth
  2. Le coach aide à la mise en place du dispositif
  3. Le coach donne le signal au joueur que celui-ci peut réaliser son saut.
  4. Le coach analyse les données reçues et peut donner des conseils d'amélioration au joueur.
  5. 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)
  6. Déconnecter le dispositif et fermer l'application

Lors de la réalisation du test complet, pour chaque étape :

  • "Will the user know what to do at this step?
  • Is complex problem solving needed to figure out what to do?
  • Will they know that they did the right thing (if they manage) and are making progress towards their goal?
  • Is complex problem solving needed to interpret the feedback?"

Le test complet de la solution sera fait durant l'été et rendu pour début septembre.

Discussion

Cette partie inclus deux sous parties :

  • Discussion du design (et si c'était à refaire ou à améliorer),
  • Discussion des résultats de vos tests utilisateurs

La discussion sera faite durant l'été et rendue pour début septembre.

Licence, fichiers et documentation

By-nc.png 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.