Projet Final - Rééducation Ludique

FlexMouv - Dispositif Robotisé de Rééducation des Membres Supérieurs

Équipe projet

•  ATASHIAN Irine

•  BAIG Seema

•  Wang Elisa 
  

FlexMouv est un dispositif robotisé conçu dans le cadre de l'UE MU5MN045. 

Il vise à accompagner la rééducation des membres supérieurs, poignet, avant‑bras, coude et bras, grâce à un système interactif où le patient pilote un petit véhicule via une télécommande.
Le mouvement du véhicule dans un parcours dédié sollicite différents axes de mobilité, permettant une rééducation progressive, ludique, sécurisée et accessible.

1 - Contexte

La rééducation des membres supérieurs est essentielle pour les patients souffrant de :

• Arthrose (dégradation articulaire limitant les amplitudes)

• Polyarthrite rhumatoïde (inflammation chronique des articulations)

• Tendinites chroniques (épicondylite, tendinite du poignet)

• Séquelles d’AVC (perte de mobilité fine)

• Traumatismes (fractures, entorses, immobilisation prolongée)

• Maladies neuromusculaires (Parkinson, myopathies)

Les dispositifs actuels sont souvent :

• coûteux,

• peu ludiques,

• non modulables,

• ou nécessitent une supervision constante.

FlexMouv répond à ces limites en proposant un système robotisé simple, motivant et adaptable.

Réflexion sur la problématique & veille sur l’existant

La rééducation du membre supérieur repose sur un ensemble d’exercices destinés à restaurer la mobilité, la force et la coordination après une pathologie ou un traumatisme. Pourtant, malgré l’importance de ces séances, de nombreux patients peinent à maintenir une pratique régulière : les exercices sont souvent répétitifs, peu stimulants, et parfois douloureux. Cette réalité crée un véritable enjeu pour les kinésithérapeutes, qui cherchent des outils capables de soutenir l’engagement du patient tout en garantissant une progression sécurisée.

Dans ce contexte, nous avons étudié différents dispositifs existants afin de comprendre leurs apports, leurs limites et les raisons pour lesquelles un système comme FlexMouv peut trouver sa place.

a) Les exosquelettes et dispositifs robotisés lourds

Les exosquelettes de rééducation (Armeo®, HAL®, ReWalk®, etc.) représentent aujourd’hui l’une des solutions les plus avancées technologiquement. Ils permettent un accompagnement motorisé très précis, une mesure fine des mouvements et une adaptation au niveau du patient. Cependant, ces systèmes présentent plusieurs limites majeures :

• un coût très élevé, très coûtant pour la majorité des cabinets ou structures de petite taille ;

• une installation complexe, nécessitant du personnel formé ;

• une utilisation fatigante pour certains patients, notamment les personnes âgées ;

• une faible dimension ludique, alors que la motivation est un facteur clé de réussite.

 

  Dispositif Armeo

Ces dispositifs sont donc performants, mais peu adaptés à une utilisation simple, régulière et accessible. FlexMouv se positionne volontairement à l’opposé : un outil léger, peu coûteux, facile à mettre en place et utilisable dans des séances courtes.

b) Les dispositifs mécaniques traditionnels

Les outils classiques de rééducation — roues de mobilisation, poignées, balles, élastiques, tables de mobilisation — sont largement utilisés car ils sont simples, robustes et économiques. Ils permettent de travailler efficacement certaines amplitudes, mais ils souffrent de plusieurs limites :

• des exercices souvent répétitifs et monotones, qui réduisent l’adhésion du patient ;

• une mobilisation parfois trop ciblée, ne sollicitant pas la coordination globale bras‑main ;

• une absence de retour ludique, ce qui peut décourager les patients souffrant de douleurs chroniques.

FlexMouv apporte ici une réponse intéressante : il transforme un exercice mécanique en une activité engageante, où le patient se concentre sur un objectif (piloter un véhicule) plutôt que sur la douleur ou la difficulté du mouvement.

c) Les jeux thérapeutiques et dispositifs ludiques

Ces dernières années, plusieurs approches ludiques ont émergé : jeux vidéo adaptés, réalité virtuelle, parcours moteurs, plateformes interactives. Elles ont démontré leur capacité à augmenter la motivation et la répétition des mouvements, deux éléments essentiels en rééducation.

Cependant, ces solutions présentent elles aussi des limites :

• un coût matériel important (casques VR, consoles, capteurs) ;

• des mouvements parfois trop globaux, peu adaptés à un travail fin du poignet ou de l’avant‑bras ;

• une complexité d’installation dans un cabinet de kinésithérapie classique ;

• une fatigue visuelle ou cognitive pour certains patients.

FlexMouv reprend l’idée de jeu , mais dans une version beaucoup plus simple, accessible et centrée sur les articulations du membre supérieur.

4. Le modèle de référence étudié

Le dispositif présenté dans la vidéo de référence (https://www.youtube.com/watch?v=Pz2hE__z57c) propose un concept intéressant : un petit véhicule piloté par le patient, évoluant dans un parcours. Ce modèle met en avant :

• la dimension ludique,

• la mobilisation naturelle du bras,

• la possibilité de varier les parcours.

Cependant, il reste limité sur plusieurs aspects :

• la télécommande n’est pas pensée pour la rééducation du poignet ;

• les mouvements sollicités sont peu variés ;

• la difficulté n’est pas modulable ;

• aucun capteur ne permet de suivre la posture ou l’inclinaison.

FlexMouv reprend cette idée, mais l’adapte à un cadre thérapeutique : télécommande ergonomique, parcours modulable, sollicitation de plusieurs articulations, possibilité d’intégrer des capteurs, et approche plus sécurisée.

Conclusion de la veille

L’analyse des dispositifs existants montre un paysage contrasté : d’un côté, des solutions très avancées mais coûteuses et complexes ; de l’autre, des outils simples mais peu engageants. FlexMouv se situe volontairement entre ces deux extrêmes. Il propose :

• une solution accessible,

• simple à utiliser,

• ludique,

• adaptée à différents profils de patients,

• et capable de solliciter plusieurs articulations du membre supérieur.

C’est précisément cette combinaison de simplicité et d'efficacité qui fait l’originalité et la pertinence du projet.

2 - Concept du dispositif 

Le dispositif repose sur un principe simple : le patient tient une télécommande et dirige un petit véhicule dans un parcours, ce qui l’amène à mobiliser différentes articulations selon les mouvements nécessaires. 

PHOTO TYPE à AJOUTER

Objectifs principaux :

• améliorer la mobilité du poignet (flexion, extension, pronation, supination)

• renforcer les muscles de l’avant‑bras

• encourager la coordination bras‑main

• proposer une rééducation progressive et sécurisée

• offrir un appareil peu coûteux, robuste et accessible

Inspirations

Le concept s’inspire de dispositifs ludiques de rééducation, notamment le modèle présenté dans la vidéo suivante : https://www.youtube.com/watch?v=Pz2hE__z57c . Nous reprenons l’idée du parcours et du contrôle manuel, mais en l’intégrant dans un système robotisé plus complet.

Définition du projet :  la conception de FlexMouv part d’un constat simple : la rééducation du membre supérieur nécessite des exercices réguliers, variés et adaptés, mais les outils disponibles sont souvent soit trop basiques, soit trop coûteux, soit trop peu engageants pour maintenir la motivation du patient. Notre projet vise donc à proposer un dispositif robotisé accessible, ludique et suffisamment polyvalent pour être utilisé dans différents contextes thérapeutiques.

Besoins utilisateurs :

a) Les patients en rééducation (atteints d’arthrose, de tendinites, de séquelles d’AVC ou de maladies neuromusculaires) ont besoin :

• d’un outil simple à prendre en main, même en cas de faiblesse musculaire ;

• d’exercices progressifs, qui respectent leurs limites ;

• d’un dispositif motivant, qui détourne l’attention de la douleur ;

• d’un environnement sécurisé, sans risque de chute ou de surcharge articulaire.

b) Kinésithérapeutes, les professionnels recherchent : 

• un outil polyvalent, capable de solliciter plusieurs articulations ;

• un dispositif rapide à installer, utilisable en séance courte ;

• un support permettant d’observer la qualité du mouvement (fluidité, amplitude, précision) ;

• un matériel fiable et robuste, facile à intégrer dans une séance classique.

c) Centres de rééducation --> les structures ont besoin :

• d’un dispositif peu coûteux, compatible avec des budgets limités ;

• d’un matériel transportable, utilisable dans différentes salles ;

• d’un système modulable, adaptable à différents profils de patients ;

• d’un outil sans maintenance complexe, contrairement aux exosquelettes ou systèmes motorisés lourds.

 

3 - Description 

• Base stable accueillant le parcours

• Véhicule robotisé compact

• Télécommande ergonomique
  

Le dispositif permet de travailler :

Choix techniques :

Contraintes Techniques

• sécurité du patient

• ergonomie de la prise en main

• résistance mécanique

• coût réduit

• facilité de nettoyage

• modularité du parcours

MANQUE ICI : Croquis & dimensions

➡️ À ajouter :

• Croquis du véhicule

• Croquis de la télécommande

• Dimensions du parcours

• Dimensions du châssis

• Dimensions du support de bras (si présent)

MANQUE ICI : Liste du matériel sous forme de tableau

MANQUE ICI : Fichiers de conception & captures d’écran

➡️ À ajouter :

• Fichiers STL / DXF / Arduino

• Captures d’écran de la CAO

• Étapes de création (CAO → impression → assemblage)

4 - Cas d'usage

Mme L., 62 ans, est suivie en kinésithérapie pour une arthrose sévère du poignet droit, aggravée par plusieurs années de douleurs chroniques et une perte progressive de mobilité. Elle présente :

• raideur matinale importante

• douleur à la flexion et à l’extension

• faiblesse musculaire de l’avant‑bras

• difficulté à effectuer des gestes du quotidien (ouvrir un bocal, tourner une clé, porter un sac)

Son kinésithérapeute souhaite introduire un outil ludique, progressif et sécurisé pour compléter les exercices classiques.

5 - Scénario d'utilisation 

• La patiente s’installe. 

• Le kiné choisit un parcours simple, avec quelques virages et une petite rampe.
• Elle saisit la télécommande, et dirige le véhicule : 

  • tourner → pronation / supination

  • avancer → extension du bras

  • franchir un obstacle → flexion du poignet
    

• Pour une séance de 20 min, 5 min de jeu sont suffisants. 
• Le thérapeute observe la fluidité, l’amplitude et la précision des mouvements. 
• Le patient repose la télécommande à la fin de l'exercice. 

6. Analyse du modèle de référence

Le modèle de la vidéo propose un parcours simple avec un véhicule contrôlé manuellement. Nous reprenons :

• l’aspect ludique

• la stimulation motrice par le pilotage

• la modularité du parcours

Nous améliorons :

• l’ergonomie de la télécommande
  

• la variété des mouvements sollicités

• la possibilité d’adapter la difficulté

• la sécurité et la stabilité du bras

Gestion de projet

MVP (Minimum Viable Product) : Le robot avance, recule et tourne en réponse à l'inclinaison de la main, via communication sans fil, même sans boîtier final ni parcours.

Répartition des rôles :

Planning :

Liste du matériel avec coût :

Composant	Quantité	Rôle	Coût estimé
Adafruit Feather ESP32-S2	1	Microcontrôleur télécommande	~20€
Arduino Uno	1	Microcontrôleur robot	~10€
Grove ADXL345 ±16g	1	Accéléromètre (détection inclinaison)	~8€
Module nRF24L01+ GT020	2	Communication sans fil 2.4GHz	~3€ x2
DFRobot DRI0009 Shield	1	Driver moteur	~10€
Châssis DG007	1	Base mobile du robot	~10€
Moteurs DC	2	Propulsion	inclus châssis
Batterie externe USB	1	Alimentation Arduino	~10€
Batterie LiPo 3.7V	1	Alimentation Feather	~5€
Piles AA x4	4	Alimentation moteurs	~2€
MDF 3mm	~30x60cm	Parcours découpe laser	~3€
Filament PLA	~50g	Support main (3D)	~2€
Fils Dupont	~20	Connexions	~1€
TOTAL			~87€

Test, essais et erreurs

Montage

Code

Récepteur 

#include <SPI.h>
#include <RF24.h>

RF24 radio(9, 10);
const byte address[6] = "00001";

#define E1 5
#define M1 4
#define E2 6
#define M2 7

String lastCommand = "";

void stopAll() {
  analogWrite(E1, 0); analogWrite(E2, 0);
  digitalWrite(M1, LOW); digitalWrite(M2, LOW);
}
void avance() {
  digitalWrite(M1, LOW);  digitalWrite(M2, LOW);
  analogWrite(E1, 200); analogWrite(E2, 205);
}
void recule() {
  digitalWrite(M1, HIGH); digitalWrite(M2, HIGH);
  analogWrite(E1, 200); analogWrite(E2, 205);
}
void tourne_droite() {
  digitalWrite(M1, LOW);  digitalWrite(M2, HIGH);
  analogWrite(E1, 130); analogWrite(E2, 130);
}
void tourne_gauche() {
  digitalWrite(M1, HIGH); digitalWrite(M2, LOW);
  analogWrite(E1, 130); analogWrite(E2, 130);
}

void setup() {
  Serial.begin(9600);
  pinMode(E1, OUTPUT); pinMode(M1, OUTPUT);
  pinMode(E2, OUTPUT); pinMode(M2, OUTPUT);
  stopAll();
// Tentatives multiples de démarrage
  int tentatives = 0;
  while (!radio.begin()) {
    Serial.println("Tentative " + String(++tentatives) + "...");
    delay(500);
    if (tentatives > 10) {
      Serial.println("❌ nRF24L01 non détecté !");
      while(1);
    }
  }

  radio.setChannel(108);
  radio.openReadingPipe(0, address);
  radio.setPALevel(RF24_PA_LOW);
  radio.startListening();
  Serial.println("✅ Récepteur nRF24 prêt !");
}

void loop() {
  if (radio.available()) {
    char msg[10] = "";
    radio.read(&msg, sizeof(msg));
    String cmd = String(msg);
    cmd.trim();
    if (cmd.length() == 0) return; 
    if (cmd != lastCommand) {
      Serial.println("← Reçu : " + cmd);
      if      (cmd == "AVANCE") avance();
      else if (cmd == "RECULE") recule();
      else if (cmd == "DROITE") tourne_droite();
      else if (cmd == "GAUCHE") tourne_gauche();
      else if (cmd == "STOP")   stopAll();
      lastCommand = cmd;
    }
  }
}

Emetteur 

#include <SPI.h>
#include <RF24.h>
#include <Wire.h>
#include <ADXL345.h>

#define PIN_I2C_POWER 6
RF24 radio(9, 10);
const byte address[6] = "00001";

ADXL345 adxl;
#define SEUIL    0.25
#define DEADZONE 0.10
#define NB_SAMPLES 8
float ax_buf[NB_SAMPLES] = {0};
float ay_buf[NB_SAMPLES] = {0};
float ax_offset = 0;
float ay_offset = 0;
int buf_index = 0;
String lastCommand = "";

float moyenne(float* buf) {
  float sum = 0;
  for (int i = 0; i < NB_SAMPLES; i++) sum += buf[i];
  return sum / NB_SAMPLES;
}

String getCommand(float ax, float ay) {
  if (abs(ax) < DEADZONE && abs(ay) < DEADZONE) return "STOP";
  if (abs(ax) >= abs(ay)) {
    if (ax < -SEUIL) return "AVANCE";
    if (ax >  SEUIL) return "RECULE";
  } else {
    if (ay >  SEUIL) return "DROITE";
    if (ay < -SEUIL) return "GAUCHE";
  }
  return "STOP";
}

void setup() {
  Serial.begin(115200);
  pinMode(PIN_I2C_POWER, OUTPUT);
  digitalWrite(PIN_I2C_POWER, HIGH);
  delay(300);
  Wire.begin();
  adxl.powerOn();
  adxl.setRangeSetting(4);
  adxl.setSpiBit(0);
  if (!radio.begin()) {
    Serial.println("❌ nRF24L01 non détecté !");
    while(1);
  }
  radio.setChannel(108);
  radio.openWritingPipe(address);
  radio.setPALevel(RF24_PA_LOW);
  radio.stopListening();
  Serial.println("✅ Émetteur nRF24 prêt !");
  // Calibration : moyenne sur 50 échantillons au repos
  Serial.println("Calibration en cours, ne bougez pas...");
  float sum_x = 0, sum_y = 0;
  for (int i = 0; i < 50; i++) {
    double xyz[3];
    adxl.getAcceleration(xyz);
    sum_x += (float)xyz[0];
    sum_y += (float)xyz[1];
    delay(20);
  }
  ax_offset = sum_x / 50.0;
  ay_offset = sum_y / 50.0;
  Serial.print("Offset ax="); Serial.print(ax_offset);
  Serial.print(" ay="); Serial.println(ay_offset);
  Serial.println("✅ Calibration terminée !");
}

void loop() {
  double xyz[3];
  adxl.getAcceleration(xyz);
  ax_buf[buf_index] = (float)xyz[0] - ax_offset;
  ay_buf[buf_index] = (float)xyz[1] - ay_offset;
  float ax = moyenne(ax_buf);
  float ay = moyenne(ay_buf);
  String cmd = getCommand(ax, ay);
  if (cmd != lastCommand) {
    char msg[10];
    memset(msg, 0, sizeof(msg));
    cmd.toCharArray(msg, sizeof(msg));
    bool ok = radio.write(msg, sizeof(msg));
    Serial.println("→ Envoyé : " + cmd + (ok ? " ✅" : " ❌"));
    lastCommand = cmd;
  }
  delay(20);
}

Photos / Vidéos des tests

Problèmes rencontrés et solutions apportées :

Problème 1 - ESP32-S2 défectueux (port I2C inutilisable)

Lors des premiers tests, le scanner I2C ne détectait pas l'accéléromètre ADXL345 malgré un câblage correct. Après de nombreux essais de pins et de configurations, nous avons remplacé la carte par un autre Feather ESP32-S2, à ce moment là, l'accéléromètre a été immédiatement détecté. La première carte avait le port I2C interne défaillant (une branche du port I2C manquait).

Problème 2 - Bluetooth inexistant sur l'ESP32-S2

Notre première approche utilisait deux Feather ESP32-S2, un pour l'émetteur et un pour le récepteur, avec une communication Bluetooth. Nous avons découvert que l'ESP32-S2 ne dispose d'aucun Bluetooth (ni Classic ni BLE). Nous avons d'abord basculé sur WiFi UDP entre les deux ESP32-S2, solution qui fonctionnait correctement. Cependant, l'ESP32-S2 prévu pour le récepteur s'est révélé incompatible avec le shield DFRobot L298P, même après de nombreuses tentatives, les moteurs ne répondaient pas. Nous avons donc remplacé l'ESP32-S2 récepteur par un Arduino Uno sur lequel le shield s'emboîte directement, et adopté 2 nRF24L01 pour la communication sans fil entre les deux cartes.

Problème 3 - nRF24L01 instable au démarrage

Le module nRF24L01 n'était pas détecté de façon fiable au reset. Cause : le 3.3V de l'Arduino Uno ne fournit pas assez de courant lors des pics de démarrage. Solution logicielle : tentatives multiples de connexion avec délai.

Problème 4 - Valeurs accéléromètre incorrectes au repos

L'accéléromètre présentait un offset (ax = -0.35 au repos au lieu de 0). Solution : calibration automatique au démarrage sur 50 échantillons, calcul d'offset soustrait en temps réel.

Problème 7 - Défauts matériels

Au cours du projet, plusieurs problèmes matériels ont été rencontrés. Un fil de moteur soudé en usine s'est décroché lors des manipulations, interrompant l'alimentation d'un moteur. En l'absence de fer à souder disponible immédiatement, nous avons opté pour une solution temporaire en maintenant le fil en contact avec le connecteur via un fil Dupont. Solution fragile et soudure propre nécessaire pour la version finale.

🔶 MANQUE ICI : Tests, essais, erreurs

• Photos/vidéos des tests

• Problèmes rencontrés

• Solutions apportées

• Analyse des performances du prototype

🔶 MANQUE ICI : Photos/vidéos du prototype

➡️ Prototype en cours ? ➡️ Photos à insérer.

🔶 MANQUE ICI : Objet final

➡️ Photos finales ➡️ Analyse du résultat ➡️ Respect du cahier des charges

🔶 MANQUE ICI : Pistes d’amélioration

➡️ Exemples :

• Ajout de capteurs

• Application mobile

• Parcours gamifiés

• Retour haptique

 

 

Sources & ressources

➡️ Tutoriels Arduino ➡️ Documentation NRF24L01 ➡️ Ressources FabLab ➡️ Articles scientifiques

• Documentation Adafruit Feather ESP32-S2 : https://learn.adafruit.com/adafruit-esp32-s2-feather
• Librairie ADXL345 Seeed Studio : https://github.com/Seeed-Studio/Accelerometer_ADXL345
• Librairie RF24 : https://docs.arduino.cc/libraries/rf24/
• Documentation DFRobot L298P Shield : https://www.alldatasheet.fr/html-pdf/2214539/DFROBOT/DRI0009/342/1/DRI0009.html