Différences entre versions de « Projets:Orthèse de Coude Robotisée »
m |
m |
||
| Ligne 1 : | Ligne 1 : | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
= Equipe (Porteur de projet et contributeurs) = | = Equipe (Porteur de projet et contributeurs) = | ||
Humanlab SP | Humanlab SP | ||
| Ligne 12 : | Ligne 6 : | ||
== Description du problème == | == Description du problème == | ||
| − | Problème : Emilie & Anouck sont deux enfants ayant un coude non fonctionnel. | + | Problème : Emilie & Anouck sont deux enfants ayant un coude non fonctionnel.<br> |
| − | But : Concevoir un système leur permettant de librement remobiliser leur bras. | + | But : Concevoir un système leur permettant de librement remobiliser leur bras.<br> |
| − | Mission : Permettre le mouvement du coude dans les deux sens sans postions prédéfinies. | + | Mission : Permettre le mouvement du coude dans les deux sens sans postions prédéfinies.<br> |
| − | Objectifs : Piloter le bras avec une force suffisante afin d'effectuer le mouvement de flexion le plus complet possible. | + | 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> |
| − | Parties prenantes : L'utilisateur du système (Emilie), sa famille et n'importe quelle personne interagissant avec l'utilisateur. | + | Parties prenantes : L'utilisateur du système (Emilie), sa famille et n'importe quelle personne interagissant avec l'utilisateur.<br> |
=== Contexte opérationnel === | === Contexte opérationnel === | ||
| Ligne 42 : | Ligne 36 : | ||
= Analyse de l'existant = | = Analyse de l'existant = | ||
| − | * Appareillage classique, orthèse thermoformée non motorisée avec verrouillage par cliquet | + | * Appareillage classique, orthèse thermoformée non motorisée avec verrouillage par cliquet<br> |
| + | |||
| + | * Projet “Assistive Robotic Arm” open-source : https://sites.google.com/site/ourkidscandoanything/build-your-own<br> | ||
| + | [[File:pasted image 6.png|right|400px]] | ||
| + | [[File:unnamed.png|left|400px]]<br> | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| − | |||
= Architecture physique = | = Architecture physique = | ||
== Prototype initial == | == 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.<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> | ||
| + | Notre choix final s'est porté sur le modèle d'actionneur linéaire LA-T8 //insérer lien.<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 piloter 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 ce membre. Nous sommes partis sur un capteur de flexion fixé sur un doigt afin de coupler la flexion du doigt à la flexion du coude. Néanmoins, afin de discriminer les intentions réelles d'entraîner un mouvement de coude des simples moments où elle souhaite 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é. 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 == | ||
| Ligne 82 : | Ligne 105 : | ||
|} | |} | ||
| − | * N'importe quel microcontrolleur 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) | + | * N'importe quel microcontrolleur 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> |
| − | ** 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 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. | + | ** 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 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> |
| − | *** 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. | + | *** 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.<br> |
==Outils nécessaires== | ==Outils nécessaires== | ||
| − | * Imprimante 3D | + | * Imprimante 3D<br> |
| − | * Outils de visserie | + | * Outils de visserie<br> |
| − | * Fer à souder | + | * Fer à souder<br> |
==Fichiers source== | ==Fichiers source== | ||
| Ligne 99 : | Ligne 122 : | ||
== Code == | == Code == | ||
| − | + | ||
Version du 8 juillet 2021 à 17:58
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.
Contexte opérationnel
// images a insérer
Cahier des charges
Exigences fonctionnelles : Exigences non-fonctionnelles : - performances : - interfaces : - opérationnelles : - contraintes :
// images a insérer
Description de la solution
Architecture fonctionnelle
// insérer images
Architecture organique
// insérer images
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.
Afin de choisir le capteur, il faut analyser les différents actions possibles d'Emilie. L'idéal est que le système soit piloter 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 ce membre. Nous sommes partis sur un capteur de flexion fixé sur un doigt afin de coupler la flexion du doigt à la flexion du coude. Néanmoins, afin de discriminer les intentions réelles d'entraîner un mouvement de coude des simples moments où elle souhaite 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é. 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
Réalisation
Matériel nécessaire
| Description | Quantité | Prix à l’unité | Coût |
|---|---|---|---|
| Arduino Nano* | 1 | 20.0 € | Example |
| Actionneur Linéaire LA-T8 5mm/s** | 1 | 20.0 € | Example |
| MC33926 Motor Driver Carrier** | 1 | 15.7 € | Example |
| USB Charger for 7.4V LiPo Battery SKU DFR0564 | 1 | 4.7 € | Example |
| Batterie 7.4V - 1000Ah, 5C*** | 1 | 11.6 € | Example |
| Diode - 1N4148 | 1 | 0.5 € | Example |
| Capacitances - 100pf, 10nf | 2 | 1.0 € | Example |
| Inductance - 10mH | 1 | 0.5 € | Example |
| Résistances - 10k, 1M, 3.3k | 3 | 1.5 € | Example |
| Divers (câbles, visserie, matériel imprimé, ...) | 15.0 € | Example | |
| Total | 90.5 € | Example |
- N'importe quel microcontrolleur 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 {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 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.
- 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 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 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.
- 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.
Outils nécessaires
- Imprimante 3D
- Outils de visserie
- Fer à souder
