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: motors control, 1st test

Sensors and effectors

For now, we configured all sensors and effectors:

  • The Sharp, the distance sensor, works in 1-5m range and we get values with 3cm precision
  • Inertial Measurement Unit (gyros, accelerometers and magnetometers return correct values)
  • Radio Frequency (remote control, see video)
  • Motors (see video)

Here is a small video where we directly control motors’ speed with remote control:

Communication

We now have a reliable communication between our PCB and the Gumstix, thanks to Samuel Tardieu’s help.
We mostly use ZeroMQ to share data between our processes and even between our computers !

Kalman

Kalman is quite smoothly, works as well on PC as on Gumstix, and we are now optimizing each operation. The actual filter is fast enough for real-time execution (we spend a lot more time to wait after data than to actually process it), but we want the filter to use less processor working time in order to execute other heavy tasks, like Lucas and Kanade (video tracking algorithm).
We do now have a way to get by Wifi only the Kalman’s results in order to display them on a PC using OpenGL as you could have seen it on our previous videos.

Next step

We are now up to test for the first time real servomechanism PID on our Copterix !

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.

MB Led : Avancées du début des vacances.

Actuellement, je m’occupe de fusionner mon code d’algorithmie avec le code de Cédric concernant l’IrDA. Nous avions quelques différences sur des fonctions d’envoi et de réception de données. J’ai du réécrire certaines fonctions pour que cela marche. Désormais, nous testons les résultats en utilisant la sonde JTAG qui nous pose certains problèmes (hier, on a passé pas mal de temps à ressouder des fils qui s’étaient déssoudés).

L’IrDA est désormais fonctionnel avec des envois à haute vitesse. Cédric a utilisé un ordonnanceur pour gérer cela. En attendant, j’ai réfléchi à une façon de détecter qu’un bloc a tourné. Les tests avec FreeRTOS et zmq sont concluants et il faut juste l’appliquer au code avec IrDA.

Hier, Alexis avec l’aide de Benjamin a soudé un bon nombre des MBLeds. Nous espérons les avoir bientôt pour que Benjamin puisse tester son code sur le driver LED. Benjamin a aussi réfléchi à deux jeux que nous voudrions implanter : un morpion et un snake. Il attend que la fusion soit finie pour tester cela.

MB Led: Des séparations difficiles…

L’implémentation de l’algorithme est désormais presque fini. Tant que personne ne « quitte » le réseau, l’algorithme permet à tout le monde de savoir qui est dans le réseau et où il est; cela passe par une phase d’identification, une phase d’élection de leader, un positionnement des modules et la propagation de l’information au réseau entier.

Le problème principal est de bien faire cela dans l’ordre et que les informations données soient fiables et bien retransmises.

Lorsqu’un des modules quitte le réseau, celui qui s’en aperçoit propage l’information qu’il faut tout recommencer.
Pour remarquer qu’un module a disparu, la technique est simple : on envoie un PING et on laisse x ms à l’autre module pour répondre par un PONG. Si cela n’est pas fait, le module a sûrement disparu.
Lors de départ de module, il faut donc envoyer toutes les informations nécessaires sans oublier d’acquitter rapidement les PING, c’est pourquoi j’ai préféré utiliser une tache freeRTOS de très haute importance pour cela. Cependant, lors d’une simulation avec 9 modules, l’élection de leader se fait partiellement. De plus, l’acquittement ne se fait pas forcément et donc on repart à rien, ce qui peut conduire à un autre acquittement raté, etc.

 

Grâce à terminator, je peux suivre en temps réel les messages échangés entre les modules via zmq. (Les ping/pong ne sont pas montrés et il y a certains commentaires pour m’aider dans le débug.)

 

MB Led: Dialogues en zMQ

Ces derniers temps, j’ai principalement implémenté notre algorithme en C, tournant sous FreeRTOS sur un PC classique.

En effet,  j’ai préféré utiliser directement les possibilitées de FreeRTOS (tâches, sémaphores, etc.) plutôt que de coder en C classique puis de modifier tout cela lorsque j’aurai voulu mettre cela sur un module MBLed (ou GLiP).Cependant, j’ai eu beaucoup de difficultés à paramétrer FreeRTOS pour que cela marche sur un ordinateur. J’ai dû me plonger dans la documentation pour finalement réussir à faire un Makefile qui marche vendredi soir.

Pour simuler les échanges entre modules, nous utilisons zéroMQ en mode PUB/SUB. Chaque module que l’on lance intéragit avec le script en python grâce à deux sockets : avec l’un, les modules publient leurs infos et le script les récupère; avec l’autre, le script python publie les informations (qu’il a modifié pour que la partie « Origine » du message soit devenue une partie « Destination ») et chaque module récupère uniquement les informations le concernant.
Pour l’implémentation de l’algorithme à proprement dit, je tente de reprendre le code en python pour le passer en C bien qu’il soit assez difficile de faire cela. J’avais beaucoup utilisé l’orienté objet dans le script et le C ne gère pas cela. Toutefois l’implémentation se fait assez vite et j’espère avoir fini cela pour jeudi ou vendredi.