ELECINF344/381

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

Catégories

RoseWheel now detects obstacles.

Yesterday we finished to implement the drivers for both the distance sensors: the infrared and the ultrasonic one. They actually work better than expected as their detection cones are a little thinner than expected.

At last, Rosewheel will come with 2 infrared sensors and 1 ultrasonic sensor. The infrared sensors will be used to detect falls and ravines whereas the ultrasonic sensor will be used to detect obstacles.

It’s not possible to link the sensors to the mainboard with a wire longer than 15cm, we will not be able to place them on the top of the handlebars to detect ravines as we previously thought. But, given the fact that the detection cone of the infrared sensor is really thinner than expected we finally conclude that we will have a sufficient range to detect ravines with sensors place on the chassis basis.

Indeed, we need a range of detection long enough as even if it could sound a bit counter-intuitive, to stop, Rosewheel needs to accelerate so that it could place back its center of gravity upright the wheels axis and then stop.

For the obstacles detection, we will use the ultrasonic sensor placed right in the middle of the chassis, with a slight upward inclination so that it doesn’t take the floor as an obstacle. As the range of detection is up to 4 meters, it will generate errors with long distance obstacles that aren’t actually on RoseWheel’s path. Thus, we have to handle only the detection of obstacles that are closer than 4 meters. We haven’t yet defined this range but we will have a clearer idea during the tests.

To be continued.

 

RoseWheel: Improvement of the PID

These last two days we mainly worked on tuning the PID coefficients to improve the stability. In this way, we tried to find the best set of PID coefficients so that RoseWheel could raise from an almost horizontal position and recover stability as soon as possible and then maintain this stability over time, even under hard external perturbation. We also worked on improving the coefficients we found for the human driving mode to make the right compromise between smooth-driving and responsiveness.

watch?v=Bn9MVGXuFqQ" /> watch?v=Bn9MVGXuFqQ" type="application/x-shockwave-flash" allowfullscreen="true" width="425" height="344">

During this test and improve phase, Alexis advised us to plot the curve of the different values critical for our system. Thus, we plotted over time the value of the angle and the angle rate before and after the kalman filtering and also the command sent to the motor calculated by our PID algorithm.

It made us find 2 problems in our software that explains why at the beginning RoseWheel was so unstable:

  • The Kalman filter wasn’t configured correctly. We first configured it for the testbench but we forgot to change the time step that was indeed ten times smaller than the correct value. That led to latency and incorrectness in the output of the Kalman filtering. Changing this parameter to its correct value made the system become really more stable.
  • Even after the Kalman filtering, we noticed that the angular rate was still a lot noisy. This noise caused our gyropod to vibrate a lot when increasing the derivative coefficient Kd in the PID. That is a problem because increasing the derivative coefficient is the only way we have to lower the amplitudes of the oscillations induced by a big proportionnal term Kp in the PID. Thus, we decided to smooth the angular rate value by using a low-pass filter after the Kalman filtering. It’s really a simple filter as it’s only made of 2 coefficients, but according to the plots, it made its work correctly and the angular rate seems to be really smoother than before. But while testing, increasing the derivative coefficient still leads to oscillations and vibrations, so we still have to work on it.

As we obtained satisfying results at making RoseWheel maintain its equilibrium, we started working on other features :

We implemented the safety switch and elaborated a protocol to avoid as much dangerous situations as possible :

At the very beginning, when one presses the power on button, RoseWheel is in self-driving-mode by default. That means it will try to reach its equilibrium position as soon as possible and then remain in this position. We assume that the user isn’t too silly and, for instance, will not try to power on RoseWheel in an almost horizontal position whereas he is facing it. Then, as soon as the safety switch that is located on the base is pressed, that means that someone has its foot on RoseWheel and wants to ride it : RoseWheel switches to its human-drive mode. If suddenly the safety switch is released, RoseWheel checks the angle. If it’s almost 0°, that means that RoseWheel’s speed is almost 0 and the person maybe wants to get out, then calmly RoseWheel switches to its self-driven mode (we still need to implement it). If the angle is under 75°, that could means two things: the person has felt down or the person has temporarily raised its foot. Thus, if the safety switch isn’t pressed within 1 second, RoseWheel makes a special noise, then, if it’s still not switched on within another second, RoseWheel switch to its self-driven mode. Finally, if the angle is greater than 75°, that means that the person has felt down and RoseWheel could represent a menace for people around, motors are disabled.

2) Concerning the obstacle detection, we almost finished to implement the sharps and sonar drivers. As these detectors are really sensitive to the external conditions, we still have to test them and see how they react in the different environnements RoseWheel will evolve in.

3) Concerning the remote control, we almost finished to implement the drivers for the Bluetooth, we made some tests yesderday, but we still need to continue them today and we will talk more about it in the next article.

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!

 

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

[CASPER] Avancées du projet côté mécanique…

Du côté de la mécanique, nous avons mis en pause le développement des drivers linux qui doivent à terme contrôler les moteurs. En effet, nous avons jugé que commander les moteurs au plus tôt et avec précision était plus prioritaire. Nous nous sommes donc penchés sur le contrôle des servos par PWM en utilisant la carte de TP STM32.

Jusque ici nous avons écrit un programme qui prend en charge les trois servos, qui est capable de prendre en entrée un angle comprit entre 0 et 180° et d’amener un servo à cette position. La prochaine étape est d’implémenter le modèle mécanique que nous avons conçu afin de donner au programme la direction de casper (sur 360°) et son inclinaison (sur 90°). Le programme interprétera ces données en terme de commandes moteurs.

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.