Le Printemps de l'ICAM aura lieu cette année encore au niveau du parc des Chantiers (près des Nefs) le samedi 21 Mars 2015.
Cette année le thème sera l'histoire de l'ingénierie, avec son passé, son présent et son futur!
Le projet Robokite fera partie des projets présentés (passé, présent, ou futur?).
mardi 23 décembre 2014
lundi 22 décembre 2014
Notez la date : Openatelier spécial nautisme jeudi 22 Janvier
Le 22 Janvier, Ping (qui vient d'avoir 10 ans!) organise un atelier autour du nautisme.
Robokite sera présenté entre autre
Extrait du programme
"Les festivités démarreront à 16h avec la présentation de:
– Nomade des Mers par Pierre-Alain Leveque de l’association “Gold of Bengal”
– Lab-R.E.V. par Adrien Marchandise
– Robokite par Baptiste Labat
– La Cale de l’île par Alain Douaré"
Robokite sera présenté entre autre
Extrait du programme
"Les festivités démarreront à 16h avec la présentation de:
– Nomade des Mers par Pierre-Alain Leveque de l’association “Gold of Bengal”
– Lab-R.E.V. par Adrien Marchandise
– Robokite par Baptiste Labat
– La Cale de l’île par Alain Douaré"
HWN500
Voici l'annonce de la création d'un nouveau réseau dans le domaine de l'énergie éolienne aérienne :
"Dear AWE-friends
We
are happy to announce the foundation of the Airborne Wind Energy
Network “HWN 500”. Goal is to initiate R&D-projects to support the
development of innovative airborne wind energy systems.
Network
partners are small & medium sized companies, international
institutions and universities as well as the German Airborne Wind Energy
Association.
Together with its partners the network initiates innovative research and development projects in the areas:
- Aerodynamics, Steering & Control
- Meteorology & Wind
- Robotics, Launch/Retrieval
- Energy Storage
- Permits & Certifications.
The
network is co-financed by the German Ministry for Economics and Energy
which has the target to support R&D projects in Germany. Even if the
focus for these projects is on Germany, the network is open for
partners from all over the world.
Further information will be published at www.hwn500.de shortly.
Please note that the Network will be present at the upcoming Airborne Wind Energy Conference taking place at TU Delft June 15/16
2015. If you are interested to join the network you are welcome to
contact our network-management either by email or at AWEC 2015.
I wish you a Merry Christmas and a Happy New Year.
Guido Luetsch
Leader Network-Management"
dimanche 21 décembre 2014
WinDEEP
WinDEEP est un projet étudiant qui démarre à l'Ecole Centrale de Lille. Le projet n'est à l'origine pas lié au projet kitemill déjà rapidement évoqué sur ce blog. A suivre donc...
Présentation prezi
Présentation prezi
Ptites news
KiteWinderKiteWinder est un récent projet d'éolienne aérienne français. Olivier Normand travaillait dans l'aéronautique avant de se lancer dans le projet.
Le projet est d'utiliser un cerf-volant de type Coddy pour porter une éolienne. Ca me rappelle certains prototype de Kpower, notamment un présenté lors de l'AWEC 2013.
Olivier a déjà développé un système de treuil instrumenté mobile à découvrir dans ses vidéos
Kitegen
Voici une chaîne youtube avec des anciennes vidéos de kitegen mais pour moi inédites
Egalement une émission télévisée
Autokite
Un système de treuil pour un kiteboat développé entre 2003 et 2007
??
https://www.youtube.com/user/markaull/videos
Balancier à 2 cerfs-volants
Joystick control
Un autre exemple de contrôle avec un joystick et quelques essais de vision par ordinateur
Le projet est d'utiliser un cerf-volant de type Coddy pour porter une éolienne. Ca me rappelle certains prototype de Kpower, notamment un présenté lors de l'AWEC 2013.
Olivier a déjà développé un système de treuil instrumenté mobile à découvrir dans ses vidéos
Kitegen
Voici une chaîne youtube avec des anciennes vidéos de kitegen mais pour moi inédites
Egalement une émission télévisée
Autokite
Un système de treuil pour un kiteboat développé entre 2003 et 2007
??
https://www.youtube.com/user/markaull/videos
Balancier à 2 cerfs-volants
Joystick control
Un autre exemple de contrôle avec un joystick et quelques essais de vision par ordinateur
samedi 6 décembre 2014
Amélioration du joystick et préparation contrôle en boucle fermée du kite
Pas mal d'amélioration au niveau du programme python servant jusqu'à présent à renvoyer les ordres du joystick vers l'arduino.
Le fonctionnement est le suivant :
Appui sur le bouton 1 : passage en mode manuel. Ce mode n'est pas implémenté, mais l'idée est de relâcher le border choquer à fond, de manière à ce que la barre puisse être parfaitement contrôlée à la main.
Appui sur le bouton 2 : passage en mode Joystick Open Loop. Dans ce mode, les ordres envoyés vont directement correspondre à la tension et donc à la vitesse des moteurs, chaque moteur étant commandé par un axe du joystick. La croix de la manette permet de régler finement un décalage (offset, trim). pour avoir une vitesse de rotation non nulle lorsque le joystick revient au neutre.
Appui sur le bouton 3 : passage en mode Joystick Close Loop. Dans ce mode, les capteurs d'angle et de border-choquer de la barre sont utilisés par la contrôler en boucle fermée. Un offset peut-être régler de même avec la croix.
Appui sur le bouton 4 : en plus des ordres envoyés par le joystick on utilise également les mesures de la petite centrale inertielle montée sur le cerf-volant et renvoyant des messages mavlink via une liaison radio en 433MHz.
Le code est là
Le fonctionnement est le suivant :
Appui sur le bouton 1 : passage en mode manuel. Ce mode n'est pas implémenté, mais l'idée est de relâcher le border choquer à fond, de manière à ce que la barre puisse être parfaitement contrôlée à la main.
Appui sur le bouton 2 : passage en mode Joystick Open Loop. Dans ce mode, les ordres envoyés vont directement correspondre à la tension et donc à la vitesse des moteurs, chaque moteur étant commandé par un axe du joystick. La croix de la manette permet de régler finement un décalage (offset, trim). pour avoir une vitesse de rotation non nulle lorsque le joystick revient au neutre.
Appui sur le bouton 3 : passage en mode Joystick Close Loop. Dans ce mode, les capteurs d'angle et de border-choquer de la barre sont utilisés par la contrôler en boucle fermée. Un offset peut-être régler de même avec la croix.
Appui sur le bouton 4 : en plus des ordres envoyés par le joystick on utilise également les mesures de la petite centrale inertielle montée sur le cerf-volant et renvoyant des messages mavlink via une liaison radio en 433MHz.
Le code est là
Apéro-projets en image
 |
| Le proto en vélo, devant la grue jaune Titan où il sera peut-être un jour installé pour faire des tests en pleine ville! |
 |
| L'auteur de cet article au micro |
 |
| Une guirlande de noel? |
 |
| Le banc de test temporaire monté pour la soirée au complet |
mercredi 26 novembre 2014
Apéros-projets
Demain de 18h30-20h30, c'est les apéro-projets au fablab nantais PlateformeC.
J'y présenterai notamment le projet robokite.
N'hésitez pas à venir, c'est ouvert à tous!
J'y présenterai notamment le projet robokite.
N'hésitez pas à venir, c'est ouvert à tous!
Reconnexion automatique du port série entre arduino et python avec pyserial
Si jamais une connexion est ouverte entre l'arduino et un programme python utilisant pyserial et que je débranche le câble, je n'arrive jamais à me reconnecter ensuite à moins de rouvrir la console arduino.
J'ai cherché une alternative en ligne de commande à l'ouverture d'arduino.
J'ai d'abord trouvé la commande screen, qui permet d'écouter ce qui arrive sur le port série (entre autres) :
screen /dev/ttyACM0 57600.cs8
La commande suivante permet ensuite de fermer cette session
Ctrl + A + k
J'ai cherché une alternative en ligne de commande à l'ouverture d'arduino.
J'ai d'abord trouvé la commande screen, qui permet d'écouter ce qui arrive sur le port série (entre autres) :
screen /dev/ttyACM0 57600.cs8
La commande suivante permet ensuite de fermer cette session
Ctrl + A + k
Une autre solution plus simple et de tapper la commande
stty -F /dev/ttyACM0 57600 cs8 cread clocal
J'ai finalement inclus cette commande dans mon script python, pas très beau et cross-platform, mais ça marche :
os.system("stty -F /dev/ttyACM0 57600 cs8 cread clocal")
J'ai le même problème de déconnection reconnection avec le joystick. Pygame qui utilise SDL 1.2 ne fait pas ça de base. Mais quelqu'un dit avoir trouvé une solution, mais sans l'expliquer... Rageant.
J'ai finalement trouvé la bonne alchimie, en faisant une reconnexion automatique si aucun mouvement du joystick n'a été envoyé dans les deux dernières secondes.
Le code python correspondant est là.
Le code arduino est là.
stty -F /dev/ttyACM0 57600 cs8 cread clocal
J'ai finalement inclus cette commande dans mon script python, pas très beau et cross-platform, mais ça marche :
os.system("stty -F /dev/ttyACM0 57600 cs8 cread clocal")
J'ai le même problème de déconnection reconnection avec le joystick. Pygame qui utilise SDL 1.2 ne fait pas ça de base. Mais quelqu'un dit avoir trouvé une solution, mais sans l'expliquer... Rageant.
J'ai finalement trouvé la bonne alchimie, en faisant une reconnexion automatique si aucun mouvement du joystick n'a été envoyé dans les deux dernières secondes.
Le code python correspondant est là.
Le code arduino est là.
Difficultés avec arduino
Cet été, au moment de faire les tests sur la plage, plus rien ne marchait à un moment du test : impossible de faire fonctionner le programme arduino envoyant les ordres aux moteurs, alors que le code était inchangé et avait marché même au début du test.
Ayant eu un problème, je l'avais simplement rechargé sur la carte arduino et plus rien ne marchait.
Au dernier moment, juste avant d'abandonner, j'avais eu la bonne idée de tester avec la version 1.03 d'arduino que j'utilisais avant au lieu de la 1.05 que j'utilisais depuis quelques jours sur d'autres développements.
Et là, comme par miracle tout s'était mis à remarcher.
Suite à la confrontation à différents bugs sur les versions précédentes, je suis maintenant sur la version 1.6.0.
Et j'essaie simplement de reprendre un code qui a déjà marché... mais là de même plus rien ne marche.
Il est vrai que maintenant un message d'erreur s'affiche pour me signaler que la mémoire dynamique restante est faible et que je pourrais avoir des problèmes de stabilité...
J'ai d'abord ajouté des traces pour identifier l'origine du bug. Assez vite j'ai trouvé qu'il y a avait un problème dans la lecture des String reçus via la communication série. Un peu comme si la mémoire n'était pas allouée/modifiée.
Au fur et à mesure, j'ai essayé d'enlever du code pour arriver à la portion de code minimale levant l'erreur.
J'ai bien trouvé une erreur potentielle avec les dimensions d'un tableau qui était en dur. Mais même après la correction de ce bug potentiel, une erreur restait et qui ne semblait pas déterministe. En enlevant des lignes sans aucun rapport à différents endroits, cela corrige parfois le problème.
J'ai finalement testé sur une carte arduino mega, et là, plus de problème, ce qui montre bien que le problème ne vient pas vraiment du code, ou alors d'une fuite mémoire.
J'ai donc essayé de refaire le code à zéro, pour enlever éventuellement des fonctionnalités, et avoir un code plus léger, mais fonctionnel.
J'ai finalement réussi à trouver que le problème survenait lors de l'ouverture d'une communication avec Software serial.
SWSerial.begin(9600);
Le problème arrive en rajoutant cette simple ligne dans l'exemple serialEvent. Si les bauds rate sont identiques, rien ne passe, s'ils sont différents, seulement quelques caractères.
Le software serial que j'utilise n'est cependant pas générique "mysoftwareserial" et le problème pourrait venir de là.
Pour rappel, j'ai du utiliser cette version de la bibliothèque modifiée à cause de problème de compatibilité avec les interrupts venant du codeur linéaire, comme expliqué ici.
Je vais essayer de voir s'il est possible de régler le problème. Dans l'immédiat, je devrais de toute manière être capable de faire une démo demain, juste en joystick, ou tout au moins sans boucle fermée sur le border-choquer.
Au passage, cela me permet de noter un problème de gestion de configuration, le code modifié n'étant pas commité. Mais aussi de m'autoféliciter d'avoir aussi bien documenté par ailleurs ;-).
Edit:
Le problème a fini par apparaître avec la librairie Software serial basique également.
En fait le problème vient du fait que la variable NOT_A_PIN était utilisée pour désigner la pin en réception, en mettant par exemple le port 10, plus de problème. Mais ça reste toujours mystérieux pour moi...
Le software serial que j'utilise n'est cependant pas générique "mysoftwareserial" et le problème pourrait venir de là.
Pour rappel, j'ai du utiliser cette version de la bibliothèque modifiée à cause de problème de compatibilité avec les interrupts venant du codeur linéaire, comme expliqué ici.
Je vais essayer de voir s'il est possible de régler le problème. Dans l'immédiat, je devrais de toute manière être capable de faire une démo demain, juste en joystick, ou tout au moins sans boucle fermée sur le border-choquer.
Au passage, cela me permet de noter un problème de gestion de configuration, le code modifié n'étant pas commité. Mais aussi de m'autoféliciter d'avoir aussi bien documenté par ailleurs ;-).
Edit:
Le problème a fini par apparaître avec la librairie Software serial basique également.
En fait le problème vient du fait que la variable NOT_A_PIN était utilisée pour désigner la pin en réception, en mettant par exemple le port 10, plus de problème. Mais ça reste toujours mystérieux pour moi...
mardi 25 novembre 2014
Python et mavlink
J'ai pour l'instant fait quelques tests d'émission de message d'attitude avec Mavlink à partir d'un arduino connecté à une petite IMU.
Ces données sont envoyées par le port série, via un kit radio, puis récupérées sur un pc (mon pc en phase de développement, puis un raspberry ensuite).
J'ai pour l'instant pu vérifier la bonne réception des trames avec QGroundControl.
Je souhaite maintenant recevoir les messages avec un programme python qui contiendra l'algorithme de pilotage et renverra des ordres en vitesse de moteur ou en position de barre.
Je me suis d'abord basé sur la documentation officiel
git clone git://github.com/mavlink/mavlink.git
cd mavlink/pymavlink
python setup.py install
J'ai ensuite essayé de lancer un exemple (mavtester.py). Je suis malheusement tombé sur une erreur concernant le sous-module mavtest qui n'existait pas.
J'ai donc cherché à recompiler à partir de
Cette fois j'obtiens l'erreur "No module named mavgen_python"
En fait l'erreur ne vient pas vraiment de là, mais de l'utilisation de mavgen.py au lieu de mavgenerate.py
Voici donc les bonnes commandes à exécuter :
cd mavlink
sudo python mavgenerate.py -o mavlinkv10.py message_definitions/v1.0/common.xml
Cela lance une GUI permettant de choisir les messages à générer à partir d'un fichier xml de définition des messages.
A la fin de l'opération, j'ai eu un message me signalant que tout s'était bien passé.
Cependant, dans la console j'avais un message d'erreur, mais qui semble sans importance :
^CException in Tkinter callback
Traceback (most recent call last):
File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1489, in __call__
return self.func(*args)
File "mavgenerate.py", line 172, in generateHeaders
tkinter.messagebox.showinfo('Successfully Generated Headers', 'Headers generated successfully.')
File "/usr/lib/python2.7/lib-tk/tkMessageBox.py", line 83, in showinfo
return _show(title, message, INFO, OK, **options)
File "/usr/lib/python2.7/lib-tk/tkMessageBox.py", line 72, in _show
res = Message(**options).show()
File "/usr/lib/python2.7/lib-tk/tkCommonDialog.py", line 48, in show
s = w.tk.call(self.command, *w._options(self.options))
KeyboardInterrupt
Mais cela ne réglait pas plus le problème du manque de mavtest.
J'ai finalement modifié le script mavtester.py pour supprimer la dernière ligne qui était la seule à utiliser le module mavtest.
Le test se lance de la manière suivante
python mavtester.py --device /dev/ttyUSB0
Mais le programme stoppait sur :
Waiting for APM heartbeat
Ces données sont envoyées par le port série, via un kit radio, puis récupérées sur un pc (mon pc en phase de développement, puis un raspberry ensuite).
J'ai pour l'instant pu vérifier la bonne réception des trames avec QGroundControl.
Je souhaite maintenant recevoir les messages avec un programme python qui contiendra l'algorithme de pilotage et renverra des ordres en vitesse de moteur ou en position de barre.
Je me suis d'abord basé sur la documentation officiel
git clone git://github.com/mavlink/mavlink.git
cd mavlink/pymavlink
python setup.py install
J'ai ensuite essayé de lancer un exemple (mavtester.py). Je suis malheusement tombé sur une erreur concernant le sous-module mavtest qui n'existait pas.
J'ai donc cherché à recompiler à partir de
mavgen.py -o mavlinkv10.py mavlink/message_definitions/v1.0/common.xml
Cette fois j'obtiens l'erreur "No module named mavgen_python"
En fait l'erreur ne vient pas vraiment de là, mais de l'utilisation de mavgen.py au lieu de mavgenerate.py
Voici donc les bonnes commandes à exécuter :
cd mavlink
sudo python mavgenerate.py -o mavlinkv10.py message_definitions/v1.0/common.xml
Cela lance une GUI permettant de choisir les messages à générer à partir d'un fichier xml de définition des messages.
A la fin de l'opération, j'ai eu un message me signalant que tout s'était bien passé.
Cependant, dans la console j'avais un message d'erreur, mais qui semble sans importance :
^CException in Tkinter callback
Traceback (most recent call last):
File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1489, in __call__
return self.func(*args)
File "mavgenerate.py", line 172, in generateHeaders
tkinter.messagebox.showinfo('Successfully Generated Headers', 'Headers generated successfully.')
File "/usr/lib/python2.7/lib-tk/tkMessageBox.py", line 83, in showinfo
return _show(title, message, INFO, OK, **options)
File "/usr/lib/python2.7/lib-tk/tkMessageBox.py", line 72, in _show
res = Message(**options).show()
File "/usr/lib/python2.7/lib-tk/tkCommonDialog.py", line 48, in show
s = w.tk.call(self.command, *w._options(self.options))
KeyboardInterrupt
Mais cela ne réglait pas plus le problème du manque de mavtest.
J'ai finalement modifié le script mavtester.py pour supprimer la dernière ligne qui était la seule à utiliser le module mavtest.
Le test se lance de la manière suivante
python mavtester.py --device /dev/ttyUSB0
Mais le programme stoppait sur :
Waiting for APM heartbeat
Cela ne fonctionnait pas, alors que des bits de vie étaient bien envoyés par l'arduino, ce que j'ai pu vérifier avec QgroundControl.
Etait-ce dû à un problème de version de la librairie (lors de l'installation avec setup.py, la version 0.9 et la version 1.0 sont copiées)?
J'ai cherché dans le code. mavutil.mavlink10() permet de vérifier si la version 1.0 est bien utilisée, et c'était le cas.
J'ai finalement trouvé l'erreur. Je n'avais pas précisé le baudrate dans la commande (il est par défaut à 115200).
Avec la commande suivante, j'arrive bien à revevoir le bit de vie.
python mavtester.py --device /dev/ttyUSB0 --baudrate 57600
Ptites news
KiteboatProject
De belles images de navigations à proximité ou sous le Golden Gate Bridge.
EPFL
Une nouvelle équipe s'intéresse au sujet de systèmes automatisés pour la production d'énergie à partir des kites.
Sean Costello, Grégory François et Dominique Bonvin ont déjà écrit un papier.
Voici également un article et la vidéo en lien.
Fotokite
Pour comprendre Fotokite, le mieux est de regarder la conférence TED donnée par Sergei Lupashin.
L'idée était dans l'air, mais c'est la première fois que je vois une réalisation ausssi aboutie. Il n'y a plus qu'à rajouter un peu de surface portante, et cela permettra d'avoir un hybride drone-cerf-volant.
Divertissement
Voici une vidéo d'un cerf-volant très rapide (lien partagé sur le forum AirborneWindEnergy, comme beaucoup de ces news).
R2/230 -2 from Andre Eibel on Vimeo.
Kitebot
Voici un lien vers quelques photos des avancées du projet DIY low tech kitebot. Des pièces de vélo sont utilisées pour réaliser un volant d'inertie avec un peu de béton.
FlygenKite
Voici un article plus tout récent sur le système flygenkite
Makani
Makani cherche à montrer que l'installation d'un prototype pendant 1 an ne sera pas un danger pour la navigation aérienne.
KUL
Un peu de transparence dans les financements européens, mais toujours peu de liens vers les résultats pour cette coquette somme.
ENSTA Bretagne
De nouveaux thésards sont arrivés, notamment Alain de Solminihac qui a réalisé son stage de fin d'études chez Kitegen à Turin. Plus de nouvelles bientôt j'espère.
De belles images de navigations à proximité ou sous le Golden Gate Bridge.
EPFL
Une nouvelle équipe s'intéresse au sujet de systèmes automatisés pour la production d'énergie à partir des kites.
Sean Costello, Grégory François et Dominique Bonvin ont déjà écrit un papier.
Voici également un article et la vidéo en lien.
Fotokite
Pour comprendre Fotokite, le mieux est de regarder la conférence TED donnée par Sergei Lupashin.
L'idée était dans l'air, mais c'est la première fois que je vois une réalisation ausssi aboutie. Il n'y a plus qu'à rajouter un peu de surface portante, et cela permettra d'avoir un hybride drone-cerf-volant.
Divertissement
Voici une vidéo d'un cerf-volant très rapide (lien partagé sur le forum AirborneWindEnergy, comme beaucoup de ces news).
R2/230 -2 from Andre Eibel on Vimeo.
Kitebot
Voici un lien vers quelques photos des avancées du projet DIY low tech kitebot. Des pièces de vélo sont utilisées pour réaliser un volant d'inertie avec un peu de béton.
FlygenKite
Voici un article plus tout récent sur le système flygenkite
Makani
Makani cherche à montrer que l'installation d'un prototype pendant 1 an ne sera pas un danger pour la navigation aérienne.
KUL
Un peu de transparence dans les financements européens, mais toujours peu de liens vers les résultats pour cette coquette somme.
ENSTA Bretagne
De nouveaux thésards sont arrivés, notamment Alain de Solminihac qui a réalisé son stage de fin d'études chez Kitegen à Turin. Plus de nouvelles bientôt j'espère.
lundi 24 novembre 2014
Raspberry Pi B+
Un raspberry pi est pour l'instant utilisé sur le projet robokite.
Quelques inconvénients devraient disparaître avec la nouvelle version B+.
D'abord le nombre de ports USB plus élevé (4 au lieu de 2) devrait permettre d'avoir à la fois le joystick, le module wifi et la connexion vers l'arduino, sans utiliser de hub usb supplémentaire. Le port USB restant pourrait même être utilisé pour faire tourner l'os, à la place de la carte sd qui était souvent corrompu (on trouve aujourd'hui des clés USB de plusieurs gigaoctets et à peine plus grande que le connecteur USB pour le même prix qu'une carte SD.
J'ai acheté le raspberry directement chez E44 electronique.
J'ai eu une petite surprise car je n'avais pas fait attention, que la carte SD a été remplacée par une carte microSD.
J'ai eu peur que cela pose un problème pour la mettre sur mon ordinateur, mais les cartes microSD sont en général vendues avec des adapteurs SD.
La procédure pour programmer la carte est donc théoriquement inchangée.
Malheureusement, la carte que j'ai flashée n'a pas fonctionnée (et n'est même plus reconnue sur mon PC). Il s'agit d'une carte SanDisk "HD video" de 8Go.
A suivre...
Quelques inconvénients devraient disparaître avec la nouvelle version B+.
D'abord le nombre de ports USB plus élevé (4 au lieu de 2) devrait permettre d'avoir à la fois le joystick, le module wifi et la connexion vers l'arduino, sans utiliser de hub usb supplémentaire. Le port USB restant pourrait même être utilisé pour faire tourner l'os, à la place de la carte sd qui était souvent corrompu (on trouve aujourd'hui des clés USB de plusieurs gigaoctets et à peine plus grande que le connecteur USB pour le même prix qu'une carte SD.
J'ai acheté le raspberry directement chez E44 electronique.
J'ai eu une petite surprise car je n'avais pas fait attention, que la carte SD a été remplacée par une carte microSD.
J'ai eu peur que cela pose un problème pour la mettre sur mon ordinateur, mais les cartes microSD sont en général vendues avec des adapteurs SD.
La procédure pour programmer la carte est donc théoriquement inchangée.
Malheureusement, la carte que j'ai flashée n'a pas fonctionnée (et n'est même plus reconnue sur mon PC). Il s'agit d'une carte SanDisk "HD video" de 8Go.
A suivre...
dimanche 23 novembre 2014
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à.
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.
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.
vendredi 21 novembre 2014
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).
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).
mardi 21 octobre 2014
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
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.
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 !
Je vous conseille de regarder le code source de la page !
dimanche 12 octobre 2014
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
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
dimanche 7 septembre 2014
Ptite news
Voici quelques ptites news (clin d'oeil au blog Foilers!)
Simulateur
Uwe Fechner a annoncé que le simulateur freekitesim développé par l'université de Delft est maintenant disponible :
https://groups.google.com/forum/#!topic/free-kitesim/X9QW-kC6JHc
Densité des kites
Voici une vidéo de snowkite où la densité de kite est assez impressionnante.
Nouvelle entreprise
Voici une nouvelle entreprise qui se lance dans les kites du côté de la Grande-Bretagne. L'équipe a l'air bonne. Le meneur a travaillé sur des winchs marins.
http://www.kitepowersolutions.com/
Ils recrutent !
Simulateur
Uwe Fechner a annoncé que le simulateur freekitesim développé par l'université de Delft est maintenant disponible :
https://groups.google.com/forum/#!topic/free-kitesim/X9QW-kC6JHc
Densité des kites
Voici une vidéo de snowkite où la densité de kite est assez impressionnante.
Nouvelle entreprise
Voici une nouvelle entreprise qui se lance dans les kites du côté de la Grande-Bretagne. L'équipe a l'air bonne. Le meneur a travaillé sur des winchs marins.
http://www.kitepowersolutions.com/
Ils recrutent !
mercredi 3 septembre 2014
Offres d'emploi Ampyx power
Ampyx power recherche des chefs de projet pour ses projets d'éoliennes aériennes.
Offre d'emploi 1
Offre d'emploi 2
Offre d'emploi 1
Offre d'emploi 2
mercredi 27 août 2014
Carakite
Je suis tombé sur cet article de seasailsurf http://www.seasailsurf.com/seasailsurf/actu/8489-Video-Une-CaraKite-dans-la-rade-de-Lorient?lang=fr
On y trouve une belle vidéo de Caravelle Kite dans la rade de Lorient. On peut apprécier les mouvements en huit imposés par le pilote pour avoir plus de puissance.
J'essaie d'en savoir plus!
On y trouve une belle vidéo de Caravelle Kite dans la rade de Lorient. On peut apprécier les mouvements en huit imposés par le pilote pour avoir plus de puissance.
J'essaie d'en savoir plus!
lundi 25 août 2014
Train d'ailes humain
Voici une belle vidéo montrant trois kitesurfeurs naviguant en train.
Un est en bas sur l'eau, les deux autres dans le ciel!
2up1down from LUPAH FILMS on Vimeo.
Un est en bas sur l'eau, les deux autres dans le ciel!
2up1down from LUPAH FILMS on Vimeo.
mercredi 20 août 2014
Test sur la plage
Vendredi 31/07 j'ai finalement refait les tests de contrôle du kite avec le joystick, tests qui avaient été avortés en mars dernier.
Je me suis rendu sur la plage avec le matos arrimé sur un chariot (mal équilibré...). Pratique!
J'ai commencé à m'installer sur la plage de Sorlock vers 19h30 (la plage est interdite aux cerfs-volants jusqu'à 19h). Le vent venait directement de la mer et était donc régulier.
La difficulté venait de la marée haute (à 20h30) qui réduisait la place sur la plage. Je me suis donc installé à quelques mètres de l'eau, en espérant que cela ne monterait pas trop...
Deux gros sacs de course remplis de sable et à moitié enfouis dans le sable ont servi d'ancrage. Les anses des sacs ont cassé en les déplaçant.
Une grande sangle faisant le tour des sacs et passant dans les anses m'a servi de point d'accroche pour la planche supportant le système de pilotage.
Comme je n'avais prévu qu'un seul point d'accroche, la planche avait tendance à tourner et à tomber sur le côté (les sacs n'étant qu'à moitié enfoui dans le sable).
J'ai donc fixé la planche en un deuxième point pour la mettre dans l'axe du vent et l'empêcher de tourner (la plupart des efforts étant transmis par l'autre point d'accroche).
J'ai eu une petite difficulté à cause d'un grain de sable qui s'était coincé dans le connecteur relié aux capteurs sur la barre. J'ai heureusement réussi à l'enlever en faisant l'aspirateur avec ma bouche ! Je n'avais pas prévu l'utilisation de protection pour ce connecteur (et n'ai de toute manière pas utilisé les protections pour les autres connecteurs non plus...).
Jean-Jacques Labat (alias papa) est venu m'aider pour le décollage.
Les premiers tests de l'électronique se sont bien passé. Puis j'ai rechargé une version (peut-être car ça ne marchait déjà plus bien), et là problème, le feedback de la carte arduino ne revenait plus, et les moteurs ne bougeaient plus. Grosse frayeur après quelques minutes. Avais-je tout préparé pour rien?
J'étais prêt à abandonner quand je me suis souvenu que les derniers tests avaient été faits avec la version 1.03 d'arduino et non la 1.05 que j'utilisais depuis quelques jours sur d'autres développement.
Et là, miracle, tout s'est mis à remarché.
Nous avons ainsi pu faire quelques tests. Au début, je décollais manuellement, puis attendais que mon père revienne, lui donnais la barre, prenais le joystick et prenait finalement le contrôle.
Sur les essais suivants j'essayais de piloter dès le lancement de l'aile, mais cela n'était pas toujours facile, le vent manquant au niveau du sol, et le cerf-volant ayant une tendance à décrocher avec le peu de vent pour s'opposer au poids.
J'ai quelques problèmes avec le bout de la butée qui n'était pas assez rigide.
Je me suis rendu sur la plage avec le matos arrimé sur un chariot (mal équilibré...). Pratique!
J'ai commencé à m'installer sur la plage de Sorlock vers 19h30 (la plage est interdite aux cerfs-volants jusqu'à 19h). Le vent venait directement de la mer et était donc régulier.
La difficulté venait de la marée haute (à 20h30) qui réduisait la place sur la plage. Je me suis donc installé à quelques mètres de l'eau, en espérant que cela ne monterait pas trop...
Deux gros sacs de course remplis de sable et à moitié enfouis dans le sable ont servi d'ancrage. Les anses des sacs ont cassé en les déplaçant.
Une grande sangle faisant le tour des sacs et passant dans les anses m'a servi de point d'accroche pour la planche supportant le système de pilotage.
Comme je n'avais prévu qu'un seul point d'accroche, la planche avait tendance à tourner et à tomber sur le côté (les sacs n'étant qu'à moitié enfoui dans le sable).
J'ai donc fixé la planche en un deuxième point pour la mettre dans l'axe du vent et l'empêcher de tourner (la plupart des efforts étant transmis par l'autre point d'accroche).
J'ai eu une petite difficulté à cause d'un grain de sable qui s'était coincé dans le connecteur relié aux capteurs sur la barre. J'ai heureusement réussi à l'enlever en faisant l'aspirateur avec ma bouche ! Je n'avais pas prévu l'utilisation de protection pour ce connecteur (et n'ai de toute manière pas utilisé les protections pour les autres connecteurs non plus...).
Jean-Jacques Labat (alias papa) est venu m'aider pour le décollage.
Les premiers tests de l'électronique se sont bien passé. Puis j'ai rechargé une version (peut-être car ça ne marchait déjà plus bien), et là problème, le feedback de la carte arduino ne revenait plus, et les moteurs ne bougeaient plus. Grosse frayeur après quelques minutes. Avais-je tout préparé pour rien?
J'étais prêt à abandonner quand je me suis souvenu que les derniers tests avaient été faits avec la version 1.03 d'arduino et non la 1.05 que j'utilisais depuis quelques jours sur d'autres développement.
Et là, miracle, tout s'est mis à remarché.
Nous avons ainsi pu faire quelques tests. Au début, je décollais manuellement, puis attendais que mon père revienne, lui donnais la barre, prenais le joystick et prenait finalement le contrôle.
Sur les essais suivants j'essayais de piloter dès le lancement de l'aile, mais cela n'était pas toujours facile, le vent manquant au niveau du sol, et le cerf-volant ayant une tendance à décrocher avec le peu de vent pour s'opposer au poids.
J'ai quelques problèmes avec le bout de la butée qui n'était pas assez rigide.
Baloon photo
Voici quelques images de Baloon photo que j'ai croisé à Nantes au mois de Juillet.
Le ballon fait 6m3 et permet de soulever une charge jusqu'à 3kg.
La caméra est orientée depuis le sol avec un joystick, et les treuils commandés également.
Le ballon peut-être rangé directement dans un camion.
Baloon photo dispose également d'un dirigeable quand le vent est plus fort et d'un drone.
Le ballon fait 6m3 et permet de soulever une charge jusqu'à 3kg.
La caméra est orientée depuis le sol avec un joystick, et les treuils commandés également.
Le ballon peut-être rangé directement dans un camion.
Baloon photo dispose également d'un dirigeable quand le vent est plus fort et d'un drone.
RF
(c'est article correspond à des tests effectués fin juillet)
J'ai acheté il y a quelques mois un module radiofréquence en 433MHz.
http://electroniqueamateur.blogspot.fr/2014/01/modules-rf-433-mhz-virtualwire-et.html
La portée est de 20 à 200m, en fonction de la tension d'alimentation pouvant aller de 3.5 à 12V.
Mes tests en extérieur donnent à peu près :
Lorsque l'on s'éloigne, la perte de message devient de plus en plus fréquente, jusqu'à ne plus rien recevoir. Des variations dans la position de l'antenne suffisent à recevoir ou ne plus recevoir.
Malheureusement 25m n'est pas suffisant pour les longueurs de ligne classiquement utilisées en kite.
Il me restait à essayer avec une pile 12V (en espérant que le 5V peut passer le seuil haut, autrement il faudra ajouter un montage avec un transistor).
Il existe des piles 12V par exemple de type MN21 23A. J'ai finalement constituée une pile à partir de 4 piles CR2025 en 3V à 163mAh (source wikipedia).
La tension de 4 piles en série était de 12.7V environ. Après quelques minutes de test, il n'y avait plus de transmission au bout de quelques secondes après le redémarrage de l'arduino. J'ai d'abord cru à un problème d'échauffement, mais la tension était tombée à 11V après 10min de test, ce qui me laisse plutôt penser que les piles étaient à plat. Cela ne correspond cependant pas bien aux données techniques qui laisseraient supposer une autonomie d'au moins 1h.
La consommation du module RF est annoncée à 40mA.
La consommation de l'arduino nano à 20mA
Je voulais changer pour une pile 23A (celles utilisées dans les télécommandes de portails automatiques). La tension est de 12V, mais la capacité de seulement 55mAh
Une meilleur solution serait donc la pile 9V, qui permet d'avoir environ 600mAh en version alcaline, 1200mAh en version lithium. De quoi tenir à priori une dizaine d'heure, en attendant de mettre au point une petite éolienne.
J'ai acheté il y a quelques mois un module radiofréquence en 433MHz.
http://electroniqueamateur.blogspot.fr/2014/01/modules-rf-433-mhz-virtualwire-et.html
La portée est de 20 à 200m, en fonction de la tension d'alimentation pouvant aller de 3.5 à 12V.
Mes tests en extérieur donnent à peu près :
- 2m avec 5V et sans antenne
- 10m avec 5V et antenne
- 25m avec 9V et antenne
Lorsque l'on s'éloigne, la perte de message devient de plus en plus fréquente, jusqu'à ne plus rien recevoir. Des variations dans la position de l'antenne suffisent à recevoir ou ne plus recevoir.
Malheureusement 25m n'est pas suffisant pour les longueurs de ligne classiquement utilisées en kite.
Il me restait à essayer avec une pile 12V (en espérant que le 5V peut passer le seuil haut, autrement il faudra ajouter un montage avec un transistor).
Il existe des piles 12V par exemple de type MN21 23A. J'ai finalement constituée une pile à partir de 4 piles CR2025 en 3V à 163mAh (source wikipedia).
La tension de 4 piles en série était de 12.7V environ. Après quelques minutes de test, il n'y avait plus de transmission au bout de quelques secondes après le redémarrage de l'arduino. J'ai d'abord cru à un problème d'échauffement, mais la tension était tombée à 11V après 10min de test, ce qui me laisse plutôt penser que les piles étaient à plat. Cela ne correspond cependant pas bien aux données techniques qui laisseraient supposer une autonomie d'au moins 1h.
La consommation du module RF est annoncée à 40mA.
La consommation de l'arduino nano à 20mA
Je voulais changer pour une pile 23A (celles utilisées dans les télécommandes de portails automatiques). La tension est de 12V, mais la capacité de seulement 55mAh
Une meilleur solution serait donc la pile 9V, qui permet d'avoir environ 600mAh en version alcaline, 1200mAh en version lithium. De quoi tenir à priori une dizaine d'heure, en attendant de mettre au point une petite éolienne.
 |
| Montage sur breadboard |
 |
| Montage directement sur le connecteur de l'IMU (avec "interrupt" grâce au fil jaune) |
 |
| Emetteur radio |
 |
| Montage complet avec pile maison 12V. |
jeudi 31 juillet 2014
Buzz sur Reddit
Je viens de voir que le projet robokite faisait un peu de buzz sur Reddit (outil communautaire de partage de lien que je ne connaissais pas trop), et ça fait toujours plaisir, surtout que des personnes proposent de l'aide !
http://www.reddit.com/r/seasteading/
http://www.reddit.com/r/opensourcehardware/
Il va vraiment falloir que je commence à mettre des news en anglais sur le blog (ça ne sera pas pour celle-ci!) et que je mette à jour le wiki sur github...
http://www.reddit.com/r/seasteading/
http://www.reddit.com/r/opensourcehardware/
Il va vraiment falloir que je commence à mettre des news en anglais sur le blog (ça ne sera pas pour celle-ci!) et que je mette à jour le wiki sur github...
samedi 26 juillet 2014
KiderWind
Je parlais récemment sur ce blog d'un nouveau projet Italien découvert sur le forum drones-discuss.
J'en sais maintenant plus.
Le projet s'appelle KiderWind et se veut open source. La "philosophie" ouverte de l'équipe correspond parfaitement à la philosophie du projet robokite (ou du projet open source ecologogy), mais plutôt orientée sur une base planeur qu'une base aile de kitesurf.
La grande nouvelle est qu'ils organisent un Hackaton fin aout sur le sujet à Matera, dans le sud de l'Italie
Peut-être une belle occasion de travailler en équipe.
J'en sais maintenant plus.
Le projet s'appelle KiderWind et se veut open source. La "philosophie" ouverte de l'équipe correspond parfaitement à la philosophie du projet robokite (ou du projet open source ecologogy), mais plutôt orientée sur une base planeur qu'une base aile de kitesurf.
La grande nouvelle est qu'ils organisent un Hackaton fin aout sur le sujet à Matera, dans le sud de l'Italie
Peut-être une belle occasion de travailler en équipe.
Mobile Airborne Wind Energy
Le projet windlift a pour l'instant fait le choix du pilotage manuel (joystick), mais produit déjà de l'électricité, avec des produits qui témoignent d'une réflexion sur le marché, plus que d'une volonté de démonstration de capacité en ingénierie.
Rob Creighton et son premier prototype (juste une armature et quelques poulies) à la télévision
Et voici le résultat en 2011
L'aile utilisée fait 40m2.
Voici également un excellent article de Rob Creighton en 2012 http://spectrum.ieee.org/energy/renewables/the-benefits-of-airborne-wind-energy
Plus de nouvelles depuis
http://www.energykitesystems.net/WindLift/index.html
Rob Creighton et son premier prototype (juste une armature et quelques poulies) à la télévision
Et voici le résultat en 2011
L'aile utilisée fait 40m2.
Voici également un excellent article de Rob Creighton en 2012 http://spectrum.ieee.org/energy/renewables/the-benefits-of-airborne-wind-energy
Plus de nouvelles depuis
http://www.energykitesystems.net/WindLift/index.html
lundi 21 juillet 2014
Et l'Asie dans tout ça?
L'Asie, notamment la Chine est souvent considéré comme le pays des cerfs-volants. Si de nombreux brevets Chinois sur la récupération d'énergie du vent grâce à des cerfs-volants existent, je n'avais jamais entendu parler de projet.
C'est maintenant chose faite avec ce projet de financement dans le secteur
http://www.connaughtenergy.net/index.php/kite-energy/
Il semble que les investisseurs aient choisi de faire confiance à l'entreprise italienne Kitenrg.
Ce qui est bien, c'est que l'on trouve des vidéos et informations non disponibles sur le site de Kitenrg.
C'est maintenant chose faite avec ce projet de financement dans le secteur
http://www.connaughtenergy.net/index.php/kite-energy/
Il semble que les investisseurs aient choisi de faire confiance à l'entreprise italienne Kitenrg.
Ce qui est bien, c'est que l'on trouve des vidéos et informations non disponibles sur le site de Kitenrg.
Projet de traversé de l'Atlantique en kiteboat
Voici un lien vers un projet de traversé de l'Atlantique en kiteboat (trouvé sur le forum AirborneWindEnergy).
http://www.ilove-the-planet.org/pages/multimedia.php?id=14
http://www.ilove-the-planet.org/pages/multimedia.php?id=14
Un article sur les éoliennes volantes dans edf-pulse
EDF-pulse est un programme de soutien à l'innovation, qui fait de la veille sur de nouvelles solutions et propose des prix :
Les éoliennes volantes intéressent évidemment EDF-pulse...
http://pulse.edf.com/fr/leolienne-volante-bientot-en-orbite
Le projet présenté est celui d'Altaeros qui a pourtant d'importants inconvénients :
Les éoliennes volantes intéressent évidemment EDF-pulse...
http://pulse.edf.com/fr/leolienne-volante-bientot-en-orbite
Le projet présenté est celui d'Altaeros qui a pourtant d'importants inconvénients :
- utilisation de l'hélium, avantageux pour rester en l'air quand il n'y a pas de vent (mais à quoi bon?), mais plus compliqué.
- faible surface balayée (mais stabilité naturelle).
Nouveau projet de pilote auto italien (open-source??)
J'ai retrouvé quelques conversations sur la possibilité de réaliser un drone de kite sur le site diydrones.
D'abord une conversation de 2011 :
http://diydrones.com/forum/topics/diy-drone-power-kite-kitegen-1
Qui m'a amené vers un article pour moi inédit sur Joby Energy :
http://diydrones.com/profiles/blogs/interesting-using-tethered
J'ai également découvert un conversation d'Avril 2014 de différentes personnes envisageant d'utiliser Ardupilot comme base pour un pilote automatique de kite.
https://groups.google.com/forum/#!msg/drones-discuss/8kG5JUiYMoU/2CgNNspn2x4J
A suivre...
D'abord une conversation de 2011 :
http://diydrones.com/forum/topics/diy-drone-power-kite-kitegen-1
Qui m'a amené vers un article pour moi inédit sur Joby Energy :
http://diydrones.com/profiles/blogs/interesting-using-tethered
J'ai également découvert un conversation d'Avril 2014 de différentes personnes envisageant d'utiliser Ardupilot comme base pour un pilote automatique de kite.
https://groups.google.com/forum/#!msg/drones-discuss/8kG5JUiYMoU/2CgNNspn2x4J
A suivre...
Paramoteur
Il y a des liens important entre le monde du cerf-volant et le monde du parapente.
Comme Luc Armant, auteur de l'Aile d'eau, travaillant maintenant chez Ozone et devenu champion de parapente.
Le pendant du cerf-volant automatique est donc le drone à voilure souple, comme ceux de Flying Robot, une entreprise suisse.
Opale paramodels est une entreprise de Boulogne Sur Mer qui conçoit et produit des parapentes radiocommandés, en essayant de reproduire fidèlement les plus grands (jusqu'à avoir une figurine avec des bras articulés).
Les modèles réduits de parapente (à partir de 400 euros environ) peuvent-être utilisées sur des falaises ou avec des ascendances thermiques. Les paramoteurs (à partir de seulement 300 euros) peuvent eux être utilisés en indoor également.
Une petite vidéo vaut mieux qu'un long discours
Comme Luc Armant, auteur de l'Aile d'eau, travaillant maintenant chez Ozone et devenu champion de parapente.
Le pendant du cerf-volant automatique est donc le drone à voilure souple, comme ceux de Flying Robot, une entreprise suisse.
Opale paramodels est une entreprise de Boulogne Sur Mer qui conçoit et produit des parapentes radiocommandés, en essayant de reproduire fidèlement les plus grands (jusqu'à avoir une figurine avec des bras articulés).
Les modèles réduits de parapente (à partir de 400 euros environ) peuvent-être utilisées sur des falaises ou avec des ascendances thermiques. Les paramoteurs (à partir de seulement 300 euros) peuvent eux être utilisés en indoor également.
Une petite vidéo vaut mieux qu'un long discours
mardi 15 juillet 2014
Yoko Tsuno : Les 3 soleils de Vinéa
Plus jeune, je lisais les bandes dessinées de Yoko Tsuno que j'empruntais à la bibliothèque.
On m'a récemment rappelé que l'énergie de la planète Venia venait des cerfs-volants !
On trouve la référence dans "Les 3 soleils de Vinéa", l'album n°6 de la collection des aventures de Yoko Tsuno par Roger Leloup. Ne trouvant pas d'extrait sur internet, j'ai commandé la BD.
On aperçoit d'abord les cerfs-volants page 26
Puis plus d'information sont données page 28 : "ces cerfs-volants dont les rotors chargent les batteries des enfants".
On m'a récemment rappelé que l'énergie de la planète Venia venait des cerfs-volants !
On trouve la référence dans "Les 3 soleils de Vinéa", l'album n°6 de la collection des aventures de Yoko Tsuno par Roger Leloup. Ne trouvant pas d'extrait sur internet, j'ai commandé la BD.
On aperçoit d'abord les cerfs-volants page 26
Puis plus d'information sont données page 28 : "ces cerfs-volants dont les rotors chargent les batteries des enfants".
mardi 1 juillet 2014
Communication radio : suite
La semaine dernière, j'étais dans une impasse face au problème de communication radio entre une IMU en l'air sur le cerf-volant et le sol.
Différentes solutions adaptées aux drones sont listés sur http://wiki.paparazziuav.org/wiki/Modems
La solution simple est d'utiliser un Xbee qui repose sur le protocole zigbee.
Différentes bandes de fréquences, différentes types d'antennes, et différents protocoles existent ce qui ne simplifie pas le choix. Une bonne documentation en français peut être trouvée ici http://jeromeabel.net/fr/ressources/xbee-arduino.
Mael de Stéréolux m'a prêté une paire pour faire des tests.
Des alternatives moins coûteuses existent à base du composant NRF24L01, dont la portée peut-être boosté par une antenne.
Une alternative est évidemment de réaliser la carte soit même pour ceux qui souhaiteraient quelque chose de plus open hardware, comme ce projet de la fabacademy http://fab.cba.mit.edu/content/projects/comm/hello_radio/
Un autre capteur qui pourrait être installé sur le cerf-volant est un anémomètre.
http://forum.arduino.cc/index.php/topic,53569.0.html
Cependant, avant de tester ces solutions, j'ai persévéré dans l'utilisation d'une paire émetteur/récepteur en 433MHz.
J'ai d'abord vérifié le bon fonctionnement de la paire émetteur/récepteur avec la bibliothèque VirtualWire puis avec la bibliothèque Radiohead (fichiers de test ici).
J'ai pu vérifier que d'ajouter la communication à relativement bas débit sur le programme lisant les valeurs de l'IMU engendrait une dépassement de la taille du tampon de l'unité de calcul du MPU6050.
J'ai d'abord testé une solution (http://diydrones.com/forum/topics/i-have-a-hard-time-using-mpu6050) sans succès.
J'ai ensuite cherché à ralentir la fréquence d'envoi des infos de l'IMU en modifiant le fichier MPU6050_6Axis_MotionApps20.h de la bibliothèque.
Et cela fonctionne ! En tout cas tant que l'on limite le nombre de données envoyés. J'arrive pour l'instant à tourner à 10Hz, mais j'aimerais maintenant utiliser une trame binaire pour envoyer les trois angles afin de voir jusqu'où je peux augmenter la fréquence.
A suivre...
Différentes solutions adaptées aux drones sont listés sur http://wiki.paparazziuav.org/wiki/Modems
La solution simple est d'utiliser un Xbee qui repose sur le protocole zigbee.
Différentes bandes de fréquences, différentes types d'antennes, et différents protocoles existent ce qui ne simplifie pas le choix. Une bonne documentation en français peut être trouvée ici http://jeromeabel.net/fr/ressources/xbee-arduino.
Mael de Stéréolux m'a prêté une paire pour faire des tests.
Des alternatives moins coûteuses existent à base du composant NRF24L01, dont la portée peut-être boosté par une antenne.
Une alternative est évidemment de réaliser la carte soit même pour ceux qui souhaiteraient quelque chose de plus open hardware, comme ce projet de la fabacademy http://fab.cba.mit.edu/content/projects/comm/hello_radio/
Un autre capteur qui pourrait être installé sur le cerf-volant est un anémomètre.
http://forum.arduino.cc/index.php/topic,53569.0.html
Cependant, avant de tester ces solutions, j'ai persévéré dans l'utilisation d'une paire émetteur/récepteur en 433MHz.
 |
| Un arduino nano connecté à l'émetteur d'un côté, un arduino uno connecté au récepteur de l'autre côté. |
J'ai d'abord vérifié le bon fonctionnement de la paire émetteur/récepteur avec la bibliothèque VirtualWire puis avec la bibliothèque Radiohead (fichiers de test ici).
J'ai pu vérifier que d'ajouter la communication à relativement bas débit sur le programme lisant les valeurs de l'IMU engendrait une dépassement de la taille du tampon de l'unité de calcul du MPU6050.
J'ai d'abord testé une solution (http://diydrones.com/forum/topics/i-have-a-hard-time-using-mpu6050) sans succès.
J'ai ensuite cherché à ralentir la fréquence d'envoi des infos de l'IMU en modifiant le fichier MPU6050_6Axis_MotionApps20.h de la bibliothèque.
Et cela fonctionne ! En tout cas tant que l'on limite le nombre de données envoyés. J'arrive pour l'instant à tourner à 10Hz, mais j'aimerais maintenant utiliser une trame binaire pour envoyer les trois angles afin de voir jusqu'où je peux augmenter la fréquence.
A suivre...
CV de surveillance : voir et être vu
L'article précédent traitait d'"être vu".
Le cerf-volant permet également de "voir", comme ce kitoon (contraction de kite et balloon désignant un aérostat en forme de cerf-volant) lancé depuis un camion et permettant d'augmenter la portée d'un radar, ou d'une antenne de télécommunication.
Le cerf-volant permet également de "voir", comme ce kitoon (contraction de kite et balloon désignant un aérostat en forme de cerf-volant) lancé depuis un camion et permettant d'augmenter la portée d'un radar, ou d'une antenne de télécommunication.
http://www.globalnearspace.
CV de signalisation
C'est encore Yves Parlier que l'on retrouve dans cette vidéo à 1'25. Un petit cerf-volant auto-stable est accroché à un flotteur muni d'une ancre flottante, le tout permettant de faire un repère visible de loin.
Voici également une discussion sur le sujet http://photocerfvolant.free.fr/phpBB2/viewtopic.php?f=8&t=299
Voici également une discussion sur le sujet http://photocerfvolant.free.fr/phpBB2/viewtopic.php?f=8&t=299
Réglementation aérienne
Ce matin je me suis intéressé à la réglementation aérienne, en commençant par un peu de bibliographie, puis en contactant la DGAC.
Un cerf-volant est un "aéronef" : "tout appareil capable de s'élever ou de circuler dans les airs."
Un point d'entrée sur le sujet est le site du ministère du développement durable
L'arrêté du 11 avril 2012 relatif à la conception des aéronefs civils qui circulent sans aucune personne à bord ne s'applique pas aux cerfs-volant.
Sur Wikipedia :
Sur Miztral :
"On admet généralement que la pratique de cette activité ne pose pas de problème particulier des lors qu'elle se déroule à plus de 10 Km d'un aérodrome et à une hauteur inférieure à 150 mètres."
"150 m c'est le plafond mini aéronautique./ - 100 m c'est le plafond maxi pour un aéronef non habité, donc pour un cerf-volant."
"De plus, les avions de l'armée peuvent voler sous le plafond des 100 mètres en zone cotière, ou sur certaines zones dont ils ont les autorisations."
J'ai ensuite contacté la DGAC Ouest par téléphone.
J'ai pu avoir une personne compétente sur le sujet qui a complété ces informations
En dessous de 50m (du sol?)
Normalement le vol en dessous de 50m est autorisé partout sauf à proximité des aéroports. Ces zones sont inaccessibles sur les aéroports publics, mais il y a des aérodromes privés, dont les positions ne sont pas rendues publiques.
Pour s'assurer de la possibilité de voler quelque part il faut donc envoyer un courrier avec la position du lieu pour que la DGAC vérifie.
De 50 à 150m
Il n'y a pas de problèmes par rapport à l'aviation civile, mais il peut y avoir des problèmes avec l'aviation militaire.
Une demande est donc à effectuer directement auprès de la DIRCAM.
Les militaires n'aiment en général pas ces demandes (cas proche du treuillage pour planeur).
Au delà de 150m
Il faut contacter la DGAC comme point d'entrée (qui transmettra aux militaires).
Il faut avoir des moyens de signalisation lumineuse (décrits dans un arrêté de 2008). Cela représente un poids supplémentaire, de l'énergie supplémentaire, mais également une nuisance visuelle.
Dans les Pays de Loire ?
Il n'y a pas de zones d'essais dédiées dans la région Pays-De-Loire.
La Mayenne est fortement déconseillée (couverte à 90% par un espace aérien militaire).
Quelques zones spéciales à noter cependant :
Un cerf-volant est un "aéronef" : "tout appareil capable de s'élever ou de circuler dans les airs."
Un point d'entrée sur le sujet est le site du ministère du développement durable
L'arrêté du 11 avril 2012 relatif à la conception des aéronefs civils qui circulent sans aucune personne à bord ne s'applique pas aux cerfs-volant.
Sur Wikipedia :
- Sur le territoire français, (sauf zones interdites aux vols) l'ascension du cerf-volant s'effectue librement en dessous d'une hauteur de 50 mètres. Pour une hauteur comprise entre 50 et 150 mètres une autorisation spécifique peut être accordée par le directeur de l'aviation civile, (plusieurs câbles de retenue du cerf-volant peuvent être demandés).
- Au-delà de 150 mètres, l'ascension du cerf-volant fait l'objet d'un plan de vol. Le cerf-volant fait partie des aéronefs civils qui ne transportent aucune personne à bord12 avec des feux règlementaires des aéronefs. Les aéronefs captifs et leur câble de retenue doivent porter des feux correspondant au balisage d’un obstacle artificiel de même hauteur13.
Sur Miztral :
"On admet généralement que la pratique de cette activité ne pose pas de problème particulier des lors qu'elle se déroule à plus de 10 Km d'un aérodrome et à une hauteur inférieure à 150 mètres."
"150 m c'est le plafond mini aéronautique./ - 100 m c'est le plafond maxi pour un aéronef non habité, donc pour un cerf-volant."
"De plus, les avions de l'armée peuvent voler sous le plafond des 100 mètres en zone cotière, ou sur certaines zones dont ils ont les autorisations."
J'ai ensuite contacté la DGAC Ouest par téléphone.
J'ai pu avoir une personne compétente sur le sujet qui a complété ces informations
En dessous de 50m (du sol?)
Normalement le vol en dessous de 50m est autorisé partout sauf à proximité des aéroports. Ces zones sont inaccessibles sur les aéroports publics, mais il y a des aérodromes privés, dont les positions ne sont pas rendues publiques.
Pour s'assurer de la possibilité de voler quelque part il faut donc envoyer un courrier avec la position du lieu pour que la DGAC vérifie.
De 50 à 150m
Il n'y a pas de problèmes par rapport à l'aviation civile, mais il peut y avoir des problèmes avec l'aviation militaire.
Une demande est donc à effectuer directement auprès de la DIRCAM.
Les militaires n'aiment en général pas ces demandes (cas proche du treuillage pour planeur).
Au delà de 150m
Il faut contacter la DGAC comme point d'entrée (qui transmettra aux militaires).
Il faut avoir des moyens de signalisation lumineuse (décrits dans un arrêté de 2008). Cela représente un poids supplémentaire, de l'énergie supplémentaire, mais également une nuisance visuelle.
Dans les Pays de Loire ?
Il n'y a pas de zones d'essais dédiées dans la région Pays-De-Loire.
La Mayenne est fortement déconseillée (couverte à 90% par un espace aérien militaire).
Quelques zones spéciales à noter cependant :
- A proximité des éoliennes, il est possible de voler sans problème tant que l'on est moins haut. Par contre, il se peut qu'il y ait une réglementation locale spécifique pour le cerf-volant à proximité des éoliennes.
- Il existe une zone (T8?) au-dessus d'un site industriel de Donges où le plafond aérien est relevé.
vendredi 27 juin 2014
Premières navigations des Birdkites
Germain Belz et Armand Torre (innov'kiteboat) ont diffusé les premières vidéos des essais sur l'eau des dernières Birdkites, les ailes de traction autostables qu'ils testent, développent, et fabriquent de A à Z (Germain allant jusqu'à transformer sa chambre en découpe laser géante!).
Un énorme travail entamé par Armand qui représente une partie phare du projet de traversée de l'Atlantique de Germain
Sur une vidéo l'aile est utilisée sur un habitable pré-existant, et peut-être utilisée en complément des voiles une fois lancée.
Cette vidéo permet de se rendre compte à quel point l'aile est stable, même lorsqu'elle est plus proche de l'eau.
Sur l'autre vidéo, Armand teste l'aile sur un kiteboat basé sur une coque de catamaran.
A partager sans modération
Un énorme travail entamé par Armand qui représente une partie phare du projet de traversée de l'Atlantique de Germain
Sur une vidéo l'aile est utilisée sur un habitable pré-existant, et peut-être utilisée en complément des voiles une fois lancée.
Cette vidéo permet de se rendre compte à quel point l'aile est stable, même lorsqu'elle est plus proche de l'eau.
Sur l'autre vidéo, Armand teste l'aile sur un kiteboat basé sur une coque de catamaran.
A partager sans modération
mercredi 25 juin 2014
IMU
Pour rappel, une IMU est une centrale inertielle, c'est à dire un capteur composé d'un accéléromètre et d'un gyroscope et de capacités de calcul pour déterminer son orientation (éventuellement sa position).
L'objectif est ici de monter ce composant directement sur ou à proximité du cerf-volant, pour avoir une image de la position et de l'orientation du cerf-volant.
Si l'on fixe le capteur directement sur le cerf-volant, la mesure dépendra du border-choquer et du différentiel de longueur entre les arrières.
Si l'on fixe le capteur sur une ligne seulement, l'information de rotation autour de l'axe des lignes ne sera pas mesurable.
La bonne solution serait donc de fixer le capteur sur un support reliant les deux arrières
Je cherche à utiliser le magnétomètre pour avoir l’azimut des lignes du kite, l'accéléromètre pour retrouver l'orientation par rapport à l'axe des lignes, ainsi que l'élévation.
Le gyroscope permet d'avoir une mesure qui n'est pas (moins) perturbées par les accélérations qui sont importantes au niveau du cerf-volant.
Une communication radio est ensuite nécessaire pour renvoyer les résultats vers la station au sol. Une carte arduino nano sert d'interface entre les deux, le tout alimenté par une batterie dans un premier temps, peut-être par une micro-éolienne ensuite.
Je n'abandonne pas l'idée du téléphone portable et de la caméra, entre les lignes avant, au niveau du sol, mais cela permettra en tout cas de faire une comparaison des différentes solutions (coût, précision, latence).
J'ai repris le travail de Lucas sur l'IMU Drotek.
Il m'a tout d'abord fallu installer toute une série de bibliothèque et les installer, ce que je ne détaillerai pas ici.
http://www.pjrc.com/teensy/td_libs_MsTimer2.html
http://www.airspayce.com/mikem/arduino/VirtualWire/ version 1.27
http://www.i2cdevlib.com/usage
Cette dernière bibliothèque contient des exemples pour tester la communication avec le protocole I2C avec les composants de l'IMU.
Parmi les exemples, un ne fonctionnait pas (gy_521_send_serial), mais le MPU6050_DMP6 qui fait un peu de fusion de données renvoyait des valeurs variables.
J'ai ainsi pu vérifier la réception de données depuis le MPU6050 (accéléromètre et gyroscope), ainsi que des capteurs donnant la température et la pression (de laquelle peut-être calculée la pression).
Un exemple (avec Processing) permet de visualiser la qualité des mouvements mesurés par l'IMU. Mais cet exemple ne fonctionnait pas très bien. J'ai trouvé une version améliorée
http://www.geekmomprojects.com/mpu-6050-dmp-data-from-i2cdevlib/
On constate que la communication ne se passe pas très bien lorsque le "baud rate" est maximum, ni quand on le diminue (erreur "FIFO overflow" qui se traduit pas des discontinuités dans les mouvements).
Il ne semble pas y avoir de solutions à ce problème.
En ce qui concerne le capteur de pression, la pression semble biaisée (très faible), ce qui a pour effet de donner après calcul une hauteur de près de 9000m... Mais cela n'est pas forcément gênant s'il s'agit seulement d'un problème de calibration.
Deux difficultés restaient à résoudre :
Pour la liaison radio, je disposais d'une paire émetteur récepteur.
La bibliothèque VirtualWire avait permis à Lucas de faire quelques tests au baudrate spécifié (4800bps, voire 9600bps).
https://www.pjrc.com/teensy/td_libs_VirtualWire.html
Malheureusement comme expliqué précédemment la communication à cette vitesse n'est pas possible, car c'est trop lent.
A suivre
L'objectif est ici de monter ce composant directement sur ou à proximité du cerf-volant, pour avoir une image de la position et de l'orientation du cerf-volant.
Si l'on fixe le capteur directement sur le cerf-volant, la mesure dépendra du border-choquer et du différentiel de longueur entre les arrières.
Si l'on fixe le capteur sur une ligne seulement, l'information de rotation autour de l'axe des lignes ne sera pas mesurable.
La bonne solution serait donc de fixer le capteur sur un support reliant les deux arrières
Je cherche à utiliser le magnétomètre pour avoir l’azimut des lignes du kite, l'accéléromètre pour retrouver l'orientation par rapport à l'axe des lignes, ainsi que l'élévation.
Le gyroscope permet d'avoir une mesure qui n'est pas (moins) perturbées par les accélérations qui sont importantes au niveau du cerf-volant.
Une communication radio est ensuite nécessaire pour renvoyer les résultats vers la station au sol. Une carte arduino nano sert d'interface entre les deux, le tout alimenté par une batterie dans un premier temps, peut-être par une micro-éolienne ensuite.
Je n'abandonne pas l'idée du téléphone portable et de la caméra, entre les lignes avant, au niveau du sol, mais cela permettra en tout cas de faire une comparaison des différentes solutions (coût, précision, latence).
J'ai repris le travail de Lucas sur l'IMU Drotek.
 |
| Arduino Nano et IMU 10dof Drotek. Notez la connexion pour les interruptions, non détaillée sur le site de Drotek. |
Il m'a tout d'abord fallu installer toute une série de bibliothèque et les installer, ce que je ne détaillerai pas ici.
http://www.pjrc.com/teensy/td_libs_MsTimer2.html
http://www.airspayce.com/mikem/arduino/VirtualWire/ version 1.27
http://www.i2cdevlib.com/usage
Cette dernière bibliothèque contient des exemples pour tester la communication avec le protocole I2C avec les composants de l'IMU.
Parmi les exemples, un ne fonctionnait pas (gy_521_send_serial), mais le MPU6050_DMP6 qui fait un peu de fusion de données renvoyait des valeurs variables.
J'ai ainsi pu vérifier la réception de données depuis le MPU6050 (accéléromètre et gyroscope), ainsi que des capteurs donnant la température et la pression (de laquelle peut-être calculée la pression).
Un exemple (avec Processing) permet de visualiser la qualité des mouvements mesurés par l'IMU. Mais cet exemple ne fonctionnait pas très bien. J'ai trouvé une version améliorée
http://www.geekmomprojects.com/mpu-6050-dmp-data-from-i2cdevlib/
On constate que la communication ne se passe pas très bien lorsque le "baud rate" est maximum, ni quand on le diminue (erreur "FIFO overflow" qui se traduit pas des discontinuités dans les mouvements).
Il ne semble pas y avoir de solutions à ce problème.
En ce qui concerne le capteur de pression, la pression semble biaisée (très faible), ce qui a pour effet de donner après calcul une hauteur de près de 9000m... Mais cela n'est pas forcément gênant s'il s'agit seulement d'un problème de calibration.
Deux difficultés restaient à résoudre :
- réussir à lire les données du magnétomètre qui n'était pas directement relié à l'arduino.
- envoyer les données vers le sol en liaison radio
Pour la liaison radio, je disposais d'une paire émetteur récepteur.
La bibliothèque VirtualWire avait permis à Lucas de faire quelques tests au baudrate spécifié (4800bps, voire 9600bps).
https://www.pjrc.com/teensy/td_libs_VirtualWire.html
Malheureusement comme expliqué précédemment la communication à cette vitesse n'est pas possible, car c'est trop lent.
A suivre
lundi 23 juin 2014
Offre d'emploi : TwingTec
Twingtec, la startup suisse recherche un ingénieur en automatique.
Leur solution se base sur ardupilots d'après DIno que j'avais rencontré à l'AWEC2013 à Berlin
Mavlink
Je m'intéresse en ce moment à Mavlink. Il s'agit d'un protocole de communication développé spécialement pour les drones aériens par l'ETH de Zurich et sous licence LGPL.
Mavlink semble être devenu le standard dans le domaine, et serait un protocole à maîtriser, pour éventuellement un jour remplacer le protocole NMEA (avec trames "propriétaires) qui est pour l'instant utilisé sur le projet robokite.
Minesto dans le courant de Floride
Minesto, et ses cerfs-plongeants s'intéresse au courant de Floride
http://www.theengineer.co.uk/energy-and-environment/news/gulf-stream-tidal-energy-to-be-studied/1018803.article#ixzz35UpkIAv0
En prime, voici une petite vidéo d'une aile monopeau (sans boudin) décollant de l'eau sans difficultés
(liens trouvés sur le forum airbornewindenergy)
http://www.theengineer.co.uk/energy-and-environment/news/gulf-stream-tidal-energy-to-be-studied/1018803.article#ixzz35UpkIAv0
En prime, voici une petite vidéo d'une aile monopeau (sans boudin) décollant de l'eau sans difficultés
(liens trouvés sur le forum airbornewindenergy)
dimanche 22 juin 2014
samedi 21 juin 2014
Enerkite est dans le vent
Après un passage à la télévision française, le projet enerkite est maintenant bien placé dans les recherches googles sur le sujet du pilotage automatique des kites.
J'ai notamment trouvé un très bon article sur la partie française de Faulhaber group, qui fabrique les moteurs servant à tendre le câble (car les gros treuils ne sont pas assez rapides). Pour moi tout cela est mal pensé, mais l'article présente également les avantages de l'éolien volant de manière générale.
http://www.faulhaber.com/sprache3/n860555/n.html
J'ai notamment trouvé un très bon article sur la partie française de Faulhaber group, qui fabrique les moteurs servant à tendre le câble (car les gros treuils ne sont pas assez rapides). Pour moi tout cela est mal pensé, mais l'article présente également les avantages de l'éolien volant de manière générale.
http://www.faulhaber.com/sprache3/n860555/n.html
mercredi 18 juin 2014
La clé de voute de Gurval
Gurval Lego, du projet Dared, avait parlé de sa nouvelle barre de kite inspirée de la cage Darlet dans un commentaire sur un post sur la cage Darlet.
Après le teaser au mois de Janvier , les premières photos au mois d'Avril, la vidéo est arrivée au mois de Mai.
Il faut avouer que cela paraît assez révolutionnaire! Et simple (beau?).
Et ce l'est. Si le système de barre rappelle en fait un simple T, utilisé par des cerfs-volistes (comme la croix d'attelle sur une marionnette), je ne l'avais jamais vu sur des grands cerfs-volants avec l'avant fixé sur un point fixe.
Cela fonctionne bien avec une "barre" raccourcie et des lignes assez courtes, et le pilotage semble plus aisé à une main
Cela m'amène à me poser quelques questions.
Cela amène-t-il de la stabilité?
Quel est le phénomène physique assurant le pilotage (un ou plusieurs)?
Y-a-t-il une différence fondamentale avec une barre classique?
Que se passe-t-il si l'on lâche la barre?
Cela présente-t-il un intérêt pour faciliter l'automatisation?
Quelles évolutions peut-on imaginer?
Après le teaser au mois de Janvier , les premières photos au mois d'Avril, la vidéo est arrivée au mois de Mai.
Il faut avouer que cela paraît assez révolutionnaire! Et simple (beau?).
Et ce l'est. Si le système de barre rappelle en fait un simple T, utilisé par des cerfs-volistes (comme la croix d'attelle sur une marionnette), je ne l'avais jamais vu sur des grands cerfs-volants avec l'avant fixé sur un point fixe.
Cela fonctionne bien avec une "barre" raccourcie et des lignes assez courtes, et le pilotage semble plus aisé à une main
Cela m'amène à me poser quelques questions.
Cela amène-t-il de la stabilité?
Quel est le phénomène physique assurant le pilotage (un ou plusieurs)?
Y-a-t-il une différence fondamentale avec une barre classique?
Que se passe-t-il si l'on lâche la barre?
Cela présente-t-il un intérêt pour faciliter l'automatisation?
Quelles évolutions peut-on imaginer?