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
vendredi 27 juin 2014
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
Inscription à :
Articles (Atom)