ROHGEC RObot Humanoid Genie Electrique Clermont
Projet GE4a-GE5a : ROHGEC : Robot Humanoide Génie Electrique Clermont-Ferrand
Entreprise / Client : Sébastien Lengagne
Auteurs : Vincent Ledain / Clément Latour
Responsable Projet : Sébastien Lengagne
Tuteur industriel : Isabelle Goi / Pascal Fickinger
Résumé
Dans le cadre de notre formation d'ingénieur, il nous est demandé de réaliser un projet mettant en pratique les compétences acquises pendant notre cycle d'ingénieur. Notre client, Sébastien Lengagne, enseignant chercheur à Polytech Clermont Ferrand dans le domaine de la génération de mouvements sûrs pour des systèmes complexes tels que les robots humanoïdes, les avatars humains, les robots hexapodes, nous a demandé de développer un robot humanoïde auto équilibré (base type segway) constitué de deux bras articulés, d'une base mobile et d'une caméra. Ce robot sera utiliser pour promouvoir le département génie Electrique lors des portes ouvertes.
Abstract
As part of our schooling, we are required to carry out a project applying skills acquired during our engineering studies. Our client is Sébastien Lengagne, teacher researcher at Polytech Clermont Ferrand (his field is the robotic generally, generation of mouvement safe to complex systems such as humanoide robot, human avatar and hexapod robots). He proposed us to make a self balancing robot (type segway) made up two swivel arms and camera. This robot will use to promote the Electrical department during
school open days.
Introduction
De nos jour, les robots prennent une place de plus en plus importante, tant dans le domaine industriel que dans la vie de tous les jours. En effet, le robot que nous devons réaliser est une copie (voir amélioration) d'un robot existant, commercialisé et destiné à un jeune publique (enfant).
L'objectif principal de ce projet est de réaliser un système commandé par un Raspberry Pi. Ce dernier sera le cerveau du système, il permettra d'envoyer des requêtes au différents microcontrôleurs constituant le robot. On ajoutera à notre robot une caméra permettant la récupération de données visuelles afin de les afficher sur un écran.
Cahier des charges
- Corps du robot animé d'un mouvement de translation (avance, recule, tourner)
- Deux bras articulés
- Une tête articulée avec caméra
- Utilisation d'un raspberry Pi comme organe de commande du système global
- Programmation en langage C et Python
- Transportable (hauteur maximale de 30 cm et poids inférieur à 4 Kg)
- Prix inférieur à 400 €
Définition des livrables
Dans un premier il nous est demandé de faire fonctionner chaque partie indépendamment les unes aux autres. C'est à dire:
Commande du mouvement de la base (Avance, Recule, Tourner)
Récupération de l'inclinaison de la base
Commande des deux bras articulés
Récupération de l'orientation de chacun
Utilisation du Raspberry Pi pour commander chacunes des parties (base mobile, bras et tête)
Utilisation d'une caméra, commandé par le Raspberry Pi
Communication USB
Une fois les livrables précédents réalisés, des améliorations peuvent être apportées:
Mise en place d'une stratégie de démonstration du robot
Asservissement de la base afin de réaliser l'auto-équilibrage du robot
Assemblage final du robot
Traitement d'image avec Open CV
Synoptique
Le système sera donc composé par plusieurs parties. A savoir deux microcontrôleurs 8bits, 1 pour le commande de la base, 1 pour la commande des bras. Ces deux microcontrôleurs seront tous les deux commandés par un Raspberry Pi via une liaison USB. Ce dernier sera utilisé pour faire du traitement d'image avec l'utilisation d'une PyCam?.
Figure 1: Synoptique
Developpement
1) Choix des composants
Durant le second semestre de quatrième année, nous avons planifié les tâches à effectuer pour la cinquième année de façon à remplir le cahier des charges dans sa totalité. Pour cela, une étape cruciale a été le choix des composants.
Le Raspberry Pi nous a été imposé par le client, celui-ci commandera le système dans sa globalité et il permettra aussi de faire du traitement d'image à l'aide de la PiCam?.
Concernant les actionneurs, il y en avait plusieurs à choisir. En effet, il en fallait pour la commande en translation de la base et pour les deux bras. Concernant la base cela nous avons opté pour des moteurs à courant continu car il offre un couple et une vitesse élevé (les servomoteurs ne sont pas commandable en vitesse, ne conviennent donc pas pour notre application, les moteurs pas à pas sont trop lent, et les moteur brushless ne sont pas adapté à notre application, on les utilise lorsque nous avons besoin de vitesse élevé (quadricoptère, machine à découpage) et demande une électronique onéreuse). Il nous a fallu ajouter un pont en H en amont des moteurs afin de pouvoir commander dans les deux sens de rotation et de manière indépendantes l'un de l'autre (L298N).
Concernant les actionneurs des bras, notre choix c'est porté sur des servomoteurs, car ce sont des moteurs qui permette d'obtenir des positions précise et offre des couples nécessaires à notre application.
Au niveau des organes de commandes, nous avons choisi d'utiliser deux microcontrôleurs, une pour la commande des bras et un pour la commande de la base. Plusieurs raisons à cela, la première permet un découpage des tâches plus facile en binôme, de plus, s'il y a un problème au niveau de la conception de la carte, nous ne restons pas paralysé par le temps de la fabrication de celle-ci et finalement, d'un point de vu académique, l'utilisation de plusieurs composants (Raspberry Pi et microcontôleur) nous permet d'élargir nos connaissances et d'obtenir un système complet.
Nos choix on été d'utiliser les PIC18F4550/2553 de chez Microchip, des microcontrôleurs 8 bits. Ces microcontrôleurs intègrent toutes les fonctionnalitées nécessaire à notre application (I2C/SPI, USB, MLI, beaucoup de ports I/O disponibles).
Un composant cruciale a du être choisi par la suite. En effet, il est nécessaire de récupérer l'inclinaison du robot (car une fois les premiers livrables fait, nous devons ajouter l'option auto-équilibrage du robot). Pour cela, nous avons opté pour une IMU (Inertial Measurment Unit ou centrale inertielle en français) qui est un composant intégrant au minimum 3 gyromètres et 3 accéléromètres (un pour chaque axe, x, y, z) et parfois 3 magnétomètres (boussole). Ce composant permet de calculer la vitesse angulaire et l'accélération linéaire d'un objet. Le composant est le MPU 9255, fonctionnant en I2C ou en SPI, qui est un composant MEMS, ce qui signifie qu'il est fortement intégré.
2) Etude des bras
a) Carte de commande
La carte de commande des bras a été réalisé par un étudiant de quatrième année pendant les séances de sous traitance. Pour cela il a utilisé le logiciel Proteus, qui est un logiciel de conception de carte électronique.
La carte final est la suivante:
Nous avons utilisé un régulateurs de tension par servomoteurs afin de fournir le courant nécessaire. En effet, chacun consomme jusqu'à 1A, c'est pourquoi il était indispensable d'utiliser autant de régulateur. Cependant, nous avons réalisé une carte relativement petite, sans utilisé de dissipateur thermique, à tort, c'est pourquoi nous avons préféré utiliser un tracoPower en amont afin de fournir le courant nécessaire car sans ce dernier, les régulateurs chauffés beaucoup, ce qui pourrait entraîner une dégradation prématurée des composants (une alternative aurait été d'utiliser des régulateurs à découpage).
b) Software
Concernant la commande des 8 servomoteurs, constituant nos bras, il a été nécessaire d'utilisé le mécanisme des interruptions et le Timer 0 du PIC. En effet, le PIC utilisé ne possède que deux sorties MLI (Modulation par Largeur d'Impulsion), et celle ci ont une période minimale de 10.8ms, ce qui est trop élevé pour la commande des servomoteurs. En effet, nous devons générer des états haut variant de 0.5 à 2.5ms toutes les 20ms afin de balayer les 180° de déplacement des axes des moteurs.
A l'aide d'un analyseur logique, nous avons relevé les chronogramme correspondant aux 8 MLI générées par le PIC.
Comme dit précédemment, nous avons ajouté deux capteurs, un pour chaque bras, permettant de connaitre l'orientation des deux bras. L'étude du MPU 9255 et le calcul des angles est faite à la partie concernant la base du robot.
Concernant la communication utilisé entre le PIC et les capteurs, nous pouvons utilisé le protocole I2C ou la SPI. Les deux ont été essayé, mais ici, seulement la SPI sera montrer. L'avantage que nous avons avec la SPI est la rapidité. En effet, avec l'I2C, la fréquence maximale est de 400kHz, alors que avec la SPI nous pouvons atteindre 1MHz (avec le MPU 9255). De plus, nous avons pu remarqué quelques problèmes avec la communication I2C, parfois, le capteur se déconnecté du PIC.
Avec l'analyseur logique, nous avons relevé un chronogramme qui montre le fonctionnement de la SPI. Dans cet exemple, nous cherchons juste à savoir si le PIC et le MPU 9255 communique bien entre eux, pour ça nous lisons à l'adresse 0x75 du capteur, et si celui ci est bien connecté, et si il est bien configuré en mode SPI, il doit nous renvoyé son adresse qui est 0x73.
La communication utilisé entre le Raspberry Pi et la carte de commande, est la communication USB (Universal Serial Bus) qui sera expliqué dans la partie Communication USB.
c) Réalisation physique des bras
Afin d'obtenir des bras solide, facile à assembler et esthétique, nous les avons réalisé avec une imprimante 3D. Pour cela, un étudiant de quatrième année, a réalisé pendant la sous traitance le dessein de chaque partie constituant les bras. Pour cela il a utilisé SolideWorks?, un logiciel de conception de dessein industriel.
Le résultat est très satisfaisant:
3)Etude de la base
Même si l'objectif principal du projet n'est pas de réaliser un robot auto-équilibré, il nous fallait bien système pour travailler. C'est pourquoi nous avons réalisé notre propre robot. Nous avons choisi tout de même de faire un système à pendule inversé, de cette manière, si nous finissons les première tâches du livrable 1, nous pourrons travailler sur le maintien en équilibre du robot.
a) Etude mathématique de la base mobile (Pendule inversé)
Le robot à concevoir est un robot auto-équilibré, c'est-à-dire que son centre de gravité est au dessus de son axe de rotation. Ce qui introduit donc un déséquilibre permanent du système, et donc, il doit être constamment équilibré par une force extérieure (qui sera ici deux moteurs à courant continu) pour lui permettre de rester en équilibre.
Etude du pendule inversé :
Pour faire une telle étude, il est nécessaire de faire des hypothèses (évidemment des hypothèses valables). Nous ne tiendrons pas contre des frottements entre le sol et le robot, on assimile le corps du robot à une tige de longueur L est de masse M, et on considère son axe de rotation comme étant fixe dans l’espace.
On définit le repère cartésien, avec les composantes suivantes : (x, y, z) qui est le repère fixe.
On définit le repère polaire avec les composantes suivantes : (er, etheta, ez) qui sera utiliser comme le repère du sommet de la tige.
D'après le Principe fondamentale de la dynamique, nous pouvons écrire:
Ce qui montre que plus notre robot sera grand (en hauteur) plus il tombera lentement, ce qui est très intéressant. En effet, l’accélération est inversement proportionnelle à la longueur du pendule.
b) Réalisation physique de la base mobile
Le robot a été conçu en plexiglas, avec trois étage. En effet, de cette façon, nous avons un étage pour chaque cartes (La Raspberry Pi tout en haut, en dessous la carte de commande des bras et finalement la carte de commande des roues. Nous avons rajouté une tige avec deux roues folles permettant la stabilité du robot lorsque nous utilisons le mode manuel (c'est à dire lorsque le robot ne s'auto-équilibre pas).
Finalement, le poids est respecté (<4Kg),
la taille est respecté (< 30cm)
il est transportable facilement.
Cependant, durant le projet, une seconde base nous a été donné par notre client. Cependant, celle-ci ne permet pas l'assemblage de toutes les parties. Nous nous en sommes servi pour travailler sur l'auto-équilibrage.
c) Commande du déplacement du robot
Comme dit précédemment, nous avons choisi d'utiliser deux moteurs à courant continu pour réaliser le déplacement du robot. L'avantage de ce type de moteur c'est qu'il est commandable avec une simple MLI (Modulation par Largeur d'Impulsion). En effet, une des caractéristiques principales de ces moteurs, c'est que la valeur moyenne E (en Volt) est proportionnelle à la vitesse angulaire de rotation du rotor, du flux du champs magnétique créé par l'inducteur à travers une spire (Phi = B * S) et d'une constante K propre au moteur.
Cette commande est relativement facile à réaliser avec un microcontrôleur, cependant, pour obtenir les deux sens de rotation possible des moteurs, il est donc nécessaire de rajouter un composant. Ce composant est un pont en H. Cette structure électronique permet d'inversé le sens du courant dans le moteurs, et donc d'inverser le sens de rotation.
Notre choix c'est porté sur un L298n, de chez STMicroelectronic. Ce composant est conçu principalement pour la commande des charges inductives (moteurs à courant continu). Ce composant supporte jusqu'à une tension d'alimentation de 46V et un courant en pointe de 2A. Cela convient tout à fait à notre application. En effet il était important d'utiliser un composant supportant des courant de cet amplitude du fait des inversion de sens de rotation des moteurs lors de l'auto-équilibrage du robot.
d) Calcul de l'inclinaison du robot
Afin de déterminer l'angle d'inclinaison, il était nécessaire de récupérer l'angle d'inclinaison du robot. Pour cela nous avons choisi d'utiliser une centrale inertielle qui intègre 3 accéléromètres (un sur chaque axe) et 3 gyromètres (un sur chaque axe) et 3 magnétomètres (un sur chaque axe). Dans notre application nous utilisons seulement les mesures de l'accéléromètres et du gyromètres. D'un coté, nous avons une mesure issue de l'accéléromètre qui est en mètre par seconde au carré, qui est extrêmement bruitée. En effet, ce capteur mesure toutes les forces extérieurs agissant sur lui. Et donc toutes les vibrations rendent les mesures très bruitées. C'est pourquoi nous utilisons un filtre passe bas pour lisser les mesures afin de supprimer les hautes fréquences (vibrations). D'un autre coté nous avons le gyromètre qui mesure des vitesses angulaires en mètre par seconde. Pour obtenir la position (donc l'angle) il suffit d'intégrer la mesure. Cependant, en plus du biais propre au gyromètre, une dérive va affecter les mesures à long terme à cause de l'intégration. C'est pourquoi nous utilisons un filtre passe haut afin de ne garder que les hautes fréquences.
Donc nous avons deux mesures avec deux inconvénients, l'accéléromètre est performant à long terme, et relativement lent du au filtrage alors que le gyromètre est performant à court terme à cause de l'effet intégrale qui engendre une dérive de la mesure. La solution a été d'utiliser un filtre complémentaire afin d'obtenir un compromis entre les deux mesures, et donc d'obtenir une valeur suffisamment précise pour notre application.
Schéma de la structure utilisée:
Calcul de l'angle:
Le calcul de l'angle issu de l'accéléromètre est le suivant (simple manipulation de formule trigonométrique):
Theta = Arctan(Ax/Ay)
e) Auto-équilibrage
Une fois les premiers livrables remplis, nous avons réalisé l'auto-équilibrage du robot. Pour cela, nous avons utilisé une régulation classique, le PID. De cette façon nous agissons directement sur la tension à envoyer aux moteurs à courant continu pour maintenir le robot en équilibre.
Une telle régulation peut se représenter comme ceci:
Méthode de réglage du PID:
La première valeur à régler est la valeur du proportionnel. Pour effectuer l'action proportionnel, il suffit de multiplier simplement l'erreur par un gain Kp, et c'est ce gain Kp qu'il faut déterminer. Pour cela, nous avons réalisé des essais successifs afin d'obtenir la meilleur valeur de ce dernier.
L'effet du proportionnel permet d'augmenter le temps de monté, et donc la rapidité du système à atteindre la consigne. Cependant, si le coefficient est trop élevé, cela rend le système oscillant, et peut même diverger.
Une fois le coefficient Kp fixé, nous avons réglé le coefficient Intégral, Ki. Cette fois-ci, seul le coefficient Dérivé est mis à 0. Ce coefficient permet d'annuler l'erreur statique, c'est à dire l'erreur entre la consigne et la mesure. Il est à remarqué, que l'utilisation seule de l'action intégrale ne permet pas de réguler correctement le système. De plus, il est nécessaire de faire attention à la saturation de l'action intégrale. Pour cela il suffit de fixer un seuil afin de ne pas dépasser une valeur limite, car pour réaliser une action dérivé il suffit de faire un addition de tous les échantillons les uns à la suites des autres.
Enfin, nous avons réglé le coefficient Dérivé, Kd. Celui ci permet de compenser les retards, et de limiter les dépassements du système.
4) Etude de la communication USB
Afin de communiquer entre la Raspberry Pi et les deux carte, nous avons choisi d'utiliser le protocole USB (Universal Serial Bus). Le choix de cet communication, plutôt que d'utiliser le port série RS-232 est que celui-ci disparaît de plus en plus. De plus, Microchip fournit un code de base permettant d'utiliser le protocole USB sur certain de leur microcontrôleur.
a) Introduction
Ce protocole permet de faire communiquer deux entités à travers un fils contenant 4 fils : VCC, VDD, D+ et D-. C'est à travers c'est deux fils que transitent les trames.
De plus, il existe plusieurs mode de communications, brièvement, nous avons:
le mode CDC: Communicative Device Class: ce mode permet de connecter plusieurs ordinateur entre eux. Ce mode fonctionne avec un port COM virtuel sur la machine hôte, ce qui permet une communication relativement facile entre deux entités. C'est
ce mode qui a été choisi dans le projet.
le mode HID: Human Interface Device: Ce mode est utilisé pour les souris, les clavier and d'autres périphériques fonctionnant à basse vitesse et avec de basse quantité de données.
ADC: Audio Device Class)
b) Utilisation dans notre application
Ce protocole de communication nous permet de faire communiquer la carte de la base et des bras avec la Raspberry Pi. En effet, depuis la Raspberry Pi, nous pouvons commander l'ensemble du robot.
En effet, nous pouvons commander la base, et passer dans deux mode différents: le mode automatique (mode ou le robot se tient en équilibre tout seul) et e mode manuel (mode ou nous commandons le déplacement du robot).
Par exemple, pour faire avancé le robot à une vitesse de 50% de son rapport cyclique, nous devons envoyer la trame suivante "MA32" ou 32 et la valeur en hexadécimal de 50. Par la suite, cette trame va être décodé par notre microcontrôleur afin d'être interpréter correctement. Pour cela, une fonction permet de convertir la valeur 32 en une valeur décimal, puis envoyé au moteur.
Concernant les bras, nous pouvons commandé chaque servo moteurs constituant les bras indépendamment les uns des autres avec le même principe que pour la base. En plus, nous récupérons aussi les données de l'orientation des deux bras grâce aux centrales inertielles. Pour cela, une fois les différents calculs effectuer pour obtenir la valeur de chaque angle des bras (x, y, z), nous effectuons une troncature de la valeur de l'angle en degrés, puis nous effectuons une conversion en hexadécimal de la valeurs. Nous envoyons une trame toutes les 500ms avec les angles de chaque IMU de la manière suivante:
$X1,Y1,Z1,X2,Y2,Z2\n
Nous avons voulu éviter au maximum d'utiliser des fonctions trop gourmande en temps, c'est pourquoi on a programmer notre propre fonction (sprintf trop longue en terme de temps).
Note d'application
Sujet 1
*Note d'application de Latour Clément*
Sujet 2
note_application_titre_yyy.pdf?
Mis à jour par Anonyme il y a environ 4 ans · 20 révisions