Version actuelle datée du 26 février 2019 à 17:31

Sommaire

1 Présentation générale
- 1.1 Description
- 1.2 Objectifs
2 Préparation du projet
3 Réalisation du Projet
4 Documents Rendus

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/…)

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

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.

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.

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.

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.

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.

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.

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.

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.

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 :

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.

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.

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.

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.

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.

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é.

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.

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.

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.

Partie mécanique du banc-test

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

@@ Ligne 34 : / Ligne 34 : @@
 ==Choix techniques : matériel et logiciel==
-==Liste des tâches à effectuer==
+==Liste non exhaustive des tâches effectuée==
-''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>
+*Définition du schéma électrique
-*<s>Création d'un visuel du schéma électrique</s>
+*Création d'un visuel du schéma électrique
-*<s>Définition des équations du système</s>
+*Définition des équations du système
-*<s>Élaboration de la REM du système</s>
+*Élaboration de la REM du système
-*<s>Création d'un visuel pour la REM</s>
+*Création d'un visuel pour la REM
-*<s>Implémentation sous MATLAB de la REM et les équations du système</s>
+*Implémentation sous MATLAB de la REM et les équations du système
-*<s>Choix éventuels de valeurs de composants</s>
+*Choix éventuels de valeurs de composants
-*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>
+*Calcul des paramètres du correcteur
-*<s>Filtrage de la consigne pour éviter les overshoots</s>
+*Filtrage de la consigne pour éviter les overshoots
-*<s>Asservissement tout ou rien de la tension de la capacité</s>
+*Asservissement tout ou rien de la tension de la capacité
 ====Ajout du correcteur de courant====
-*<s>Choix du correcteur	    </s>
+*Choix du correcteur
-*<s>Calculs des paramètres    </s>
+*Calculs des paramètres
-*<s>Implémentation sous MATLAB</s>
+*Implémentation sous MATLAB
-*<s>Vérification des résultats</s>
+*Vérification des résultats
 ====Ajout du correcteur de vitesse====
-*<s>Choix du correcteur       </s>
+*Choix du correcteur
-*<s>Calculs des paramètres	 </s>
+*Calculs des paramètres
-*<s>Implémentation sous MATLAB</s>
+*Implémentation sous MATLAB
 *Vérification des résultats
@@ Ligne 179 : / Ligne 178 : @@
-[[Fichier:18P04 possinus.png|vignette|center|1000 px| Suivi de consigne sinusoïdale du système]]
+[[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.
@@ Ligne 215 : / Ligne 214 : @@
 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
+[[Fichier:18P04reponseSinChargeMeca.png|vignette|center|800 px| Asservissement de la charge mécanique par retour d'état]]
 ==Semaine 9==
@@ Ligne 241 : / Ligne 242 : @@
 ==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.
-Résolution d'un problème de génération de code
+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é.
-Modification du modèle 3D
+[[Fichier:18P04_Assemblagev11.png|vignette|center|800 px| Nouvelle version du support de moteur]]
-Correction de la simulation
+==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.
-==Semaine 12==
+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.
-Résolution définitive du PB de simulation
+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.
-Modification du prototype pour fonctionner sous STM32
+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.
-Calcul de la puissance max du moteur
+[[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=
@@ Ligne 263 : / Ligne 289 : @@
 Diapositive de mi-projet : [[Fichier:2018P04 Soutenance de mi-projet.pdf]]
+D

IMA5 2018/2019 P04 : Différence entre versions