Tests mavlink

Afin de vérifier la qualité de la communication radio, j'ai essayé d'utiliser mavlink.

Voici l'idée : un programme tourne sur la carte arduino et envoie un bit de vie sur le port série.
Ce message est transmis en radio vers mon pc équipé de la carte RF sol. Je vérifie la validité des messages reçus.

J'ai essayé de suivre http://qgroundcontrol.org/dev/mavlink_arduino_integration_tutorial

Malheureusement, cette documentation n'est pas à jour, et des liens sont morts.

D'autres que moi ont déjà eu les mêmes problèmes, et j'ai essayé de suivre leurs conseils

http://diydrones.com/forum/topics/beginning-tests-using-mavlink

Après avoir appliqué ces conseils, j'avais ensuite de nouvelles erreurs à la compilation :
avr-gcc: error: unrecognized command line option ‘-assembler-with-cpp’

Cela vient de la nouvelle version du compilateur (dans ubuntu 14.04) qui n'est plus compatible avec les anciennes versions d'arduino.
Le problème a été résolu dans la version de développement d'arduino.

Malheureusement, d'autres erreurs arrivaient de nouveau.

J'ai finalement simplement enlevé la dépendence à FastSerial qui n'est pas indispensable.
J'ai également mis le chemin en dur vers mavlink.h

J'ai alors pu compiler, et voir passer les messages (codés) du bit de vie dans le "serialmonitor".

Afin de vérifier l'intégrité de ces messages, j'ai installé GGroundControlStation (installation très simple à partir des binaires).

QGroundControl a automatiquement détecté les messages arrivant sur le port série. Malheureusement la version du protocole Mavlink, ne correspondait pas, un message d'erreur fut affiché.

Finalement, j'ai repris le script de test et téléchargé le code source plus récent généré en C

L'include suivant était suffisant pour utiliser la bibliothèque.
#include "/home/bat/sketchbook/libraries/mavlink/ardupilotmega/mavlink.h"

J'arrivais ensuite bien à voir les messages dans QGroundControl (il faut pour cela aller dans Communication, ajouter la liaison série si elle n'est pas connectée automatiquement, et ouvrir la connexion).

Malheureusement, les messages s'arrêtaient systématiquement au bout d'un certain temps. Mais cette fois c'était ma faute, car je stockais le temps en ms dans un int (allant jusqu'à 32 767 ). Au bout de 32s, le programme se retrouvait donc bloqué...

J'ai également ajouté des messages fictifs d'attitude et de position. J'ai ainsi pu tester les outils de logs et de graphique en temps réels, ainsi que les possibilités de rejeu.

Le code pour l'arduino est là.

Attitude et trajectoire simulées et envoyées à partir d'une carte arduino connectée en série

Graphiques temps réels et inspecteur mavlink.

Open atelier

Jeudi c'est open-atelier à PlateformeC.

Et aujourd'hui, c'est déjà noël !

Je teste un nouveau kit de télécommunication radio, suite à l'essai d'un kit plus basique, mais dont les performances s'étaient révélées limites (mais pas testé en pleine puissance d'émission).
Cette paire doit permettre d'atteindre une portée de 1km, pour un prix de 47€ (contre 5 euros pour le kit précédent), et une utilisation très simple. Il s'agit d'un clone d'une autre carte dont la documentation est ici.

Le kit permet de remplacer le câble série utilisé avec un arduino.
D'un côté,  il y a un connecteur USB.
De l'autre côté, il y a 4 fils seulement, masse, 5v, RX et TX.
En sortant le kit de la boite il n'est cependant pas possible de le brancher puis de charger un programme sur la carte arduino, car par défaut la connexion est à 57600 bauds, alors que le chargement des programmes sur l'arduino se fait à 9600 bauds (je n'ai pas trouvé comment le modifier).

J'ai donc chargé l'exemple Analog/AnalogInOutSerial d'arduino et modifié le baud rate à 57600.

Voici les messages reçus (à une distance de 5cm...). On voit déjà que des parties sont perdues (1 ligne sur 5, environ). Plusieurs caractères sont perdus.

sensor = 268 oor = 267 output = 66
sensor = 269 output = 67
sensor = 269 output = 67
senso 67
sensor = 266 output = 66
sensor = 266 output = 66
sensor = 268 output = 66
sensor = 269 output = 67
sput = 67
sensor = 268 output = 66
sensor = 266 output = 66
sensor = 266 output = 66
sensor = 269 output = 67
tput = 66
sensor = 269 output = 67
sensor = 267 output = 66
sensor = 266 osensor = 269 output = 67
sensor = 267 output = 66
sensor = 266 output output = 66
sensor = 266 output = 66
sensor = 266 output = 66
sensor = 269 output = 67
sensor = 268 output = output = 67
sensor = 267 output = 66
sensor = 266 output = 66
sensor = 267 r = 266 output = 66
sensor = 269 output = 67
sensor = 269 output = 67

Il semble donc nécessaire d'avoir un mécanisme de vérification des messages.
Je vais donc essayer de faire des tests plus poussés avec des messages NMEA, ou des messages Mavlink.
Il semble aussi nécessaire d'intégrer un bit de vie (heartbeat) pour être capable de vérifier la connexion.

IMU

J'avais recommandé 2 IMU 10DOF chez Drotek, suite à la destruction d'une carte par une pile qui a explosé, puis coulé.

J'ai recommandé une carte identique pour pouvoir repartir de là où j'étais rendu, et une carte utilisant les derniers composants.

Les cartes étant livrées sans "pin header", j'ai d'abord soudé des connecteur coudées, aux contacts SDA, SCL, GND, 5V (en laissant de côté le 3.3V, les arduino nano et uno que j'utilise fonctionnant en 5V).

Malheureusement, les programmes restaient désespérément bloqués à l'initialisation avec les deux cartes. Dès le premier "write" le programme bloquait.

Dans le doute, j'ai utilisé une autre librairie  I2C ainsi qu'un programme de scan des adresses I2C.

Avec l'ancienne carte, même endommagée, j'arrivais bien à détecter le MPU6050, mais rien avec la nouvelle, comme si le fil de données SDA n'était pas connecté. J'ai pourtant pu vérifier avec un multimètre que les contacts étaient bons jusqu'aux pattes du circuit intégré.

Rien non plus avec la carte plus récente. Alors que je commençais à desespérer de n'avoir pu faire fonctionner aucune des deux cartes j'ai trouvé, en cherchant sur le forum de drotek, un poste expliquant probablement l'origine de mon problème sur la carte récente. La carte doit être modifiée si on veut utiliser le protocole I2C. Des "Pull up solder bridged' sont prévus sur la carte, comme on peut le voir sur le schéma de drotek (Points jaunes, oranges et rouges dans la vue "TOP").

Je n'ai pas trouvé d'explication sur la manière de faire ces soudures. J'ai donc essayé en chauffant au fer à souder, mais je n'arrivais pas à faire le contact. J'ai donc essayé d'amener un peu d'étain, mais là, catastrophe! Le plastique se mettait à fondre recouvrant les pastilles d'une couche isolante empêchant tout contact.

Etant incapable de réaliser le contact électrique, j'ai essayé d'enlever le plastique en chauffant de nouveau avec la pointe du fer à souder. Et là, les choses ont empiré, le plastique a complètement fondu, et les pastilles se décalaient lorsque je raclais avec la pointe du fer à souder.

A l'heure actuelle, je ne sais dire si cela est dû à un fer à souder trop chaud (je n'ai pas de contrôle de la température), une panne trop grosse, ma maladresse (bientôt légendaire), ou mon manque d'expérience.

Le problème est que je n'ai pas acquis plus d'expérience de mes erreurs... Que faire? Racheter une carte, renvoyer une des deux en SAV? Trouver une autre carte sans soudure à réaliser?

J'ai finalement commandé la version précédente de la carte.
Il n'y a effectivement pas de jumper à souder (mais toujours des pins). Un autre avantage est que le code proposé pour le MPU9250 n'était pas vraiment officiel, alors que la documentation sur le MPU9150 est plus importante.

J'ai aussi remarqué que l'accéléromètre et le gyro de la carte endommagée, fonctionnent encore (mais pas le magéntomètre et le capteur de pression).

JSBSIM

I am looking at how to integrate a tether in JSBSim (the flight dynamic model used by FlightGear).
The easy way seems to integrate some external forces, which is possible.

Je regarde comment intégrer une ligne de retenue dans JSBSim (le modèle dynamique de vol de FlightGear). La bonne solution semble d'intégrer des forces extérieures, ce que prévoit le logiciel.
 http://wiki.flightgear.org/JSBSim_External_forces

The good point is that mooring forces were already integrated in some Zeppelin example.

La bonne nouvelle, c'est que des exemples d'ancrages sont disponibles, par exemple pour un Zeppelin.
http://wiki.flightgear.org/ZLT-NT

More in details, the mooring system is defined here
Plus précisément, le système d'ancrage est défini ici
https://gitorious.org/anders-hangar/zlt-nt/source/a5d532a4260b540deab1aab27612564e3622af71:Systems/mooring-jsbsim.xml 

Son fonctionnement est décrit ici
https://gitorious.org/anders-hangar/zlt-nt/source/a5d532a4260b540deab1aab27612564e3622af71:Systems/ground_handling.nas

Une autre approche, peut-être plus intéressante encore, est de réutiliser un modèle de planeur avec un câble de traction (winch ou aerotowing).
http://wiki.flightgear.org/Howto:Setup_winch_and_aerotowing_for_JSBSim-aircraft

Hackathon Kiderwind à Matera

Je suis toute la semaine à Matera, dans le sud de l'Italie, pour participer au hackathon Kiderwind.

Nous réfléchissons à reprendre un pilote automatique de drone aérien, et à le modifier afin de piloter un kider (contraction de kite et glider).

Nous avons déjà eu de belles discussions avec d'autres passionnés par le sujet.
Une idée qui me plait est de tendre un câble dans la vallée de la Gravina sous le village, et d'attacher le kider au milieu du câble. Ainsi pas de risque de crash.

Article Beyond The sea

Voici un nouvel article sur Beyond the Sea dans le Sud-Ouest.
Je vous conseille de regarder le code source de la page !

Ptites news d'Octobre

Peu de temps pour poster des nouvelles depuis Septembre, mais j'ai gardé quelques liens de côté.

Robokite
Voici tout d'abord un article paru dans Nantes Passion et parlant du projet robokite. Attention, il y a maintenant un autre projet robokite, qui nous vient de Russie. Cette équipe étudiante cherche à développer un système se fixant sur... une planche de kite! Objectif : une dronification complète pour participer à la microtransat!

E-Kite
Voici une (nouvelle?) entreprise misant sur le reel in/out aux Pays-Bas 

Enerkite
Voici des nouvelles vidéos d'Enerkite, une entreprise allemande à découvrir dans deux vidéos amusantes


Kitegen
Kitegen a dévoilé les premières images de sa nouvelle aile semi-rigide de 150m2

Makani
Makani prévoit des tests d'endurance à Hawai en 2015

Kitemill
Voici également un article sur le projet Kitemill, poussé par la société Kongsberg, vendant des systèmes automatiques pour les navires.

Swiss kite power
Voici le dernier article scientifique sur le sujet

TUDelft
Voici également une vidéo sur des simulations réalisées par TUDelft

DFSCKite
D'autres simulations d'un système de pompage réalisées par l'équipe kite de l'Université Fédéral De Santa Catarina au Brésil

Niveau simulation, voici également un lien vers un simulateur de câble aérien (en Fortran).

Rolokite
Voici un lien vers Rolokite, l'entreprise de Roland Verheul qui conçoit des cerfs-volants à partir de boudins gonflables.

Kiteboat
Voici le lien vers un article du sintef, sur un projet visant à développer des navires 100% automatisés.

Un article sur l'avenir du kite pour la traction en course ou en plaisance et présentant notamment une vidéo sympa du projet kitetender


Aerosail
Et voici également deux belles vidéos sur le projet Aérosail de Stéphane Rousson qui a finalement réussi à faire décoller son dirigeable (en mer) après des déboires administratifs.

Beyond The Sea
Et pour finir un article paru dans le journal Sud Ouest sur le projet d'Yves Parlier