Vidéo HD

Présent

• Transpondeurs RFID (inventaire à réaliser)
• Antennes RFID
• Tags
• Puces Xbee
• Supports Xbee Xplorer
• Supports Xbee Shields
• Cartes Arduino Duemilanove

A acheter

• Modules Xbee suivant inventaire

Avancement du projet

Première séance (08/02/2012)

Objectifs :

• Prise en main du sujet
• Familiarisation avec les composants

Réalisations :

Pour cette première séance , nous avons dans un premier temps cherché les datasheets des transpondeurs RFID (Q5M-005) sur le site Lextronic. Cette datasheet nous informe que le module Q5M communique via une liaison série type RS232 (compatible TTL) , nous avons donc cherché un moyen de communiquer avec le module Q5M à l'aide d'un arduino. L'arduino UNO ne comportant qu'un seul "port série" qui est déjà utilisé par le port USB , nous avons dû utiliser la librairie <SoftwareSerial.h> qui permet d'émuler un port série sur des broches "classiques". Nous avons réalisé un premier montage pour communiquer avec le module Q5M via les broches 12(RX) et 13(TX) de l'arduino (Broche RX de l'arduino connectée sur la broche TX du module et inversement). L'arduino a été programmé de façon à récupérer une trame complète de 11 octets puis de l'afficher sur le terminal. Malheureusement , nous avons seulement été capable de récupérer un octet contenant 0x00 lorsqu'une carte est présente vers l'antenne , et rien autrement.

Deuxième séance (15/02/2012)

Objectif :

• Récupérer l'identifiant d'une carte Unique à l'aide du Q5M

Réalisations :

Suite à l’échec de la semaine dernière et après une relecture de la datasheet , nous avons compris que le Q5M fonctionne sur le principe de requête/réponse. Afin de simplifier le problème , nous avons laisser de coté l'arduino , et nous avons tenté de communiquer avec le module Q5M directement en utilisant le logiciel officiel FRAMER qui intègre les trames à envoyer. Pour ces tests , nous utilisons un convertisseur USB/Série connecté à notre module. Malheureusement , là encore , le module n'envoie qu'un seul octet 0x00 lorsque une carte est présente et rien d'autre , peut importe les requêtes que nous envoyons via le programme FRAMER. Dans le doute , nous avons voulu vérifier si les trames envoyé via FRAMER étaient correctes en les récupérant sur l'arduino en utilisant le programme réalisé la semaine d'avant. Après quelques tests , nous somme bien capable de récupérer les octets envoyés via FRAMER mais ceux-ci sont complètement incohérents avec ceux envoyés. Après quelques recherches sur internet , il se trouve que les signaux envoyés par l'ordinateur sur le convertisseur USB/Série sont inversés par rapport à des signaux RS232 compatible TTL ( http://kubuntu.free.fr/blog/index.php/2010/05/13/272-liaison-serie-rs232-vs-ttl ). Nous avons donc placé un inverseur entre le convertisseur USB/Série et l'arduino , et surprise , nous arrivons bien a récupérer les trames envoyées par FRAMER. Nous avons ensuite placé l'inverseur entre le convertisseur USB/Série et le module Q5M mais une fois encore , le module ne retourne qu'un octet 0x00 peut importe les requêtes envoyées via FRAMER.

Troisième séance (22/02/2012)

Objectif :

• Récupérer l'identifiant d'une carte Unique à l'aide du Q5M

Réalisations :

Après de nombreuses réflexions et de nombreux tests , nous avons voulu observer ce qu'il se passait sur les autres broches du module ... et nous avons remarqué que la communication série se faisait en fait sur une autre broche ... laissant supposé que notre module n'est pas un Q5M005 mais un UM005 (qui ne fonctionne qu'en "auto-read") ! Nous avons donc repris notre "programme de lecture" de la première séance et nous avons enfin réussi à lire un identifiant avec succès !

Maintenant que la lecture des identifiants des cartes RFID se fait correctement , nous avons cherché un moyen de réaliser une interface graphique qui afficherai cet identifiant dans une fenêtre windows. Pour cela nous utilisons le programme "Processing" qui permet de programmer toutes sortes d’éléments graphiques ainsi que de prendre en charge des périphériques USB tel un arduino (ou un Xbee).

Nous avons formalisé les données envoyées par les arduino de la façon suivante : Lorsqu'une carte est à portée d'un transpondeur, chaque arduino envoie le texte "Base X Carte YYYYY" ou X est l'identifiant du arduino qui correspond à une position sur une carte et YYYYY les 5 octets de l'identifiant de la carte. Partant de cette syntaxe, nous avons réalisé un premier programme sur Processing qui récupère les données envoyées sur le port série et qui les traites de façon à afficher les identifiants à différents endroit d'une fenêtre Windows.

Aperçu :

Quatrième séance (07/03/2012)

Objectifs :

• Utiliser les modules Xbee
• Tester l’intégration de plusieurs modules UM005 sur UN arduino
• Améliorer l'interface graphique pour gérer plusieurs identifiants simultanément

Réalisations :

Afin de solliciter un peu plus les arduino , nous avons tenté de connecter deux modules UM005 sur un seul arduino. Nous utilisons toujours la librairie <SoftwareSerial.h> pour émuler cette fois-ci deux ports séries. L'écoute de ces ports doit ce faire à tour de rôle par la commande "mySerial.listen()" et "mySerial2.listen()" , l’inconvenant majeur est qu'il faut attendre "2 coups d'envoi" du module pour récupérer les données ce qui rend le système assez lent.

Cinquième séance (14/03/2012)

Objectifs :

• Réaliser un réseau point à point à l'aide des modules Xbee
• Améliorer l'interface graphique pour afficher correctement les identifiants (pas de décalages)

Réalisations :

Nous avons réussi à réaliser un réseau "point à point" avec 3 modules arduino + Xbee. Les données sont transmises en "multi-saut" du module le plus "loin" jusqu'au pc. Nous avons amélioré le systeme d'affichage des identifiants dans Processing : lorsque qu'un identifiant change de base , l'affichage se fait sans décalage.

Sixième séance (21/03/2012)

Objectifs :

• Implémenter le calcul et la vérification du CRC avant l'envoi des données (dans l'arduino)
• Améliorer la communication globale entre les modules

Réalisations :

Nous avons implanté la vérification du CRC dans l'arduino avant l'envoi des données via le module Xbee.Nous avons constaté que la communication est beaucoup plus stable : nous n'obtenons plus de message incohérent sur le PC.

Septième séance (28/03/2012)

Objectifs :

• Améliorer l'interface graphique
• Améliorer la communication globale entre les modules

Réalisations :

Le code de notre programme a été changé de façon à pouvoir afficher les identifiants à des positions variables. Nous avons également réussi à charger une image de fond qui peut représenter par la suite le plan d'un bâtiment

Huitième séance (04/04/2012)

Objectifs :

• Rendre le flux de données Xbee bilatérale (adressage 64bits)

Réalisations :

Jusqu'ici le transfert des données s'effectue bien de manière "point à point" du module le plus loin jusqu'au pc en passant par tout les points , or ce transfert ne s'effectue pour l'instant que dans un seul sens (modules vers pc) , nous voudrions rendre ce flux bilatérale.

Neuvième séance (11/04/2012)

Objectifs :

• Rendre le flux de données Xbee bilatérale

Réalisations :

La semaine dernière nous avons vu qu'il n'était pas possible d'avoir 2 adresses de destination pour les modules Xbee , l'idée était donc de changer l'adresse de destination "à la volée" en utilisant l'arduino et les commandes ATxx

Rapport