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


Copterix: Flight in the complex

Today, we went to the complex, a more spacious room than the one where we used to do our tests. The tests were quite conclusive. We were able to do some « landing » (the copter was caught by Axel near the floor because of turbulences caused by the proximity of this obstacle). With more power to the motors, we made the copter stay longer in the air, about 10/20 seconds (sadly, it wasn’t filmed).

We also used the remote to control the trust and the setpoint of the PID. It will need some software adjustments since it is still to brutal and rather hard to use.

Tomorrow, we’ll restore height control in our PID and see how much the copter drifts. This drift shall be corrected with the remote.

Copterix: some reflexions about Kanade

After having spent hours focusing on our PID into the Télécom ParisTech’s dancing room, we joined Télécom Robotic’s room in order to work on our implementation of Lucas and Kanade algorithm, because of a giant chessboard in green and red, perfect for image processing. We fixed Copterix in the air using some strings, and started test, with or without threshold, and it wasn’t really efficient…
We thought a moment about using ‘unfisheye’ opencv’s algorithm (see joined photo to understand why we wanted to use it), but it took 0.6 seconds per frame on our Gumstix…


What our camera actually sees: we can observe a 'fisheye' effect

Then we stopped and decided we should decide exactly how, even if it worked, Lucas and Kanade would help us to correct Copterix’s drift.
As we have 10 frames per second when processing the algorithm, it will be really difficult to determine in real time if we actually corrected the drift whenever we would want to correct it, and that is why we imagined the following algorithm:

  1. wait for Copterix to be horizontal (pitch and yaw < epsilon)
  2. take a reference picture and search the good features to track on it (quite heavy operation)
  3. while Copterix is horizontal (pitch and yaw < epsilon)
  4. ____take a picture, compare it with reference
  5. ____if not horizontal (pitch and yaw >= epsilon)
  6. ______wait for Copterix to be horizontal (pitch and yaw < epsilon)
  7. ______go to 3.
  8. ____if drift is big enough (move size > threshold)
  9. ______go to 12.
  10. ____if we don’t find enough features to track
  11. ______go to 1.
  12. ask PID to incline Copterix toward the good direction (we have to decide an angle)
  13. wait a chosen time (we have to be over-precise on this data)
  14. ask PID to set Copterix horizontal
  15. go to 1.

The real difficulty of this algorithm is that it infers we do own a powerful and precise PID, able to remain horizontal most of the time, and to follow an order in the better and faster possible way, which is of course not true.

That is why we are now considering the fact that we may not have time to have a excellent PID AND implement such a precise algorithm; we will talk about it tomorrow with our teachers.

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 : 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] Implémentation du filtre de Kalman

Après de nombreuses hésitations quant à l’implémentation exacte du filtre qui nous permettra de traiter les données issues des capteurs de position (drift du gyroscope notamment) nous nous dirigeons de plus en plus vers l’association entre un filtre complémentaire (présenté dans un post un peu plus bas) et un filtre de Kalman permettant d’estimer le drift du gyroscope à chaque instant.

L’implémentation du filtre de Kalman est en fait assez simple. Voilà les données du problèmes :

On mesure à chaque instant la vitesse angulaire (theta_dot)  et l’angle d’inclinaison du manche de RoseWheel par rapport à la verticale (theta).

On considère que la mesure theta_m de  l’angle d’inclinaison est entachée d’un bruit blanc gaussien centré v(t).

On considère de plus que la mesure de la vitesse angulaire theta_dot_m est biaisée par un signal b(t) susceptible d’évoluer dans le temps (le drift).

A partir de ces 2 mesures theta_m et theta_dot_m on construit un filtre de Kalman permettant d’estimer le biais b(t). On pourra alors facilement corriger les valeurs en fonctions de l’estimation de ce biais.

Comme il n’est pas possible de modéliser la façon dont évolue le drift b(t) car celle-ci dépend de beaucoup de paramètres différents. On va considérer pour l’implémentation du Kalman que ce biais b(t) est constant. Mais ce qui nous donne en régime permanent un gain de Kalman nul car l’équation n’est pas bruitée. Ainsi, une fois le biais constant estimé, le filtre ne sera plus capable de détecter la dérive de ce biais. Ce qui est problématique.

Cependant on va ajouter à l’équation d’état un bruit fictif w(t) plus ou moins important qui va permettre de signaler au filtre de Kalman qu’il faut qu’il accorde à chaque itération plus de confiance dans les mesures et moins de confiance dans la modélisation, celle-ci étant incorrecte dans la mesure ou on a considéré un drift constant.

On obtient ainsi une estimation du biais b(t) du gyroscope qu’il est ensuite facile de soustraire au signal theta_dot_m mesuré par celui-ci.

C’est en particulier le filtre qui a été utilisé par Rich Chi Ooi dans sa thèse : Balancing of a Two-Wheeled Autonomous Robot

Des simulations Matlab/Octave sont à venir.

Sur un autre front, Clément à quant à lui commencé à regarder la théorie des algorithmes LQR mais nous attendons la présentation de vendredi pour nous y pencher de plus près.

RoseWheel : banc de tests et filtre de Kalman

Depuis ce week-end, nous avons avancé dans le projet sur deux fronts : d’un côté le banc de tests, de l’autre le filtre de Kalman.

En ce qui concerne le banc de tests, nous avons commencé à concevoir la partie logicielle du système. Clément et moi avons attaqué la partie « haut niveau », c’est-à-dire, les fonctions qui vont gérer la réalisation des tests et le calcul des statistiques d’intérêt ; en quelques lignes de Python (langage que Cédric et moi avons commencé à découvrir ce week-end), nous avons réussi à faire un script qui génère une série de valeurs de test aléatoires, simule les mesures correspondantes et calcule la moyenne et la variance de l’erreur. En y ajoutant encore quelques lignes, et à l’aide de matplotlib, Clément a réussi à afficher dynamiquement les résultats avec une belle interface graphique, dont voici un aperçu :

Écran du script du banc de tests. Les deux premières figures représentent les angles « thêta » et « phi », et la dernière, la vitesse angulaire dans l'axe des « thêta ». Les valeurs d'entrée sont dessinées en bleu, et les mesures simulées, en vert

En parallèle, Cédric a commencé à écrire, également en Python, une petite bibliothèque pour contrôler des servo-moteurs AX-12 (merci Samuel pour la recommandation) à travers le port série. Les prochains pas seront d’intégrer ce code dans l’application principale et implémenter des fonctions pour lire les valeurs des capteurs.

Sur l’autre front, Florian a beaucoup travaillé pour comprendre+implémenter le filtre de Kalman et pouvoir l’expliquer aux autres. Cependant, nous recherchons encore la meilleure manière d’intégrer à ce dispositif le filtre complémentaire (passe-bas pour l’accéléromètre + passe-haut pour le gyroscope).

En outre, nous avons réfléchi davantage sur le choix des capteurs, mais pour le gyroscope nous hésitons encore entre prendre l’IMU-3000 (3 axes) ou le MLX90609 (notre premier choix, avec un seul axe). La performance du projet « robot de equilibrio », qui utilise cette dernière puce, nous a beaucoup impressionné, et le fait que son drift soit faible (selon la datasheet) est assez intéressant ; pourtant, avoir un axe supplémentaire pourrait être utile pour l’asservissement dans les courbes, et permettrait le partage d’une intégration plus grande du travail avec Copterix.

Finalement, comme toute production électronique est censée être versionnée, nous avons tous eu droit à une vraie leçon pratique de Clément pour utiliser Git. En nous apprenant à sauvegarder nos avancées temporaires sur notre dépôt de projet, il a pu aussi préparer sa stratégie pédagogique pour la présentation de vendredi.