IMA4 2017/2018 P23 - Table de bar connectée

Présentation générale

Description

Wiki des prédécesseurs [1]

Analyse du projet

Analyse du premier concurrent

Digilor [2]

Digilor dispose d'un catalogue de tables et de bornes interactives tactiles assez génériques. Ces dernières fonctionnent en général avec un environnement Windows 8/10 et un écran capacitif projeté.

Le principal marché de référence de Digilor est le monde de l'entreprise. En effet, leur produits sont plutôt destinés a des fins commerciales et/ou publicitaires. On pense notamment au magasin de vêtement qui pourrait avoir une borne pour présenter leur catalogue en ligne ou un hôtel, afin que la salle d'accueil soit plus animée. Cela permettrait également de donner un côté moderne et high-tech de l'entreprise hôte.

Analyse du second concurrent

Dymension[3]

Dymension, possède un panel de table un peu plus large. En effet, il est possible de trouver sur leur catalogue des tables de terrasse de restaurant. Mais également des tables réservées aux personnes à mobilité réduite ainsi qu'aux enfants.

La particularité de Dymension et qu'en plus de fournir les tables aux entreprises. Elle dispose également d'un panel d'applications d(y)imensionnées parfaitement pour leur catalogue. Notamment quelques jeux multijoueurs, des menus sur lesquels on peut commander directement en restaurant, un espace de travail collaboratif (table de réunion...)

Scénario d'usage du produit ou du concept envisagé

M. Redon, maître incontesté et souverain des salles E302-304-306, est très fier de son patrimoine. En effet, ce lieu regorge de technologies loufoques et d'inventions d'une autre époque. C'est également le lieu principal d'apprentissage de la formation Informatique Microélectronique et Automatique.

Cependant, bien que la salle dispose d'une pléthore de matériel, le professeur n'a que de peu d'outils utilisables directement afin de présenter sa formation à ses collègues et aux personnes extérieures. Ainsi, grâce à la table connectée, il pourra aisément démontrer l'intérêt de la formation et la nécessité d'avoir du matériel à disposition. De plus, cela lui permettra, dans le cadre d'interventions extérieures (CREP / JPO) d'exposer tout le potentiel qu'offre les études en IMA.

Il pourra également, de part le réseau de capteurs et d'actionneurs connecté à la table, contrôler son domaine sans avoir à se déplacer. Il pourra ainsi vérifier la présence d'étudiants dans la seconde salle, ou bien leur émettre un message via le panneau LED... Les possibilités d'une telle table sont infinies ! On peut également imaginer un concept de jeu de société numérique et interactif nouvelle génération, ou un plateau dynamique permettant de faire du jeu de rôle 2.0. Le maître de jeu pourra alors, via l'écran principal, contrôler le développement de la partie en envoyant directement des ordres de jeu aux tablettes des utilisateurs et en modifiant en direct l'environnement et l'ambiance dans lequel les joueurs évoluent (bruits ambiants, lumières, ventilateurs, diffuseurs d'odeurs...)

Réponse à la question difficile

Quel réseau de capteur ?

Nous partirons sur un réseau Xbee afin de communiquer avec un jeu de capteurs et d'actionneurs. L'objectif est de côntroler l'environnement autour de la table connectée (Ici la E306). Nous utiliserons alors des capteurs de températures, de luminosité et de présence. Et pour les actionneurs : un panneau LED, un ventilateur, et différents périphériques annexes (exemple : tourelle lance-missile)

Préparation du projet

Cahier des charges

• L'unité centrale de la table doit pouvoir communiquer avec les 6 tablettes annexes. L'utilisateur principal (sur l'écran de la table) doit etre en mesure

de lancer des applications sur chacune des six tablettes connectées. L'opérateur principal pourra alors via un "jet" d'application (Drag&Drop) lancer cette même application sur la tablette cible. Cette application ne sera alors plus affichée sur l'écran principal, jusqu'à ce que l'opérateur rende la main à l'hôte.

• Contrôler depuis les différentes applications crées, les différents capteurs et actionneurs présents dans la pièce. Ce contrôle doit également être possible si

l'application est lancée sur une tablette et non sur l'unité centrale.

Liste des tâches à effectuer

• Effectuer une étude de fonctionnement du produit actuel.
• Finaliser le travail réalisé par mes prédécesseurs (notamment la partie électrique).
• Créer une application mère sur l'ordinateur de la table permettant de communiquer avec les six tablettes.
• Créer une application fille sur les tablettes, qui peut recevoir des ordres de la table (exemple : ouvrir une application) et lui faire un compte-rendu.
• Créer différentes cartes électroniques afin d'y placer les capteurs et actionneurs de l'environnement.
• Mettre en place un réseau de communication Xbee entre les différents circuits électroniques et l'unité centrale de la table.

Réalisation du Projet

Feuille d'heures

Tâche	Prélude	Heures S1	Heures S2	Heures S3	Heures S4	Heures S5	Heures S6	Heures S7	Heures S8	Heures S9	Heures S10	Total
Analyse du projet	6	2										8
Découverte de la table	0	2										2
Essais sur le réseau Xbee via Arduino	0	2	5									7
Programmation libUsb et LUFA	0	0	0	2	0	0	8					10
Conception PCB Driver XbeeUSB et lecture Datasheet	0	0	2	6	7	2	0					17
Tests Annexes	0	0	0	0	1	0	0	2				3
Serveur Socket+Libusb	0	0	0	0	0	0	6	2				8
Client graphique Java	0	0	0	0	0	0	0	3				3
Total	6	6	7	8	8	2	14	7				58

Semaine 1

La première séance a principalement été consacrée à la découverte de la table connectée réalisée par mes prédécesseurs, ainsi qu'a l'analyse de l'application qu'ils avaient réalisé. Il a fallut rebrancher intégralement la table, qui n'est en réalité ni plus ni moins qu'un ordinateur avec une écran tactile. En effet, à l'un des pieds de la table se trouve une unité centrale qui sera reliée au moniteur. Le branchement consiste alors à un branchement classique d'un ordinateur : câble d'alimentation, câble vidéo (ici DVI) ainsi qu'un câble USB-B permettant l'envoi des entrées sur l'écran tactile à l'unité centrale.

L'application n'est en fait qu'une "simple" interface Web, utilisant une base de donnée PostGres afin de stocker les commandes avec une interface pour les clients, les serveur et le gérant du bar. L'interface Web permet une programmation "simple" d'un côté graphique (HTML/CSS), cela peut être une bonne idée à reprendre.

Afin de faire communiquer nos capteurs et actionneurs avec notre unité centrale, il faudra implémenter un réseau de communication. Nous partirons sur un réseau Xbee. Une datasheet des modules utilisés est disponible en ligne. Les modules Xbee peuvent être configuré directement via XCTU, un logiciel fourni par Digi International via un connecteur USB-Xbee.

Semaine 2

-- PHOTO SHIELD Tentative de communication entre deux Arduino Uno via le réseau Xbee. On utilise pour cela un bouclier Xbee connecte directement sur l'Arduino. Il y a pas mal de pins présents sur le shield, mais seul 4 sont nécessaires : les broches de communication Serie TX/RX, ainsi que l'alimentation 5V/GND provenant du ICSP. Un convertisseur 5V DC/3V3 DC est présent sur le bouclier afin d'alimenter le module Xbee depuis l'alimentation de l'Arduino.

Il est cependant nécessaire de paramétrer les modules afin qu'il puisse communiquer entre eux, trois paramètres doivent être définis afin que la communication puisse avoir lieu :

• Le canal de communication : Il s'agit du choix de la fréquence de communication du Xbee. Il est possible de choisir parmi 16 canaux de fréquence dans la bande 2,4 GHz. On choisira le canal 0x0B, arbitrairement..

-- PHOTO GAMME FREQUENCE

• L'ID de la communication : Il s'agit de second paramètre à définir afin de permettre aux modules de communiquer entre eux. Il est nécessaire que tous les modules communiquant entre eux soit sur le même ID (ainsi que même canal de communication évidemment)
• La Baud Rate : Il s'agit de la vitesse de la communication série. On peut imaginer, dans le cas de deux Arduinos communiquant en série, que les deux modules Xbee serviront de "cable" en reliant les broches TX et RX des deux Arduinos. Il est donc nécessaire de définir la même vitesse pour les deux modules, vitesse qui doit être supportée par les Arduinos. On prendra alors par défaut une vitesse de 9600.

On définit un protocole assez simple, utilisant des caractères ASCII afin de faciliter la compréhension humaine du message. (Ce protocole est destiné à être changé lorsque l'on envisagera la sécurisation du système).

• Un caractère de début de transmission : '['
• L'identifiant (un caractère) du périphérique à contrôler : X
• Un caractère d'espacement : '-'
• L'identifiant (un caractère encore) de l'ordre à exécuter sur le périphérique cible : Y
• Un caractère de fin de transmission : ']'

On se limite pour l'instant à pouvoir communiquer entre trois Arduinos. Une ordonnant aux deux autres d'allumer ou d'éteindre la LED connectée au pin 13. Il est alors possible de voir, grâce à un "sniffer" qui est paramétré de la même manière que les autres modules, de voir passer des messages "dans l'air".

-- PHOTO A FAIRE

Semaine 3

L'idée d'une "Clé USB Zigbee" émerge. L'objectif est de pouvoir contrôler différents périphériques, capteurs comme actionneur, depuis la table. La table n'étant en réalité qu'un simple ordinateur muni d'un écran tactile. Il est alors possible d'y brancher une clé USB et de programmer un driver permettant d'utiliser cette dite clé.

On explore donc à nouveau le mini-projet réalisé en tutorat système sur la libusb et le re-flashage de l'ATMEGA16U2 de l'Arduino via la librairie LUFA. L'objectif est alors de développer une application, console pour l'instant, permettant de communiquer avec le microcontrôleur via le protocole USB. Pour le protocole USB, on reprend une architecture similaire à celle d'un périphérique type manette : 2 Interfaces de communication. Chacune disposant d'un EndPoint, un en entrée, l'autre en sortie de l'Atmega16U2.

En explorant un peu l'architecture d'une Arduino, on se rend compte que la communication entre les deux microcontrôleurs se fait via une liaison série UART. Cependant, afin de communiquer avec le module Xbee, une liaison série suffit. On en déduit donc que l'architecture matérielle de la clé USB ne possédera qu'un seul microcontrôleur, un Atmega16u2, qui communiquera directement avec le module Zigbee. Il faudra en plus, l'environnement permettant aux deux composants de fonctionner. On commence alors à travailler sur le fichier de Schematics de notre clé USB avec le logiciel Altium.

Semaine 4

On reprend le schematics d'un Arduino au complet afin de concevoir notre circuit. Cependant, nous ne prendrons que la partie concernant l'Atmega16U2. En effet, comme expliqué précédemment, seul ce microcontrôleur sera nécessaire.

En lisant la datasheet du module Xbee , on se rend compte que ce dernier doit être alimenté par une tension comprise entre 2.8 et 3.4V (3.3 en nominal). Cependant la communication en USB se fait via une alimentation en 5V. Il sera donc nécessaire d'utiliser un convertisseur 5V -> 3V3 afin d'alimenter le Xbee. Ce convertisseur nécessite l'utilisation de deux condensateurs, un de 100nF et un autre de 10 µF, comme précisé sur la figure 4 de la datasheet du composant.

Afin de communiquer avec le module Xbee, seul 4 "cables" sont nécessaires. Les pins d'alimentation, (3V3 et GND), ainsi que les pins de communication série TX et RX. Les autres pins du modules ne sont que des pins de reparamétrage ou d'entrée/sortie. On supposera dans un premier temps que les modules sont déjà paramétrés en amont, et que l'on ne pourra pas les reparamétrer "on the go"

On remarque également qu'en lisant la datasheet de l'ATMEGA16U2, que le microcontrôleur peut fonctionner dans une plage de 2.7 - 5.5V. Étant donné que les pins digitaux des microcontrôleurs à l'état haut sont à la tension d'alimentation, on alimentera l'ATMEGA16U2 en 3V3 grâce au convertisseur. Cela permettra d'éviter des problèmes de communication entre le microcontrôleur et le module Xbee, et permettra de n’utiliser qu'un seul convertisseur 5V-3V3. On fera fonctionner le microcontrôleur a 16MHz, il est conseiller d'utiliser des condensateurs 22pF directement connecté a l'horloge... C'est ce que l'on fait donc

Semaine 5

• Une grande partie de la conception réside dans la recherche de composant et de s'assurer que les packaging des composants sont corrects. Il faut également faire attention aux dimensions des résistances et condensateurs CMS utilisés

//TODO

Semaine 6

• Finalisation de la partie Soft du driver XbeeUSB. Les essais de programmation ont été réalisés via une Arduino Uno dont l'Atmega328P a ete retirée.
• La programmation ne fut pas très complexe, en effet une bonne partie du programme avait été réalisée en Tutorat. Il fallait cependant remettre au propre le code afin qu'il soit compatible avec le projet actuel. Il est désormais possible de compiler le code via la cible "debug" du Makefile permettant l'activation des procédures d'affichage afin de vérifier le bon fonctionnement du programme.
• Une erreur a bloqué l'avancement pendant une bonne heure. En effet, un Shield Xbee pour Arduino est utilisée, malgré la non présence de l'Atmega328P.

On essai de communiquer directement via les pins série de l'Atmega16U2 avec le Xbee. Cependant le bouclier a été designé pour communiquer avec une Arduino complète. Ainsi les pins TX/RX de l'Arduino sont habituellement connectés respectivement aux pins RX/TX du module Xbee. Cependant dans notre cas, ou seul l'Atmega16u2 est utilisée, cela ne fonctionnait pas. Cela s'explique par le fait que les deux microcontrôleurs communiquent habituellement via ces ports... Impliquant du fait que le TX/RX de l'Atmega16u2 sont connectés aux RX/TX de l'Atmega328p... Ainsi, si l'on utilise le bouclier Xbee directement en utilisant l'atmega16u2 cela ne pourra jamais fonctionné car deux pins TX sont connectés entre eux (idem pour le RX). Il a fallut donc connecte le bouclier à l'Arduino via des jumpers, en prenant soin d'inverse les connectiques série.

Semaine 7

• Mise en place d'un serveur socket PF_UNIX (communication via fichier temporaire) implantent la libusb afin de contrôler le périphérique USB/Xbee. Mise en place d'un client socket afin de communiquer avec le serveur. Il est alors possible de contrôler les LEDs des EndDevices à distance depuis l'entrée sur la console du client
• Recherche sur la mise en place d'une interface graphique "simple" (quelques boutons, champ de saisie etc.). L'idée d'une interface Web est abordée. Cependant il est impossible de communiquer en socket via du javascript, uniquement en Websockets. Comme le client socket est déjà codé, et que je ne souhaite pas le refaire en websocket... je recherche une autre solution : interface graphique Java
• Cependant Java n'inclut pas nativement les sockets PF_UNIX, on change alors le fonctionnement du serveur afin d'utiliser des sockets AF_INET (communication via la pile TCP/IPV4). Test d'un client Java console afin de s'assurer de la connexion : tout est ok. On peut donc travailler sur l'interface graphique
• Développement de l'interface graphique java via Swing. 4 boutons permettent alors l'envoi de commande au réseau Xbee : allumer A ou B, éteindre A ou B

Semaine 8

• Reprise de la partie conception électronique du driver XbeeUsb. Finalisation du circuit imprimé grâce aux conseils de M. Boé.
• Impression de la carte. Le circuit semble correct, cependant l'empreinte du connecteur USB n'est pas la même que celle du connecteur que je possède. De plus la distance entre les pattes des headers n'est pas standard.