FPGA et roues codeuses

Work In Progress

Cette page est en cours de rédaction et le restera tout le long du projet. Elle sera mise à jour régulièrement (lors des séances de travail).
La version finale sera disponible le 16 avr. 2014.

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)

Codage d'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)

Semaine 3 (19/02)

Fin du codage de la PWM.

//Image venant de l'analyseur logique

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.

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 de coder nous même le module.

Semaine 5 (05/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.

Semaine 6 (12/03)

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.

//Photo de la carte qui affichele code ascii d'un caractère envoyé, photo du minicom

//photo de la trame qui a circulée

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

Semaine 7 (19/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. //Photo de l'affichage de la donnée sur minicom (en hexa) et des switch

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

Semaine 8 (26/03)

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.

Semaine 9 (2/04)

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
• 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.

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 30V consommant jusqu'à 2A. Ces moteurs seront contrôlés par une modulation par largeur d'impulsion (PWM).

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.