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 de librement 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
// images a insérer
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
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 pouvoir retourner sa position afin de permettre un contrôle précis et fiable de la 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 //insérer lien. Celui-ci ne possédant pas 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. 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, il faut analyser les différents 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 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 :
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 | Peu être difficile à insérer 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 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, le capteur est finalement trop peu fiable en utilisant directement les librairies natives de Bare Conductive.
La solution 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 : le circuit capacitif balaie un large spectre de hautes fréquences à la manière d'un oscillateur (et non à une fréquence fixe comme habituellement) sur un objet conducteur relié par un câble, et renvoie le pic du signal qui change lorsqu'une personne interagit avec 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.
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 : l'idée 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é.
Réalisation
Matériel nécessaire
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 € |
1N'importe quel microcontrôlleur 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)
2L'actionneur doit être suffisamment puissant afin de lever aisément à minima le système {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.
3La batterie doit être de 7.4V minimum pour correctement alimenter à la fois le moteur ainsi que le microcontrolleur. 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 SKU 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
Fichiers source
Assemblage
Code
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.