Wiki de Projets IMA - Contributions de l’utilisateur [fr]

IMA5 2018/2019 P04

2019-02-26T17:31:39Z

Thubert : /* Liste des tâches à effectuer */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste non exhaustive des tâches effectuée==

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
*Définition du schéma électrique
*Création d'un visuel du schéma électrique
*Définition des équations du système
*Élaboration de la REM du système
*Création d'un visuel pour la REM
*Implémentation sous MATLAB de la REM et les équations du système
*Choix éventuels de valeurs de composants

====Ajout de l'asservissement de la tension de la capacité====
*Modification de la REM et ajout de l'asservissement
*Calcul des paramètres du correcteur
*Filtrage de la consigne pour éviter les overshoots
*Asservissement tout ou rien de la tension de la capacité

====Ajout du correcteur de courant====
*Choix du correcteur
*Calculs des paramètres
*Implémentation sous MATLAB
*Vérification des résultats

====Ajout du correcteur de vitesse====
*Choix du correcteur
*Calculs des paramètres
*Implémentation sous MATLAB
*Vérification des résultats

====Rapport de projet====
#Elaboration de la REM
*Expliquer l'élabortation de la REM
*Expliquer l'implémentation sous MATLAB
*Valider la simulation

===Réalisation du prototype réel===

====Réalisation d'un banc d'essai====
Réalisation d'un support pour le moteur
*Conception du support
*Impression 3D du support
*Amélioration du support pour fixation sur breadboard
Création d'un circuit de test et de mesure pour le moteur
*Test du circuit
*Trouver une solution pour mesurer le rendement
Contrôle du moteur avec un STM32
*Prise en main du driver nucleo
*Contrôle du moteur à l'aide de ce driver
*Prise en main du Nucléo F410RE pour contrôler le driver

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04_possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

[[Fichier:18P04reponseSinChargeMeca.png|vignette|center|800 px| Asservissement de la charge mécanique par retour d'état]]

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|800 px| Modèle 3D du support de moteur]]

==Semaine 11==
Cette semaine a débuté sur un premier problème de code. En effet, la génération de code se passe bien, mais la compilation pose problème. En effet, une erreur de compilation a lieu, le champ "SR" n'existe pas dans l'objet "NVIC", qui est un registre spécifique du micro-processeur. Ce qui est étrange, c'est que nous n'utilisons pas le registre "NVIC" dans notre programme. En fait, après quelques recherches, il s'avère que matlab réinitialise un bloc qui sert à la lecture de registre, et le remet par défaut en lecture du registre "NVIC". Pour régler le problème, il faut donc régler manuellement le registre et le remettre en "USART". Après cette manipulation, il n'y a plus d'erreur de compilation.

Ensuite, un travail a été fourni sur la modification du modèle 3D du support de moteur. Son design a été repensé pour être plus stable, donc une base plus large a été faite, et un système de fixation pour la Breadboard a été ajouté.

[[Fichier:18P04_Assemblagev11.png|vignette|center|800 px| Nouvelle version du support de moteur]]

==Semaine 12==

De nouveaux problèmes de génération de code sont apparus. En effet, lors de la génération de code nous avons le message : "Error: RT_MODEL record RTWSolverInfo not found". Après beaucoup de temps passé à chercher d'où venait cette erreur, il semble qu'elle survienne suite à la modification du nom du fichier .slx ouvert par Matlab. En effet, j'historise manuellement les différentes versions du .slx en les renommant avec la date du jour de la sauvegarde. Or, si on renomme un ancien fichier pour qu'il soit ouvert par Matlab, la génération de projet ne se fait plus correctement et ce genre d'erreur peut arriver. il faut donc supprimer tous les fichiers temporaires, fermer Matlab et relancer le tout. La génération de projet peut alors se faire correctement.

La suite du projet a été de modifier le programme ainsi que le câblage du prototype électronique pour l'adapter au STM32. Le code fait pour l'arduino a été implémenté sous Matlab, puis implanté dans le STM32 grâce à la génération de code. Le contrôle se fait maintenant par liaison série, et non plus par des actionneurs analogiques.

Enfin, des calculs importants on été réalisés. En effet, pour pouvoir conseiller l'entreprise sur le choix des moteurs, il a fallu déterminer la puissance nécessaire d'après leur cahier des charges. Le cahier des charges consiste en la définition de la dynamique à atteindre, soit une masse de 5g qui doit pouvoir réaliser un déplacement aller-retour sur 4cm à une fréquence de 20Hz.

A partir de cette description, nous pouvons déterminer la trajectoire idéale de la pièce, donc calculer sa vitesse et son accélération en fonction du temps. Ce qui nous permet de calculer facilement la puissance nécessaire à ce déplacement. On obtient donc facilement la puissance maximale développée par le moteur, ce qui nous guide pour son choix.

[[Fichier:18P04puissanceTemps.png|vignette|center|800 px| Puissance en fonction du temps, ici la charge (doigt) est pris en compte]]

==Semaine 13==

Cette semaine, suite à mon intégration au projet de GOTouchVR, de nouveaux objectifs m'ont été donnés. D'abord, ma première tâche a été de rechercher des moteurs adaptés, en plus des moteurs déjà proposés par mon tuteur. Au final, cinq références de moteurs différents on été étudiées.

Ensuite, j'ai travaillé à la création d'une documentation comparant les différents moteurs proposés par mon tuteur. Pour ce faire, mon travail s'est basé sur les données des constructeurs, qu'il a fallu compléter par les calculs. Enfin, il a fallu créer les courbes des moteurs, courbes qui permettent de définir les performances de ces moteurs.

Ces courbes devraient permettre de comparer les moteurs avec la charge qu'on va leur exiger. Il permettrons de choisir à la fois le bon moteur, mais aussi de trouver le ratio optimal pour le réducteur.

[[Fichier:18P04CourbesTGPP.png|vignette|center|800 px| Courbes caractéristiques d'un moteur, ici le TGPP avec un réducteur 1:26]]

==Semaine 14==
Cette semaine a servi à la mise en place des tests des moteurs. D'abord, il a fallu élaborer les tests à effectuer. Plusieurs familles de tests ont été définies. D'abord, les tests servent à identifier les paramètres réels des moteurs. Ensuite, les tests devront permettre de déterminer les performances pratiques des moteurs. Enfin, la dernière famille de test devra définir un modèle thermique des moteurs en notre possession.

Une feuille de calculs a été également créée, elle sert à fournir les paramètres des moteurs en fonction des mesures effecuées. Elle permet de vérifier facilement la fiabilité des données du constructeur.

Et enfin, un travail important a été fait sur la conception mécanique du banc-test. Ce travail a été effectué par un collègue, cependant il a demandé beaucoup de coordination pour qu'il permette d'effectuer tous les tests nécessaires.

[[Fichier:18P04doubleBancTest.jpg|vignette|center|800 px| Partie mécanique du banc-test]]
[[Fichier:18P04fullTestBench.jpg|vignette|center|800 px| Banc-test]]

==Semaine 15==
Cette dernière semaine de projet a permis de finaliser les mesures, et de comparer les résultats de la simulation avec les résultats réels. Ce qui nous permet d'arriver à la conclusion suivante : le système est viable, et permet de lisser totalement le courant, et protège bien la batterie. En effet, il n'y a plus de pics de courant au niveau de la batterie.

Cependant, son implémentation n'a pas encore été décidée pour le prototype final. En effet, si il permet une bonne gestion de la puissance, la supercapacité est relativement encombrante. De plus, son poids pourrait être une autre raison de ne pas l'implémenter malgré ses performances. La suite du projet, qui sera mon stage de fin d'études, nous permettra de choisir définitivement l'implémentation ou non de ce système.

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]
D

Fichier:18P04fullTestBench.jpg

2019-02-26T17:29:49Z

Thubert :

IMA5 2018/2019 P04

2019-02-26T17:29:40Z

Thubert : /* Semaine 14 */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
*<s>Définition du schéma électrique</s>
*<s>Création d'un visuel du schéma électrique</s>
*<s>Définition des équations du système</s>
*<s>Élaboration de la REM du système</s>
*<s>Création d'un visuel pour la REM</s>
*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
*<s>Choix éventuels de valeurs de composants</s>
*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
*Modification de la REM et ajout de l'asservissement
*<s>Calcul des paramètres du correcteur</s>
*<s>Filtrage de la consigne pour éviter les overshoots</s>
*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*Vérification des résultats

====Rapport de projet====
#Elaboration de la REM
*Expliquer l'élabortation de la REM
*Expliquer l'implémentation sous MATLAB
*Valider la simulation

===Réalisation du prototype réel===

====Réalisation d'un banc d'essai====
Réalisation d'un support pour le moteur
*Conception du support
*Impression 3D du support
*Amélioration du support pour fixation sur breadboard
Création d'un circuit de test et de mesure pour le moteur
*Test du circuit
*Trouver une solution pour mesurer le rendement
Contrôle du moteur avec un STM32
*Prise en main du driver nucleo
*Contrôle du moteur à l'aide de ce driver
*Prise en main du Nucléo F410RE pour contrôler le driver

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04_possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

[[Fichier:18P04reponseSinChargeMeca.png|vignette|center|800 px| Asservissement de la charge mécanique par retour d'état]]

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|800 px| Modèle 3D du support de moteur]]

==Semaine 11==
Cette semaine a débuté sur un premier problème de code. En effet, la génération de code se passe bien, mais la compilation pose problème. En effet, une erreur de compilation a lieu, le champ "SR" n'existe pas dans l'objet "NVIC", qui est un registre spécifique du micro-processeur. Ce qui est étrange, c'est que nous n'utilisons pas le registre "NVIC" dans notre programme. En fait, après quelques recherches, il s'avère que matlab réinitialise un bloc qui sert à la lecture de registre, et le remet par défaut en lecture du registre "NVIC". Pour régler le problème, il faut donc régler manuellement le registre et le remettre en "USART". Après cette manipulation, il n'y a plus d'erreur de compilation.

Ensuite, un travail a été fourni sur la modification du modèle 3D du support de moteur. Son design a été repensé pour être plus stable, donc une base plus large a été faite, et un système de fixation pour la Breadboard a été ajouté.

[[Fichier:18P04_Assemblagev11.png|vignette|center|800 px| Nouvelle version du support de moteur]]

==Semaine 12==

De nouveaux problèmes de génération de code sont apparus. En effet, lors de la génération de code nous avons le message : "Error: RT_MODEL record RTWSolverInfo not found". Après beaucoup de temps passé à chercher d'où venait cette erreur, il semble qu'elle survienne suite à la modification du nom du fichier .slx ouvert par Matlab. En effet, j'historise manuellement les différentes versions du .slx en les renommant avec la date du jour de la sauvegarde. Or, si on renomme un ancien fichier pour qu'il soit ouvert par Matlab, la génération de projet ne se fait plus correctement et ce genre d'erreur peut arriver. il faut donc supprimer tous les fichiers temporaires, fermer Matlab et relancer le tout. La génération de projet peut alors se faire correctement.

La suite du projet a été de modifier le programme ainsi que le câblage du prototype électronique pour l'adapter au STM32. Le code fait pour l'arduino a été implémenté sous Matlab, puis implanté dans le STM32 grâce à la génération de code. Le contrôle se fait maintenant par liaison série, et non plus par des actionneurs analogiques.

Enfin, des calculs importants on été réalisés. En effet, pour pouvoir conseiller l'entreprise sur le choix des moteurs, il a fallu déterminer la puissance nécessaire d'après leur cahier des charges. Le cahier des charges consiste en la définition de la dynamique à atteindre, soit une masse de 5g qui doit pouvoir réaliser un déplacement aller-retour sur 4cm à une fréquence de 20Hz.

A partir de cette description, nous pouvons déterminer la trajectoire idéale de la pièce, donc calculer sa vitesse et son accélération en fonction du temps. Ce qui nous permet de calculer facilement la puissance nécessaire à ce déplacement. On obtient donc facilement la puissance maximale développée par le moteur, ce qui nous guide pour son choix.

[[Fichier:18P04puissanceTemps.png|vignette|center|800 px| Puissance en fonction du temps, ici la charge (doigt) est pris en compte]]

==Semaine 13==

Cette semaine, suite à mon intégration au projet de GOTouchVR, de nouveaux objectifs m'ont été donnés. D'abord, ma première tâche a été de rechercher des moteurs adaptés, en plus des moteurs déjà proposés par mon tuteur. Au final, cinq références de moteurs différents on été étudiées.

Ensuite, j'ai travaillé à la création d'une documentation comparant les différents moteurs proposés par mon tuteur. Pour ce faire, mon travail s'est basé sur les données des constructeurs, qu'il a fallu compléter par les calculs. Enfin, il a fallu créer les courbes des moteurs, courbes qui permettent de définir les performances de ces moteurs.

Ces courbes devraient permettre de comparer les moteurs avec la charge qu'on va leur exiger. Il permettrons de choisir à la fois le bon moteur, mais aussi de trouver le ratio optimal pour le réducteur.

[[Fichier:18P04CourbesTGPP.png|vignette|center|800 px| Courbes caractéristiques d'un moteur, ici le TGPP avec un réducteur 1:26]]

==Semaine 14==
Cette semaine a servi à la mise en place des tests des moteurs. D'abord, il a fallu élaborer les tests à effectuer. Plusieurs familles de tests ont été définies. D'abord, les tests servent à identifier les paramètres réels des moteurs. Ensuite, les tests devront permettre de déterminer les performances pratiques des moteurs. Enfin, la dernière famille de test devra définir un modèle thermique des moteurs en notre possession.

Une feuille de calculs a été également créée, elle sert à fournir les paramètres des moteurs en fonction des mesures effecuées. Elle permet de vérifier facilement la fiabilité des données du constructeur.

Et enfin, un travail important a été fait sur la conception mécanique du banc-test. Ce travail a été effectué par un collègue, cependant il a demandé beaucoup de coordination pour qu'il permette d'effectuer tous les tests nécessaires.

[[Fichier:18P04doubleBancTest.jpg|vignette|center|800 px| Partie mécanique du banc-test]]
[[Fichier:18P04fullTestBench.jpg|vignette|center|800 px| Banc-test]]

==Semaine 15==
Cette dernière semaine de projet a permis de finaliser les mesures, et de comparer les résultats de la simulation avec les résultats réels. Ce qui nous permet d'arriver à la conclusion suivante : le système est viable, et permet de lisser totalement le courant, et protège bien la batterie. En effet, il n'y a plus de pics de courant au niveau de la batterie.

Cependant, son implémentation n'a pas encore été décidée pour le prototype final. En effet, si il permet une bonne gestion de la puissance, la supercapacité est relativement encombrante. De plus, son poids pourrait être une autre raison de ne pas l'implémenter malgré ses performances. La suite du projet, qui sera mon stage de fin d'études, nous permettra de choisir définitivement l'implémentation ou non de ce système.

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]
D

Fichier:18P04puissanceTemps.png

2019-02-26T17:27:38Z

Thubert :

Fichier:18P04doubleBancTest.jpg

2019-02-26T17:27:28Z

Thubert :

Fichier:18P04CourbesTGPP.png

2019-02-26T17:26:25Z

Thubert :

IMA5 2018/2019 P04

2019-02-26T17:25:58Z

Thubert : /* Semaine 14 */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
*<s>Définition du schéma électrique</s>
*<s>Création d'un visuel du schéma électrique</s>
*<s>Définition des équations du système</s>
*<s>Élaboration de la REM du système</s>
*<s>Création d'un visuel pour la REM</s>
*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
*<s>Choix éventuels de valeurs de composants</s>
*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
*Modification de la REM et ajout de l'asservissement
*<s>Calcul des paramètres du correcteur</s>
*<s>Filtrage de la consigne pour éviter les overshoots</s>
*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*Vérification des résultats

====Rapport de projet====
#Elaboration de la REM
*Expliquer l'élabortation de la REM
*Expliquer l'implémentation sous MATLAB
*Valider la simulation

===Réalisation du prototype réel===

====Réalisation d'un banc d'essai====
Réalisation d'un support pour le moteur
*Conception du support
*Impression 3D du support
*Amélioration du support pour fixation sur breadboard
Création d'un circuit de test et de mesure pour le moteur
*Test du circuit
*Trouver une solution pour mesurer le rendement
Contrôle du moteur avec un STM32
*Prise en main du driver nucleo
*Contrôle du moteur à l'aide de ce driver
*Prise en main du Nucléo F410RE pour contrôler le driver

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04_possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

[[Fichier:18P04reponseSinChargeMeca.png|vignette|center|800 px| Asservissement de la charge mécanique par retour d'état]]

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|800 px| Modèle 3D du support de moteur]]

==Semaine 11==
Cette semaine a débuté sur un premier problème de code. En effet, la génération de code se passe bien, mais la compilation pose problème. En effet, une erreur de compilation a lieu, le champ "SR" n'existe pas dans l'objet "NVIC", qui est un registre spécifique du micro-processeur. Ce qui est étrange, c'est que nous n'utilisons pas le registre "NVIC" dans notre programme. En fait, après quelques recherches, il s'avère que matlab réinitialise un bloc qui sert à la lecture de registre, et le remet par défaut en lecture du registre "NVIC". Pour régler le problème, il faut donc régler manuellement le registre et le remettre en "USART". Après cette manipulation, il n'y a plus d'erreur de compilation.

Ensuite, un travail a été fourni sur la modification du modèle 3D du support de moteur. Son design a été repensé pour être plus stable, donc une base plus large a été faite, et un système de fixation pour la Breadboard a été ajouté.

[[Fichier:18P04_Assemblagev11.png|vignette|center|800 px| Nouvelle version du support de moteur]]

==Semaine 12==

De nouveaux problèmes de génération de code sont apparus. En effet, lors de la génération de code nous avons le message : "Error: RT_MODEL record RTWSolverInfo not found". Après beaucoup de temps passé à chercher d'où venait cette erreur, il semble qu'elle survienne suite à la modification du nom du fichier .slx ouvert par Matlab. En effet, j'historise manuellement les différentes versions du .slx en les renommant avec la date du jour de la sauvegarde. Or, si on renomme un ancien fichier pour qu'il soit ouvert par Matlab, la génération de projet ne se fait plus correctement et ce genre d'erreur peut arriver. il faut donc supprimer tous les fichiers temporaires, fermer Matlab et relancer le tout. La génération de projet peut alors se faire correctement.

La suite du projet a été de modifier le programme ainsi que le câblage du prototype électronique pour l'adapter au STM32. Le code fait pour l'arduino a été implémenté sous Matlab, puis implanté dans le STM32 grâce à la génération de code. Le contrôle se fait maintenant par liaison série, et non plus par des actionneurs analogiques.

Enfin, des calculs importants on été réalisés. En effet, pour pouvoir conseiller l'entreprise sur le choix des moteurs, il a fallu déterminer la puissance nécessaire d'après leur cahier des charges. Le cahier des charges consiste en la définition de la dynamique à atteindre, soit une masse de 5g qui doit pouvoir réaliser un déplacement aller-retour sur 4cm à une fréquence de 20Hz.

A partir de cette description, nous pouvons déterminer la trajectoire idéale de la pièce, donc calculer sa vitesse et son accélération en fonction du temps. Ce qui nous permet de calculer facilement la puissance nécessaire à ce déplacement. On obtient donc facilement la puissance maximale développée par le moteur, ce qui nous guide pour son choix.

[[Fichier:18P04puissanceTemps.png|vignette|center|800 px| Puissance en fonction du temps, ici la charge (doigt) est pris en compte]]

==Semaine 13==

Cette semaine, suite à mon intégration au projet de GOTouchVR, de nouveaux objectifs m'ont été donnés. D'abord, ma première tâche a été de rechercher des moteurs adaptés, en plus des moteurs déjà proposés par mon tuteur. Au final, cinq références de moteurs différents on été étudiées.

Ensuite, j'ai travaillé à la création d'une documentation comparant les différents moteurs proposés par mon tuteur. Pour ce faire, mon travail s'est basé sur les données des constructeurs, qu'il a fallu compléter par les calculs. Enfin, il a fallu créer les courbes des moteurs, courbes qui permettent de définir les performances de ces moteurs.

Ces courbes devraient permettre de comparer les moteurs avec la charge qu'on va leur exiger. Il permettrons de choisir à la fois le bon moteur, mais aussi de trouver le ratio optimal pour le réducteur.

[[Fichier:18P04CourbesTGPP.png|vignette|center|800 px| Courbes caractéristiques d'un moteur, ici le TGPP avec un réducteur 1:26]]

==Semaine 14==
Cette semaine a servi à la mise en place des tests des moteurs. D'abord, il a fallu élaborer les tests à effectuer. Plusieurs familles de tests ont été définies. D'abord, les tests servent à identifier les paramètres réels des moteurs. Ensuite, les tests devront permettre de déterminer les performances pratiques des moteurs. Enfin, la dernière famille de test devra définir un modèle thermique des moteurs en notre possession.

Une feuille de calculs a été également créée, elle sert à fournir les paramètres des moteurs en fonction des mesures effecuées. Elle permet de vérifier facilement la fiabilité des données du constructeur.

Et enfin, un travail important a été fait sur la conception mécanique du banc-test. Ce travail a été effectué par un collègue, cependant il a demandé beaucoup de coordination pour qu'il permette d'effectuer tous les tests nécessaires.

[[Fichier:18P04doubleBancTest.jpg|vignette|center|800 px| Partie mécanique du banc-test]]

==Semaine 15==
Cette dernière semaine de projet a permis de finaliser les mesures, et de comparer les résultats de la simulation avec les résultats réels. Ce qui nous permet d'arriver à la conclusion suivante : le système est viable, et permet de lisser totalement le courant, et protège bien la batterie. En effet, il n'y a plus de pics de courant au niveau de la batterie.

Cependant, son implémentation n'a pas encore été décidée pour le prototype final. En effet, si il permet une bonne gestion de la puissance, la supercapacité est relativement encombrante. De plus, son poids pourrait être une autre raison de ne pas l'implémenter malgré ses performances. La suite du projet, qui sera mon stage de fin d'études, nous permettra de choisir définitivement l'implémentation ou non de ce système.

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]
D

IMA5 2018/2019 P04

2019-02-26T17:25:46Z

Thubert : /* Semaine 13 */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
*<s>Définition du schéma électrique</s>
*<s>Création d'un visuel du schéma électrique</s>
*<s>Définition des équations du système</s>
*<s>Élaboration de la REM du système</s>
*<s>Création d'un visuel pour la REM</s>
*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
*<s>Choix éventuels de valeurs de composants</s>
*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
*Modification de la REM et ajout de l'asservissement
*<s>Calcul des paramètres du correcteur</s>
*<s>Filtrage de la consigne pour éviter les overshoots</s>
*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*Vérification des résultats

====Rapport de projet====
#Elaboration de la REM
*Expliquer l'élabortation de la REM
*Expliquer l'implémentation sous MATLAB
*Valider la simulation

===Réalisation du prototype réel===

====Réalisation d'un banc d'essai====
Réalisation d'un support pour le moteur
*Conception du support
*Impression 3D du support
*Amélioration du support pour fixation sur breadboard
Création d'un circuit de test et de mesure pour le moteur
*Test du circuit
*Trouver une solution pour mesurer le rendement
Contrôle du moteur avec un STM32
*Prise en main du driver nucleo
*Contrôle du moteur à l'aide de ce driver
*Prise en main du Nucléo F410RE pour contrôler le driver

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04_possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

[[Fichier:18P04reponseSinChargeMeca.png|vignette|center|800 px| Asservissement de la charge mécanique par retour d'état]]

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|800 px| Modèle 3D du support de moteur]]

==Semaine 11==
Cette semaine a débuté sur un premier problème de code. En effet, la génération de code se passe bien, mais la compilation pose problème. En effet, une erreur de compilation a lieu, le champ "SR" n'existe pas dans l'objet "NVIC", qui est un registre spécifique du micro-processeur. Ce qui est étrange, c'est que nous n'utilisons pas le registre "NVIC" dans notre programme. En fait, après quelques recherches, il s'avère que matlab réinitialise un bloc qui sert à la lecture de registre, et le remet par défaut en lecture du registre "NVIC". Pour régler le problème, il faut donc régler manuellement le registre et le remettre en "USART". Après cette manipulation, il n'y a plus d'erreur de compilation.

Ensuite, un travail a été fourni sur la modification du modèle 3D du support de moteur. Son design a été repensé pour être plus stable, donc une base plus large a été faite, et un système de fixation pour la Breadboard a été ajouté.

[[Fichier:18P04_Assemblagev11.png|vignette|center|800 px| Nouvelle version du support de moteur]]

==Semaine 12==

De nouveaux problèmes de génération de code sont apparus. En effet, lors de la génération de code nous avons le message : "Error: RT_MODEL record RTWSolverInfo not found". Après beaucoup de temps passé à chercher d'où venait cette erreur, il semble qu'elle survienne suite à la modification du nom du fichier .slx ouvert par Matlab. En effet, j'historise manuellement les différentes versions du .slx en les renommant avec la date du jour de la sauvegarde. Or, si on renomme un ancien fichier pour qu'il soit ouvert par Matlab, la génération de projet ne se fait plus correctement et ce genre d'erreur peut arriver. il faut donc supprimer tous les fichiers temporaires, fermer Matlab et relancer le tout. La génération de projet peut alors se faire correctement.

La suite du projet a été de modifier le programme ainsi que le câblage du prototype électronique pour l'adapter au STM32. Le code fait pour l'arduino a été implémenté sous Matlab, puis implanté dans le STM32 grâce à la génération de code. Le contrôle se fait maintenant par liaison série, et non plus par des actionneurs analogiques.

Enfin, des calculs importants on été réalisés. En effet, pour pouvoir conseiller l'entreprise sur le choix des moteurs, il a fallu déterminer la puissance nécessaire d'après leur cahier des charges. Le cahier des charges consiste en la définition de la dynamique à atteindre, soit une masse de 5g qui doit pouvoir réaliser un déplacement aller-retour sur 4cm à une fréquence de 20Hz.

A partir de cette description, nous pouvons déterminer la trajectoire idéale de la pièce, donc calculer sa vitesse et son accélération en fonction du temps. Ce qui nous permet de calculer facilement la puissance nécessaire à ce déplacement. On obtient donc facilement la puissance maximale développée par le moteur, ce qui nous guide pour son choix.

[[Fichier:18P04puissanceTemps.png|vignette|center|800 px| Puissance en fonction du temps, ici la charge (doigt) est pris en compte]]

==Semaine 13==

Cette semaine, suite à mon intégration au projet de GOTouchVR, de nouveaux objectifs m'ont été donnés. D'abord, ma première tâche a été de rechercher des moteurs adaptés, en plus des moteurs déjà proposés par mon tuteur. Au final, cinq références de moteurs différents on été étudiées.

Ensuite, j'ai travaillé à la création d'une documentation comparant les différents moteurs proposés par mon tuteur. Pour ce faire, mon travail s'est basé sur les données des constructeurs, qu'il a fallu compléter par les calculs. Enfin, il a fallu créer les courbes des moteurs, courbes qui permettent de définir les performances de ces moteurs.

Ces courbes devraient permettre de comparer les moteurs avec la charge qu'on va leur exiger. Il permettrons de choisir à la fois le bon moteur, mais aussi de trouver le ratio optimal pour le réducteur.

[[Fichier:18P04CourbesTGPP.png|vignette|center|800 px| Courbes caractéristiques d'un moteur, ici le TGPP avec un réducteur 1:26]]

==Semaine 14==
Cette semaine a servi à la mise en place des tests des moteurs. D'abord, il a fallu élaborer les tests à effectuer. Plusieurs familles de tests ont été définies. D'abord, les tests servent à identifier les paramètres réels des moteurs. Ensuite, les tests devront permettre de déterminer les performances pratiques des moteurs. Enfin, la dernière famille de test devra définir un modèle thermique des moteurs en notre possession.

Une feuille de calculs a été également créée, elle sert à fournir les paramètres des moteurs en fonction des mesures effecuées. Elle permet de vérifier facilement la fiabilité des données du constructeur.

Et enfin, un travail important a été fait sur la conception mécanique du banc-test. Ce travail a été effectué par un collègue, cependant il a demandé beaucoup de coordination pour qu'il permette d'effectuer tous les tests nécessaires.

[[18P04doubleBancTest.jpg|vignette|center|800 px| Partie mécanique du banc-test]]

==Semaine 15==
Cette dernière semaine de projet a permis de finaliser les mesures, et de comparer les résultats de la simulation avec les résultats réels. Ce qui nous permet d'arriver à la conclusion suivante : le système est viable, et permet de lisser totalement le courant, et protège bien la batterie. En effet, il n'y a plus de pics de courant au niveau de la batterie.

Cependant, son implémentation n'a pas encore été décidée pour le prototype final. En effet, si il permet une bonne gestion de la puissance, la supercapacité est relativement encombrante. De plus, son poids pourrait être une autre raison de ne pas l'implémenter malgré ses performances. La suite du projet, qui sera mon stage de fin d'études, nous permettra de choisir définitivement l'implémentation ou non de ce système.

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]
D

IMA5 2018/2019 P04

2019-02-26T17:25:32Z

Thubert : /* Semaine 12 */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
*<s>Définition du schéma électrique</s>
*<s>Création d'un visuel du schéma électrique</s>
*<s>Définition des équations du système</s>
*<s>Élaboration de la REM du système</s>
*<s>Création d'un visuel pour la REM</s>
*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
*<s>Choix éventuels de valeurs de composants</s>
*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
*Modification de la REM et ajout de l'asservissement
*<s>Calcul des paramètres du correcteur</s>
*<s>Filtrage de la consigne pour éviter les overshoots</s>
*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*Vérification des résultats

====Rapport de projet====
#Elaboration de la REM
*Expliquer l'élabortation de la REM
*Expliquer l'implémentation sous MATLAB
*Valider la simulation

===Réalisation du prototype réel===

====Réalisation d'un banc d'essai====
Réalisation d'un support pour le moteur
*Conception du support
*Impression 3D du support
*Amélioration du support pour fixation sur breadboard
Création d'un circuit de test et de mesure pour le moteur
*Test du circuit
*Trouver une solution pour mesurer le rendement
Contrôle du moteur avec un STM32
*Prise en main du driver nucleo
*Contrôle du moteur à l'aide de ce driver
*Prise en main du Nucléo F410RE pour contrôler le driver

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04_possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

[[Fichier:18P04reponseSinChargeMeca.png|vignette|center|800 px| Asservissement de la charge mécanique par retour d'état]]

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|800 px| Modèle 3D du support de moteur]]

==Semaine 11==
Cette semaine a débuté sur un premier problème de code. En effet, la génération de code se passe bien, mais la compilation pose problème. En effet, une erreur de compilation a lieu, le champ "SR" n'existe pas dans l'objet "NVIC", qui est un registre spécifique du micro-processeur. Ce qui est étrange, c'est que nous n'utilisons pas le registre "NVIC" dans notre programme. En fait, après quelques recherches, il s'avère que matlab réinitialise un bloc qui sert à la lecture de registre, et le remet par défaut en lecture du registre "NVIC". Pour régler le problème, il faut donc régler manuellement le registre et le remettre en "USART". Après cette manipulation, il n'y a plus d'erreur de compilation.

Ensuite, un travail a été fourni sur la modification du modèle 3D du support de moteur. Son design a été repensé pour être plus stable, donc une base plus large a été faite, et un système de fixation pour la Breadboard a été ajouté.

[[Fichier:18P04_Assemblagev11.png|vignette|center|800 px| Nouvelle version du support de moteur]]

==Semaine 12==

De nouveaux problèmes de génération de code sont apparus. En effet, lors de la génération de code nous avons le message : "Error: RT_MODEL record RTWSolverInfo not found". Après beaucoup de temps passé à chercher d'où venait cette erreur, il semble qu'elle survienne suite à la modification du nom du fichier .slx ouvert par Matlab. En effet, j'historise manuellement les différentes versions du .slx en les renommant avec la date du jour de la sauvegarde. Or, si on renomme un ancien fichier pour qu'il soit ouvert par Matlab, la génération de projet ne se fait plus correctement et ce genre d'erreur peut arriver. il faut donc supprimer tous les fichiers temporaires, fermer Matlab et relancer le tout. La génération de projet peut alors se faire correctement.

La suite du projet a été de modifier le programme ainsi que le câblage du prototype électronique pour l'adapter au STM32. Le code fait pour l'arduino a été implémenté sous Matlab, puis implanté dans le STM32 grâce à la génération de code. Le contrôle se fait maintenant par liaison série, et non plus par des actionneurs analogiques.

Enfin, des calculs importants on été réalisés. En effet, pour pouvoir conseiller l'entreprise sur le choix des moteurs, il a fallu déterminer la puissance nécessaire d'après leur cahier des charges. Le cahier des charges consiste en la définition de la dynamique à atteindre, soit une masse de 5g qui doit pouvoir réaliser un déplacement aller-retour sur 4cm à une fréquence de 20Hz.

A partir de cette description, nous pouvons déterminer la trajectoire idéale de la pièce, donc calculer sa vitesse et son accélération en fonction du temps. Ce qui nous permet de calculer facilement la puissance nécessaire à ce déplacement. On obtient donc facilement la puissance maximale développée par le moteur, ce qui nous guide pour son choix.

[[Fichier:18P04puissanceTemps.png|vignette|center|800 px| Puissance en fonction du temps, ici la charge (doigt) est pris en compte]]

==Semaine 13==

Cette semaine, suite à mon intégration au projet de GOTouchVR, de nouveaux objectifs m'ont été donnés. D'abord, ma première tâche a été de rechercher des moteurs adaptés, en plus des moteurs déjà proposés par mon tuteur. Au final, cinq références de moteurs différents on été étudiées.

Ensuite, j'ai travaillé à la création d'une documentation comparant les différents moteurs proposés par mon tuteur. Pour ce faire, mon travail s'est basé sur les données des constructeurs, qu'il a fallu compléter par les calculs. Enfin, il a fallu créer les courbes des moteurs, courbes qui permettent de définir les performances de ces moteurs.

Ces courbes devraient permettre de comparer les moteurs avec la charge qu'on va leur exiger. Il permettrons de choisir à la fois le bon moteur, mais aussi de trouver le ratio optimal pour le réducteur.

[[18P04CourbesTGPP.png|vignette|center|800 px| Courbes caractéristiques d'un moteur, ici le TGPP avec un réducteur 1:26]]

==Semaine 14==
Cette semaine a servi à la mise en place des tests des moteurs. D'abord, il a fallu élaborer les tests à effectuer. Plusieurs familles de tests ont été définies. D'abord, les tests servent à identifier les paramètres réels des moteurs. Ensuite, les tests devront permettre de déterminer les performances pratiques des moteurs. Enfin, la dernière famille de test devra définir un modèle thermique des moteurs en notre possession.

Une feuille de calculs a été également créée, elle sert à fournir les paramètres des moteurs en fonction des mesures effecuées. Elle permet de vérifier facilement la fiabilité des données du constructeur.

Et enfin, un travail important a été fait sur la conception mécanique du banc-test. Ce travail a été effectué par un collègue, cependant il a demandé beaucoup de coordination pour qu'il permette d'effectuer tous les tests nécessaires.

[[18P04doubleBancTest.jpg|vignette|center|800 px| Partie mécanique du banc-test]]

==Semaine 15==
Cette dernière semaine de projet a permis de finaliser les mesures, et de comparer les résultats de la simulation avec les résultats réels. Ce qui nous permet d'arriver à la conclusion suivante : le système est viable, et permet de lisser totalement le courant, et protège bien la batterie. En effet, il n'y a plus de pics de courant au niveau de la batterie.

Cependant, son implémentation n'a pas encore été décidée pour le prototype final. En effet, si il permet une bonne gestion de la puissance, la supercapacité est relativement encombrante. De plus, son poids pourrait être une autre raison de ne pas l'implémenter malgré ses performances. La suite du projet, qui sera mon stage de fin d'études, nous permettra de choisir définitivement l'implémentation ou non de ce système.

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]
D

IMA5 2018/2019 P04

2019-02-26T17:25:09Z

Thubert : /* Semaine 11 */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
*<s>Définition du schéma électrique</s>
*<s>Création d'un visuel du schéma électrique</s>
*<s>Définition des équations du système</s>
*<s>Élaboration de la REM du système</s>
*<s>Création d'un visuel pour la REM</s>
*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
*<s>Choix éventuels de valeurs de composants</s>
*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
*Modification de la REM et ajout de l'asservissement
*<s>Calcul des paramètres du correcteur</s>
*<s>Filtrage de la consigne pour éviter les overshoots</s>
*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*Vérification des résultats

====Rapport de projet====
#Elaboration de la REM
*Expliquer l'élabortation de la REM
*Expliquer l'implémentation sous MATLAB
*Valider la simulation

===Réalisation du prototype réel===

====Réalisation d'un banc d'essai====
Réalisation d'un support pour le moteur
*Conception du support
*Impression 3D du support
*Amélioration du support pour fixation sur breadboard
Création d'un circuit de test et de mesure pour le moteur
*Test du circuit
*Trouver une solution pour mesurer le rendement
Contrôle du moteur avec un STM32
*Prise en main du driver nucleo
*Contrôle du moteur à l'aide de ce driver
*Prise en main du Nucléo F410RE pour contrôler le driver

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04_possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

[[Fichier:18P04reponseSinChargeMeca.png|vignette|center|800 px| Asservissement de la charge mécanique par retour d'état]]

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|800 px| Modèle 3D du support de moteur]]

==Semaine 11==
Cette semaine a débuté sur un premier problème de code. En effet, la génération de code se passe bien, mais la compilation pose problème. En effet, une erreur de compilation a lieu, le champ "SR" n'existe pas dans l'objet "NVIC", qui est un registre spécifique du micro-processeur. Ce qui est étrange, c'est que nous n'utilisons pas le registre "NVIC" dans notre programme. En fait, après quelques recherches, il s'avère que matlab réinitialise un bloc qui sert à la lecture de registre, et le remet par défaut en lecture du registre "NVIC". Pour régler le problème, il faut donc régler manuellement le registre et le remettre en "USART". Après cette manipulation, il n'y a plus d'erreur de compilation.

Ensuite, un travail a été fourni sur la modification du modèle 3D du support de moteur. Son design a été repensé pour être plus stable, donc une base plus large a été faite, et un système de fixation pour la Breadboard a été ajouté.

[[Fichier:18P04_Assemblagev11.png|vignette|center|800 px| Nouvelle version du support de moteur]]

==Semaine 12==

De nouveaux problèmes de génération de code sont apparus. En effet, lors de la génération de code nous avons le message : "Error: RT_MODEL record RTWSolverInfo not found". Après beaucoup de temps passé à chercher d'où venait cette erreur, il semble qu'elle survienne suite à la modification du nom du fichier .slx ouvert par Matlab. En effet, j'historise manuellement les différentes versions du .slx en les renommant avec la date du jour de la sauvegarde. Or, si on renomme un ancien fichier pour qu'il soit ouvert par Matlab, la génération de projet ne se fait plus correctement et ce genre d'erreur peut arriver. il faut donc supprimer tous les fichiers temporaires, fermer Matlab et relancer le tout. La génération de projet peut alors se faire correctement.

La suite du projet a été de modifier le programme ainsi que le câblage du prototype électronique pour l'adapter au STM32. Le code fait pour l'arduino a été implémenté sous Matlab, puis implanté dans le STM32 grâce à la génération de code. Le contrôle se fait maintenant par liaison série, et non plus par des actionneurs analogiques.

Enfin, des calculs importants on été réalisés. En effet, pour pouvoir conseiller l'entreprise sur le choix des moteurs, il a fallu déterminer la puissance nécessaire d'après leur cahier des charges. Le cahier des charges consiste en la définition de la dynamique à atteindre, soit une masse de 5g qui doit pouvoir réaliser un déplacement aller-retour sur 4cm à une fréquence de 20Hz.

A partir de cette description, nous pouvons déterminer la trajectoire idéale de la pièce, donc calculer sa vitesse et son accélération en fonction du temps. Ce qui nous permet de calculer facilement la puissance nécessaire à ce déplacement. On obtient donc facilement la puissance maximale développée par le moteur, ce qui nous guide pour son choix.

[[18P04puissanceTemps.png|vignette|center|800 px| Puissance en fonction du temps, ici la charge (doigt) est pris en compte]]

==Semaine 13==

Cette semaine, suite à mon intégration au projet de GOTouchVR, de nouveaux objectifs m'ont été donnés. D'abord, ma première tâche a été de rechercher des moteurs adaptés, en plus des moteurs déjà proposés par mon tuteur. Au final, cinq références de moteurs différents on été étudiées.

Ensuite, j'ai travaillé à la création d'une documentation comparant les différents moteurs proposés par mon tuteur. Pour ce faire, mon travail s'est basé sur les données des constructeurs, qu'il a fallu compléter par les calculs. Enfin, il a fallu créer les courbes des moteurs, courbes qui permettent de définir les performances de ces moteurs.

Ces courbes devraient permettre de comparer les moteurs avec la charge qu'on va leur exiger. Il permettrons de choisir à la fois le bon moteur, mais aussi de trouver le ratio optimal pour le réducteur.

[[18P04CourbesTGPP.png|vignette|center|800 px| Courbes caractéristiques d'un moteur, ici le TGPP avec un réducteur 1:26]]

==Semaine 14==
Cette semaine a servi à la mise en place des tests des moteurs. D'abord, il a fallu élaborer les tests à effectuer. Plusieurs familles de tests ont été définies. D'abord, les tests servent à identifier les paramètres réels des moteurs. Ensuite, les tests devront permettre de déterminer les performances pratiques des moteurs. Enfin, la dernière famille de test devra définir un modèle thermique des moteurs en notre possession.

Une feuille de calculs a été également créée, elle sert à fournir les paramètres des moteurs en fonction des mesures effecuées. Elle permet de vérifier facilement la fiabilité des données du constructeur.

Et enfin, un travail important a été fait sur la conception mécanique du banc-test. Ce travail a été effectué par un collègue, cependant il a demandé beaucoup de coordination pour qu'il permette d'effectuer tous les tests nécessaires.

[[18P04doubleBancTest.jpg|vignette|center|800 px| Partie mécanique du banc-test]]

==Semaine 15==
Cette dernière semaine de projet a permis de finaliser les mesures, et de comparer les résultats de la simulation avec les résultats réels. Ce qui nous permet d'arriver à la conclusion suivante : le système est viable, et permet de lisser totalement le courant, et protège bien la batterie. En effet, il n'y a plus de pics de courant au niveau de la batterie.

Cependant, son implémentation n'a pas encore été décidée pour le prototype final. En effet, si il permet une bonne gestion de la puissance, la supercapacité est relativement encombrante. De plus, son poids pourrait être une autre raison de ne pas l'implémenter malgré ses performances. La suite du projet, qui sera mon stage de fin d'études, nous permettra de choisir définitivement l'implémentation ou non de ce système.

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]
D

Fichier:18P04 Assemblagev11.png

2019-02-26T17:24:20Z

Thubert :

IMA5 2018/2019 P04

2019-02-26T17:23:25Z

Thubert :

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
*<s>Définition du schéma électrique</s>
*<s>Création d'un visuel du schéma électrique</s>
*<s>Définition des équations du système</s>
*<s>Élaboration de la REM du système</s>
*<s>Création d'un visuel pour la REM</s>
*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
*<s>Choix éventuels de valeurs de composants</s>
*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
*Modification de la REM et ajout de l'asservissement
*<s>Calcul des paramètres du correcteur</s>
*<s>Filtrage de la consigne pour éviter les overshoots</s>
*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*Vérification des résultats

====Rapport de projet====
#Elaboration de la REM
*Expliquer l'élabortation de la REM
*Expliquer l'implémentation sous MATLAB
*Valider la simulation

===Réalisation du prototype réel===

====Réalisation d'un banc d'essai====
Réalisation d'un support pour le moteur
*Conception du support
*Impression 3D du support
*Amélioration du support pour fixation sur breadboard
Création d'un circuit de test et de mesure pour le moteur
*Test du circuit
*Trouver une solution pour mesurer le rendement
Contrôle du moteur avec un STM32
*Prise en main du driver nucleo
*Contrôle du moteur à l'aide de ce driver
*Prise en main du Nucléo F410RE pour contrôler le driver

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04_possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

[[Fichier:18P04reponseSinChargeMeca.png|vignette|center|800 px| Asservissement de la charge mécanique par retour d'état]]

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|800 px| Modèle 3D du support de moteur]]

==Semaine 11==
Cette semaine a débuté sur un premier problème de code. En effet, la génération de code se passe bien, mais la compilation pose problème. En effet, une erreur de compilation a lieu, le champ "SR" n'existe pas dans l'objet "NVIC", qui est un registre spécifique du micro-processeur. Ce qui est étrange, c'est que nous n'utilisons pas le registre "NVIC" dans notre programme. En fait, après quelques recherches, il s'avère que matlab réinitialise un bloc qui sert à la lecture de registre, et le remet par défaut en lecture du registre "NVIC". Pour régler le problème, il faut donc régler manuellement le registre et le remettre en "USART". Après cette manipulation, il n'y a plus d'erreur de compilation.

Ensuite, un travail a été fourni sur la modification du modèle 3D du support de moteur. Son design a été repensé pour être plus stable, donc une base plus large a été faite, et un système de fixation pour la Breadboard a été ajouté.

[[Fichier:18P04_Assemblagev11.png|vignette|center|800 px| Nouvelle version du support de moteur]]

==Semaine 12==

De nouveaux problèmes de génération de code sont apparus. En effet, lors de la génération de code nous avons le message : "Error: RT_MODEL record RTWSolverInfo not found". Après beaucoup de temps passé à chercher d'où venait cette erreur, il semble qu'elle survienne suite à la modification du nom du fichier .slx ouvert par Matlab. En effet, j'historise manuellement les différentes versions du .slx en les renommant avec la date du jour de la sauvegarde. Or, si on renomme un ancien fichier pour qu'il soit ouvert par Matlab, la génération de projet ne se fait plus correctement et ce genre d'erreur peut arriver. il faut donc supprimer tous les fichiers temporaires, fermer Matlab et relancer le tout. La génération de projet peut alors se faire correctement.

La suite du projet a été de modifier le programme ainsi que le câblage du prototype électronique pour l'adapter au STM32. Le code fait pour l'arduino a été implémenté sous Matlab, puis implanté dans le STM32 grâce à la génération de code. Le contrôle se fait maintenant par liaison série, et non plus par des actionneurs analogiques.

Enfin, des calculs importants on été réalisés. En effet, pour pouvoir conseiller l'entreprise sur le choix des moteurs, il a fallu déterminer la puissance nécessaire d'après leur cahier des charges. Le cahier des charges consiste en la définition de la dynamique à atteindre, soit une masse de 5g qui doit pouvoir réaliser un déplacement aller-retour sur 4cm à une fréquence de 20Hz.

A partir de cette description, nous pouvons déterminer la trajectoire idéale de la pièce, donc calculer sa vitesse et son accélération en fonction du temps. Ce qui nous permet de calculer facilement la puissance nécessaire à ce déplacement. On obtient donc facilement la puissance maximale développée par le moteur, ce qui nous guide pour son choix.

[[18P04puissanceTemps.png|vignette|center|800 px| Puissance en fonction du temps, ici la charge (doigt) est pris en compte]]

==Semaine 13==

Cette semaine, suite à mon intégration au projet de GOTouchVR, de nouveaux objectifs m'ont été donnés. D'abord, ma première tâche a été de rechercher des moteurs adaptés, en plus des moteurs déjà proposés par mon tuteur. Au final, cinq références de moteurs différents on été étudiées.

Ensuite, j'ai travaillé à la création d'une documentation comparant les différents moteurs proposés par mon tuteur. Pour ce faire, mon travail s'est basé sur les données des constructeurs, qu'il a fallu compléter par les calculs. Enfin, il a fallu créer les courbes des moteurs, courbes qui permettent de définir les performances de ces moteurs.

Ces courbes devraient permettre de comparer les moteurs avec la charge qu'on va leur exiger. Il permettrons de choisir à la fois le bon moteur, mais aussi de trouver le ratio optimal pour le réducteur.

[[18P04CourbesTGPP.png|vignette|center|800 px| Courbes caractéristiques d'un moteur, ici le TGPP avec un réducteur 1:26]]

==Semaine 14==
Cette semaine a servi à la mise en place des tests des moteurs. D'abord, il a fallu élaborer les tests à effectuer. Plusieurs familles de tests ont été définies. D'abord, les tests servent à identifier les paramètres réels des moteurs. Ensuite, les tests devront permettre de déterminer les performances pratiques des moteurs. Enfin, la dernière famille de test devra définir un modèle thermique des moteurs en notre possession.

Une feuille de calculs a été également créée, elle sert à fournir les paramètres des moteurs en fonction des mesures effecuées. Elle permet de vérifier facilement la fiabilité des données du constructeur.

Et enfin, un travail important a été fait sur la conception mécanique du banc-test. Ce travail a été effectué par un collègue, cependant il a demandé beaucoup de coordination pour qu'il permette d'effectuer tous les tests nécessaires.

[[18P04doubleBancTest.jpg|vignette|center|800 px| Partie mécanique du banc-test]]

==Semaine 15==
Cette dernière semaine de projet a permis de finaliser les mesures, et de comparer les résultats de la simulation avec les résultats réels. Ce qui nous permet d'arriver à la conclusion suivante : le système est viable, et permet de lisser totalement le courant, et protège bien la batterie. En effet, il n'y a plus de pics de courant au niveau de la batterie.

Cependant, son implémentation n'a pas encore été décidée pour le prototype final. En effet, si il permet une bonne gestion de la puissance, la supercapacité est relativement encombrante. De plus, son poids pourrait être une autre raison de ne pas l'implémenter malgré ses performances. La suite du projet, qui sera mon stage de fin d'études, nous permettra de choisir définitivement l'implémentation ou non de ce système.

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]
D

Fichier:RapportFinal P04 ThomasHubert.pdf

2019-02-26T16:46:42Z

Thubert : Thubert a téléversé une nouvelle version de Fichier:RapportFinal P04 ThomasHubert.pdf

Fichier:RapportFinal P04 ThomasHubert.pdf

2019-02-26T16:20:15Z

Thubert : Thubert a téléversé une nouvelle version de Fichier:RapportFinal P04 ThomasHubert.pdf

Projets IMA5 2018/2019

2019-02-26T15:41:58Z

Thubert : /* Répartition des binômes */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en demandant une modification du format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

{| class="wikitable"
! Projet !! Elèves !! Encadrants école !! Rapport intermédiaire !! Rapport final !! Vidéo
|-
| P0 [[IMA5 2018/2019 P0|Modèle]]
|
|
|
|
|
|-
| P04 [[IMA5 2018/2019 P04|Conception mécatronique d'un gant haptique pour la réalité virtuelle]]
| Thomas Hubert
| Frédéric Giraud / Betty Semail
|[[Fichier:RapportIntermédiaire 2018P04.pdf]]
|[[Fichier:RapportFinal P04 ThomasHubert.pdf]]
|
|-
| P05 [[IMA5 2018/2019 P05|Simulation on the Web]]
| Rodolphe Toin
| Jérémie Dequidt
|[[Fichier:Rapport_intermediaire_P05.pdf]]
|
|
|-
| P06 [[IMA5 2018/2019 P06|Développement d'un système de gestion d'un réseau de capteurs]]
| Simon Feutrier / Antoine Duquenoy
| Thomas Vantroys / Alexandre Boé
|[[Fichier:PFE_06_Rapport_Intermediaire.pdf]]
|
|
|-
| P10 [[ IMA5 2018/2019 P10|Traces d’exécution de système temps réel]]
| Amine El Messaoudi
| Julien Forget
|[[Fichier:rapport1_P10.pdf]]
|
|
|-
| P13 [[ IMA5 2018/2019 P13|Réseau de capteurs pour parking intelligent]]
| Baptiste Cartier
| Alexandre Boé / Xavier Redon / Thomas Vantroys
|[[Fichier:RapportIntermédiaire.pdf]]
|
|
|-
| P16 [[IMA5 2018/2019 P16|Le Sportif Augmenté]]
| Matthieu Delobelle
| Alexandre Boé / Xavier Redon / Thomas Vantroys
|
|
|
|-
| P17 [[IMA5 2018/2019 P17|Système multisources de production d'hydrogène]]
| François-Xavier Cockenpot
| Anne-Lise Gehin
|
|[[fichier:Rapport_PFE17_Cockenpot.pdf]]
|
|-
| P21 [[IMA5 2018/2019 P21|Pilotage automatique d'un drone]]
| Claire Vandamme / Justine Senellart
| Aziz Nakrachi / Claudine Lecocq
|[[Fichier:Rapport de projet intermediaire P21 Pilotage automatique de drone.pdf]]
|
|
|-
| P22 [[IMA5 2018/2019 P22|Commande en position d'un drone]]
| Lijie YAO / Lirui ZHANG
| Komi Midzodzi PEKPE
|[[Fichier:Rapport_Intermédiaire_P22.pdf]]
|[[Fichier:Rapport_Final_P22.pdf]]
|
|-
| P26 [[IMA5 2018/2019 P26|Interaction 2D en réalité virtuelle]]
| Ji YANG
| Laurent Grisoni
| [[Fichier:Ji_YANG_PRE_Intermediaire.pdf]]
|[[Fichier:Rapport_final_26.pdf]]
|
|-
| P28 [[IMA5 2018/2019 P28|Clonage d'une calculatrice open-source NumWorks]]
| Alexis Dorian
| Xavier Redon / Alexandre Boé / Thomas Vantroys
|
| [[Fichier:Rapport PFE 28 Alexis DORIAN.pdf]]
|
|-
| P30 [[IMA5 2018/2019 P30|Contrôle à distance d'un robot de grande taille]]
| Delaporte Maëva / Blas Simon
| Xavier Redon / Thomas Vantroys / Alexandre Boé
|
|
|-
| P31 [[IMA5 2018/2019 P31|Supervision des serveurs de la plateforme informatique]]
| Taky Djeraba
| Xavier Redon / Thomas Vantroys
| [[Fichier:Rapport interm diaire PFE.pdf]]
|
|
|-
| P36 [[IMA5 2018/2019 P36|Pilotage automatique d'un drone]]
| Abass Ayoub / Alexis Viscogliosi
| Aziz Nakrachi / Claudine Lecocq
|[[Fichier:rapport_P36_Viscogliosi_Ayoub.pdf]]
|
|
|-
| P42 [[IMA5 2018/2019 P42 |Traçage d'empreintes de navigateur en utilisant des techniques avancées d'apprentissage automatique]]
| Mehanna Naif
| Walter Rudametkin / Romain Rouvoy
| [[Media:Rapport intermediaire de PFE.pdf|Rapport de mi-projet]]
|
|
|-
| P43 [[IMA5 2018/2019 P43 |Réalisation d'un synthétiseur]]
| Untereiner Antoine
| Alexandre Boé
| Rapport intermédiaire de PFE : [[Media:Rapport_AU.pdf|Rapport de mi-projet]]
|
|
|-
| P19 [[IMA5 2018/2019 P19 |Détection de menaces IOT sur FPGA]]
| MACHEREZ Alexis
| Alexandre Boé / Thomas Vantroys
|
|
|
|-
| P24 [[IMA5 2018/2019 P24 |Filtrage de Kalman pour la détection de défaut sur un robot mobile]]
| Samy Belhouachi
| Komi Midzodzi PEKPE
|
|
|-
| P44 [[IMA5 2018/2019 P44 |Iron Car]]
| DUFRESNE Erwan / ZALCZER Eloi
| Thomas Vantroys / Xavier Redon / Alexandre Boé
|
|-
| P18 [[IMA5 2018/2019 P18 | Emetteur / Récepteur analogique en bande FM ]]
| WATINE Jean-Baptiste
| Alexandre Boé
|
|
|}

== Matériel à acquérir ==

{| class="wikitable"
! Projet !! Matériel
|-
| P28 [[IMA5 2018/2019 P28|Clonage d'une calculatrice open-source NumWorks]]
|

[https://www.mouser.fr/ProductDetail/Adesto-Technologies/AT25SF641-SUB-T?qs=H7WEQPD31y1rOaelqGYUaQ== AT25SF641 ](Ram)

[https://www.mouser.fr/ProductDetail/STMicroelectronics/STM32F412VGT6?qs=qzCNEk%252bRr%252baGf9Ry5zWpvw%3D%3D&gclid=EAIaIQobChMI8OWLjsq63QIVxIjVCh0HCADGEAAYASAAEgKz5_D_BwE STM32F412VGT6 ] (microcontroleur)

[https://www.alibaba.com/product-detail/2-4-portait-LCD-module-ET024QV01_60727925701.html?spm=a2700.details.pronpeci14.2.5d9f12f4aeUQCE ET024QV01-K] (ecran)

[https://www.mouser.fr/ProductDetail/Newhaven-Display/NHD-24-240320CF-CTXI-F?qs=sGAEpiMZZMu%2fRY1bNe3bOwi7Ku0KTtuWVqK2peAZKeQH3KKyXLxcNw== NHD-2.4-240320CF] (autre ecran)

[https://fr.farnell.com/hirose-hrs/fh12s-40s-0-5sh-55/fiche-femelle-ffc-fpc-0-5mm-zif/dp/1324588?MER=sy-me-pd-mi-alte connecteur nappe]

[https://fr.farnell.com/richtek/rt9365gqw/driver-de-led-boost-250khz-wqfn/dp/2729821 RT9365GQW ](control retro éclairage)

[https://fr.farnell.com/richtek/rt9078-28gj5/regul-ldo-fixe-2-8v-0-3a-tsot/dp/2729807?krypto=MSyMhsZJSwpJzbmMaWZGoRn20imQ%2Bn8JeH7D4MHTZf%2B2dB6VsTHGLrm%2FOLrSWQ7xeojNK5JXTGImaV58n0tJ9A%3D%3D&ddkey=https%3Afr-FR%2FElement14_France%2Fsearch RT9078-28GJ5 ](régulateur de tension)

[https://fr.farnell.com/richtek/rt9526age/chargeur-bat-li-ion-0-5a-wdfn/dp/2433119?krypto=HIqdjNHqabMYeF39WOpX9xKeZ2JYmYKNIiZzSQh83hC6pdrzMzXqu1zU68gCpKyvU1HQLlLe%2FHV60YNgVaXvsg%3D%3D&ddkey=https%3Afr-FR%2FElement14_France%2Fsearch RT9526AGE ](chargeur lipo)

[https://fr.farnell.com/stmicroelectronics/usblc6-2sc6/esd-protection-smd-sot-23-6/dp/1269406?st=USBLC6-2SC6 USBLC6-2SC6 ] (protection USB)

[https://www.mouser.fr/ProductDetail/Lite-On/LTST-S310F2KT?qs=xb8aMrBSZRKYryAdlDhh3g== TST-S310F2KT] (led multi couleur)

[https://www.mouser.fr/ProductDetail/ECS/ECS-2520MV-250-BN-TR?qs=sGAEpiMZZMtldj7qu1ydrQG1afnrXLdGjWqvhZ7yquORJy%252b1U87asg%3d%3d Oscillateurs]

|-
| P16 [[IMA5 2018/2019 P16|Le Sportif Augmenté]]
|
*2 [https://www.digikey.com/product-detail/en/garmin-canada-inc/ANTAP281M5IB/1094-1004-ND/2748494 Module RF Ant+]
[https://www.digikey.com/product-detail/en/stmicroelectronics/STM32L031K6T7/497-16269-ND/5805501 MCU (Cortex M0) STM32-L0 (32-LQFP)]

[https://www.digikey.com/product-detail/en/stmicroelectronics/STM32L152CBT6/497-11197-ND/2640843 MCU (Cortex M3) STM32-L1 (64-LQFP)]
*4 [https://www.digikey.com/product-detail/en/yageo/CC0603CRNPO9BN4R3/311-3858-6-ND/8025870 Capacités 4,3 pF] (pour l'oscillateur 32k768 Hz)
*2 [https://www.digikey.com/product-detail/en/epson/FC-135-32.7680KA-A0/SER4077CT-ND/5604233 Oscillateur 32k768 Hz]

*4 [https://www.digikey.com/product-detail/en/kemet/C0603C180K5GACTU/399-7866-1-ND/3471589 Capacités 18 pF] (pour l'oscillateur 16 MHz)
*2 [https://www.digikey.com/product-detail/en/abracon-llc/ABLS-16.000MHZ-B4-T/535-10226-1-ND/2184261 Oscillateur 16MHz]

[https://www.digikey.com/product-detail/en/sparkfun-electronics/SEN-13944/1568-1424-ND/6193601 Capteur 9-DOF]

[https://www.digikey.com/product-detail/en/stmicroelectronics/NUCLEO-L031K6/497-16283-ND/5806780 Carte NUCLEO-L031]
[https://www.digikey.com/product-detail/en/stmicroelectronics/NUCLEO-L152RE/497-14363-ND/4695528 Carte NUCLEO-L152]

*6 [https://www.digikey.com/product-detail/en/rohm-semiconductor/SML-D12U1WT86/SML-D12U1WT86CT-ND/5843858 LED RED CMS]
*6 [https://www.digikey.com/product-detail/en/rohm-semiconductor/ESR03EZPJ131/RHM130DCT-ND/1762927 Resistances 130Ω (Pour LED)]

*15 [https://www.digikey.com/product-detail/en/samsung-electro-mechanics/CL10F104ZA8NNNC/1276-1011-1-ND/3889097 Capacités 100nF] (découplage/stabilité)
*6 [https://www.digikey.com/product-detail/en/rohm-semiconductor/ESR03EZPF1002/RHM10KADCT-ND/1983753 Resistances 10kΩ]
Les composants passifs permettant la mise en place de l'environnement des STM32 (resistances/capa) est deja en la possession de M. Redon (en 0603)
[https://www.mouser.fr/ProductDetail/Adesto-Technologies/AT25SF641-SUB-T?qs=H7WEQPD31y1rOaelqGYUaQ== AT25SF641 ](Ram)

|-
| P18 [[IMA5 2018/2019 P18|Emetteur récepteur bande FM]]
|

*2 [https://www.mouser.fr/ProductDetail/NXP-Semiconductors/SA612AD-01118?qs=sGAEpiMZZMv2G7q7wICjtfIJxBnl77S2%252b%252bZqLbCgGU0%3d mélangeurs]
*2 [https://www.mouser.fr/ProductDetail/NXP-Semiconductors/SA614AD-01118?qs=sGAEpiMZZMvKM5ialpXrmuXCYQ%252bnE0i4 système FM fi] (limiteur-détecteur de quadrature)
*1 [https://www.mouser.fr/ProductDetail/Molex/73366-0062?qs=sGAEpiMZZMuLQf%252bEuFsOrrXdJIKRuO8bR4ObDwYPMwJagDUqGGFvkA%3d%3d connecteur coaxial femelle]
*2 [https://www.mouser.fr/ProductDetail/ON-Semiconductor-Fairchild/BZX79C6V2?qs=sGAEpiMZZMvAvBNgSS9Lqlg9n3rYFLVD diodes zener]
*2 [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM317LIPK?qs=sGAEpiMZZMuTgk%252bQPI7Id6xN2vdLoIf2 régulateur de tension ] (alim 6V et 9V)
*4 [https://www.mouser.fr/ProductDetail/NXP-Semiconductors/BB202115?qs=me8TqzrmIYXTPBMElCe%252b3A%3D%3D diodes varicap BB202]
*3 [https://www.mouser.fr/ProductDetail/NXP-Semiconductors/BBY40215?qs=sGAEpiMZZMvKM5ialpXrmmojF8tXHUxP diodes varicap BBY40]
*2 [https://www.mouser.fr/ProductDetail/Central-Semiconductor/2N2219?qs=sGAEpiMZZMshyDBzk1%2fWiw99kSkYzPxmDv7Gy92BLz8%3d transistors 2N2219]
*2 [https://www.mouser.fr/ProductDetail/Infineon-Technologies/BFR-92P-E6327?qs=sGAEpiMZZMvDjfggS9kWsTVpFmAS0FC53nH33%2fxtfLg%3d transistors BFR92 ]
*2 [https://www.mouser.fr/ProductDetail/ON-Semiconductor-Fairchild/BC547B?qs=sGAEpiMZZMvAvBNgSS9LqhyF%2fsTQxMNe transistors BC547 ]
*1 [https://www.mouser.fr/ProductDetail/Texas-Instruments/TL081CP?qs=sGAEpiMZZMtCHixnSjNA6P3Ssczg4flJ1xPmD0j6Cko%3d ampli op TL081]
*3 [https://www.mouser.fr/ProductDetail/Murata-Electronics/SFECV10M7FA00-R0?qs=sGAEpiMZZMtMMXztyU6kdIFTJJQM3M6Q8oelu8IKNP4%3d filtres céramiques 10.7 MHz ]

*1 [https://www.mouser.fr/ProductDetail/Murata-Electronics/LQH32NH181J23L?qs=sGAEpiMZZMsg%252by3WlYCkU3ZhzMeKyJmpRKAif0Lp6Ck%3d inductance 180 µH] (quadrature tank)
*1 [https://www.mouser.fr/ProductDetail/Murata-Electronics/TZB4P400AA10R00?qs=sGAEpiMZZMukHu%252bjC5l7YV3%252btnLLlDRG39nrOadOFPc%3d condensateur ajustable ] (quadrature tank)

*2 [https://www.mouser.fr/ProductDetail/Murata-Electronics/TZC3P200A110R00?qs=sGAEpiMZZMukHu%252bjC5l7YZvVElVk%252bNfj93Is%2fuvc9Wg%3d condensateurs ajustables 5/20 pF] (filtre entrée + oscillateur réception)
*2 [https://www.mouser.fr/ProductDetail/Murata-Electronics/TZB4P300AA10B00?qs=sGAEpiMZZMukHu%252bjC5l7YTPfG1JP5wIeK%252bWvR6IL42U%3d condo ajustable 6.5 30 pF] ( oscillateur émission )

*1 [https://www.mouser.fr/ProductDetail/Texas-Instruments/LM386MX-1-NOPB?qs=sGAEpiMZZMvu8NZDyZ4K0W0q7hpC7Bhp amplificateur audio ]
*4 [https://www.mouser.fr/ProductDetail/Ohmite/OM1045E-R58?qs=sGAEpiMZZMtlubZbdhIBIJMLE6vvLglcKmQsvX788Ns%3d résistances 100k] (Commande d'accord)

*2 [https://www.mouser.fr/ProductDetail/TDK/VLS6045EX-470M-H?qs=sGAEpiMZZMsg%252by3WlYCkUwWVs%252bZAfRN3PTEA%2fTmKAE8%3d self 47µH] (alim émetteur)
*1 [https://www.mouser.fr/ProductDetail/ABRACON/AIML-0603-1R0K-T?qs=sGAEpiMZZMsg%252by3WlYCkUwX6XY3JXxzLWnI%2fwB2g2jA%3d self 1 µH] (oscillateur Clapp réception)
*1 [https://www.mouser.fr/ProductDetail/Sumida/RCH895NP-5R5M?qs=sGAEpiMZZMsg%252by3WlYCkUybotbHgb6KFVPPswvntSaM%3d self 5.5 µH] (alim SA612)
*1 [https://www.mouser.fr/ProductDetail/TDK/MLG1005SR15JTD25?qs=sGAEpiMZZMsg%252by3WlYCkU3b8Zei%252b1OAifaUcqd304aU%3d inductance 150 nH] (filtre entrée récepteur)
*3 [https://www.mouser.fr/ProductDetail/Yageo/CFR-25JR-52-47K?qs=sGAEpiMZZMtlubZbdhIBIFoOGUvNp40aRsKgdTuFP2M%3d 47 kohm]
*5 [https://www.mouser.fr/ProductDetail/Yageo/CFR-12JB-52-6K8?qs=sGAEpiMZZMtlubZbdhIBINt%2ft6Hry3%2fBikJxMgrSCuc%3d 6.8kohm]
*3 [https://www.mouser.fr/ProductDetail/Yageo/CFR-25JR-52-4K7?qs=sGAEpiMZZMtlubZbdhIBICXBKsnvdtuNQUT1efiei5o%3d 4.7kohm]
*2 [https://www.mouser.fr/ProductDetail/Ohmite/OM3315E-R58?qs=sGAEpiMZZMtlubZbdhIBIJMLE6vvLglc%252bDEGbeBtvHM%3d 330 ohm]
*4 [https://www.mouser.fr/ProductDetail/Yageo/CFR-25JR-52-10K?qs=sGAEpiMZZMtlubZbdhIBIFoOGUvNp40acurReI2X22I%3d 10kohm]
*3 [https://www.mouser.fr/ProductDetail/Yageo/CFR-12JB-52-3K3?qs=sGAEpiMZZMtlubZbdhIBINt%2ft6Hry3%2fBD0BUzHysOuw%3d 3.3 kohm]
*2 [https://www.mouser.fr/ProductDetail/Yageo/CFR-25JT-52-1K?qs=sGAEpiMZZMtlubZbdhIBIFoOGUvNp40ae7jvtA1AnXI%3d 1kohm]
*2 [https://www.mouser.fr/ProductDetail/Vishay-Beyschlag/MBB02070C4707JRP00?qs=sGAEpiMZZMtlubZbdhIBIP7908E9uONJCHSyGAzV3aU%3d 470 µOhm]
*1 [https://www.mouser.fr/ProductDetail/Yageo/CFR-50JB-52-51R?qs=sGAEpiMZZMtlubZbdhIBINt%2ft6Hry3%2fBC5eCORtsLAg%3d 51 ohm ]
*1 [https://www.mouser.fr/ProductDetail/Fastron/0603AS-R25G-01?qs=sGAEpiMZZMsg%252by3WlYCkU8BLlVcluYKELzEDw6f1yWg%3d inductance 250 nH] (filtre entrée, récepteur)
*2 [https://www.mouser.fr/ProductDetail/BI-Technologies-TT-Electronics/P160KNPD-4FC20B10K?qs=sGAEpiMZZMtC25l1F4XBUzVC3q8S9Qb8aPhpXWOj9iI%3d potentiomètres 10k] (excursion émetteur + volume ampli)
*1 [https://www.mouser.fr/ProductDetail/Vishay-BC-Components/A180J15C0GH5TAA?qs=sGAEpiMZZMt3KoXD5rJ2NzBWF85J6ZF%252b%252bo81cncSPEw%3d 18 pF]
*3 [https://www.mouser.fr/ProductDetail/AVX/SA102A6R8DAA?qs=sGAEpiMZZMt3KoXD5rJ2N5lIJeR4ZUrtmTB7BoqORwY%3d 6.8 pF]
*1 [https://www.mouser.fr/ProductDetail/KEMET/C410C109C5G5TA7200?qs=sGAEpiMZZMt3KoXD5rJ2NwtB0uHhSEq9vtyDsa3K98U%3d 1pF]
*2 [https://www.mouser.fr/ProductDetail/AVX/SA102A220JARN?qs=sGAEpiMZZMt3KoXD5rJ2N1kQx%252bJ8sD3bbV6dYyIiT%252b0%3d 22pF]
*1 [https://www.mouser.fr/ProductDetail/AVX/SA102A270KAA?qs=sGAEpiMZZMt3KoXD5rJ2N1kQx%252bJ8sD3b6VD4VJwASUQ%3d 27pF]
*1 [https://www.mouser.fr/ProductDetail/AVX/SA101C102KAN?qs=sGAEpiMZZMsh%252b1woXyUXj%2f3B4I5okv6zSvA2Ym6ziCg%3d 1nF]
*1 [https://www.mouser.fr/ProductDetail/AVX/SA102A300JAA?qs=sGAEpiMZZMt3KoXD5rJ2NzvLbS0KFQ%2f%252b5kaPDDiWAgo%3d 30pF]
*15 [https://www.mouser.fr/ProductDetail/AVX/SA105E104MAA?qs=sGAEpiMZZMsh%252b1woXyUXj3Nak6oU7yKrYCK71BDgMlE%3d 100 nF]
*1 [https://www.mouser.fr/ProductDetail/Vishay-BC-Components/A470J15C0GL5UAA?qs=sGAEpiMZZMsh%252b1woXyUXj8ONvsi0bWiaolBsRkHTcAM%3d 47 pF]
*1 [https://www.mouser.fr/ProductDetail/AVX/SA102C221MAR?qs=sGAEpiMZZMsh%252b1woXyUXjyfE4iDuOGSr53rCY4KakHw%3d 220 pF]
*1 [https://www.mouser.fr/ProductDetail/AVX/SA051A151KAA?qs=sGAEpiMZZMsh%252b1woXyUXj%2f3B4I5okv6zpkzVpPbcLiQ%3d 150 pF]
*1 [https://www.mouser.fr/ProductDetail/AVX/SA105E103MAA?qs=sGAEpiMZZMsh%252b1woXyUXj8uGuC5qkdnX1V0gW0DNeJo%3d 10 nF]
*3 [https://www.mouser.fr/ProductDetail/Illinois-Capacitor-CDE/106TTA035MSD?qs=sGAEpiMZZMsh%252b1woXyUXj2YUqcaON%252bY2ycv%252b%252bYI%252bzfg%3d 10µF]
*1 [https://www.mouser.fr/ProductDetail/Yageo/CFR-25JT-52-220K?qs=sGAEpiMZZMtlubZbdhIBIFoOGUvNp40aCABL0zhC45g%3d 220 kohms]
*1 [https://www.mouser.fr/ProductDetail/TDK/FG28C0G1H121JNT06?qs=sGAEpiMZZMsh%252b1woXyUXj6h8Z0XTvQqoywqalzoCCnY%3d 120 pF]

*1 [https://www.mouser.fr/ProductDetail/AVX/SA105C153KAC?qs=sGAEpiMZZMsh%252b1woXyUXjwY3RqoIrAVYKs8FxuMq1eg%3d 15 nF]
*1 [https://www.mouser.fr/ProductDetail/AVX/SA101A181KAC?qs=sGAEpiMZZMsh%252b1woXyUXj8OXp%252bRMDh2M0Hbc8eTr6IY%3d 180 pF]
*2 [https://www.mouser.fr/ProductDetail/Ohmite/ON9135E-R58?qs=sGAEpiMZZMtlubZbdhIBIDvWcNDqMrFVaJIsPx%252bAPc8%3d 91kohm]
*2 [https://www.mouser.fr/ProductDetail/Illinois-Capacitor-CDE/107TTA010M?qs=sGAEpiMZZMsh%252b1woXyUXj6tSaZI%252bOgx%2fNzJnlNxDV9c%3d 100 µF]
*1 [https://www.mouser.fr/ProductDetail/Illinois-Capacitor-CDE/108TTA010M?qs=sGAEpiMZZMsh%252b1woXyUXj6tSaZI%252bOgx%2fKpcwmoQX9XA%3d 1000 µF]

|-}

Fichier:RapportFinal P04 ThomasHubert.pdf

2019-02-26T15:41:02Z

Thubert :

IMA5 2018/2019 P04

2019-02-14T17:59:44Z

Thubert : /* Semaine 13 */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
*<s>Définition du schéma électrique</s>
*<s>Création d'un visuel du schéma électrique</s>
*<s>Définition des équations du système</s>
*<s>Élaboration de la REM du système</s>
*<s>Création d'un visuel pour la REM</s>
*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
*<s>Choix éventuels de valeurs de composants</s>
*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
*Modification de la REM et ajout de l'asservissement
*<s>Calcul des paramètres du correcteur</s>
*<s>Filtrage de la consigne pour éviter les overshoots</s>
*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*Vérification des résultats

====Rapport de projet====
#Elaboration de la REM
*Expliquer l'élabortation de la REM
*Expliquer l'implémentation sous MATLAB
*Valider la simulation

===Réalisation du prototype réel===

====Réalisation d'un banc d'essai====
Réalisation d'un support pour le moteur
*Conception du support
*Impression 3D du support
*Amélioration du support pour fixation sur breadboard
Création d'un circuit de test et de mesure pour le moteur
*Test du circuit
*Trouver une solution pour mesurer le rendement
Contrôle du moteur avec un STM32
*Prise en main du driver nucleo
*Contrôle du moteur à l'aide de ce driver
*Prise en main du Nucléo F410RE pour contrôler le driver

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04_possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

[[Fichier:18P04reponseSinChargeMeca.png|vignette|center|800 px| Asservissement de la charge mécanique par retour d'état]]

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|800 px| Modèle 3D du support de moteur]]

==Semaine 11==

Résolution d'un problème de génération de code

Modification du modèle 3D

Correction de la simulation

==Semaine 12==

Résolution définitive du PB de simulation

Modification du prototype pour fonctionner sous STM32

Calcul de la puissance max du moteur

==Semaine 13==

Recherche de moteurs potentiels

Completion des datasheet par le calcul

Rédaction d'un rapport comparatif des différents moteurs pour GotouchVR

==Semaine 14==

Mise en place des tests

Mise en place du banc-test

Création d'une feuille de calculs automatisée des paramètres

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]

IMA5 2018/2019 P04

2019-02-14T17:44:35Z

Thubert : /* Semaine 13 */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
*<s>Définition du schéma électrique</s>
*<s>Création d'un visuel du schéma électrique</s>
*<s>Définition des équations du système</s>
*<s>Élaboration de la REM du système</s>
*<s>Création d'un visuel pour la REM</s>
*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
*<s>Choix éventuels de valeurs de composants</s>
*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
*Modification de la REM et ajout de l'asservissement
*<s>Calcul des paramètres du correcteur</s>
*<s>Filtrage de la consigne pour éviter les overshoots</s>
*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*Vérification des résultats

====Rapport de projet====
#Elaboration de la REM
*Expliquer l'élabortation de la REM
*Expliquer l'implémentation sous MATLAB
*Valider la simulation

===Réalisation du prototype réel===

====Réalisation d'un banc d'essai====
Réalisation d'un support pour le moteur
*Conception du support
*Impression 3D du support
*Amélioration du support pour fixation sur breadboard
Création d'un circuit de test et de mesure pour le moteur
*Test du circuit
*Trouver une solution pour mesurer le rendement
Contrôle du moteur avec un STM32
*Prise en main du driver nucleo
*Contrôle du moteur à l'aide de ce driver
*Prise en main du Nucléo F410RE pour contrôler le driver

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04_possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

[[Fichier:18P04reponseSinChargeMeca.png|vignette|center|800 px| Asservissement de la charge mécanique par retour d'état]]

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|800 px| Modèle 3D du support de moteur]]

==Semaine 11==

Résolution d'un problème de génération de code

Modification du modèle 3D

Correction de la simulation

==Semaine 12==

Résolution définitive du PB de simulation

Modification du prototype pour fonctionner sous STM32

Calcul de la puissance max du moteur

==Semaine 13==

Recherche de moteurs potentiels

Comptetion des datasheet par le calcul

Rédaction d'un rapport comparatif des différents moteurs pour GotouchVR

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]

IMA5 2018/2019 P04

2019-01-29T10:52:07Z

Thubert : /* Semaine 5 */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
*<s>Définition du schéma électrique</s>
*<s>Création d'un visuel du schéma électrique</s>
*<s>Définition des équations du système</s>
*<s>Élaboration de la REM du système</s>
*<s>Création d'un visuel pour la REM</s>
*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
*<s>Choix éventuels de valeurs de composants</s>
*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
*Modification de la REM et ajout de l'asservissement
*<s>Calcul des paramètres du correcteur</s>
*<s>Filtrage de la consigne pour éviter les overshoots</s>
*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*Vérification des résultats

====Rapport de projet====
#Elaboration de la REM
*Expliquer l'élabortation de la REM
*Expliquer l'implémentation sous MATLAB
*Valider la simulation

===Réalisation du prototype réel===

====Réalisation d'un banc d'essai====
Réalisation d'un support pour le moteur
*Conception du support
*Impression 3D du support
*Amélioration du support pour fixation sur breadboard
Création d'un circuit de test et de mesure pour le moteur
*Test du circuit
*Trouver une solution pour mesurer le rendement
Contrôle du moteur avec un STM32
*Prise en main du driver nucleo
*Contrôle du moteur à l'aide de ce driver
*Prise en main du Nucléo F410RE pour contrôler le driver

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04_possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

[[Fichier:18P04reponseSinChargeMeca.png|vignette|center|800 px| Asservissement de la charge mécanique par retour d'état]]

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|800 px| Modèle 3D du support de moteur]]

==Semaine 11==

Résolution d'un problème de génération de code

Modification du modèle 3D

Correction de la simulation

==Semaine 12==

Résolution définitive du PB de simulation

Modification du prototype pour fonctionner sous STM32

Calcul de la puissance max du moteur

==Semaine 13==

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]

Fichier:18P04 possinus.png

2019-01-29T10:50:56Z

Thubert : Thubert a téléversé une nouvelle version de Fichier:18P04 possinus.png

IMA5 2018/2019 P04

2019-01-29T10:42:08Z

Thubert : /* Semaine 8 */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
*<s>Définition du schéma électrique</s>
*<s>Création d'un visuel du schéma électrique</s>
*<s>Définition des équations du système</s>
*<s>Élaboration de la REM du système</s>
*<s>Création d'un visuel pour la REM</s>
*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
*<s>Choix éventuels de valeurs de composants</s>
*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
*Modification de la REM et ajout de l'asservissement
*<s>Calcul des paramètres du correcteur</s>
*<s>Filtrage de la consigne pour éviter les overshoots</s>
*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*Vérification des résultats

====Rapport de projet====
#Elaboration de la REM
*Expliquer l'élabortation de la REM
*Expliquer l'implémentation sous MATLAB
*Valider la simulation

===Réalisation du prototype réel===

====Réalisation d'un banc d'essai====
Réalisation d'un support pour le moteur
*Conception du support
*Impression 3D du support
*Amélioration du support pour fixation sur breadboard
Création d'un circuit de test et de mesure pour le moteur
*Test du circuit
*Trouver une solution pour mesurer le rendement
Contrôle du moteur avec un STM32
*Prise en main du driver nucleo
*Contrôle du moteur à l'aide de ce driver
*Prise en main du Nucléo F410RE pour contrôler le driver

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04 possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

[[Fichier:18P04reponseSinChargeMeca.png|vignette|center|800 px| Asservissement de la charge mécanique par retour d'état]]

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|800 px| Modèle 3D du support de moteur]]

==Semaine 11==

Résolution d'un problème de génération de code

Modification du modèle 3D

Correction de la simulation

==Semaine 12==

Résolution définitive du PB de simulation

Modification du prototype pour fonctionner sous STM32

Calcul de la puissance max du moteur

==Semaine 13==

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]

Fichier:18P04reponseSinChargeMeca.png

2019-01-29T10:41:18Z

Thubert :

IMA5 2018/2019 P04

2019-01-29T10:11:31Z

Thubert : /* Semaine 6 */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
*<s>Définition du schéma électrique</s>
*<s>Création d'un visuel du schéma électrique</s>
*<s>Définition des équations du système</s>
*<s>Élaboration de la REM du système</s>
*<s>Création d'un visuel pour la REM</s>
*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
*<s>Choix éventuels de valeurs de composants</s>
*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
*Modification de la REM et ajout de l'asservissement
*<s>Calcul des paramètres du correcteur</s>
*<s>Filtrage de la consigne pour éviter les overshoots</s>
*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*Vérification des résultats

====Rapport de projet====
#Elaboration de la REM
*Expliquer l'élabortation de la REM
*Expliquer l'implémentation sous MATLAB
*Valider la simulation

===Réalisation du prototype réel===

====Réalisation d'un banc d'essai====
Réalisation d'un support pour le moteur
*Conception du support
*Impression 3D du support
*Amélioration du support pour fixation sur breadboard
Création d'un circuit de test et de mesure pour le moteur
*Test du circuit
*Trouver une solution pour mesurer le rendement
Contrôle du moteur avec un STM32
*Prise en main du driver nucleo
*Contrôle du moteur à l'aide de ce driver
*Prise en main du Nucléo F410RE pour contrôler le driver

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04 possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

TODO : consigne sinusoïdale avec charge mécanique

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|800 px| Modèle 3D du support de moteur]]

==Semaine 11==

Résolution d'un problème de génération de code

Modification du modèle 3D

Correction de la simulation

==Semaine 12==

Résolution définitive du PB de simulation

Modification du prototype pour fonctionner sous STM32

Calcul de la puissance max du moteur

==Semaine 13==

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]

IMA5 2018/2019 P04

2019-01-29T09:55:00Z

Thubert : /* Semaine 10 */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
*<s>Définition du schéma électrique</s>
*<s>Création d'un visuel du schéma électrique</s>
*<s>Définition des équations du système</s>
*<s>Élaboration de la REM du système</s>
*<s>Création d'un visuel pour la REM</s>
*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
*<s>Choix éventuels de valeurs de composants</s>
*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
*Modification de la REM et ajout de l'asservissement
*<s>Calcul des paramètres du correcteur</s>
*<s>Filtrage de la consigne pour éviter les overshoots</s>
*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*Vérification des résultats

====Rapport de projet====
#Elaboration de la REM
*Expliquer l'élabortation de la REM
*Expliquer l'implémentation sous MATLAB
*Valider la simulation

===Réalisation du prototype réel===

====Réalisation d'un banc d'essai====
Réalisation d'un support pour le moteur
*Conception du support
*Impression 3D du support
*Amélioration du support pour fixation sur breadboard
Création d'un circuit de test et de mesure pour le moteur
*Test du circuit
*Trouver une solution pour mesurer le rendement
Contrôle du moteur avec un STM32
*Prise en main du driver nucleo
*Contrôle du moteur à l'aide de ce driver
*Prise en main du Nucléo F410RE pour contrôler le driver

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04 possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

TODO : Insérer suivi de sinus et de steps

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

TODO : consigne sinusoïdale avec charge mécanique

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|800 px| Modèle 3D du support de moteur]]

==Semaine 11==

Résolution d'un problème de génération de code

Modification du modèle 3D

Correction de la simulation

==Semaine 12==

Résolution définitive du PB de simulation

Modification du prototype pour fonctionner sous STM32

Calcul de la puissance max du moteur

==Semaine 13==

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]

IMA5 2018/2019 P04

2019-01-25T15:03:51Z

Thubert : /* Liste des tâches à effectuer */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
*<s>Définition du schéma électrique</s>
*<s>Création d'un visuel du schéma électrique</s>
*<s>Définition des équations du système</s>
*<s>Élaboration de la REM du système</s>
*<s>Création d'un visuel pour la REM</s>
*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
*<s>Choix éventuels de valeurs de composants</s>
*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
*Modification de la REM et ajout de l'asservissement
*<s>Calcul des paramètres du correcteur</s>
*<s>Filtrage de la consigne pour éviter les overshoots</s>
*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
*<s>Choix du correcteur </s>
*<s>Calculs des paramètres </s>
*<s>Implémentation sous MATLAB</s>
*Vérification des résultats

====Rapport de projet====
#Elaboration de la REM
*Expliquer l'élabortation de la REM
*Expliquer l'implémentation sous MATLAB
*Valider la simulation

===Réalisation du prototype réel===

====Réalisation d'un banc d'essai====
Réalisation d'un support pour le moteur
*Conception du support
*Impression 3D du support
*Amélioration du support pour fixation sur breadboard
Création d'un circuit de test et de mesure pour le moteur
*Test du circuit
*Trouver une solution pour mesurer le rendement
Contrôle du moteur avec un STM32
*Prise en main du driver nucleo
*Contrôle du moteur à l'aide de ce driver
*Prise en main du Nucléo F410RE pour contrôler le driver

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04 possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

TODO : Insérer suivi de sinus et de steps

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

TODO : consigne sinusoïdale avec charge mécanique

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|800 px| Modèle 3D du support de moteur]]

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]

IMA5 2018/2019 P04

2019-01-25T15:01:06Z

Thubert : /* Rapport de projet */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
##*<s>Définition du schéma électrique</s>
##*<s>Création d'un visuel du schéma électrique</s>
##*<s>Définition des équations du système</s>
##*<s>Élaboration de la REM du système</s>
##*<s>Création d'un visuel pour la REM</s>
##*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
##*<s>Choix éventuels de valeurs de composants</s>
##*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
##*Modification de la REM et ajout de l'asservissement
##*<s>Calcul des paramètres du correcteur</s>
##*<s>Filtrage de la consigne pour éviter les overshoots</s>
##*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*Vérification des résultats

====Rapport de projet====
#Elaboration de la REM
#*Expliquer l'élabortation de la REM
#*Expliquer l'implémentation sous MATLAB
#*Valider la simulation

====Réalisation d'un banc d'essai====
###Réalisation d'un support pour le moteur
###*Conception du support
###*Impression 3D du support
###*Amélioration du support pour fixation sur breadboard
###Création d'un circuit de test et de mesure pour le moteur
###*Test du circuit
###*Trouver une solution pour mesurer le rendement
###Contrôle du moteur avec un STM32
###*Prise en main du driver nucleo
###*Contrôle du moteur à l'aide de ce driver
###*Prise en main du Nucléo F410RE pour contrôler le driver

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04 possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

TODO : Insérer suivi de sinus et de steps

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

TODO : consigne sinusoïdale avec charge mécanique

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|800 px| Modèle 3D du support de moteur]]

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]

IMA5 2018/2019 P04

2019-01-25T15:00:44Z

Thubert : /* Liste des tâches à effectuer */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
##*<s>Définition du schéma électrique</s>
##*<s>Création d'un visuel du schéma électrique</s>
##*<s>Définition des équations du système</s>
##*<s>Élaboration de la REM du système</s>
##*<s>Création d'un visuel pour la REM</s>
##*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
##*<s>Choix éventuels de valeurs de composants</s>
##*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
##*Modification de la REM et ajout de l'asservissement
##*<s>Calcul des paramètres du correcteur</s>
##*<s>Filtrage de la consigne pour éviter les overshoots</s>
##*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*Vérification des résultats

====Rapport de projet====
###Elaboration de la REM
###*Expliquer l'élabortation de la REM
###*Expliquer l'implémentation sous MATLAB
###*Valider la simulation

====Réalisation d'un banc d'essai====
###Réalisation d'un support pour le moteur
###*Conception du support
###*Impression 3D du support
###*Amélioration du support pour fixation sur breadboard
###Création d'un circuit de test et de mesure pour le moteur
###*Test du circuit
###*Trouver une solution pour mesurer le rendement
###Contrôle du moteur avec un STM32
###*Prise en main du driver nucleo
###*Contrôle du moteur à l'aide de ce driver
###*Prise en main du Nucléo F410RE pour contrôler le driver

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04 possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

TODO : Insérer suivi de sinus et de steps

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

TODO : consigne sinusoïdale avec charge mécanique

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|800 px| Modèle 3D du support de moteur]]

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]

IMA5 2018/2019 P04

2019-01-25T14:56:32Z

Thubert : /* Semaine 10 */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
##*<s>Définition du schéma électrique</s>
##*<s>Création d'un visuel du schéma électrique</s>
##*<s>Définition des équations du système</s>
##*<s>Élaboration de la REM du système</s>
##*<s>Création d'un visuel pour la REM</s>
##*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
##*<s>Choix éventuels de valeurs de composants</s>
##*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
##*Modification de la REM et ajout de l'asservissement
##*<s>Calcul des paramètres du correcteur</s>
##*<s>Filtrage de la consigne pour éviter les overshoots</s>
##*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*Vérification des résultats

====Rapport de projet====
###Elaboration de la REM
###*Expliquer l'élabortation de la REM
###*Expliquer l'implémentation sous MATLAB
###*Valider la simulation

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04 possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

TODO : Insérer suivi de sinus et de steps

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

TODO : consigne sinusoïdale avec charge mécanique

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|800 px| Modèle 3D du support de moteur]]

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]

IMA5 2018/2019 P04

2019-01-25T14:56:14Z

Thubert : /* Semaine 10 */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
##*<s>Définition du schéma électrique</s>
##*<s>Création d'un visuel du schéma électrique</s>
##*<s>Définition des équations du système</s>
##*<s>Élaboration de la REM du système</s>
##*<s>Création d'un visuel pour la REM</s>
##*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
##*<s>Choix éventuels de valeurs de composants</s>
##*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
##*Modification de la REM et ajout de l'asservissement
##*<s>Calcul des paramètres du correcteur</s>
##*<s>Filtrage de la consigne pour éviter les overshoots</s>
##*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*Vérification des résultats

====Rapport de projet====
###Elaboration de la REM
###*Expliquer l'élabortation de la REM
###*Expliquer l'implémentation sous MATLAB
###*Valider la simulation

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04 possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

TODO : Insérer suivi de sinus et de steps

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

TODO : consigne sinusoïdale avec charge mécanique

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

[[Fichier:18P04 Moteur et support.png|vignette|center|1000 px| Modèle 3D du support de moteur]]

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]

Fichier:18P04 Moteur et support.png

2019-01-25T14:55:03Z

Thubert :

IMA5 2018/2019 P04

2019-01-25T14:54:17Z

Thubert : /* Semaine 8 */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
##*<s>Définition du schéma électrique</s>
##*<s>Création d'un visuel du schéma électrique</s>
##*<s>Définition des équations du système</s>
##*<s>Élaboration de la REM du système</s>
##*<s>Création d'un visuel pour la REM</s>
##*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
##*<s>Choix éventuels de valeurs de composants</s>
##*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
##*Modification de la REM et ajout de l'asservissement
##*<s>Calcul des paramètres du correcteur</s>
##*<s>Filtrage de la consigne pour éviter les overshoots</s>
##*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*Vérification des résultats

====Rapport de projet====
###Elaboration de la REM
###*Expliquer l'élabortation de la REM
###*Expliquer l'implémentation sous MATLAB
###*Valider la simulation

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04 possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

TODO : Insérer suivi de sinus et de steps

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

[[Fichier:18P04_charge_mecanique.png|vignette|center|1000 px| Charge mécanique du système]]

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

[[Fichier:18P04 charge meca equivalente.png|vignette|center|800 px| Charge mécanique équivalente du système]]

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

TODO : consigne sinusoïdale avec charge mécanique

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

TODO : Image de la modélisation

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]

Fichier:18P04 charge meca equivalente.png

2019-01-25T14:53:39Z

Thubert :

Fichier:18P04 charge mecanique.png

2019-01-25T14:52:21Z

Thubert :

IMA5 2018/2019 P04

2019-01-25T14:22:08Z

Thubert : /* Description */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du VRtouch est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du VRtouch]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
##*<s>Définition du schéma électrique</s>
##*<s>Création d'un visuel du schéma électrique</s>
##*<s>Définition des équations du système</s>
##*<s>Élaboration de la REM du système</s>
##*<s>Création d'un visuel pour la REM</s>
##*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
##*<s>Choix éventuels de valeurs de composants</s>
##*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
##*Modification de la REM et ajout de l'asservissement
##*<s>Calcul des paramètres du correcteur</s>
##*<s>Filtrage de la consigne pour éviter les overshoots</s>
##*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*Vérification des résultats

====Rapport de projet====
###Elaboration de la REM
###*Expliquer l'élabortation de la REM
###*Expliquer l'implémentation sous MATLAB
###*Valider la simulation

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04 possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

TODO : Insérer suivi de sinus et de steps

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

TODO : Insérer shcéma de la mécanique du modèle

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

TODO : Photo schéma équivalent

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

TODO : consigne sinusoïdale avec charge mécanique

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

TODO : Image de la modélisation

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]

IMA5 2018/2019 P04

2019-01-25T14:20:18Z

Thubert : /* Semaine 5 */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du GotouchVR est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du GotouchVR]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
##*<s>Définition du schéma électrique</s>
##*<s>Création d'un visuel du schéma électrique</s>
##*<s>Définition des équations du système</s>
##*<s>Élaboration de la REM du système</s>
##*<s>Création d'un visuel pour la REM</s>
##*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
##*<s>Choix éventuels de valeurs de composants</s>
##*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
##*Modification de la REM et ajout de l'asservissement
##*<s>Calcul des paramètres du correcteur</s>
##*<s>Filtrage de la consigne pour éviter les overshoots</s>
##*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*Vérification des résultats

====Rapport de projet====
###Elaboration de la REM
###*Expliquer l'élabortation de la REM
###*Expliquer l'implémentation sous MATLAB
###*Valider la simulation

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

[[Fichier:18P04_SMC_Pos.png|vignette|center|1000 px| REM et SMC du système]]

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

[[Fichier:18P04 ReponseImpulsionellePosition.png|vignette|center|1000 px| Suivi de position du système]]

On peut voir que la position est correctement asservie, mais avec un transitoire assez violent. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

[[Fichier:18P04 possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

TODO : Insérer suivi de sinus et de steps

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

TODO : Insérer shcéma de la mécanique du modèle

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

TODO : Photo schéma équivalent

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

TODO : consigne sinusoïdale avec charge mécanique

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

TODO : Image de la modélisation

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]

Fichier:18P04 possinus.png

2019-01-25T14:18:48Z

Thubert :

Fichier:18P04 ReponseImpulsionellePosition.png

2019-01-25T14:15:06Z

Thubert :

Fichier:18P04 SMC Pos.png

2019-01-25T14:12:22Z

Thubert :

IMA5 2018/2019 P04

2019-01-10T19:20:56Z

Thubert :

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du GotouchVR est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du GotouchVR]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
##*<s>Définition du schéma électrique</s>
##*<s>Création d'un visuel du schéma électrique</s>
##*<s>Définition des équations du système</s>
##*<s>Élaboration de la REM du système</s>
##*<s>Création d'un visuel pour la REM</s>
##*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
##*<s>Choix éventuels de valeurs de composants</s>
##*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
##*Modification de la REM et ajout de l'asservissement
##*<s>Calcul des paramètres du correcteur</s>
##*<s>Filtrage de la consigne pour éviter les overshoots</s>
##*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*Vérification des résultats

====Rapport de projet====
###Elaboration de la REM
###*Expliquer l'élabortation de la REM
###*Expliquer l'implémentation sous MATLAB
###*Valider la simulation

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

 TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

TODO : Insérer image de la REM et SMC

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

TODO : Insérer image de suivi d'échelon

On peut voir que la postion est correctement asservie. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

TODO : suivi de sinusoïde

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

TODO : Insérer suivi de sinus et de steps

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

TODO : Insérer shcéma de la mécanique du modèle

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

TODO : Photo schéma équivalent

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

TODO : consigne sinusoïdale avec charge mécanique

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

TODO : Image de la modélisation

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]

IMA5 2018/2019 P04

2019-01-10T19:20:00Z

Thubert : /* Semaine 8 */

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du GotouchVR est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du GotouchVR]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
##*<s>Définition du schéma électrique</s>
##*<s>Création d'un visuel du schéma électrique</s>
##*<s>Définition des équations du système</s>
##*<s>Élaboration de la REM du système</s>
##*<s>Création d'un visuel pour la REM</s>
##*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
##*<s>Choix éventuels de valeurs de composants</s>
##*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
##*Modification de la REM et ajout de l'asservissement
##*<s>Calcul des paramètres du correcteur</s>
##*<s>Filtrage de la consigne pour éviter les overshoots</s>
##*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*Vérification des résultats

====Rapport de projet====
###Elaboration de la REM
###*Expliquer l'élabortation de la REM
###*Expliquer l'implémentation sous MATLAB
###*Valider la simulation

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

TODO : Insérer image de la REM et SMC

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

TODO : Insérer image de suivi d'échelon

On peut voir que la postion est correctement asservie. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

TODO : suivi de sinusoïde

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

TODO : Insérer suivi de sinus et de steps

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

TODO : Insérer shcéma de la mécanique du modèle

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

TODO : Photo schéma équivalent

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

TODO : consigne sinusoïdale avec charge mécanique

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

TODO : Image de la modélisation

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]

IMA5 2018/2019 P04

2019-01-10T19:19:37Z

Thubert :

__TOC__
 

=Présentation générale=

==Description==
Les casques de réalité virtuelle permettent une immersion visuelle de grande qualité. Mais il manque le retour tactile des objets que l'on touche virtuellement. Pour pallier ce problème, il existe des gants haptiques qui fournissent sur les doigts de l’utilisateur des stimulations tactiles physiques. Ces gants utilisent des moteurs, des capteurs, des convertisseurs, une batterie pour actionner des effecteurs qui viennent stimuler la pulpe du doigt. C’est un système embarqué sur la paume de la main. La conception nécessite une bonne gestion énergétique (grâce à des convertisseurs) et le dimensionnement optimal des composants du système (moteur/réducteur/…)

<center><include iframe src="https://www.youtube.com/embed/htBVmw7F_LY" width="640px" height="360px" frameborder="0" scrolling="yes"/></center>

Un prototype du GotouchVR est déjà réalisé, mais qui possède des défauts. En particulier une mauvaise gestion énergétique qui réduit très fortement la durée de vie de la batterie, et qui ne permet pas au système d'avoir une dynamique suffisante à l'application qu'il vise. Une étude a donc été réalisée par les chercheurs de l'IRCICA pour chercher les solutions possibles à ce problème
[[Fichier:18P04_gtvr.jpg|center|400 px|vignette|Vue du GotouchVR]]

L'objet de ce projet est d'abord de simuler le fonctionnement du système avec la modification proposée, pour pouvoir déterminer sa capacité à résoudre les problèmes évoqués, ensuite étudier et choisir des composants pour mettre en place cette solution, et enfin la fabrication d'un prototype réel.

==Objectifs==
Le travail se découpe en 3 parties :
# Réalisation d’un prototype virtuel, sous Matlab/Simulink
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

=Préparation du projet=
==Cahier des charges==
Le cahier des charges est défini en trois parties distinctes, correspondant aux trois parties du projet. Comme chaque partie dépend de la précédente, le cahier des charges va se préciser au fur et à mesure de l'avancée du projet.

# Réalisation d’un prototype virtuel sous Matlab/Simulink. Pour cela il faut :
#*Simuler chaque composant du système : hacheur, capacité, inductances, moteur...
#*Pour chaque composant, vérifier son modèle
#*Obtenir un modèle fiable du prototype
# Optimisation énergétique des éléments : estimation de la durée de vie de la batterie, choix des composants,
# Prototype réel : fabrication / réalisation d’un élément du gant (impression 3D , PCB, …)

==Choix techniques : matériel et logiciel==
==Liste des tâches à effectuer==
''Les tâches barrées sont celles qui sont déjà effectuées à ce jour''

===Réalisation du prototype virtuel===
====Création d'une simulation simplifiée de la partie électrique sous Matlab :====
##*<s>Définition du schéma électrique</s>
##*<s>Création d'un visuel du schéma électrique</s>
##*<s>Définition des équations du système</s>
##*<s>Élaboration de la REM du système</s>
##*<s>Création d'un visuel pour la REM</s>
##*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
##*<s>Choix éventuels de valeurs de composants</s>
##*Vérification du modèle du moteur

====Ajout de l'asservissement de la tension de la capacité====
##*Modification de la REM et ajout de l'asservissement
##*<s>Calcul des paramètres du correcteur</s>
##*<s>Filtrage de la consigne pour éviter les overshoots</s>
##*<s>Asservissement tout ou rien de la tension de la capacité</s>

====Ajout du correcteur de courant====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*<s>Vérification des résultats</s>

====Ajout du correcteur de vitesse====
##*<s>Choix du correcteur </s>
##*<s>Calculs des paramètres </s>
##*<s>Implémentation sous MATLAB</s>
##*Vérification des résultats

====Rapport de projet====
###Elaboration de la REM
###*Expliquer l'élabortation de la REM
###*Expliquer l'implémentation sous MATLAB
###*Valider la simulation

==Calendrier prévisionnel==
*Mi-Octobre 2018 : Simulation fonctionnelle
*Fin Novembre 2018 : Tests sur le système existant

=Réalisation du Projet=

==Semaine 0==
La première entrevue avec le tuteur a permis de poser les bases du projet.
Ont été définis les différents objectifs, la méthode et les rendez-vous concernant le projet.

Pour les objectifs, on a vu en particulier ceux concernant la première étape du projet, à savoir la modélisation du système.
*Dans un premier temps, il s'agit de mettre en place un modèle du système. On se base sur la REM de ce système.
*Nous avons ensuite modéliser la commande de ce système. En effet, le but est d'ajouter un LTC3125 qui doit permettre de garantir la limitation du courant. Ce composant est placé entre la batterie et la capacité, il sert à l'asservissement du courant issu de la batterie.

A l'issue de cette séance, nous avons un schéma fonctionnel simplifiant le système qui est établi et que nous allons devoir modéliser. [[Fichier:18P04_Schemafonc.png|vignette|800px|center|Schéma fonctionnel du système]]

==Semaine 1==
La première étape de notre projet est la définition des équations qui définissent notre système. Pour chaque composant de notre schéma électrique, nous trouvons son équation temporelle que nous transformons dans le domaine de Laplace. Puis nous les mettons en forme pour respecter les causalités. Ainsi nous obtenons des équations faciles à implémenter sous Simulink.

A partir de ces formules, nous pouvons définir une Représentation Énergétique Macroscopique (REM). L'avantage de cette représentation, c'est qu'elle décompose le système en blocs soit linéaires, soit avec le fonctionnement d'un premier ordre. de plus, ils nous donnent un bon aperçu des échanges énergétiques effectués au sein de notre système. Ce qui nous permet facilement de les simuler et de les contrôler par la suite.

[[Fichier:18P04 REM.png|vignette|center|1000 px| REM du système]]

Dans un premier temps, cette représentation ne comprends que le système sans sa partie commande. L'ajout de la partie commande sera fait par la suite.

On peut alors implémenter le système sous Matlab. Il faut alors vérifier la justesse du modèle, nous commencerons par la partie qui connecte la capacité et la batterie.

TODO : Rajout des vérifs du système

==Semaine 2==

La semaine passée, nous avions vérifié que notre simulation correstpondent aux valeurs de composants que nous lui avions donné. Cependant, les valeurs ne correspondaient pas à la réalité par manque d'informations. Elles ont été rectifiées pour mieux y correspondre.

Notre modèle est à présent vérifié dans sa partie Batterie-Capacité, et comprend les bonnes valeurs. Il va maintenant falloir émuler le LTC3125 pour la suite de notre projet. Ce composant est un convertisseur DC-DC avec possibilité de limiter le courant. Dans notre schéma structurel, il est représenté par une inductance et un hacheur élévateur. On commence par asservir le courant pour modéliser le limiteur de tension.

Notre but est d'asservir le courant de la batterie soit Icharge, à partir du hacheur, commandé par K1. Nous devons donc inverser tous les blocs entre les deux soit notre hacheur Hach1 et le stockeur d'énergie Lcharge. Pour ce stockeur d'énergie, nous utilisons un PID, dont nous calculons les paramètres par identification.

[[Fichier:18P04COR CUR.png|vignette|center|1000 px| REM du système avec ajout de l'asservissement du courant]]

On implémente alors notre correcteur sous Matlab-Simulink.

Du temps a également été consacré à la réalisation d'un schéma électrique pour le rapporta ainsi que le wiki. C'est le schéma présent en semaine 0 dans ce rapport.
Par la même occasion, un visuel de la REM a été fait pour illustrer la semaine 1.

==Semaine 3==
La semaine précédente, nous avons implémenté notre contrôleur sous Matlab. Nous avons choisi un PI dans notre cas, le PID réduit le temps de réponse, mais il induit un plus fort dépassement.

[[Fichier:18P04_PI.PNG|vignette|center|800 px| Vue du schéma-bloc sous Simulink]]

Nous allons maintenant calculer nos paramètres de PI. Pour ce faire, nous calculons la fonction de transfert en boucle fermée; nos calculent prennent en paramètres les constantes du PI. Une fois ces calculs effectués, nous calculons les paramètres de notre PI, en fonction des paramètres du système et des performances qu'on lui réclame.

Sous matlab, on entre directement les valeurs des paramètres du PI en fonction des paramètres du modèle, pour qu'ils se recalculent automatiquement si on modifie une valeur du modèle.

Une fois cela implémenté, on observe la réponse de notre système à une consigne.

[[Fichier:18P04 ReponseCourantNonAmorti.png|vignette|center|1000 px|Réponse à une consigne en courant]]

On voit que la réponse subit un dépassement de la consigne supérieur à 10%, alors que nous avons paramétré notre système pour qu'il n'y ait pas de dépassement, puisque notre but est de limiter les courants dans la batterie. Nous verrons par la suite si nous pouvons améliorer cet aspect.

Nous avons également modifié des paramètres moteurs , qui étaient erronés.

==Semaine 4==
Nous avions implémenté un correcteur pour asservir le courant dans la batterie. Mais nous avions encore un dépassement assez conséquent (>10%), alors que le LTC3125 n'en aura qu'un minime. Nous cherchons à réduire ce dépassement pour que notre simulation soit la plus exacte possible. Ce dépassement est dû au fait que le numérateur de notre fonction de transfert ne soit pas d'ordre zéro et qui induit donc un effet de dérivateur. Pour atténuer cet effet, nous allons filtrer la consigne en amont (Ce qui physiquement parlant a du sens puisque nous maîtrisons totalement notre consigne). Le résultat obtenu est pleinement satisfaisant.

[[Fichier:18P04_ReponseCourantAmorti.png|vignette|center|1000 px| Réponse du courant avec filtrage de la consigne]]

Nous avons également continué de compléter notre modèle. Pour ce faire nous avons rajouté un asservissement de la tension de la capacité. Le but de notre système est de maintenir notre capacité à la tension de 5V à l'aide d'un asservissement en tout ou rien. Nous avons donc fixé deux seuils de tensions, l'un haut pour arrêter la recharge de la capacité une fois qu'il est atteint, l'autre bas qui déclenche la recharge de la capacité si la tension tombe en deçà. Dans notre exemple, nous avons une charge qui débite un courant. Cette charge est totalement arbitraire et ne sert qu'à tester notre asservissement.

[[Fichier:18P04 TORCapa.png|vignette|center|1000 px| Asservissement de la tension en charge]]

==Semaine 5==

Pour cette semaine, nous avons commencé par la correction de la charge mécanique, qui jusque là avait des valeurs arbitraires. Nous lui avons donnés les valeurs de frottement et d'inertie du moteur. ainsi nous avons des valeurs qui ont un sens physiquement et qui nous permettent d'avoir une idée beaucoup plus précise du fonctionnement du système. pour cette partie mécanique, il restera à simuler le reste de la partie mécanique, à savoir le réducteur linéaire, le réducteur angulaire et la poutre qui entre en rotation.

La grosse partie du travail de cette semaine a été la mise en place de l'asservissement en position. Pour ce faire, nous devons d'abord asservir le courant moteur, ce qui nous permet de contrôler le couple appliqué sur le réducteur en sortie du moteur. On pourra ensuite ajouter une boucle d'asservissement en vitesse, ce qui nous permet de maîtriser la position.

TODO : Insérer image de la REM et SMC

Dans ce but, nous choisissons de mettre en place un régulateur PI. Pour le calcul des paramètres, nous procédons par placement de pôles. On calcule donc la fonction de transfert avec le correcteur, qui est une fonction de transfert de second ordre. On pose la fonction de transfert attendue sous la forme canonique, et on identifie ainsi les paramètres du correcteur. Une fois l'implémentation sous Matlab-Simulink réalisée, on obtient les résultats suivants pour une consigne en échelon :

TODO : Insérer image de suivi d'échelon

On peut voir que la postion est correctement asservie. Mais dans notre cas le suivi d'une consigne en échelon n'est pas très utile, on vérifie donc le comportement de la boucle fermée pour une consigne sinusoïdale.

TODO : suivi de sinusoïde

On voit que le système en boucle fermée ne suit pas la consigne sinusoïdale. En effet, une erreur en vitesse s'installe et nuit au suivit de la consigne de vitesse. On va donc devoir trouver une autre solution d'asservissement.

==Semaine 6==
Le correcteur de position implémenté la semaine passée est probélématique. En effet, on asservit la vitesse et non la position. Naïvement, on pourrait penser qu'il suffit de donner en consigne en vitesse la dérivée de la consigne en position, et laisser l'asservissement en vitesse donner les résultats. Cela fonctionne pour une consigne de type échelon, mais on a une erreur de vitesse qui apparaît si on fait suivre une rampe un un signal sinusoïdal.
On choisit donc d'abandonner le PI pour ce correcteur, pour passer à un correcteur à retour d'état. Ce correcteur permet d'asservir simultanément des variables physiques et d'autres représentations de ces variable, comme la vitesse et la position, qui sont deux manières de représenter une même variable physique.

On trouve donc les équations d'états, que l'on met ensuite sous forme matricielle. On ajoute ensuite une matrice contenant les coefficients correcteurs, et on calcule la fonction de transfert du système obtenu en boucle fermée. On peut alors identifier notre fonction de transfert la fonction de transfert idéale pour notre système, et en déduire les valeurs de la matrice de correction. On teste alors notre implémentation par le suivi d'une rampe, puis d'un sinus.

TODO : Insérer suivi de sinus et de steps

==Semaine 7==
On a vu la semaine passée les résultats de notre implémentation du retour d'état. On a pu constater que le système a l'air de fonctionner, mais les courants sont élevés pour un système à vide. On vérifie donc les paramètres de la simulation.

On s'aperçois donc que les paramètres qui décrivent le moteur sont erronnés, on les modifie donc pour obtenir des performances beaucoup plus réalistes à la suite de la modification. Par ailleurs, les paramètres des correcteurs sont directement calculés en fonction des paramètres du système dont ceux du moteur. On n'a pas eu à les recalculer manuellement.

Cette semaine a enfin servi à la rédaction du rapport. Ce rapport a été rédigé pour à la fois dans un but purement académique, mais il a aussi pour vocation de renseigner les différentes idées et les choix qui ont été fait durant ce projet.

==Semaine 8==

Nous avons poursuivi la modélisation du système par l'ajout de la partie mécanique.

L'intérêt de simuler la partie mécanique, c'est de pouvoir vérifier que notre système peut fonctionner selon la dynamique recherchée et dans les contraintes énergétiques données. On doit pour cela modéliser les échanges d'énergie de la batterie au doigt de l'utilisateur, ce qui nécéssite de prendre en compte sa mécanique.

Nous avons commencé par l'ajout des réducteurs et des inerties. Nous ne considérons que les frottements du moteur dans un premier temps. On réalise donc le schéma mécanique du système.

TODO : Insérer shcéma de la mécanique du modèle

Pour en réaliser la simultation, on retrouve des problèmes de causalité qui nous empêchent de réaliser simplement la REM du système. Un avantage non négligeable est le fait qu'avec cette équivalence, si on ramène les différentes inerties au niveau de celle du moteur, les paramètres sont très facilement calculables puisqu'il suffira alors de remplacer l'inertie du moteur par l'inertie équivalente du système.

On réalise donc un schéma équivalent du système, qui ramène les différentes inerties en un point unique. On obtient donc un schéma équivalent de notre système mécanique.

TODO : Photo schéma équivalent

On peut alors obtenir facilement les équations du système puis sa REM. On peut alors l'implémenter sous Matlab Simulink. On peut alors tester l'asservissement de ce nouveau système pour une consigne sinusoïdale.

TODO : consigne sinusoïdale avec charge mécanique

==Semaine 9==
Pour finir notre modélisation, nous voulons modéliser le doigt de l'utilisateur dans notre système. Si on suit le schéma mécanique, le doigt de l'utilisateur est en contact avec la poutre qui effectue la vibration. Pour modéliser le doigt, nous considérons qu'il impose une force résistante sur la poutre, qui dépend de son déplacement.

En d'autres termes, nous allons modéliser la force imposée par le doigt de l'utilisateur par un bloc qui génère une force dépendant de la position de la poutre. Nous l'ajoutons à la simulation, mais les calculs deviennent beaucoup plus long, sans que nous en ayons trouvé la raison. On choisit donc de laisser de côté la modélisation de la force du doigt, pour pouvoir continuer nos tests.

Par la même occasion, nous avons découvert la suite logicielle permettant la génération de code depuis Matlab, la compilation du code, et son envoi sur le micro-contrôleur. Nous utilisons donc STM32Cube pour générer un fichier de configuration de la carte à programmer, nous l'importons dans Matlab-simulink où nous créons le schéma à importer sur la carte. Nous générons ensuite le code C pour la carte, que nous compilons à l'aide du programme System Workbench for STM32. Le même logiciel nous permet également de téléverser le programme sur la carte.

On teste donc la chaîne de développement par un petit programme permettant de faire clignotter une led. On génère le code, compile et téléverse le tout sur la carte, la led clignote, le programme est fonctionnel.

==Semaine 10==

Cette semaine a d'abord été marquée par un problème récurrent à la génération de code. Lors de celle-ci, une erreur apparaît : "The code is successfully generated, but project generation have a problem". Et de cette erreur il découle l'impossibilité de compiler le code et de l'executer sur le Nucléo. Mais cette erreur a finalement pu être corrigée. En effet, elle est due à un problème dans le fichier de configuration de la carte électronique. En effet, le type de projet sélectionné n'était pas le bon, ce qui empêchait la génération de code de se faire.

En parallèlle de la recherche d'une solution à ce problème, un travail a été fait sur le driver de moteur qui doit être piloté par le Nucleo F401RE. On ne peut pas l'utiliser directement avec cette carte, cependant le driver est compatible avec les arduino Uno. Pour prendre en main de driver, nous avons connecté les deux, et essayé de contrôler le moteur de manière efficace. Nous avons donc pu mettre en place un premier banc d'essai pour bien comprendre cette carte. Après quelques heures de travail, nous arrivons à contrôler parfaitement le moteur. Ainsi, nous pourrons implémenter plus facilement le contrôle du moteur par la suite.

Nous avons également travaillé sur la réalisation d'un support physique pour notre banc d'essai. Nous avons modélisé sous Fusion360 un premier modèle de support pour notre moteur. Ce support doit permettre de maintenir le moteur de manière efficace, de maintenir une roue codeuse en vis-à-vis du moteur, et de maintenir la poutre à actionner. Pour l'instant, il n'y a que le moteur et son support qui sont modélisés.

TODO : Image de la modélisation

=Documents Rendus=
Rapport de mi-projet : [[Fichier:RapportIntermédiaire_2018P04.pdf]]

Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]

IMA5 2018/2019 P04

2018-12-19T07:33:06Z

Thubert : /* Documents Rendus */

IMA5 2018/2019 P04

2018-12-19T07:32:58Z

Thubert : /* Documents Rendus */

Fichier:2018P04 Soutenance de mi-projet.pdf

2018-12-19T07:32:14Z

Thubert :

IMA5 2018/2019 P04

2018-12-18T11:50:25Z

Thubert : /* Documents Rendus */

Projets IMA5 2018/2019

2018-12-18T11:42:56Z

Thubert : /* Répartition des binômes */

Fichier:RapportIntermédiaire 2018P04.pdf

2018-12-18T11:42:12Z

Thubert :

IMA5 2018/2019 P04

2018-12-14T10:45:33Z

Thubert : /* Semaine 5 */

IMA5 2018/2019 P04

2018-12-03T23:01:18Z

Thubert : /* Semaine 4 */

IMA5 2018/2019 P04

2018-12-02T23:48:00Z

Thubert : /* Semaine 4 */