jeudi 26 février 2015

Support téléphone portable

La dernière version du support pour monter un téléphone portable sur une ligne datait d'un an. Le prototype avait cassé au niveau d'une des oreilles permettant de maintenir le support sur la ligne.

J'ai redessiné une version légèrement renforcée, et avec quelques améliorations pour permettre un montage plus rapide. La version précédente avait été codée avec kokopelli dont l'usage n'est pas très répandu. J'ai recodé l'ensemble avec openscad pour une plus grande généricité. La géométrie en 3D a été projetée pour obtenir une géométrie 2D en DXF. Inkscape a permis de définir différents calques avant de lancer le plugin laserengraver pour générer le gcode.
La pièce a ensuite été découpée au laser dans du contreplaqué de 5mm d'épaisseur (j'ai profité d'une chute, ce qui m'a évité de refaire les réglages de focale et de vitesse de découpe).


Le support est à l'extérieur. A l'intérieur quatre attaches rapides (inspirées des tendeurs de tentes), ainsi que les deux barrettes servant à attacher la pochette étanche contenant le téléphone.


Quelques nœuds et quelques tours de papillon plus tard voici le résultat (accroché à un ligne verticale).
Je pensais au début fixer le système sur les deux lignes avant, mais il est possible de le fixer sur une seule ligne également (ce qui permet de le mettre sur un monofil également. L'oreille peut toujours être utilisée pour passer la deuxième ligne et empêché la rotation du téléphone autour de la ligne.
Cela permet aussi de fixer le support sur les deux lignes d'un cerf-volant pilotable, le support fixé sur une seule ligne et l'autre ligne glissant dans le support.

mercredi 25 février 2015

Tests à Pornichet

Hier à 13h30 j'avais rendez-vous avec Simon sur la plage de Pornichet.

Ciel bleu, grand soleil, mais vent un peu fort (15 à 27kt d'après les relevés) pour sortir la 6m2 en toute tranquillité. J'ai donc ressorti la petite aile de traction de mes 10 ans (2 lignes seulement).

 J'ai préparé le matos à l'arrière du camion (prêté par Maxime).
A défaut de raspberry, j'ai donc enlevé la veille du PC, branché les câbles, lancé les programmes, remis le PC dans sa house, puis dans un sac à dos d'où ne sortait que le câble vers la station sol et le câble vers le joystick.

Nous avons accroché la station au sol au niveau d'un poteau signalant la sortie des égouts au milieu de la plage (au niveau des immeubles en vague), ce qui a permis de gagner beaucoup de temps. Il manquait quelques points d'accroche sur la planche.

Le capteur embarqué (plus batterie, plus antenne, plus microcontrôleur) a été scotché sur l'aile.

J'ai d'abord testé le contrôle avec le joystick, mais cette fois encore je manquais de repère (visual ou haptique) pour savoir où j'étais rendu.
Du coup, je faisais partir le cerf-volant un coup à droite, puis un coup à gauche, en overshootant dans tous les sens, jusqu'au crash.

J'ai eu quelques fois les mèches qui se sont désolidarisés des mandrins à force d'atteindre les butées et d'utiliser le limiteur de couple. Après un bon coup de pince s'était mieux.
J'ai eu également une poulie qui s'est coincée entre la mèche et la butée.
Se servir des poulies comme cale n'est de toute manière pas une bonne idée, il faut que je rajoute quelque chose.

J'ai sorti deux fois le PC du sac, en pensant qu'un programme avait planté, mais non, en fait, c'est soit moi qui n'appuyait pas assez bien sur les boutons de changement de mode du joystick, soit que des messages étaient perdus (ce que j'ai observé quelques fois, c'est le risque en UDP, il faudrait passer en TCP, mais j'ai des problèmes de connexion...). Une difficulté similaire est que dans l'implémentation actuelle je détecte si un bouton est enfoncé, mais pas les fronts montants, ce qui n'est pas bon par exemple pour les réglages des gains (qu'il faudra également penser à saturer).

A force de tomber, le scotch tenant le capteur sur le cerf-volant s'est peu à peu décollé. Nous avons finalement attaché au niveau du boudin en plastique où le scotch tenait mieux que sur le tissu, et en profitant des scratchs tenant le boudin.
Pouah, faire ça sur la plage dans le sable volant, ce n'était pas au top.

Nous avons fait quelques tests en mode automatique, en espérant que cela serait mieux que moi. Mais pas mieux (et même pire disons le), cerf-volant allant même jusqu'à faire une quinzaine de loop avant que Simon ne l'intercepte (et s'amuse à défaire les tours...).

Pour finir, j'ai testé de piloter le cerf-volant directement en manuel (ce par quoi j'aurai du commencer). J'ai bien réussi à le maintenir un peu au zenith, mais pas facile avec les rafales. Je me rends bien compte que je pilote grâce à la sensation de la différence de tension dans les lignes lorsque la rafale arrive. Mais même avec cette information supplémentaire, je n'arrivais pas à contrôler le cerf-volant, probablement dû au boudin dégonflé.

En ramenant le matos au camion, je me suis rendu compte que la connexion avec le capteur embarqué ne fonctionnait plus (le moteur tournait toujours dans le même sens), ce qui expliquait peut-être les loopings en mode automatique.
EDIT : je viens de voir que l'antenne 433Mhz s'est détaché du connecteur SMA. Et sans antenne, la portée est nulle. Du coup, elle est perdue.

Malheureusement, j'avais oublié de lancer QgroundControl pour avoir des enregistrements, donc pas d'enregistrement autres que ma mémoire et quelques photos.

Plateforme au sol attachée à un poteau

Simon prêt à lancer l'aile en bord de fenêtre. On peut apercevoir les trois bouts de scotch tenant initialement l'électronique embarquée

 

Point d"avancement

J'ai pu commencer les modifications évoquées dans l'article précédent.
Le script python motorJoy.py retransmet maintenant les trames mavlink en UDP, ce qui permet de récupérer les messages (et par exemple d'avoir une visualisation avec des courbes) dans la plupart des stations de contrôle de drones.

J'ai essayé d'envoyer les trames mavlink de feedback de la barre directement à partir de l'arduino de la station sol, mais cela bloquait... Peut-être un problème lié au fait que ces trames ont été rajoutées il y a une quinzaine de jour dans mavlink. A creuser...

J'ai ajouté un réglage des gains directement via les boutons supérieurs de la manette/joystick. Lors des tests avec l'IMU, je trouvais le fonctionnement bizarre, le roulis était mal estimé. Je suis repassé en mode RAW, pour voir les trames avant fusion : la valeur correspondant à l'accélération selon y était toujours à 0. Cela semblait être un problème au niveau du capteur. Plus possible en tout cas de mesurer le roulis (à moins de faire un changement d'axe).
J'avais un capteur de rechange, mais pas là où j'étais parti en WE, ce qui me bloquait pour faire des tests...
Finalement, j'ai tout de même réessayer avec une version logicielle antérieure... et là miracle ça marchait. Le problème peut-être observé en sortie de la fonction MPU9150::getMotion9 qui récupère les accélérations, vitesses de giration et le champ magnétique sur les 3 axes du capteur.
En faisant les lectures en 3 temps, plus de problème, alors que le code semble être le même à l'intérieur. Mystérieux, mais maintenant ça remarche...

J'ai également coupé le script motorJoy.py en deux.
Le script joystick.py récupère les consignes donnés au joystick et les envoie dans une trame mavlink MANUAL_CONTROL qui sera lu par motorJoy.py
Cela devrait me permettre d'avoir le joystick déporté, et par exemple de faire le lancement du kite tout seul (en mettant mon téléphone en routeur wifi à mi-chemin)
J'ai également créé un script keyboard.py qui permet d'envoyer les consignes mais simplement à partir d'un clavier, ce qui devrait permettre à un plus grand nombre de développeurs de pouvoir faire des tests (j'ai en tête la simulation Software In The Loop derrière) sans disposer de matériel spécifique.

Finalement, pour tester tout ça, j'ai fait des tests d'endurance (nuit de lundi à mardi) avec le script motorJoy.py, joystick.py ainsi que QgroundControl pour faire les sauvegardes des messages, sur le PC, le programme GoundUnit.ino sur l'arduino de la station au sol, et le programme MPU9150_MS5611_IMU.ino
Et au bout de 5h, tout marchait toujours! A ma surprise, le fichier d'enregistrement ne faisait que 25Mo. A regarder plus en détail.

J'étais presque prêt pour des tests, plus qu'à installer le tout sur le raspberry pour éviter de sortir la PC sur la plage sous la pluie...

Malheureusement, j'avais oublié l'adaptateur pour la carte microSD, donc j'ai du charger le programme en ssh (et de toute manière, je devais installer scipy également). Et là j'avais l'erreur "Video system not initialized" que je n'avais pas sur mon PC. Peut-être lié à une mauvaise fermeture du programme au premier lancement (je me rappelle avoir eu un problème similaire lorsque j'essayais de faire un affichage graphique en mode console), mais là ce n'est pas là cas.

Donc prêt pour des essais mais une fois encore avec le PC.

vendredi 20 février 2015

Difficultés avec MAVLnk et Arduino

J'ai de nouveau essayé d'intégrer le décodage des trames mavlink sur un arduino.

Malheureusement, cela bloque toujours.
Il suffit que je fasse un Serial.read() pour que cela bloque lorsque j'envoie des messages mavlink vers l'arduino. J'ai essayé de limiter la fréquence d'envoi, de changer le baudrate, d'utiliser la librairie Fastserial, d'envoyer les messages depuis python, plutôt que depuis un autre arduino avec une liaison radio, mais rien n'y fait.

Le problème semble donc venir d'arduino qui se bloque, peut-être à cause d'un problème de buffer que je n'arrive pas à m'expliquer.

EDIT : peut-être une piste de (pseudo)solution en augmentant la taille logicielle du buffer dans ~/arduino-1.6.0/hardware/arduino/avr/cores/arduino/HardwareSerial.h

J'ai passé beaucoup de temps sur ce problème, en trouvant des traces sur internet d'autres ayant eu le problème mais sans que la solution n'apparaisse, ni même que le problème soit clairement identifié, ce qui est rageant.

J'ai donc décidé de contourner le problème, et de ne pas utiliser l'envoi des messages mavlink vers l'arduino, et de garder les trames NMEA, même si cela forme un tout un peu incohérent.

Afin de profiter des nombreux outils développés autour de Mavlink en attendant de trouver une vraie solution,  je fais donc faire en sorte d'avoir un programme python relais, qui recevra les messages mavlink venant de l'arduino au sol et de l'arduino embarqué, puis les transmettra vers une station de contrôle en UDP.
Ce programme recevra les commandes mavlink, et les convertira en trames NMEA.

Un peu compliqué mais mes tests montrent que ça devrait marcher.

Les messages que je souhaite utiliser sont :

HEARTBEAT comme bit de vie
ATTITUDE pour les donnée d'attitude issues du filtre embarqué
HIGHRES_IMU pour les données brutes dans les phases de calibration
MANUAL_CONTROL pour transmettre les ordres du joystick
ACTUATOR_CONTROL_TARGET (message standard ajouté récemment) pour les feedback actionneurs (vitesse et position moteur, position barre)
SET_ACTUATOR_CONTROL_TARGET (message standard ajouté récemment)
SCALED_PRESSURE pour la pression

Il me reste à choisir les messages pour :
-azimuth, elevation, ou position x,y,z
-vitesse du kite

Peut-être :
LOCAL_POSITION_NED
ou
VISUAL_POSITION_ESTIMATE et VISION_SPEED_ESTIMATE

Ainsi qu'à créer les messages pour la tension dans les lignes.

lundi 16 février 2015

Idée reçue n°1 : avoir plusieurs lignes complique les choses pour changer la longueur de lignes.

Je continue à lire différentes critiques d'un système ayant plusieurs lignes pour contrôler le kite.
Le système avec une seule ligne et une unité de pilotage sous le cerf-volant serait supérieur car plus simple, car il ne demande qu'un seul gros winch pour rouler/dérouler les lignes.

Si je pense que ce système devient intéressant pour un cerf-volant très très haut dans le ciel, je pense que ce n'est qu'un délire d'ingénieur pour des systèmes pratiques.

J'ai fait une petite animation pour montrer qu'il est également possible de contrôler le cerf-volant avec trois lignes et un seul moteur de winch.
Il suffit pour cela de changer les longueurs des lignes en les "pinçant". Il faut imaginer dans l'animation ci-dessous que les trois lignes en bas sont enroulées autour d'un même cylindre, et qu'il y a des petites poulies en bas, là où les lignes se courbent.


Thèses et colloborations

Voici 8 thèses parmi les 14 qui vont être lancés dans toute l'Europe (du Nord...) sur le sujet de la récupération de l'énergie éolienne aérienne.

Ku Leuven, June 30: large-eddy simulations of kite systems and kite farms in the atmospheric boundary layer,

Ampyx power, Den Haag, Control of launching and landing the PowerPlane on a launch platform
Embedded Model Predictive Control of a Tethered Aircraft for Airborne WindEnergy

Xsens, Enschede (Netherlands),February 28: Moving Horizon Estimation for 3D Motion Tracking

Freiburg, Multi-Scenario Design and Trajectory Optimization Methods and Adaptive and Fault-Tolerant Model Predictive Control and Moving Horizon Estimation

Chalmers University of Technology (Sweden), February 28: Integration of Airborne Wind Energy in the Power Grid

ETH, Zurich Modeling, January 2015: identification and control of kite dynamics for airborne wind power generation


TUM, Munich, March 01: Robust and Fault Tolerant Low Level Control of the Electrical Drive System of a Kite Wind Power Plant


De nombreuses collaborations ont lieu entre les différentes universités et les entreprises travaillant sur le sujet, notamment en Allemagne et aux Pays-Bas

Par exemple entre e-kite et TU Delft
http://www.e-kite.com/2015/02/02/delft-university-students-win-award/

Entreprise multikite

Multikite pourrait être un nouvel acteur français dans le domaine de l'Airborne Wind Energy.
A l'origine de Multikite, il y a Rogelio LOZANO, qui a réalisé une thèse sur l'étude d'un générateur à cerfs-volants de 2010 à 2014.


Pas plus d'information sur le net pour l'instant...