ELECINF344/381

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

Catégories

TSV Safe Express:Going ahead with Ethernet part

we have started today making some tests on the DCC part. As we have seen the good results with the oscilloscope, we moved to testing on a rail part by placing the train and sending the DCC commands through the rails. In fact we could command our train in both directions in different speeds.

Then, we started to implement a small module that takes Ethernet commands following a simple protocol. This module is translating the Ethernet commands to appropriate DCC and CAN commands in order to command different parts of our train model.

In parallel we still test the stability of our CAN module. Despite the good results there are very rare cases where our cards become unstable. We are making some modifications and we are going tomorrow to test on multiple light cards.

Our next PSSC is the initialization of Ethernet (what is already done) and control of our circuit from an extern program.

RoseWheel: tests preparation

This week we tried to put together our developments and make them interact with each other. It includes sensors communication, kalman filter, control feedback, motors control, CAN communication protocol. We were dogged by bad luck as we realized the heatsink of our mainboard was too big to fit in the Zzaag… A few millimeters required us to order for a new one with a more suitable shape. Fortunately Alexis and Samuel helped us to find a new one. Because of that we were not able to validate the following « feedback control tuning » PSSC for Saturday as planned. Adviced by Samuel we also decided to postpone the « encoders drivers » PSSC as it wasn’t really in our first order priorities.

 

We tried to make profit of this situation and decided to prepare everything for the first tests. Alexis helped us defining our tests procedure to be as safe as possible for both hardware and people. Motors need special attention as they can be broken with unsuitable commands. Because of the wheels and the weight of the chassis they have a really high inertia. Asking them sharply to reverse their direction of rotation when they are rotating fast can seriously damage them and the H-bridges. If we damage them we wouldn’t be able to order new ones before the end of the course, it would be fatal for our project. Therefore we need at first to make some testing at low speed so as to define the maximum acceptable speed at which we can run the motors before they get damaged. To this extent we need an interpreter running on the mainboard and communicating using RS232 to be able to give motors various commands and define this maximum speed. Then we need to limit our commands to this maximum speed using software limitations. Finally the interpreter should be able to change the feedback control values for our testing to be more flexible. We implemented such an interpreter and made a video. The motors commands in the video are given between 0 and 1000 such as:

  • ml0 = 0%:  max negative speed
  • ml500 = 50%: stop
  • ml1000 = 100%: max positive speed

 

Before trying the Zzaag motors we do some testings on other DC motors with less inertia that we cannot damage as easily as the Zzaag’s ones. Putting all the pieces together we were able to shoot a video which shows the motors reacting appropriately to the inclination of the sensorboard. As for the Kalman filter, we implemented a lighter version than the one of RoseWheel as it works best when tested on the real system. This version was only able to track the gyroscope drift and correct it. As far as we could see during the testing, it did it well. Concerning the PID, we tried to test the version that we are going to use in the RoseWheel but it still needs to be improved during the next tests.

 

Tomorrow we will be able to work on the Zzaag motors using our safe procedure and the tools developped. We look forward to it as it is a major step further for our project…

[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

TSV Safe Express: Day’s work.

Today we were able to control our leds using the TLC5945 Led Driver, although we have not yet exploited it’s capabilities at full extent.  As Alexis and Samuel proposed during our meeting, we should use dot correction in order to balance the mismatch of luminosity between green, red and orange. In addition, it would be useful to control intensity through TLC5945 grayscale mode especially once we assemble the whole system containing 60 leds.

Our next PSSC concerns DCC  control of the train , although there are many more things we are concerned about. At this point we are mostly concerned about switching from our laboratory based STM32F103 cards, to the STM32F107 based central station card. For the moment we haven’t yet achieved to configure the STM32F107 CAN bus drivers correctly. Once this is done we will do more tests and continue working on the stability of the NMRAnet CAN bus module.

One problem of the NMRAnet CAN bus net module is the fact that in presence of multiple producer consumer events, the nodes fail to reply in time, to the STATUS REQUEST message addressed to them by the central station at some point. We have thought that a possible fact that causes this situation is that for the moment nodes are using only one of the STM32F103′s  available CAN bus reception FIFO’s. In this case, processing the status request incoming packets is being delayed by event packets already present in the FIFO . Therefore we think that filtering out NMRAnet producer/ consumer event packets from one of the FIFO’s and letting them pass thorugh the other one  seems like an improvement.

 

RoseWheel : accelerometer done and progress update

One of our PSSC was to have a functionnal accelerometer for last monday. Despite the fact we didn’t post that day, we did have a working implementation and we were able to compute the inclination angle using the normalized 3D acceleration vector. We did this only with interruptions and without any kind of polling. The code was actually already working at our last demo. But in the meantime we’ve made some improvements that deserve to be described here. We used to detect rising edge of the accelero’s RDY pin to update the values. The rate at which values are calculated depends on the decimation factor chosen. According to the datasheet it spans from 40 Hz to 2560 Hz (with only 4 different values) and because of the fact we need 200 values per second we chose a decimation factor of 32 that enabled us to refresh values at a rate of 400Hz (closest value). Using interruptions at rising edge of RDY pin and then requesting the values from the device using SPI bus protocol was a bit demanding for the processor at this rate. We have therefore chosen not to use the RDY pin to be able to choose more precisely our rate of update. Some changes have also been made on the number of bytes used to represent data and a global coordinate system has been defined for both accelerometer and gyroscope.

 

Video of our sensorboard displaying the inclination angle using a color led.


Today we also assembled the mechanics of the Zzaag project. We could even try to ride it using the board shipped with. Here is a picture of what it looks like:

Mechanics of th Zzagg project

Mechanics of th Zzagg project

We had the time to begin the drivers for our hypothetical encoders (we are not sure to be able to set them on the mechanics) and we will be able to finish them tomorrow to be able to validate another PSSC.

At this point we have several pieces of software that wait to be integrated in our boards softs. The integration of the sensorboard has been started. In the main task an infinite loop wakes up every 5ms (200Hz). We retrieve the values of the accelerometer and the gyroscope that are updated separately in independant tasks. Then we need to give these values to the kalman filter for the final angle to be computed getting rid of the noise. But the kalman filter needs to estimate the next state before correcting the given values. We then need to receive the current values of the commands applied to the motors sent on the CAN bus by the main board. Finally we broadcast the computed angle and angular velocity on the CAN bus.

MB Led : PSSC pour ces trois prochaines semaines

Suite à la demande d’Alexis et Samuel, nous ajoutons des garants pour nos prochaines étapes:

- Contrôle de la matrice de LED.                                                      => 15 avril (Benjamin)
- Élection de leader sur un ensemble de bloc.                                    => 15 avril (Guillaume)
- Affichage d’une image sur un ensemble de bloc.                              => 18 avril (Benjamin)
- Lecture de données sur la SD Card.                                               => 18 avril (Cédric)
- Détection de la rotation d’un bloc (gauche, droite, demi-tour)            => 20 avril (Guillaume)
- Mise à jour du firmware via IrDA fonctionnelle                                => 24 avril (Cédric)
- Possibilité de jouer au morpion sur 3×3 blocs                                 => 26 avril (Benjamin)

Copterix : PSSC

Voici nos PSSC avec la date et le responsable :

  • Récupération des données des capteurs du STM32 – Date : 13/04Responsable : Samuel
  • Filtrage de Kalman fonctionnel sur la Gumstix – Date : 13/04 – Responsable : Axel
  • Communication entre la Gumstix et le stm32 avec un protocole permettant de récupérer l’ensemble des valeurs des capteurs et d’envoyer les consignes moteurs – Date : 13/04 – Responsable : Loïc
  • Piloter chaque moteur à la vitesse voulue (i2c) – Date : 15/04 – Responsable : Bertrand
  • Lucas et Kanade opérationnel sur la Gumstix – Date : 20/04 – Responsable : Samuel
  • Contrôler les moteurs en fonction des données des capteurs pour atteindre un vol stationnaire – Date : 20/04 – Responsable : Loïc
  • Gestion des déplacements – Date : 25/04 – Responsable : Bertrand
  • Contrôle avec une télécommande – Date : 25/04 – Responsable : Axel

TSV Safe Express: Résultats et précision des PSSCs

Après avoir fini l’écriture de mon Bootloader CAN je l’ai testé avec un programme que j’ai écrit  pour envoyer des messages en CAN suivant le protocole implémenté. Et là  j’avais un petit problème: si j’utilise mon fichier d’initialisation le CAN marche mais l’écriture en Flash ne marche plus et si j’utilise init.c de la bibliothèque c’est l’inverse. Après avoir comparé les deux nous sommes arrivés à booter en flash à partir du Bootloader CAN.

D’autre part, il me reste de tester mon programme qui prends des messages via UART et les envoie par CAN. Je ferai lorsque le serveur sera en marche.

Ce que nous faisons dès l’après midi est de lire chacun le code des autres pour être sur du respect de la norme NMRA, voire les éventuelles erreurs et en même temps comprendre ce que nous avons fait séparément. Nous  continuerons ensemble à finir la partie CAN: relier plusieurs cartes en même temps et commander les feux et capteurs.

Nous actualisons nos prochains PSSC et nous déclarons les responsabilités après une dispute sur qui prend celle de Ethernet:)

 

 

 

 

 

 

Copterix : PSSC

Voici la mise à jour de nos PSSC

  • Réalisation d’une carte d’extension fonctionnelle (design PCB)  – Fait
  • Récupérer la vitesse de translation grâce à la caméra  – Fait avec openCV
  • Communication Wifi avec le Copterix  – Statut : Ok en ad-hoc reste à tester avec un routeur wi-fi sécurisé – Date : 08/04
  • Récupération des données des capteurs du STM32 - Statut  : En cours, non testé – Date : 10/04
  • Filtrage de Kalman fonctionnel – Statut : Ok avec l’IMU, modulo un léger bruit,  reste à le tester sur notre PCB – Date : 13/04
  • Piloter chaque moteur à la vitesse voulue (i2c) – Statut : Non commencé – Date : 13/04
  • Communication entre la gumstix et le stm32 avec un protocole permettant de récupérer l’ensemble des valeurs des capteurs et d’envoyer les consignes moteurs – Statut : En cours de debug – Date : 13/04
  • Contrôler les moteurs en fonction des données des capteurs pour atteindre un vol stationnaire – Statut : Non commencé – Date : 20/04
  • Gestion des déplacements - Statut : Non commencé – Date : 25/04
  • Contrôle avec une télécommande – Statut : Non commencé – Date : 25/04

RoseWheel : Simulateur et Testbench

Aujourd’hui nous avons travaillé sur plusieurs fronts à la fois en vue de préparer la présentation d’une part et d’autre part d’avancer sur les différentes PSSC en cours, notamment la finalisation du TestBench et du simulateur.

Nous avons complètement restructuré la mécanique du Testbench. En effet, en rapport avec le Post d’hier soir, nous observions trop de bruit lors des transitions du moteur entre les différents angles.
Afin de palier à ce problème, nous avons ajouté un potentiomètre sur l’axe du servomoteur afin de pouvoir mesurer en temps réel et de façon précise le mouvement exact du moteur. Nous sommes alors en mesure d’extraire la partie issue du moteur dans le bruit du signal mesuré.
Nous avons de plus ajouté un rapporteur centré sur l’axe du servomoteur afin d’avoir un moyen de plus pour nous permettre de valider la fiabilité de la mesure des angles issus de l’accéléromètre et du gyroscope.

Concernant le simulateur, nous observons toujours des problèmes vis-à-vis des paramètres physiques. En effet, avec les paramètres que nous utilisons pour le moment, nous obtenons toujours une valeur saugrenue de la tension de commande (aux alentours de 3000V au lieu des 24V prévus). Nous avons donc remis en question chacun des paramètres que nous avions initialement calculés et nous sommes arrivés à la conclusion que les valeurs de la constante de couple reliant le courant au couple moteur et la constante de force contre électromotrice reliant la tension contre électromotrice à la vitesse de rotation étaient peut-être faussées.
Nous nous sommes donc penchés à nouveau sur une doc (très sommaire) des moteurs utilisés dans le zzaag. De plus Alexis nous a conseillé de simuler à l’aide de Matlab/Octave les équations d’état des moteurs que nous avions injectées dans les équations d’état de RoseWheel afin d’observer directement les valeurs du couple et de la vitesse de rotation de l’axe pour différentes valeurs des 2 constantes précédemment citées. Ceci nous permettra de vérifier les valeurs que nous avons calculé.

Dans l’optique de la présentation de demain, nous nous sommes penchés à nouveau sur un certain nombre de choses :

Le schéma de l’architecture matérielle a été revu et corrigé :

 

Le schéma de l’architecture logique a  été lui aussi corrigé :