1

Utilisation des données en provenance des codeurs avec un LS7084 ou LS7083

screenshot.22.png

L’information en provenance des codeurs est fournie sur 3 signaux dont 2 réellement utiles (le troisième signal étant déduit par le codeur depuis les 2 premiers). L’utilisation des créneaux fournis par un des signaux permet déjà d’avoir une première information sur l’évolution du cycle moteur. Cependant il est indispensable d’étudier les 2 signaux pour connaitre le sens de rotation du moteur (par simple observation du premier front montant entre le signal A et B).

C’est le rôle du LS7084N (http://www.lsicsi.com/pdfs/Data_Sheets/LS7083N_LS7084N.pdf) de LSICSI qui reçoit en entrée le signal A et B et ressort en sortie deux signaux l’un étant un créneau « mixant » les créneaux des entrées A et B et l’autre une indication sur le sens de rotation des moteurs. Il est de plus possible de paramétrer le mode « mixage » des signaux A et B pour récupérer un coefficient multiplicateur entre x1, x2 et x4 entre le nombre de créneau sur une des voies d’entrées A ou B et la sortie.

Le schéma ci-dessous décrit les différents créneaux de sortie (CLK) suivant le mode de multiplication choisi.

screenshot.21

LS7084N Output

Ainsi, chaque codeur est relié à un LS7084N qui est lui-même relié à 2 entrées numériques de la carte d’asservissement. Chaque CLK est relié sur une entrée Fréquence de la carte d’asservissement et les UP/DN sont reliées sur des entrées numériques de la carte d’asservissement. Le paramétrage du mode est fait par une liaison directe au 12V qui permet de sélectionner le mode x4 en continue.

0

Premiers tours de roue

Voici les images des premiers tours de roue réalisés hier soir par la base roulante. Ca semble un peu bancal car pour l’instant, il n’y a pas d’asservissement et un seul des deux codeurs était connecté. Mais les premiers résultats sont là : on maitrise le nombre de tours de roue là ou le codeur est relié.

La carte d’asservissemement sert de carte d’alimentation à la carte mère dans cet exemple. Cette dernière étant uniquement utilisé ensuite comme réducteur 12V / 5V pour alimenter les codeurs.

Prochaine étape, ranger un peu les cables, faire des branchements plus propres et démarrage des essais d’asservissement !!!

2

Choix de la carte mère

.net

Cette année, l’association s’est enrichie de plusieurs membres expérimentés dans les technologies Microsoft .net.

Pour profiter de ces compétences et nous permettre de les approfondir, nous avons rapidement envisagé d’utiliser ce type de technologie dans l’une de ses versions adaptées à un usage électronique.

Dans ce domaine, deux solutions existent : les cartes Windows CE et celles MicroFramework.

Cartes Windows CE

Exemple de carte Windows CE : FriendlyArm mini 2440

Une carte embarquant Windows CE du genre FriendlyARM Mini2440 ferait l’affaire.

L’intérêt de ce genre de cartes, outre le fait de permettre la programmation avec le Compact Framework .net que je commence à maitriser (c’est un peu mon boulot…), est qu’elles présentent une grande variété d’interfaces (UART, ethernet, Carte SD, USB hote, I2C…). De plus, ce genre de plateforme propose des processeurs puissant (ARM920T de 400MHz dans le cas de la carte ci contre).

L’alimentation de la carte est simplifiée avec une seule alimentation (au lieu du port ATX nécessitant une demie douzaine de tentions d’alimentations différentes utilisé par les cartes mères standard type VIA Epia que nous avons pu utiliser par le passé).

D’un autre coté, cette plateforme impose la présence d’un OS + un framework ce qui implique des pertes de performances dans l’exécution du programme.

Enfin on peut également déplorer que le développement sur compact framework nécessite la version Professionnal de Visual Studio qui, bien que présentant un environnement de travail trés convivial et permettant le debbugage très simplement, est complètement hors budget (compter 1000€ par licence).

Cartes MicroFramework

Depuis quelques années, Microsoft s’est lancé dans un framework orienté pour l’électronique : le MicroFramework. Il est depuis devenu open source et peut être développé dans la version gratuite de Visual studio : Visual Studio Express. Ce « Framework » est en fait un CLR qui tourne sur la carte et execute le code managé, remplacant à la fois l’OS et le framework. Celui-ci est bien plus limité que le .net Framework classique mais offre un panel trés large de possibilités (gestion des entrées/sorties, Multi-threading, gestion de l’affichage, debuggage USB, nombreux driver de communication…). De plus, les cartes sont souvent moins cher que celles sous Windows CE !

Parmis les constructeurs de ce type de carte, on trouve Device Solution avec ses cartes Meridian/P ou Tahoe II, des cartes complètes proposant de nombreuses entrées/sorties, plusieurs port de communication (UART, I2C, SPI…) le tout alimenté en 5V.

D’autre part, on trouve un autre constructeur, GHI Electronic, qui sur son site Tiny CLR propose plusieurs cartes très intéressantes à partir de 35$ la carte pour la FEZ Panda, ainsi que de nombreux periphériques adaptés et leur drivers associés (et leurs sources !). Ces cartes sont pour la plupart plus petites que celles de Device Solution avec un processeur de 72Mhz permettant la communication grâce à 4 UART, un SPI, un I2C et deux CAN. Enfin, elles peuvent être alimentées avec une tension entre 5V et 12V.

Le choix

Dans le robot, nos contraintes sont les suivantes :

Carte FEZ Domino

  • Utilisation de l’I2C pour la communication avec nos divers périphériques et cartes déjà en notre possession (carte boussole, de contrôle de plusieurs servo-moteur et cartes à base de PIC)
  • Alimentation idéalement en 12V (directement sur les batteries) ou éventuellement en 5V (régulé par une autre carte)
  • Utilisation d’un port CAN pour communication avec la carte d’asservissement (offerte par Manitou et qui fera l’objet d’un prochain post)
  • Autant d’entrées/sorties que possible : même si nous aurons de toute facon d’autres cartes pour gérer certains actionneurs et capteurs du robot, il est bon de les limiter au maximum.
  • Si possible, suffisamment d’espace de stockage pour effectuer des logs.
  • Un prix aussi raisonnable que possible bien sur!

Au final, notre choix se fait donc sur la carte FEZ Domino, qui répond à tous les critères énoncés ci-dessus.

Vous aurez donc bientôt des nouvelles sur l’utilisation de cette carte ! En attendant, je vous encourage vivement à aller voir le post de Pierre Cauchois sur le sujet.

FriendlyARM Mini2440

0

Commande de moteur cc

moteur-courant-continu

Pour commander les moteurs sur notre robot, nous avons une carte dédiée à cette tache. Ainsi en cas de surchauffe, le remplacement de cette carte se fait rapidement et n’implique pas les carte plus grosses qui vont prendre les décisions de déplacement.

Dans une premier temps voici le schéma électrique basé sur un L297. Ce composant est habituellement employé pour faire de la commande sur des moteurs pas à pas. Il est donc souvent associé au L298. Le brochage qui suit permet de controler indépendemment en vitesse et en sens deux moteurs à courant continu.

La carte ne comporte pas d’élément très compliqués. Voici le tableau des signaux que vous devez envoyer pour commander vos moteurs CC:

Enable Input 1 Input 2 Moteur
0 X X Roue Libre
1 0 0 Blocage
1 0 1 Sens 1
1 1 0 Sens 2
1 1 1 Bloquage

Voici le typon que nous avons réalisé. Il est en simple couche. Nous posterons plus tard la suite de cet article pour détailler les composants a assembler sur ce typon. Vous pouvez également télécharger tous les typons qui sont proposés sur ce site dans la rubrique téléchargement.

0

Boussole CMP03

_BOUSSOLE_CMP03

La boussole est un élément très important pour le robot. C’est elle qui va guider le châssis et lui donner la direction globale à atteindre. Les télémètres indiqueront les obstacles à éviter, et le robot risque de devoir faire des détours. La boussole lui redira alors la bonne direction à prendre dès l’obstacle franchit.

Il y a deux méthodes pour obtenir la position :

- A travers un signal PWM directement sur l’une des pins du capteur - En faisant une requête i2c.

La seconde possibilité à été retenue afin de permettre à n’importe quelle carte d’avoir accès à ces informations. Elle est plus longue à mettre en place mais nous permettra un plus large choix de possibilités.

C’est pourquoi, dans un premier temps, nous utilisons la PWM pour orienter le Robot. Il suffit de connecter la broche sur un port analogique du microcontrôleur et l’on obtient une tension fonction de la position.

Voici le schéma de la boussole que nous utilisons. Il faut noter que certaines broches sont à configurer en fonction des besoins. Par exemple la broche 7 doit être reliée à la masse car nous sommes en France et fonctionnons en 50Hz.

La broche 6 permet de calibrer notre module. Il est aussi possible de le faire via l’I2C en jouant avec le registre 15. Cependant, nous n’avons pas besoin de calibrer notre capteur car nous fonctionnons en positionnement relatif et non pas absolu. De plus, au démarrage, le robot n’as aucune idée de l’orientation du Nord magnétique. Mais la possibilité reste présente pour d’autres applications éventuelles…

Pages ... 1 2 3 4