ELECINF344/381

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

Catégories

Copterix : PID on the way

Today, our purpose was also to find the good values for the PID. At the beginning, the copter was very instable and oscillating. But after having changed the structure of the PID (before we had 6 values to configure, now we have only 3 coefficients), the impact of each coefficients was more easily to understand. The result seems good, but it will be better when we will have the camera and the Sharp (distance sensor). Here is a little video illustrating our breakthrough:

 

 

 

 

Copterix: First flight

Today, I finalized the emission of the commands for the motors, from the Gumstix to the STM32 and their reception (check the validity of the packet and if it’s valid, update the commands sent to the motors).

Then, with Samuel, we added 0MQ exchanges on the Gumstix between Kalman and the PID and between the PID and the UART.

On the Gumstix, the program that handles the UART has two threads. One receives data from the sensors from the STM32 and sends it -thanks to 0MQ- to the program computing Kalman. The other one, receives the commands of the motors from the PID and sends them to the STM32.

 

Copterix IHM

Copterix's IHM

We also attached the PCBs on the copter:

PCB's on copter

We configured Kalman with the new axes and the offset of roll and pitch angles.

 

Finally, we all tested the PID. The algorithm seems okay, however, we’ll have to set each coefficient properly.

We’re trying  to control roll and pitch angles with a low thrust (in order to prevent any accident). Then, we’ll add a control on Z thanks to the Sharp sensor.

Copterix : communication between Gumstix and STM32

Today, we have resolved the problem concerning the communication between the Gumstix and the STM32. Our initialization of the serial port wasn’t good because we didn’t set raw mode. Now we have a good communication at 1MHz between the two boards and we’re able to send around 300 packets per second (21 bytes per packet) . We are able to transmit all the data from sensors to the Gumstix with a precise protocol previously explained. We are also able to receive data from the Gumstix in order to command the motors later.

For the time being, we gather information from gyroscopes, accelerometers and magnetometers. These sensors are enough to use the Kalman filter.  Besides, this filter has a little problem when we are doing brutal movements. A first idea to resolve this problem is to optimize our filter to be faster and to take into account big sensors variations.
After having optimized the Kalman filter (for now, we just split the 3D render process and the Kalman process, and we use ZMQ to exchange data), it became more efficient.

Tomorrow, we will add a Sharp to measure our altitude because we don’t use a pressure sensor anymore. We will also begin the communication with the motors. We will have to parameter the Kalman filter in good conditions, and finally optimize it deeply before putting it on Gumstix.

Rosewheel restructure son planning

Aujourd’hui nous avons pris le temps de réétudier un peu notre planning. Les travaux pratiques de l’UE ont, pour les premières semaines, un peu empiété sur le temps que nous voulions consacrer au projet et quelques modifications s’imposent. Nous pensons néanmoins être toujours dans les temps par rapport à nos objectifs finaux. Notre planning prévisionnel était :

  1. Étude : Kalman, composants, banc de test
  2. Conception PCB : logique, capteurs
  3. Contrôle en vitesse non asservi
  4. Fusion de capteurs & asservissement
  5. Tenir debout, tourner, s’arrêter
  6. Détection d’obstacles
  7. Conception & implémentation contrôle brushless
  8. Conception de l’application Android & video
  9. Soutenance finale

L’étude du filtre de Kalman en première semaine a été concluante. Nous disposons de tous les éléments théoriques pour concevoir le filtre optimal pour notre application. Afin d’assurer un bon équilibre entre robustesse du filtre et complexité des calculs, différentes approches, complémentaires, sont mises en place. Tout d’abord, afin d’assurer la robustesse du filtre aux erreurs numériques susceptibles de se produire du fait de l’utilisation de calculs en virgule fixe, nous comptons utiliser l’algorithme du square root filtering. Ensuite, nous séparerons bien les capteurs entrant dans l’équation d’évolution du système et les capteurs n’ayant un rôle que de « mesure », ceci afin d’alléger la taille des matrices utilisées dans le filtre. Enfin, nous nous placerons dans la situation, fictive, où RoseWheel est toujours immobile. Le mouvement de ce dernier sera vu comme un bruit que nous intégrerons dans les équations et qui, si le choix des différents paramètres est judicieux, nous permettra là aussi d’obtenir des résultats satisfaisant tout en garantissant la simplicité des calculs.

Une étude plus approfondie de la dynamique du système nous a également permis de définir plus précisément nos différentes unités de traitement : filtre Kalman pour supprimer le bruit des capteurs, LQR pour asservissement en inclinaison, LQR pour asservissement en vitesse des moteurs brushless. Il nous manque toujours certaines informations pour pouvoir établir des modèles notamment des informations sur les divers éléments mécaniques et les capteurs. Nous n’avons pas encore finalisé le choix des capteurs et autres composants que nous allons utiliser. Nous avons collecté suffisamment d’informations sur ces derniers mais nous devons maintenant trancher en fonction de plusieurs contraintes : coût, précision, bruit de mesure, disponibilité, délais de livraison, possibilités de collaboration… Par exemple, nous pourrions partager les efforts avec Copterix pour les accéléromètre (MMA7660FCR1), gyroscope (IMU-3000) et capteur sharp (GP2Y0D02YK0F) de façon à factoriser les développements. Mais nous pourrions aussi utiliser des composants plus appropriés comme ce qui a été proposé à la soutenance initiale (nous n’avons par exemple pas besoin de 3 axes pour le gyroscope). Nous allons affiner notre sélection durant les prochains jours pour converger vers un choix final au plus tard samedi prochain (justifications à l’appui) de façon à pouvoir finir les PCB logique et capteurs pour dimanche soir comme prévu..

La première semaine devait également faire l’objet d’une étude sur la réalisabilité d’un banc de tests pour nos capteurs. Suite à plusieurs fausses pistes nous avons finalement trouvé où nous procurer des servos et du bois/plexi. L’implémentation, assez triviale, a bien avancé. La réalisation du banc de test reste tout de même moins prioritaire que l’avancée sur les capteurs et le filtre de Kalman : il est inutile de tester quelque chose que l’on a pas encore conçu. Nous avons donc décidé de reporter la semaine 3, soit la semaine prochaine. Nous devrions avoir un prototype viable en fin de semaine.

Enfin nous avons pris un peu de temps pour développer un simulateur simple de la physique de notre système (pour l’instant tel que décrit dans la thèse de Rich Chi Ooi) à l’aide d’Octave. Cela nous permettra de faire des premiers tests sur le filtre de Kalman et le (les) LQR assez rapidement.

Copterix : Changements post présentation

Suite à la présentation, nous avons décidé de faire une carte d’extension pour la gumstix sans STM32 et de reporter l’ensemble des calculs (Kalman et asservissement) sur le CortexA8.

Samuel et moi avons aussi commencé à réfléchir sur l’architecture de cette carte (partie IMU). On aimerait mettre :

  • Un gyroscope 3 axes IMU-3000 (I2C)
  • Un accéléromètre 3 axes LIS302DLH (I2C, SPI)
  • 1 altimètre
  • On hésite entre un sharp (IR) et un capteur ultrason pour l’altitude par rapport au sol

RoseWheel prend la route !

Aujourd’hui nous avons commencé à élaborer le planning du projet.

Un bug tracker a été rapidement mis en place (Redmine) et va nous permettre de :

  • Lister nos tâches et en garder des traces
  • Faire du suivi de bugs et d’ajout de fonctionnalité
  • Nous assigner des tâches les uns les autres
  • Générer des diagrammes de Gantt
  • Partager des fichiers non versionnés (pdf, images, …)

Nous avons pu éclaircir quelques points sur lesquels nous nous posions des questions :

- Il est nécessaire de charger le Rosewheel avec des objets ayant un poids inférieur à 90kg et dont le centre de gravité est approximativement le même que celui d’un être humain.

- Il faut utiliser à la fois un gyroscope et un accelerometre pour nous permettre de mesurer l’angle d’inclinaison du manche du RoseWheel car on a :

  • gyro : integrale(biais + theta_point) = derive linéaire + theta
  • accelero : theta + bruit

ces deux mesures sont en fait complémentaires,

  • gyro = theta + composantes basses fréquences
  • accelero = theta + composantes hautes fréquences

donc fusion des capteurs = filtrage passe-bas + filtrage passe haut.

- Peut-être utiliser en plus un Kalman pour rendre le signal issu de la fusion des capteurs d’angle encore plus propre.

-  Pour la gestion de la sécurité de RW (Arret si detection d’obstacle), nous avons pensé à utiliser un système de sonars et/ou détecteurs infrarouges (Sharps). L’idée serait d’en avoir plusieurs  à l’avant du robot : certains pointant horizontalement pour détecter des murs, d’autres pointant vers le sol pour détecter un changement de pente ou un objet au sol. Détecter un changement de pente  pourrait permettre d’adapter l’allure : si descente on ralentit, si montée on accelère. Par ailleurs on pourrait évetuellement détecter un trou et s’arreter pour ne pas tomber dedans. Nous n’avons pas encore poussé plus loin nos investigations en terme de chiffrage et de choix  de composants.

- Il faut utiliser comme processeur principal un processeur capable de traiter à la fois les calculs des différents filtres (Kalman,passe-haut et passe-bas) pour les calculs de l’angle theta, de traiter les calculs issus des capteurs de distance (Sonars, sharps), de traiter les données issus des encodeurs. De calculer les prochains nombre de tours à appliquer aux moteurs.

- Nous allons remplacer les moteurs CC d’origine par des moteurs Brushless, il sera donc nécessaire d’utiliser un processeur sur la carte de puissance afin de gérer la commande de ceux-ci.