Différences entre versions de « Projets:Orthèse de Coude Robotisée »

De wikilab
m
 
(23 versions intermédiaires par 4 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
= Equipe (Porteur de projet et contributeurs) =
+
{{Infobox projet
 +
|Image principale=1625128.jpg
 +
|Description=Orthèse de coude motorisée permettant de bouger le bras dans les deux sens
 +
|Porteur de projet=Emilie, Anouck
 +
|Contributeurs=Sijobert, Erwan Ollive
 +
|Fabmanager=Sijobert
 +
|Référent documentation=Erwan Ollive, Sijobert
 +
|Catégorie de handicap=Motricité, Membre supérieur
 +
|Etat d'avancement=Réalisés
 +
|Statut de la documentation=Complète
 +
|Relecture de la documentation=Non vérifiée
 +
|Techniques=moteur, arduino
 +
|Licence=by-sa
 +
|Projet date=2020-08-27
 +
|Nom humanlab=Humanlab_SP
 +
}}
 +
 
 +
== Equipe (Porteur de projet et contributeurs) ==
 
Humanlab SP
 
Humanlab SP
  
= Description du projet =
+
== Description du projet ==
  
 
== Description du problème ==
 
== Description du problème ==
Ligne 9 : Ligne 26 :
 
But : Concevoir un système leur permettant en complète autonomie de remobiliser leur bras.<br>
 
But : Concevoir un système leur permettant en complète autonomie de remobiliser leur bras.<br>
 
Mission : Permettre le mouvement du coude dans les deux sens sans postions prédéfinies.<br>
 
Mission : Permettre le mouvement du coude dans les deux sens sans postions prédéfinies.<br>
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.<br>
+
Objectifs :  
 +
* Monter un moteur d'une force suffisante pour à minima porter le poids du système s={avant-bras, orthèse}
 +
* Effectuer le mouvement de flexion le plus complet possible, sans gêner l'utilisateur
 +
* Piloter le bras à l'aide d'une commande simple et intuitive
 
Parties prenantes : L'utilisateur du système (Emilie), sa famille et n'importe quelle personne interagissant avec l'utilisateur.<br>
 
Parties prenantes : L'utilisateur du système (Emilie), sa famille et n'importe quelle personne interagissant avec l'utilisateur.<br>
  
Ligne 37 : Ligne 57 :
  
 
* Projet “Assistive Robotic Arm” open-source : https://sites.google.com/site/ourkidscandoanything/build-your-own<br>
 
* Projet “Assistive Robotic Arm” open-source : https://sites.google.com/site/ourkidscandoanything/build-your-own<br>
[[File:pasted image 6.png|right|400px]]
+
<gallery>
[[File:unnamed.png|left|400px]]<br>
+
unnamed.png|Lorelei, porteur du projet "Assistive Robotic Arm"
 
+
pasted_image_6.png|Schéma du projet de Lorelei
 
+
</gallery>
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  
 
+
== Architecture physique ==
 
 
 
 
= Architecture physique =
 
  
 
[[File:OrtheseCoudeRobotisee Phys.png|700px]]
 
[[File:OrtheseCoudeRobotisee Phys.png|700px]]
Ligne 68 : Ligne 69 :
  
 
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.<br>
 
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.<br>
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.<br>
+
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.<br>
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. <br>
+
Notre choix final s'est porté sur le modèle d'[https://fr.aliexpress.com/item/4000079971200.html?spm=a2g0s.9042311.0.0.27426c37kFg4h5 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. <br>
  
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.<br>
+
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.<br>
  
 
== Prototype retenu ==
 
== 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 :<br>
+
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 :<br>
  
 
{| class="wikitable"
 
{| class="wikitable"
Ligne 89 : Ligne 90 :
 
|}<br>
 
|}<br>
  
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.<br>
+
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.<br>
La solution finale est alors inspirée d'une publication du Disney Research Lab : [https://la.disneyresearch.com/publication/touche-enhancing-touch-interaction-on-humans-screens-liquids-and-everyday-objects/ 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.<br>
+
La solution software finale est alors inspirée d'une publication du Disney Research Lab : [https://la.disneyresearch.com/publication/touche-enhancing-touch-interaction-on-humans-screens-liquids-and-everyday-objects/ 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 quelques composants passifs (résistances, bobine et capacitances) ; il propose donc une approche low-cost très facilement reproductible. Une partie du code provient notamment du travail [http://www.illutron.dk/filter/member de deux makers Danois (DZL and Hobye)] qui ont proposé il y a quelques années une implémentation sur les microcontrôleurs 8-bits.<br>
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é.<br>
+
 
  
= Réalisation =
 
 
== Matériel nécessaire ==
 
== Matériel nécessaire ==
  
Ligne 124 : Ligne 124 :
 
|}
 
|}
  
<sup>1</sup>N'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)<br>
+
<sup>1</sup>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)<br>
  
<sup>2</sup>L'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.<br>
+
<sup>2</sup>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.<br>
  
<sup>3</sup>La 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. <br>
+
<sup>3</sup>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. <br>
  
 
==Outils nécessaires==
 
==Outils nécessaires==
Ligne 135 : Ligne 135 :
 
* Fer à souder<br>
 
* Fer à souder<br>
  
==Fichiers source==
+
== 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.
 +
[[File:Orthese ideal Drawing v4.pdf|left|thumb]]<br>
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
== 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).<br>
 +
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.<br>
 +
<gallery>
 +
Capteur_orthese.jpg|Capteur capacitif monté
 +
Capteur1.jpg|Capteur capacitif démonté
 +
PAVE FIL CUIVRE v6 Drawing v1.pdf|Schéma capteur capacitif
 +
</gallery>
 +
==Schéma électronique==
 +
 
 +
[[File:Emilie breadboard1.png|700px]]
 +
[[File:Emilie breadboard zoom.png|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.<br>
 +
L'assemblage nécessite 8 vis M3x28 ainsi que 8 écrous M3.<br>
 +
<gallery>
 +
Boitier2.jpg|Boitier monté
 +
Boitier1.jpg|Boitier en flexion
 +
Boitier3.png|Boitier - vue en coupe
 +
</gallery>[[File:VideoBoitier.mov|left|thumb]]<br>
 +
[[File:Boitier Emilie.zip|thumb]]
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
  
== Assemblage ==
 
  
 
== Code ==
 
== 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.
 +
 
[[File:EmilieArm v3.zip|thumb]]
 
[[File:EmilieArm v3.zip|thumb]]
 +
 +
= Démonstration =
 +
 +
[[File:Emilie.jpg|400px]]
 +
 +
// insérer video
 +
 
= Suite =
 
= Suite =
  
 
En attendant les retours d'utilisation, nous pouvons déjà évoquer certaines pistes d'amélioration pour une v2 :<br>
 
En attendant les retours d'utilisation, nous pouvons déjà évoquer certaines pistes d'amélioration pour une v2 :<br>
 
* 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.
 
* 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.
+
* 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.<br>
 +
<gallery>
 +
Capteurs capacitifs.jpg|A gauche la v1, à droite la v2 imprimée en bi-matière
 +
</gallery>
 +
 
 
* 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.
 
* 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.
  
  
 
[[Category:Projets]]
 
[[Category:Projets]]
[[Category:Concept]]
+
[[Category:Réalisés]]
 
[[Category:Motricité]]
 
[[Category:Motricité]]
 
[[Category:Membre supérieur]]
 
[[Category:Membre supérieur]]
 
[[Category:Humanlab_SP]]
 
[[Category:Humanlab_SP]]

Version actuelle datée du 9 décembre 2022 à 12:39

Orthèse de Coude Robotisée

1625128.jpg

Informations
Description Orthèse de coude motorisée permettant de bouger le bras dans les deux sens
Catégorie Motricité Membre supérieur
Etat d'avancement Réalisés
Techniques moteur, arduino
Durée de fabrication
Coût matériel
Niveau
Licence by-sa
Date de création 2020-08-27
Équipe
Porteur de projet Emilie, Anouck
Contributeurs Sijobert, Erwan Ollive
Fabmanager Sijobert
Référent documentation Erwan Ollive, Sijobert
Nom humanlab Humanlab_SP
Documentation
Statut de la documentation Complète
Relecture de la documentation Non vérifié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 :

  • Monter un moteur d'une force suffisante pour à minima porter le poids du système s={avant-bras, orthèse}
  • Effectuer le mouvement de flexion le plus complet possible, sans gêner l'utilisateur
  • Piloter le bras à l'aide d'une commande simple et intuitive

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 :

OrtheseCoudeRobotisee Modes.png


Cahier des charges

OrtheseCoudeRobotisee CdC.png
OrtheseCoudeRobotisee CdC2.png

Description de la solution

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

OrtheseCoudeRobotisee Orga.png

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

Architecture physique

OrtheseCoudeRobotisee Phys.png

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 quelques composants passifs (résistances, bobine et capacitances) ; il propose donc une approche low-cost très facilement reproductible. Une partie du code provient notamment du travail de deux makers Danois (DZL and Hobye) qui ont proposé il y a quelques années une implémentation sur les microcontrôleurs 8-bits.


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 €

1N'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)

2L'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.

3La 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.

Orthese ideal Drawing v4.pdf











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.

Schéma électronique

Emilie breadboard1.png Emilie breadboard zoom.png


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.
L'assemblage nécessite 8 vis M3x28 ainsi que 8 écrous M3.


Fichier:Boitier Emilie.zip








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

Emilie.jpg

// 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.
  • 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.