juil

27

Carte CPLD

By Inounx

La carte CPLD qui gère le décodage des signaux des codeurs optiques fixés sur les moteurs, a été développée par un ami (Mr Béber pour ne pas le nommer) dans le but de décoder les signaux en quadrature des encodeurs, et de compter les impulsions. Elle est basée sur un CPLD Xilinx XC95144XL. Je sais qu’il existe des composants tout fait qui réalisent ce décodage mais je préférais avoir ma propre carte pour apprendre à bien utiliser un cpld en conditions réelles. Un autre avantage est le fait de pouvoir coder une liaison série entre l’arduino et cette carte au lieu d’une liaison parallèle très couteuse en pattes coté arduino (il y en a très peu de disponibles, c’est un atmega168 de 28 broches PDIP)

Voici le principe de fonctionnement :

Principe carte CPLD

Principe carte CPLD

La structure interne

Chaque codeur est relié au CPLD qui viens décoder les signaux en quadrature. Une fois décodés ces signaux sont comptés avec un compteur 12 bits (pourquoi 12 bits ? parce que c’est la taille max qui peut rentrer dans ce CPLD) dont la valeur peut être récupérée par la MAE (Machine à Etats) qui gère la communication série. Il y a aussi un registre 8 bits de sortie, permettant de contrôler 8 sorties numériques au besoin. Tout le système de configuration qui est géré par la boite noire qu’est la MAE, fonctionne sur le principe de registres adressés (pour acceder à un registre on spécifie son adresse) dans lesquels on vient écrite les valeurs de configuration. Il y a actuellement 4 registres :

  • TCON : Timer configuration. Permet d’activer ou désactiver les timers T0 et T1, ainsi que de choisir si une RAZ du timer est faite sur lecture de sa valeur.
  • R1 : Registre de sortie. Permet d’écrire de controler 8 bits en sortie sur un port du CPLD.
  • T0 : Accès en lecture / écriture à la valeur du Compteur 0
  • T1 : Accès en lecture  / écriture à la valeur du Compteur 1

Communication Série

La communication série est de type maître / esclave pour plus de simplicité : le microcontroleur peut être le seul initiateur d’une communication entre lui est le CPLD. Les signaux de contrôle de la communication (SYNCB et CLOCK) sont exclusivement contrôlés par le microcontroleur. Le principe de communication est le suivant : une première trame de 4 bits est envoyée au CPLD pour spécifier l’adresse du registre (3bits) auquel on veut accéder ainsi que le mode lecture ou écriture (1bit). En suivant, une trame de 12bit est envoyée dans le cas d’une écriture, ou lue dans le cas d’une lecture. Le microcontroleur contrôle l’horloge qui séquence la communication série. Au total, vu mon implémentation une lecture ou une écriture dans un registre prend environ 12us. Pendant chaque trame, le signal SYNCB doit être au niveau bas pour indiquer qu’une communication est en cours. Il est au niveau haut au repos. Cela permet d’éviter d’attraper tout les parasites qui passent sur la ligne quand il n’y a pas de communication et d’être certain de la synchronisation du début de transmission entre le CPLD et le microcontroleur.

Voici une image montrant un exemple d’écriture dans le CPLD :

Communication CPLD

Communication CPLD

avr

4

Carte driver moteur

By Inounx

Je n’avais pas encore parlé de la carte driver moteur que j’utilise sur Robert. Cette carte s’articule autour d’un double pont en H intégré L298. Elle rassemble 2 connecteurs moteur, 1 connecteur d’alimentation (5v pour la logique de commande et 7.2V pour l’alimentation des moteurs), et un 1 connecteur HE10 10broches pour la communication avec l’arduino. Les diodes de roue libre sont des diodes rapides BYW100. Le schéma est disponible ici au format Eagle 5.4 : cmd_moteur.sch

Note : Les résistances R1 et R2 ne sont pas obligatoires. Elles peuvent être remplacées par un fil. Elle permettent de mesurer le courant passant dans les pont en H en regardant la tension à leur bornes mais ça ne fonctionne pas très bien.

cmd_moteur_schemaLe typon est disponible ici au format Eagle 5.4 :  cmd_moteurs.brd cmd_moteur_typon Et un petit aperçu de la carte terminée : driver_moteur_small2

avr

4

Les premiers pas de Robert en vidéo

By Inounx

Voici une petite vidéo montrant l’évolution de Robert en milieu « hostile ». A ce stade la gestion des collisions est gérée par l’arduino grâce aux 3 capteurs ultrason. La commande fournie aux moteurs est proportionnelle à la distance à l’obstacle pour essayer d’avoir un comportement assez intéressant même si ça reste basique.

mar

27

Des nouvelles cartes pour Robert

By Inounx

Cela fait quelques temps que je n’avais pas mis de nouvelles sur l’avancement de Robert, à cause de la surcharge de travail due aux exams de fin d’année. Départ en stage d’ici une semaine, direction Paris chez Gostai puis Montpellier chez Wany Robotics. En attendant je me rattrape avec ce billet :)

Quelques nouvelles cartes sont arrivées pour rendre Robert plus propre et finalisé au niveau de l’étage « électronique ». J’ai aussi reçu les supports pour capteurs Ultrason que j’avais commandé chez EasyRobotics.

Arduino Shield

Arduino Shield

Arduino Shield

Je me suis fait une petite carte Arduino Shield qui viens donc s’enficher au dessus de l’Arduino afin de pouvoir tout connecter  facilement.
Il y a donc 5 connecteurs pour brancher des capteurs US SRF05 (Robert n’est équipé que de 3 capteurs pour le moment mais une évolution future est prévue). Cette carte dispose aussi de 2 connecteurs 5v pour récupérer l’alimentation de la carte Arduino si besoin, mais aussi d’un connecteur pour la liaison série avec l’étage « décisionnel », d’un connecteur Two Wire Interface (TWI) et d’un connecteur HE10 pour la liaison avec la carte Driver moteur. Un pont diviseur de tension permet aussi de mesurer facilement la tension batterie. Le typon de cette carte est disponible ici (Format .brd Eagle 5.4) : robert_arduino_shield_typon

Typon arduino shield

Carte alimentation

C’est une carte toute simple qui fourni 5 connecteurs Vbat et 3 connecteurs 5V. Quelques condensateurs ont été ajoutés pour filtrer et faire office de réserve d’énergie.

Carte d'alimentation

Carte d'alimentation

Le typon (Format .brd Eagle 5.4) : alim.brd

Typon carte alimentation

Typon carte alimentation

Et voici un petit aperçu de Robert cablé avec ces nouvelles cartes et son nouveau support pour les 3 capteurs US :

Robert avec support 3 capteurs US

Robert avec support 3 capteurs US

jan

23

Choix des capteurs et des moteurs

By Inounx

Pendant que nous attendions  que le chassis soit fabriqué nous avons réfléchi aux capteurs à utiliser. Dans l’idée nous voulions mettre en place des capteurs simples à mettre en oeuvre dans un premier temps délivrant une information directe comme une distance, une tension… etc. Les objectifs de la base du robot  étant d’avoir un asservissement correct pour les moteurs et de pouvoir prendre quelques mesures de distance pour commencer à faire « joujou ».

Les capteurs de distance

Notre attention s’est essentiellement portée sur deux types de technologies : l’Infrarouge et l’Ultrason. Chacune de ces technologies ayant ses avantages et ses inconvénients. Coté Infrarouge les avantages sont la rapidité de la mesure et le faible angle de détection (qui peut aussi devenir un inconvénient si l’on veut balayer un large espace avec des capteurs fixes.), en revanche ils sont sensibles à l’éclairement et à la couleur des objets, même si on arrive maintenant à avoir des capteurs qui permettent à peu près de ne pas en tenir compte. Il ont aussi une caractéristique de réponse pas forcément linéaire, ce qui rends la conversion de la mesure plus difficile.

Coté ultrasons on dispose d’un grand angle de détection, généralement une plus longue portée que les infrarouges et d’une caractéristique de réponse linéaire ce qui simplifie grandement l’acquisition de l’information. Par contre ces capteurs sont sensibles aux sons, enfin aux sources d’ultrasons (normal me direz vous), ils sont plus lents (eh oui le son se déplace moins vite que la lumière…), d’autant plus qu’il faut respecter un temps d’attente entre chaque mesure, pour que le signal sonore ait fini de faire des « rebonds » et ne vienne pas perturber la mesure suivante.

Pour nos tests, nous avons commandé un capteur de chaque type : un télémètre à ultrason SRF05 et un capteur de distance à infrarouge GP2Y0A02YK.

Télémètre US SRF05

Télémètre US SRF05

Caractéristiques du télémètre US SRF05 :

  • Alimentation : 5v
  • Consommation : 4mA nominal
  • Portée : 1cm à 4m
  • Déclenchement : impulsion TTL positive de 10µs
  • Signal écho : impulsion TTL positive de durée proportionnelle à la distance
Cpateur de distance Sharp

Capteur de distance Sharp

Caractéristiques du capteur de distance Sharp :

  • Alimentation : 5v
  • Portée : 20cm à 1.5m
  • Sortie analogique 0-5v

Au vu  de la simplicité de mise en oeuvre des télémètres ultrasons nous avons décidé d’opter pour 3 capteur US à l’avant du robot disposés à 45°.

L’odométrie

Coté déplacement du robot nous avons besoin de connaître avec un peu de précision les déplacements « réels » du robot. Avant de commencer à mettre en oeuvre un système de vision ou autre tout aussi complexe nous avons opté pour un système classique d’odométrie sur les moteurs avec un encodeur optique en quadrature. Les moteurs que nous avons choisis sont les suivants :

Moteur Lynxmotion GHM03

  • Tension nominale : 7.2V
  • Vitesse à vide : 291 tr/min
  • Rapport de réduction :  30:1
  • Couple de blocage : 3.9 Kg.cm
  • Courrant à vide : 150 mA environ
  • Courrant axe bloqué : 3.80 A
Motoréducteur Lynxmotion GHM03

Motoréducteur Lynxmotion GHM03

Nous avons choisi ce moteur pour deux raisons : d’une part il a une vitesse importante qui permettra au robot d’être réactif, tout en ayant un couple de blocage assez élevé. D’autre part il dispose d’un axe à l’arrière du moteur spécialement pour accueillir un encodeur. Nous avons donc, en même temps que les moteurs, commandé des encodeurs optiques en quadrature Lynxmotion.

Encodeurs en quadrature Lynxmotion QME01

  • Résolution : 100 pas par tour
  • Résolution avec quadrature : 400 pas par tour
  • Fréquence : jusqu’à 30khz
Encodeur rotatif Lynxmotion

Encodeur rotatif Lynxmotion

Ces codeurs permettrons une première approche de positionnement par odométrie avec un asservissement PID.

Voici une image résumant le positionnement des capteurs, des moteurs et des encodeurs :

robot_capteurs

jan

19

ROBERT : ROBot d’Exploration et de Recherche Technologique

By Inounx

Bonjour à tous,

je fais ce premier post sur ce blog pour vous parler d’un projet en cours depuis quelques temps déjà : ROBERT. Robert c’est un petit robot qui a pour but de mettre en oeuvre différentes techniques utilisées en robotique comme l’asservissement, la vision, la cartographie (déplacement en environnement connu / inconnu) entres autres. Au départ nous sommes deux étudiants, Yoann Sculo alias Aquanum et moi même, Marc Laval aussi connu sous le pseudo Inounx. Tout deux passionnés de Robotique nous nous sommes rencontrés alors qu’il effectuait son stage de fin d’études à Toulouse au CNES. Ayant chacun déjà eu l’idée de construire un robot digne de ce nom, il était évident qu’au vu des possibilités et de l’intérêt de mener à bien un projet tel que celui-ci à deux, nous avons été tout de suite tenté :) . C’est comme cela que petit à petit Robert est né, un nom amusant pour un projet qui se veut sans prise de tête, just for fun. D’un coté plus technique nous voulions chacun un robot à nous, nous avons donc décidé de partir d’une base mécanique commune (chassis, moteurs, capteurs) pour ensuite le faire évoluer suivant nos envies. Par exemple nous n’avons pas les mêmes cartes de contrôle, Aquanum disposant d’une FoxBoard G20 et moi d’une Roboard RB-100. Par la suite, d’autres personnes sont venues se rajouter au projet et c’est aussi pour cela que nous avons gardé le principe d’une base commune. Cela permet à d’autres personnes de travailler chacune sur des parties différentes du robot et pouvoir mettre en commun facilement. Une autre raison pour laquelle nous avons commencé ce projet, est aussi de promouvoir la robotique en France. En effet même si de plus en plus la robotique tends à se démocratiser, on voit assez peu de personnes prêtes à se « mettre les mains dans le camboui » par peur d’une trop grande complexité ou manque de compétence. Robert serait donc l’occasion de fournir une base mécanique de robot, avec toute une architecture fonctionnelle permettant de modifier son comportement facilement grâce au code source fourni.

Pour des soucis de simplicité et de robustesse nous avons fait faire notre chassis sur mesure par Easy Robotics. En voici une des premières représentation 3D sous solidworks :

Modélisation 3D du châssis

N’étant pas des amateurs de mécanique, cela nous a permis d’obtenir facilement un bon châssis en aluminium. Si vous aussi vous avez des pièces alu à faire fabriquer je vous recommande Easy Robotics. Nicolas, le gérant est vraiment sympathique et très à l’écoute des besoins des clients. Il fait des pièces de très bonne qualité pour un prix défiant toute concurrence. Voici un aperçu du chassis nu :

Châssis nu monté

Châssis nu monté

Ainsi qu’une fois monté avec des moteurs (temporaires les bons moteurs étaient en commande au moment ou j’ai pris la photo) et une plateforme :

Châssis monté avec moteurs temporaires et plateforme

Châssis monté avec moteurs temporaires et plateforme

Notre base étant prête nous avons pu commencer à réfléchir à l’électronique embarquée sur le robot.