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 extrêmement élevé, inaccessible 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.

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 ludicité, 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.

MANQUE ICI : Définition complète du projet (attendu obligatoire)

➡️ À ajouter :

• Besoins utilisateurs (patients, kinés, centres)

• Fonctionnalité principale (pilotage du véhicule)

• Fonctionnalités secondaires (parcours modulable, difficulté réglable, sans fil, etc.)

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 une communication sans fil et avec support pour la main et un 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	~17€
Châssis DG007	1	Base mobile du robot	~10€
Moteurs DC	2	Propulsion	inclus châssis
Batterie LiPo 3.7V	1	Alimentation Feather	~5€
Piles AA x4	4	Alimentation moteurs	~2€
Peuplier 6mm	~50x80cm	Parcours découpe laser	~3€
Filament PLA	~50g	Support main (3D)	~2€
Fils Dupont	~20	Connexions	~1€
TOTAL			~84€

Test, essais et erreurs

Montage

Code

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);
}

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;
    }
  }
}

Photos et vidéos des tests

Vidéo test

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.

Problème 3 - Incompatibilité entre l'ESP32-S2 et le Shield

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 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 5 - nRF24L01 récepteur non fonctionnel en 3.3V

Malgré les caractéristiques du module indiquant une alimentation de 3.3V, le module côté récepteur ne fonctionnait pas de façon stable à cette tension sur l'Arduino Uno. En branchant le VCC sur le 5V de l'Arduino Uno, le module a fonctionné correctement. Explication probable : le régulateur 3.3V de l'Arduino Uno ne fournit pas suffisamment de courant lors des pics de transmission radio, ce qui entraîne des chutes de tension et des dysfonctionnements.

 

Photos et vidéos du prototype final

Vidéo test prototype

Analyse critique du prototype 

Limites du dispositif

• Absence de retour de force (pas de résistance réelle)
• Pas de suivi des performances
• Précision dépendante de la stabilité du capteur ADXL345

Pistes d’amélioration

• Utilisation d’un capteur IMU (gyro + accéléromètre) comme le MPU6050, pour améliorer la précision et la stabilité des mouvements
  
• Ajouter une résistance physique à la télécommande  (exemple élastique)
• Parcours gamifié avec en plusieurs niveaux de difficulté progressif et un système de score
• Application mobile simple de pour visualiser les progrès avec l'historique des séances

Sources & ressources

➡️ Articles scientifiques

• Vidéo d'inspiration : https://www.youtube.com/watch?v=Pz2hE__z57c
• 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