P21 Projet bras déformable antagoniste
- Etudiant : Florian Giovannangeli
- Encadrants : Thor MORALES BIEZE & Mario SANZ-LOPEZ (INRIA Lille)
Sommaire
Cahier des charges
Présentation générale du Projet
Contexte
En robotique, la majorité des machines sont composées d’éléments mécaniques, avec des structures rigides. Le mouvement s’effectue grâce à un nombre fini d’actionneurs permettant d’agir à un endroit particulier avec un degré de liberté spécifique. Ils sont donc limités sur certaines capacités comme notamment s’adapter à leur environnement, se déformer pour franchir des obstacles, manier des objets fragiles sans les abîmer ou ne pas heurter le matériel et les individus environnants.
Constitués de matériaux souples capables de se déformer pour produire un mouvement, les robots déformables peuvent posséder un degré de liberté infini ce qui offre un grand nombre de possibilités comme celles sus-citées.
Les champs d’applications seraient bien plus vastes et les robots déformables pourraient être présents dans tous les aspects actuels de la robotique. Mais actuellement ces robots posent encore un certain nombre de défis scientifiques que la recherche doit relever.
Description
Le projet que j'ai choisi d'effectuer a été proposé par l'Institut National de Recherche en Informatique et Automatique (Inria) de Lille, et plus précisément au sein de l'équipe DEFROST (DEFormable RObot SofTware) qui s’intéresse à l’étude des robots déformables. Cette équipe de chercheurs s'intéressent à un certain nombre de défis posés par les robots déformables, notamment le contrôle, le design ou la fabrication de ceux-ci. Ils possèdent pour cela plusieurs prototypes ayant différents aspects, objectifs, fonctionnements et donc différentes contraintes. Le prototype sur lequel je vais travailler est celui d'un bras articulé surnommé BigMomma (Big Mou Manipulator), actionné par câbles et cavités pneumatiques. Il est inspiré de différents modèles existants, mais est plus de dix fois plus grand que ceux-ci ce qui posent de nouveaux enjeux et de nouvelles problématiques.
Objectif
L'objectif global est d'améliorer le modèle actuel du corps du robot, et de mettre en place l'intégralité du système de contrôle pneumatique développé, ainsi que les moyens d'actionnement des câbles, à travers de la conception de cartes PCB en forme des modules. Également, il sera nécessaire de mettre en place un système embarqué de contrôle et pilotage des actionneurs, avec le développement du code pour la communication. La conception de certaines parties du robot et la planification du système d'actionnement est faite à l'aide du simulateur SOFA, notamment concernant le passage des câbles à travers la structure. La prise en main du logiciel étant trop longue, elle n'entrera pas dans les objectifs du projet, mais une étude pourra être réalisée pour une conception ultérieure.
Tâches à réaliser
- Etudes préalables
- les robots déformables
- le robot, son fonctionnement et son but
- travaux réalisés, état actuel du projet
- Carte de contrôle pneumatique
- recherche de solution d'amélioration
- choix des composants
- réalisation du schématique et PCB
- tests et optimisation
- Programme de contrôle pneumatique
- recherche de solutions d'amélioration
- implémentation
- tests et optimisation
Avancement du Projet
Phase préparatoire
18/09/17 - 22/09/17
- Rendez-vous de présentation du projet avec les encadrants/intervenants (M. MORALES BIEZE Thor et M. SANZ-LOPEZ Mario)
- Elaboration du cahier des charges
- Elaboration de la page Wiki (préparation de la mise en page et présentation du sujet)
Semaine 1
25/09/17 - 29/09/17
- Revue du Cahier des Charges avec les encadrants
- Etude des documents mis à disposition sur l'état du projet
Semaine 2
02/10/17 - 06/10/17
- Précisions sur le cahier des charges
- Etude de l'état du robot (électronique, programmes et données mesurées)
- Recherche de solutions d'amélioration pour la carte de contrôle pneumatique
Semaine 3
09/10/17 - 13/10/17
- Réalisation de programmes de tests
- Choix des composants
- Réalisation des schématiques et du PCB de la carte de contrôle
Semaine 4
16/10/17 - 20/10/17
- Réalisation des tests sur Arduino Uno
- Choix des composants
- Réalisation des schématiques de la carte de contrôle
Semaine 5
23/10/17 - 27/10/17
- Commande des composants
- Réalisation du PCB de la carte de contrôle
Semaine 6
06/11/17 - 10/11/17
- Commande des composants (retard)
- Réalisation du PCB de la carte de contrôle
Semaine 7
13/11/17 - 17/11/17
- Commande des composants (retard)
- Corrections sur le PCB de la carte de contrôle et demande d'impression
- Analyse du programme de contrôle
Semaine 8
20/11/17 - 24/11/17
- Réception et vérification des composants (24/11)
- Impression du PCB en cours
- Analyse du programme de contrôle et recherche d'améliorations
Semaine 9
27/11/17 - 01/12/17
- Câblage de la carte de contrôle pneumatique
- Analyse du contrôle de la pompe à vide et recherche d'améliorations
- Début de réalisation des schématiques pour la pompe à vide
Semaine 10
04/12/17 - 08/12/17
- Tests de la carte de contrôle pneumatique
- Modification du schématique et PCB de la carte de contrôle pneumatique
- Réalisation du schématique et PCB de la carte pour la pompe à vide
Semaine 11
11/12/17 - 15/12/17
- Tests de filtres pour le contrôle pneumatique
- Correction manuelle de la carte de contrôle pneumatique
- Nouveaux tests de la carte de contrôle pneumatique
- Commande de deux nouveaux circuits imprimés (contrôle pneumatique et pompe à vide)
Semaine 12
18/12/17 - 22/12/17
- Réception et câblage des deux nouveaux circuits imprimés
- Tests de la carte de contrôle pneumatique
- Réalisation du rapport et du support de soutenance de mi-parcours
Semaine 13
08/01/18 - 12/01/18
- Réunion de mise au point du travail restant avec les encadrants
- Tests des cartes de contrôle pneumatique et de la pompe à vide sur le robot
- Etude du programme de contrôle et ciblage des modifications à effectuer
Semaine 14
15/01/18 - 19/01/18
- Tests des cartes de contrôle pneumatique et de la pompe à vide sur le robot
- Calibrage des capteurs et modification du code pour leur contrôle
Semaine 15
22/01/18 - 26/01/18
- Premiers tests sur robot réel
- Calibrage du PID
Semaine 16
29/01/18 - 02/02/18
- Calibrage du PID
- Récolte et stockage de données pour une réutilisation future
- Réalisation de la documentation
- Réalisation du rapport et support de soutenance
Présentation du travail effectué
1 - Amélioration du système de contrôle pneumatique
Système actuel
Le système de contrôle pneumatique a été défini et réalisé par de précédentes recherches sur le sujet. Néanmoins, des pistes d'amélioration sont encore à trouver et le premier prototype de carte de contrôle a été réalisé à la main. Le premier travail à réaliser est donc d'étudier le système actuel, de dépouiller les données mesurées sur celui-ci et de proposer des améliorations afin d'accroître la performance du contrôle pneumatique.
Le système actuel qui a été défini est celui-ci :
La première sortie de l'Arduino correspond au signal PWM de contrôle de la valve. Il est suivi d'un filtre permettant d'avoir un signal analogique, qui est ensuite amplifié à l'aide d'un montage en amplificateur non-inverseur afin d'avoir les bonnes tensions de commande de la valve (0-10V).
La valve envoie en retour les valeurs mesurées de pression qu'elle a fourni au robot. Ce signal passe par un diviseur de tension et un filtre de façon à fournir un signal lisible et interprêtable par l'Arduino.
Enfin, l'Arduino contrôle un système d'interrupteur composé de 2 MOSFET en parallèle pour connecter ou déconnecter la valve pneumatique en fonction des besoins.
Les données mesurées sur ce système montrent qu'il y a néanmoins des possibilités d'amélioration, notamment au niveau de la propreté et la précision des signaux échangés ainsi que de la rapidité d'exécution.
Amplificateur opérationnel
Les premières perspectives d'amélioration se sont portées sur l'amplificateur opérationel. J'ai effectué plusieurs recherches afin de vérifier que celui utilisé (LM324N) était le mieux adapté à l'application voulue. Il s'est avéré qu'il était difficile de trouver un meilleur AOP. En effet, le circuit demande tout d'abord une alimentation assez importante (24V) ce qui restreint le choix des AOP qui demandent généralement moins (~5-10V). L'utilisation d'un régulateur pourrait être envisagée, mais dans notre cas ce n'était pas pertinant. Un aspect important du régulateur est sa tension de sortie à l'état bas. L'objectif est d'avoir la valeur la plus proche de 0 possible pour envoyer les commandes à la valve (celle-ci attend du 0-10V). Dans notre cas, le composant utilisé est de type rail-to-rail et cette valeur est de 5 à 10mV ce qui est suffisamment proche. Enfin, il est nécessaire d'avoir 4 AOP pour contrôler, à terme, les 4 cavités du robot. Les recherches effectuées n'ont donc pas permis de trouver un meilleur composant pour nos attentes, ou en tous cas pas suffisamment pour envisager un changement peu utile.
Filtres et programmes de tests
D'autres perspectives d'amélioration se sont ensuite portées sur les filtres d'entrée et de sortie. Ceux-ci n'étaient pas optimum et pouvaient être améliorés afin d'avoir des signaux plus propres et donc plus de précision. Afin d'avoir une idée du meilleur filtre à utiliser pour le circuit, j'ai dû me lancer dans la réalisation d'un code de test pour simuler les signaux de commande PWM et de retour de la valve pneumatique. Ces signaux seront générés par un Arduino Uno et on pourra donc, à l'aide d'un oscilloscope, visualiser le contenu harmonique et déterminer le filtre le mieux adapté.
Le programme ainsi réalisé crée un signal PWM qui effectue un balayage sur une certaine gamme de fréquence. On utilise pour cela le Timer1 de l'Arduino UNO qui permet plusieurs modes de PWM (Fast, Phase Correct, Phase and Frequency Correct...). Dans un premier temps nous utilisons le Phase Correct PWM Mode qui est suffisant pour notre application. Initialement, le balayage se fait entre 20 et 30kHz, mais l'utilisateur peut utiliser la console de l'IDE Arduino pour modifier la valeur des registres OCR1A et OCR1B de façon à modifier la gamme de fréquence du balayage et ainsi observer la réaction du filtre.
Le programme de tests a fonctionné correctement, en revanche il a été impossible d'exploiter le résultat et la réaction du filtre car la carte avait des défauts. En effet, il s'est avéré qu'il y avait des faux contacts et même certaines pistes involontairement reliées, ce qui risquait d'endommager certains composants. Ces défauts viendraient de l'âge du circuit ou des dernières modifications de la carte (réalisées par une précédente stagiaire) qui n'avaient pas été correctement réalisées ni testées. J'ai tenté de corriger ces défauts en refaisant certaines soudures, mais il y avait toujours des problèmes de faux contacts, notamment au niveau de l'amplificateur opérationnel (probablement déjà endommagé). Nous avons donc abandonné l'idée des tests par simulation de signaux.
A l'aide des données que j'ai pu retrouver dans les archives et les spécifications des composants, j'ai néanmoins changé les valeurs pour le filtre de sortie de façon à mettre une résistance R7 plus importante (R7 >> R5//R6), et fixer le filtre à une fréquence de coupure f0~=100Hz pour améliorer le filtrage.
Nous avons envisagé l'idée d'utiliser un filtre du 2nd ordre de type Sallen & Key pour améliorer encore le signal de retour, mais la carte étant déjà très chargée, nous avons décidé de rester sur un filtre du 1er ordre pour l'instant et tenter éventuellement un 2nd ordre plus tard.
Capteurs de pression
Actuellement, comme le montre le schéma ci-dessus, la valeur de retour utilisée par la carte de contrôle est celle fournie par la valve pneumatique. Or cette valeur est très bruitée et peu représentative de la pression réelle à l'intérieur des cavités car elle est mesurée par la valve, mais il y a des pertes et des pressions sensiblement différentes à cause des tuyaux et autres imperfections. Une autre approche qui a été envisagée est d'utiliser un capteur installé à l'intérieur de chaque valve et qui permettrait donc d'obtenir une valeur plus proche de la réalité. Des premiers essais ont été réalisés avec un capteur de pression absolue étant le capteur le plus facile à installer. Cependant ce capteur pose quelques problèmes au niveau de l'offset et de la précision. En effet, dans le cas où l'on arrête et redémarre le robot, la pression dans les cavités peut changer et il est donc difficile de régler un offset universel, une référence, qui prenne en compte ces changements, sans risquer d'endommager le robot (sur-pression, sous-pression...). L'environnement pose également problème (pression extérieur, poids futurs que le robot devra porter...).
Nous avons donc envisagé l'utilisation des capteurs de pression relative (différentielle) qui peut utiliser la pression atmosphérique comme référence et sa pression interne pour se calibrer au démarrage. Ce type de capteur est donc plus fiable, bien que plus difficile à intaller (2 tuyaux traversants les cavités à installer, ce qui peut engendrer des pertes). L'installation de ceux-ci ne sera donc probablement pas possible d'ici la fin de mon projet, mais leur utilisation future a été prévue et intégrée à la carte de contrôle.
2 - Réalisation de la carte de contrôle
Schématique et PCB
L'objectif de cette nouvelle carte de contrôle est d'être la plus polyvalente possible pour que les applications futures puissent être testées sans qu'il soit nécessaire de refaire une carte. La carte réalisée initialement et présentée ci-dessus ne permet de contrôler qu'une seule cavité du robot. Or, à terme, le système de contrôle devra être capable de contrôler les 4 cavités. Il faut donc prendre cet aspect en compte pour la nouvelle carte et le schéma présenté ci-dessus doit être répété 4 fois pour contrôler les 4 valves pneumatiques.
Nous avons également ajouté 2 rangés de 4 commutateurs. La première rangée permettra de by-passer les résistances R3 (cf schéma) des amplificateurs du circuit dans le cas où nous voudrions utiliser un gain de 1 au lieu de 2 (dans le cas d'un éventuel changement de valve pneumatique, d'AOP, ou d'alimentation). La deuxième rangée de commutateurs permettra de by-passer le diviseur de tension (R5//R6) dans le cas de l'utilisation d'un capteur de pression interne comme valeur de retour. En effet, comme expliqué précédemment, la valeur de retour est actuellement transmise par la valve pneumatique, mais une autre option envisagée est d'utiliser des capteurs de pression dans les cavités afin d'avoir plus de précision.
Le schématique complet de la nouvelle carte, réalisé sur Kicad, est disponible ici ou dans les livrables en version PDF pour une meilleure qualité :
.
Câblage
Pour commencer le câblage, il a fallu attendre la réception des composants commandés par l'Inria ainsi que la carte imprimée à Polytech. Cette attente a été plutôt longue en raison des démarches administratives à effectuer pour commander du matériel. L'équipe a donc voulu faire une commande groupée plus importante, ce qui a retardé la demande et la réception de mes composants. En ce qui concerne la carte PCB, les modifications successives ainsi qu'un problème informatique au service EEI a également retardé l'impression mais sans les composants c'était de toute façon moins problématique.
Une fois la carte imprimée et les premiers composants reçus, j'ai pu d'abord constater une erreur au niveau de l'impression : les trous pour les pins du connecteur DC 24V n'avaient pas été faits et ceux des connecteurs de l'AOP étaient trop petits (problème d'empreinte sur Kicad). J'ai donc dû utiliser la Dremel du labo de l'Inria pour effectuer minutieusement les trous à la main. Le câblage a ensuite pu être fait sans encombre. Il manquait dans un premier temps quelques composants qui étaient sur une autre commande comme par exemple les switchs. J'ai donc dû câbler un fil pour compenser cela et faire des tests en attendant la réception.
Suite au câblage et aux premiers tests, 2 problèmes ont été révélés. Le premier est que le signal de contrôle des valves s'est trouvé être plus bruité qu'attendu. Cela est probablement dû à certaines pistes un peu longues qui peuvent produire un effet antenne, notamment au niveau des résistances R3 de l'AOP qui, lorsqu'elles ne sont pas câblées (switchs ouverts), laissent place à de longues pistes non utilisées. Ce bruit est peut-être aussi dû aux pattes des résistances qui sont entourées de la masse, ce qui peut produire un effet de condensateur. Pour palier à ce problème, nous avons décidé de rajouter un condensateur aux bornes de la résistance R4 (boucle de l'AOP) de façon à réaliser un nouveau filtre qui ne pourra qu'être bénéfique quelque soit l'application.
Le deuxième problème plus important est une erreur d'empreinte des transistors MOSFET. Alors que je constatais des tensions anormales à leurs bornes, j'ai vérifié le circuit et il s'est avéré que l'empreinte fournie par Kicad et qui était censée être universelle (package TO-220) était en vérité fausse, ou du moins inadaptée pour mon application. L'effet de cette erreur est que les pins de la base et du collecteur se retrouvent échangées et le fonctionnement des MOSFET n'est donc pas celui souhaité. Pour corriger cela, je vais dans un premier temps tenter d'échanger manuellement les pins afin d'effectuer des tests, mais par la suite il faudra obligatoirement réimprimer une carte.
Premiers tests
Suite aux modifications manuelles expliquées ci-dessus, et en attendant l'impression de la nouvelle carte corrigée, j'ai pu effectuer quelques tests. J'ai utilisé pour cela une petite cavité de test réalisée en silicone et un petit programme simple permettant un gonflage et dégonflage progressif de la cavité en contrôlant uniquement le compresseur et la valve pneumatique. J'ai également connecté un capteur de pression tel que celui utilisé sur BigMomma pour tester la récupération de données. Après quelques corrections les tests ont bien fonctionné. Cependant, à cause du problème des MOSFETs, je n'ai pu tester qu'un seul circuit de contrôle. Les autres circuits étant identiques, il ne devrait pas y avoir de problème par la suite. Nous avons également remarqué quelques soucis de faux contacts qui se sont créés à force d'utilisation notamment sur certains condensateurs. Ces problèmes devront être évités pour la prochaine carte.
Extrait du programme réalisant un gonflage progressif via la PWM :
void loop(){
analogWrite(inputPin, inflation); // PWM Command
delay(300);
if(inflation == modulo + 10){ // Every 10 increments
val = analogRead(pressureSensorPin); // Pressure Sensor reading
Serial.println(val, DEC);
modulo = modulo + 10;
delay(100);
}
inflation++; // PWM incrementation
Serial.println(inflation, DEC);
if(inflation>40){ // Stop incrementation and reset
inflation = 0 ;
modulo = 0 ;
analogWrite(inputPin, inflation);
delay(3000);
}
}
Tests en situation réelle
Après la réception et le câblage de la nouvelle carte de contrôle, j'ai pu me lancer dans le calibrage des différents éléments de contrôle (capteurs, PID, potentiomètres...) afin de pouvoir, à terme, effectuer des tests en situation réelle, c'est-à-dire directement sur le robot avec le programme de contrôle préalablement réalisé.
J'ai tout d'abord réaliser le calibrage du capteur Phidget 1140 en en utilisant un autre et en faisant des tests hors robot. En modifiant le programme et en effectuant plusieurs mesures, j'ai pu arriver à un calibrage proche de la valeur réelle. D'autres modifications seront apportées avec les tests sur le robot afin d'obtenir des valeurs encore plus précises.
Dès la tentative de passage sur le robot, j'ai été confronté à un problème. Les données envoyées par le capteur interne n'étaient pas celles attendues. Nous avons donc dû ouvrir le robot pour vérifier et il s'est avéré que le capteur installé n'était pas celui annoncé. En effet, le Phidget avait déjà été remplacé par le capteur relatif MPX4250 et mes encadrants n'en avaient pas été informés.
D'un certain point de vue, cette modification est bénéfique car elle devait de toute façon être faite à terme, l'utilisation d'un capteur relatif étant dans notre cas plus efficace que celle d'un capteur absolu. Mais le fait de ne pas être courant avant a posé 2 problèmes : les connexions entre les deux capteurs étant différentes, nous avons dégradé inconsciemment celui installé et avons du le changer; et le calibrage faite au préalable ne servait donc plus et j'ai dû la recommencer avec le nouveau capteur.
Après l'installation et le calibrage du nouveau capteur relatif, j'ai pu procéder aux tests. Les 2 cartes (contrôle pneumatique et pompe à vide) se sont révélées toujours fonctionnelles sur le robot réel, avec des données envoyées et collectées satisfaisantes (valeurs attendues, peu de bruit etc...). J'ai donc pu me lancer sur le réglage du PID et la recherche de seuils.
3 - Programmation du contrôle pneumatique
Problématique
Le programme actuel est globalement fonctionnel, mais il est nécessaire d'apporter plusieurs modifications pour améliorer le rendement et la précision du contrôle du robot. Le principal problème vient de l'alternance entre gonflage et dégonflage de la cavité. Actuellement le gonflage se fait avec un PID et l'ouverture de la vanne venant du compresseur tandis que le dégonflage s'effectue par l'ouverture de la vanne menant à la pompe à vide. Ces techniques sont simples et efficaces mais peu stables. En effet, une fois la pression arrivée à la valeur demandée, il y a un temps entre les fermetures des vannes et la stabilisation complète de la pression (temps de fermeture, air dans les tuyaux, fuites...). Cela induit des dépassements qui ont pour effet de faire s'alterner rapidement le compresseur et la pompe à vide jusqu'à la stabilisation difficile de la pression à la valeur demandée, et risque à force de dégrader les pompes.
Une solution envisagée est de définir des seuils autour de la valeur demandée qui permettront d'atténuer les ondulations. Lors du gonflage, il suffit de modifier les valeurs du PID une fois le seuil dépassé pour que le gonflage se fasse plus lentement. Lors du dégonflage, on peut couper la pompe à vide et ouvrir les vannes menant à l'extérieur pour que l'air se vide naturellement et donc plus lentement. Cette solution permettra également de palier le problème de commande très peu changeante ne nécessitant pas l'utilisation des pompes, ainsi que le problème des interractions extérieures qui peuvent fausser les valeurs (ex: une personne qui appuie sur le robot, faisant changer la pression).
Par la suite, une amélioration de cette solution peut être envisagée pour le dégonflage qui est l'utilisation d'une électro-vanne qui contrôlera ce passage par la pompe à vide ou par l'extérieur. Mais dans un premier temps, ce n'est pas indispensable et c'est la première solution qui sera testée.
Réglage du PID
J'ai réalisé les premiers tests sur le robot complet directement avec le programme qui avait été fait par les précédentes recherches afin de vérifier son fonctionnement et mieux assimiler l'état actuel du contrôle. Le contrôle était fonctionnel mais il y avait des différences avec les données précédemment collectées. Dans un premier temps, le gain de l'AOP a été modifié sur ma carte (passé de 2 à 1) ce qui a induit, comme attendu, de forts dépassements de la réponse. Il est donc nécessaire pour cela de recalibrer le PID. De plus, un prototype de fonction dans le programme permettant de désigner des seuils d'activation avait été entamé, mais il ne correspondait pas à nos attentes. Nous avons donc décidé de le supprimer et de reprendre cette fonction plus tard, une fois le PID réglé et les seuils définis.
Recherche des seuils
Un premier seuil a été fixé pour éteindre la valve (ce qui la met en échappement total) à l'aide des MOSFETs lorsque la pression est de 0,2 kPa au dessus de la commande (measured_value - desired_value > 0.2). Cela fournit deux avantages :
Dans un premier temps, cela constitue une sécurité en cas de dépassement imprévu de la commande (par exemple un problème de régulation ou une intervention extérieure sur le robot) permettant d'éviter un déchirement du robot lors d'un gros gonflage. Dans cette situation, la valve se coupe, il ne peut donc plus y avoir de pression supplémentaire et l'air peut s'échapper.
Dans un second temps, cela permet théoriquement de dégonfler plus rapidement le robot si une nouvelle commande demande une pression bien inférieure à la précédente car la valve éteinte est à priori plus ouverte à l'échappement que lors d'une commande à 0. Ce second aspect est cependant actuellement théorique. J'ai en effet réalisé plusieurs tests et il s'avère que le fait de couper la valve ne change pas (ou très peu) la vitesse de dégonflage. Cela est probablement dû à la capacité de la pompe à vide qui ne peut pas aspirer plus d'air, malgré la plus grande ouverture de la valve. Il sera nécessaire de réaliser de nouveaux tests avec une pompe à vide plus performante pour valider cette théorie.
Autre problème découvert
Lors de mes recherches pour le réglage du PID, j'ai testé le dégonflage de la cavité en débranchant la pompe à vide, de façon à observer la réaction. Cela m'a permis de découvrir un problème de programmation très dangereux pour le robot. En effet, lors de ces tentatives, j'ai constaté qu'à un certain moment du dégonflage la commande passe de 0 (pour que la vanne soit à l'échappement) à une valeur extrêmement grande, sans raison apparente. Cela a pour effet de regonfler le robot sans limite, pouvant mener à son éclatement si on ne coupe pas la valve à temps. Après différents tests j'ai dans un premier temps constaté que la durée y était pour quelque chose, ce qui expliquait que cet incident ne s'était pas produit auparavant grâce à la pompe qui accélérait le processus. Malgré mes recherches perso, ce n'est qu'avec l'aide de mon tuteur Mario que nous avons pu découvrir la raison difficilement décelable. Lors du dégonflage, la valeur de la commande descend dans les négatifs puisque la pression dans la cavité est supérieure à celle désirée. Or la valve ne prenant pas en compte les valeurs négatives, le programme réalisé par la précédente chercheuse n'affichait pas ces valeurs et les ramenait à 0, raison pour laquelle je n'ai pas situé le problème. Le temps de dégonflage étant plus long sans la pompe et le PID faisant son travail, la commande diminue rapidement dans les négatifs et passe finalement en overflow ce qui change la valeur en une autre très grande. Pour contrer ce problème, nous avons modifié le type de la valeur de commande d'un entier à un entier long. Cette solution ne corrige pas le passage dans les négatifs, mais ralonge énormément le temps d'arrivée au dépassement, ce qui évitera cet incident car il ne sera à priori jamais atteint compte tenu de la taille du robot et de l'utilisation de la pompe en cas d'écart important avec la consigne.
4 - Travail subsidiaire
Contrôle de la pompe à vide
Durant l'attente de certains composants ou tests, j'ai pu me lancer sur une autre tâche facultative confiée par mes tuteurs et qui concerne le contrôle interne de la pompe à vide. Pour les besoins du robot, une nouvelle pompe à vide a été créée auparavant permettant le contrôle de la pression dans son réservoir. Cette pompe est composée d'un compresseur inversé, d'un capteur de pression Phidget et d'un système de contrôle électronique de type bascule de Schmitt permettant de couper ou enclencher la pompe en fonction de la pression au sein de son réservoir. Le système ainsi réalisé est le suivant :
Cependant ce système électronique a été fait tardivement pour des tests à l'aide d'une breadboard, et possède des valeurs choisies arbitrairement sans grande précision. Je me suis donc lancé dans la conception d'une carte électronique plus propre qui permettrait de réaliser ces fonctions. De plus, la réception d'un boîtier d'alimentation double tension (5V/12V) permet de simplifier le montage et surtout de rendre le circuit indépendant (car en effet, actuellement le 5V est pris sur l'Arduino de contrôle).
Pour ce faire, il a été nécessaire de réaliser au préalable plusieurs calculs pour définir les valeurs des composants. Nous avons également décidé de changer la résistance R11 par un potentiomètre de façon à avoir une certaine liberté de modification des seuils de la bascule de Schmitt et rendre ainsi la carte plus polyvalente dans le cas par exemple d'un changement de pompe.
Un circuit imprimé a donc été imprimé pour réaliser cette fonction.
Câblage et tests
Après réception de la carte et des composants, j'ai pu les câbler et réaliser les premiers tests. J'ai été confronté à plusieurs problèmes dûs à des faux contacts ou des valeurs de potentiomètres mals réglées qui m'ont un peu perturbé, ne trouvant pas au départ d'où ils venaient. Mais après les avoir identifiés et corrigés, j'ai pu réaliser les tests sur la pompe à vide et procéder ainsi au réglage du cycle d'hysteresis souhaité. Le fait d'ajouter un second potentiomètre nous a permis, comme souhaité, d'avoir plus de libertés sur ce réglage. Nous avons donc pu définir un cycle d'arrêt/allumage plus précis de la pompe : celle-ci fait désormais en sorte d'avoir en permanence une pression entre 0,6 et 0,7 bar dans son réservoir.
.
Livrables
Détails composants
Schématiques et PCB
Schéma de la carte de contrôle pneumatique globale (réalisé sur Kicad) : Fichier:Controle pneumatique ki.pdf
Rapport
Rapport PFE mi-parcours : Fichier:GIOVANNANGELI Florian Rapport PFE mi-parcours.pdf
Rapport PFE final : Fichier:GIOVANNANGELI Florian RapportFinal PFE.pdf
Fichiers de programmation
Codes Arduino pour le contrôle pneumatique du robot : Fichier:Control loop.zip
