ELECINF344/381

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

Catégories

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…

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

 

 

RoseWheel : CAN & Kalman

Today, we finished and/or improved some of the micro tasks we assigned to each other at the beginning of this week.

We tested a lighter version of the Kalman Filter that will be used in RoseWheel on the testbench we made a few weeks earlier. We used a light version because the full one needed to know the state equations of the system to be accurate. As we didn’t want to loose time trying to find out the state equations of the testbench (even if they are really similar to the ones of RoseWheel), we decided to test a version that was only able to track the drift of the gyroscope and make some minor corrections on the signal from the accelerometer during x axis translation. The light Kalman filter worked well and did what we expected, he tracked the drift and thus corrected the gyroscope noise and also filtered the signal from the accelerometer thanks to the sensor fusion.

During the experiments, we could observe that the noise from both the accelerometer and the gyroscope weren’t as high as we expected, that is a good news. However, even if the drift problem is correct by the Kalman filter, the measurements from the accelerometer are still not accurate during movements because of the noise induced by the other accelerations components. These other acceleration components are only dependents on the angle and its derivatives. We thought of a way to subtract those noisy components at each step by using the estimation of this values at the previous step. We will test it tomorrow on the testbench if we have time to do it.

We also finished the implementation of the CAN drivers and we tested it on our laboratory boards as we didn’t receive yet our mainboard. The tests were satisfaying. But as at the time we performed the tests we hadn’t decided yet the final version of the CAN protocol we were going to use for the communication between our 3 board (mainboard, sensorboard, HI board ), we didn’t use any filters. Hopefully tomorrow we will be able to test the CAN protocol as we will receive our mainboard.

 

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.

RoseWheel : à pleine vitesse

Voici un compte rendu des avancées que nous avons fait pour la démonstration de vendredi et pendant le weekend :

Carte capteurs

Côté accéléromètre, nous avons réussi à communiquer proprement avec accéléromètre en utilisant une interruption externe liée au signal RDY ; cela nous a permis plusieurs démonstrations intéressantes : contrôle d’une LED suivant l’angle, envoi des valeurs mesurées par le port série, affichage de l’angle mesurée avec Matlab.

Pour le gyroscope, nous avons eu plus de difficultés, notamment pour bien gérer l’implémentation du protocole I2C dans le STM32. Après quelques heures de debug, nous sommes arrivés à une implémentation minimale du driver pour la démonstration, les données lues étant transmises par le port série et affichées dans le même graphique que celles en provenance de l’accéléromètre ; cependant, le capteur parfois s’arrêtait sans explication.

Dans un premier temps, nous avions attribué ce problème à des micro-coupures d’alimentation. Néanmoins, nous ne sommes toujours pas satisfaits de cette explication, puisque une telle fragilité n’est pas désirable pour une partie si vitale de notre projet ; alors, nous avons travaillé sur le code pendant le weekend pour essayer de trouver la source des instabilités, mais nous n’avons pas encore trouvé la réponse. À suivre donc…

Filtre de Kalman

Nous avons implémenté en C notre filtre de Kalman dans la journée du vendredi. Afin de procéder aux tests « définitifs », nous attendons d’avoir des drivers plus fiables pour le gyroscope et la partie mécanique monté, étant donné qu’il est indispensable de tester le filtre dans les conditions prévues sur le système pour lequel il a été conçu.

Entre-temps, nous envisageons d’utiliser une version un peu modifié qui ne traquerait que la dérive du gyroscope sur notre banc de test. Pendant la démonstration, nous avons montré nos performances en simulation, dont nous avions parlé dans notre dernier post.

Banc de test

Nous avons également montré au jury le fonctionnement de notre banc de test, notamment le graphique de variation d’angle et de vitesse angulaire, que nous avons détaillé dans des posts précédents.

CAN

Nous avons aussi avancé sur le bus CAN, et nous pensons à le tester demain avec les drivers que nous avons écrit ce week-end.

Moteurs

Nous commençons à implémenter les des moteurs et l’utilisation de PWM pour contrôler les ponts en H.
Sur notre PCB, nous utilisons des « pilotes de demi ponts en H » (IRS2184SPBF) qui permettent (entre autres) d’éviter les court circuits.
Dans le schéma suivant, ces composants se brancheraient à droite et à gauche de façon à ne jamais avoir A et B à la même valeur :


Pour pouvoir changer le sens de rotation, on pense utiliser la broche enable disponible sur le « pilote » (IRS2184SPBF).
Le chronogramme suivant illustre ce que l’on croit nécessaire au moment de la transition d’un sens de rotation à l’autre :

 

De façon à éviter d’entendre le signal de contrôle, on pense utiliser une fréquence de l’ordre de 20KHz mais on ne sait pas encore si cela ne sera pas trop élevé pour « limiter les pertes lors de la commutation des transistors du pont en H ».
Un certain nombre d’incertitudes persistent donc toute suggestion serait la bienvenue !

Planning pour la semaine – « micro-tâches »

Envisageant pouvoir asservir correctement le segway avant dimanche prochain, nous nous sommes attribués les « micro-tâches » suivantes pour la suite :

Drivers carte capteurs

- I2C / Gyroscope -> João 12/04
- SPI / Accéléromètre -> Clément 11/04

Drivers carte principale

- Drivers Ponts en H -> Cédric 13/04
- Contrôle moteurs -> Cédric 14/04
- Drivers CAN -> Florian 11/04
- Tests Drivers CAN -> Florian 11/04
- Protocole CAN -> João 13/04
- Tests protocole CAN -> João 14/04
- Drivers encodeurs -> Clément 14/04

Tests filtre de Kalman

- Intégration filtre TestBench -> Florian 13/04
- Réglage filtre -> Florian 17/04

Intégration logicielle carte capteurs

- Implémentation asservissement en C -> Clément 12/04
- Réglage de l’asservissement -> Clément 17/04
- Réglage direction -> João 17/04

Divers

- Montage RoseWheel -> Cédric 12/04
- Montage encodeurs RoseWheel -> Cédric 13/04

RoseWheel : Une journée ensoleillée.

Tout d’abord, nous avons pu récupérer notre carte capteur en fin d’après-midi sur laquelle étaient soudés les principaux composants, en particulier l’accéléromètre, le gyroscope, un micromatch pour une UART et le STM32 de manière à ce que nous puissions effectuer les premiers tests et vérifier que les capteurs fonctionnaient bien.

Nous travaillons encore à traiter et à récupérer de façon propre les données de l’accéléromètre mais nous avons tout de même pu allumer une LED de deux couleurs différentes suivant l’inclinaison d’un axe, la preuve que celui-ci fonctionne comme il faut.

Nous sommes aussi en train de finaliser l’initialisation des drivers pour faire fonctionner l’I2C et le gyroscope. Les tests ne devraient pas tarder.

Enfin, nous avons pu faire fonctionner l’UART et envoyer des messages sur minicom. Ce fut un peu fastidieux et nous avons passé 2 heures à débugger une erreur très bête.

Coté filtrage, nous avons réussi à fusionner les 2 filtres de Kalman décrits dans le post précédent. Finalement nous obtenons un filtre de Kalman avec un vecteur d’état à 3 composantes [theta theta_dot drift]‘ et un vecteur de mesure à 2 composantes [theta_mes theta_dot_mes].

Les tests en simulation s’avèrent très bons, le filtre suit parfaitement le biais du gyroscope et ne décroche plus sur le long terme. Il a cependant fallu un peu de temps pour régler les valeurs d’initialisation. De plus, nous avons quasiment terminée l’implémentation en C et nous espérons pouvoir lancer des tests demain en fin de journée lorsque le gyroscope et l’accéléromètre seront en fonction.

To be continued.

RoseWheel : simulation et drivers

Aujourd’hui nous avons enfin terminé la partie simulation du RoseWheel. Nous sommes donc maintenant capables de simuler avec précision la dynamique du système ainsi que le filtrage des données des capteurs.

Évidemment, la modélisation exacte des différents paramètres, notamment les bruits des capteurs n’est qu’approximative et il faudra passer un peu de temps lors de l’implémentation en réel afin de les déterminer de manière correcte.

Concernant plus particulièrement la simulation du filtrage de Kalman, nous avons implémenté dans la simulation deux filtres de Kalman linéaires, le premier chargé d’extraire le biais de la mesure du gyroscope, le second chargé d’éliminer les composantes en hautes fréquences présentes dans les données du gyroscope et de l’accéléromètre. Cependant, pour des questions d’optimisation de temps CPU, on sera certainement amenés à fusionner ces deux filtres en un seul filtre, on espère que cela ne posera pas trop de soucis.

Nous avons cependant constaté que le filtre avait quand même du mal à suivre les variations du biais que nous simulions et que sur le long terme il lui arrivait de décrocher. Toutefois, nous pensons qu’il s’agit plus d’un problème au niveau de la simulation et que nous nous pencherons de façon plus approfondie sur le problème lorsque nous implémenterons le filtre en réel, c’est à dire demain.

Nous avons aussi pensé que cela pouvait être causé par la nature non linéaire du biais présent dans les données issus du gyroscope et qu’il serait peut-être nécessaire d’implémenter une forme de Kalman étendue plutôt que la forme linéaire. Mais encore une fois, nous testerons demain en réel afin de décider de la nécessité, ou non, de passer à une forme étendue du filtre.
Clément et Joao ont de leur côté continué d’implémenter les drivers pour les cartes.

Bonne nouvelle ! Alexis a terminé de souder les composants sur notre carte capteur. La journée de demain sera donc consacré aux différents tests de cette carte.

L’arrivée de notre carte est d’autant plus une bonne nouvelle que nous avons constaté un problème récurrent sur le gyroscope de la carte de Wheely que nous utilisions sur le testbench. En effet celui-ci a la fâcheuse tendance de ne plus rien retourner du tout parfois. Nous espérons que ce ne sera pas le cas sur notre carte.

RoseWheel : développement carte capteurs

Hier,

Cédric a terminé le banc de tests. Après quelques ajustements au niveau communication (les deux cartes n’envoyaient pas leurs données à la même vitesse) nous sommes en mesure d’afficher :

  • la valeur de l’ADC donnant la position du potentiomètre et donc l’inclinaison
  • l’angle d’inclinaison calculé à partir de l’acceleromètre
  • la vitesse angulaire donnée par le gyroscope
  • la vitesse angulaire calculée à partir des données de l’ADC

Voici un exemple de graphe affichant en rouge ADC, en bleu calcul de l’angle à partir de l’accéléromètre, en vert la mesure du gyroscope et en noir la vitesse angulaire calculée à partir de l’ADC :

La prochaine étape est donc de confronter la simulation de notre filtre de Kalman au banc de tests…

Florian a travaillé à ajuster notre filtre de Kalman pour qu’il ne tienne compte que des données que nous récupérons sur le banc de tests. En effet jusqu’ici nos simulations faisaient l’hypothèse de la présence d’encodeurs. En simulation nous éstimons connaître parfaitement notre déplacement et notre vitesse de déplacement. Le montage du Zzaag nous dira si il est possible ou non d’inclure des encodeurs dans notre version finale. Florian et João ont également travaillé à l’amélioration du simulateur et de l’asservissement LQR.

João et moi-même avons bien avancé sur les drivers. Nous avons développé ces derniers en utilisant la bibliothèque STM32F10x_StdPeriph_Driver ce qui nous permet d’avoir un peu plus de flexibilité qu’en configurant directement les registres. Nous essayons d’implémenter les drivers pour nos différents périphériques aussi indépendemment que possible du brochage. Ainsi, pour chacune de nos cartes, nous aurons juste à « instancier » nos périphériques en indiquant la patte sur laquelle ils sont branchés. Nous avons nommé cette bibliothèque libperiph et en générons une version statique (.a) que nous lierons avec les objets de nos différentes cartes. Nous disposons dores et déjà de drivers pour :

  • Adcin (tout périphérique nécessitant des conversion ADC en « single conversion »)
  • Button
  • Buzzer
  • Leds
  • Sharps (utilisation de l’ADC en « continuous conversion » et du DMA)
  • Switch

Nous allons aujourd’hui tester ces drivers sur la carte de TP et implémenter les autres :

  • CAN
  • Accéléromètre (SPI)
  • Gyroscope (I2C)
  • UART
  • Bluetooth
  • Sonar
  • Encodeurs
  • Moteurs

Copterix : simulation du filtre de Kalman

Avec Axel, nous nous sommes penchés sur le filtre de Kalman. Après de longues lectures, nous sommes arrivés à clarifier les équations mises en jeu.

Nous avons finalement décidé d’opter pour un vecteur d’état contenant les trois biais des gyroscopes ainsi qu’un quaternion déterminant l’attitude de l’hélicoptère. Nous étions initialement partis sur un vecteur d’état contenant les trois biais des gyroscopes ainsi que les deux premières colonnes de la DCM (Direct Cosine Matrix) qui elle aussi permet de déterminer l’attitude de l’hélicoptère. Ce changement nous a permis de réduire de 2 éléments notre état.

Nous avons dans un premier temps implémenté le filtre sous Matlab. Voici quelques illustrations de nos avancées :

 

 

La courbe en rouge représente l’état prédit et la courbe bleue l’état mis à jour. Nous avons choisi d’accorder plus de confiance aux valeurs estimées par le filtre qu’aux mesures. Malgré un fort bruit, le filtre se comporte plutôt bien.

Mais encore pas mal de travail reste à faire notamment au niveau de la détermination des différentes constantes mises en jeu dans le filtre ou encore au niveau du testbench.

RoseWheel : PCB, banc de tests

Après deux jours de travail, nous avons fini les schémas de nos PCB et, à l’heure où cet article est écrit, nous parachevons le routage de la carte capteurs (autrefois appelée « carte logique »). Parmi les changements clé que nous avons faits, nous pouvons citer notamment l’inclusion d’une alimentation exclusive pour les références des convertisseurs analogique-numériques à l’intérieur du gyroscope et de l’accéléromètre – cela permet d’avoir des conversions plus fiables et donc de réduire le bruit des mesures.

Pour la carte principale (ancienne « carte de puissance »), les plans ont été un peu modifiés : finalement, le circuit de puissance, responsable du contrôle des moteurs en courant, sera intégré par Alexis à la carte, principalement à cause de problèmes d’intégrité du signal (utiliser le bus CAN en entrée permet d’être plus robuste face aux bruits induits par les moteurs à courant continu) et économiques (l’intégration élimine la nécessité de fabriquer une troisième carte qui ne ferait qu’accepter un PWM en entrée et le transmettre aux moteurs).

Côté banc de test, nous avons réussi à contrôler le servomoteur en angle avec la carte de TP, en utilisant les broches originalement assignées au bus SPI pour sortir du PWM. Nous avons commencé alors à le calibrer, puisque la position horizontale (à 0°) ne se trouve pas forcement au milieu de l’échelle du PWM ; pour faire cela, nous avons utilisé une application Android qui nous indiquait l’angle d’inclinaison du téléphone portable. Voici notre dispositif expérimental :

Après cela, nous avons  fini la partie mécanique en fixant une planche de balsa pour tenir la carte dans sa place pendant que nous faisons les tests. Le montage final est celui-ci :

Par rapport à la simulation physique, nous hésitons encore entre continuer à la développer en Octave ou passer à Matlab, étant donné que certaines bibliothèques utiles pour l’implémentation du filtre de Kalman ne sont pas disponibles dans le logiciel libre.