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.

RoseWheel: first ride

Tuesday evening, after nearly two days of fine-tuning our testing procedures and security measures, we finally did the first tests on our own vehicle. In order to make sure we didn’t damage the equipment (nor hurt somebody), we followed a simple and strict protocol:

1. First of all, we checked that we could control manually the motors via our interpreter;

2. Then, we verified that the limitations we applied to the variation of the voltage of each motor were adequate (as mentioned in a previous post, an abrupt increase or decrease on the voltage could severely damage the motors);

3. Finally, we determined a maximum speed that seemed reasonable, so that we could stop the vehicle manually should the worst happen.

After this initial procedure, we could start the actual tests of our system. After some iterations of tuning the coefficients of our controller, we realized that it was actually much easier to equilibrate the vehicle with a human being on top of it than without any load, since:

(i) the person enhances the performance of the control system by balancing his/her weight in a way that maximizes stability;

(ii) the presence of the human being makes the test conditions closer to the physical model we used to compute and simulate the parameters.

After several adjustments, we were able to take our first ride on the RoseWheel -- with basic steering capabilities via the integrated potentiometer implemented as a plus.

Nevertheless, by wednesday morning we had not yet found a way of balancing the RoseWheel alone -- a must for our next major goal, remote control. Then, we realized that the chassis we used had a very interesting property: by tilting it to a specific angle, we could align the center of gravity of the steering bar with the axis of the wheels, reaching a metastable equilibrium. We used this fact to offset the error variable of our PID controller, and that proved to be very effective, since we obtained as a result a pretty good stability. But all this comes at a price: since we now have two different equilibrium positions, we must use the safety button located on the chassis to determine if we are carrying a person or not; nothing too difficult to implement, though.

On the other hand, the PID coefficients may be trickier to master. We are still working on them to solve the issues we are having, notably oscillations and vibrations that sometimes occur. To help us with the debugging, we set up a solution to plot angle, angular velocity, and output voltage command for each one of the motors. Our next actions on this front will be to use all these data to better tune Kp, Ki and Kd, so as to have a more responsive and stable control algorithm.

Meanwhile, we started to move on to our next goals: we began to study the Bluetooth controller, and are already able to compile and run a « hello world » Android application. Next steps include implementing drivers for our distance sensors to implement obstacle detection.

To summarize all our work, we prepared a special video showing some of the most interesting (and/or funny) demos we made so far. Enjoy!

 

RoseWheel: gyroscope and communication protocol

Yesterday, after several days of debugging, we finally managed to gather data from the gyroscope. We ultimately found out that the freezes we were experiencing were caused by a reset interrupting an I2C cycle in the exact moment a slave was about to write a ’0′ on the SDA line (as an acknowledgement or during a read cycle); when the STM32 woke up and tried to generate a START condition, the slave would immediately force SDA to a low state, thus preventing the microcontroller from reclaiming the bus. We fixed this problem by sending several clock pulses on the SCL line until the IMU-3000 releases SDA; then, we can force a STOP condition and abort the incomplete cycle.

We have also completed a first version of our communication protocol. Under normal operating conditions, the following messages are exchanged on the bus:

ID Name Description Vital MAIN SENSOR HI
0×08 STOP Emergency Stop !!! Tx/Rx Tx/Rx Tx/Rx
0×09 RESET Reset !!! Tx/Rx Tx/Rx Tx/Rx
0x0A ANGLE_ANGVEL Angle from accelerometer, angular velocity from gyroscope !!! Rx Tx
0x0B SPEED Speed of RoseWheel !!! Tx Rx Rx
0x0C DANGER Danger (detected by distance sensor) !!! Tx/Rx Tx Rx
0x0D MOTORCOMMAND Command sent to the motor
0×10 REMOTECONTROL Remote control (from Bluetooth/UART) Rx Tx Rx
0×11 BATTERYLEVEL Battery level Tx Rx Rx
0×12 USERCOMAND User command Rx Rx Tx

In debug mode, the sensor board sniffs the bus so that it can send it by Bluetooth or serial port. The HI board monitors the exchanges as well to display relevant information on the LCD:

ID Name Description Vital MAIN SENSOR HI
0×08 STOP Emergency Stop !!! Tx/Rx Tx/Rx Tx/Rx
0×09 RESET Reset !!! Tx/Rx Tx/Rx Tx/Rx
0x0A ANGLE_ANGVEL Angle from accelerometer, angular velocity from gyroscope !!! Rx Tx Rx
0x0B SPEED Speed of RoseWheel !!! Tx Rx Rx
0x0C DANGER Danger (detected by distance sensor) !!! Tx/Rx Tx/Rx Rx
0x0D MOTORCOMMAND Command sent to the motor Tx Rx Rx
0×10 REMOTECONTROL Remote control (from Bluetooth/UART) Rx Tx Rx
0×11 BATTERYLEVEL Battery level Tx Rx Rx
0×12 USERCOMAND User command Rx Rx Tx

 

 

MB Led: Firmware, Bluetooth, bibliothèque graphique.

Depuis dimanche j’ai eu l’occasion d’avancer sur différentes parties:

Firmware:

Comme je l’explique dans mon précédent article nous mettons en place un système de mise à jour de firmware via IrDA. Mon travail a été d’implémenter, en utilisant les bibliothèques ST, les fonctions de déplacement de secteur de la flash depuis un bootloader situé en début de flash. J’ai effectué mes tests sur la carte de TP et utilisé objdump et openocd, ainsi que deux versions du « firmware » pour mes tests (un qui éclaire la LED en bleu et l’autre en vert). Une phase de débugage assez longue: des pages qui sont effacées sans le vouloir, la raison étant que la ligne de commande openocd faisait un « reset halt »  qui relancé l’ancien bootloader pour un nombre indétrerminé d’instructions, effaçant ainsi des mauvaises pages. Désormais on peut manipuler la flash à notre guise depuis le bootloader et effectuer la phase de recopie du nouveau firmware avant de l’exécuter sans problème.

Bluetooth:

J’ai commencer à implémenter réception/émission de commandes/réponses coté MB Led. Dès que je récupère un module bluetooth F2M03GLA, je pourrais faire des premiers tests de communication avec un client bluetooth sur mon pc.

Bibliothèque graphique:

Ecriture de premières fonction de manipulation des images, inspirées du code GLiP et d’autres plus adaptées au mode jeu (affichage de sprites, de lettres …).

A faire:

Nous devrions bientôt récupérer quelques unes de nos cartes avec les composants soudés. Je pourrais alors tester mon code pour le driver LED. En attendant je continue d’avancer sur les trois points précédents.

MB Led: Algorithmie

Après une journée très épuisante lundi avec le communication challenge, nous voilà reparti sur le projet. Hier, j’ai revu l’algorithmie de base avec l’aide de Cédric et Benjamin. Aujourd’hui, j’ai parlé avec Sam sur le zéro MQ. En effet, pour l’instant, ma simulation est uniquement en Python (une classe pour le module, une pour l’envoi de message, une pour la réception). Sam me dit qu’il serait préférable — quand l’algorithmie sera au point — de programmer les modules en C directement et d’utiliser zéro MQ pour simuler un scénario et envoyer les messages entre modules.

 

Le schéma algorithmique est le suivant :
PING -> ELECTION DE LEADER -> ORIENTATION -> POSITIONNEMENT.

  • PING

Les modules ping tout le temps leur 4 interfaces (disant « HELLO MY_ID »). Au bout d’un certain nombre de messages reçus sur une interface, il considère qu’il a un voisin.

  • ELECTION DE LEADER

A la fin de la phase d’identification, il y a « élection de leader » pour savoir qui décidera de l’orientation. Pour l’élection, on choisit le module Bluetooth en premier et sinon, c’est celui avec l’ID le plus grand.

Si un module arrive sur un réseau déjà orienté, il n’y a pas d’élection de leader, il « subit » la loi du nombre.

  • ORIENTATION

Le « leader » oriente les autres modules selon son orientation.

  • POSITIONNEMENT

Le but est de savoir à chaque instant qui est dans le réseau (et où exactement).

Nous avons opté pour la création d’un tableau de voisin stocké en RAM. Au centre de ce tableau est inscrit le numéro du module.Ensuite, les voisins « directs » (accessibles par IrDA) sont stockés selon l’UART avec laquelle ils communiquent.

Ex : Le module est en rouge ici, le voisin qui communique avec l’UART 1 est stocké en 1, etc.


Quand un module arrive sur un réseau, il n’est pas considéré comme faisant parti du réseau tant qu’il n’est pas orienté correctement. Quand il le devient, il envoie un message à ses voisins disant « coucou je fais parti du réseau », ce à quoi on lui répond « OK. Voici tous les modules connectés au réseau (avec leurs coordonnées) »

Quand l’algorithme de positionnement sera fini (d’ici peu j’espère), je passerai à la programmation en C des modules et je tenterai un affichage graphique de la simulation.

 

MB Led et PCB

Aujourd’hui, fin du STM32 et continuation du projet. J’ai donc continuer à faire le PCB que Benjamin avait repris en l’adaptant à l’évolution des composants.
Il a donc fallu lire les Datasheets des composants qui avaient changé lors de la commande ce qui permet ce soir et après le TP une meilleur vision de leur utilisation.
Après les suggestions d’Alexis, nous avons cherché un nouveau driver de LED car l’ancien proposait une sortie en PWM ce qui aurait posé des problèmes avec le système d’affichage ligne par ligne. Nous resterons donc chez TI mais prendrons le TLC5951 dont les sorties sont à courant continu. L’avantage de ce driver est qu’il possède 24 sorties réparties en 3 groupes permettant de gérer ensemble des paramètres comme l’intensité maximale. Il prendra 5 pin pour le contrôler 2 timers et 3 des quatre fils du SPI (MISO,MOSI,SCK).

Pour le module bluetooth, nous aurons également besoin de 5 pin (2GPIO, 1UART, un reset) afin de pouvoir configurer le module.

Tout cela m’a permis de finaliser le brochage et demain je commencerai le routage.

MB Led: Article post communication challenge.

Aujourd’hui j’ai enfin réussi à flasher quatre modules conçus par l’équipe GLiP de l’an dernier. J’ai flashé le code maitre pour un bloc contrôlable avec un PC et minicom pour la sélection des animations ainsi que le code pour trois esclaves.

Lors de la compilation de ces codes sont incluses les différentes animations préalablement convertis grâce au script python gif2glip (conçu par l’équipe GLiP).

Nous avons donc pu faire tourner des petites animations sur un réseau carré de quatre GLiP tout en constatant que les animations étaient bien affichées après mélange des blocs.

Cette étape m’a permis de me familiariser avec l’architecture du code de GliP et de m’imprégner de leurs algorithmes pour la réorganisation du réseau ainsi que pour l’affichage des images via les drivers de LED. La compréhension de ce code nous permettra de faire des premiers tests notamment pour les communications IRDA et nos algorithmes réparties en attendant d’avoir nos propres modules.

Ce soir je me suis consacré à la réorganisation de nos PSSC et à la création d’un diagramme de Gant pour une meilleur répartition des ressources dans notre équipe. Le temps passé sur le TP sur le STM32 nous a obligés de décaler les différentes deadlines pour nos PSSC.

====== Reprise du projet GLiP : ======
- A partir de GIF convertibles par gif2glip nous savons les charger via le bloc maître et les jouer sur un réseau de bloc en utilisant leur matériel ⇒ Fait

====== Conception de la carte et test : ======
- Choix des composants terminé : Fait

- Image PCB prête (on peut passer la commande du circuit imprimé) ⇒ 25 mars

Puis en supposant que nous recevons les PCB au plus tard le 4 avril :

- Soudage des composants sur les cartes => 6 avril

- Contrôle de la matrice de LED (affichage d’image) ⇒ 15 avril

====== IRDA ======
- Echange de messages entre deux blocs ⇒ 11 avril

- Ecriture via Irda sur la sdcard => 22 avril

====== Bluetooth: ======
- Communication Bluetooth avec un ordinateur ⇒ 16 avril
- Exécution de commandes reçu en Bluetooth ⇒ 21 avril
- Application de contrôle Android ⇒ 26 avril

====== Gestion de la mémoire : ======
- Lecture sur la SD Card. ⇒ 12 avril
- Ecriture sur la SD Card. ⇒ 17 avril
- Exécution d’un programme stocké en SD Card. ⇒ 22 avril
- Mise à jour du firmware depuis la SD Card. ⇒ 24 avril

====== Système réparti : ======
- Environnement de simulation en place ⇒ 3 avril
- Gestion dynamique du réseau de bloc⇒ 15 avril

====== Jeux sur l’ensemble : ======
- Jeu du morpion fonctionnel (sans Bluetooth) ⇒ 24 avril
- Jeu du morpion fonctionnel (avec Bluetooth) ⇒ 27 avril

 

Rosewheel : conception des cartes

Conformément à nos objectifs, nous avons passé la journée à établir les schémas électriques de notre carte logique et capteurs.

Vu la diversité des bus de communication de nos capteurs et le nombre d’entrées/sorties nécessaires, nous sommes d’abord partis sur un processeur de type STM32 possédant 64 broches contre 48 pour celui utilisé sur la carte de TP (le processeur reste le même). Après avoir fait l’assignement des broches nous nous sommes dit qu’il serait peut être plus simple d’essayer de brocher le STM32 sur un boitier de 48 broches. Nous avons donc fait deux modifications majeures vis-à-vis de notre modèle initial :

  • Au lieu d’utiliser un port SPI pour l’accéléromètre et un port I2C pour le gyroscope, nous avons choisi de tout multiplexer sur l’I2C. D’aprés nos calculs ça devrait pouvoir tenir le débit.
  • Au lieu d’utiliser 3 UARTs, nous n’utilisons que 2 UARTs et branchons sur la même UART le module Zigbee et l’UART de debug.

Nous nous sommes aussi rendu compte que le module Bluetooth que nous avions initialement choisi était maintenant déconseillé par le constructeur pour des applications Bluetooth récentes. Nous nous sommes donc rabattu sur le même module que celui utilisé l’année dernière par l’équipe Wheely.

La majeure partie étant faite (schéma électrique), nous ferons le placement et le routage dans le courant de la semaine prochaine afin de pouvoir bénéficier de conseils sur l’intégrité du signal notamment. Cela nous a laissé le temps de commencer notre carte de puissance. Nous n’avons néanmoins pas pu terminer le schéma électrique du fait de notre manque de connaissance en électronique de puissance (une petite aide serait la bienvenue). Globalement, la commande des moteurs brushless serait réalisé par 6 transistors MOSFET commandé par 6 PWM en sortie du processeur STM32. 3 capteurs à effet hall sont aussi présents afin de permettre au STM32 de connaitre à chaque instant la position du rotor par rapport aux stators du moteur.

Pour les schémas électriques de la carte de puissance nous nous sommes basés sur ce document : Contrôle Brushless.

Nous avons assigné plus de broches que nécessaire sur les cartes logiques et de puissance pour les sharps et les sonars afin de nous laisser la liberté de choisir ensuite plus précisément la meilleure configuration possible.

Le schéma de la carte logique et capteurs est disponible ici. Toute remarque est bienvenue.

MB Led : architecture fonctionnelle

Durant cette semaine, nous nous sommes surtout focalisés sur le TP STM32. Cependant, nous avons revu notre choix des composants pour MB Led.
Nous avons trouvé – merci Alexis – le TCL59116 de chez Texas Instrument. C’est un driver de LED où le contraste de chaque LED est programmable en soft. Ainsi, il serait possible d’avoir la même intensité pour toutes les LEDs. Etant donné qu’il contrôle seulement 16 LEDs, nous en prendrons deux. Le STM32 communiquera avec les TCL59116 par bus I²C, ce qui ne changerait pas notre brochage.
Pour le reste des composants, nous ne changeons pas notre choix initial (cf https://spreadsheets.google.com/ccc?key=0AncMdD-cz6M-dE5adzNDWkNnel9qNzd3LU1faUpuNEE&authkey=CNSan78L&hl=en#gid=0 )

Durant ce week end, j’ai aussi continué de programmer le test bench en Python. L’apprentissage du python se fait difficilement mais j’arrive à communiquer entre deux threads, c’est déjà un bon début.

Voici notre architecture fonctionnelle : les 16 blocs ont la même face recto et pour le verso, un des bloc intègre un module Bluetooth tandis que les autres ne l’ont pas.

 

MB led: Liste des composants, modulation d’intensité et Python

Depuis vendredi dernier nous avons terminé d’établir la liste des composants qui serons utilisé dans chacun de nos blocs. Elle possède quelques différence avec celle du projet GLIP, leurs tranceivers IRDA ne sont plus disponibles, nous intégrerons un lecteur de carte microSD, nous rajoutons des résistances variables. Nous intégrons aussi à l’un des blocs le module recevant et émettant des informations en Bluetooth depuis un terminal Android. La liste détaillée se trouve ici .
Le coût total serait pour l’instant de plus de 1000€ pour 16 blocs et un module bluetooth ce qui parait excessif, il faut que nous trouvions une alternative afin de diminuer cette somme.
Nous nous sommes posées la question de la modulation de la puissance des LEDs bleus qui, d’après l’équipe de GLiP, serait 10 fois plus puissantes que les jaunes et rouges. Pour cela Samuel nous a conseillé d’utiliser une résistance variable réglable depuis en logiciel, l’idée serait d’en connecter une par colonne de led bleu (8 au total), nous les brancherions toutes sur la même sortie GPIO du micro-contrôleur, mais en mettre 8 prendrai une place considérable sur la carte. Nous cherchons des réseaux de résistances variables afin d’économiser de la place sur la carte.
Guillaume s’est intéressé ce week-end à la programmation en Python, langage qu’il ne connaissait pas, mais qui nous a été conseillé pour développer un environnement de simulation de notre réseau de bloc notamment pour son paradigme objet. Cela nous permettra avant même d’avoir les cartes de pouvoir définir précisément le comportement de notre système dans des scénarios variés. Cette environnement part du principe que les communications infrarouge se déroulent sans problèmes (trop grande portée de l’infrarouge, messages corrompus, temps de réaction trop lent etc) cela afin de bien séparer dans un premier temps matériel et algorithmie.
Voici une présentation de Gerard Padio qui traite d’algorithmie répartie et d’échanges d’informations entres modules dans un réseau pair-à-pair. Cela correspond exactement à ce que nous voulons faire. Nous pensons donc nous inspirer de ce protocole pour gérer les échanges inter-blocs.