ELECINF344/381

Partie interactive du site pédagogique ELECINF344/ELECINF381 de Télécom ParisTech (occurrence 2011).

Catégories

Wireless RoseWheel

After a long night of debugging, we finally managed to make the bluetooth working.  We are now able to send instruction and receive information from RoseWheel through the bluetooth interface using minicom on a laptop. We are also able to pair with an Android smartphone but we haven’t been able to verify the data transmission yet. We are still working on the Android application, but hopefully tomorrow we will be able to start our first tests of wireless communication with RoseWheel.

We also tested the  range of the Bluetooth with the transmitter inside the chassis and we received the signal from a distance of approximately 10 meters with two walls in between.

We started the implementation of the human-interface board. We have found a big LCD driven by the same controller as the one of our laboratory boards. We plan to use it to display information to the user directly on the handlebars, such as the engine power, battery level and the current angle measured by the sensors. As we are going to place the LCD vertically we had to rewrite a new set of characters made to be displayed in this orientation.

[Casper] Flash, Screen and Pictures…

We’ve been working these last few days on the PCB, to display pictures and to save and load them from flash.

First, we developped a set of functions to erase, write and read the flash memory, using a SPI protocol. After testing it with text strings we displayed on the screen, we tried with pictures. However, the STM32 RAM is not big enough to handle a whole picture : we have at most 20kbytes RAM, and one picture takes 25kbytes (132*132 pixels of 12 bits, 4 for each RGB channel). So we read the flash per 256 bytes blocks that we send to the LCD screen, until transfer completion. Similarly, we write flash per 256 bytes blocks when receiving a picture from the UART connection.

In order to have a simple protocol for writing pictures, we do not allow two pictures to share a same memory sector (smallest erasable area). Since each sector is 4 kbytes wide, we use 7 sectors for each picture : that’s about 3 kbytes too large. However, this allows to store 146 pictures in the flash, which should be enough for our project. We did not work yet on the possibility of storing smaller pictures which could be used to refresh a small screen area. It may be useful for animations.

Finally, we use the screen configuration options to rotate pictures by 90, 180 or 270 degrees, changing the way the screen controller reads the RAM.

Moreover, we wrote a small program which uses OpenCV library (which is already used on the beagleboard for face detection and recognition) and converts a picture (jpeg, png, bmp,…) in a 132*132 12 bits picture and saves it in a file that can be sent to the PCB by UART.

[CASPER] PSSC

After some over-the-internet discussions, we finally agreed on the following list of goals and milestones :

A interface task is placed between SVOX Pico and ALSA on the beagleboard  – 04/18  Thibault
The beagleboard and Casper PCB communicate over an UART link – 19/04  Alain
We store and read images to and from the flash memory on the Casper PCB – 20/04  Alain
We are capable of having the beagleboard read a text file out loud – 20/04 Thibault
The beagleboard is able to recognized predetermined vocal commands – 21/04  Thibault
The LCD display adapts itself according to the robot’s orientation – 22/04  Alain
We are capable of controlling the robot’s tilt angle  -  22/04  Thomas
We are capable of controlling the robot’s orientation (azimuth) – 22/04   Thomas
The robot as been assembled, and the devices (camera, PCB, …) are on board – 23/04  Thomas
We can make the robot track a face (the robot’s orientation follows slow mouvements) – 25/04   Alain
The API we previously defined is accessible from LUA scripts - 27/04   Thibault
The robot is capable of accessing a simple mail box (without encryption protocols) – 28/04   Alain
The robot has a simple remote http setup interface – 29/04   Thomas
We use a LUA script, using the API, to drive the robot for the demo – 29/04   Thomas
The servomotors are being driven by a linux device driver on the beagleboard – 29/04  Thibault

[CASPER] Demo de vendredi et API RS232

Voici dans ce post un bilan de la démonstration de Vendredi, ainsi qu’un bref état des lieux des avancées d’aujourd’hui concernant la programmation série en C sous linux.

 

Démonstration de vendredi

Nous avons Vendredi fait état de nos dernières avancées.

Nous avons débuté la démonstration par la présentation du PCB que nous avions réalisé et qu’Alexis nous avait remis il y a peu. Alain a, comme il l’a montré dans un post précédent, réussi à piloter l’écran LCD et afficher une animation simple comportant des rectangles de couleur et du texte.
Reste maintenant à réaliser l’interface série entre la carte et un ordinateur, puis programmer la mémoire flash embarquée.

Nous avons poursuivi par la démonstration de Thomas qui a piloté par l’intermédiaire de la carte de TP STM32 l’un des servomoteurs que nous allons utiliser. Grâce à son programme, nous sommes capables de piloter ces moteurs en leur fournissant une consigne angulaire.
Reste désormais à piloter le prototype en installant trois servomoteurs dans sa base.

Nous avons ensuite effectué une démonstration logicielle qui rassemblait les « helloworlds » que nous avions réalisés avec les différentes bibliothèques. Nous avons ainsi pu piloter à la voix l’ordinateur, lui demander de faire l’apprentissage de deux visages, puis de passer en mode reconnaissance. Une fois en mode reconnaissance, le moteur de synthèse vocale interfacé pour le moment avec pulseaudio a salué les visages connus en les nommant par leurs prénoms.

 

Comme Thomas l’a signalé dans son billet, nous avons pour le moment mis de côté le développement de drivers, pour nous concentrer essentiellement sur la mécanique, la programmation du PCB, et le port de nos applications sur la beagleboard.

Afin de préciser notre démarche, nous publierons bientôt sur ce site une liste actualisée de nos PSCC et des responsables associés.

 

Avancées de la journée : API RS232

De mon côté, je me suis penché sur la programmation du port série en C sous linux. J’ai trouvé à ce sujet une excellente source de documentation, qui m’a permis de comprendre rapidement l’interface posix permettant d’en effectuer la configuration. Vous retrouverez ce guide ici.

J’ai créé une interface de plus haut niveau permettant de lire et d’écrire sur un nombre indéfini de ports série, et de rentre transparente la gestion des lectures et écritures avec tampon.

Il suffit en effet pour utiliser un port série d’en demander l’ouverture en précisant le fichier /dev/tty* associé, et de donner en argument la fonction que l’on souhaite être appelée pour traiter les données.

L’API se charge ensuite d’appeler cette fonction lorsque de nouvelles données sont disponibles, ainsi que d’écrire les données stockées dans des tampons chainés lorsque le matériel est prêt.

L’utilisateur peut donc utiliser des fonctions non bloquantes pour écrire, et utiliser ses propres fonctions pour lire.

Pour finir, bien que cela ne soit pas encore implémenté, il est possible d’ajouter à cette API les sockets en plus des ports série. Cela permettrait de gérer par le biais d’une interface unique toutes les transmissions de la beagleboard, que ce soit par réseau ou avec le PCB.

[Casper] Carte STM32

Nous avons aujourd’hui poursuivi la prise en main de notre carte, en commençant par l’écran. Mauvaise surprise, il se commande en SPI 9 bits, et le STM ne fait que du 8 ou du 16 bits. D’après certains forums, il est possible de contourner le problème en utilisant un USART, mais malheureusement aucun USART du STM n’est remappable sur les pins que nous avons choisis pour contrôler l’écran. Nous avons donc dû commander l’écran en bit-banging. Nous nous sommes appuyés sur le tutoriel de James P. Lynch, très clair, pour les protocoles d’initialisation de l’écran et d’écriture. Celui-ci fournit également trois fontes de caractères dans un format facilement utilisable. Notre écran est à base de contrôleur de type Epson (l’écran peut en effet être à base de deux types différents de contrôleurs), mais la plupart des pins de configuration ne sont pas accessibles depuis la sortie de l’écran (comme celles permettant de faire du SPI 8 bits…).

Heureusement, la flash se commande quant à elle en SPI 8 bits, et l’utilisation du DMA devrait permettre de soulager un peu plus le processeur lors du chargement d’images à afficher…

Prochaine étape : communication UART pour envoyer des images à afficher, et les stocker dans la flash.

 

[CASPER] PCB

Afin de poursuivre le compte-rendu de notre travail de la semaine dernière, voici le résultat de la conception du PCB de casper.

La carte mesure environ 50mmx50mm et sera intégrée dans la tête du robot. Elle comporte notamment un processeur STM32, une mémoire flash, un écran LCD et plusieurs micros.

Elle permettra de gérer l’affichage sur l’écran via des commandes envoyées depuis la beagleboard vers le STM32, ainsi que de contrôler certaines réactions/comportements visuels.

La carte a été finalisée pour la production par Alexis.

Communication challenge 2011

Cette année, le communication challenge repose sur la possibilité d’exécuter des commandes en tâche de fond et de stocker des commandes pour usage futur.

Communication avec le serveur

Le serveur communique en 802.15.4. Son identité est « CC » (0×43 0×43). Chaque client doit être configuré avec les initiales du participant sur deux caractères comme c’était le cas pour la mise en œuvre il y a deux semaines. Les messages envoyés en broadcast seront rejetés et pourront conduire à l’élimination de la personne fautive. Toute tentative, réussie ou non, de se faire passer pour le serveur, pour un autre client ou de perturber un autre participant sera sanctionnée.

Toutes les communications utilisent un protocole découpé en lignes, chaque ligne étant terminée par le caractère ‘\r’ (line feed). Aucune ligne, émise par le serveur ou par les cartes, ne peut contenir plus de 50 caractères (y compris le caractère de fin de ligne).

Lorsque des valeurs doivent être échangées entre le serveur et le client en hexadécimal ou en base 33, celles-ci utiliseront les chiffres de 0 à 9 puis les lettres majuscules, de ‘A’ jusqu’à, respectivement, ‘F’ ou ‘W’. Les valeurs transmises par le serveur contiendront systématiquement deux chiffres lorsqu’elles sont en hexadécimal ou un seul chiffre lorsqu’elles sont en base 33. Les valeurs transmises en hexadécimal par le client contiendront autant de chiffres que nécessaire (jusqu’à 3).

Les paquets envoyés par le serveur auront systématiquement la forme suivante :

SLOTID [CMD] EOL

où :

  1. SLOTID est un caractère en base 33. Il vaut soit ’0′, pour signifier une exécution immédiate, soit une valeur entre ’1′ et ‘W’ indiquant qu’il faut stocker les commandes dans le slot correspondant (il faut donc prévoir 32 slots) pour une exécution future (voir, plus bas, la commande ‘X’).
  2. [CMD] représente 0, 1 ou plusieurs commandes, concaténées sans séparateur intermédiaire.
  3. EOL représente le caractère de fin de ligne ‘\r’.

La réponse à la réception d’une commande doit être envoyée immédiatement (avant exécution éventuelle) sous la forme d’un paquet de deux caractères :

SLOTID EOL

Ensuite, si SLOTID vaut 0, la commande doit être exécutée (ce qui peut provoquer l’envoi de paquets supplémentaires comme indiqué dans la description individuelle des commandes.

Les exemples donnés le sont à titre d’illustration et ne sont pas contractuels (ils peuvent contenir des erreurs, même si un effort particulier a été fait pour qu’ils soient corrects). Le préfixe « > » représente une ligne envoyée par le serveur à la carte et le préfixe « < » un envoi d’une ligne de la carte vers le serveur.

Pour initier le dialogue avec le serveur, la carte doit, après avoir configuré son adresse correctement, envoyer une ligne « START », et le serveur enverra alors sa première commande. À tout moment, en cas de réponse incorrecte, le serveur peut arrêter d’envoyer des commandes à la carte, et ne recommencera que lorsqu’un nouveau « START » sera renvoyé. L’envoi de « START » par le client est permis à tout moment et redémarrera la séquence.

Commandes

Ping

La commande Ping est constituée d’un unique caractère ‘P’. L’effet de son exécution est l’envoi d’un paquet contenant le caractère ‘P’ suivi d’un caractère de fin de ligne (l’envoi de ce caractère de fin de ligne est valable pour toutes les commandes qui envoient quelque chose, son utilisation ne sera pas rappelée par la suite).

Exemple d’exécution de la commande Ping

> 0P
< 0
< P

Leds

La commande Leds est constituée du caractère ‘L’ suivi de trois valeurs hexadécimales comprises entre 00 et FF représentant, respectivement, l’éclairage des leds rouge, verte et bleue composant la led tricolore équipant la carte. Elle ne donne lieu à aucune réponse.

Exemple d’allumage de la LED tricolore à environ 50% de vert et 0% de rouge et bleu

> 0L007F00
< 0

Execute

La commande Execute est constituée du caractère ‘X’ suivi d’un numéro de slot en base 33 entre ’1′ et ‘W’. Elle ne donne lieu à aucune réponse directe, mais l’exécution des commandes stockées dans le slot correspondant peut donner lieu à l’envoi de paquets si ces commandes le prévoient.

Attention : l’exécution d’une commande dans un slot particulier peut contenir des ordres d’exécution d’autres commandes. Il est donc important que l’exécution de commandes imbriquées soit possible.

La carte ne doit pas traiter de nouvelles commandes entrantes tant que la commande en cours n’a pas terminé son exécution. Par exemple, le traitement de la commande « 0X1″ (exécuter immédiatement le contenu du slot 1) doit effectuer les commandes du slot 1 avant d’accepter une nouvelle commande entrante.

Exemple de stockage d’une commande (double ping) dans le slot 1 suivi de son exécution

> 1PP
< 1
> 0X1
< 0
< P
< P

Exemple de stockage et d’exécutions multiples

> 1X2X2
< 1
> 2PP
< 2
> 0PX1X2
< 0
< P
< P
< P
< P
< P
< P
< P

Upper LCD line

Cette commande permet d’afficher un message sur la ligne supérieure du LCD. Si le message contient 16 caractères ou moins, le message doit être simplement affiché en l’alignant à gauche. Si le message contient plus de 16 caractères, il doit défiler continuement en tâche de fond jusqu’à ce qu’un nouvel affichage sur cette ligne ait lieu lors de l’exécution d’une nouvelle commande du même type.

La commande est constituée du caractère ‘U’, de la longueur du message en hexadécimal puis des caractères individuels à afficher. L’exécution de cette commande ne renvoie rien.

Exemple d’affichage du mot « PING » sur la ligne supérieure et de la réponse à un Ping

> 0U04PINGP
< 0
< P

Lower LCD line

La commande ‘D’ est à traiter comme la commande ‘U’ à la différence qu’elle affiche le message sur la ligne inférieure de l’écran LCD.

Exemple d’affichage du message « Hello world » sur les deux lignes

> 0U05HelloD05world
< 0

Switch

La commande Switch est constituée de l’unique caractère ‘S’. Son exécution doit, dans l’ordre :

  1. attendre que les deux boutons soit relâchés ;
  2. envoyer, selon le bouton pressé, respectivement ‘L’ pour le bouton de gauche (left) ou ‘R’ pour le bouton de droite.

Exemple d’appui sur le bouton gauche puis le bouton droit

> 0U0EPresser gaucheD0Apuis droitSS
< 0
< L
< R

Analog sensor

La commande Analog est constituée de l’unique caractère ‘A’. Son exécution renvoie la valeur, en hexadécimal, du potentiomètre tel que lu sur 12 bits sur le convertisseur analogique-numérique. Cette valeur sera comprise entre 0 et FFF.

Afin de pallier les problèmes liés aux légères variations du convertisseur analogique-numérique dans les poids faibles de la valeur retournée, il est permis (et conseillé) de lisser la valeur retenue en procédant ainsi : si la valeur est éloignée de moins de 50 (décimal) de la valeur précédemment lue, cette valeur précédente peut être conservée. Par exemple, si la valeur « 7F8″ (hexadécimal) a été précédemment utilisée, elle peut être retournée tant que la valeur lue dans le convertisseur est comprise entre « 7C6″ (hexadécimal) et « 82A » (hexadécimal).

Exemple de lecture du capteur analogique positionné approximativement à mi-course

> 0A
< 0
< 7F8

Connect analog sensor to stored commands

Cette commande permet d’exécuter, en tâche de fond, la valeur lue sur le convertisseur analogique-numérique à des commandes préalablement stockée. La plage de sensibilité du capteur (entre « 0″ et « FFF ») doit être divisée en zones de taille égale et ordonnées, et la commande correspondante doit être exécutée.

La commande est constituée du caractère ‘C’ suivi d’une valeur hexadécimale indiquant le nombre de zones à utiliser, puis la liste ordonnée des slots correspondant à ces zones. Un nombre de zones égal à « 00″ désactive cette fonctionalité. La commande ne renvoie rien.

Cette commande doit alors s’exécuter en tâche de fond. Vous avez la garantie que le serveur n’enverra pas de commandes perturbant l’exécution de cette commande avant d’avoir stoppé son exécution.

Si vous avez opté pour la procédure de lissage conseillée pour l’implémentation de la commande ‘A’, vous devez également utiliser ce lissage pour l’implémentation de cette commande.

Exemples de séparation en trois zones (rouge, vert, bleu)

> RLFF0000
< R
> GL00FF00
< G
> BL0000FF
< B
> 0C03RGB
< 0

Rendu du code

Le code du challenge devra se trouver dans un répertoire appelé « challenge2011″ dans la branche « master » de votre dépôt personnel. Il ne doit y avoir qu’un seul répertoire portant ce nom, et il peut se trouver où vous le souhaitez dans l’arborescence de votre dépôt.

RoseWheel : Choix des composants – Architecture matérielle

La réunion de vendredi avec Alexis et Samuel nous a permis d’éclaircir un certain nombre de points. Nous avons ainsi pu établir aujourd’hui un choix quasiment définitif de nos composants ainsi que l’architecture  matérielle de RoseWheel.

Le système est composé de 3 cartes :

  • Une carte mère contenant toute la logique
  • Une carte de puissance permettant de contrôler les moteurs Brushless
  • La carte de puissance permettant de contrôler les moteurs DC du projet ZZAAG

La carte mère qui se trouvera sur le guidon contient :

  • 1 processeur STM32 qui sera en charge de traiter les calculs nécessaires à l’implémentation du filtre de Kalman pour la fusion des capteurs ainsi que les calculs pour l’algorithme d’asservissement des moteurs. Concernant cet asservissement, nous avons choisi dans un premier temps d’implanter un PID. Ensuite nous nous dirigerons vers l’implémentation d’un LQR
  • Les capteurs permettant le contrôle de l’équilibre, soit le gyroscope et l’accéléromètre
  • 3 UARTs, pour une connexion RS232 pour le debug, une connexion Zigbee, une connexion Bluetooth
  • 1 LCD permettant d’afficher des informations pour l’utilisateur
  • Des jumpers ADC pour la connexion d’une partie des Sharps pour la détection des obstacles
  • 1 port CAN bidirectionnel permettant de communiquer avec la carte de puissance de contrôle des moteurs Brushless

La carte de contrôle en puissance des moteurs Brushless qui permettra aussi, dans un premier temps, de faire l’interface entre la carte de contrôle de puissance des moteurs DC du ZZAAG et la carte logique. Cette carte contient :

  • 1 processeur STM32 permettant de générer les PWM nécessaires au fonctionnement, d’une part des moteurs DC sur la carte du ZZAAG, d’autre part les PWM permettant de gérer le contrôle des moteurs Brushless
  • 1 connecteur CAN bidirectionnel fin de communiquer avec la carte mère logique différentes informations. Notamment les données permettant l’asservissement des moteurs
  • 1 jumper pour la connexion des Sharps nécessaires à la détection des obstacles à courte distance
  • 1 jumper pour la connexion des encodeurs
  • 3 ports pour la connexion des données provenant des capteurs à effet Hall du moteur Brushless et permettant de gérer le contrôle de ces moteurs

La carte de contrôle de puissance du ZZAAG qui sera contrôlée par la carte de contrôle de puissance des Brushless et qui ne nécessite en entrée que 2 PWM (1 pour chaque moteur) ainsi que 2 autres entrées permettant de contrôler la direction.

Le choix plus précis des composants est à priori :

Accéléromètre : LIS3LV02DL – 3 axes – port SPI – boitier LGA-16 – fréq échantillonnage 640 Hz – prix : 15,09 €

Gyroscope : IMU-3000 – 3 axes – port I2C – boitier QFN – fréq échantillonnage 8000 Hz – prix : 34,98 €

Encodeurs : HEDS-5500#A06 – Vmax 30000 tour/min ( un peu beaucoup mais moins cher ) – fréq échantillonnage 100 kHz – prix : 50,07 €

Bluetooth: AMB2300 – prix : 29,04 €

Xbee : XBP24-AWI-001 – prix : 30,62 €

LCD : MDLS16265LED043V – prix 39,29 €

Sharps :

  • GP2Y3A003K0F – Min distance : 20cm – Max distance : 150cm  - Angle de vision : 25°  - prix 55,35 €
  • GP2Y0A710K0F - Min distance : 40cm – Max distance : 300cm  - Angle de vision : 25°  - prix 25,57 €

Capteurs ultrason :

  • MSU05 – Angle de détection plus large que les Sharps (55°) : possibilité de fusion de capteurs – Utilisation simple : 1 GPIO – prix 21.5 €

Enfin voici un schéma de notre architecture materielle :

[CASPER] Architecture et liste de composants

Architecture globale

 

La beagleboard est l’élément central du système (www.beagleboard.org). Elle est chargée des algorithmes de haut niveau tel que le traitement de la vidéo et le traitement audio. C’est aussi elle qui se chargera de la connectivité internet et du pilotage des actionneurs.

Elle sera étendue par une carte embarquant un contrôleur STM32 chargé de piloter un écran LCD à partir de données stockées dans une mémoire flash.

Les informations sur les composants requis sont fournies dans les paragraphes suivants, les informations détaillées concernant les actionneurs/servomoteurs seront publiée dans un prochain post.

 

Ecran

Color LCD 128×128 Nokia Knock-Off

http://www.sparkfun.com/products/569

Avantage : bien documenté

Connexion au STM32 : un seul port SPI (pas de bus data)

Rq : sparkfun indique vendre un « loose connector » pour 2$ sur la même page, qui apparemment facilite le soudage…

Accessoires écran

1 transistor pour contrôle du rétroéclairage (http://fr.farnell.com/nxp/bc846/transistor-npn-boitier-sot-23/dp/1081227)

1 régulateur tension de 7V (pour le rétroéclairage).

Le modèle choisi sera finalement un LT1932 (http://fr.farnell.com/linear-technology/lt1932es6-pbf/ic-dc-dc-convert-led-dr-6sot2/dp/1651929). Il s’agit en réalité non pas d’un régulateur de tension mais d’une source de courant spécifiquement conçue pour alimenter une ou plusieurs leds.

Pour fonctionner, ce régulateur a besoin outre quelques résistances et condensateurs, d’une diode schottky (http://fr.farnell.com/rohm/rb050la-40tr/diode-schottky-40v-3a/dp/1680015) et d’une inductance de 6.8µH telle que celle-ci http://fr.farnell.com/panasonic/eljfa6r8jf/inductance-1210-6-8uh/dp/3838341 qui peut se commander à l’unité.

Carte STM32

1 STM32F103CBT6 (ou modèle équivalent, on a juste besoin d’un port SPI pour l’écran, un deuxieme pour une mémoire flash, un UART pour la liaison avec la beagle, et le reste des I/O serviront pour les extensions éventuelles)

1 régulateur 3.3V (L4931CD33)

1 prise jack pour l’alimentation

1 quartz 8MHz

1 prise JTag

1 switch (pour le reset…)

1 connecteur UART

1 transceiver UART (http://radiospares-fr.rs-online.com/web/search/searchBrowseAction.html?method=getProduct&R=6608802)

1 connecteur 6 broches (pour le SPI)

1 mémoire flash http://fr.farnell.com/spansion/s25fl032k0xmfi011/memory-flash-32m-3v-spi-8soic/dp/1861630 , qui servira à stocker les images pour le lcd

À noter : la fréquence de fonctionnement de cette flash (104MHz) laisse une marge suffisante pour récupérer des images 128*128 couleur à envoyer au LCD afin de l’animer. C’est en pratique le microcontrôleur qui limitera la vitesse de fonctionnement.

 

Son

Haut-parleur

2 Haut-parleurs MCKP2852SP1F-4752 (Ref Farnell 1801037, http://fr.farnell.com/multicomp/mckp2852sp1f-4752/dp/1801037)

Ce modèle est suffisamment petit pour pouvoir l’intégrer au visage de casper. Le deuxième pourra être placé dans le socle

 

Microphone

5 Micro pastille MCKPCM-40H15-40DB-4797 (Ref Farnell 1758416, http://fr.farnell.com/multicomp/mckpcm-40h15-40db-4797/microphone/dp/1758416)

Ce modèle a l’avantage d’être très plat (1.5mm) ce qui permettra de l’intégrer plus facilement. Plutôt que d’ajouter juste un micro à Casper, nous pourrions en ajouter 3 ou 4 autres à la base qui pourraient servir à la détection de la provenance du son. On peut alors imaginer toutes sortes de réactions du robot.

À noter : chaque microphone a besoin d’un petit circuit de polarisation, composé d’une résistance et d’une capacité de 5µF.

WiFi

Étant donné la présence de l’USB hôte sur la Beagleboard, nous pouvons pencher pour une solution de clef USB Wifi facilement trouvable dans la grande distribution (http://www.grosbill.com/4-bluestork_cle_wifi_nano_usb_wifi_n_150mbps-80561-reseaux-carte_reseau_sans_fil)

Une carte Wifi de facteur de forme SD pourrait toutefois être essayée (?).

Camera

Nous utiliserions là encore une Webcam très classique (http://www.grosbill.com/4-logitech_c120-100684-peripheriques-webcam) reconnue par linux.

Nous sortirions les différents composants de la coque de la caméra afin de pouvoir les intégrer dans un volume compact.

 

IRL : Avancées du weekend

Nous avons avancé dans le choix des composants avec pour objectif de fournir mercredi soir une liste quasi-definitive.

Nous utiliserons probablement :

  • Un STM32 sur la carte DMX sous FreeRTOS , avec deux tranceivers RS485/RS422 et le même module XBee que celui utilisé en TP.
  • Un STM32 sur la carte Laser sous FreeRTOS, avec une connection SPI vers la carte principale et une utilisation des deux DACs en mode 12 bits  (i.e 0.7mm de précision sur un écran de 3m par 3m).
  • Une Beagleboard en tant que carte principale (moins cher qu’une Gumstix compte-tenu de la connectique nécessaire) avec comme besoin : 
    • Ethernet
    • SPI
    • UART
    • DVI pour un écran pour faire l’installation
    • GPIO pour la configuration de l’IP (boutons) et le contrôle de l’extinction du laser
    • Petit écran LCD pour la configuration de l’IP
    • Carte SD