FPGA et roues codeuses

Vidéo HD

Présentation

Aperçu

Le sujet propose de réaliser un système simple sur cible FPGA permettant de :

• Lire et décoder une ou plusieurs roues codeuses ;
• Asservir un ou plusieurs moteurs, soit pas-à-pas soir à courant continu.

La cible visée sera un FPGA de chez Xilinx (carte de développement). En parallèle, une carte d'interface de puissance sera réalisée (interface entre FPGA et moteurs).

Cahier des charges étendu

Description

Ce projet s'inscrit dans le cadre de la réalisation d'un robot mobile autonome, capable de se déplacer avec précision grâce au retour de ses capteurs. La propulsion du robot est effectuée par deux moteurs à courant-continu, chacun couplé à une roue motrice tandis que le retour sur le déplacement est lui obtenu par deux codeurs à quadratures de phases couplés à des roues de mesures. Il est aussi possible de récupérer l'information de vitesse des moteurs grâce à des dynamos tachymétriques ou par le biais d'autres codeurs à quadratures de phases directement couplés au moteur.

Pour approcher ce fonctionnement, on travaillera initialement sur un seul codeur et un seul moteur. L'objectif est d'interpréter les signaux en quadratures de phases avec un FPGA et d'effectuer à partir de cette information un asservissement en vitesse du moteur.

Si ce fonctionnement de base est obtenu suffisamment tôt, des améliorations sont envisageables, comme par exemple :

• Commande et mesure pour plusieurs moteurs et codeurs ;
• Pilotage du FPGA par un protocole de communication (série, CAN, I2C, à déterminer …) ;
• Asservissement polaire (cas d'un déplacement de robot) ;
• Calcul d'odométrie.

La liste est non exhaustive.

Travail à réaliser 

• FPGA :
  • Récupération des signaux codeurs ;
  • Interprétation des signaux et comptage ;
  • Écriture de la mesure sur un bus ;
  • Lecture de la consigne d'asservissement ;
  • Asservissement et génération de la consigne moteur.

• Électronique de puissance :
  • Carte de conversion consigne (signaux logiques) en commande (tension avec puissance) ;
  • Éventuelle protection en tension et en courant de la carte.

Caractéristiques 

Les moteurs utilisés peuvent être de deux types différents :

• Graupner Speed 720 BB Torque.

Alimenté en 0-12V avec des courants max de 3A et des courants moyens de 750mA.

• Faulhaber 3557K024CS.

Alimenté en 0-24V avec des courants max de 1,1A et des courants moyens de 65mA.

Ces deux types de moteurs représentent des cas très usités, il conviendra donc d'avoir une carte de puissance permettant d'assumer ces deux configurations.

Suivi des séances

Semaine 1 (5/02)

Élaboration du cahier des charges étendu. Réflexion sur les différentes étapes à réaliser pour arriver au bout du projet.

Semaine 2 (12/02)

Nous commençons notre programmation sur le logiciel Altium afin d'utiliser le FPGA de la nanoboard. Le premier module sera un module de génération de PWM (Pulse Width Modulation) afin de pouvoir contrôler les moteurs au travers de la carte de puissance. Ce module est paramétré par une valeur codée sur 1 octet (entre 0 et 255) qui permet de changer la valeur du rapport cyclique.

• Si on a 0, rapport cyclique = 0% , sortie = 0V (état bas)
• Si on a 127, rapport cyclique = 50% , sortie = 50% état haut et 50% état bas
• Si on a 255, rapport cyclique = 100%, sortie = 3V3 (état haut)

Nous commençons aussi la réflexion sur les méthodes de décodage de signaux de quadratures de phases. Les résultats sont peu concluant, la solution trouvée test chaque configuration possible des signaux avant de traduire la configuration en un comptage ou un décomptage. La résolution est limité au nombre de pas par tours du codeur.

Semaine 3 (19/02)

Fin du codage de la PWM. Ci dessous un image montrant une PWM de rapport cyclique 33% donc avec 0x3F en entrée.

Dans le cadre du projet et du développement du robot de la coupe de France 2014, nous avons besoin d'un module de communication série afin de pourvoir avoir un dialogue entre le FPGA et d'autres contrôleurs (Raspberry Pi, beagleBone...).

Dans un premier temps nous cherchons une IP(Intellectual Property) de communication serie RS232. Et nous testons les différents modules trouvés.

Afin de pouvoir se partager les codes sources et faire un travail collaboratif de manière efficace, nous avons mis en place un repository git sur GitHub. De cette manière tous nos codes seront versionnés et nous pourrons revenir à des versions précédente en cas de problème.

Après une importante tâche de documentation, il s'avère que les composants électroniques du commerces comptent chaque fronts des deux signaux en quadratures de phases, augmentant ainsi la résolution du comptage par 4 et facilitant apparemment le raisonnement. En étudiant la situation sous forme logique (table de vérité, tableau de karnaugh), nous trouvons une solution à base de quelques ou exclusif.

Semaine 4 (26/02)

Test de différents modules mais les résultats ne sont pas concluants. Les IP trouvées sont des très lourds et difficiles à mettre en place. Pour les besoins de notre projet nous avons voulons un programme assez simple qui fais juste une communication RS232 sans correction d'erreurs. C'est pourquoi nous décidons finalement de coder nous même le module.

La solution développée sur papier pour le décodage des signaux est mis en place sous Altium, on obtient un comptage/décomptage conforme, mais un tour ne correspond pas exactement à 1024 * 4 pas.

Semaine 5 (05/03)

Afin de s'affranchir d'Altium et de la nanoboard nous décidons de passer sur le logiciel ISE de Xilink. Son avantage est que nous allons pouvoir passer sur une carte de développement différente (la starter board ) et nous pourrons aussi programmer avec la prochaine carte de développement (Spartan-6 LX9 MicroBoard) qui sera commandée prochainement.

Le passage sous Xilink implique la programmation d'un fichier de contraintes afin d'indiquer au logiciel où connecter physiquement nos entrées sorties déclarées dans le programme. Ce fichier sera le seul à changer si l'on veut changer de FPGA car un code VHDL est portable et ne dépends pas du FPGA.

Nous avons donc pris en main le nouveau logiciel et programmer notre premier fichier de contrainte afin de pouvoir essayer notre module de PWM sur la nouvelle carte.

Les problèmes de comptage de la semaine précédente sont identifiés, lors du temps de monté des signaux en quadratures, le FPGA interprète différents niveau de tensions (haut,bas) à cause d'un bruit présent sur le signal. C'est un phénomène similaires aux "rebonds" que l'on trouverait sur un bouton poussoir. Une solution à base de lissage est essayée, ce n'est pas concluant.

Semaine 6 (12/03)

Début du codage de la partie réception du module série. Celui-ci sera composé de trois fichiers :

• le fichier de réception série : serial_rx
• le fichier d'envoi série : serial_tx
• le fichier de gestion des deux autres fichiers : serial_module, c'est le fichier principal du module, c'est dans celui-là que l'on va instancier dans deux composants serial_rx et serial_tx.

Réception d'une carte de développement FPGA (Spartan-6 LX9 MicroBoard), c'est celle là qui sera intégrée au robot. Programmation du fichier de contraintes et test de cette carte avec un programme simple (allumage d'une LED) afin de vérifier son fonctionnement.

Pour enfin résoudre le problème d'inexactitude du comptage, le problème des "rebonds", nous utilisons un module "debouncer", qui vérifie l’établissement du signal pendant plusieurs fronts d'horloge. Ce module a été développé par Mickael Coronado, Ingénieur Electronique Analogique / Numérique (Spécialiste FPGA) et Dirigeant (entreprise Inodesign).

Semaine 7 (19/03)

Après quelques difficultés de programmation dû à l'appréhension du VHDL, le module de réception série est fonctionnel. Lorsqu'on lui envoi une donnée grâce à minicom, il l'affiche le code ASCII sur des leds.

Sur l'image suivante, nous avons envoyé le caractère 'a' (code ASCII : 0x97) et l'on voit que l'affichage de 'a' sur les leds fonctionne correctement

Début du code d'émission série.

Début du code et du raisonnement de l'asservissement d'un moteur. Assemblage des modules PWM, debouncer, décodeur à quadrature dans un module reprenant toute l'application.

Semaine 8 (26/03)

Fin du code d'émission série, le FPGA est capable d'envoyer une donnée venant des switch de la carte(8 bits) et l'affichage se fait sur minicom. Par exemple si on envoi 98 en hexadecimal (0110 0010), nous verrons 'b' s'afficher sur minicom car 0x98 correspond au code ASCII du caractère 'b'.

Début de la programmation du module général de la communication série.

Un pilotage d'un moteur à courant continu en vitesse est maintenant possible avec un codeur rotatif.

Semaine 9 (2/04)

Le module de communication série est entièrement fonctionnel, il peut donc être intégré dans n'importe quelle programme VHDL, pour cela il faut le déclarer en tant que composant dans son programme et faire les map des ports nécessaires.

Ce module permet de gérer l'envoi et la réception facilement, au sein d'un programme.

Afin de faciliter l'accès aux différents paramètres d'asservissement et ainsi pouvoir les lires ou les changer, nous décidons de créer un module de mémoire. Celui-ci sera un registre de grande taille dans lequel le module d'asservissement mais aussi un ordinateur comme un Raspberry (par le biais de la communication série) pourra aller lire/écrire.

Valentin est partit pour la semaine complète à Magdebourg (Allemagne) pour une participation à l'Open German Robocup, une pré-coupe de la Robocup, compétition internationale de robotique. Il y a donc eu une interruption logique de la progression sur son travail.

Semaine 10 (9/04)

Début de la programmation du module prenant en charge le composant série et le registre avec le protocole série d'accès aux données.

Le module du registre est relativement simple à coder puisqu'il s'agit de déclarer un grand registre et d'y faire des alias afin d'avoir un accès simplifié.

Test de communication entre le port série et le registre. Pour cela on a créé un module instanciant les composants serial_module et register_module. Ce module va écouter le port série et si une donnée arrive et correspond à une valeur particulière, il écrira dans le registre la valeur en question. Puis, il ira chercher la valeur écrite dans le registre afin de la renvoyer et de vérifier que la donnée du registre correspond à la donnée envoyée.

Maintenant, nous voulons modifier ce module afin qu'il puisse aller écrire au bon endroit dans le registre. Nous allons donc créer un protocole d'envoi des données, de cette manière suivant l'adresse et la donnée reçue nous pourrons mettre à jour le registre mais aussi renvoyer une valeur du registre.

L'ordinateur connecté au FPGA pourra donc récupérer les valeurs des asservissement et de déplacement. Il pourra aussi modifier ces valeurs afin de donner des ordres au robot (exemple : avancer à une vitesse particulière).

Le protocole est le suivant :

• Premier octet, initialisation : 0x00
• Deuxième octet, ordre :
  • 0x01 : lecture
  • 0x02 : écriture
• Troisième octet, adresse : entre 0x00 et 0x17 (24 adresses possibles)
• Quatrième octet, données : entre 0x00 et 0xFF (en cas de lecture 0x55)
• Cinquième octet, fin : 0xFF

Le FPGA n'aura jamais à demander d'informations au Raspberry par conséquent, lorsqu'il y aura une demande de lecture, le FPGA renverra directement la valeur demandée sans utilisation de protocole particulier.

Semaine 11 (16/04)

On a continué à programmer le protocole, des difficultés ont été rencontrées dans l'instanciation et le mappage des différentes entrées sorties afin d'utiliser correctement les modules à inclure (serial_module et register_module). Ces difficultés sont dues au faite que c'est la première fois où l'on fait un mappage complet prenant en compte deux composants annexes. La programmation n'est aujourd'hui (15/04/2014) pas encore fini du à un retard dans les phases de tests, il sera prochainement finalisé en vue d'une implantation dans un module principal de gestion du déplacement du robot qui sera programmé dans le FPGA du robot.

A venir

Création d'un programme C sur Raspberry afin de faire des échanges de données avec le FPGA et création de l'intelligence du robot.

Descriptif technique

Carte de puissance

La carte de puissance permet de connecter 2 moteurs entre 12 et 55V consommant jusqu'à 3A grâce à deux ponts en H (LMD18200). Ces moteurs seront contrôlés par une modulation par largeur d'impulsion (PWM).

Schéma électrique

PCB

Communication série

La communication fonctionne à une vitesse fixée dans le programme, par défaut à 9600 bauds. Elle est 8N1 c'est à dire 8 bits de données, pas de parité et 1 bit de stop. Elle peut être implantée sur n'importe qu'elle FPGA car elle n'utilise aucune librairie propre à un constructeur.

Registre mémoire

Le registre mémoire est un registre de grande taille sur lequel on va lire et écrire des données de différentes tailles.

Asservissement

Il peut être intéressant de réaliser un asservissement polaire d'un robot (en angle et en distance) en utilisant deux moteurs de propulsions, de la mesure sur les moteurs pour une boucle d'asservissement de vitesse et une mesure sur deux roues libres qui suivent le déplacement. C'est une réalisation plutôt compliquée, mais les briques principales sont déjà prêtes.

Rapport

Vous pouvez accéder au rapport du projet en suivant ce lien : Rapport du projet