Wiki de Projets IMA - Contributions de l’utilisateur [fr]

Capteur Communicant Intelligent

2014-02-26T14:16:35Z

Nhusse : /* Prototype à base du MRF49XA */

== 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) ===

[[Fichier:AVRISP mkII.jpg|250px|thumb|left|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) ===

[[Fichier:Matos.jpg|400px|thumb|center|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) ===

[[Fichier:Xbee Pro Std.jpg|250px|thumb|left|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.

{| class="wikitable alternance center"
|+ Format d'une Trame
|-
|
! scope="col" | Base/Tourelle/Bracelet
! scope="col" | ID
! scope="col" | CMD
! scope="col" | Emission/Reponse Commande
! scope="col" | DATA
! scope="col" | Stuffing
! scope="col" | TOTAL
! scope="col" | NB OCTECTS
|-
! scope="row" | Nb de Bits
| 2
| 16
| 4
| 1
| 32
| 1
| 56
| 7
|}

{| class="wikitable alternance center"
|+ Format des DATA
| align="center" style="background:#f0f0f0;"|'''NUM'''
| align="center" style="background:#f0f0f0;"|'''CODE'''
| align="center" style="background:#f0f0f0;"|'''CMD'''
| align="center" style="background:#f0f0f0;"|'''EMETTEUR'''
| align="center" style="background:#f0f0f0;"|'''DATA [nb de bits]'''
| align="center" style="background:#f0f0f0;"|'''Nb Bits de DATA Utilisés'''
| align="center" style="background:#f0f0f0;"|'''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.

==== Partie Station de Base ====

=== Séance 19 (08/11/13) ===

==== Partie PCB ====

* Développement du PCB : ATMega328p

==== Partie Station de Base ====

=== 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 ====

=== 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 ====

=== 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 ====

=== 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
[[Fichier:Schematic.png|centre|400px|alt=Schematic - Capteur Communicant Intelligent V1|vignette|Schéma]]
[[Fichier:Typon.png|centre|400px|alt=Typon - Capteur Communicant Intelligent V1|vignette|Typon]]

=== Séance 27 (27/11/13) ===

==== Partie PCB ====

[[Fichier:Proto1 MRFXA49.jpg|250px|thumb|left|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 ===

[[Fichier:Tx mrf.png|250px|thumb|left|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 : [[Fichier:MRF49XA.pdf|Datasheet du MRF49XA]]
* Firmware de l'ATMega328p : [[Fichier:Mrf49xa firmware.zip]] / [[https://bigfile.univ-lille1.fr/get?k=qpgkFLtHGwszbpEgOyP|Lien 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]] / [[https://bigfile.univ-lille1.fr/get?k=GanInTsS29ZOdIX9esL|Lien BigFile de Lille1]]
* Schéma de la nouvelle version du prototype, non réalisé : [[Fichier:Mrf49xa schema v2.zip]] / [[https://bigfile.univ-lille1.fr/get?k=aLcJi1fAkF2BglHkuNh|Lien BigFile de Lille1]]

Fichier:Mrf49xa schema v2.zip

2014-02-26T14:16:01Z

Nhusse : Schéma de la nouvelle version du prototype (non réalisé).

Schéma de la nouvelle version du prototype (non réalisé).

Fichier:Mrf49xa schema v1.zip

2014-02-26T14:14:34Z

Nhusse : Schéma de la version actuelle du prototype.

Schéma de la version actuelle du prototype.

Fichier:Mrf49xa firmware.zip

2014-02-26T14:11:52Z

Nhusse : Firmware du MRF49XA

Firmware du MRF49XA

Capteur Communicant Intelligent

2014-02-26T14:08:59Z

Nhusse : /* Prototype à base du MRF49XA */

== 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) ===

[[Fichier:AVRISP mkII.jpg|250px|thumb|left|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) ===

[[Fichier:Matos.jpg|400px|thumb|center|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) ===

[[Fichier:Xbee Pro Std.jpg|250px|thumb|left|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.

{| class="wikitable alternance center"
|+ Format d'une Trame
|-
|
! scope="col" | Base/Tourelle/Bracelet
! scope="col" | ID
! scope="col" | CMD
! scope="col" | Emission/Reponse Commande
! scope="col" | DATA
! scope="col" | Stuffing
! scope="col" | TOTAL
! scope="col" | NB OCTECTS
|-
! scope="row" | Nb de Bits
| 2
| 16
| 4
| 1
| 32
| 1
| 56
| 7
|}

{| class="wikitable alternance center"
|+ Format des DATA
| align="center" style="background:#f0f0f0;"|'''NUM'''
| align="center" style="background:#f0f0f0;"|'''CODE'''
| align="center" style="background:#f0f0f0;"|'''CMD'''
| align="center" style="background:#f0f0f0;"|'''EMETTEUR'''
| align="center" style="background:#f0f0f0;"|'''DATA [nb de bits]'''
| align="center" style="background:#f0f0f0;"|'''Nb Bits de DATA Utilisés'''
| align="center" style="background:#f0f0f0;"|'''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.

==== Partie Station de Base ====

=== Séance 19 (08/11/13) ===

==== Partie PCB ====

* Développement du PCB : ATMega328p

==== Partie Station de Base ====

=== 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 ====

=== 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 ====

=== 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 ====

=== 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
[[Fichier:Schematic.png|centre|400px|alt=Schematic - Capteur Communicant Intelligent V1|vignette|Schéma]]
[[Fichier:Typon.png|centre|400px|alt=Typon - Capteur Communicant Intelligent V1|vignette|Typon]]

=== Séance 27 (27/11/13) ===

==== Partie PCB ====

[[Fichier:Proto1 MRFXA49.jpg|250px|thumb|left|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 ===

[[Fichier:Tx mrf.png|250px|thumb|left|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 ===

* [[Fichier:MRF49XA.pdf|Datasheet du MRF49XA]]
* Firmware de l'ATMega328p : [[https://bigfile.univ-lille1.fr/get?k=qpgkFLtHGwszbpEgOyP|Lien 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 : [[https://bigfile.univ-lille1.fr/get?k=GanInTsS29ZOdIX9esL|Lien BigFile de Lille1]]
* Schéma de la nouvelle version du prototype, non réalisé : [[https://bigfile.univ-lille1.fr/get?k=aLcJi1fAkF2BglHkuNh|Lien 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).

Capteur Communicant Intelligent

2014-02-26T14:07:50Z

Nhusse : /* Prototype à base du MRF49XA */

== 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) ===

[[Fichier:AVRISP mkII.jpg|250px|thumb|left|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) ===

[[Fichier:Matos.jpg|400px|thumb|center|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) ===

[[Fichier:Xbee Pro Std.jpg|250px|thumb|left|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.

{| class="wikitable alternance center"
|+ Format d'une Trame
|-
|
! scope="col" | Base/Tourelle/Bracelet
! scope="col" | ID
! scope="col" | CMD
! scope="col" | Emission/Reponse Commande
! scope="col" | DATA
! scope="col" | Stuffing
! scope="col" | TOTAL
! scope="col" | NB OCTECTS
|-
! scope="row" | Nb de Bits
| 2
| 16
| 4
| 1
| 32
| 1
| 56
| 7
|}

{| class="wikitable alternance center"
|+ Format des DATA
| align="center" style="background:#f0f0f0;"|'''NUM'''
| align="center" style="background:#f0f0f0;"|'''CODE'''
| align="center" style="background:#f0f0f0;"|'''CMD'''
| align="center" style="background:#f0f0f0;"|'''EMETTEUR'''
| align="center" style="background:#f0f0f0;"|'''DATA [nb de bits]'''
| align="center" style="background:#f0f0f0;"|'''Nb Bits de DATA Utilisés'''
| align="center" style="background:#f0f0f0;"|'''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.

==== Partie Station de Base ====

=== Séance 19 (08/11/13) ===

==== Partie PCB ====

* Développement du PCB : ATMega328p

==== Partie Station de Base ====

=== 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 ====

=== 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 ====

=== 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 ====

=== 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
[[Fichier:Schematic.png|centre|400px|alt=Schematic - Capteur Communicant Intelligent V1|vignette|Schéma]]
[[Fichier:Typon.png|centre|400px|alt=Typon - Capteur Communicant Intelligent V1|vignette|Typon]]

=== Séance 27 (27/11/13) ===

==== Partie PCB ====

[[Fichier:Proto1 MRFXA49.jpg|250px|thumb|left|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 ===

[[Fichier:Tx mrf.png|250px|thumb|left|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 ===

* [[Fichier:MRF49XA|Datasheet du MRF49XA]]
* Firmware de l'ATMega328p : [[https://bigfile.univ-lille1.fr/get?k=qpgkFLtHGwszbpEgOyP|Lien 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 : [[https://bigfile.univ-lille1.fr/get?k=GanInTsS29ZOdIX9esL|Lien BigFile de Lille1]]
* Schéma de la nouvelle version du prototype, non réalisé : [[https://bigfile.univ-lille1.fr/get?k=aLcJi1fAkF2BglHkuNh|Lien 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).

Capteur Communicant Intelligent

2014-02-26T14:07:26Z

Nhusse : /* Phase 3 : Mise en place et test du protocole */

== 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) ===

[[Fichier:AVRISP mkII.jpg|250px|thumb|left|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) ===

[[Fichier:Matos.jpg|400px|thumb|center|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) ===

[[Fichier:Xbee Pro Std.jpg|250px|thumb|left|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.

{| class="wikitable alternance center"
|+ Format d'une Trame
|-
|
! scope="col" | Base/Tourelle/Bracelet
! scope="col" | ID
! scope="col" | CMD
! scope="col" | Emission/Reponse Commande
! scope="col" | DATA
! scope="col" | Stuffing
! scope="col" | TOTAL
! scope="col" | NB OCTECTS
|-
! scope="row" | Nb de Bits
| 2
| 16
| 4
| 1
| 32
| 1
| 56
| 7
|}

{| class="wikitable alternance center"
|+ Format des DATA
| align="center" style="background:#f0f0f0;"|'''NUM'''
| align="center" style="background:#f0f0f0;"|'''CODE'''
| align="center" style="background:#f0f0f0;"|'''CMD'''
| align="center" style="background:#f0f0f0;"|'''EMETTEUR'''
| align="center" style="background:#f0f0f0;"|'''DATA [nb de bits]'''
| align="center" style="background:#f0f0f0;"|'''Nb Bits de DATA Utilisés'''
| align="center" style="background:#f0f0f0;"|'''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.

==== Partie Station de Base ====

=== Séance 19 (08/11/13) ===

==== Partie PCB ====

* Développement du PCB : ATMega328p

==== Partie Station de Base ====

=== 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 ====

=== 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 ====

=== 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 ====

=== 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
[[Fichier:Schematic.png|centre|400px|alt=Schematic - Capteur Communicant Intelligent V1|vignette|Schéma]]
[[Fichier:Typon.png|centre|400px|alt=Typon - Capteur Communicant Intelligent V1|vignette|Typon]]

=== Séance 27 (27/11/13) ===

==== Partie PCB ====

[[Fichier:Proto1 MRFXA49.jpg|250px|thumb|left|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 ===

[[Fichier:Tx mrf.png|250px|thumb|left|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 ===

* [[Fichier:MRF49XA|Datasheet du MRF49XA]]
* Firmware de l'ATMega328p : [[https://bigfile.univ-lille1.fr/get?k=qpgkFLtHGwszbpEgOyP|Lien 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 : [[https://bigfile.univ-lille1.fr/get?k=GanInTsS29ZOdIX9esL|Lien BigFile de Lille1]]
* Schéma de la nouvelle version du prototype, non réalisé : [[https://bigfile.univ-lille1.fr/get?k=aLcJi1fAkF2BglHkuNh|Lien BigFile de Lille1]]

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

Fichier:MRF49XA.pdf

2014-02-26T13:52:31Z

Nhusse : Datasheet du MRF49XA

Datasheet du MRF49XA

Capteur Communicant Intelligent

2014-02-26T13:49:13Z

Nhusse : /* Phase 3 : Mise en place et test du protocole */

Capteur Communicant Intelligent

2014-02-26T13:48:43Z

Nhusse : /* Phase 3 : Mise en place et test du protocole */

Capteur Communicant Intelligent

2014-02-26T13:48:14Z

Nhusse : /* Phase 3 : Mise en place et test du protocole */

Capteur Communicant Intelligent

2014-02-26T13:47:11Z

Nhusse : /* Phase 3 : Mise en place et test du protocole */

== 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) ===

[[Fichier:AVRISP mkII.jpg|250px|thumb|left|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) ===

[[Fichier:Matos.jpg|400px|thumb|center|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) ===

[[Fichier:Xbee Pro Std.jpg|250px|thumb|left|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.

{| class="wikitable alternance center"
|+ Format d'une Trame
|-
|
! scope="col" | Base/Tourelle/Bracelet
! scope="col" | ID
! scope="col" | CMD
! scope="col" | Emission/Reponse Commande
! scope="col" | DATA
! scope="col" | Stuffing
! scope="col" | TOTAL
! scope="col" | NB OCTECTS
|-
! scope="row" | Nb de Bits
| 2
| 16
| 4
| 1
| 32
| 1
| 56
| 7
|}

{| class="wikitable alternance center"
|+ Format des DATA
| align="center" style="background:#f0f0f0;"|'''NUM'''
| align="center" style="background:#f0f0f0;"|'''CODE'''
| align="center" style="background:#f0f0f0;"|'''CMD'''
| align="center" style="background:#f0f0f0;"|'''EMETTEUR'''
| align="center" style="background:#f0f0f0;"|'''DATA [nb de bits]'''
| align="center" style="background:#f0f0f0;"|'''Nb Bits de DATA Utilisés'''
| align="center" style="background:#f0f0f0;"|'''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.

==== Partie Station de Base ====

=== Séance 19 (08/11/13) ===

==== Partie PCB ====

* Développement du PCB : ATMega328p

==== Partie Station de Base ====

=== 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 ====

=== 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 ====

=== 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 ====

=== 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
[[Fichier:Schematic.png|centre|400px|alt=Schematic - Capteur Communicant Intelligent V1|vignette|Schéma]]
[[Fichier:Typon.png|centre|400px|alt=Typon - Capteur Communicant Intelligent V1|vignette|Typon]]

=== Séance 27 (27/11/13) ===

==== Partie PCB ====

[[Fichier:Proto1 MRFXA49.jpg|250px|thumb|left|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 ===

[[Fichier:Tx mrf.png|250px|thumb|left]]
==== 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.

Capteur Communicant Intelligent

2014-02-26T13:46:31Z

Nhusse : /* Débogage du prototype */

== 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) ===

[[Fichier:AVRISP mkII.jpg|250px|thumb|left|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) ===

[[Fichier:Matos.jpg|400px|thumb|center|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) ===

[[Fichier:Xbee Pro Std.jpg|250px|thumb|left|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.

{| class="wikitable alternance center"
|+ Format d'une Trame
|-
|
! scope="col" | Base/Tourelle/Bracelet
! scope="col" | ID
! scope="col" | CMD
! scope="col" | Emission/Reponse Commande
! scope="col" | DATA
! scope="col" | Stuffing
! scope="col" | TOTAL
! scope="col" | NB OCTECTS
|-
! scope="row" | Nb de Bits
| 2
| 16
| 4
| 1
| 32
| 1
| 56
| 7
|}

{| class="wikitable alternance center"
|+ Format des DATA
| align="center" style="background:#f0f0f0;"|'''NUM'''
| align="center" style="background:#f0f0f0;"|'''CODE'''
| align="center" style="background:#f0f0f0;"|'''CMD'''
| align="center" style="background:#f0f0f0;"|'''EMETTEUR'''
| align="center" style="background:#f0f0f0;"|'''DATA [nb de bits]'''
| align="center" style="background:#f0f0f0;"|'''Nb Bits de DATA Utilisés'''
| align="center" style="background:#f0f0f0;"|'''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.

==== Partie Station de Base ====

=== Séance 19 (08/11/13) ===

==== Partie PCB ====

* Développement du PCB : ATMega328p

==== Partie Station de Base ====

=== 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 ====

=== 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 ====

=== 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 ====

=== 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
[[Fichier:Schematic.png|centre|400px|alt=Schematic - Capteur Communicant Intelligent V1|vignette|Schéma]]
[[Fichier:Typon.png|centre|400px|alt=Typon - Capteur Communicant Intelligent V1|vignette|Typon]]

=== Séance 27 (27/11/13) ===

==== Partie PCB ====

[[Fichier:Proto1 MRFXA49.jpg|250px|thumb|left|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 ===

==== Débogage du prototype ====
[[Fichier:Tx mrf.png|250px|thumb|left]]
* 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.

Fichier:Tx mrf.png

2014-02-26T13:44:14Z

Nhusse : Utilisation du registre de transmission du MRF49XA.

Utilisation du registre de transmission du MRF49XA.

Capteur Communicant Intelligent

2014-02-26T13:41:35Z

Nhusse :

== 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) ===

[[Fichier:AVRISP mkII.jpg|250px|thumb|left|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) ===

[[Fichier:Matos.jpg|400px|thumb|center|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) ===

[[Fichier:Xbee Pro Std.jpg|250px|thumb|left|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.

{| class="wikitable alternance center"
|+ Format d'une Trame
|-
|
! scope="col" | Base/Tourelle/Bracelet
! scope="col" | ID
! scope="col" | CMD
! scope="col" | Emission/Reponse Commande
! scope="col" | DATA
! scope="col" | Stuffing
! scope="col" | TOTAL
! scope="col" | NB OCTECTS
|-
! scope="row" | Nb de Bits
| 2
| 16
| 4
| 1
| 32
| 1
| 56
| 7
|}

{| class="wikitable alternance center"
|+ Format des DATA
| align="center" style="background:#f0f0f0;"|'''NUM'''
| align="center" style="background:#f0f0f0;"|'''CODE'''
| align="center" style="background:#f0f0f0;"|'''CMD'''
| align="center" style="background:#f0f0f0;"|'''EMETTEUR'''
| align="center" style="background:#f0f0f0;"|'''DATA [nb de bits]'''
| align="center" style="background:#f0f0f0;"|'''Nb Bits de DATA Utilisés'''
| align="center" style="background:#f0f0f0;"|'''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.

==== Partie Station de Base ====

=== Séance 19 (08/11/13) ===

==== Partie PCB ====

* Développement du PCB : ATMega328p

==== Partie Station de Base ====

=== 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 ====

=== 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 ====

=== 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 ====

=== 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
[[Fichier:Schematic.png|centre|400px|alt=Schematic - Capteur Communicant Intelligent V1|vignette|Schéma]]
[[Fichier:Typon.png|centre|400px|alt=Typon - Capteur Communicant Intelligent V1|vignette|Typon]]

=== Séance 27 (27/11/13) ===

==== Partie PCB ====

[[Fichier:Proto1 MRFXA49.jpg|250px|thumb|left|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 ===

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

Capteur Communicant Intelligent

2013-12-17T20:28:41Z

Nhusse : /* Séance 36 (13/12/13) */

== 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) ===

[[Fichier:AVRISP mkII.jpg|250px|thumb|left|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) ===

[[Fichier:Matos.jpg|400px|thumb|center|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) ===

[[Fichier:Xbee Pro Std.jpg|250px|thumb|left|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.

{| class="wikitable alternance center"
|+ Format d'une Trame
|-
|
! scope="col" | Base/Tourelle/Bracelet
! scope="col" | ID
! scope="col" | CMD
! scope="col" | Emission/Reponse Commande
! scope="col" | DATA
! scope="col" | Stuffing
! scope="col" | TOTAL
! scope="col" | NB OCTECTS
|-
! scope="row" | Nb de Bits
| 2
| 16
| 4
| 1
| 32
| 1
| 56
| 7
|}

{| class="wikitable alternance center"
|+ Format des DATA
| align="center" style="background:#f0f0f0;"|'''NUM'''
| align="center" style="background:#f0f0f0;"|'''CODE'''
| align="center" style="background:#f0f0f0;"|'''CMD'''
| align="center" style="background:#f0f0f0;"|'''EMETTEUR'''
| align="center" style="background:#f0f0f0;"|'''DATA [nb de bits]'''
| align="center" style="background:#f0f0f0;"|'''Nb Bits de DATA Utilisés'''
| align="center" style="background:#f0f0f0;"|'''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.

==== Partie Station de Base ====

=== Séance 19 (08/11/13) ===

==== Partie PCB ====

* Développement du PCB : ATMega328p

==== Partie Station de Base ====

=== 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 ====

=== 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 ====

=== 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 ====

=== 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
[[Fichier:Schematic.png|centre|400px|alt=Schematic - Capteur Communicant Intelligent V1|vignette|Schéma]]
[[Fichier:Typon.png|centre|400px|alt=Typon - Capteur Communicant Intelligent V1|vignette|Typon]]

=== Séance 27 (27/11/13) ===

==== Partie PCB ====

[[Fichier:Proto1 MRFXA49.jpg|250px|thumb|left|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 34 (11/12/13) ===

=== Séance 35 (12/12/13) ===

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

=== Séance 37 (18/12/13) ===

Capteur Communicant Intelligent

2013-12-17T20:27:13Z

Nhusse : /* Séance 36 (13/12/13) */

== 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) ===

[[Fichier:AVRISP mkII.jpg|250px|thumb|left|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) ===

[[Fichier:Matos.jpg|400px|thumb|center|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) ===

[[Fichier:Xbee Pro Std.jpg|250px|thumb|left|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.

{| class="wikitable alternance center"
|+ Format d'une Trame
|-
|
! scope="col" | Base/Tourelle/Bracelet
! scope="col" | ID
! scope="col" | CMD
! scope="col" | Emission/Reponse Commande
! scope="col" | DATA
! scope="col" | Stuffing
! scope="col" | TOTAL
! scope="col" | NB OCTECTS
|-
! scope="row" | Nb de Bits
| 2
| 16
| 4
| 1
| 32
| 1
| 56
| 7
|}

{| class="wikitable alternance center"
|+ Format des DATA
| align="center" style="background:#f0f0f0;"|'''NUM'''
| align="center" style="background:#f0f0f0;"|'''CODE'''
| align="center" style="background:#f0f0f0;"|'''CMD'''
| align="center" style="background:#f0f0f0;"|'''EMETTEUR'''
| align="center" style="background:#f0f0f0;"|'''DATA [nb de bits]'''
| align="center" style="background:#f0f0f0;"|'''Nb Bits de DATA Utilisés'''
| align="center" style="background:#f0f0f0;"|'''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.

==== Partie Station de Base ====

=== Séance 19 (08/11/13) ===

==== Partie PCB ====

* Développement du PCB : ATMega328p

==== Partie Station de Base ====

=== 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 ====

=== 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 ====

=== 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 ====

=== 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
[[Fichier:Schematic.png|centre|400px|alt=Schematic - Capteur Communicant Intelligent V1|vignette|Schéma]]
[[Fichier:Typon.png|centre|400px|alt=Typon - Capteur Communicant Intelligent V1|vignette|Typon]]

=== Séance 27 (27/11/13) ===

==== Partie PCB ====

[[Fichier:Proto1 MRFXA49.jpg|250px|thumb|left|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 34 (11/12/13) ===

=== Séance 35 (12/12/13) ===

=== Séance 36 (13/12/13) ===

* Problème de communication peut-être du à l'absence d'une inductance dans le ballun de la carte.

=== Séance 37 (18/12/13) ===

Capteur Communicant Intelligent

2013-12-17T20:22:57Z

Nhusse : /* Séance 33 (10/12/13) */

== 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) ===

[[Fichier:AVRISP mkII.jpg|250px|thumb|left|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) ===

[[Fichier:Matos.jpg|400px|thumb|center|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) ===

[[Fichier:Xbee Pro Std.jpg|250px|thumb|left|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.

{| class="wikitable alternance center"
|+ Format d'une Trame
|-
|
! scope="col" | Base/Tourelle/Bracelet
! scope="col" | ID
! scope="col" | CMD
! scope="col" | Emission/Reponse Commande
! scope="col" | DATA
! scope="col" | Stuffing
! scope="col" | TOTAL
! scope="col" | NB OCTECTS
|-
! scope="row" | Nb de Bits
| 2
| 16
| 4
| 1
| 32
| 1
| 56
| 7
|}

{| class="wikitable alternance center"
|+ Format des DATA
| align="center" style="background:#f0f0f0;"|'''NUM'''
| align="center" style="background:#f0f0f0;"|'''CODE'''
| align="center" style="background:#f0f0f0;"|'''CMD'''
| align="center" style="background:#f0f0f0;"|'''EMETTEUR'''
| align="center" style="background:#f0f0f0;"|'''DATA [nb de bits]'''
| align="center" style="background:#f0f0f0;"|'''Nb Bits de DATA Utilisés'''
| align="center" style="background:#f0f0f0;"|'''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.

==== Partie Station de Base ====

=== Séance 19 (08/11/13) ===

==== Partie PCB ====

* Développement du PCB : ATMega328p

==== Partie Station de Base ====

=== 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 ====

=== 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 ====

=== 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 ====

=== 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
[[Fichier:Schematic.png|centre|400px|alt=Schematic - Capteur Communicant Intelligent V1|vignette|Schéma]]
[[Fichier:Typon.png|centre|400px|alt=Typon - Capteur Communicant Intelligent V1|vignette|Typon]]

=== Séance 27 (27/11/13) ===

==== Partie PCB ====

[[Fichier:Proto1 MRFXA49.jpg|250px|thumb|left|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 34 (11/12/13) ===

=== Séance 35 (12/12/13) ===

=== Séance 36 (13/12/13) ===

Capteur Communicant Intelligent

2013-12-17T20:21:24Z

Nhusse : /* Séance 31 (05/12/13) */

== 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) ===

[[Fichier:AVRISP mkII.jpg|250px|thumb|left|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) ===

[[Fichier:Matos.jpg|400px|thumb|center|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) ===

[[Fichier:Xbee Pro Std.jpg|250px|thumb|left|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.

{| class="wikitable alternance center"
|+ Format d'une Trame
|-
|
! scope="col" | Base/Tourelle/Bracelet
! scope="col" | ID
! scope="col" | CMD
! scope="col" | Emission/Reponse Commande
! scope="col" | DATA
! scope="col" | Stuffing
! scope="col" | TOTAL
! scope="col" | NB OCTECTS
|-
! scope="row" | Nb de Bits
| 2
| 16
| 4
| 1
| 32
| 1
| 56
| 7
|}

{| class="wikitable alternance center"
|+ Format des DATA
| align="center" style="background:#f0f0f0;"|'''NUM'''
| align="center" style="background:#f0f0f0;"|'''CODE'''
| align="center" style="background:#f0f0f0;"|'''CMD'''
| align="center" style="background:#f0f0f0;"|'''EMETTEUR'''
| align="center" style="background:#f0f0f0;"|'''DATA [nb de bits]'''
| align="center" style="background:#f0f0f0;"|'''Nb Bits de DATA Utilisés'''
| align="center" style="background:#f0f0f0;"|'''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.

==== Partie Station de Base ====

=== Séance 19 (08/11/13) ===

==== Partie PCB ====

* Développement du PCB : ATMega328p

==== Partie Station de Base ====

=== 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 ====

=== 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 ====

=== 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 ====

=== 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
[[Fichier:Schematic.png|centre|400px|alt=Schematic - Capteur Communicant Intelligent V1|vignette|Schéma]]
[[Fichier:Typon.png|centre|400px|alt=Typon - Capteur Communicant Intelligent V1|vignette|Typon]]

=== Séance 27 (27/11/13) ===

==== Partie PCB ====

[[Fichier:Proto1 MRFXA49.jpg|250px|thumb|left|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) ===

=== Séance 34 (11/12/13) ===

=== Séance 35 (12/12/13) ===

=== Séance 36 (13/12/13) ===

Fichier:Schematic.png

2013-12-13T14:00:51Z

Nhusse : a téléversé une nouvelle version de « Fichier:Schematic.png »

Schematic - Capteur Communicant Intelligent V1
Nicolas Husse / Chalaux Bastien

Capteur Communicant Intelligent

2013-12-10T14:22:10Z

Nhusse : /* Partie PCB */

== 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) ===

* 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) ===

* 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) ===

[[Fichier:Xbee Pro Std.jpg|250px|thumb|left|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.

{| class="wikitable alternance center"
|+ Format d'une Trame
|-
|
! scope="col" | Base/Tourelle/Bracelet
! scope="col" | ID
! scope="col" | CMD
! scope="col" | Emission/Reponse Commande
! scope="col" | DATA
! scope="col" | Stuffing
! scope="col" | TOTAL
! scope="col" | NB OCTECTS
|-
! scope="row" | Nb de Bits
| 2
| 16
| 4
| 1
| 32
| 1
| 56
| 7
|}

{| class="wikitable alternance center"
|+ Format des DATA
| align="center" style="background:#f0f0f0;"|'''NUM'''
| align="center" style="background:#f0f0f0;"|'''CODE'''
| align="center" style="background:#f0f0f0;"|'''CMD'''
| align="center" style="background:#f0f0f0;"|'''EMETTEUR'''
| align="center" style="background:#f0f0f0;"|'''DATA [nb de bits]'''
| align="center" style="background:#f0f0f0;"|'''Nb Bits de DATA Utilisés'''
| align="center" style="background:#f0f0f0;"|'''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.

==== Partie Station de Base ====

=== Séance 19 (08/11/13) ===

==== Partie PCB ====

* Développement du PCB : ATMega328p

==== Partie Station de Base ====

=== 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 ====

=== 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 ====

=== 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 ====

=== 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
[[Fichier:Schematic.png|centre|400px|alt=Schematic - Capteur Communicant Intelligent V1|vignette|Schéma]]
[[Fichier:Typon.png|centre|400px|alt=Typon - Capteur Communicant Intelligent V1|vignette|Typon]]

=== Séance 27 (27/11/13) ===

==== Partie PCB ====

* Réalisation de 3 PCB MRF49XA + Ballun. Découverte des logicielles liés à la graveuse
-> Ajouter photos PCB
* 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.

=== Séance 33 (10/12/13) ===

=== Séance 34 (11/12/13) ===

=== Séance 35 (12/12/13) ===

=== Séance 36 (13/12/13) ===

Fichier:Typon.png

2013-12-10T14:15:19Z

Nhusse : Typon - Capteur Communicant Intelligent V1 Nicolas Husse / Chalaux Bastien

Typon - Capteur Communicant Intelligent V1
Nicolas Husse / Chalaux Bastien

Fichier:Schematic.png

2013-12-10T14:14:49Z

Nhusse : Schematic - Capteur Communicant Intelligent V1 Nicolas Husse / Chalaux Bastien

Schematic - Capteur Communicant Intelligent V1
Nicolas Husse / Chalaux Bastien

Capteur Communicant Intelligent

2013-12-08T21:41:06Z

Nhusse : /* Phase 2 : Développement de Prototypes */

Capteur Communicant Intelligent

2013-12-08T21:36:55Z

Nhusse : /* Phase 2 : Développement de Prototypes */

Vision déportée

2013-05-07T06:42:51Z

Nhusse : /* Rapport */

== Introduction ==
[[Image:étudiants.png|200px|thumb|upright|Etudiants]]
Le but de ce projet est de développer une tourelle équipée d'un caméra suivant le regard d'une personne.Le projet est constitué principalement de 3 parties:

* Communication à l'aide des modules Xbee

* Acquisition des données capteur (accéléromètre)

* Commande d'un ou plusieurs moteurs pour les mouvements du caméra.

Ce projet est en collaboration avec le département Conception Mécanique représenté par M. Rodolphe Astori et M. Aurelien Benechet.

* Ensuite une 4éme partie d'acquisition vidéo et transfert de vidéo pour afficher chez l'utilisateur.

[http://www.youtube.com/watch?v=FH0rIUhr-kQ&feature=youtu.be Lien provisoire vers la vidéo]

== Préparation du projet ==
===Matériel nécessaire===

* 2 Arduino Uno

* 2 Modules Xbee : 4214A-XBEE série S1

* 1 Accéléromètre équipé d'un gyroscope: ADLX345 / ITG-3200

* 3 Servomoteurs

* 1 Caméra

* SRAM 23K256

* 1 Une tourelle mécanique (Fourni par le département CM)

* 1 Casque (Fourni par le département CM)

{|
| [[Image:arduino.jpg|150px|thumb|upright|Arduino]]
| [[Image:Capteur.jpg|150px|thumb|upright|Capteur(Accéléromètre et Gyroscope]]
| [[Image:Xbee.jpg|150px|thumb|upright|Xbee]]
| [[Image:servo.jpg|150px|thumb|upright|Servomoteur]]
| [[Image:C3088.jpg|150px|thumb|upright|Caméra]]
|}

===Matériel de tests===

* 1 adapateur série - usb pour softwareserial.

* 1 tourelle de test

{|
| [[Image:tourelle.jpg|150px|thumb|upright|Tourelle de test]]
|}

== Avancement du projet ==
'''Lundi 4 Février 2013:'''

* Contact des encadrants du projet.

* Présentation du projet par M. Alexandre Boé.

* Discussion autour des différentes parties du projet.

'''Jeudi 7 Février 2013:'''
[[Image:Shield xbee.jpg|150px|thumb|upright|Shield Xbee]]

Durant cette séance, nous avons effectué la configuration de la communication sans fil à travers le protocole de communication ZigBee.
Pour garantir une communication entre deux modules xBee 4214A-XBEE on a défini :

Un identifiant réseau: 3005 (commande ATID)

Une adresse pour chaque module:(adresses 10 et 11)

1er Module ATMY10 - ATDL11

2éme Module ATMY11 - ATDL10

Enregistrement en Mémoire: ATWR

La vérification et les tests se font à l'aide de deux ordinateurs sous terminal série qui communiquent à une même vitesse (9600 BAUD).(Partie achevée)

'''Lundi 11 Février 2013:'''
[[Image:Partiecapteur.jpg|150px|thumb|upright|Installation xbee et capteur]]

* Utilisation d'un accéléromètre et récupération des données sur le terminal série d'un arduino suivant 3 axes.(Tests techniques)

* Communication des données via le module Xbee entre deux Arduino.(Test techniques)

Problème de vérification sur terminal série et envoi des données en même temps => recours à une connexion série supplémentaire sur les broches d'arduino.

* Réunion de spécification et avancement de projet avec les enseignants CM.

Répartition de travail pour la prochaine séance sur 2 parties:

* Communication et tests connexion série (Nicolas)

* Commande servomoteur (Adel)

'''Jeudi 14 Février 2013:'''

* Élaboration et tests de la commande d'un mini servomoteur en utilisant un Arduino et un potentiomètre fonctionnant sur 180°.(Partie achevée et fonctionnelle)

* Communication sur une liaison série parallèle.(Partie non achevée) => emprunt d'un module Xbee et une liaison série pour travailler pendant les vacances.

'''Vacances:'''

Il est à noter que pour pouvoir exploiter un port série logiciel à l'aide la librairie SoftwareSerial (pour le débuggage par exemple), il faut utiliser un MAX232 (Niveaux TTL et RS-232 différents).

* La configuration automatique du Xbee par l'Arduino est opérationnel.

* Montage:

1 Condensateur 100nF entre le pin 1 et 3 du MAX232

1 Condensateur 100nF entre le pin 4 et 5 du MAX232

1 Condensateur 100nF entre le pin 2 du MAX232 et VCC

1 Condensateur 100nF entre le pin 6 du MAX232 et GND

Le pin 16 du MAX232 est relié au VCC

Le pin 15 du MAX232 est relié au GND et à la broche GND du RS-232 (fil noir)

Le pin 14 du MAX232 est relié à la broche TX du RS-232 (fil rouge)

Le pin 13 du MAX232 est relié à la broche RX du RS-232 (fil jaune)

Le pin 12 du MAX232 est relié au pin 10 de l'Arduino

Le pin 11 du MAX232 est relié au pin 11 de l'Arduino

'''Lundi 25 Février 2013'''

* Test du code développé en vacances en utilisation l'Arduino de l'émission équipé d'un module Xbee.

'''Mercredi 27 Févier 2013'''

* Développement de la fonctionnalité de l'émission par récupération des valeurs de l'accéléromètre et transmission avec Xbee.

* Test unitaire sur Arduino de programme à l'émission.

* Suivi d'avancement de projet et discussion sur les solutions à proposer pour évoluer le système.

'''Jeudi 28 Février 2013'''

* Développement sur Arduino d'une fonction permettant de récupérer à partir du module xbee les valeurs de l'accéléromètre selon les trois axes (x,y,z) à travers une lecture sur le terminal série de l'Arduino.

* Vérification des valeurs obtenu à travers l'utilisation de softwareSerial en faisant une écriture sur ce terminal. ==> Partie Fonctionnelle

'''Lundi 04 Mars 2013'''

[[Image:Partie moteurs.jpg|150px|thumb|upright|Partie servomoteurs]]
* Phase d'intégration entre la partie commande de moteur et la partie récupération des valeurs de l'accéléromètre reçu par Xbee.

* Test d'intégration en utilisant les valeurs d'un seul axe x.

Partie non achevée : Test en cours et identification d'une réponse du moteur non correcte.

'''Mercredi 06 Mars 2013'''

Résultat des tests d'intégration:

* Observation d'une oscillation dans le mouvement de servomoteur.

* Détection d'une incompatibilité entre la libraire softwareserial.h et servo.h.

* Problème de lecture sur terminal série à cause de l'absence de Serial.available().

'''Jeudi 07 Mars 2013'''

* Mise en œuvre des corrections nécessaires pour modifier la réponse de moteur et la stabiliser.

* Étalonnage des valeurs de moteur entre 0 et 180 en fonction des valeurs de x reçus.

* Début de l'intégration de 3 servomoteurs à la fois.

* Récupération d'une tourelle de test chez M. Aurelien Benechet.

'''Lundi 11 Mars 2013'''

* Axes X et Y fonctionnels, cependant au bout d'un certain (ou d'un certain nombre de mesure ?) les servos s’arrêtent de fonctionner...

* Prochaine séance: régler la position initiale.

'''Mercredi 13 Mars 2013'''

* Le problème des servomoteurs est réglé.

* Les mesures selon les 3 axes:

L'axe x : axe longitudinal ou axe de roulis --> Fonctionnel

L'axe y : axe transversal ou axe de tangage --> Fonctionnel

L'axe z : axe de lacet --> Non Fonctionnel

'''Lundi 18 Mars 2013'''

* Poursuite des tests pour régler les résultats incohérents sur l'axe z.

'''Mercredi 20 Mars 2013'''

* Nos propres tests et une recherche bibliographique nous permet d'affirmer que on ne peut détecter un mouvement de lacet à travers un accéléromètre seulement.

'''Jeudi 21 Mars 2013'''

* Solution: On a fait un changement de matériel pour remplacer l’accéléromètre par un nouveau composant intégrant:

- L’accéléromètre ADXL345 (déjà utilisé)

- Gyroscope ITG-3200

--> Modification de la technologie de communication de SPI vers I2C.

* Début de la partie acquisition à partir d'une caméra (C3088).

'''Lundi 25 Mars 2013'''

* Configuration en I2C de nouveau composant (Accéléromètre + Gyroscope)

* Lecture de la documentation du module C3088 (avec la caméra ov6620).

'''Mercredi 27 Mars 2013'''

* Développement du programme I2C permettant de communiquer avec la caméra en I2C.

'''Mercredi 3 Avril 2013'''

* Tests de la communication I2C avec la caméra --> Fonctionnel

* Début de la configuration de la caméra pour l'adapter à un fonctionnement sous microcontrôleur ATmega.

'''Jeudi 4 Avril 2013'''

* Configuration de la caméra:

- Format QCIF (176*144)

- YCrCb mode

- Réduction de nombre des images par seconde (fps).

* Début de l'acquisition des images à travers le terminal série de l'Arduino (fonctionnement à 115200 bauds).

--> Résultats non fonctionnels pour cette partie.

'''Lundi 8 avril 2013'''

* Pour travailler plus rapidement, nous avons effectué quelques optimisations de notre programme:

- Utilisation des ports de l'ATmega 2560 pour lire simultanément les 8 broches Y.

--> Possibilité d'utiliser un RAM externe pour stocker les données avant de l'envoyer via port série.

'''Vacances'''

* Partie Tracking : Récupération des trois angles nécessaire pour commander les servomoteurs à partir du gyromètre et de l'accéléromètre en utilisant une librairie existante. Testé sans Xbee.

'''Lundi 29 avril 2013'''

* Partie Tracking :Ajout de la communication par Xbee entre l'Arduino qui récupère les angles et celui qui commande les servomoteurs.

* Partie caméra : Intégration d'une mémoire SRAM 23K256 pour la sauvegarde des données.

'''Jeudi 2 Mai 2013'''

* Assemblage du dispositif de prototypage pour la vidéo.

== Bilan ==

Nous avons fait le bilan d'avancement de notre projet:

* Détection de mouvements de la tête:Fonctionnel

* Communication sans fil(Xbee):Fonctionnel

* Commande des servomoteurs:Fonctionnel

* Acquisition de flux vidéo:Configuration fonctionnel, Capture non fonctionnel

{|
| [[Image:Casque_f.png|150px|thumb|upright|Casque de détection]]
| [[Image:Tourelle_de_prototype.jpg|150px|thumb|upright|Tourelle de prototypage]]
| [[Image:Camera_f.png|150px|thumb|upright|Caméra C3008]]
|}

== Difficultés rencontrées ==
Les difficultés rencontrées durant ce projet sont :

* Synchronisation de signal vidéo à travers un micro-contrôleur.(Problème principale)

* Utilisation d'un pur accéléromètre au début de projet pour mesurer la rotation de lacet --> physiquement impossible.

* Récupérer la bonne information du gyroscope à travers les parasites.

== Conclusion ==
A travers ce projet, nous avons réussi à réaliser la partie principale de la vision déportée avec :

* La communication Xbee

* Acquisition des valeurs des capteurs (accéléromètre + gyroscope)

* Traitement des données récupérées.

* Commande des moteurs de la tourelle selon 3 axes de rotation.

mais nous n'avons pas réussi à finir la partie acquisition et transfert des données caméra.

== Rapport ==
[[Fichier:Rapport projet vision déportée.pdf]]

Fichier:Rapport projet vision déportée.pdf

2013-05-07T06:41:32Z

Nhusse : Rapport projet vision déportée - Nicolas Husse - Adel Aljane

Rapport projet vision déportée - Nicolas Husse - Adel Aljane

Vision déportée

2013-05-06T19:12:18Z

Nhusse : /* Difficultés rencontrées */

Vision déportée

2013-05-05T18:41:33Z

Nhusse :

== Introduction ==
Le but de ce projet est de développer une tourelle équipée d'un caméra suivant le regard d'une personne.Le projet est constitué principalement de 3 parties:

* Communication à l'aide des modules Xbee

* Acquisition des données capteur (accéléromètre)

* Commande d'un ou plusieurs moteurs pour les mouvements du caméra.

Ce projet est en collaboration avec le département Conception Mécanique représenté par M. Rodolphe Astori et M. Aurelien Benechet.

* Ensuite une 4éme partie d'acquisition vidéo et transfert de vidéo pour afficher chez l'utilisateur.

[http://www.youtube.com/watch?v=FH0rIUhr-kQ&feature=youtu.be Lien provisoire vers la vidéo]

== Préparation du projet ==
===Matériel nécessaire===

* 2 Arduino Uno

* 2 Modules Xbee : 4214A-XBEE série S1

* 1 Accéléromètre équipé d'un gyroscope: ADLX345 / ITG-3200

* 3 Servomoteurs

* 1 Caméra

* SRAM 23K256

* 1 Une tourelle mécanique (Fourni par le département CM)

* 1 Casque (Fourni par le département CM)

{|
| [[Image:arduino.jpg|150px|thumb|upright|Arduino]]
| [[Image:Capteur.jpg|150px|thumb|upright|Capteur(Accéléromètre et Gyroscope]]
| [[Image:Xbee.jpg|150px|thumb|upright|Xbee]]
| [[Image:servo.jpg|150px|thumb|upright|Servomoteur]]
| [[Image:C3088.jpg|150px|thumb|upright|Caméra]]
|}

===Matériel de tests===

* 1 adapateur série - usb pour softwareserial.

* 1 tourelle de test

{|
| [[Image:tourelle.jpg|150px|thumb|upright|Tourelle de test]]
|}

== Avancement du projet ==
'''Lundi 4 Février 2013:'''

* Contact des encadrants du projet.

* Présentation du projet par M. Alexandre Boé.

* Discussion autour des différentes parties du projet.

'''Jeudi 7 Février 2013:'''

Durant cette séance, nous avons effectué la configuration de la communication sans fil à travers le protocole de communication ZigBee.
Pour garantir une communication entre deux modules xBee 4214A-XBEE on a défini :

Un identifiant réseau: 3005 (commande ATID)

Une adresse pour chaque module:(adresses 10 et 11)

1er Module ATMY10 - ATDL11

2éme Module ATMY11 - ATDL10

Enregistrement en Mémoire: ATWR

La vérification et les tests se font à l'aide de deux ordinateurs sous terminal série qui communiquent à une même vitesse (9600 BAUD).(Partie achevée)

'''Lundi 11 Février 2013:'''

* Utilisation d'un accéléromètre et récupération des données sur le terminal série d'un arduino suivant 3 axes.(Tests techniques)

* Communication des données via le module Xbee entre deux Arduino.(Test techniques)

Problème de vérification sur terminal série et envoi des données en même temps => recours à une connexion série supplémentaire sur les broches d'arduino.

* Réunion de spécification et avancement de projet avec les enseignants CM.

Répartition de travail pour la prochaine séance sur 2 parties:

* Communication et tests connexion série (Nicolas)

* Commande servomoteur (Adel)

'''Jeudi 14 Février 2013:'''

* Élaboration et tests de la commande d'un mini servomoteur en utilisant un Arduino et un potentiomètre fonctionnant sur 180°.(Partie achevée et fonctionnelle)

* Communication sur une liaison série parallèle.(Partie non achevée) => emprunt d'un module Xbee et une liaison série pour travailler pendant les vacances.

'''Vacances:'''

Il est à noter que pour pouvoir exploiter un port série logiciel à l'aide la librairie SoftwareSerial (pour le débuggage par exemple), il faut utiliser un MAX232 (Niveaux TTL et RS-232 différents).

* La configuration automatique du Xbee par l'Arduino est opérationnel.

* Montage:

1 Condensateur 100nF entre le pin 1 et 3 du MAX232

1 Condensateur 100nF entre le pin 4 et 5 du MAX232

1 Condensateur 100nF entre le pin 2 du MAX232 et VCC

1 Condensateur 100nF entre le pin 6 du MAX232 et GND

Le pin 16 du MAX232 est relié au VCC

Le pin 15 du MAX232 est relié au GND et à la broche GND du RS-232 (fil noir)

Le pin 14 du MAX232 est relié à la broche TX du RS-232 (fil rouge)

Le pin 13 du MAX232 est relié à la broche RX du RS-232 (fil jaune)

Le pin 12 du MAX232 est relié au pin 10 de l'Arduino

Le pin 11 du MAX232 est relié au pin 11 de l'Arduino

'''Lundi 25 Février 2013'''

* Test du code développé en vacances en utilisation l'Arduino de l'émission équipé d'un module Xbee.

'''Mercredi 27 Févier 2013'''

* Développement de la fonctionnalité de l'émission par récupération des valeurs de l'accéléromètre et transmission avec Xbee.

* Test unitaire sur Arduino de programme à l'émission.

* Suivi d'avancement de projet et discussion sur les solutions à proposer pour évoluer le système.

'''Jeudi 28 Février 2013'''

* Développement sur Arduino d'une fonction permettant de récupérer à partir du module xbee les valeurs de l'accéléromètre selon les trois axes (x,y,z) à travers une lecture sur le terminal série de l'Arduino.

* Vérification des valeurs obtenu à travers l'utilisation de softwareSerial en faisant une écriture sur ce terminal. ==> Partie Fonctionnelle

'''Lundi 04 Mars 2013'''

* Phase d'intégration entre la partie commande de moteur et la partie récupération des valeurs de l'accéléromètre reçu par Xbee.

* Test d'intégration en utilisant les valeurs d'un seul axe x.

Partie non achevée : Test en cours et identification d'une réponse du moteur non correcte.

'''Mercredi 06 Mars 2013'''

Résultat des tests d'intégration:

* Observation d'une oscillation dans le mouvement de servomoteur.

* Détection d'une incompatibilité entre la libraire softwareserial.h et servo.h.

* Problème de lecture sur terminal série à cause de l'absence de Serial.available().

'''Jeudi 07 Mars 2013'''

* Mise en œuvre des corrections nécessaires pour modifier la réponse de moteur et la stabiliser.

* Étalonnage des valeurs de moteur entre 0 et 180 en fonction des valeurs de x reçus.

* Début de l'intégration de 3 servomoteurs à la fois.

* Récupération d'une tourelle de test chez M. Aurelien Benechet.

'''Lundi 11 Mars 2013'''

* Axes X et Y fonctionnels, cependant au bout d'un certain (ou d'un certain nombre de mesure ?) les servos s’arrêtent de fonctionner...

* Prochaine séance: régler la position initiale.

'''Mercredi 13 Mars 2013'''

* Le problème des servomoteurs est réglé.

* Les mesures selon les 3 axes:

L'axe x : axe longitudinal ou axe de roulis --> Fonctionnel

L'axe y : axe transversal ou axe de tangage --> Fonctionnel

L'axe z : axe de lacet --> Non Fonctionnel

'''Lundi 18 Mars 2013'''

* Poursuite des tests pour régler les résultats incohérents sur l'axe z.

'''Mercredi 20 Mars 2013'''

* Nos propres tests et une recherche bibliographique nous permet d'affirmer que on ne peut détecter un mouvement de lacet à travers un accéléromètre seulement.

'''Jeudi 21 Mars 2013'''

* Solution: On a fait un changement de matériel pour remplacer l’accéléromètre par un nouveau composant intégrant:

- L’accéléromètre ADXL345 (déjà utilisé)

- Gyroscope ITG-3200

--> Modification de la technologie de communication de SPI vers I2C.

* Début de la partie acquisition à partir d'une caméra (C3088).

'''Lundi 25 Mars 2013'''

* Configuration en I2C de nouveau composant (Accéléromètre + Gyroscope)

* Lecture de la documentation du module C3088 (avec la caméra ov6620).

'''Mercredi 27 Mars 2013'''

* Développement du programme I2C permettant de communiquer avec la caméra en I2C.

'''Mercredi 3 Avril 2013'''

* Tests de la communication I2C avec la caméra --> Fonctionnel

* Début de la configuration de la caméra pour l'adapter à un fonctionnement sous microcontrôleur ATmega.

'''Jeudi 4 Avril 2013'''

* Configuration de la caméra:

- Format QCIF (176*144)

- YCrCb mode

- Réduction de nombre des images par seconde (fps).

* Début de l'acquisition des images à travers le terminal série de l'Arduino (fonctionnement à 115200 bauds).

--> Résultats non fonctionnels pour cette partie.

'''Lundi 8 avril 2013'''

* Pour travailler plus rapidement, nous avons effectué quelques optimisations de notre programme:

- Utilisation des ports de l'ATmega 2560 pour lire simultanément les 8 broches Y.

--> Possibilité d'utiliser un RAM externe pour stocker les données avant de l'envoyer via port série.

'''Vacances'''

* Partie Tracking : Récupération des trois angles nécessaire pour commander les servomoteurs à partir du gyromètre et de l'accéléromètre en utilisant une librairie existante. Testé sans Xbee.

'''Lundi 29 avril 2013'''

* Partie Tracking :Ajout de la communication par Xbee entre l'Arduino qui récupère les angles et celui qui commande les servomoteurs.

* Partie caméra : Intégration d'une mémoire SRAM 23K256 pour la sauvegarde des données.

'''Jeudi 2 Mai 2013'''

* Assemblage du dispositif de prototypage pour la vidéo.

== Bilan ==

Nous avons fait le bilan d'avancement de notre projet:

== Difficultés rencontrées ==
Les difficultés rencontrées durant ce projet sont :

* Synchronisation de signal vidéo à travers un micro-contrôleur.(Problème principale)

* Utilisation d'un pur accéléromètre au début de projet pour mesurer la rotation de lacet --> physiquement impossible.

== Conclusion ==
A travers ce projet, nous avons réussi à réaliser la partie principale de la vision déportée avec :

* La communication Xbee

* Acquisition des valeurs des capteurs (accéléromètre + gyroscope)

* Traitement des données récupérées.

* Commande des moteurs de la tourelle selon 3 axes de rotation.

mais nous n'avons pas réussi à finir la partie acquisition et transfert des données caméra.

Vision déportée

2013-04-29T15:13:36Z

Nhusse : /* Avancement du projet */

== Introduction ==
Le but de ce projet est de développer une tourelle équipée d'un caméra suivant le regard d'une personne.Le projet est constitué principalement de 3 parties:

* Communication à l'aide des modules Xbee

* Acquisition des données capteur (accéléromètre)

* Commande d'un ou plusieurs moteurs pour les mouvements du caméra.

Ce projet est en collaboration avec le département Conception Mécanique représenté par M. Rodolphe Astori et M. Aurelien Benechet.

== Préparation du projet ==
===Matériel nécessaire===

* 2 Arduino Uno

* 2 Modules Xbee : 4214A-XBEE série S1

* 1 Accéléromètre : ADLX345

* 3 Servomoteurs

* 1 Caméra

* 1 Une tourelle mécanique (Fourni par le département CM)

* 1 Casque (Fourni par le département CM)

===Matériel de tests===

* 1 adapateur série - usb pour softwareserial.

* 3 Mini servomoteurs de Kit arduino.

* 1 tourelle de test

== Avancement du projet ==
'''Lundi 4 Février 2013:'''

* Contact des encadrants du projet.

* Présentation du projet par M. Alexandre Boé.

* Discussion autour des différentes parties du projet.

'''Jeudi 7 Février 2013:'''

Durant cette séance, nous avons effectué la configuration de la communication sans fil à travers le protocole de communication ZigBee.
Pour garantir une communication entre deux modules xBee 4214A-XBEE on a défini :

Un identifiant réseau: 3005 (commande ATID)

Une adresse pour chaque module:(adresses 10 et 11)

1er Module ATMY10 - ATDL11

2éme Module ATMY11 - ATDL10

Enregistrement en Mémoire: ATWR

La vérification et les tests se font à l'aide de deux ordinateurs sous terminal série qui communiquent à une même vitesse (9600 BAUD).(Partie achevée)

'''Lundi 11 Février 2013:'''

* Utilisation d'un accéléromètre et récupération des données sur le terminal série d'un arduino suivant 3 axes.(Tests techniques)

* Communication des données via le module Xbee entre deux Arduino.(Test techniques)

Problème de vérification sur terminal série et envoi des données en même temps => recours à une connexion série supplémentaire sur les broches d'arduino.

* Réunion de spécification et avancement de projet avec les enseignants CM.

Répartition de travail pour la prochaine séance sur 2 parties:

* Communication et tests connexion série (Nicolas)

* Commande servomoteur (Adel)

'''Jeudi 14 Février 2013:'''

* Élaboration et tests de la commande d'un mini servomoteur en utilisant un Arduino et un potentiomètre fonctionnant sur 180°.(Partie achevée et fonctionnelle)

* Communication sur une liaison série parallèle.(Partie non achevée) => emprunt d'un module Xbee et une liaison série pour travailler pendant les vacances.

'''Vacances:'''

Il est à noter que pour pouvoir exploiter un port série logiciel à l'aide la librairie SoftwareSerial (pour le débuggage par exemple), il faut utiliser un MAX232 (Niveaux TTL et RS-232 différents).

* La configuration automatique du Xbee par l'Arduino est opérationnel.

* Montage:

1 Condensateur 100nF entre le pin 1 et 3 du MAX232

1 Condensateur 100nF entre le pin 4 et 5 du MAX232

1 Condensateur 100nF entre le pin 2 du MAX232 et VCC

1 Condensateur 100nF entre le pin 6 du MAX232 et GND

Le pin 16 du MAX232 est relié au VCC

Le pin 15 du MAX232 est relié au GND et à la broche GND du RS-232 (fil noir)

Le pin 14 du MAX232 est relié à la broche TX du RS-232 (fil rouge)

Le pin 13 du MAX232 est relié à la broche RX du RS-232 (fil jaune)

Le pin 12 du MAX232 est relié au pin 10 de l'Arduino

Le pin 11 du MAX232 est relié au pin 11 de l'Arduino

'''Lundi 25 Février 2013'''

* Test du code développé en vacances en utilisation l'Arduino de l'émission équipé d'un module Xbee.

'''Mercredi 27 Févier 2013'''

* Développement de la fonctionnalité de l'émission par récupération des valeurs de l'accéléromètre et transmission avec Xbee.

* Test unitaire sur Arduino de programme à l'émission.

* Suivi d'avancement de projet et discussion sur les solutions à proposer pour évoluer le système.

'''Jeudi 28 Février 2013'''

* Développement sur Arduino d'une fonction permettant de récupérer à partir du module xbee les valeurs de l'accéléromètre selon les trois axes (x,y,z) à travers une lecture sur le terminal série de l'Arduino.

* Vérification des valeurs obtenu à travers l'utilisation de softwareSerial en faisant une écriture sur ce terminal. ==> Partie Fonctionnelle

'''Lundi 04 Mars 2013'''

* Phase d'intégration entre la partie commande de moteur et la partie récupération des valeurs de l'accéléromètre reçu par Xbee.

* Test d'intégration en utilisant les valeurs d'un seul axe x.

Partie non achevée : Test en cours et identification d'une réponse du moteur non correcte.

'''Mercredi 06 Mars 2013'''

Résultat des tests d'intégration:

* Observation d'une oscillation dans le mouvement de servomoteur.

* Détection d'une incompatibilité entre la libraire softwareserial.h et servo.h.

* Problème de lecture sur terminal série à cause de l'absence de Serial.available().

'''Jeudi 07 Mars 2013'''

* Mise en œuvre des corrections nécessaires pour modifier la réponse de moteur et la stabiliser.

* Étalonnage des valeurs de moteur entre 0 et 180 en fonction des valeurs de x reçus.

* Début de l'intégration de 3 servomoteurs à la fois.

* Récupération d'une tourelle de test chez M. Aurelien Benechet.

'''Lundi 11 Mars 2013'''

* Axes X et Y fonctionnels, cependant au bout d'un certain (ou d'un certain nombre de mesure ?) les servos s’arrêtent de fonctionner...

* Prochaine séance: régler la position initiale.

'''Mercredi 13 Mars 2013'''

* Le problème des servomoteurs est réglé.

* Les mesures selon les 3 axes:

L'axe x : axe longitudinal ou axe de roulis --> Fonctionnel

L'axe y : axe transversal ou axe de tangage --> Fonctionnel

L'axe z : axe de lacet --> Non Fonctionnel

'''Lundi 18 Mars 2013'''

* Poursuite des tests pour régler les résultats incohérents sur l'axe z.

'''Mercredi 20 Mars 2013'''

* Nos propres tests et une recherche bibliographique nous permet d'affirmer que on ne peut détecter un mouvement de lacet à travers un accéléromètre seulement.

'''Jeudi 21 Mars 2013'''

* Solution: On a fait un changement de matériel pour remplacer l’accéléromètre par un nouveau composant intégrant:

- L’accéléromètre ADXL345 (déjà utilisé)

- Gyroscope ITG-3200

--> Modification de la technologie de communication de SPI vers I2C.

* Début de la partie acquisition à partir d'une caméra (C3088).

'''Lundi 25 Mars 2013'''

* Configuration en I2C de nouveau composant (Accéléromètre + Gyroscope)

* Lecture de la documentation du module C3088 (avec la caméra ov6620).

'''Mercredi 27 Mars 2013'''

* Développement du programme I2C permettant de communiquer avec la caméra en I2C.

'''Mercredi 3 Avril 2013'''

* Tests de la communication I2C avec la caméra --> Fonctionnel

* Début de la configuration de la caméra pour l'adapter à un fonctionnement sous microcontrôleur ATmega.

'''Jeudi 4 Avril 2013'''

* Configuration de la caméra:

- Format QCIF (176*144)

- YCrCb mode

- Réduction de nombre des images par seconde (fps).

* Début de l'acquisition des images à travers le terminal série de l'Arduino (fonctionnement à 115200 bauds).

--> Résultats non fonctionnels pour cette partie.

'''Lundi 8 avril 2013'''

* Pour travailler plus rapidement, nous avons effectué quelques optimisations de notre programme:

- Utilisation des ports de l'ATmega 2560 pour lire simultanément les 8 broches Y.

--> Possibilité d'utiliser un RAM externe pour stocker les données avant de l'envoyer via port série.

'''Vacances'''

* Récupération des trois angles nécessaire pour commander les servomoteurs à partir du gyromètre et de l'accéléromètre en utilisant une librairie existante. Testé sans Xbee.

'''Lundi 29 avril 2013'''

* Ajout de la communication par Xbee entre l'Arduino qui récupère les angles et celui qui commande les servomoteurs.

== Conclusion ==

Vision déportée

2013-04-29T15:13:13Z

Nhusse : /* Avancement du projet */

== Introduction ==
Le but de ce projet est de développer une tourelle équipée d'un caméra suivant le regard d'une personne.Le projet est constitué principalement de 3 parties:

* Communication à l'aide des modules Xbee

* Acquisition des données capteur (accéléromètre)

* Commande d'un ou plusieurs moteurs pour les mouvements du caméra.

Ce projet est en collaboration avec le département Conception Mécanique représenté par M. Rodolphe Astori et M. Aurelien Benechet.

== Préparation du projet ==
===Matériel nécessaire===

* 2 Arduino Uno

* 2 Modules Xbee : 4214A-XBEE série S1

* 1 Accéléromètre : ADLX345

* 3 Servomoteurs

* 1 Caméra

* 1 Une tourelle mécanique (Fourni par le département CM)

* 1 Casque (Fourni par le département CM)

===Matériel de tests===

* 1 adapateur série - usb pour softwareserial.

* 3 Mini servomoteurs de Kit arduino.

* 1 tourelle de test

== Avancement du projet ==
'''Lundi 4 Février 2013:'''

* Contact des encadrants du projet.

* Présentation du projet par M. Alexandre Boé.

* Discussion autour des différentes parties du projet.

'''Jeudi 7 Février 2013:'''

Durant cette séance, nous avons effectué la configuration de la communication sans fil à travers le protocole de communication ZigBee.
Pour garantir une communication entre deux modules xBee 4214A-XBEE on a défini :

Un identifiant réseau: 3005 (commande ATID)

Une adresse pour chaque module:(adresses 10 et 11)

1er Module ATMY10 - ATDL11

2éme Module ATMY11 - ATDL10

Enregistrement en Mémoire: ATWR

La vérification et les tests se font à l'aide de deux ordinateurs sous terminal série qui communiquent à une même vitesse (9600 BAUD).(Partie achevée)

'''Lundi 11 Février 2013:'''

* Utilisation d'un accéléromètre et récupération des données sur le terminal série d'un arduino suivant 3 axes.(Tests techniques)

* Communication des données via le module Xbee entre deux Arduino.(Test techniques)

Problème de vérification sur terminal série et envoi des données en même temps => recours à une connexion série supplémentaire sur les broches d'arduino.

* Réunion de spécification et avancement de projet avec les enseignants CM.

Répartition de travail pour la prochaine séance sur 2 parties:

* Communication et tests connexion série (Nicolas)

* Commande servomoteur (Adel)

'''Jeudi 14 Février 2013:'''

* Élaboration et tests de la commande d'un mini servomoteur en utilisant un Arduino et un potentiomètre fonctionnant sur 180°.(Partie achevée et fonctionnelle)

* Communication sur une liaison série parallèle.(Partie non achevée) => emprunt d'un module Xbee et une liaison série pour travailler pendant les vacances.

'''Vacances:'''

Il est à noter que pour pouvoir exploiter un port série logiciel à l'aide la librairie SoftwareSerial (pour le débuggage par exemple), il faut utiliser un MAX232 (Niveaux TTL et RS-232 différents).

* La configuration automatique du Xbee par l'Arduino est opérationnel.

* Montage:

1 Condensateur 100nF entre le pin 1 et 3 du MAX232

1 Condensateur 100nF entre le pin 4 et 5 du MAX232

1 Condensateur 100nF entre le pin 2 du MAX232 et VCC

1 Condensateur 100nF entre le pin 6 du MAX232 et GND

Le pin 16 du MAX232 est relié au VCC

Le pin 15 du MAX232 est relié au GND et à la broche GND du RS-232 (fil noir)

Le pin 14 du MAX232 est relié à la broche TX du RS-232 (fil rouge)

Le pin 13 du MAX232 est relié à la broche RX du RS-232 (fil jaune)

Le pin 12 du MAX232 est relié au pin 10 de l'Arduino

Le pin 11 du MAX232 est relié au pin 11 de l'Arduino

'''Lundi 25 Février 2013'''

* Test du code développé en vacances en utilisation l'Arduino de l'émission équipé d'un module Xbee.

'''Mercredi 27 Févier 2013'''

* Développement de la fonctionnalité de l'émission par récupération des valeurs de l'accéléromètre et transmission avec Xbee.

* Test unitaire sur Arduino de programme à l'émission.

* Suivi d'avancement de projet et discussion sur les solutions à proposer pour évoluer le système.

'''Jeudi 28 Février 2013'''

* Développement sur Arduino d'une fonction permettant de récupérer à partir du module xbee les valeurs de l'accéléromètre selon les trois axes (x,y,z) à travers une lecture sur le terminal série de l'Arduino.

* Vérification des valeurs obtenu à travers l'utilisation de softwareSerial en faisant une écriture sur ce terminal. ==> Partie Fonctionnelle

'''Lundi 04 Mars 2013'''

* Phase d'intégration entre la partie commande de moteur et la partie récupération des valeurs de l'accéléromètre reçu par Xbee.

* Test d'intégration en utilisant les valeurs d'un seul axe x.

Partie non achevée : Test en cours et identification d'une réponse du moteur non correcte.

'''Mercredi 06 Mars 2013'''

Résultat des tests d'intégration:

* Observation d'une oscillation dans le mouvement de servomoteur.

* Détection d'une incompatibilité entre la libraire softwareserial.h et servo.h.

* Problème de lecture sur terminal série à cause de l'absence de Serial.available().

'''Jeudi 07 Mars 2013'''

* Mise en œuvre des corrections nécessaires pour modifier la réponse de moteur et la stabiliser.

* Étalonnage des valeurs de moteur entre 0 et 180 en fonction des valeurs de x reçus.

* Début de l'intégration de 3 servomoteurs à la fois.

* Récupération d'une tourelle de test chez M. Aurelien Benechet.

'''Lundi 11 Mars 2013'''

* Axes X et Y fonctionnels, cependant au bout d'un certain (ou d'un certain nombre de mesure ?) les servos s’arrêtent de fonctionner...

* Prochaine séance: régler la position initiale.

'''Mercredi 13 Mars 2013'''

* Le problème des servomoteurs est réglé.

* Les mesures selon les 3 axes:

L'axe x : axe longitudinal ou axe de roulis --> Fonctionnel

L'axe y : axe transversal ou axe de tangage --> Fonctionnel

L'axe z : axe de lacet --> Non Fonctionnel

'''Lundi 18 Mars 2013'''

* Poursuite des tests pour régler les résultats incohérents sur l'axe z.

'''Mercredi 20 Mars 2013'''

* Nos propres tests et une recherche bibliographique nous permet d'affirmer que on ne peut détecter un mouvement de lacet à travers un accéléromètre seulement.

'''Jeudi 21 Mars 2013'''

* Solution: On a fait un changement de matériel pour remplacer l’accéléromètre par un nouveau composant intégrant:

- L’accéléromètre ADXL345 (déjà utilisé)

- Gyroscope ITG-3200

--> Modification de la technologie de communication de SPI vers I2C.

* Début de la partie acquisition à partir d'une caméra (C3088).

'''Lundi 25 Mars 2013'''

* Configuration en I2C de nouveau composant (Accéléromètre + Gyroscope)

* Lecture de la documentation du module C3088 (avec la caméra ov6620).

'''Mercredi 27 Mars 2013'''

* Développement du programme I2C permettant de communiquer avec la caméra en I2C.

'''Mercredi 3 Avril 2013'''

* Tests de la communication I2C avec la caméra --> Fonctionnel

* Début de la configuration de la caméra pour l'adapter à un fonctionnement sous microcontrôleur ATmega.

'''Jeudi 4 Avril 2013'''

* Configuration de la caméra:

- Format QCIF (176*144)

- YCrCb mode

- Réduction de nombre des images par seconde (fps).

* Début de l'acquisition des images à travers le terminal série de l'Arduino (fonctionnement à 115200 bauds).

--> Résultats non fonctionnels pour cette partie.

'''Lundi 8 avril 2013'''

* Pour travailler plus rapidement, nous avons effectué quelques optimisations de notre programme:

- Utilisation des ports de l'ATmega 2560 pour lire simultanément les 8 broches Y.

--> Possibilité d'utiliser un RAM externe pour stocker les données avant de l'envoyer via port série.

'''Vacances'''

* Récupération des trois angles nécessaire pour commander les servomoteurs à partir du gyromètre et de l'accéléromètre en utilisant une librairie existante. Testé sans Xbee.

'''Lundi 29 avril 2013'''

* Ajout de la communication par Xbee entre l'Arduino qui récupère les angles et celui qui commande les servomoteurs.

== Conclusion ==

Vision déportée

2013-03-11T14:55:25Z

Nhusse : /* Avancement du projet */

Vision déportée

2013-02-22T15:34:18Z

Nhusse : /* Avancement du projet */

Vision déportée

2013-02-22T14:44:05Z

Nhusse : /* Avancement du projet */

Gestion afficheurs, 2011/2012, TD3

2012-05-26T22:17:02Z

Nhusse : /* Rapport */

= Gestion d'afficheurs 7-segments =

== Evaluation informatique et électronique ==

=== Gestion de projet / rédaction Wiki ===

Rédaction correcte du Wiki (avec illustration). On espère une version un peu plus etoffée sous peu. La partie gestion de projet est abordé.
Note 70% (à revoir suivant les améliorations apportées).

=== Test fonctionnels ===

* Sous-système : Le système est fonctionnel sur le banc d'essai Arduino. Un souci de défilement avec la NanoBoard. Note 110% (note à revoir éventuellement sur réception de la vidéo).
* Système : Non abordé. Note 100%

=== Qualité de la réalisation ===

* Informatique :
** procédure de test : Pas de <tt>README</tt> sur la FoxBoard. Un site web mais la régulation de vitesse ne semble pas marcher. Note 50%.
** pages HTML et Javascript : Page HTML correcte, script JS correct mais copie conforme du projet du TD1. Note 50%.
** scripts PHP ou programmes C : Programme non plagie, coté affichage correct mais la gestion de la vitesse de défilement n'est pas vraiment abordée. Note 75%.
** installation sur FoxBoard : Pas de tentative de démarrage automatique du démon série. Plusieurs sources sans explication sur les différences de version. Note 50%.
* Electronique :
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Tous les points principaux ont un poids équivalent (sauf "système" qui est un bonus).

Note finale :

== Le 20 avril 2012: ==

Lors de cette séance, nous avons divisé le groupe en deux: Nicolas Husse, s'occupant de la partie informatique et Mathieu Lenormand et Matthias Debie pour la partie électronique.
Pour la partie informatique, le programme conçu permet actuellement d'envoyer, à partir d'un tableau de caractère converti en 7 segments, chaque caractère de ce tableau.
Pour la partie électronique, nous avons commencé à concevoir un schéma électronique qui permet de recevoir 4 octets via une liaison série. Nous avons câblé ensemble plusieurs composants déjà vu en cours (comme : démultiplexeur, multiplexeur, bascule D....). Nous l'avons testé, toutes les étapes de compilation ont aboutis mais à la simulation nous avons eu un problème d'affichage (les caractères s'affichaient sur un afficheur à la fois au lieu de tous ensembles). Le but de cette séance est de remédier à cela.

== Le 11 mai 2012: ==

'''Prévisions:'''

Le but de séance pour la partie informatique est de concevoir l'interface utilisateur afin d'afficher la chaîne de caractère rentré par l'utilisateur sur les afficheurs 7 segments.

'''Travail effectué:'''

L'interface utilisateur est fonctionnel ainsi que le codage du code ASCII vers les 7 segments (sauf caractères spéciaux et K, M, V, W, X, Z)

Pour la partie électronique, nous avons fait les modifications nécessaires pour résoudre l'affichage sur les 4 afficheurs simultanément. Ensuite nous avons cablé la maquette des 4 afficheurs au FPGA et nous testé sont bon fonctionnement. Ensuite nous avons amélioré notre cablage pour qu'il corresponde aux codes de la partie logicielle (le trait du haut représente le bit 0 et ainsi de suite comme sur un afficheur standard).

== Le 21 mai 2012 ==

'''Prévision:'''

Pour la partie informatique, le programme doit être intégré et adapté à la FoxBoard.
Pour la partie électronique, pour faciliter l'intégration du programme nous allons rajouter des portes inverseuses car le programme a été fait en logique inverse (0 pour allumer, 1 pour éteindre).

'''Travail effectué:'''

Pour la partie électronique, en accord avec la partie informatique nous n'avons pas rajouté de porte inverseuse, le code sera changé dans la partie informatique. Cependant nous avons rajouté le bloc réception pour pouvoir utiliser la foxbord dicrectement reliée au FPGA par liaison série. Nous avons testé le code de la partie informatique et remarqué des caractères qui ne correspondaient pas au message envoyé car nous n'avions pas encore la mise à jour de la partie informatique.
Pour la partie informatique, après quelques difficultés pour prendre en main la FoxBoard et envoyé le programme dessus, celui-ci a directement était fonctionnel avec l'Arduino. Cependant comme dit précédemment, la mise en commun avec la partie électronique n'a pas été un succès car le tableau de conversion n’est pas le même.

== Le 24 mai 2012 ==

'''Prévision:'''

Le but de cette séance supplémentaire est de terminer la fusion entre la partie informatique et la partie électronique.

'''Travail effectué:'''

Le nouveau tableau de conversion du programme est fonctionnel cependant lorsque l'on dépasse quatre caractères dans le message à afficher, le défilement pose problème.
Un essai de régulation de la vitesse ainsi que de l'arrêt du programme par l'interface web a été testé mais le résultat n'a pas été probent et l'affichage n'était plus fonctionnel. Il a été décidé de l'enlever pour fournir un programme fonctionnel.

= Rapport =
'''Partie électronique:'''
[[Fichier:Schema_elec.png|640px|thumb|left|Schéma électrique fait sur altium et implanté sur la nanoboard]]

Ce schéma est constitué de:

- 2 compteurs (CB2CES)

- 2 démultiplexeurs (M8_B1B4, M1_S1S4)

- 1 multiplexeur (M8_B4B1)

- 4 bascules (FD8CB)

- 1 decodeur (D2_4S)

- 12 sorties

- 1 horloge correspond à celle de la nanoboard

- un bloc de réception

- 1 bloc pour le port série RS232

[[Fichier:Circuit_elec.jpg|640px|thumb|left|montage électrique entre la plaquette, l'afficheur, la nanoboard et la foxboard]]

En bas à droite de la plaquette blanche on a branché les douzes sorties elles-même reliées par une nappe 20 broches au port HA de la nanoboard (8 pour le mot binaire à afficher et 4 pour la selection)
Eu haut à gauche de la plaquette blanche on a la connexion entre les deux prises femelles du port série (relié entre la nanoboard et la forxboard)

'''Partie informatique:'''

Deux versions du programme sont présent sur la Foxboard: "prog_a.c" pour les afficheurs 7-segments liés à l'Arduino et "prog.c" pour les afficheurs 7-segments conçu dans la partie électronique. Seul le tableau de conversion est changé dans le programme.
En effet, le code envoyé aux afficheurs ne sont pas les mêmes entre l'Arduino et la réalisation de la partie électronique: Les bits 0 sont remplacés par des 1 et inversement et le sens entre le bit de poids fort et le bit de poids faible sont inversé.
Le tableau de conversion ASCII/7-segments est issue de ce tableau: [http://3.bp.blogspot.com/-DaLlkUUNG40/Tl-0JcQ0sXI/AAAAAAAAABk/2ZMzsZeEmQY/s1600/ASCII-to-SevenSegent.jpg Lien]

[[Fichier:7-seg-web.png|424px|thumb|left|Interface web de la gestion de l'afficheur 7-segments]]

Pour la partie web, seul l'envoie du texte est fonctionnel. La régulation de la vitesse et l'arrêt du programme, prévus à l'origine, ne sont pas actif car non fonctionnel lors des test.

Le README est disponible ici: [[Média:Readme.txt]]

Malgré les problèmes, une vidéo a été tourné et est disponible ici: [[https://www.dropbox.com/s/kjg1ktnw24r634a/Gestion_afficheurs_7-seg.mpg lien]].

Gestion afficheurs, 2011/2012, TD3

2012-05-26T13:23:07Z

Nhusse : /* Rapport */

Gestion afficheurs, 2011/2012, TD3

2012-05-26T13:22:35Z

Nhusse : /* Rapport */

Gestion afficheurs, 2011/2012, TD3

2012-05-26T13:19:26Z

Nhusse : /* Rapport */

Gestion afficheurs, 2011/2012, TD3

2012-05-26T13:18:40Z

Nhusse : /* Rapport */

Fichier:Readme.txt

2012-05-26T13:18:25Z

Nhusse : Readme de la gestion de l'afficheur 7-segments.

Readme de la gestion de l'afficheur 7-segments.

Gestion afficheurs, 2011/2012, TD3

2012-05-25T22:02:08Z

Nhusse : /* Rapport */

Gestion afficheurs, 2011/2012, TD3

2012-05-25T21:24:31Z

Nhusse : /* Le 24 mai 2012 */

Gestion afficheurs, 2011/2012, TD3

2012-05-25T21:18:24Z

Nhusse : /* Le 11 mai 2012: */

= Gestion d'afficheurs 7-segments =

== Evaluation informatique et électronique ==

=== Gestion de projet / rédaction Wiki ===

Rédaction correcte du Wiki (avec illustration). On espère une version un peu plus etoffée sous peu. La partie gestion de projet est abordé.
Note 70% (à revoir suivant les améliorations apportées).

=== Test fonctionnels ===

* Sous-système : Le système est fonctionnel sur le banc d'essai Arduino. Un souci de défilement avec la NanoBoard. Note 110% (note à revoir éventuellement sur réception de la vidéo).
* Système : Non abordé. Note 100%

=== Qualité de la réalisation ===

* Informatique :
** procédure de test : Pas de <tt>README</tt> sur la FoxBoard. Un site web mais la régulation de vitesse ne semble pas marcher. Note 50%.
** pages HTML et Javascript : Page HTML correcte, script JS correct mais copie conforme du projet du TD1. Note 50%.
** scripts PHP ou programmes C : Programme non plagie, coté affichage correct mais la gestion de la vitesse de défilement n'est pas vraiment abordée. Note 75%.
** installation sur FoxBoard : Pas de tentative de démarrage automatique du démon série. Plusieurs sources sans explication sur les différences de version. Note 50%.
* Electronique :
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Tous les points principaux ont un poids équivalent (sauf "système" qui est un bonus).

Note finale :

== Le 20 avril 2012: ==

Lors de cette séance, nous avons divisé le groupe en deux: Nicolas Husse, s'occupant de la partie informatique et Mathieu Lenormand et Matthias Debie pour la partie électronique.
Pour la partie informatique, le programme conçu permet actuellement d'envoyer, à partir d'un tableau de caractère converti en 7 segments, chaque caractère de ce tableau.
Pour la partie électronique, nous avons commencé à concevoir un schéma électronique qui permet de recevoir 4 octets via une liaison série. Nous avons câblé ensemble plusieurs composants déjà vu en cours (comme : démultiplexeur, multiplexeur, bascule D....). Nous l'avons testé, toutes les étapes de compilation ont aboutis mais à la simulation nous avons eu un problème d'affichage (les caractères s'affichaient sur un afficheur à la fois au lieu de tous ensembles). Le but de cette séance est de remédier à cela.

== Le 11 mai 2012: ==

'''Prévisions:'''

Le but de séance pour la partie informatique est de concevoir l'interface utilisateur afin d'afficher la chaîne de caractère rentré par l'utilisateur sur les afficheurs 7 segments.

'''Travail effectué:'''

L'interface utilisateur est fonctionnel ainsi que le codage du code ASCII vers les 7 segments (sauf caractères spéciaux et K, M, V, W, X, Z)

Pour la partie électronique, nous avons fait les modifications nécessaires pour résoudre l'affichage sur les 4 afficheurs simultanément. Ensuite nous avons cablé la maquette des 4 afficheurs au FPGA et nous testé sont bon fonctionnement. Ensuite nous avons amélioré notre cablage pour qu'il corresponde aux codes de la partie logicielle (le trait du haut représente le bit 0 et ainsi de suite comme sur un afficheur standard).

== Le 21 mai 2012 ==

'''Prévision:'''

Pour la partie informatique, le programme doit être intégré et adapté à la FoxBoard.
Pour la partie électronique, pour faciliter l'intégration du programme nous allons rajouter des portes inverseuses car le programme a été fait en logique inverse (0 pour allumer, 1 pour éteindre).

'''Travail effectué:'''

Pour la partie électronique, en accord avec la partie informatique nous n'avons pas rajouté de porte inverseuse, le code sera changé dans la partie informatique. Cependant nous avons rajouté le bloc réception pour pouvoir utiliser la foxbord dicrectement reliée au FPGA par liaison série. Nous avons testé le code de la partie informatique et remarqué des caractères qui ne correspondaient pas au message envoyé car nous n'avions pas encore la mise à jour de la partie informatique.
Pour la partie informatique, après quelques difficultés pour prendre en main la FoxBoard et envoyé le programme dessus, celui-ci a directement était fonctionnel avec l'Arduino. Cependant comme dit précédemment, la mise en commun avec la partie électronique n'a pas été un succès car le tableau de conversion n’est pas le même.

== Le 24 mai 2012 ==

= Rapport =
'''Partie électronique:'''
[[Fichier:Schema_elec.png|640px|thumb|left|Schéma électrique fait sur altium et implanté sur la nanoboard]]

Ce schéma est constitué de:

- 2 compteurs (CB2CES)

- 2 démultiplexeurs (M8_B1B4, M1_S1S4)

- 1 multiplexeur (M8_B4B1)

- 4 bascules (FD8CB)

- 1 decodeur (D2_4S)

- 12 sorties

- 1 horloge correspond à celle de la nanoboard

- un bloc de réception

- 1 bloc pour le port série RS232

[[Fichier:Circuit_elec.jpg|640px|thumb|left|montage électrique entre la plaquette, l'afficheur, la nanoboard et la foxboard]]

En bas à droite de la plaquette blanche on a branché les douzes sorties elles-même reliées par une nappe 20 broches au port HA de la nanoboard (8 pour le mot binaire à afficher et 4 pour la selection)
Eu haut à gauche de la plaquette blanche on a la connexion entre les deux prises femelles du port série (relié entre la nanoboard et la forxboard)

'''Partie informatique:'''

Deux versions du programme sont présent sur la Foxboard: "prog_a.c" pour les afficheurs 7-segments liés à l'Arduino et "prog.c" pour les afficheurs 7-segments conçu dans la partie électronique. Seul le tableau de conversion est changé dans le programme.
En effet, le code envoyé aux afficheurs ne sont pas les mêmes entre l'Arduino et la réalisation de la partie électronique: Les bits 0 sont remplacés par des 1 et inversement et le sens entre le bit de poids fort et le bit de poids faible sont inversé.
Le tableau de conversion ASCII/7-segments est issue de ce tableau: [http://3.bp.blogspot.com/-DaLlkUUNG40/Tl-0JcQ0sXI/AAAAAAAAABk/2ZMzsZeEmQY/s1600/ASCII-to-SevenSegent.jpg Lien]

[[Fichier:7-seg-web.png|424px|thumb|left|Interface web de la gestion de l'afficheur 7-segments]]

Pour la partie web, seul l'envoie du texte est fonctionnel. La régulation de la vitesse et l'arrêt du programme, prévus à l'origine, ne sont pas actif car non fonctionnel lors des test.

Note: Rédaction du Readme en cours

Gestion afficheurs, 2011/2012, TD3

2012-05-25T21:18:08Z

Nhusse : /* Rapport */

= Gestion d'afficheurs 7-segments =

== Evaluation informatique et électronique ==

=== Gestion de projet / rédaction Wiki ===

Rédaction correcte du Wiki (avec illustration). On espère une version un peu plus etoffée sous peu. La partie gestion de projet est abordé.
Note 70% (à revoir suivant les améliorations apportées).

=== Test fonctionnels ===

* Sous-système : Le système est fonctionnel sur le banc d'essai Arduino. Un souci de défilement avec la NanoBoard. Note 110% (note à revoir éventuellement sur réception de la vidéo).
* Système : Non abordé. Note 100%

=== Qualité de la réalisation ===

* Informatique :
** procédure de test : Pas de <tt>README</tt> sur la FoxBoard. Un site web mais la régulation de vitesse ne semble pas marcher. Note 50%.
** pages HTML et Javascript : Page HTML correcte, script JS correct mais copie conforme du projet du TD1. Note 50%.
** scripts PHP ou programmes C : Programme non plagie, coté affichage correct mais la gestion de la vitesse de défilement n'est pas vraiment abordée. Note 75%.
** installation sur FoxBoard : Pas de tentative de démarrage automatique du démon série. Plusieurs sources sans explication sur les différences de version. Note 50%.
* Electronique :
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Tous les points principaux ont un poids équivalent (sauf "système" qui est un bonus).

Note finale :

== Le 20 avril 2012: ==

Lors de cette séance, nous avons divisé le groupe en deux: Nicolas Husse, s'occupant de la partie informatique et Mathieu Lenormand et Matthias Debie pour la partie électronique.
Pour la partie informatique, le programme conçu permet actuellement d'envoyer, à partir d'un tableau de caractère converti en 7 segments, chaque caractère de ce tableau.
Pour la partie électronique, nous avons commencé à concevoir un schéma électronique qui permet de recevoir 4 octets via une liaison série. Nous avons câblé ensemble plusieurs composants déjà vu en cours (comme : démultiplexeur, multiplexeur, bascule D....). Nous l'avons testé, toutes les étapes de compilation ont aboutis mais à la simulation nous avons eu un problème d'affichage (les caractères s'affichaient sur un afficheur à la fois au lieu de tous ensembles). Le but de cette séance est de remédier à cela.

== Le 11 mai 2012: ==

'''Prévisions:'''
Le but de séance pour la partie informatique est de concevoir l'interface utilisateur afin d'afficher la chaîne de caractère rentré par l'utilisateur sur les afficheurs 7 segments.

'''Travail effectué:'''
L'interface utilisateur est fonctionnel ainsi que le codage du code ASCII vers les 7 segments (sauf caractères spéciaux et K, M, V, W, X, Z)

Pour la partie électronique, nous avons fait les modifications nécessaires pour résoudre l'affichage sur les 4 afficheurs simultanément. Ensuite nous avons cablé la maquette des 4 afficheurs au FPGA et nous testé sont bon fonctionnement. Ensuite nous avons amélioré notre cablage pour qu'il corresponde aux codes de la partie logicielle (le trait du haut représente le bit 0 et ainsi de suite comme sur un afficheur standard).

== Le 21 mai 2012 ==

'''Prévision:'''

Pour la partie informatique, le programme doit être intégré et adapté à la FoxBoard.
Pour la partie électronique, pour faciliter l'intégration du programme nous allons rajouter des portes inverseuses car le programme a été fait en logique inverse (0 pour allumer, 1 pour éteindre).

'''Travail effectué:'''

Pour la partie électronique, en accord avec la partie informatique nous n'avons pas rajouté de porte inverseuse, le code sera changé dans la partie informatique. Cependant nous avons rajouté le bloc réception pour pouvoir utiliser la foxbord dicrectement reliée au FPGA par liaison série. Nous avons testé le code de la partie informatique et remarqué des caractères qui ne correspondaient pas au message envoyé car nous n'avions pas encore la mise à jour de la partie informatique.
Pour la partie informatique, après quelques difficultés pour prendre en main la FoxBoard et envoyé le programme dessus, celui-ci a directement était fonctionnel avec l'Arduino. Cependant comme dit précédemment, la mise en commun avec la partie électronique n'a pas été un succès car le tableau de conversion n’est pas le même.

== Le 24 mai 2012 ==

= Rapport =
'''Partie électronique:'''
[[Fichier:Schema_elec.png|640px|thumb|left|Schéma électrique fait sur altium et implanté sur la nanoboard]]

Ce schéma est constitué de:

- 2 compteurs (CB2CES)

- 2 démultiplexeurs (M8_B1B4, M1_S1S4)

- 1 multiplexeur (M8_B4B1)

- 4 bascules (FD8CB)

- 1 decodeur (D2_4S)

- 12 sorties

- 1 horloge correspond à celle de la nanoboard

- un bloc de réception

- 1 bloc pour le port série RS232

[[Fichier:Circuit_elec.jpg|640px|thumb|left|montage électrique entre la plaquette, l'afficheur, la nanoboard et la foxboard]]

En bas à droite de la plaquette blanche on a branché les douzes sorties elles-même reliées par une nappe 20 broches au port HA de la nanoboard (8 pour le mot binaire à afficher et 4 pour la selection)
Eu haut à gauche de la plaquette blanche on a la connexion entre les deux prises femelles du port série (relié entre la nanoboard et la forxboard)

'''Partie informatique:'''

Deux versions du programme sont présent sur la Foxboard: "prog_a.c" pour les afficheurs 7-segments liés à l'Arduino et "prog.c" pour les afficheurs 7-segments conçu dans la partie électronique. Seul le tableau de conversion est changé dans le programme.
En effet, le code envoyé aux afficheurs ne sont pas les mêmes entre l'Arduino et la réalisation de la partie électronique: Les bits 0 sont remplacés par des 1 et inversement et le sens entre le bit de poids fort et le bit de poids faible sont inversé.
Le tableau de conversion ASCII/7-segments est issue de ce tableau: [http://3.bp.blogspot.com/-DaLlkUUNG40/Tl-0JcQ0sXI/AAAAAAAAABk/2ZMzsZeEmQY/s1600/ASCII-to-SevenSegent.jpg Lien]

[[Fichier:7-seg-web.png|424px|thumb|left|Interface web de la gestion de l'afficheur 7-segments]]

Pour la partie web, seul l'envoie du texte est fonctionnel. La régulation de la vitesse et l'arrêt du programme, prévus à l'origine, ne sont pas actif car non fonctionnel lors des test.

Note: Rédaction du Readme en cours

Gestion afficheurs, 2011/2012, TD3

2012-05-25T21:01:25Z

Nhusse : /* Le 11 mai 2012: */

= Gestion d'afficheurs 7-segments =

== Evaluation informatique et électronique ==

=== Gestion de projet / rédaction Wiki ===

Rédaction correcte du Wiki (avec illustration). On espère une version un peu plus etoffée sous peu. La partie gestion de projet est abordé.
Note 70% (à revoir suivant les améliorations apportées).

=== Test fonctionnels ===

* Sous-système : Le système est fonctionnel sur le banc d'essai Arduino. Un souci de défilement avec la NanoBoard. Note 110% (note à revoir éventuellement sur réception de la vidéo).
* Système : Non abordé. Note 100%

=== Qualité de la réalisation ===

* Informatique :
** procédure de test : Pas de <tt>README</tt> sur la FoxBoard. Un site web mais la régulation de vitesse ne semble pas marcher. Note 50%.
** pages HTML et Javascript : Page HTML correcte, script JS correct mais copie conforme du projet du TD1. Note 50%.
** scripts PHP ou programmes C : Programme non plagie, coté affichage correct mais la gestion de la vitesse de défilement n'est pas vraiment abordée. Note 75%.
** installation sur FoxBoard : Pas de tentative de démarrage automatique du démon série. Plusieurs sources sans explication sur les différences de version. Note 50%.
* Electronique :
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Tous les points principaux ont un poids équivalent (sauf "système" qui est un bonus).

Note finale :

== Le 20 avril 2012: ==

Lors de cette séance, nous avons divisé le groupe en deux: Nicolas Husse, s'occupant de la partie informatique et Mathieu Lenormand et Matthias Debie pour la partie électronique.
Pour la partie informatique, le programme conçu permet actuellement d'envoyer, à partir d'un tableau de caractère converti en 7 segments, chaque caractère de ce tableau.
Pour la partie électronique, nous avons commencé à concevoir un schéma électronique qui permet de recevoir 4 octets via une liaison série. Nous avons câblé ensemble plusieurs composants déjà vu en cours (comme : démultiplexeur, multiplexeur, bascule D....). Nous l'avons testé, toutes les étapes de compilation ont aboutis mais à la simulation nous avons eu un problème d'affichage (les caractères s'affichaient sur un afficheur à la fois au lieu de tous ensembles). Le but de cette séance est de remédier à cela.

== Le 11 mai 2012: ==

'''Prévisions:'''
Le but de séance pour la partie informatique est de concevoir l'interface utilisateur afin d'afficher la chaîne de caractère rentré par l'utilisateur sur les afficheurs 7 segments.

'''Travail effectué:'''
L'interface utilisateur est fonctionnel ainsi que le codage du code ASCII vers les 7 segments (sauf caractères spéciaux et K, M, V, W, X, Z)

Pour la partie électronique, nous avons fait les modifications nécessaires pour résoudre l'affichage sur les 4 afficheurs simultanément. Ensuite nous avons cablé la maquette des 4 afficheurs au FPGA et nous testé sont bon fonctionnement. Ensuite nous avons amélioré notre cablage pour qu'il corresponde aux codes de la partie logicielle (le trait du haut représente le bit 0 et ainsi de suite comme sur un afficheur standard).

== Le 21 mai 2012 ==

'''Prévision:'''

Pour la partie informatique, le programme doit être intégré et adapté à la FoxBoard.
Pour la partie électronique, pour faciliter l'intégration du programme nous allons rajouter des portes inverseuses car le programme a été fait en logique inverse (0 pour allumer, 1 pour éteindre).

'''Travail effectué:'''

Pour la partie électronique, en accord avec la partie informatique nous n'avons pas rajouté de porte inverseuse, le code sera changé dans la partie informatique. Cependant nous avons rajouté le bloc réception pour pouvoir utiliser la foxbord dicrectement reliée au FPGA par liaison série. Nous avons testé le code de la partie informatique et remarqué des caractères qui ne correspondaient pas au message envoyé car nous n'avions pas encore la mise à jour de la partie informatique.
Pour la partie informatique, après quelques difficultés pour prendre en main la FoxBoard et envoyé le programme dessus, celui-ci a directement était fonctionnel avec l'Arduino. Cependant comme dit précédemment, la mise en commun avec la partie électronique n'a pas été un succès car le tableau de conversion n’est pas le même.

== Le 24 mai 2012 ==

= Rapport =

[[Fichier:Schema_elec.png|1500px|thumb|left|Schéma électrique fait sur altium et implanté sur la nanoboard]]

ce schéma est constitué de:

- 2 compteurs (CB2CES)

- 2 démultiplexeurs (M8_B1B4, M1_S1S4)

- 1 multiplexeur (M8_B4B1)

- 4 bascules (FD8CB)

- 1 decodeur (D2_4S)

- 12 sorties

- 1 horloge correspond à celle de la nanoboard

- un bloc de réception

- 1 bloc pour le port série RS232

[[Fichier:Circuit_elec.jpg|1000px|thumb|left|montage électrique entre la plaquette, l'afficheur, la nanoboard et la foxboard]]

En bas à droite de la plaquette blanche on a branché les douzes sorties elles-même reliées par une nappe 20 broches au port HA de la nanoboard (8 pour le mot binaire à afficher et 4 pour la selection)
Eu haut à gauche de la plaquette blanche on a la connexion entre les deux prises femelles du port série (relié entre la nanoboard et la forxboard)

Gestion afficheurs, 2011/2012, TD3

2012-05-25T21:00:31Z

Nhusse : /* Le 21 mai 2012 */

= Gestion d'afficheurs 7-segments =

== Evaluation informatique et électronique ==

=== Gestion de projet / rédaction Wiki ===

Rédaction correcte du Wiki (avec illustration). On espère une version un peu plus etoffée sous peu. La partie gestion de projet est abordé.
Note 70% (à revoir suivant les améliorations apportées).

=== Test fonctionnels ===

* Sous-système : Le système est fonctionnel sur le banc d'essai Arduino. Un souci de défilement avec la NanoBoard. Note 110% (note à revoir éventuellement sur réception de la vidéo).
* Système : Non abordé. Note 100%

=== Qualité de la réalisation ===

* Informatique :
** procédure de test : Pas de <tt>README</tt> sur la FoxBoard. Un site web mais la régulation de vitesse ne semble pas marcher. Note 50%.
** pages HTML et Javascript : Page HTML correcte, script JS correct mais copie conforme du projet du TD1. Note 50%.
** scripts PHP ou programmes C : Programme non plagie, coté affichage correct mais la gestion de la vitesse de défilement n'est pas vraiment abordée. Note 75%.
** installation sur FoxBoard : Pas de tentative de démarrage automatique du démon série. Plusieurs sources sans explication sur les différences de version. Note 50%.
* Electronique :
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Tous les points principaux ont un poids équivalent (sauf "système" qui est un bonus).

Note finale :

== Le 20 avril 2012: ==

Lors de cette séance, nous avons divisé le groupe en deux: Nicolas Husse, s'occupant de la partie informatique et Mathieu Lenormand et Matthias Debie pour la partie électronique.
Pour la partie informatique, le programme conçu permet actuellement d'envoyer, à partir d'un tableau de caractère converti en 7 segments, chaque caractère de ce tableau.
Pour la partie électronique, nous avons commencé à concevoir un schéma électronique qui permet de recevoir 4 octets via une liaison série. Nous avons câblé ensemble plusieurs composants déjà vu en cours (comme : démultiplexeur, multiplexeur, bascule D....). Nous l'avons testé, toutes les étapes de compilation ont aboutis mais à la simulation nous avons eu un problème d'affichage (les caractères s'affichaient sur un afficheur à la fois au lieu de tous ensembles). Le but de cette séance est de remédier à cela.

== Le 11 mai 2012: ==

Le but de séance pour la partie informatique est de concevoir l'interface utilisateur afin d'afficher la chaîne de caractère rentré par l'utilisateur sur les afficheurs 7 segments.

L'interface utilisateur est fonctionnel ainsi que le codage du code ASCII vers les 7 segments (sauf caractères spéciaux et K, M, V, W, X, Z)

Pour la partie électronique, nous avons fait les modifications nécessaires pour résoudre l'affichage sur les 4 afficheurs simultanément. Ensuite nous avons cablé la maquette des 4 afficheurs au FPGA et nous testé sont bon fonctionnement. Ensuite nous avons amélioré notre cablage pour qu'il corresponde aux codes de la partie logicielle (le trait du haut représente le bit 0 et ainsi de suite comme sur un afficheur standard).

== Le 21 mai 2012 ==

'''Prévision:'''

Pour la partie informatique, le programme doit être intégré et adapté à la FoxBoard.
Pour la partie électronique, pour faciliter l'intégration du programme nous allons rajouter des portes inverseuses car le programme a été fait en logique inverse (0 pour allumer, 1 pour éteindre).

'''Travail effectué:'''

Pour la partie électronique, en accord avec la partie informatique nous n'avons pas rajouté de porte inverseuse, le code sera changé dans la partie informatique. Cependant nous avons rajouté le bloc réception pour pouvoir utiliser la foxbord dicrectement reliée au FPGA par liaison série. Nous avons testé le code de la partie informatique et remarqué des caractères qui ne correspondaient pas au message envoyé car nous n'avions pas encore la mise à jour de la partie informatique.
Pour la partie informatique, après quelques difficultés pour prendre en main la FoxBoard et envoyé le programme dessus, celui-ci a directement était fonctionnel avec l'Arduino. Cependant comme dit précédemment, la mise en commun avec la partie électronique n'a pas été un succès car le tableau de conversion n’est pas le même.

== Le 24 mai 2012 ==

= Rapport =

[[Fichier:Schema_elec.png|1500px|thumb|left|Schéma électrique fait sur altium et implanté sur la nanoboard]]

ce schéma est constitué de:

- 2 compteurs (CB2CES)

- 2 démultiplexeurs (M8_B1B4, M1_S1S4)

- 1 multiplexeur (M8_B4B1)

- 4 bascules (FD8CB)

- 1 decodeur (D2_4S)

- 12 sorties

- 1 horloge correspond à celle de la nanoboard

- un bloc de réception

- 1 bloc pour le port série RS232

[[Fichier:Circuit_elec.jpg|1000px|thumb|left|montage électrique entre la plaquette, l'afficheur, la nanoboard et la foxboard]]

En bas à droite de la plaquette blanche on a branché les douzes sorties elles-même reliées par une nappe 20 broches au port HA de la nanoboard (8 pour le mot binaire à afficher et 4 pour la selection)
Eu haut à gauche de la plaquette blanche on a la connexion entre les deux prises femelles du port série (relié entre la nanoboard et la forxboard)

Fichier:7-seg-web.png

2012-05-25T20:52:21Z

Nhusse : Interface web de la gestion des afficheurs 7-segments.

Interface web de la gestion des afficheurs 7-segments.

Gestion afficheurs, 2011/2012, TD3

2012-05-12T13:31:40Z

Nhusse : /* Avancement */

= Gestion d'afficheurs 7-segments =

Nicolas Husse, Mathieu Lenormand, Matthias Debie

== Introduction ==

== Avancement ==

'''Le 20 avril 2012:'''

Lors de cette séance, nous avons divisé le groupe en deux: Nicolas Husse, s'occupant de la partie informatique et Mathieu Lenormand et Matthias Debie pour la partie électronique.
Pour la partie informatique, le programme conçu permet actuellement d'envoyer, à partir d'un tableau de caractère converti en 7 segments, chaque caractère de ce tableau.
Pour la partie électronique, nous avons commencé à concevoir un schéma électronique qui permet de recevoir 4 octets via une liaison série. Nous avons câblé ensemble plusieurs composants déjà vu en cours (comme : démultiplexeur, multiplexeur, bascule D....). Nous l'avons testé, toutes les étapes de compilation ont aboutis mais à la simulation nous avons eu un problème d'affichage (les caractères s'affichaient sur un afficheur à la fois au lieu de tous ensembles). Le but de cette séance est de remédier à cela.

'''Le 11 mai 2012:'''

Le but de séance pour la partie informatique est de concevoir l'interface utilisateur afin d'afficher la chaîne de caractère rentré par l'utilisateur sur les afficheurs 7 segments.

L'interface utilisateur est fonctionnel ainsi que le codage du code ASCII vers les 7 segments (sauf caractères spéciaux et K, M, V, W, X, Z)

'''Prochaine séance'''

Pour la partie informatique, le programme doit être intégré et adapté à la FoxBoard.

Gestion afficheurs, 2011/2012, TD3

2012-05-12T13:31:29Z

Nhusse : /* Avancement */

Gestion afficheurs, 2011/2012, TD3

2012-05-11T15:28:03Z

Nhusse : /* Avancement */