IMA3/IMA4 2021/2023 P10
Sommaire
Résumé
Notre projet est de concevoir un robot mobile à deux roues ayant la faculté de s'équilibrer automatiquement. En effet, ne possédant que deux roues, l'équilibre du robot sur son axe vertical est compromis, a la manière d'un segway. Afin d'empecher ce désequilibre, nous avons pensé à intégrer au robot un système de contrôle de son angle vertical, utilisant des capteurs et des actionneurs mis en relation par une boucle de régulation automatique. Les composants electroniques et mécaniques du robot nous étant fournis, notre travail consiste donc surtout à étudier ce système, pour ensuite concevoir un asservissement, et l'implémenter dans notre robot.
L'intégralité de notre programme est disponible sur le dépôt git à l'adresse: https://gitlab.com/remi_farault/self-balanced-robot
Présentation générale
🌏Contexte
Les moyens de transport actuels reposent principalement sur le principe du robot à deux roues, c'est la raison pour laquelle l'étude de celui ci s'avère importante, en effet l'étude de sa conception et son contrôle va nous permettre de développer des outils innovants qui pourraient potentiellement intéresser des sociétés de transport .
🎯Objectif
Notre objectif principal est de commander le robot, de là interviennent d'autres objectifs tel que la stabilité ,développer un code robuste qui assure cette fonctionnalité et aussi le contrôler pour réaliser des fonctionnalités de déplacement et d'éviter des obstacles . Des objectifs secondaires sont de créer un site web à travers lequel nous allons mener toutes les opérations de contrôle .
🔍Expression du besoin
Un robot autoéquilibré à deux roues est un type de robot qui peut se maintenir en équilibre sur deux roues sans tomber. Pour réaliser cette fonctionnalité, le robot utilise un ensemble de capteurs, d'algorithmes de contrôle et de moteurs pour ajuster sa position en temps réel.
Le diagramme interacteurs permet en fait de visualiser les fonctions services assurées par le système
.png)
Réalisations et Résultats
Après mis en place notre stratégie de gestion de projet en s6 à travers le diagramme de GANTT et le cahier de charges fonctionnels, nous nous sommes focalisés sur l'étude technique.
Tout d'abord, étudier à travers des outils automatiques la stabilité du robot en faisant appel à des modèles théoriques et pratiques et commencer par un raisonnement par niveaux, d'abord le niveau 1 du moteur à courant continu et les équations correspondantes puis le niveau 2 assurant la stabilité du robot directement, on avait la possibilité de passer directement au niveau 2 à travers le modèle du pendule inversé et les équations qui en découlent sauf que celui-ci ne nous permettra pas de revenir au niveau 1 et asservir le moteur à travers les codeurs incrémentales ,la deuxième partie consistait à réaliser les codes informatiques en s'appuyant sur les structures de données en C vues l'année dernière et conduire un même raisonnement(par niveaux) s'appuyant d'abord sur les codes sources correspondants à la génération d'un signal PWM pour les deux moteurs avec un rapport cyclique modifiable, et aussi les codes sources correspondants à la gestion des moteurs, en effet, ceux-ci tournent dans un sens ou dans un autre ou ne tournent pas en fonction de la variable in1 et in2 pour faire tourner les moteurs .
Cependant, nous avons rencontré quelques problèmes en automatique notamment pour trouver des valeurs des constantes théoriques pour les références du moteur entre les mains, ce qui nous a obligé à prendre des valeurs issues d'autres applications, nous avons rencontré aussi quelques problèmes choisir une modélisation parmi celles qui sont disponibles sur Internet .
Etude Automatique
Avant de programmer notre système sur la carte Arduino, nous avons également créé une simulation complète de notre système robotisé sur SIMULINK. Cependant, avant cela, nous avons dû déterminer les équations qui régissent notre système en trouvant les matrices d'inertie de chaque composant de notre robot, à savoir la masse transportée par le robot (M), le châssis constitué de deux plateaux et de la motorisation (les piliers et leur inertie ont été négligés car leur masse est très faible), ainsi que les roues (roue droite et roue gauche). Vous trouverez ci-dessous les matrices d'inertie que nous avons obtenues pour chaque composant.
Masse M :
Les coefficients seront notés dans la suite pour simplifier : AM,BM,CM
Chassis:
Les coefficients de la diagonale seront notés dans la suite pour simplifier : AH,BH,CH
Roue gauche:
Les coefficients de la diagonale seront notés dans la suite pour simplifier : AD,BD,CD
Roue droite:
Les coefficients de la diagonale seront notés dans la suite pour simplifier : AD,BD,CD
Ci-dessous un paramétrage de notre système : Chaque angle détermine un repère
Le repère R0 est supposé galliléen.
Le repère R1 est en rotation ,appelé angle de virage par rapport à R0.
Le repère R2 est en rotation ,appelé angle d’inclinaison du châssis par rapport à R0 .
Le repère R3 est en rotation ,appelé angle d’inclinaison arrière-avant de la masse par rapport à R0 .
Le repère R4 est en rotation ,appelé angle d’inclinaison droite-gauche de la masse par rapport à R0 .
l’angle de consigne est de 0deg,nous employons un PID pour corriger l’angle de mesure,à sa sortie,on aura une tension W(p).Les blocs Km et W(p) assurent le passage tension->couple->angle ,il faut ensuite retirer pour ne garder que l’angle d’inclinaison du châssis .Km=0.0125N.m.V-1(d’après la datasheet du moteur)
Les équations obtenues sont les suivantes (Le détail des calculs a été précisé dans le Rapport):
Après linéarisation : Considérer l'approximations des petits angles pour le sinus et cosinus,et négliger aussi la vitesse angulaire quadratique devant la vitesse angulaire,nous obtenons :
Une courbe d'angle d'inclinaison stable avec un léger dépassement et un bon temps de réponse indique que le robot auto-équilibré à deux roues est capable de maintenir efficacement son équilibre. Le léger dépassement se traduit par une légère inclinaison du robot dans la direction opposée à son déplacement, suivie d'une stabilisation, ce qui est une caractéristique normale d'un système de contrôle de rétroaction. Le bon temps de réponse indique que le robot réagit rapidement aux perturbations qui pourraient affecter son équilibre, garantissant ainsi une stabilité à long terme. Dans l'ensemble, ces résultats suggèrent que le système de contrôle du robot auto-équilibré est bien conçu et assure une maintien de l'équilibre efficace et fiable, ce qui est essentiel pour son bon fonctionnement.
Modélisation en 3D du robot
La dernière étape de l'étude automatique consiste à construire notre robot en 3D,en utilisant la bibliothèque Simscape multibody avec les bonnes masses de et les bonnes longueurs de notre robot ,de ce fait notre robot est constitué de deux parties:
Châssis:composé de deux plateaux,de piliers pour le tenir .
Cart : composé d’une tige qui représente l’axe de rotation des roues ainsi que des roues ,nous avons aussi placé des cylindres au niveau du centre des roues pour représenter les deux moteurs
Le bloc entre le châssis et le revolute joint est appelé un rigid transform,il est utilisé en mode rotation et réglé de telle façon pour mettre le châssis dans la bonne position . L’angle en rad est ensuite récupéré du bloc Revolute joint et converti en deg .Le bloc Ps Simulink Converter permet de passer de la physique du système aux blocs standards de Simulink . La perturbation est ensuite ajouté avec une valeur de 10 degré,le PID est réglé par l’autotune pour avoir la réponse la mieux adapté à l’application et on réutilise le bloc PS-Simulink Converter pour passer à la physique du système . Finalement le bloc prismatic joint est relié d’une part à la masse pour permettre au robot de se déplacer sur le sol,d’autre part , il est relié au PID pour donner la force nécessaire d’autoéquilibrer le système .
Le tune des PID a été fait automatiquement,cependant nous avons réalisé quelques essaies avec différentes valeurs de PID,en effet l'augmentation du P équilibre le robot mais pas indéfinniment,on augmente alors le coefficient D pour avoir l'éuilibre souhaité,cependant l'érreur est relativement grande,d'ou la nécessité d'augmenter le coefficient I .
Effectivement, dans la vidéo, on observe un léger dépassement initial qui se manifeste par un déséquilibre momentané du robot. Cependant, il est important de souligner que malgré ce déséquilibre initial, le robot parvient à maintenir son autoéquilibrage de manière continue.
Environnement de developpement
Notre microcontrolleur étant une Arduino Uno, nous aurions pu utiliser le framework Arduino donnant accès à un IDE intégrant les outils pour compiler et flasher le code, ainsi qu'une multitude de bibliothèques haut niveaux très simples d'utilisation et plutôt performantes, permettant de programmer notre robot en simplement quelques dizaines de lignes de code.
Cependant, l'Arduino est simplement une carte de prototypage intégrant un microcontrôleur AVR Atmega 328p. Les microcontroleurs AVR disposent d'une grande communauté, et il existe de nombreux outils nécessaires au developpement sur ces cartes. Afin d'avoir un meilleur contrôle sur notre projet, et surtout d'en tirer un maximum de compétences, nous avons donc décidés de programmer notre robot directement en C en utilisant les outils AVR:
- avr-gcc: compilateur open-source portant toutes les fonctionnalités du langage C standard sur les microcontroleurs AVR. Seul, son utilisation est quasiment impossible et demande trop de travail en programmation bas-niveau.
- avr-libc: implémentation basé sur le compilateur avr-gcc de la bibliothèque standard du langage C. Cette bibliothèque permet donc d'utiliser les fonctions et structures standards du C (IO, maths, chaines de caractères), mais elle intègre également un mapping mémoire de tous les registres de l'atmega, ainsi qu'un mécanisme pour programmer des interruptions.
- avr-objcopy: ce programme en ligne de commande formate le binaire obtenu en format utilisable par les AVR
- avr-dude: ce programme en ligne de commande permet de flasher via une interface USB-série un microcontroleur AVR présent sur une carte Arduino.
Nous avons donc developpé un Makefile utilisant tous ces outils, constituant un environnement de developpement très efficace pour notre projet. Ce Makefile est disponible sur notre gitlab.
Programme du robot
PWM
La première étape consistait à commander nos moteurs DC, afin de poser les bases de notre asservissement bas niveau. Ces moteurs sont contrôlés par le driver de moteurs, utilisant des signaux logiques pour définir l’état d’un moteur et des signaux PWM pour définir la vitesse de rotation. La génération de signaux PWM sur AVR se fait en utilisant les timers en mode PWM. Tout simplement, nous avons un registre compteur 16 bits incrémenté périodiquement, et une valeur maximale définie par le registre ICRx. Nous utilisons ensuite les registres OCRnx contenant une valeur inférieure au maximum. Lorsque le compteur atteint la valeur contenue dans OCRnx, il inverse la valeur logique de sortie du pin OCnx. Ainsi, nous pouvons modifier instantanément la valeur d’OCRnx afin de modifier le rapport cyclique de notre signal. Ce rapport cyclique est ensuite directement proportionnel à la vitesse de rotation du moteur associé. La fréquence du signal est définie par la période d’incrémentation du compteur et par la valeur maximale ICRx. Pour notre composant, nous pouvions utiliser une fréquence allant jusqu’à plusieurs kHz. Cette fréquence n’a aucun impact sur la rotation du moteur. Nous avons donc choisis 20 kHz. Nous avons définis la init_pwm pour configurer les registres nécessaires, et la fonction generate_pwm pour modifier le rapport cyclique de nos deux signaux PWM avec la valeur souhaitée.
Encodeurs
Une fois nos moteurs pouvant tourner à une vitesse voulue, nous avons du trouver un moyen de mesurer leurs vitesses effectives afin de réaliser une boucle d’asservissement. Pour cela, nous avons utilisés les encodeurs optiques disponibles sur nos moteurs DC. Ces encodeurs envoient sur leur broches un front-montant à chaque tour de la roue codeuse reliée au moteurs (ayant une vitesse proportionnelle à celle du moteur). En détectant ces fronts montant, nous pouvons donc compter le nombre de tours du moteur pendant un intervalle de temps défini, puis déterminer la vitesse réelle du moteur. Pour détecter les fronts montant, nous utilisons l’interface Pin Change Interrupt de l’Atmega. Cette interface exécute une interruption logicielle à chaque changement d’état logique du pin associé. Dans notre cas, nous devons ensuite observé l’état précédent de la sortie et l’état actuel pour déterminer si on est bien en présence d’un front montant. Une fois le front montant détecté, cette interruption incrémente ensuite le compteur de tours. Ce compteur est ensuite utilisé pour calculer la vitesse de rotation puis remis à zéro pour la mesure suivante. Dans notre cas, nous réalisons cette mesure à une fréquence d’environ 244 Hz, dans une autre fonction d’interruption qu’on détaillera plus loin.
Angle
Notre boucle de régulation principale a besoin d’une mesure de l’angle d’inclinaison du robot sur son axe vertical perpendiculaire à celui de déplacement. Cette mesure s’effectue via le MPU6050. Ce composant fonctionne via le protocole i2c, protocole de communication simple utilisé par la plupart des systèmes électroniques. Ce protocole étant bas niveau, il existe de nombreuses bibliothèques implémentés en C permettant son utilisation. De plus, le MPU6050 est un composant très complet et complexe, afin d’en récupérer l’angle, il faut d’abord amorcer une communication i2c puis configurer certains des ses registres, afin ensuite de pouvoir lire les registres contenant la mesure de l’angle selon l’axe désiré. Afin de conserver un code efficace et concis, nous avons également décidés d’utiliser une bibliothèque faisant office de « driver » pour ce composant, intégrant des fonctions d’initialisation et de lecture des mesures faites par ce gyroscope. Nous obtenons donc la valeur de l’angle en degrés, comprise entre 0 et 360.Dans notre cas, nous souhaitions obtenir une valeur comprise entre -180 et 180, car seule la valeur absolue et le sens de l’inclinaison nous intéresse, nous avons donc appliqués une correction de cette valeur.
Interruption principale
Lors de implémentation d’un asservissement automatique via un microcontrôleur, la puissance de calcul finie impose que les commandes des actionneurs et les mesures des capteurs doivent être réalisées périodiquement. Pour cela, nous pouvons utiliser une routine d’interruption qui s’exécute à chaque overflow d’un compteur, via l’interface des timers de l’atmega. Dans notre cas, cette interruption correspond à la fonction principale de notre programme. Nous avons réglés sa fréquence à 244Hz, en divisant le fréquence de base de 16MHz avec un prescaler de 256 (plus une deuxième division par 256 du à la taille du registre timer de 8 bits). Cette interruption vient d’abord remettre a zéro les compteurs des encodeurs et récupérer la vitesse des deux moteurs. Ensuite, elle effectue les calculs nécessaires à la régulation de l’angle, mais également de la vitesse linéaire et de la rotation du robot. Chaque paramètre à réguler est corrigé par un régulateur PID de coefficients différents via la fonction pid(). Enfin, nous obtenons une commande à envoyer aux moteurs, qui actionnent notre robot de la manière souhaitée. Le code de notre système est disponible sur nôtre dépôt gitlab également.
Gestion de projet
Durant ces trois semestres, la gestion de projet est un des domaines où nous avons le plus de difficultés, mais également un de ceux dans lequel nous avons le plus appris.
Voici notre Diagramme de Gantt previsionnel réalisé au S6
D'abord trois, nous nous sommes retrouvés à deux dès le deuxième semestre, et nous avons donc du modifier l'organisation prévue pour la suite.
Nous avons au final plus ou moins suivis ce diagramme previsionnel, à quelques choses près.
En travaillant à deux, nous avons du trouvé un moyen d'avancer efficacement. L'un de nous étant en filière SA (Systemes Autonomes) et l'autre en filière SC (Systemes Communicants), la répartition des taches informatiques et automatiques était donc simplifiée.
Cependant, nous avons donc du réussir à expliquer et à mettre en relation chacune de nos parties, en s'améliorant sur la partie communication. Pour cela, au début de chaque séance, nous commencions par faire le point sur l'avancement globale et propre à chacun.
Ensuite, nous nous répartitions les taches communes aux différentes parties.
Enfin, nous échangions sur les taches respectives à nos deux parties afin de pouvoir les faire coincider le moment venu, et il est arrivé plusieurs fois que l'on s'aide réciproquement chacun sur la partie de l'autre.
Globalement, cela a été positif car nous avons pu tous les deux sortir de notre zone de confort et apprendre beaucoup dans différents domaines.
Comme outils, nous utilisions donc git et gitlab pour la gestion de code et google drive pour le partage de documents.
Nous avons préferés travailler un maximum en présentiel, d'un accord commun.
Semestre 6
Séance du 01/03/22
Séance de découverte du sujet de notre projet.
Recherche de l'existant
Réalisation de recherches sur leurs différentes utilisations.
Séance du 08/03/22
Début de création du diagramme de Gantt .
Réalisation d'une étude du besoin.
Séance du 15/03/22
Etude du marché : Recherche des robots similaires.
Commencer à prendre en main le robot.
Séance du 22/03/22
Poursuite de l'étude de marché.
Etude des opportunités.
Séance du 29/03/22
Fin d'étude du marché.
Commencer à rédiger le cahier des charges.
Séance du 05/04/22
Poursuite de la rédaction du cahier des charges.
Séance du 26/04/22
Bilan du semestre.
Etude de faisabilité.
Etude des risques.
Séance du 03/05/22
Finalisation de l'étude des risques.
Finalisation de l'étude de faisabilité.
Finalisation du cahier des charges.
Semestre 7
Séance du 10/10/22
Commencement de l'étude technique des encodeurs . Recherche des boucles d'asservissement du robot .
Séance du 21/10/22
Etude du changement de la carte arduino pour ajouter des nouvelles fonctionnalités : connexion Wifi, fréquence microprocesseur plus élevé,.. Test des encodeurs moteur DC : validé . Poursuite de recherche des boucles d'asservissement du robot .
Séance du 28/10/22
Etude de génération des signaux PWM
Test sur Matlab Simulink des boucles d'asservissement issues des robots similaires .
Séance du 18/11/22
Poursuite de la programmation des signaux PWM du robot.
Calcul de la fonction de transfert issue de la boucle.
Séance du 21/11/22
Etude du fonctionnement du gyroscope et des autres composants pour programmer le robot .
Séparation du travail a effectuer pour le robot entre une boucle du moteur DC(niveau 1) et une boucle du niveau supérieur(niveau 2) pour asservir l'angle d'inclinaison du robot.
Séance du 25/11/22
Modification et amélioration du diagramme de Gantt pour le S7 et le S8.
Avancée de la modélisation de la boucle du niveau 1 .
Diagramme de Gantt S7-S8
Séance du 28/11/22
Fin d'implémentation de la boucle du niveau inférieur sur Matlab/Simulink et récupération des résultats sur le scope .
Séance du 08/12/22
Poursuite de la partie informatique et avancement de la partie automatique . Programmation de la liaison série pour débugger les sorties de notre robot .
Séance du 15/12/22
Début de rédaction du rapport pour le S7
Semestre 8
Séance du 18/01/23
Recherches pour le gyroscope . Test des encodeurs . Communication sur les attentes du semestre s8 ,les fautes à éviter pour rebondir par rapport au retard S7 Mise à niveau pour comprendre les aspects techniques de la partie informatique pour pouvoir travailler ensemble sur les résultats du S8 .
Séance du 25/01/23
- Suppression des structures de données pour avancer plus rapidement sur les résultats du semestre s8 .
- Recherches pour la programmation des interruptions PCINT .
- Recherche sur la doc technique pour faire l'initialisation des interruptions externes .
- Recherche de la modélisation en 3D de notre robot pour trouver les paramètres PID de notre robot .
Séance du 01/02/23
Durant cette séance, nous avons :
Modification du code des encodeurs et test sur les moteurs DC .
Poursuite de recherche de l'existant pour trouver le code du gyroscope .
Mise à jour du git .
Début du calcul des matrices d'inertie de chaque solide.
Recherche du code des régulateurs.
Avancement sur la gestion de projet .
Séance du 08/02/23
Durant cette séance, nous avons essayé de récupérer les résultats des tests électronique de l'oscilloscope effectués dans les salles d'électronique .
Le code des encodeurs marchent ,la liaison série affiche exactement la vitesse de la consigne :les Régulateurs implémentés correspondent bien à notre applications.
Poursuite de la programmation de la partie informatique du gyroscope : Objectif : récupération de l'angle d'inclinaison sur la liaison série avec la meilleure précision possible .
Séance du 15/02/23
Fin du calcul des matrices d'inertie .
Paramétrage de notre robot pour avoir la visibilité sur les configurations possibles d'avoir(en virage, ligne droite),en précisant les angles d'inclinaison et es repères associés .
Poursuite de programmation des régulateurs par niveaux en utilisant le code précédemment implémenté pour les encodeurs .
Séance du 01/03/23
Fin d'implémentation du modèle en 3D de notre robot pour essayer de l'autoéquilibrer en utilisant les PIDS issues de l'autotune par rapport à nos préférences(stabilité,temps de réponse,dépassement,précision).
Nous avons testé le robot en l'alimentant par le biai la liaison USB ! et enregistrement des résultats .
Poursuite de la partie automatique en trouvant toutes les équations nécessaires à notre modèle .
Séance du 08/03/23
Réalisations de cette séance :
Test du robot pour se stabiliser sur le sol en faisant plusieurs essaies .
Faire tous les calculs des dimensions géométriques de notre robot et test de la boucle d'asservissement avec les deux niveaux sur Matlab Simulink avec nos préférences de stabilité, temps de réponse,précision,dépassement .
Séance du 15/03/23
Absence justifiée .
