[Logos du site]
Suivez nous :
[Sponsors du club]
mdp
Suivez nous :


01/06/2010 Le projet can x est une interface can faite maison en java auteur : C3dr1c[FP][@][M][*]

[HAUT][COM]
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
image club robotque alsacien µart ( uart ):manquante

Can X en mode terran avec adversaire
image club robotque alsacien µart ( uart ):manquante

Can X en mode split avec 2 signaux en fonction du temps
image club robotque alsacien µart ( uart ):manquante

Can X en mode superposition avec 2 signaux en fonction du temps
image club robotque alsacien µart ( uart ):manquante
|---Edité--- le 14/10/2010 par C3dr1c[FP][@][M][*] --|

05/04/2009 Fault Handler auteur : Matt[FP][@][M][*]

[HAUT][COM]
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.

image club robotque alsacien µart ( uart ):manquante

Matthieu
|---Edité--- le 16/06/2009 par C3dr1c[FP][@][M][*] --|

19/09/2008 Communication inter PIC auteur : C3dr1c[FP][@][M][*]

[HAUT][COM]
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




|---Edité--- le 26/11/2008 par Anaïs[FP][@][M][*] --|

21/07/2008 Le Flashage dans l'équipe µART auteur : Matt[FP][@][M][*]

[HAUT][COM]
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 :
image club robotque alsacien µart ( uart ):manquante







|---Edité--- le 31/01/2009 par C3dr1c[FP][@][M][*] --|

04/08/2008 champion du monde auteur : Sepi

[HAUT]
tu t'es vraiment appliqué sur l'illustration....
Bravo Matt, très fort, très très fort....!!!
image club robotque alsacien µart ( uart ):manquante
|---Edité--- le 31/01/2009 par C3dr1c[FP][@][M][*] --|

16/06/2008 Vision couleur auteur : Yann[FP][@][M][*]

[HAUT][COM]
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 :

image club robotque alsacien µart ( uart ):manquante

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:

image club robotque alsacien µart ( uart ):manquante




|---Edité--- le 25/11/2008 par Anaïs[FP][@][M][*] --|

10/06/2008 Les balises US auteur : Sepi[FP][@][M][*]

[HAUT][COM]
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.

image club robotque alsacien µart ( uart ):manquante



On place l’origine au niveau de
la balise R1 soit X_tmp et Yorg.

image club robotque alsacien µart ( uart ):manquante

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.

image club robotque alsacien µart ( uart ):manquanteimage club robotque alsacien µart ( uart ):manquanteimage club robotque alsacien µart ( uart ):manquante
Vue d’ensemble des balises fixes

image club robotque alsacien µart ( uart ):manquanteimage club robotque alsacien µart ( uart ):manquanteimage club robotque alsacien µart ( uart ):manquante
La balise adverse émettrice

image club robotque alsacien µart ( uart ):manquante
La Carte US embarquée dans le robot(Photos)

Schéma élec:

image club robotque alsacien µart ( uart ):manquante
Les cartes de traitement



Biblio: un grand merci aux différents sites suivants :
robot-electronics
Loïc Lefebvre
micro-examples
Fassociation.arobas.free.fr
|---Edité--- le 26/11/2008 par Anaïs[FP][@][M][*] --|