Capteur Communicant Intelligent

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

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.

Format d'une Trame

	Base/Tourelle/Bracelet	ID	CMD	Emission/Reponse Commande	DATA	Stuffing	TOTAL	NB OCTECTS
Nb de Bits	2	16	4	1	32	1	56	7

Format des DATA

NUM	CODE	CMD	EMETTEUR	DATA [nb de bits]	Nb Bits de DATA Utilisés	DESCRIPTION
BASE
0	0000	-	BASE	-	-	-
1	0001	TX TOUR	BASE	IDTOUR [16] / NBTRAME [3] / INTERVAL (x10ms) [8]	27	Autorise une Tourelle à Emettre
2	0010	RSSI TOUR	BASE	IDBRAC [16] / MASK [16]	16	Interroge un ou des bracelets pour connaitre le RSSI des Tourelles
3	0011	RSSI MAX	BASE	IDBRAC [16] / MASK [16] / N [3]	19	Interroge un ou des bracelets pour connaitre les N RSSI plus fort recus
4	0100	ENTENDU	BASE	IDBRAC [16]	16	Demande à tout les bracelets qui ont entendu un ID particulier de repondre
5	0101	PING	BASE	IDBRAC [16]	16	Ping un bracelet en particulier
TOURELLES
0	0000	-	TOUR	Tout les bits à 1		la Tourelle envoie une trame de Test en Broadcast
1	0001	TX TOUR	TOUR	IDTOUR [16] / NUMTRAME [3] / NBTRAME [3] / INTERVAL [8]	30	Trame émise par une Tourelle
BRACELETS
0	0000	-	BRAC	-	-	-
1	0001	-	BRAC	-	-	Ne fait rien ce sont les touerelles qui emettent
2	0010	RSSI TOUR	BRAC	IDTOUR [16] / NBTRAME [3] / RSSIMOY [10]	29	Le Bracelet renvoi le RSSI Moyen recu des tourelles qu'il a entendu
3	0011	RSSI MAX	BRAC	IDBRAC [16] / N [3] / RSSI [10]	29	Le Bracelet renvoi les N plus forts RSSI recu des autres bracelets entendus
4	0100	ENTENDU	BRAC	IDBRAC [16] / RSSI [10]	26	Le Bracelet renvoi le RSSI recu du bracelet recherché

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.

Séance 19 (08/11/13)

Partie PCB

• Développement du PCB : ATMega328p

Séance 20 (12/11/13)

Partie AVR

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

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.

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.

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

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.

.

Séance 28 (28/11/13)

• Ajout de fonctions de communication à travers le MRF49XA.

Séance 29 (03/12/13)

• 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.

Séance 30 (04/12/13)

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

Séance 31 (05/12/13)

• 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.

Séance 33 (10/12/13)

• Programmation de la lecture du RSSI.

Séance 36 (13/12/13)

• 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.

Phase 3 : Mise en place et test du protocole

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

Prototype à base du MRF49XA

• Datasheet du MRF49XA
• Firmware de l'ATMega328p : [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 actuel du prototype : [BigFile de Lille1]
• Schéma de la nouvelle version du prototype, non réalisé : [BigFile de Lille1]

Les liens BigFile sont valables jusqu'au 19 mars 2014. Si les fichiers sont indisponibles, vous pouvez me contacter par mail (nicolas.husse).