Projets:Orthèse de Coude Robotisée

Equipe (Porteur de projet et contributeurs)

Humanlab SP

Description du projet

Description du problème

Problème : Emilie & Anouck sont deux enfants ayant un coude non fonctionnel.
But : Concevoir un système leur permettant en complète autonomie de remobiliser leur bras.
Mission : Permettre le mouvement du coude dans les deux sens sans postions prédéfinies.
Objectifs : Piloter le bras avec une force suffisante à l'aide d'une commande simple et intuitive afin d'effectuer le mouvement de flexion le plus complet possible.
Parties prenantes : L'utilisateur du système (Emilie), sa famille et n'importe quelle personne interagissant avec l'utilisateur.

Modes opérationnels

Très simplement, le système doit passer par les phases suivantes :

Cahier des charges

Description de la solution

Partant du cahier des charges, nous pouvons imaginer une solution comme suivante :

Nous cherchons donc des solutions similaires déjà réalisées dans la partie suivante.

Analyse de l'existant

• Appareillage classique, orthèse thermoformée non motorisée avec verrouillage par cliquet
  

• Projet “Assistive Robotic Arm” open-source : https://sites.google.com/site/ourkidscandoanything/build-your-own
  

• 

  Lorelei, porteur du projet "Assistive Robotic Arm"

• 

  Schéma du projet de Lorelei

Architecture physique

Prototype initial

Le moteur est l'élément principal puisqu'en plus d'être le seul élément nécessairement présent sur l'orthèse, c'est lui qui assure la fonction principale. Les deux critères principaux sont donc ici la puissance du moteur et son encombrement. Notre choix s'est donc porté sur un actionneur linéaire, permettant un positionnement peu encombrant par rapport aux moteurs rotatifs.
Idéalement, le moteur doit comporter trois fils à la manière d'un servomoteur afin de permettre un retour précis et fiable de sa position. Ainsi, nous sommes partis sur un moteur linéaire à feedback d'Actuonix. Malheureusement en plus d'être particulièrement cher, le moteur choisi ne s'avérait pas suffisamment puissant malgré un faible encombrement.
Notre choix final s'est porté sur le modèle d'actionneur linéaire LA-T8 (6V, 5mm/s, 188N, 50mm de course). Celui-ci ne possédant pas de signal de retour de position, nous avons tenté de rajouter un capteur supplémentaire. Notre choix s'est d'abord porté sur un capteur linéaire de pression : faible en encombrement, celui-ci se colle sur le moteur ou sur une partie fixe encastrée. Le mécanisme testé n'étant pas concluant, nous sommes partis sur un capteur d'élongation faisant varier sa résistance en fonction de son étirement (stretch sensor). Néanmoins, celui-ci manque de précision en statique : un changement de valeur a été constaté alors que le moteur ne bougeait pas. La seule solution jugée satisfaisante, c'est-à-dire assurant un suivi de la position suffisamment précis, est l'utilisation d'un potentiomètre linéaire. Le défi est de l'intégrer de manière discrète à l'orthèse au vu de son encombrement.

Afin de choisir le capteur qui entraîne le mouvement du moteur, il faut analyser les différentes actions possibles d'Emilie. L'idéal est que le système soit piloté par une action fiable mais mobilisant le moins de membres et d'efforts possible. Etant donné qu'elle ne peut pas bouger son bras depuis l'épaule jusqu'au poignet, l'idée initiale est de se servir des doigts de la main de ce même membre : nous sommes alors partis sur un capteur de flexion fixé sur le doigt, qui couplerait ainsi la flexion du doigt à la flexion du coude. Afin de discriminer les moments où elle fléchit son doigt pour entraîner un mouvement de coude des moments pour attraper un objet, nous avions l'intention d'utiliser deux capteurs de flexion sur deux doigts de sa main : si les deux sont fléchis, le mouvement du coude n'est pas demandé. Néanmoins, il se trouve qu'Emilie peut bouger deux doigts, mais pas de manière indépendante : le mouvement de son majeur entraîne le mouvement de son index. Nous sommes donc partis sur un autre système, tout en gardant en tête les contraintes initiales.

Prototype retenu

Tout en restant sur l'idée de baser la commande sur les mouvements de ses doigts, nous avons cherché un nouveau capteur pour effectuer la commande. Nous sommes alors partis sur l'idée du toucher capacitif : ainsi non seulement le capteur ne nécessite aucun effort de force/pression de la part de l'utilisateur, mais en plus il ne s'activera pas lors de la préhension d'objets. Plusieurs technologies toutes faites existent pour la réalisation d'un tel capteur, dont notamment :

Technologies capacitives

Technologie	Avantages	Inconvénients
Peinture conductive & TouchBoard de Bare Conductive	Se peint sur toutes surfaces, taille et endroit ajustables	S'écaille avec le temps, Cher
Écran LCD	Fiable et précis	Fragile, très difficile à monter sur l'orthèse (forme géométrique strictement plane)
Capteur capacitif sur PCB (exemple Adafruit)	Fiable et précis	Difficile à monter sur l'orthèse

La TouchBoard paraît alors la solution la plus adaptée. Cependant vu son prix élevé et étant donné qu'elle se programme avec le framework d'Arduino, nous avons souhaité coupler la peinture ainsi que les libraires software de Bare Conductive avec une carte de la gamme d'Arduino - des cartes plus accessibles dont certaines moins encombrantes. L'Arduino n'étant cependant pas faite pour ce genre de traitement du signal, le capteur est finalement trop peu fiable en utilisant directement les librairies natives de Bare Conductive.
La solution software finale est alors inspirée d'une publication du Disney Research Lab : le projet "Touché". Le principe, appelé "Swept Frequency Capacitive Sensing", est le suivant : un circuit capacitif excite un objet conducteur par un câble en lui envoyant un signal électrique et mesure son signal de réponse. Ce dernier est perturbé par les propriétés électriques de la main humaine, ce qui permet de détecter le toucher. Contrairement à la plupart des technologies capacitives, le signal est émis à l'objet en balayant un large spectre de hautes fréquences à la manière d'un oscillateur (d'où son nom) et non à une fréquence fixe. Notre version du code effectue une moyenne mobile des différentes réponses aux différentes fréquences, permettant de manière robuste de détecter le toucher. Bien qu'originellement destiné à des applications de reconnaissances de gestes (la technologie permet de reconnaitre la présence d'un doigt, de deux, d'une main, de deux mains, d'un doigt et une main, etc. via de la classification), le projet "Touché" ne nécessite qu'un objet conducteur (quel qu'il soit) et de quelques composants passifs et propose donc une approche low-cost très facilement reproductible. Une partie du code provient donc du travail de deux makers Danois qui ont proposé il y a quelques années une implémentation sur les microcontrôleurs 8-bits.

Réalisation

Matériel nécessaire

Caption text

Description	Quantité	Prix à l’unité	Coût
Arduino Nano1	1	20.0 €	20.0 €
Actionneur Linéaire LA-T8 5mm/s2	1	20.0 €	20.0 €
MC33926 Motor Driver Carrier2	1	15.7 €	15.7 €
Batterie 7.4V - 1000Ah, 5C3	1	11.6 €	11.6 €
USB Charger for 7.4V LiPo Battery SKU DFR05643	1	4.7 €	4.7 €
Diode - 1N4148	1	0.06 €	0.06 €
Capacitances - 100pf, 10nf	2	0.85 €	1.70 €
Inductance - 10mH	1	0.85 €	0.85 €
Résistances - 10k, 1M, 3.3k	3	0.30 €	0.90 €
Divers (câbles, visserie, matériel imprimé, ...)			10.0 €
Total			85.51 €

¹N'importe quel microcontrôleur 8-bits fait l'affaire. La Nano ici est un compromis entre performances, faible encombrement et grande accessibilité (grande communauté donc difficulté moins grande à faire évoluer le système, facile à trouver chez les distributeurs, faible prix)

²L'actionneur doit être suffisamment puissant afin de lever aisément à minima le système S={avant-bras de l'enfant, partie avant-bras de l'orthèse}. Jouer sur la longueur de course permet d'optimiser le placement du moteur sur l'orthèse non seulement par rapport au bras de levier mais aussi par rapport à la flexion maximale permise (une flexion trop faible ne permet pas un mouvement complet du coude, mais une flexion trop importante n'est pas nécessaire mais en plus peut gêner l'utilisateur si elle est trop prononcée). En fonction du moteur, on choisira le driver adapté - ici le MC33926 propose le pilotage d'un seul moteur avec circuits de protections et retour sur la consommation.

³La batterie doit être de 7.4V minimum pour correctement alimenter à la fois le moteur ainsi que le microcontrôleur. Son autonomie est un compromis entre le temps d'utilisation avant recharge (une fois par jour maximum pour une utilisation confortable, le système pouvant être chargé durant la nuit) et l'encombrement dans le boitier. De même, en fonction de la batterie on choisira le module de charge adapté - ici le DFR0564 intègre des circuits de protection et permet de ne rien débrancher pour le chargement.

Outils nécessaires

• Imprimante 3D
  
• Outils de visserie
  
• Fer à souder
  

Positionnement du moteur

Comme évoqué précédemment, le positionnement du moteur sur l'orthèse est un compromis entre le bras de levier et la flexion maximale du coude. Une simulation sur Fusion 360 nous a permis de positionner le moteur pour la flexion, et un calcul des sommes des forces nous permet d'estimer l'angle de la force de l'actionneur linéaire.

Capteur capacitif

Pour une application fixe - c'est-à-dire reliée à une alimentation sur secteur, le prototype s'est avéré très efficace. Cependant pour une application embarquée, le pic du signal ne change pas de manière significative. Ceci est dû au fait que la différence de potentiel à la masse de référence n'est pas suffisamment importante. Une première idée de solution est alors que l'utilisateur doit en permanence être en contact avec la masse. Ceci permet également de "verrouiller" le toucher : seul l'utilisateur relié à la masse peut activer le capteur. Malheureusement ce contact permanent étant compliqué à mettre en oeuvre (d'un point de vue du confort, de la fiabilité, de la sécurité du dispositif, ...), nous avons repensé notre capteur afin que l'utilisateur touche à la fois la masse et le câble du signal lors d'un seul touché (voir plus dans la partie suivante).
Ainsi, nous avons pensé à un peindre un motif qui permettrait à l'utilisateur de toucher à la fois la masse et à la fois le fil du signal lors d'un toucher. Nous avions d'abord pensé à un motif type "spiral" que l'on viendrait découper à l'aide d'une découpe laser dans de l'aluminium double surface que l'on viendrait coller sur l'orthèse. Après quelques essais, il s'avère que l'aluminium du double face empêche l'utilisation de la découpe laser, même lorsque placé à la découpe sur son autre face. Nous avons alors choisi un nouveau motif "zig-zag" plus facile à découper avec précision au cutter. Néanmoins il se trouve également que le câble ne se soudait pas au double-face aluminuim, et il en est de même que son alternative double-face cuivre. Ainsi nous avons eu l'idée de coudre deux fils de cuivre au travers d'une pièce imprimée en 3D que nous fixons de manière rigide (rivets / vis) à l'orthèse.

• 

  Capteur capacitif monté

• 

  Capteur capacitif démonté

• 

  Schéma capteur capacitif

Schéma électronique

700px

Boitier

Le boitier, séparé de l'orthèse, devait contenir toute l'électronique restante. D'un point de vue confort, l'utilisateur serait plus à l'aise avec un port du boitier au niveau de la hanche, à la manière d'une banane. Afin que le boitier épouse au maximum la forme de la hanche de l'utilisateur, nous avons opté pour une solution hybride entre boitier rigide et flexible : celle-ci consiste en deux boitiers rigides imprimés en PETG se vissant sur une troisième partie imprimée en Filaflex/TPU - filament flexible. Afin de sécuriser l'ensemble, il n'y a que 4 câbles qui font la jonction entre les deux parties rigides. Le passage de câble s'effectue à l'intérieur de la partie flexible.

• 

  Boitier monté

• 

  Boitier en flexion

• 

  Boitier - vue en coupe

Code

Le code est entièrement commenté. Le toucher est détecté en fonction d'une valeur seuil : le toucher entraîne la baisse de la moyenne mobile lue par le capteur. Cette valeur ainsi que l'écart de valeur peuvent varier en fonction des personnes, ainsi il est important de calibrer le système en choisissant une valeur fiable. Le système peut détecter deux types d'appuis sur le capteur : un appui long ou un appui court. Le mouvement du moteur est entraîné par un appui long sur le capteur. La direction du moteur dépend de s'il y a un appui court qui précède l'appui long : si le système détecte un appui court avant un appui long, l'arbre du moteur sort. Si le système détecte un appui long uniquement, l'arbre du moteur rentre. En résumé :

• un appui long => l'orthèse monte ;
• un appui court puis un appui long => l'orthèse descend.

Le système garde en mémoire un appui court durant 3 secondes : si un appui court a lieu dans les 3 secondes qui précèdent l'appui long, l'orthèse descend. Si un appui court a eu lieu il y a plus de 3 secondes avant un appui long, le système considère qu'il n'y a pas eu d'appui court et l'orthèse monte. Ceci permet de ne pas garder en mémoire les touchers non-intentionnelles entre les moments ou l'utilisateur souhaite mouvoir son membre, ceux-ci pouvant fausser la commande.

Le code est constitué de 7 parties distinctes :

• partie "pinout", la déclaration des variables liées au capteur/moteur/pins ;
• partie "setup", la déclaration des entrées/sorties et états initiaux ;
• partie "loop", qui se résume à l'activation du signal capacitif et d'un switch..case en fonction du toucher détecté ;
• partie "état moteur", les fonctions de mesure de consommation/position du moteur ;
• partie "capacitive", une fonction permettant la génération du signal envoyé et la mesure du signal retour du capteur capacitif ;
• partie "mouvements", les fonctions de mouvement haut/bas de l'orthèse ;
• partie "multi-click et évènements", les fonctions de gestion d'appui longs/courts/.

Quelques variables clés pour s'approprier l'orthèse :

• La variable seuil à calibrer est TRIGGERVALUE dans la partie "pinout" ;
• La partie "pinout" comporte des déclarations de LED afin de debugger/calibrer le système plus facilement. Si vous souhaiter vous en servir, il y a deux variables booléennes à modifier : la variable debug_mode permet l'activation de LEDs ainsi que la communication serie, tandis que la variable demo_mode active uniquement les LEDs.
• La variable MAX_ClICK_TIMER de la partie "pinout" permet de définir le temps de mémoire de l'appui court (ici de 3 secondes) ;
• Pour inverser le comportement de l'orthèse aux touchers, il suffit d'inverser les noms des fonctions motionUp et motionDown dans la partie "mouvements" ;
• La variable DCgap dans la partie "multi-click" permet de modifier le temps de ce que le système considère un appui court ;
• La variable holdTime dans la partie "multi-click" permet de modifier le temps de ce que le système considère un appui long.

Fichier:EmilieArm v3.zip

Démonstration

// insérer video

Suite

En attendant les retours d'utilisation, nous pouvons déjà évoquer certaines pistes d'amélioration pour une v2 :

• Le système manque un capteur permettant un retour de position du moteur. Celui-ci pourrait être assuré par un potentiomètre linéaire type fader de table de mixage, reste à savoir comment l'intégrer de façon discrète. Des capteurs de fin de courses sont intégrés au moteur, permettant une sécurité du système et évitant une surconsommation. Néanmoins, même si le moteur ne consomme pas lorsque il arrive en fin de course, le signal envoyé par l'arduino lui consomme quelques mA.
• Fiabiliser le capteur capacitif. Celui-ci est fonctionnel, mais nous avons réfléchi à une alternative que nous avons déjà testé. Cette seconde version consiste en une pièce imprimée en deux couches de PLA différentes : une première couche de PLA classique, sur lequel s'ajoute une couche de PLA Carbone conducteur. Bien que plus esthétique, nous ne l'avons pas implémenté car nous ne connaissions pas le comportement du PLA Carbone sur le long terme, notamment concernant sa conductivité en s'abîmant avec le temps.
  

• 

  A gauche la v1, à droite la v2 imprimée en bi-matière

• Une LED indique actuellement si le système est allumé ou non, ainsi l'utilisateur peut éteindre le système à l'aide d'un switch pour éteindre la batterie. Une amélioration pour une V2 serait de la faire clignoter lorsque la batterie est faiblement chargé (<15% par exemple) afin d'avertir l'utilisateur qu'il ne faudra pas tarder à la charger.