ELECINF344/381

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

Catégories

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

Copterix : mécanique & oscilloscope

PID

Ce week-end, j’ai complètement modifié le PID. Avant, je mettais à jour à chaque itération les commandes moteurs. Maintenant, j’applique un delta aux commandes d’équilibre (à déterminer en pratique). Un testbench minimaliste montre que ce PID asservit correctement les trois angles (lacet, tangage et roulis) ainsi que l’altitude.

Après des tests sur l’hélico, il restera en l’englober dans un PID asservissant X et Y.

Capteurs

Samuel a terminé de récupérer les données des capteurs de notre PCB, Alexis ayant soudé les composants manquants. Il reste cependant à améliorer le calcul de l’altitude. Il faut en effet récupérer une dizaine de valeur sur l’altimètre pour calculer la pression. Pour l’instant la précision ne nous permet pas d’avoir un Δz exploitable.

Communication PCB/Gumstix

Loïc a terminé ses programmes pour communiquer entre PC et carte de TP que l’on doit porter sur Gumstix/PCB.

Nous avons donc branché le PCB sur la Gumstix. Les deux cartes sont connectées par une barrette 40 broches. On se sert de cinq d’entre elles: deux pour l’uart, une pour transmettre le VCC gumstix et deux en tant que GPIO. Il faudra écrire des modules pour la Gumstix pour contrôler les GPIO, c’est-à-dire l’enable du level-shifter (nécessaire, car la Gumstix est en 1.8V et notre PCB en 3.3V) et le reset du PCB.

Un debug à l’oscilloscope nous a montré que l’uart fonctionne en partie : on transmet de la Gumstix à notre PCB, mais cela ne fonctionne pas dans l’autre sens. En effet, les masses des deux cartes n’étant pas reliées, la différence de potentiel entre GND du PCB et VCC de la Gumstix est quasi nulle. Les sorties du level-shifter côté Gumstix sont ainsi inexploitables. Il faudra donc patcher la carte pour relier les deux masses.

RoseWheel : Avancées de ce lundi

Joao et moi avons passé la journée de Lundi à chercher ce qui ne fonctionnait pas dans le modèle utilisé dans la simulation. En effet, même avec une inclinaison initiale de 5° et avec une tension de commande des moteurs à sa valeur maximale (24V) sans asservissement, le système n’arrivait pas à redresser le RoseWheel pour le ramener à sa position d’équilibre de 0° et il chutait.

Nous avons donc revu tour à tour tous les paramètres de la simulation (Voir ici un récapitulatif des paramètres que nous utilisons : parameters), que nous avons fait varier, nous avons ainsi pu observer leur influence sur l’évolution du système. Il s’est avéré que le seul paramètre critique était la constante de couple des moteurs.  A peu près tous les autres n’ayant qu’un effet sur le temps de chute. Nous avons mesuré rapidement cette constante de couple directement sur le moteur. Nous avons ainsi pu vérifier que la valeur qui était fournie dans la datasheet du moteur correspondait bien avec celle mesurée.

Il s’est finalement avéré que le problème venait des équations que nous utilisions. Nous avons repris toutes les équations et nous nous sommes rendu compte qu’il manquait un facteur 2 au niveau de celles décrivant l’effet de la commande sur les moteurs. Avec ce facteur 2 en plus, tout fonctionne parfaitement et le système est bien asservi avec une tension de commande maximale de 24V.

Nous consacrons donc cette journée de Mardi à peaufiner la simulation, notamment à choisir un set de coefficients optimum pour le LQR. De plus, jusqu’à présent nous utilisions des équations « complètes » pour le filtre de Kalman, c’est à dire que nous prenions pour hypothèse que nous avions accès à la mesure de tous les paramètres du système. Ce qui ne sera pas le cas dans la réalité. Nous allons ainsi choisir ce matin la forme définitive pour le filtre de Kalman et tester en simulation ces performances.

Cet après-midi, nous implémenterons en C cette forme du filtre de Kalman, que nous adapterons au Testbench que Drix a quasiment terminé hier et nous pourrons ainsi tester en réel le filtrage.

Clément a continué d’avancer sur l’implémentation de drivers génériques pour les deux cartes. Nous vous donnerons très bientôt plus de nouvelles à ce propos.

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