CanX ou CAN eXploreur est un projet une API java d'interfacage avec le robot
Nos robots sont constitués de plusieurs cartes chacunes avec son propre pic et sa fonction, pour que tout ce petit monde communique ensemble nous utilisons un bus CAN (bus tres utilisé dans l'automobile).
Aujourd'hui nous arrivons à lire ce bus au travers d'une carte can/usb (merci à notre sponsor kvaser), notre but est de développer notre propre outil d'interfacage et d'aquisition qui sera certe plus simple et moins fiable que les outils professionnels mais personnalisés
Il nous permettra de connaitre toutes les instructions qui circulent sur le can mais aussi d'envoyer des instructions au robot. Il nous sera tres utile lors des phases de debug et d'analyse.
Can X en mode terrain sans adversaire
Can X en mode terran avec adversaire
Can X en mode split avec 2 signaux en fonction du temps
Can X en mode superposition avec 2 signaux en fonction du temps
Bonjour à tous,
voici un 1er screenshot de la page web générée par la Gateway et résumant la totalité des erreurs retournées par les différents µC présents dans le robot.
Matthieu
en construction
Comme beaucoup d’équipes, nous nous appuyons pour l’intelligence et la commande sur un réseau à base de plusieurs DsPIC de Microchip.
Etant donné que chaque DsPic se doit d'échanger des informations avec ses partenaires, nous nous sommes penchés sur la mise en place d'un bus de terrain.
La difficulté dans ce genre de réseau réside le plus souvent dans la fiabilité, la rapidité, la flexibilité et le débit proposé par cette mise en réseau. La communication est un élément important qu’il ne faut pas négliger, perdre des informations et des instructions n’est pas admissible. Une communication externe (par câble non non pas de télécommande…) peut toujours être utile afin de réaliser des logs et des informations de debug.
Lors de notre étude, nous nous somme arrêtés sur plusieurs choix de bus de terrain possibles :
Nous avions envisagé le tam tam ou les signaux de fumée mais pour des raisons évidentes de risques de tricherie (télécommander le robot au briquet) nous les avons rapidement écartés.
Par la suite, nous avions envisagé le wifi par Xbee mais trop lent et pas assez fiable (nous l’utilisons pour la communication avec les balises en utilisant des trames cryptées pour éviter les perturbations et interférences avec des communications Xbee concurrentes) (attention nous avons eu quelques problèmes de temps de latence avec les xbee qui ne sont pas faits pour une communication aussi pointue notamment en environnement très perturbé par d'autres stations émettant en wifi, nous doublerons un xbee en 2009 pour palier à ce problème).
La liaison I2C que certains membres ont utilisé par le passé. Pour notre application, la liaison I2C a rapidement été jugée trop restrictive et trop sensible aux parasites avec des lignes d'un mètre environ.
La liaison série, très simple à mettre en œuvre mais pas très efficace dans une configuration multi-maîtres…(nous l’utilisons cependant un peu pour le debug merci printf).
Les autres possibilités sont encore nombreuses et variées mais ne seront pas évoquées ici.
Notre choix s'est finalement arrêté sur l'utilisation d'un bus CAN (merci Matt de nous avoir laissé le choix
)
En effet le CAN a déjà largement fait ses preuves en environnement très perturbé (d'ou sa grande utilisation dans l'automobile) et présente un débit adapté à nos besoins ainsi qu'une architecture multi-maîtres.
Les DsPics intègrent de série un contrôleur CAN et ne nécessitent pour la mise en œuvre que l'ajout d'un transceiver et d'une résistance de terminaison.
Explication de la partie électrique
Les câbles
Le chip can
Branchement sur le pic….Programmation
Pour la programmation de nos DsPIC nous avons opté pour une architecture commune, un noyau dur commun à tous avec des modules polyvalents qui sont ou ne sont pas implémentés lors de la compilation (#if #ELIF…pour ceux à qui cela parle). Les timers, la configuration des I/O, les asserv, sont communs. Pour faire simple, nous n’avons qu’un seul programme et chacun y ajoute une brique avec du spécifique à son ou ses projets en essayant d’utiliser ou de développer des fonctions les plus polyvalentes possibles. Le can fait partie d’une de ces briques communes. Je m’attarde sur le sujet car cela prend toute son importance lorsque nous parlons de communication. En effet, pour communiquer il faut parler le même langage et chacun son tour. Cette architecture commune par brique nous permet de n’avoir qu’un seul programme de communication et les modifications faites sont prises en compte pour l’ensemble des projets. Dans la pratique, fonctionnant en gestion de projet et étant tous géographiquement très éloignés, chacun fait évoluer l’ensemble des briques en fonction de ses besoins et une personne se charge au moyen de programme de comparaison (nous utilisons
beyond compare sous WXP autre mouture linux) de réconcilier tous les projets lors des réunions.
Afin d'organiser les IDs des messages sur le bus nous avons opté pour un codage des destinataires dans l'ID (29 bits).
DDDD EEEE TTTTTTTTTTTTTTTTT LLLL
D : Destinataire du msg (0 = Broadcast, 1 à 15 = ID du micro)
E : Emetteur du msg (1 à 15 = ID du micro)
T : ID du message
L : longueur du message (0 à 8)Avec simplement 2 masques d'acceptance, on peut ainsi accepter les broadcasts et les messages qui ne sont destinés qu'à un seul
µC.
Ce type d'adressage nous permet ainsi d'envoyer un message commun à un seul et même micro.
Afin de pouvoir échanger tous types de données (char, int, float, double,...) en passant par le codage 8 bits du CAN nous avons utilisé la méthode très simple de l'union :
typedef union{
ULONG64 l_FullFrame_UL;
UBYTE l_DataArray_UB[8];
struct
{
UWORD l_BatterieVoltage_UW : 9;
UWORD l_ElapsedTime_UW : 10;
BOOL l_Color_B : 1;
etc....
}PartialAccess;
}Msg_RobotState_Type;
Pour en revenir au sujet qui nous intéresse nous avions en 2008 une gestion des messages.
Nous avions un certain nombre de données à faire transiter par le CAN :
Chaque pic est susceptible d’envoyer et de recevoir des messages,
Les messages sont destinés à un, plusieurs ou tous les pics,
Les données sont multiples et sur de multiples formats byte char long float…
Pour une communication efficace il faut bien structurer la donnée et l'optimiser au maximum.
Nous avons donc défini X messages par pic, chaque message est codé sur une trame de 64 bit.
Pour optimiser le nombre de message en fonction du type de donnée nous imbriquons plusieurs données et faisons du décodage réception.
Ainsi chaque message est défini selon :
Une adresse ou un code propre,
Une trame de décodage,
Et à qui il se destine.
Nous garderons une architecture similaire, mais travaillons d’arrache-pied pour une configuration automatique, la configuration en 2008 était très fastidieuse.
Voir pour mettre le code des mails box
En 2008 notre robot était constitué de 10 microcontrôleurs DsPIC. Ceci implique un nombre certain de reflashages (enfin ça dépend pour qui
). Nous nous sommes rendus compte qu'en travaillant à plusieurs simultanément sur le robot, l'opération de flashage devenait très rapidement fastidieuse : branchage et débranchage du programmateur, mauvaise connexion, fichier hexa chargé dans le mauvais micro etc etc.
Cette année, une solution de flashage à travers le CAN est donc en cours de réalisation. L'interface se composera d'un point d'accès Wifi (qui sera enlevé durant les matchs), d'un serveur web embarqué relié à une gateway CAN.
Chaque développeur pourra ainsi reflasher son micro à travers le CAN et sans fils depuis sa place simplement en se connectant depuis une page web.
Schéma de principe :
La vision couleur : LinbotCAM La vision couleur est réalisée par une webcam USB et un logiciel écrit en C (LinbotCAM). Il doit permettre d'ajouter progressivement des fonctions de reconnaissance plus ou moins évoluées. La première tâche consiste à détecter des zones de couleurs prédéfinies. Elle a été développée afin de repérer des balles de couleur lors de la Coupe de France de Robotique 2008. Malheureusement la maturité du projet et la qualité de la caméra n'ont pas permis l'intégration de ce module dans le robot cette année-là.
Le module LinbotCAM est une application exécutée par le PC. Un client peut s'y connecter via TCP/IP et envoyer/recevoir des données. L'architecture de ce module est détaillée ci-dessous :
Le module de vision LinbotCAM a été écrit en C afin de permettre une bonne optimisation du code afin d'accélérer les traitements. Le protocole de communication TCP/IP ne sera pas détaillé ici. Les commandes sont des chaines ASCII. Les images complètes peuvent également être transmises afin de mettre au point les algorithmes et régler les paramètres.
LinbotCAM permet d'effectuer une série de traitements sur les images capturées afin d'en retirer un maximum d'informations. L'algorithme mis en place dans le thread de capture est le suivant:
Depuis 2007 le concours Eurobot contraint les participants à éviter l’adversaire. Cette nouvelle consigne ajoute un peu de piment à la Coupe mais prévient surtout les collisions parfois violentes et destructrices au bénéfice du spectacle.
Certaines équipes ne se contentent pas simplement d’esquiver l’adversaire. Les plus fortes (
RCVA,
Helb-Inraci,
IUT Angers,
Microb, …) peuvent anticiper et agir en fonction des actions adverses pour optimiser les déplacements et adapter leurs stratégies au cours du match.
Dans ce petit article nous nous focaliserons uniquement sur un mode de détection par balises Ultra-son, la stratégie ne sera pas développée.
L’idée est de connaître la position exacte (à 3 cm près) du robot adverse sur l’aire de jeu afin de pouvoir agir en conséquence.
Pour cela nous avons développé un système de balise Ultra-son à synchronisation
HF.
Petit descriptif du système.Un émetteur US omnidirectionnel
E est placé sur le robot adverse, des récepteurs
R1 et R2 sont disposés sur les supports de balise fixes. Celles-ci sont orientées dans le même sens. De cette manière, seul 2 balises sont nécessaires à la localisation.
3 émetteurs
HF ZBee sont dispatchés dans le robot
MARS’L (M), la balise émettrice
E et la balise réceptrice
R1.
La balise Fixe
R1 coordonne les mesures.
1.R1 : Envoi d’une requête de mesure de position à E par voie HF (ZBee)
2.E : Envoi d’une impulsion US
3.R1 et R2 : Mesure du temps entre la requête HF et l’onde US (t1 et t2)
4.R2 : Transfert du temps t2 à la balise R1 par un bus CAN commun aux 2 balises
5.R1 : Conversion du temps en distance (t1 : d1 et t2 : d2)
6.R1 : Calcul des coordonnées X et Y de l’adversaire (Petit rappel sur la triangulation)
7.R1 : Transfert des coordonnées au robot M par voie HF (ZBee)
La distance maximum correspond à la diagonale de l’aire de jeu soit 3662 mm, soit t = 11.2 ms (avec Vitesse du son = 320 m/s).
La période de rafraîchissement est fixée au minimum à 2t = 22.4ms pour s’affranchir des échos éventuels. Cette année nous avions pris une marge de sécurité de 7-8ms soit un échantillonnage à 30 ms (33Hz).
Traitement du signal.Pour limiter les bruits dans les mesures, nous avons mis au point au système de tracking soft de l’onde US mesurée.
Ce principe est basé sur une décomposition de la mesure en 3 temps :
1.Temps mort (varie entre 0 et 12 ms)
2.Temps avant acquisition (fixe, fonction du temps d’impulsion US)
3.Temps après acquisition (fixe, fonction du temps d’impulsion US)
Durant la phase de temps mort nous ne tenons pas du tout compte des événements US. En fait, l’onde US qui nous intéresse ne peut pas appartenir à cet intervalle de temps.
Cette phase est définie par le temps d’acquisition tn-1 de l’échantillon de la mesure précédente. L’échantillon tn-1 étant initialisé à 0 au début de l’algo.
Temps_mort = (dn-1 – (Erreur * (delta_dist_max)/2 + T_pulse/2))/Vson
Avec :
dn-1 : distance à l’échantillon précédent
Erreur : compteur de perte de signal US
delta_dist_max : la distance max admissible entre 2 échantillons (ici 30 mm si vmax = 1m/s et Tech = 30ms)
T_Pulse : temps du pulse d’émission US
Vson : Vitesse du son
A la fin du temps mort nous lançons l’acquisition de la mesure.
dn = temps_mort + temps_Acquisition
dn_last = temps_mort + temps_Acquisition_Last
Pulse_dn = dn_last – dn
Avec
dn : échantillon en cours de mesure
temps_Acquisition : temps de la 1ère variation
temps_Acquisition_Last : temps de la dernière variation
Pulse_dn : Pulse de l’échantillon
dn_last: dernière variation US mesurée par les capsules
on vérifie ensuite que le pulse mesuré rentre dans l’intervalle défini pour valider la mesure ou le cas contraire, augmenter la largeur de l’intervalle.
Si Pulse_dn est compris dans l’interval (T_Pulse * 0,9 <Pulse_dn< T_Pulse * 1,1) et si (temps_Acquisition : minimum)
dn-1 = dn
Sinon
Erreur ++
Petit rappel sur la triangulation.On place l’origine au niveau de
la balise
R1 soit X_tmp et Yorg.
Enfin nous changeons de repère (Xorg,Yorg)
Nous avons combiné à ce système un repérage périmétrique par réflexion US. Il se résume à 2 récepteurs US directionnels par coté et un émetteur omnidirectionnel au sommet du robot.
Nous pouvons donc soit directement mesurer l’onde provenant de la balise adversaire soit mesurer une réflexion entre les différents capteurs périmétriques et l’émetteur sous support de balise. (Photos).
Ce dispositif est activé dans le cas ou les balises fixes ne reçoivent plus de signaux valides pendant 20 Te, soit 600 ms. Le traitement des ondes US se fait de la même façon qu’avec les balises fixes.
Vue d’ensemble des balises fixes
La balise adverse émettrice
La Carte US embarquée dans le robot(Photos)
Schéma élec:
Les cartes de traitement
Biblio: un grand merci aux différents sites suivants :
robot-electronics Loïc Lefebvremicro-examplesassociation.arobas.free.fr
Bravo Matt, très fort, très très fort....!!!