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

Vidéo HD

Présentation générale

Description

Wiki des prédécesseurs [1]

Analyse du projet

Positionnement par rapport à l'existant

Le marché du meuble connecté n’est pas nouveau. De nombreux concurrents se disputent le développement de nouvelles technologies de plus en plus innovantes. De plus ce genre de meuble devient davantage présent dans les lieux publics ou dans certains établissements à des fins commerciales. Il est d’ailleurs possible d’en observer un dans le hall de Polytech Lille en face du Fabricarium.

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

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

• 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. En effet, cela permet de simuler le fonctionnement de la clé USB. Afin de reprogrammer le microcontrolleur, il est possible d'utiliser l'utilitaire dfu-programmeur (Device Firmware Upgrade). Pour se faire, il est nécessaire d'utiliser les commandes suivantes :

dfu-programmer atmega16u2 erase                        #Supprime le firmware precedemment installé
dfu-programmer atmega16u2 flash XbeeController.hex     #Upload le nouveau firmware precedemment compilé
dfu-programmer atmega16u2 reset                        #Effectue un soft-reset du microcontroller

Pour gagner du temps, ces trois commandes sont placées dans un script shell, il est alors possible, afin de mettre a jour le firmware, d'utiliser la commande :

./upload.sh

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é. Je raccorde les broches de l’ATMEGA16U2 et du module Xbee a des barrettes. Sait-on jamais, cela pourrait servir.

• La carte étant validée, elle part en production au service électronique de l’école. Avec l’aide de M. Thierry FLAMAN, cette première carte voit le jour. On peut alors constater que l’empreinte du connecteur USB choisit ne correspond pas à celui que je possède. De plus, l’écartement des pins de chaque barrettes ne correspond pas à celles standards. Cependant l’empreinte des autres composants, qu’il s’agisse de l’ATMEGA16U2, du module Xbee, du LD1117V33 ou des composants passifs est correct.

Semaine 9

Modification du PCB afin de corriger les erreurs recensées. Reimpression de la carte.

La réimpression de la carte échoue. En effet, on soupçonne que la machine s'est tromper d'outil lors du passage entre deux pistes. L'objectif du passage de l'outil était la finalisation de la carte afin d'enlever les bouts de cuivre orphelins. Cependant la machine a complétement creusé la carte.

On lance alors une seconde fois la réimpression, cette fois-ci en surveillant le process. La même erreur a lieu. J'assiste alors M. Flaman dans l'entretien dans la machine à la recherche de ce qui pose problème. Je régénère les fichiers Gerber afin de voir si les fichiers ne sont pas en cause. Rien ne change...

Semaine 10

Reessai d'impression avec les nouveaux Gerber et la machine fraichement entretenue... L'erreur a de nouveau lieu. En regardant comment le logiciel de la graveuse analyse le fichier Gerber, on remarque qu'il échoue dans le calcul du choix d'outil. Il décide d'utiliser la tête de 2mm entre deux pistes qui sont écartées d'environ 0.7mm...

En l'absence de succès.. je décide de refaire intégralement le projet sur Altium. Peut être était il corrompu... Le placement des composants et le schéma du routage étant déjà imaginé, cela fut assez rapide de refaire le circuit.

En attendant la réimpression de la nouvelle version du circuit, je décide de commencer à travailler sur les périphériques annexes qui serviront d'actionneurs contrôlable depuis la table. On essai donc d'utiliser la grande matrice de LED 64*32.

Cependant, lors de la commande de matériel, j'ai oublie de commander l'alimentation de la matrice... On improvise alors. En lisant la documentation offerte sur le site du fabriquant, on remarque que la matrice doit être alimentée par une alimentation de 5V et aura une consommation maximale avoisinant les 4A. Je décide alors de recycler une alimentation 5V/3A qui était destinée a recharger un appareil... Certes, la consommation maximale n'est pas atteinte... mais dans le pire des cas, cela ne brillera pas aussi fort... Avec l'aval de M. Redon, je sectionne le câble reliant la sortie du transformateur à la connectique, dénude le câble et le soude avec le connecteur de l'alimentation fournie avec la matrice. On fait attention à souder les deux cables d'alimentation dans le bon sens.. On finalise cette alimentation improvisée en utilisant de la gaine thermoformable afin de ne pas laisser le cuivre apparant.

La carte que l'on avait commandée à M. Flaman est prête. Cette fois-ci tout est parfait ! Enfin ! On commence donc le placement des composants CMS, que l'on fera souder au four.

Semaine 11

On finalise la soudure des composants traversants de la carte. Une fois la carte prête, on fait un essai de branchement en utilisant une rallonge USB male/femelle afin de pouvoir utiliser un multimètre plus facilement.

Au branchement de la carte, rien n'explose ! C'est déjà un bon début ! Je décide alors de vérifier la tension en sortie du connecteur USB, le 5V est okay. Il est également possible de mesurer le 3V3 en sortie du convertisseur. Normalement, l'ATMEGA16U2 et le module Xbee sont alimentés !

Ma curiosité me pousse à faire un essai de la commande lsusb. Cette dernière liste tous les périphériques connectées via les ports USB. Et la grande surprise. Un périphérique nommé "Atmel Corp" est présent, cela veut dire deux choses :

• La carte fonctionne, et le microcontrolleur est bien allumé.
• Un bootloader est déjà installé sur le contrôleur. Cela réduira un peu la quantité de travail avant d'utiliser la carte. Cela signifie également que l'ICSP que j'avais posé sur la carte perd un peu de son intérêt.

Je fais un essai de l'outil dfu-programmer afin de voir s'il m'est possible de reprogrammer le microcontroleur directement.. et BINGO ! L'upload du nouveau firmware fonctionne parfaitement ! On essaie alors de faire fonctionner une communication Xbee via le prototype de cle USB.

Pour se faire, je réutilise le programme réalisée en prototypage sur une Arduino, il ne devrait rien avoir a changer car l'environnement utilisée sur la cle USB est le même que celui de l'Atmega16U2 d'une Arduino classique. A l'essai de l'application avec la cle, on se rends compte que des caractères sont bien envoyés, mais ces derniers n'ont aucun sens : au lieu d'une trame de 5 octets de la forme "[X-Y]", j'obtient un message de 13 octets valant tous '0x80', un caractère non défini dans la table ASCII.

La communication ne se fait donc pas de manière effective, surement un problème d'horloge. En relisant la datasheet, je me rends compte qu'il est impossible d'utiliser une horloge de 16MHz si le CPU est alimenté en 3,3V. Je change donc le cristal externe pour une fréquence de 8MHz, qui est compatible. Il s'agissait d'un composant traversant, donc il n'y a pas de soucis pour le changer. Bien qu'un nouveau quartz fut installé, cela ne marchait pas. Pour voir si l'horloge externe est bien utilisée je test un clignotement d'une LED avec un changement d'état toutes les secondes. Je remercie M. Boe pour m'avoir conseiller de raccorder toutes les sorties de l'ATMEGA a des barrettes, en effet sans cela il m'aurait été impossible de connecte une résistance et une LED.

En chronométrant le clignotement de la LED, on remarque qu'elle change d'état toutes les 8 secondes (précisément) au lieu de toutes les secondes. Plusieurs essais avec des valeurs de temps différentes donnent le même résultat. La période d'un état est 8 fois plus longues qu'attendu. Cela signifie que la fréquence du microcontrolleur est 8 fois plus faible. On fait des recherches sur le net et dans la datasheet de la raison de l'utilisation d'une fréquence de 1MHz.

Les bits des fuses paramétrés avec le bootloader pré-installé semblent utiliser le générateur de clock interne de l'ATMEGA, cette horloge fournit une fréquence d'utilisation de 8MHz au contrôleur. Cependant, il existe un paramètre dans les bits de fuses permettant de diviser la fréquence par 8, le bit : CKDIV8. Ce dernier doit donc être activé.

Au lieu de changer la vitesse de fréquence de travail du microcontrolleur, je décide de m'adapter à une fréquence d'1 MHz. Je change alors la fréquence du CPU précisée dans le Makefile permettant de générer le .hex, ainsi la fréquence bonne fréquence sera utilisée dans les calculs de délai, de baud rate etc... Cependant, un fréquence aussi basse ne permet pas d'avoir une vitesse de communication très élevée, il est donc nécessaire de passer à une baud rate plus faible.

J'utiliserai donc une baud date de 4800 au lieu de 9600, je recompile le programme avec tous les changements, reteleverse le programme dans l'ATMEGA. Il est également nécessaire de reparamétrer les modules Xbee pour qu'ils utilisent aussi la même vitesse. Une fois tout cela fait, on réutilise le sniffer Xbee t l'application XCTU afin de voir si les messages sont corrects... Et enfin, la communication s'effectue sans problèmes. Il est alors parfaitement possible d'utiliser l'application sur la table afin de contrôler les LEDs des deux Arduinos.

Semaine 12 : un actionneur d'interrupteur

Une idée simple d’actionneur à but domotique est un système de deux moteurs que l’on poserait sur l’interrupteur de la lumière d’une salle afin de contrôler l’éclairage de la salle à distance. Pour se faire, on utilise deux moteurs AX-12 de la marque Dynamixel. Il s’agit de servo-moteur utilisés dans les robots Bioloids. Ces moteurs ont la particularité d’être alimentés entre 7 et 11V, d’être contrôlable en vitesse et en position, et de proposer des retours d’informations sur le nombre de tours réalisés ou la position du moteur. Mais surtout de pouvoir contrôler plusieurs moteurs via un seul et même réseau. Le contrôle de ces moteurs se fait via une communication série bi-directionelle (sur un même câble) à 1 mégabaud. Cette communication est également accompagnée d’un protocole de communication particulier. Ainsi, une seule communication série permet de contrôler plusieurs moteur. Il s'agit d'une technologie sur laquelle j'ai déjà pu travailler au sein de Robotech.

Afin de pouvoir communiquer avec ces moteurs, l’utilisation d’un buffer 3 états est nécessaire. En effet, nous allons fusionner les connecteurs TX et RX de l’Arduino au sein d’un 74LS241N (Octal Tri-State Buffer) afin de pouvoir les réunir en un seul câble. Ce buffer trois états permettra "d’ordonnancer" le sens de la communication entre le réseau de moteur et l’Arduino. Le principe du montage est expliqué par le schéma suivant.

Les broches de données 1 et 2 côté AX-12 étant reliées entre elles, l’état activé ou non du pin Data-Control de l’octal buffer permettra le transfert dans un sens ou dans l’autre de la donnée vers l’Arduino. Il est alors possible de contrôler ces moteurs depuis la table en connectant un module Xbee à un second port série (Il est donc nécessaire d’utiliser un Arduino Mega)

Semaine 13 : Une librairie propre

Beaucoup de code fantôme fut enlevé, et une cible de déverminage activant les affichages dans la console a été ajoutée dans le Makefile. Cette réécriture du code avait principalement pour but de permettre la création d’une librairie .a permettant d’utiliser la clé USB plus facilement dans les différentes applications, mais également pour permettre un portage de cette partie du projet à d’autres travaux futurs.

Ainsi l’ensemble de la librairie USB, un peu complexe a été simplifiée en 4 fonctions élémentaires. Une fonction de connexion, d’écriture de message, de lecture ou de déconnexion de la clé. Pour se faire, beaucoup d’éléments sont passés en variables globales dans le code afin de permettre le bon fonctionnement de celui-ci.

Ainsi quatres fonctions sont utilisables :

int init_xbee_controller();
write_endpoint(msg,sizeof(msg));
int x = read_endpoint();
int close_xbee_controller();

Ces fonctions permettent d'utiliser la clé en faisant abstraction de la librairie libusb, un peu compliquée, qui fonctionne derrière.

Travail supplémentaire : la fin du projet

Circuit final

En prenant en considération la pré installation d’un bootloader sur l’ATMEGA16U2 ainsi que l’utilisation par défaut de l’oscillateur interne, je décide d’enlever l’ICSP et le cristal externe afin de gagner de la place sur le circuit. Ainsi, il est possible de réduire grandement la taille de carte et d’obtenir un PCB de 2,8 x 3,5 cm. Une taille beaucoup plus acceptable pour une clé USB.

Une fois la soudure de tous les composants réalisée, je procède aux différents essais afin de m’assurer de l’intégrité du circuit. Cependant bien que les tensions appliquées sur le l’ATMEGA et le module Xbee semblent correctes, la carte n’est pas reconnue par l’ordinateur.

L’ATMEGA16U2 étant normalement livré avec un bootloader pré-installé comme on a pu le voir sur la précédente clé, j’explore différentes possibilités en comparant les niveaux de tensions entre les deux cartes en chaque point du circuit. Cependant, lors de la mesure de tension sur la piste reliant le connecteur USB au CPU du prototype de la clé USB, j’effectue un courtcircuit. De cette erreur résulte la surchauffe de la piste, la détruisant au passage.

Bien qu’il ne s’agisse que d’une tension de 5V, un court-circuit délivre suffisamment de courant pour cramer une piste de 0.2mm de large. Il a donc,été nécessaire de réparer le circuit en redessinant la piste avec un fil. L’aide de M. REDON a grandement était utile afin de sauver la carte. Il a fallut un certain à l’ATMEGA pour se remettre de ses émotions avant qu’il n’accepte de fonctionner à nouveau.

Après des essais de détection de différence non concluant, l’option de l’inexistence du bootloader est envisagée, bien qu’elle était initialement écartée. L’absence d’ICSP sur la carte complique grandement les choses, il fut alors nécessaire de le souder directement sur les pattes du CPU.

Ne possédant pas de programmateur ISP, un Arduino a été reprogrammé en tant que tel. Il est alors possible de programmer un microcontrolleur AVR depuis cet Arduino et l’IDE. Il est également possible de le faire directement en console via l’outil avr-dude (outil utilisé par l’IDE Arduino). Bien qu’il fut possible de reprogrammer l’ATMEGA16U2 d’un autre Arduino via cette technique, celui de ma clé USB semble ne pas du tout être reprogrammable. Il fut impossible de lire ne serait-ce que la signature AVR du composant, impossible de dire informatiquement qu’il s’agit d’un ATMEGA16U2 que l’on souhaite programmer.

Le gros de la partie informatique du projet ne pourra donc être utilisé que sur les cartes de prototypages.

Interface Graphique

Travail sur une interface graphique plus complète. La présence des boutons Allumer la lumière (anciennement Allumer A) et Éteindre la lumière(Eteindre A) persiste. Un champ de saisie a été ajoutée en vue de l'utilisation de la matrice de LED. Ce champ de saisie permettra l'affichage d'un message sur la matrice. Je prévoit également un bouton d'envoie et de clear de la matrice.

Je travaille sur la possibilité de dessiner directement sur la matrice. Pour se faire je met un place un tableau de bouton. Afin de préciser la position des boutons, je crée une classe java custom héritant du widget JButton de Swing. Classe auquel j'ajoute deux entiers en attributs, la position en x et celle en y.

Ainsi je peux définir une seule fonction d'event pour les 64*32 boutons, et lorsqu'un bouton est cliqué, on fait appel aux attributs définis à l'initialisation de l'interface pour savoir quel bouton a été enclenché.

Matrice de LED

Afin d’utiliser cette matrice plus facilement, il est possible de réaliser un bouclier venant se connecter à un Arduino Mega. Il est ici nécessaire d’utiliser un Arduino MEGA car un UNO ne dispose pas suffisamment de RAM pour faire fonctionner le programme de la matrice. Il fut possible de reprendre le bouclier qui avait déjà été réalisé par des étudiants lors du module Internet des Objets afin de gagner du temps dans la conception. Il n’a fallut que voir avec M. FLAMAN afin de réimprimer la carte.

Cependant un autre problème technique eu lieu lors de l’impression de cette carte. Ce problème avait pour problème un erreur réalisée par M. FLAMAN lors de la maintenance de son outil : la planéité du plan de gravure des cartes n’était plus assuré. Cela a un peu ralenti l’obtention de ce PCB, mais pas autant que lors de la dernière fois.

Une fois la soudure réalisée, et les différents ordres définis, il fut une nouvelle fois possible de contrôler la matrice de LED depuis la table

Documents Rendus

Fichier:Rapport Projet IMA4 2018 P23 Delobelle.pdf

Code disponible sur : http://github.com/Ruubbis/ProjetIMA4