0

Le multi-tâche

Aujourd’hui, un mot sur la structure général de nos programmes pour robot (coté Asservissement et intelligence, pour le robot métalique).

En général, le principe d’un logiciel pour robot est construit sur la base d’une machine à état sur le modèle :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public static void Main()

{
// Initialisation du système
Ecran.Init();
Capteur.Init();
// Etc.

while (true)
{
switch (etatActuel)
{
case etat.AttenteJack:
// traitement
break;
case etat.Demarrage:
// traitement
break;
// Etc.
}
}
}

Les limites de ce système est qu’il se bloque à chaque étape du traitement. De plus, on est là sur un fonctionnement très séquentiel alors que certains traitements peuvent être fait en parallèle (affichage sur un écran, récupération de l’état des capteurs, calcul des objectifs du robot…)

Notre approche est un peu différente : nous avons mis en place (déjà l’an dernier avec succès) un système multi-tâche. L’équipe Pobot a déjà fait un post à ce sujet, voilà notre approche en C#.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public static void Main()

{
// Initialisation du système
Ecran.Init();
Capteurs.Init();
// Etc.

while (true)
{
ComPort.Process();
Capteurs.Process();
Ecran.Process();
Objectif.Process();
// Etc.
}
}

Comme on peut le voir, chaque élément du robot (Capteur, communication, etc.) est appelé systématiquement à chaque boucle. Ainsi, chacun des traitements doit évaluer l’état du robot (capteurs, temps, position…) et entraîner ou non une nouvelle action. … Lire la suite

1

Asservissement.net (part. 2)

Nous avons déjà vu la base de notre asservissement en .net

Voici maintenant la suite : comment intégrer ce PID dans le cadre de notre Robot, avec un asservissement en distance et en rotation.

Notre code de PID utilise des delegates pour passer les différentes valeurs et renvoyer celles de sortie. Il y a donc 6 fonctions à définir (3 par PID).

Les deux premières concernent la récupération des valeurs réelle obtenue en lisant les codeurs. Dans notre cas, nous utilisons des composants nommés LS7366 qui, de manière autonome, récupère les pas renvoyés par les codeurs. Il suffit ensuite de les interroger par SPI pour connaitre l’état des codeurs. Ce composant s’occupe de filtrer les pas dus à la vibration du robot et prend en compte correctement le sens de rotation des moteurs. Nous ferons sans doute un article à son sujet (car il le mérite).
Pour en revenir à nos deux fonctions, elles renvoient pour l’avance la moyenne du codeur droit et gauche pour l’avance et la différence entre les deux pour la rotation.

… Lire la suite

2

Asservissement.net

Comme l’a dit précédemment PAC, cette année, pour le robot métallique, tout passe par du .net. Ou plus précisément en microframework.

Tout passer en .net, ça passe également par une migration de l’asservissement en .net. A première vue, cela peut paraître dangereux, le microFramework n’étant pas un OS temps réel, cependant notre expérience positive de l’an dernier sur la partie IA, capteurs et actionneurs nous a pousser à tenter l’asservissement.

Voici déjà en introduction une petite vidéo de ce que nous avons déjà réussi à obtenir (il reste à régler les PID mais c’est un bon début).

Je passe tous les concepts classique sur les PID de robot que l’on trouve très bien présentés sur d’autres site comme le club elekRCVA ou ce très complet ppt également de RCVA. Mon objectif est de faire un asservissement en polaire donc avec un PID pour l’angle et un pour l’avance.

Pour point de départ, nous sommes partit de ce code trouvé sur codeprojet.net : http://www.codeproject.com/Articles/49548/Industrial-NET-PID-Controllers

C’était un bon point de départ avec tout de même quelques défauts (boucle infinie, tests bizares autour du terme I…)

Dans les bons points, on note l’utilisation de delegate (pointeurs sur fonction) pour passer les valeurs d’entrée et de sortie, ainsi on peut utiliser une même classe pour plusieurs PID (dans notre cas, un polaire et un en distance).

… Lire la suite

0

Communication FEZ Domino sur le bus CAN en microframework

Carte de test du bus CAN

Premier pas dans la communication entre la carte d’asservissement et la carte mère du robot 2011, la communication sur le bus CAN (cf article sur le fonctionnement de la propulsion 2011).

Pour assurer cette bonne communication, la première étape était de réussir à faire communiquer deux cartes du même type entre elles. Possédant deux exemplaires de notre carte mère, nous cherchions à envoyer et recevoir des messages entre ces 2 cartes pour valider la bonne communication sur le port CAN.

Adapteur SOIC / DIP

Adapteur SOIC / DIP

La carte FEZ Domino comporte un controleur CAN mais pas de transceiver. Il faut donc adjoindre un transceiver CAN pour permettre à la carte de communiquer sur le bus. Nous avons commencé par tester la gamme des transceivers TI VP230. Il nous a été impossible  de trouver ce transceiver en mode DIP et avons donc été obligés de nous tourner vers un packaging SOIC souder sur un adaptateur DIP/SOIC. Le grand intérêt de la gamme TI VP230 est de fonctionner en logique 3.3V ce qui correspond à la logique de la FEZ Domino

… Lire la suite

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

Pages ... 1 2