Capteur Communicant Intelligent : Différence entre versions

Version actuelle datée du 19 mars 2014 à 14:34

Présentation

Cahier des charges

Objectif :

Réaliser une matrice de LED à l’échelle d'un publique d'une salle de spectacle en distribuant des bracelets lumineux localisables automatiquement

Description :

Dans le cadre d'un projet entre l'Artiste Wax Taylor et le laboratoire IRCICA de Lille, nous devont mettre au point un système permettant de localiser des personnes dans une salle de spectacle en vue de réaliser une matrice de LED à l'échelle d'un publique où le bracelet lumineux d'une personne ou ceux d'un ensemble de personne représente un pixel d'une image ou d'un motif. Le défi majeur reside dans la localisation des bracelets

Choix techniques : matériel requis

Avancement du Projet

Phase 0 : Début du Projet

Séance 1 (11/09/13)

Xbees Pro et Std

• Prise en main du sujet
• Test de la programmation ISP d'un ATMega328p et de son mode de fonctionnement sans quartz pour faire clignoter une LED sur breadboard

.

Séance 2 (17/09/13)

• Réflexion autour de différentes solutions techniques de localisation à l'intérieur d'un bâtiment.

Infrarouge
Ultrason
RSSI (Received Signal Strength Indication) : Absolue / Relative

Séance 3 (18/09/13)

• Confrontation avec le point de vue des encadrants : Après plusieurs discussions, la localisation absolue par RSSI semble la solution la plus "adaptée" au sujet. Il reste néanmoins à faire rapidement la preuve de ce concepte. Il a donc été décidé d'implémenter un premier système à base d'Xbee et d'Arduino en vu de faire des tests préliminaires dans l’amphithéâtre de l'IRCICA.

Phase 1 : Expérimentation Xbee & Arduino

Séance 4 (25/09/13)

Matériel

• Regoupement du matériel disponible à l'IRCICA et Polytech :

    6 x Xbee Standard
    4 x Xbee Pro
    4 x Arduino UNO
    1 x Arduino Mega

Séance 5 (26/09/13)

Début de la configuration des Xbees grâce à l'outils X-CTU de la société DIGI.

   Serial	ID	CH	DL	DH	MY
   4049CDF2	3335	C	FFFF	0	CDF2
   4049CC3E	3335	C	FFFF	0	CC3E
   407A6584	3335	C	FFFF	0	6584
   407A6459	3335	C	FFFF	0	6459
   40017249	3335	C	FFFF	0	7249
   40017248	3335	C	FFFF	0	7248
   407BE8C6	3335	C	FFFF	0	E8C6
   407C84D7	3335	C	FFFF	0	84D7

Serial = numéro de série de l'Xbee
ID (Network Identifiant) = Id du réseau (virtuel) dans lequel on veut faire travailler les Xbees
CH (Channel) = Selection du canal d'émission correspondant à la frequénce TX/RX
DL (Destination Low) = Partie basse du registre de configuration de l'adresse de communication (FFFF = Broadcast)
DH (Destination High) = Partie haute du même registre
MY (Device Identifiant) = Identifiant de l'Xbee sur le reseau (Convention : MY=2 derniers octects du Serial)

Séance 6 (30/09/13)

• Pour la localisation par RSSI, on constate très vite qu'il nous faut au minimum 3 émetteurs dont on connait la position et qui transmettent des trames de façon régulière chacun leur tour sans qu'il y ait de conflits. On appellera ces émetteurs TOURELLE tout au long de ce projet en opposition avec le récepteur à localiser qui sera appelé BRACELET.
  
  

• Pour les TOURELLES on décide d'implémenter dans un Arduino UNO un petit programme capable d’écouter ce qu'il reçoit sur son port série en provenance du module Xbee et d'identifier les éléments d'un trame simpliste de la forme suivante :

   <AA,BB,CC> 
   AA=num de la trame
   BB=nb total de trames
   CC=identifiant de la TOURELLE 

Chaque Arduino connait l'ensemble des identifiants des tourelles et leur priorité et sait ainsi à quel moment il a le droit d’émettre.

• Pour l'unique BRACELET que l'on cherche à localiser on utilise une Arduino MEGA 2530 qui comporte 3 vraies UART supplémentaires. On aura donc Serial0 (Arduino <--> PC) et Serial1 (Arduino <--> Xbee) afin de ne manquer aucune trame et de pouvoir la visualiser en direct sur un PC. Ce récepteur enregistre les niveaux RSSI reçu de chaque TOURELLE. On y a directement accès via la pin6 du module Xbee qui est en fait une PWM dont le rapport cyclique et proportionnel au RSSI.

Séance 7 (02/10/13)

• On continu d'implémenter les fonctions précédemment décrites dans les Arduinos.

• On redécouvre les joies du parsing de commande sur un environnement embarqué qui peut parfois poser des problèmes (utilisation de masques binaires et/ou des fonctions de la librairie C standard <String>)

Séance 8 (04/10/13)

• Des tests préliminaires dans le petit laboratoire de l'IRCICA démontrent que la puissance d'émission des TOURELLES doit être suffisamment faible ou en tout cas adaptée à la surface que l'on veut couvrir pour ne pas saturer le récepteur. En effet dans le cas des Xbee le RSSI est calculé uniquement sur 10 bits et on atteint la saturation pour quelques mW.

Séance 9 (10/10/13)

Xbees Pro et Std

• En lisant la datasheet on remarque que les Xbee standard ont une puissance (configurable) plus faible que les Xbee PRO on décide donc de remplacer les Xbee PRO des TOURELLES par des Xbee standard et de renouveler notre expérience. On observe maintenant une différence de signal quand on se déplace à l'échelle d'une pièce

.

Séance 10 (14/10/13)

• Jusqu'ici nous récupérions le RSSI en lisant un registre de l'Xbee. Cela a pour avantage d'avoir directement une valeur en numérique mais les temps d'accès sont long puisque pour chaque accès il faut mettre l'Xbee dans le mode d'interprétation des commandes AT à l'aide de la commande "+++" attendre sa réponse, l'interroger, parser sa réponse. Tout cela à la vitesse de 9600 bauds. On décide donc d'utiliser la sortie RSSI de l'Xbee sur la pin 6 qui est une PWM dont la rapport cyclique est proportionnel au RSSI donc facile à évaluer avec l'entrée analogique d'un arduino.

Séance 11 (15/10/13)

• Premiers tests dans l'amphi de l'IRCICA mais nous manquons d'alimentations indépendantes pour les Arduino et il y a encore trop de collisions entre les messages des TOURELLES nous devons donc encore améliorer notre code.

Séance 12 (16/10/13)

• Amélioration de l’algorithme des TOURELLES pour qu'elles emmettent chacun leur tour de façon cyclique pour ne plus avoir à s'occuper de cette partie lors des essai dans l'amphi.

• Optimisation de la puissance d'emission des Xbees

• Récupération d'alimentation secteurs 5V pour les futurs tests

Séance 13 (21/10/13)

• Deuxième essai dans l’amphithéâtre de l'IRCICA. Le système fonctionne bien.

• En première approximation la résolution est de 2 sièges.

• / ! \ On constate rapidement que la présence d'une personne dans le champs entre un BRACELET et une TOURELLE fait fortement fluctuer les valeurs sans changer la position spatiale des différents systèmes.

• Ce phénomène s'explique avec l'utilisation de la bande de fréquence des 2,4 GHz qui est très proche de la fréquence de résonance de l'eau donc plus sensible aux êtres vivants. On décide donc d'abandonner cette bande de fréquence et de regarder les technologies disponibles dans les 433 MHz ou 868 MHz (fréquences libres en Europe)

Séance 14 (23/10/13)

• Toute la séance est consacrée à la reflexion autour d'un prtocole de communication à la fois de compact et riche en information.

• Discussion autour des différentes techniques combinées de localisation : Position barycentrique grâce aux tourelles de references, Découvertes des voisins les plus proches

Phase 2 : Développement de Prototypes

Pendant les Vacances

• Ébauche du protocole de communication.

Séance 15 (04/11/13)

• Bilan de l'avancement avec M Vantroys.
• On règle différentes questions qu'en à la taille des données de localisation et leur stockage.
• On fait le point sur les objectifs pour la soutenance du 19 décembre (validation de concepte, réalisation de prototypes et de mesures)

Séance 16 (05/11/13)

• A partir de là nous nous sommes reparti les tâches en 2 parties. L'un commençant à écrire le code pour la station de BASE qui sera le chef d'orchestre de tout le système donnant la parole aux Equipements chacun leur tour et relevant les données en vu d'effectuer les calculs de localisation. L'autre s'occupe de réaliser les différents PCB sous EAGLE

Séance 17 (06/11/13)

Partie PCB

• Nous somme parti sur l'utilisation du MRF49XA, un transmetteur utilisant les fréquences 433/868Mhz et utilisant la communication série SPI.
• Recherche et ébauche du schéma utilisant un ATMega328p et le MRF49XA.

Partie Station de Base

• Expérimentation de la librairie de communication Serie en C "RS-232 for Linux and Windows" entre un arduino UNO et un PC sous windows

   int RS232_OpenComport(int comport_number, int baudrate)
   void RS232_CloseComport(int comport_number)
   int RS232_PollComport(int comport_number, unsigned char *buf, int size)
   int RS232_SendByte(int comport_number, unsigned char byte)

source : http://www.teuniz.net/RS-232/

Séance 18 (07/11/13)

Partie PCB

• Correction du schéma précédant.
• Et recherche d'une solution compact pour l'antenne.

Partie Station de Base

• Intégration de la librairie "RS-232 for Linux and Windows" à notre projet
• Réalisation de quelques tests d'émission/reception en configurant un Arduino pour qu'il émette sur le port série à intervels réguliers

Rq : On réalise vite que comme sur un µP il va falloir faire le choix entre scrutation du buffer de reception et detection des interruptions du port série. Après quelques réflexions on constate que l'utulisation d'un thread de scrutation du port série serait bien adapté.

Séance 19 (08/11/13)

Partie PCB

• Développement du PCB : ATMega328p

Partie Station de Base

• Beaucoup de temps de recherche pour intégrer la librairie pthread dans CodeBlocks et configurer les différents paramètres de compilation

Séance 20 (12/11/13)

Partie AVR

• Développement de fonctions C permettant la communication serial sans les librairies et le bootloader Arduino.

Partie Station de Base

• On écrit le code de void * th_Serial_Check(void * param) qui permet de scruter le port série et plus tard qui permettra de lancer les bonnes fonctions de parsing et de contrôle d'intégrité des trames ainsi que de gérer l'enregistrement des trames

Séance 21 (13/11/13)

Partie AVR

• Suite du développement de fonctions C permettant la communication SPI sans les librairies et le bootloader Arduino.

Partie Station de Base

• Ajout des fonctions de calcul de CRC
• Mise en forme de l'affichage sur la console des trames reçues

Séance 22 (15/11/13)

• On commence à écrire la commande en commun des composants que l'on aura besoin pour la suite du projet, on relève les références sur le site MOUSER

Séance 23 (18/11/13)

Partie PCB (En commun)

• Suite à une réunion avec Alexandre Boé, nous nous sommes orienté vers une carte sans ATMega328p.

Séance 24 (19/11/13)

Partie PCB

• Réalisation la carte sans ATMega328p.

Partie Station de Base

• Début d'implémentation des fonctions de parsing, l'Arduino emet des trames dont le contenu est connu et on essai de les décoder
• Essai complémentaire avec des trames générées aléatoirement pour valider les fonctions de CRC et detection des trames valides

Séance 25 (20/11/13)

• Finalisation de la commande MOUSER

Séance 26 (26/11/13)

• Avancement du Wiki

• Réflexions autour des algorithmes de localisation (Barycentre, Trilatération,...)

Partie PCB

• Optimisation du 1er PCB de prototypage : MRF49XA + Ballun

Schéma

Typon

Partie Station de Base

• Début d'implémentation de l'arbre des différents cas en fonctions des Code commande, de l'emetteur, du destinataire,... à l'aide de plusieurs Switch...Case:...Break

Séance 27 (27/11/13)

Partie PCB

Vue Eclatée

• Réalisation de 3 PCB MRF49XA + Ballun. Découverte des logicielles liés à la graveuse
• Ajout de fonctions simples permettant la configuration des registres du MRF49XA ainsi que l'ensemble des définitions de variable utile à sa configuration.

.

Partie Station de Base

Séance 28 (28/11/13)

Partie MRF49XA

• Ajout de fonctions de communication à travers le MRF49XA.

Partie Station de Base

Séance 29 (03/12/13)

Partie MRF49XA

• Test du programme dans le MRF49XA, une premières lecture du registre de statut du MRF49XA semble validé la configuration mais il semble y avoir une erreur lors de l'envoie.

Partie Station de Base

Séance 30 (04/12/13)

Partie MRF49XA

• Débugage du programme : soit un problème au niveau de la communication SPI, soit un problème dans le traitement de l'interruption.

Partie Station de Base

Séance 31 (05/12/13)

Partie MRF49XA

• Test de la communication SPI à partir d'un second Arduino. Il n'y a pas de problème.
• Résolution de problème : prendre en compte le RESET.

Partie Station de Base

Séance 33 (10/12/13)

Partie MRF49XA

• Programmation de la lecture du RSSI.

Partie Station de Base

Séance 36 (13/12/13)

Partie MRF49XA

• Test de la communication entre deux cartes et de lecture du RSSI. Problème de communication peut-être du à l'absence d'une inductance dans le ballun de la carte.

Partie Station de Base

Phase 3 : Mise en place et test du protocole

A partir d'ici on laisse tomber le découpage en séance au profit de celui en semaines car 100% du temps est consacré au PFE De plus on ne fera plus de distinction entre Station de Base et Code du Bracelet car ceux si évoluent conjointement (le code écrit et les bugs corrigés de l'un servent à gagner du temps dans le développement du code de l'autre). On mettra l'accent sur les spécificités de l'un et de l'autre.

Semaine du 01/01/14

Débogage du prototype

• Rajout de l'inductance manquante. Un nouveau test de communication entre deux cartes n'a pas fonctionné. Après divers tests sur l'un des prototype, celui-ci ne semble pas fonctionnel car la communication par SPI ne semble pas donner de réponse.
• Ces tests ont aussi mis en évidence l'impossibilité d'envoyer des paquets.

Semaine du 20/01/14

Débogage du prototype

• Mise en évidence d'un conflit au niveau des tests d'envoie de paquet. En effet, pour réaliser ce test, un paquet est envoyé tous les 60 boucles du main. Hors, c'est envoie était réalisé sans vérifier le statut du MRF. Problème résolu mais qui n'était pas à l'origine du problème d'envoie de paquet.

Semaine du 27/01/14

Utilisation du registre de transmission du MRF49XA

Débogage du prototype

• Aucun paquet n'est envoyé. En effet, à la première interruption provoquer par le MRF, c'est un paquet de réveil du registre de transmission qui est envoyé (deux paquets ayant pour valeur 0xAA pour réveillé le registre de transmission sont réclamé par la datasheet et dont le schéma à gauche en résume l'utilisation) et non un paquet de donnée.

Semaine du 03/02/14

Débogage du prototype

• Une autre erreur de programmation a été mis en évidence : à chaque interruption, l'adresse du registre de transmission est envoyé avant l'octet de donnée hors cette adresse n'est nécessaire qu'à la première interruption et ne l'est plus pour les interruptions suivantes.

Semaine du 10/02/14

Débogage du prototype

• Un court-circuit a était découvert au niveau du ballun du circuit. Une tentative de réparation a été effectué mais malheureusement sans réussite. Un nouveau prototype est nécessaire.

Semaine du 17/02/14

Débogage du prototype

• Le prototype à base de MRF est pour l'instant mis de côté afin de pouvoir travailler sur les essais à base de XBee.

Rendu final

Rapports

• Rapport Intermediaire : Fichier:CHALAUX HUSSE ProjetCCI 19.12.2013.pdf
• Rapport Final : Fichier:PFE CHALAUX HUSSE Projet Wax Tailor Final.pdf

Code Système Complet version Xbee

• Archive : Fichier:Projet CCI Base Tour Bracelet VersionXbee CHALAUX HUSSE.zip

Prototype à base du MRF49XA

• Datasheet du MRF49XA : Fichier:MRF49XA.pdf
• Firmware de l'ATMega328p : Fichier:Mrf49xa firmware.zip / [BigFile de Lille1]

AVR-GCC est nécessaire pour pouvoir compiler le programme est le transférer sur l'ATMega328p.

• Schéma et typon de la version actuelle du prototype : Fichier:Mrf49xa schema v1.zip / [BigFile de Lille1]
• Schéma de la nouvelle version du prototype, non réalisé : Fichier:Mrf49xa schema v2.zip / [BigFile de Lille1]