Projets:Fit and Fun
Fit and Fun | |
---|---|
Ce projet recherche ces compétences :
Développement logiciel, Internet des objets, Linux, Mécatronique, Raspberry pi, Autre | |
Informations | |
Description | Ecran interactif pour pédalier à main d’entraînement sportif. |
Catégorie | Motricité |
Etat d'avancement | En cours |
Techniques | raspberry pi, ESP32"ESP32" n’est pas dans la liste (android, appinventor, arduino, BLE, bluetooth, bricolage, couture, découpe laser, esp, fixation, ...) de valeurs autorisées pour la propriété "A techniques"., Pygame"Pygame" n’est pas dans la liste (android, appinventor, arduino, BLE, bluetooth, bricolage, couture, découpe laser, esp, fixation, ...) de valeurs autorisées pour la propriété "A techniques". |
Durée de fabrication | de 2 à 4 h |
Coût matériel | De 100 à 200 euros |
Niveau | Moyen |
Licence | autre |
Date de création | 2022-10-20 |
Équipe | |
Porteur de projet | Julien, Guillaume |
Contributeurs | Gweltaz, Philippe, Samuel, Beatrixm, Pissard |
Animateur | Francois |
Fabmanager | Cecile |
Référent documentation | Luc, Beatrixm |
Partenaires: | Autonabee"Autonabee" n’est pas dans la liste (le collège des Hautes Ourmes (Rennes), le collège des Chalais (Rennes), l’Institut Médico Educatif PREFAAS (Rennes), le collège Bellevue (Redon), l’Institut d’Education Motrice La Clarté (Redon), le collège Mahatma Gandhi (Fougères), l’Institut d’Education Sensoriel Paul Cézanne (Fougères), le collège Du Querpon (Maure-de-Bretagne), l’Institut Médico Éducatif Les enfants du pays (Poligné), Lab4i, ...) de valeurs autorisées pour la propriété "A partenaires"., INRIA |
Nom humanlab | Humanlab_MHK |
Documentation | |
Statut de la documentation | Partielle |
Relecture de la documentation | Non vérifiée |
Description du projet
La salle de sport S.P.O.R.T de l'association Lyonnaise ANTS est spécialisée pour les personnes en situation de handicap moteur. Elle propose du matériel spécialisée afin de maintenir une activité physique régulière hors milieu médical. Parmi le matériel, la salle est dotée d'un pédalier à main basique. Julien, co-président et membre fondateur de l'association, et les autres utilisateurs de ce pédalier l'utilisent pour s'échauffer mais ils le trouvent ennuyeux.
Le projet propose donc d'ajouter au pédalier à main un écran pour avoir des retours et rendre son utilisation plus interactive, en particulier en le dotant d'un jeu vidéo dont l'entrée est la vitesse du pédalier.
Cahier des charges
- Susciter l'envie de rejouer
- Accessibilité dans les salles de sport
- Motiver les utilisateurs à rester engagés pendant 10 minutes d'utilisation du maindalier
- Varier les vitesses (force et cardio)
- Donner des feedbacks sur la performance
- Faire oublier l'effort
- Jouable sans connection internet
- Bas coût
- Facile à prendre en main et ludique
Analyse de la problématique
Possibilités d'interaction
- Rotation avant / arrière
- Accélération de la rotation
- Serrer les poings
- Bouger la tête
- Posture du dos
- Distance entre le maindalier et le buste
- Lâcher une main
- Capteur de pression des mains sur les poignées
- Capteur cardiaque (montre connectée)
- Variation de la résistance mécanique
- Capteur de pression d'assise
Besoins
- Bonne qualité de l'équipement (roulement fluide, amplitude du mouvement)
- Jeu qui suscite l'empathie (par ex, nostalgie de Mario)
- Intuitif (facile de comprendre les règles)
- Maintenir la forme physique :
* Endurance, respiration * Vitesse * Accélération * Attention * Coordination * Gainage * Fatigabilité
- Avoir une bonne posture
- Installation rapide (<10s)
- Entraîner le bras plus faible
- Personnaliser les poignées à chacun
- Rendre l'exercice plus attractif
- Avoir du feedback sur ces stats : temps, vitesse, calories, infos pour les APA
- Jouer en multijoueur
- Historique des performances du joueur et de celles des autres
Axes
On a décidé de s'organiser en 3 axes de travail
- Concept du jeu vidéo
- Hacking de l'électronique du maindalier
- Programmation PyGame et intégration hardware
Equipe
Porteurs du projet
- Julien, ANTS
- Guillaume, Mhk
Concepteurs/contributeurs
- Gweltaz, MHK
- Philippe, Covea
- Samuel
Animateur (coordinateur du projet)
- Francois, Autonabee
Fabmanager référent
- Cécile, Autonabee
Responsables documentation et Game Design
- Beatrixem, Autonabee
- Luc, Floss Manuel
Concepteurs/contributeurs à distance
- Roger, Humanlab Inria
Travail réalisé: Axe Concept du jeu vidéo
Cadrage
Références
- Ring Fit Adventure
- Playdate
- Simulations existantes de balade (balade en montagne, etc.)
Usages
- Une session d'entrainement peut durer de 5 à 45 min.
- Compétences stimulées :
* Endurance : pédaler le plus longtemps possible. * Vitesse, réflexes.
Lexique
Explication des termes utilisés dans cette documentation :
- Boucle de jeu : une séquence de jeu avec un début, un milieu et une fin.
- Brique de gameplay : objet que l'on peut faire apparaître à l'écran et qui permet de créer du challenge (obstacles, bonus, malus...).
Description du jeu
Le jeu consiste en un parcours d'obstacle à défilement vertical, dans lequel on incarne un personnage qui rame dans un canoë avec deux rames symétriques en vue du dessus. L'objectif est de parcourir la distance la plus grande dans un temps limité.
Le choix d'un visuel 2D en pixel art rend plus facile la production et l'intégration de contenu.
Phases "Avance" et "Recule"
Le jeu peut fonctionner dans deux phases différentes :
- Avance : le joueur doit pédaler vers l'avant. Quand on ne pédale pas, il est en bas de l'écran. Plus on pédale vers l'avant et plus il se positionne haut.
- Recule : le joueur doit pédaler vers l'arrière. Quand on ne pédale pas, il est en haut de l'écran. Plus on pédale vers l'arrière et plus il se positionne bas.
Le jeu commence à chaque fois en phase "Avance". Le changement de phase est déclenché par la brique de gameplay "Barrage".
Suite à un test de Guillaume, on note que l'effort physique lors du pédalage arrière est plus difficile qu'en avant. Pour y palier, on peut adapter la difficulté dans cette phase (séquences plus simples).
Contrôles et personnage
Le canoë se situe sur un axe vertical à une extrémité de l'écran (en bas en phase "Avance", en haut en phase "Recule").
Sur-place
Tant que le joueur ne pédale pas, le canoë reste sur place. Le fond défile toutefois très lentement vers le bas pour simuler l'écoulement de l'eau.
Défilement de l'écran
Défilement vers l'avant : L'écran défile selon la vitesse à laquelle on pédale vers l'avant, et le score de distance parcourue augmente de la même manière
Défilement vers l'arrière : L'écran défile selon la vitesse à laquelle on pédale vers l'arrière , et le score de distance parcourue augmente de la même manière.
La vitesse du canoë peut être modifiée par certaines briques de gameplay.
Infos
Les infos s'affichent en haut de l'écran. Il y en a 3, placées les unes à côté des autres.
- Temps restant : le temps restant avant la fin de la séquence de jeu.
- Score : la distance parcourue par le canoë en mètres. Cette distance augmente en fonction de la vitesse de déplacement du canoë.
- Difficulté : une jauge indiquant la résistance du maindalier.
* 0 = résistance minimum/pas de résistance, 100 = résistance maximum. * En fonction de la résistance, la couleur de la barre passe du vert (résistance min) au rouge (résistance max).
Feedback de progression important à mettre en place, la borne :
- Tous les X mètres, une petite borne (bien lisible) est placée sur le scroll, indiquant clairement la distance à laquelle elle correspond.
- Quand le canoë passe devant, la borne bump.
Boucle de jeu
Une boucle de jeu dure un temps déterminé (pour une première démo nous fixons à 5 minutes).
Le joueur doit faire voyager son canoë sur la plus grande distance possible avant la fin du délai.
Récompense à la fin : il peut comparer son score avec son meilleur score.
Début de séquence de jeu
Une séquence de jeu commence par un compteur "3...2...1...GO !" Le personnage n'est contrôlable qu'à la fin de ce compteur, et l'info "temps restant" ne décroît qu'à partir de ce moment.
Fin de séquence de jeu
Quand le temps restant arrive à 0, un sprite de ligne d'arrivée vient se placer dans le décor à l'extérieur de l'écran. Une fois que le joueur la franchit, l'écran de score s'affiche.
Animations du personnage
- Idle : quand le canoë n'avance pas, l'animation reste sur une frame au repos (les deux rames sont à l'horizontal).
- Moving : alternance de frames entre rames à l'avant et rames à l'arrière. La vitesse de l'anim se base sur la vitesse de rotation du maindalier.
- Moving (reverse) : même animation que moving mais à l'envers.
- Victory : à la fin de la séquence de jeu, le personnage lève les bras en l'air, il est content.
Briques de gameplay
Objets venant du côté
Objet avec un sprite qui apparaît sur un bord de l'écran et se déplace horizontalement.
Le placement de ces objets peut se faire sur 3 positions verticales possibles (relativement à la direction haut ou bas) : milieu (peut toucher le canoë s'il est à l'arrêt ou rame à vitesse normale), intermédiaire (peut toucher le canoë s'il est au quart de l'écran), max (peut le toucher quand il est à la position la plus extrême)
Tremplin
Objet venant du côté. L'effet de cet objet s'applique quand le canoë entre en collision avec lui.
Effet : gros bonus de vitesse de scroll (2 fois plus vite que le max) pour 2 secondes sans que ça n'affecte le positionnement vertical du canoë (sinon il risque de se prendre les canards involontairement), mais le scroll vertical est effectivement accéléré.
(intention de design : pousser l'utilisateur à accélérer pour l'atteindre).
Animation de déplacement du tremplin :
- pour éviter la sensation qu'il flotte étrangement par rapport au background qui scrolle : quand le tremplin se déplace sur la berge, il vole (petites ailes + ombre en-dessous).
- Quand il est dans l'eau, pas d'anim.
Groupe de canards
Objet venant du côté. L'effet de cet objet s'applique quand le canoë entre en collision avec lui.
Effet : le canoë shake rotate et se stoppe pendant 3 secondes (le scrolling et le positionnement du perso se stoppent aussi pendant ce délai, pour qu'il reste bien sur place).
Animation de déplacement du canard :
- quand le canard se déplace sur la berge, une sensation de flottement gênante dans leur visuel par rapport au background qui scrolle. Pour résoudre ce problème : tant qu'ils sont sur la berge, les faire jouer une animation de vol (avec ombre en-dessous, tournés en diagonale pour qu'ils aient l'air de compenser le scroll).
- quand ils sont dans l'eau, animation où leur tête fait un petit aller-retour avant-arrière.
(intention de design : pousser l'utilisateur à accélérer ou ralentir pour les esquiver).
Vent
Un sprite s'affiche :
- en haut de l'écran quand on avance
- en bas quand on recule.
Effet : la résistance du pédalier augmente pendant la durée du vent. (intention de design : augmentation temporaire de la difficulté)
Barrage
Un sprite prenant toute la largeur du canal apparaît en haut de l'écran (en phase "Avance") ou en bas (en phase "Recule") et suit le défilement.
Effets :
- Le canoë ne peut pas se déplacer plus loin que le barrage dans la direction de celui-ci.
- Le jeu change de phase (Avance/Recule).
Pour indiquer au joueur qu'il doit changer de sens, une grosse flèche rouge en bas de l'écran et orientée vers le bas clignotte pendant quelques secondes.
Level Design
Pour avoir des séquences cohérentes, une solution est de d'avoir des séquences d'apparition d'objets, dans lesquelles le jeu va piocher au hasard. Divers outils sont possibles pour la conception de ces séquences : fichiers json, csv...
- A chaque séquence est associé un indicateur de distance minimum (pour avoir une difficulté progressive, et que certains objets ne puissent arriver qu'à partir d'un certain moment).
- On peut mettre une séquence en "forcé" pour qu'elle soit obligée d'arriver à un moment défini.
Un délai entre chaque séquence permet d'éviter qu'elles se superposent.
Un petit Level Design à implémenter pour un premier test (le format est objet/seconde/distance, ou "seconde" correspond au temps depuis le début. S'il y a plusieurs chiffres c'est qu'il y en a plusieurs à la suite) :
// Séquence "accélérer jusque max" => dispo à 6s
- Canard/0/milieu
- Canard/2/milieu
- Canard/6/milieu
- Canard/6/intermédiaire
// [forcé] Séquence Tremplin
- Tremplin/18/intermédiaire
// Séquence "forcer à ralentir" => dispo à 26s
- Canard/0-1-2-3/max
// Séquence "pousser à ralentir fortement" => dispo à 39s
- Canard/0-1-2-3/intermédiaire
- Canard/0-1-2-3/max
// [forcé] Séquence Tremplin
- Tremplin/max/44
Puis dans le cas où l'on a la feature du barrage : // Séquence Barrage forcé
- Barrage/-/52
// Séquence Recule "accélérer" => dispo à 57s
- Canard/0/min
// [forcé} Séquence Recule tremplin
- tremplin/62/max
Améliorations à long terme
Retour sur la posture
Problème : certains utilisateurs du maindalier ne restent pas droits et se penchent en avant pendant qu'ils pédalent.
Solution envisagée : une pop-up dans un coin de l'écran, avec vue rapprochée du personnage donnant un de feedback :
- Si on ne se tient pas bien droit : fatigué, rouge, penché en avant.
- Si on se tient bien droit: content, vert, sourire.
Cette popup ne doit pas apparaître quand il y a un obstacle dans ce coin.
Autre bénéfice de cette solution : identification au personnage.
Compte utilisateur
La feature "Compte utilisateur" peut apporter ces solutions :
- Enregistrement des scores passés de chaque utilisateur (pour se comparer).
- Observation de sa progression à long terme.
- Possibilité de personnaliser le contenu (réglages, etc.) pour chaque utilisateur.
Dans un premier écran de jeu, l'utilisateur peut choisir son compte ou en créer un nouveau. Ce compte mémorise le score de ses sessions.
Enregistrement du score
Il semble nécessaire classer le score de l'utilisateur par mode de jeu et par durée. Par exemple : -> "fractionné 5 minutes : 1100m, 9300m" -> "fractionné 15 minutes : 3200m, 2800m"
Expérience et niveaux
La feature "Expérience et niveaux" peut apporter ces solutions :
- motiver les joueurs à relancer le jeu à plusieurs occasions.
- débloquer du contenu de jeu progressivement.
A la fin d'une séquence de jeu, le compte de l'utilisateur gagne des points d'expérience. Quand ces points franchissent des palliers prédéfinis (qui sont de plus en plus élevés), il passe un niveau. Chaque niveau débloque du contenu supplémentaire.
Système de paliers
Pour récompenser le joueur quand il parcourt une certaine distance, de nouveaux éléments de jeu peuvent apparaître. Ce peuvent être :
- De nouveaux bonus avec d'autres réglages que le tremplin (taux d'augmentation de la vitesse, durée du déplacement, temps d'apparition du bonus) : bumper, baleine qui tire le canoë, élastique, fusée, etc.
- De nouveaux obstacles avec d'autres réglages que les canards : gros oiseau, cheval qui nage, nuage (personnage ralenti)
- De nouveaux éléments de décor : l'effet est seulement esthétique mais plaisant.
(intention de design : varier les situations de jeu)
Variantes de décor
Pour bien casser la monotonie, le background change drastiquement à chaque nouvelle séquence de jeu. Par exemple :
- les quatre saisons
- d'autres localisations géographiques (désert, jungle, tropiques...).
Modes de jeu
Plusieurs modes de jeu sont envisageables :
- Échauffement : mode standard avec les différents
- Fractionné :
- Renforcement musculaire
- mode libre
Axe Hacker l'électronique du maindalier
Retour de Julien
- Julien utilise le réglage de la résistance, les APA font le réglage pour chaque personne à chaque fois
- Julien s'échauffe 15-20 min, préfère la manivelle alternée
- Michel (autre membre de ANTS) préfère la manivelle synchro, car sur son handbike la manivelle est synchro pour une meilleure gestion des virages, cela plus jouer l'inertie du système
- Le bâti du pédalier à main a été bricolé, pas de plan
- 44 utilisateurs du mandalier dont 20 avec gants (problème de préhension, force dans les mains)
Démontage
- 1 capteur de rotation - compte tour
- Donnée déduite de cette vitesse de rotation, courbe de calibration
- Il existe un jack male connecté à l'afficheur et un cable femelle non connecté qui pourrait permettre de paramétrer le système
- Transmission purement mécanique entre le bouton de réglage et le déplacement du solénoid qui règle la position de l'électro-aimant du frein
- Il y a de la place pour mettre un moteur dans le capot sans toucher au mécanisme de base
- Logiciel gratuit du constructeur - plein de fonctionalités à tester
Position du corps
Discussion avec Périne, il faut respecter des lois posturales pour la position du bras et du dos. Est-ce qu'une correction par des instructions suffisent?
Axe PyGame et intégration hardware
Introduction
Le système est constitué d'un Raspberry Pi 4 connecté à un écran qui affiche un jeu qui est contrôlé par la vitesse du pédalier. On dispose sur le pédalier d'un capteur centrale inertielle sans fil qui envoie la vitesse angulaire (gyromètre) de l'axe. Le capteur centrale inertielle est constitué par une micro-contrôleur ESP8266 et d'une centrale inertielle BNO05. Le Raspberry est configuré en access-point Wifi et recoit des messages MQTT du capteur.
Une pré-étude a été réalisée en stage chez Autonabee par Corentin: Media:RapportDeStage_CorentinANDRIEU_AUTONABEE.pdf
MQTT est un protocole IoT pour envoyer des 'petits' paquets de données. C'est un protocole de messagerie publish-subscribe basé sur le protocole TCP/IP et un serveur central (broker). Les objets connectés s'abonnent et publient sur le réseau. De très nombreuses bibliothèques sont disponibles pour programmer les clients. Nous avons utilisé un client Python sous Raspberry et Arduino sous en utilisant ce protocole. Pour le serveur, sous Raspberry Linux, nous avons utilisé l'implémentation Mosquitto.
On retrouve plus d'informations sur le logiciel sur le README.md
Taches réalisées/à faire
- [x] Exemple jeu pygame avec entrée clavier (Roger)
- [x] Exemple jeu pygame avec communication MQTT (Roger)
- [x] Tester l'intégration d'émulation capteur par clavier (Gweltaz)
- [x] Programmation du jeu (Gweltaz)
- [x] Communication MQTT avec jeu Raspberry et la centrale ESP8266/BNO055 (Roger)
- [x] Prototypage contrôle moteur (Cécile/Roger)
- [x] Prise en main et tuto (Cécile)
- [ ] Brancher et debug l'écran
- [ ] Intégration capteur M5StickC-P en alternative
PyGame - Step-By-Step de Cécile (pour windows)
1. [Installer Python 3.10](https://www.python.org/downloads/) 2. Ouvrir l'IDLE de base Python 3.10 3. Récupérer l'adresse du répertoire où installer la librairie PyGame : [racine où est installer Python3.10]...\Python\Python310\Scripts 4. Installer la librairie PyGame via la console windows (connection internet requise)
* Taper `cmd` dans la barre de recherche * Taper `cd [racine où est installer Python3.10]...\Python\Python310\Scripts` * Taper `pip3 install pygame`
5. Tester l'installation en tapant dans l'IDLE `import pygame` 6. Découvrer le fonctionnement d'un jeu en plusieurs étapes
* Etape 1 : Créer une fenêtre vierge - Ouvrez Game1.py * Etape 2 : Créer une page d'accueil - Ouvrez Game2.py * Etape 3 : Créer une fenêtre de jeu - Ouvrez Game3.py * Etape 4 : Créer le défilement du jeu - Ouvrez Game4.py
Matériel
- Pédalier à Main
- RaspberryPi 4
- Ecran 7 à 10 pouces
- ESP2866 micro-controleur arduino avec Wifi
- centrale BNO055 centrale inertielle
- M5Stick-C P centrale inertielle avec micro-controleur intégré
- TB6560 contrôleur moteur pas à pas
Fichiers sources
Les fichiers se trouvent dans le projet github fit_and_fun. On y retrouve:
- le code source
- les plans 3D du boîtier (à déposer)
A Continuer & Boites à idées
- Packager le dispositif pour qu'il soit utilisable dans la salle de sport
- Ajouter les fonctionnalités manquantes du jeu
- Intégrer le contrôle de la résistance du pédalier par moteur pas à pas
- Conception de la poignée connectée et du tableau de commande
- Faire une option kayak pour quand le maindalier est en configuration pédale opposée
- Handicap visuel - retour de force avec la résistance au mouvement, spatialisation du son?
- Permettre une intégration clé en main via des moteurs très accessibles (tels Construct3, Game Maker ou autre...) pour que n'importe qui puisse développer un jeu pour maindalier sans connaissance en programmation. (cf https://www.construct.net/en/blogs/construct-official-blog-1/construct-raspberry-pi-1491 et https://meseta.medium.com/setting-up-gamemaker-builds-on-the-rpi-81ecab7e0638 )