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.

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.

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.

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...

Tests, tests

J'ai pu faire quelques tests en boucle fermé complet.

Les interférences ne sont pas négligeables entre les deux module radio. La fréquence de rafraichissement du module envoyant les données d'attitude tombe de 9Hz à 6Hz environ. Cela semble aggravé par rapport aux tests d'interférence que j'avais fait. Probablement dû au fait que j'alimente l'émetteur radio directement en 9V alors que je l'alimentais en 5V pendant les tests. Je pense modifier le câblage pour revenir à 5V. Il faut peut-être également augmenter de base la fréquence des trames d'attitude.

J'ai pu vérifier le bon fonctionnement de la boucle fermée de contrôle de la barre. A cause des différentes corrections et normalisation, l'offset sur l'angle de barre n'est pas facilement réglable. Je pense qu'il faut que je rajoute une couche de conversion avant l'affichage des résultats.

Une difficulté dans l'utilisation du joystick était que la plupart du temps, je ne veux maîtriser que la direction du kite, sans modifier le réglage de la puissance. Cependant, ne désirant utiliser qu'un seul doigt pour la direction et pour le trim, je me retrouvais avec des mouvements non souhaités sur le border-choquer.
Afin de palier à ce problème, j'ai rajouté une plage morte sur l'axe avant-arrière du joystick. Plus de risque de changer le trim lorsque je vais à droite ou à gauche, mais toujours la possibilité de border ou choquer en allant à fond.

Je réfléchis également à me débarrasser purement et simplement de la boucle fermée sur le trim dans le contrôle avec le joystick du kite. Cela permettrait de simplifier le capteur de barre en supprimant le capteur de border-choquer.
Une autre alternative est de commander non pas une position avec le joystick mais un changement de position (un peu équivalent avec envoyer un ordre au moteur directement, mais avec les bénéfices d'une boucle fermée).
Des capteurs de fin de course, ou une mesure dans la tension des lignes (comme le sentirait un kiter) permettrait également au système d'avoir connaissance des butées.

Butées mécaniques

Voici la description de quelques évolutions sur la mécanique de la station sol.
Comme attendu, le système de butée ne donnait pas satisfaction. La butée rajoutée était fixée par une seul vis, et s'est mise à tourner de 90° sous l'action de la poulie, ne servant du coup plus à rien. Mais, oh surprise, le support placé sous la butée a suffi à bloquer la poulie, et à l'empêcher de faire des tours autour de la mèche. Cela marchait du côté où la ligne partait sous la mèche, mais pas de l'autre côté. Mais cela donnait une manière plus simple de faire une butée. J'ai donc rajouté une planchette de bois à quelques millimètres au dessus de la mèche. La deuxième poulie ne peut alors plus passer non plus. En plus d'être plus robuste et plus simple, cela m'a également permis de gagner deux précieux cm sur la course max des poulie.

L'ancienne butée, inutile car elle a tourné sous l'action de la poulie.

Nouvelle butée (petite planche sur le treuil en bas)

Et voici une petite vidéo montrant le test des butées
J'ai également revu la manière donc je rangeais les cartes électroniques dans le boîtier de dérivation. Je les avais jusqu'à présent glissées à la verticale, sur les diagonales du boîtier. Je les ai maintenant simplement mises à plat les unes au dessus des autres, ce qui permet de gagner de la place (pour faire rentrer le raspberry notamment).

Nouveau rangement des cartes (carte arduino par dessus la carte sabertooth)

Fin refonte connectique capteur

Aujourd'hui j'ai finalisé une refonte de la connectique des capteurs. Voici quelques photos des résultats.
J'ai pu commencer à réinstaller les capteurs sur le banc. Tests sur le banc prévu demain. Peut-être des tests à la plage samedi soir ou dimanche?

En bas l'arduino nano, au dessus de gauche à droite antenne, pile 9V, IMU

Antenne côté PC (avec une rallonge USB pour ne pas l’abîmer.

Capteurs de barre avec module RF

Voici quelques infos sur les composants et la technique (non-conventionnelle j'imagine...) utilisée.

Capteur embarqué

Numéro	Description	Fournisseur	Prix
1	IMU 10dof
2	Arduino Nano
3	Kit de télémétrie
4	Pile 9V
5	Clip pile 9V
6	Connecteur
7	Connecteur
8	Connecteur
9	Gaine

Interférences

Comme décrit dans l'article précédent, j'utilise maintenant deux kits en 433MHz.

http://www.drotek.fr/shop/fr/home/372-module-de-transmission-de-reception-rf-433mhz.html

http://www.drotek.fr/shop/fr/home/147-radio-telemetry-433-915-mhz.html


Initialement, je ne voulais utiliser que le premier pour renvoyer des informations depuis le cerf-volant, mais la portée s'est révélée insuffisante.
Le deuxième avait une portée plus importante.

Mais le premier me permettait de relier la station de contrôle au sol, aux capteurs de barre distants de quelques mètres seulement, et d'éviter des problèmes avec le câble de liaison. Par contre, je n'avais pas pensé au risque d'interférence a priori.

J'ai donc réalisé quelques tests a posteriori.

D'une part le kit de telemetrie envoi la trame mavlink ATTITUDE à une fréquence attendue de 10Hz. La validité de la trame reçue peut-être vérifiée grâce à un contrôle de redondance cyclique (CRC).
La fréquence de réception des trames est mesurée avec qgroundcontrol

D'autre part le module transmission, envoi des messages à une fréquence attendue de 20Hz. La validité de la trame reçue peut-être vérifiée grâce à une somme de contrôle (checksum).
La fréquence de réception des trames est mesurée avec un sketch arduino.

Il y a un loup dans la validité de la mesure qui n'est pas assurée (je mesure jusqu'à 50 messages reçues par seconde alors qu'il ne devrait y en avoir que 20)...

Mais dans tous les cas, j'ai pu observer des interférences.
La fréquence reçue des trames mavlink tombe de 8 à 7Hz lorsque l'autre module est branché.

La fréquence des trames reçues sur le kit de réception tombe de 50 à 20Hz.

Cela reste à mon avis satisfaisant.

Sans fil

Voici quelques jours que je travaille à une modification de l'architecture du projet afin de supprimer la liaison filaire entre les capteurs de barre, et la station au sol. Ce fil était en effet assez gênant, et un point de fragilité.
Le supprimer permettra d'avoir des mesures plus facile des ordres de barres d'une personne pilotant le kite manuellement et pouvant se déplacer.de quelques mètres autour de la station au sol.

Voici l'ancienne architecteture :


                    Joystick                                                  
                          |                                                            
                          |                                                            
                          v                                                           
GCS <-->Raspberry Pi <--> Arduino Uno-->Sabertooth-->Motors
                        ^                   ^              ^
                       /                     |                 \
                     /                       |                   \
              Telemetry    Line tension sensor  Bar sensor  
                    ^
                     :
                     :
               Telemetry
                    ^
                     |
          Arduino Nano
                    ^
                     |
                  IMU


Et voici la nouvelle architecture, où la liaison filaire entre les capteurs au niveau de la barre et de la ligne a été remplacé par une liaison sans fil.
Cela me fait remarquer que je n'ai pas fait de tests d'interférence...


                    Joystick                                                  
                          |                                                            
                          |                                                            
                          v                                                           
GCS <-->Raspberry Pi <--> Arduino Uno->Sabertooth-->Motors
                        ^                          ^
                        /                            |
                      /                        RF 433MHz
              Telemetry                        ^
                    ^                                :
                     :                          RF 433 MHz
                     :                                 ^
               Telemetry                         |
                    ^                       Arduino Nano
                     |                         ^                  ^
          Arduino Nano                 |                     \
                    ^             Line tension sensor  Bar sensors
                     |
                  IMU

Cela n'a (comme toujours) pas été aussi simple qu'envisagé.
Je voulais d'abord envoyer ce nouveau message sous forme de message mavlink afin d'essayer d'avoir une cohérence dans les messages, et de pouvoir utiliser des outils de log existants.

J'ai donc simplement essayer de faire un code émetteur envoyant un bit de vie avec mavlink, et un code récepteur le décodant et renvoyant une info sur le port série. Malheureusement pour une raison que j'ignore encore, je n'y suis pas arrivé. J'arrive bien à décoder le message venant de l'émetteur et à exécuter une action (allumer une led), mais impossible de faire des écritures sur le port série.
Le problème arrivait lors de l'appel de la fonction mavlink_parse_char.

Je suis finalement reparti vers quelques choses de plus simple, en modifiant les exemples de base d'envoi de trame pour envoyer des données numériques au lieu d'une chaîne de caractère.

J'ai ensuite réintégré le code permettant de venir lire le capteur d'angle de barre et le codeur linéaire.

J'ai eu des problèmes au niveau de la lecture de ce capteur. J'ai d'abord cru que c'était encore des problèmes de charge. Mais au final, je crois que les problèmes étaient liés à la lumière du soleil qui arrivait directement sur les capteurs des fourches optiques, perturbant le signal. Un peu problématique pour une utilisation prévue en extérieur, il va falloir réfléchir à utiliser un cache si mes conjectures sont bonnes.

Il me reste encore à vérifier l'intégration de la mesure de tension, à faire des tests d'interférence entre les deux émetteurs en 433MHz, à améliorer la connectique, puis à faire une intégration mécanique du tout, probablement avec de l'impression 3D ou de la découpe laser.

Perfectionnisme, KIS et RTFM

Hier, je parlais de la calibration du magnétomètre. Malheureusement à cause d'un problème de sauvegarde (que j'ai du mal à m'expliquer, peut-être dû à l'IDE arduino que je continue à utiliser...), j'ai perdu cette calibration qui avait été bien compliquée.
En réessayant de la faire, toujours quelque chose de bizarre au niveau du magnétomètre. J'ai finalement trouvé le problème... Le magnétomètre n'utilise pas les mêmes conventions pour les axes que l'accéléromètre et le gyroscope.
Les corrections que j'appliquais sur x, se retrouvaient sur y.
De plus, la calibration utilisant un modèle d’ellipsoïde demande énormément de points et donne souvent un résultat très décevant.

J'ai donc petit à petit trouvé une méthode de calibration beaucoup plus simple : j'observe les courbes des signaux (mx, my, mz) un par un (grâce aux courbes en temps réel dans QgroundControl ou grâce à Arduscillo). Je bouge le capteur de manière à maximiser la mesure sur l'axe, puis à la minimiser. Pour cela il faut orienter l'axe du capteur vers le nord ou vers le sud, mais presque à la verticale (le champ magnétique fait un angle de 70° avec l'horizontale). Je fais ensuite de petits mouvements pour essayer de trouver l'optimum.
Je calcule ensuite la différence entre le min et le max, et je divise par deux pour trouver le biais. Keep It Simple (KIS)!

J'étais très content de cette nouvelle méthode qui m'a permis d'avoir de très bons résultats (ainsi que d'autres modification pour recevoir les mesures du magnétomètre à un rythme plus élevé, et pour sélectionner automatiquement la bonne plage de mesure pour le capteur). Et puis en relisant les commentaires dans le fichier duquel j'étais parti, j'ai vu que cette méthode était celle conseillée... RTFM (Read The F****** Manual).

"        //  The gyros and accelerometers can in principle be calibrated in addition to any factory calibration but they are generally
        //  pretty accurate. You can check the accelerometer by making sure the reading is +1 g in the positive direction for each axis.
        //  The gyro should read zero for each axis when the sensor is at rest. Small or zero adjustment should be needed for these sensors.
        //  The magnetometer is a different thing. Most magnetometers will be sensitive to circuit currents, computers, and
        //  other both man-made and natural sources of magnetic field. The rough way to calibrate the magnetometer is to record
        //  the maximum and minimum readings (generally achieved at the North magnetic direction). The average of the sum divided by two
        //  should provide a pretty good calibration offset. Don't forget that for the MPU9150, the magnetometer x- and y-axes are switched
        //  compared to the gyro and accelerometer!
"

J'ai toujours des problèmes de robustesse, la carte arduino se bloquant après quelques minutes. Cela pourrait venir de la bibliothèque wire qui est utilisée pour la communication I2C et qui n'a pas de protection en cas de blocage (à voir avec le "repeated start", ça me dit quelque chose, mais impossible de retrouver).
Apparemment, nous sommes nombreux à avoir ces problèmes, openROV par exemple https://github.com/OpenROV/openrov-software-arduino/issues/16 

J'hésite à installer une autre bibliothèque I2C ou à modifier I2Cdevlib comme proposé ici http://www.i2cdevlib.com/forums/topic/218-arduino-wire-endtransmission-readbytes-not-working/ 

Edit : le problème semblait en fait venir de la liaison série entre l'arduino et le PC. En changeant de port USB sur le PC et en réduisant la fréquence d'envoi des trames à 10Hz, plus de problème. Mais j'ai aussi modifié i2cdev.cpp...

Calibration MPU9150

Edit 12/02/2015 : Mieux vaut se référer à l'article http://robokite.blogspot.fr/2015/02/perfectionnisme-kis-et-rtfm.html pour la calibration

Aujourd'hui j'ai calibré partiellement le capteur MPU9150 (simplement en rajoutant des offsets)
Cette calibration est indispensable pour le magnétomètre, sinon le cap donne vraiment n'importe quoi.

Pour cela, j'ai d'abord rajouté un script faisant la sauvegarde des données brutes (trames mavlink HIGHRES_IMU) dans des fichiers csv, puis utilisé le script magnetometer_calibration.m ayant déjà servi pour la calibration des données du téléphone mobile.

J'ai eu du mal à faire cette calibration car lorsque j'envoie des messages mavlink, l'arduino se bloque après un certain temps.
Le problème semble avoir disparu après avoir changé le format du temps en ms d'un long en un uint32_t (ce qui pour moi était un peu près équivalent...).

Après calibration, j'ai mesuré les variances du bruit au repos (directement grâce à l'outil plot de Qgroundcontrol) :
6e-7 roll
4e-5 pitch
2e-3 yaw

Cela correspond aux écarts types suivants:
0.05° en roulis
0.4 ° en pitch
2.5° en cap

Un peu décevant sur le cap.
Edit : mieux sur le cap depuis la correction du taux de rafraichissement.

Urbolienne

Voici le lien vers la campagne ulule d'un projet d'éolienne à axe vertical open hardware. Cela constitue un bon exemple de projet open-hardware dans une phase un peu plus avancée que robokite.


Eolienne urbaine - Urbolienne - AeroSeeD by aeroseed-sas

Jeu de la balle qui roule

Aujourd'hui à l'open atelier, j'ai pu tester la nouvelle version hardware.

Afin de rendre le test plus ludique, j'ai accroché une gouttière (carton plié en deux) au niveau des contrepoids du banc de test.

Le contrôle de la barre permet ainsi de modifier l'inclinaison de cette gouttière.
Gouttière dans laquelle j'ai rajouté une petite balle en mousse.

Le jeu est donc de contrôler la barre afin de déplacer la balle sans jamais la faire tomber de la gouttière.
On peut commencer en prenant directement la barre en pilotage manuel, puis en utilisant le joystick et en faisant tourner les moteurs, puis en utilisant le joystick avec la boucle fermée.

Et bientôt, j'espère rajouter une boucle fermée complète pour le contrôle de cette balle (grâce à de la reconnaissance dans le flux vidéo).

Au premier plan, la balle rose dans la gouttière au dessus des jerricans d'eau simulant la traction du cerf-volant, au deuxième plan, les moteurs et la barre, au dessus, les lignes faisant un aller retour dans des poulies accrochées au plafond

Modifications de la station de pilotage au sol.

J'avais déjà partiellement repris la partie mécanique de la station de pilotage au sol début Janvier et noté quelques problèmes.

J'ai finalement tout démonté et tout remonté, avec comme objectif principal de multiplier la course possible, et ce afin de pouvoir maximiser le couple de pilotage de base (qui peut facilement être réduit ensuite au profit d'une plus grande vitesse en déplaçant les points d'accroche sur la barre).

J'ai du sacrifier le manche de la visseuse/dé-visseuse à cause de la contrainte imposée par la taille de la planche support. J'ai également sacrifié la quasi-symétrie antérieure.

J'ai pu retester tout ça aujourd'hui et ça marche plutôt bien (à l'exception de la câle qui n'est pas assez solide).

Avant les modifications

Démontage complet

Nouveau placement des composants

Détail sur le noeud magique qui fait tenir les poulies. Solide et pratique pour pouvoir monter démonter à volonté pour tester différentes configurations.

Ajout de cales pour stopper les mouvements de poulies

Résultat final, en place sur le banc de test

Mavelous

Mavelous est une station de contrôle pour drone.

Mavelous a la particularité de fonctionner directement dans un navigateur web, ce qui est l'objectif pour robokite également.

Cela permet notamment de tester directement l'application sans rien installer !

Mavelous fonctionne en se basant sur le serveur python CherryPy et en utilisant le protocole mavlink.

Mavelous est développé sous licence MIT, ce qui va permettre de récupérer des morceaux, des exemples pour faire évoluer robokite plus rapidement sur la partie interface, station de contrôle.

Devis de poids

Lorsqu'on parle de faire voler des instruments, il faut penser à leurs poids.

Voici mes mesures sur l'ensemble IMU/RF embarqué.

Arduino nano : 6g
Antenne et kit radio : 13g
IMU : 3g (avec gros connecteur soudé...)
Cables de connexion : 2g x2
Cable usb : 11g
Mini breadboard : 17g
Batterie :  60g

Total : 114g

Ce poids est négligeable sur un kite de 2kg (aile de 6m2).

Cependant il peut-être intéressant d'embarquer le capteur même sur un petit cerf-volant pour faire des tests de robustesse en toute facilité (type luge enfant avec queue de 50g. Cet été j'avais accroché une gopro de 205g, mais ça ne volait pas très bien...). Ou pour tester avec un petit cerf-volant pilotable ou un Révolution à 4 fils.

Si je remplace cette batterie par des piles standards, il me faudra pour avoir minimum 6 volts :

• 97g pour 4 piles AA
• 47g pour 4 piles AAA
• 40g pour une pile 9v

Si je remplace la batterie par une pile 9V (40g), que je remplace la breadboard par des câbles de connexion je tombe à 72g.

Une vrai pochette étanche rajoutera 60g, un tupperwear 40 à 100g. un sac congélation 1g, ce qui sera mon choix pour les essais à terre...

Robokite démineur

J'ai bien rigolé en découvrant ce projet qui vise à utiliser des cerfs-volants dronifiés pour la détection des mines.

L'idée de base est bonne, mais le fait que les cerfs-volants soient confiés à des enfants, me fait penser à de l'humour noir, alors que le projet à l'air très sérieux... sur le plan du design tout au moins.

Voici en tout cas une nouvelle application pour un robo(cop)kite.

https://www.behance.net/gallery/8186809/Mine-sweeping-drone