ELECINF344/381

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

Catégories

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.

Copterix : on passe entièrement sur la Gumstix !

Aujourd’hui, avec Bertrand, puis rejoins par Samuel et Axel, nous nous sommes concentrés sur la communication Gumstix/STM32. Nous avons enfin réussi à connecter comme nous le voulions les deux cartes.

Nous avons d’abord dû activer le GPIO 10, le pin correspondant n’étant pas configuré par défaut en tant que GPIO. Nous avons donc choisi de le configurer à chaque démarrage par l’intermédiaire d’un script shell, exécuté automatiquement, réalisant l’accès en mémoire nécessaire à la configuration, à l’aide de l’utilitaire memdev2.

Après avoir débugué notre carte à l’oscilloscope, et résolu un problème de soudure, nous avons donc enfin pu communiquer entre nos deux cartes. Les premiers essais ne furent malheureusement pas très fructueux : alors que les échanges de paquets se faisaient sans soucis entre PC et carte de TP STM32, avec le même protocole, nous avons à présent plus de 10% de perte de paquets (parfois 25%), et surtout, de longs moments (se décomptant en secondes) qui s’écoulent avec presqu’aucun paquet de valide. Les cartes sont donc inutilisables dans ces conditions.

Après analyse des données échangées, il semblerait que de nombreux octets ne sont pas reçus par la Gumstix, ceux-ci se perdant, à un niveau qu’il nous reste encore à déterminer. Exemple : sur des paquets qui devraient être de 21 octets, nous avons parfois observé plus de la moitié des octets perdus. Et ce, malgré le fait que nous avons redescendu la vitesse de l’UART à 115200 bps.

Les différentes pistes que nous avons à explorer demain, pour essayer de résoudre ce problème, sont les suivantes:

- Alexis nous a suggéré d’essayer de modifier le préscalaire de l’horloge concernée. Les quartzs n’étant pas forcément très fiables, il se peut que le souci vienne d’une vitesse de communication approximative, qu’on pourrait essayer de compenser de cette manière.
- Axel m’a suggéré de modifier légèrement le protocole. En effet, si on perd un octet, on perd au minimum deux paquets. Je rappelle le protocole :
On envoie un octet de start : 0xfe. Puis un octet identifiant le paquet : 0x4b. Ensuite on lit le nombre d’octets correspondant. Si on perd un octet, on va déborder sur le paquet suivant dans la lecture, et on ne le lira donc pas non plus. La solution proposée par Axel serait d’enregistrer la position de tout octet 0xfe croisé dans le contenu d’un paquet, et si le paquet est invalide, revenir à cette position pour « récupérer » ce paquet. Toutefois cela ne résoudra pas le problème, il s’agit juste de perdre moins de données à cause du protocole.

 

D’autre part, nous allons abandonner l’altimètre. Il semblerait que celui-ci soit trop peu précis, et trop complexe à utiliser. Nous allons donc plutôt faire des tests avec un détecteur à ultrasons ou un sharp, pour voir si nous obtenons quelque chose de plus satisfaisant.

Nous avons également été chercher l’hélicoptère, afin de pouvoir tester les commandes des moteurs très bientôt.

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.

Copterix : PSSC

Voici nos PSSC avec la date et le responsable :

  • Récupération des données des capteurs du STM32 – Date : 13/04Responsable : Samuel
  • Filtrage de Kalman fonctionnel sur la Gumstix – Date : 13/04 – Responsable : Axel
  • Communication entre la Gumstix et le stm32 avec un protocole permettant de récupérer l’ensemble des valeurs des capteurs et d’envoyer les consignes moteurs – Date : 13/04 – Responsable : Loïc
  • Piloter chaque moteur à la vitesse voulue (i2c) – Date : 15/04 – Responsable : Bertrand
  • Lucas et Kanade opérationnel sur la Gumstix – Date : 20/04 – Responsable : Samuel
  • Contrôler les moteurs en fonction des données des capteurs pour atteindre un vol stationnaire – Date : 20/04 – Responsable : Loïc
  • Gestion des déplacements – Date : 25/04 – Responsable : Bertrand
  • Contrôle avec une télécommande – Date : 25/04 – Responsable : Axel

Copterix : PSSC

Voici la mise à jour de nos PSSC

  • Réalisation d’une carte d’extension fonctionnelle (design PCB)  – Fait
  • Récupérer la vitesse de translation grâce à la caméra  – Fait avec openCV
  • Communication Wifi avec le Copterix  – Statut : Ok en ad-hoc reste à tester avec un routeur wi-fi sécurisé – Date : 08/04
  • Récupération des données des capteurs du STM32 - Statut  : En cours, non testé – Date : 10/04
  • Filtrage de Kalman fonctionnel – Statut : Ok avec l’IMU, modulo un léger bruit,  reste à le tester sur notre PCB – Date : 13/04
  • Piloter chaque moteur à la vitesse voulue (i2c) – Statut : Non commencé – Date : 13/04
  • Communication entre la gumstix et le stm32 avec un protocole permettant de récupérer l’ensemble des valeurs des capteurs et d’envoyer les consignes moteurs – Statut : En cours de debug – Date : 13/04
  • Contrôler les moteurs en fonction des données des capteurs pour atteindre un vol stationnaire – Statut : Non commencé – Date : 20/04
  • Gestion des déplacements - Statut : Non commencé – Date : 25/04
  • Contrôle avec une télécommande – Statut : Non commencé – Date : 25/04

Copterix : ubuntu sur gumstix && communication STM32/Gumstix

Hier et aujourd’hui, j’ai -comme Casper- fait passer Ubuntu d’ext3 à nilfs2 pour des raisons de performances et pour augmenter la durée de vie de la microSD.

Les noyaux fournis par Gumstix ne le supportant pas, j’ai recompilé le kernel (patché pour supporter la Camera), généré un uInitrd et reconfiguré le bootloader.

En parallèle, j’ai terminé un script faisant un debootstrap adapté à nos besoins, avec les paquets et les fichiers de configurations idoines. Il permet ensuite de formater correctement la microSD et d’y installer notre ubuntu fraichement créé.

 

Loïc continue de travailler sur la communication Gumstix/STM32. Pour des raisons de vitesse de transfert (avoir au moins 1000 paquets/s, un paquet contenant l’ensemble des données des capteurs), il a poussé l’UART à 1 Mhz et est en train de faire des testbenchs pour mesurer le débit utile.

Copterix : finalisation du filtre de Kalman

Alors, comme nous l’avons dit hier, cette journée a été dédiée aux tests du FQA et du filtre de Kalman sur une IMU. On récupère les données brutes des capteurs (3 gyroscopes, 3 accéléromètres et 3 magnétomètres) par un script python. Le Kalman qui sera implémenté sur la Gumstix est en C++. Il a donc fallu dans un premier temps faire communiquer le script python et le programme C++ afin d’acheminer les données des capteurs vers notre Kalman. Nous avons pour cela utilisé ZeroMQ avec une architecture Publisher/Subscriber.

Une fois la communication fonctionnelle, nous avons pu commencer à tester notre FQA et notre Kalman. Au début, nous avions pas mal de problèmes au niveau de l’orientation de nos axes. Mais après avoir passé pas mal de temps à étudier les sorties des capteurs pour comprendre selon quels axes ils étaient positionnés, nous avons obtenu des résultats plutôt satisfaisants :

Dans la première vidéo , nous n’utilisons pas le filtre de Kalman (juste le FQA) alors que dans la seconde, le filtre de Kalman est activé. L’utilisation du filtre permet d’éliminer pas mal de bruit. Il reste tout de même quelques petits détails à régler car il y a quelques indéterminations qui chamboulent un petit peu le filtre.

Nous avons en outre reçu notre PCB :

La journée de demain sera consacrée à établir la communication avec notre nouvelle carte !

Copterix : communications

Depuis mercredi, je me suis occupé d’implémenter la communication via UART entre STM32 et Linux.

Comme nous ne disposions ni de la gumstix parfaitement fonctionnelle, ni du STM32, j’ai commencé à communiquer entre ma carte de TP et mon ordinateur, via un cable micromatch 4 / USB.

J’ai commencé par réaliser la partie du code du STM32, sous FreeRTOS. Je me suis alors rendu compte que contrairement à ce que je pensais, le protocole XModem n’était pas vraiment adapté à ce que je voulais, mais qu’il y avait dans celui-ci de bonnes idées, il a donc constitué un très bon départ pour un protocole maison. Voici le protocole que j’ai finalement adopté :

Les données à envoyer sont regroupées au sein de structures C (une pour l’ensemble des données des capteurs, une pour l’ensemble des commandes des moteurs). On envoie les données structures par structures, de cette manière :
On commence par envoyer un octet qui caractérise le paquet (dans notre cas, j’ai choisi 0×03 si c’est les données du capteur, 0×01 pour les commandes moteur, 0×02 pour les commandes RF). Ensuite on envoie la structure, octet par octet, sachant que l’émetteur et le receveur connaissent la structure, donc sa taille, et donc le nombre d’octet attendu. Enfin, on envoie un checksum, constitué de la somme de tous les octets modulo 256. Le récepteur va ensuite vérifier le paquet reçu avec le checksum, et l’utiliser s’il est correct, l’ignorer sinon : il n’y a pas de renvoi des paquets erroné, car cela me semble inutile, vu l’aspect temps réel des paquets échangés.

Du coup, on peut se passer d’acquittement, ce qui nous permet de fonctionner en full duplex : on devrait pouvoir envoyer les données des capteurs et recevoir les données des moteurs en même temps.

Hier donc, j’ai codé la partie STM32 (sauf les commandes RF, il faudra que je les rajoute après), puis j’ai vérifié, en dialoguant avec le PC via des scripts Python, que cette partie fonctionnait correctement.

Aujourd’hui, je me suis occupé de la partie côté Linux, en C : j’ai implémenté le protocole de réception, pour stocker les données reçues dans la structure correspondante. Ensuite, j’ai mis en place une communication 0MQ basée sur le système de Publisher/Suscriber : le module de réception publie ainsi chaque update. J’ai également créé un programme qui souscrit à ces updates, et les affiches : ses fonctions pourront être intégrées au filtre de Kalman, pour qu’il puisse souscrire aux updates.

Il me reste donc à implémenter le module d’émission côté Linux, à ajouter les paquets provenant du module RF, et je pense qu’ensuite j’aurais intérêt à faire quelques simulations pour estimer le taux d’erreurs, ainsi que le taux d’erreurs non détectées.

 

Copterix : Gumstix

Aujourd’hui j’ai remplacé la Gumstix TIDE par la FE, ce qui a permis après quelques configurations d’avoir le Wi-Fi sur notre carte. Celle-ci crée un réseau ad-hoc qui sera très utile pour tester, quand nous aurons notre pcb, Kalman avec notre IMU et plus tard pour ajuster « au vol » les coefficients du PID dès que l’on mettra nos cartes sur l’hélicoptère.