Yves Parlier qui était il y a quelques jours aux Pays-Bas pour la conférence de NRSail se lance ces jours-ci sur l'Atlantique pour convoyer le trimaran de Lalou Roucayrol jusqu'aux Canaries où il sera rematé. Et devinez quelle est la propulsion choisie...
dimanche 30 mars 2014
jeudi 27 mars 2014
Modifications sur la plateforme
(Les modifications présentées ci-dessous avaient été réalisées la semaine dernière avant les tests à St-Brévin)
Remplacement de l'axe en bois par un axe en métal
 |
| Le bout de la mèche qui s'est usé jusqu'à casser |
 |
| Ponçage de l'axe en le faisant tourner contre une feuille de papier à l'eau P320 pour réduire le diamètre et enfiler les roulements |
 |
| Quelques coups de marteau pour mettre les roulements en position |
 |
| Découpage de la mèche pour réaliser un méplat |
 |
| Méplat (artisanal) |
 | |||||
| L'axe après montage sur le treuil (et câle) |
Boîte de dérivation
 |
| Oups, petit problème avec la breadboard en essayant de la repositionner après l'avoir collé une première fois. |
 |
| Arduino, Sabertooth et breadboard dans la boîte de dérivation (un poil petit pour ajouter le raspberry). Une plaque de 2mm sert de support (enfoncée dans le rail au fond de la boîte). |
 |
| La boîte de dérivation montée |
Installation de joint étanche et démontable sur la boîte de dérivation
 |
| Boîte de dérivation avec joint plastique enlevé. |
 |
| Joint sur un goulot de bouteille plastique |
 | |||
| Connexions démontables |
Sangle et balance
Aujourd'hui à PlateformeC, j'ai essayé d'imprimer des boucles de
réglages de sangle pour améliorer l'installation du capteur de barre (je
n'en ai pas trouvé dans les magasins de bricolage ou de couture). J'ai
utilisé un fichier trouvé sur thingiverse.
Malheureusement lors de ma première impression, la plaque support en
verre de l'imprimante 3D a complètement glissé. Cela était suffisant,
mais j'ai préféré relancer une impression. Le rendu n'était pas très
joli non plus, mais cela était suffisant.
J'ai également retravaillé sur le système de mesure de tension dans les lignes, en modifiant la partie mécanique. Pour cela j'ai d'abord défait l'assemblage que j'avais déjà constitué (à la glu), j'ai ensuite percé la jauge de contrainte une première fois, au bout de la jauge (trou de gauche sur la photo ci-dessous). Cependant le rivet en dessous empêchait de passer un boulon, même très fin. J'ai donc dû refaire un trou, décalé par rapport au rivet (trou de droite). J'ai ensuite monté la jauge de contrainte sur une équerre métallique (avec un boulon de 10x3mm, un écrou est des rondelles pour que le boulon ne dépasse pas de l'écrou.)
Voici le résultat (après amélioration du câblage, et redécoupage de la planche également).
J'ai également retravaillé sur le système de mesure de tension dans les lignes, en modifiant la partie mécanique. Pour cela j'ai d'abord défait l'assemblage que j'avais déjà constitué (à la glu), j'ai ensuite percé la jauge de contrainte une première fois, au bout de la jauge (trou de gauche sur la photo ci-dessous). Cependant le rivet en dessous empêchait de passer un boulon, même très fin. J'ai donc dû refaire un trou, décalé par rapport au rivet (trou de droite). J'ai ensuite monté la jauge de contrainte sur une équerre métallique (avec un boulon de 10x3mm, un écrou est des rondelles pour que le boulon ne dépasse pas de l'écrou.)
Voici le résultat (après amélioration du câblage, et redécoupage de la planche également).
Sujet master norvégien sur la propulsion maritime
Voici le rapport de Kristian Malde Gilje qui s'est intéressé à la propulsion de grands navires par cerfs-volants, en extrapolant notamment les données des ailes de Makani Power. Je n'ai pas encore eu le temps de le lire, donc tous les commentaires sont les bienvenus !
http://www.diva-portal.org/smash/get/diva2:646800/FULLTEXT01.pdf
http://www.diva-portal.org/smash/get/diva2:646800/FULLTEXT01.pdf
Veille vidéo
Voici une petite sélection de vidéo sur le sujet des kites automatiques, des kiteboats, ou des drones voiliers.
Une vidéo simple mais avec des schémas à la main rappelant les différents principes envisagés pour transformer l'énergie du vent en électricité avec un cerf-volant, puis l'utilisation d'une kinect pour un apprentissage par l'ordinateur du pilotage (demo du concept).
Une vidéo didactique également, de TU Delft
La dernière vidéo de TU Delft
La dernière vidéo de kiteboat project
Un projet de drone voilier
Saildrone - Autonomous circumnavigation of Farallon islands from Richard Jenkins on Vimeo.
Une vidéo simple mais avec des schémas à la main rappelant les différents principes envisagés pour transformer l'énergie du vent en électricité avec un cerf-volant, puis l'utilisation d'une kinect pour un apprentissage par l'ordinateur du pilotage (demo du concept).
Une vidéo didactique également, de TU Delft
La dernière vidéo de TU Delft
La dernière vidéo de kiteboat project
Un projet de drone voilier
Saildrone - Autonomous circumnavigation of Farallon islands from Richard Jenkins on Vimeo.
samedi 22 mars 2014
Test sur la plage
Hier les conditions parfaites pour des essais étaient réunies.
Température clémente, vend d'ouest d'une dizaine de nœud, ensoleillé.
Nous sommes donc parti avec Jean-Pierre, direction Saint-Brévin (merci à la famille Labat pour le prêt de la voiture).
Nous sommes allés au parking du Pointeau (club de voile).
Des chars à voile occupant une bonne partie de la plage, nous avons commencé à nous installer plus vers l'eau (avec la marée montante...). Nous nous sommes finalement décalés plus vers le sable sec après le départ des chars à voile.
L'installation à été un peu laborieuse car j'avais changé les lignes bâbord et tribord, Il fallait donc refaire un nombre de tours suffisant (je n'avais pas compté...) et replacer les butées mécaniques. Si cela est assez facile à faire sur le banc de test, c'est assez compliqué sur le sable lorsque les lignes ne sont pas tendues. Si les butées sont trop proches, on ne peut pas tirer à fond d'un côté. Si les butées sont trop éloignées, on risque de tirer de manière trop importante et de casser les capteurs, d'avoir du mou dans l'autre ligne.
Jean-Pierre s'est chargé d'enterrer un grand sac de course dans le sable, tout en passant une sangle autour. C'était un peu léger, mais j'avais oublié de prendre une pelle et on avait toujours la possibilité de se mettre sur la planche.
Nous avons d'abord testé l'électronique (avec le raspberry et pas d'ordinateur autre), cela fonctionnait.
Nous avons gonflé l'aile (6m2) et vérifié qu'aile volait bien. Au zénith elle était presque autostable, mais avait une tendance à décrocher un peu et à repartir en arrière dans la fenêtre, puis à redevenir puissante tout d'un coup.
L'électronique ne fonctionnait plus (était-ce la batterie utilisée pour le raspberry? Dur à dire car le voyant n'était plus visible dans la lumière du jour). J'ai donc finalement sorti le PC (j'avais pris une table pliante, pratique).
Le problème semblait venir de l'arduino, qui des fois se bloque pour une raison inconnue. Un rechargement du programme règle le problème.
Nous avons finalement lancé le cerf-volant avec l'ensemble connecté. Le réglage de la sangle sur la ligne centrale a permis de passer du contrôle manuel au contrôle joystick. Malheureusement, la butée sur la direction était trop proche et le cerf-volant est parti sur le bord de la fenêtre (à droite) alors que l'on tirait à fond vers la gauche. J'ai essayé de courir pour rattraper l'aile pour la poser et régler, mais elle a fini par repartir en arrière dans la fenêtre en arrivant proche du sol où il y avait moins de vent. J'ai raté l'aile et elle est repartie pleine fenêtre...
Elle est tombée une fois, est repartie, a arrachée son ancre, en entraînant la plate-forme (je n'avais pas encore eu le temps de revenir pour déclencher le largueur).
Heureusement, malgré les efforts important il n'y a pas eu de casse, sauf au niveau d'un "fusible" sur le câble du capteur de barre, ou le bout de scotch fusible a arraché l'un des 6 fils de connexions (les autres se déconnectant normalement).
Après rangement du matos, nous avons fait un petit débrief.
L'erreur de base est d'avoir refait les réglages sur la plage, dans un environnement difficile. Cependant les réglages étaient à mon avis assez proches de ceux testés à PlateformeC où je n'allais pas jusqu'à mettre la barre à 90°, ce qui semble pourtant nécessaire pour maîtriser le cerf-volant, mais difficile sur cette barre.
Un autre problème est que la ligne centrale n'était pas calée par rapport à la plate-forme, ce qui fait que ce réglage aurait de toute manière été susceptible de changer dans le transport.
Au niveau de notre réaction, je n'aurai pas dû partir vers l'aile, mais reprendre le contrôle en manuel et assurer (cela aurait dû être le premier test). Jean-Pierre ne connaissait en effet pas assez bien l'aile et le système pour reprendre le contrôle quand j'ai lâché le joystick. De manière plus générale, j'aurai dû refaire une présentation plus générale du système, de l'utilisation de la sangle, de l'utilisation du largueur, ... Mais nous étions un peu dans la précipitation avec notamment la contrainte de la mer qui montait et le temps perdu à refaire des réglages.
L'ancrage était suffisant pour un vol en bord de fenêtre, mais évidemment trop léger (même si il a bien tenu) pour un passage en pleine fenêtre.
Un autre problème de l'ancrage, est que le point d'ancrage de la planche était trop haut. La planche se retrouvait du coup un peu en l'air, ce qui n'était pas pratique pour se mettre dessus et de manière plus générale pour trouver une position confortable pour piloter (un couvercle solide sur lequel on puisse marcher serait un plus).
La solution des sacs semble assez bonne mais il en faut plus, plus profond, et avec un système de sangle permettant de tirer pour fixer la planche au sol. Pour réaliser tout cela, c'est surtout une pelle qui nous manquait.
Il faudra également revoir le "fusible" au niveau du capteur qui doit fonctionner sans dégât dans le cas "normal" d'un largage.
Nous avons également réfléchi à une check list pour de futurs tests.
Check list
En conclusion, ces tests nous ont permis de vérifier le fonctionnement de la plate-forme en extérieur (batteries, etc) et sa robustesse globale et d'identifier les problèmes à résoudre avant de nouveaux tests.
Température clémente, vend d'ouest d'une dizaine de nœud, ensoleillé.
Nous sommes donc parti avec Jean-Pierre, direction Saint-Brévin (merci à la famille Labat pour le prêt de la voiture).
Nous sommes allés au parking du Pointeau (club de voile).
Des chars à voile occupant une bonne partie de la plage, nous avons commencé à nous installer plus vers l'eau (avec la marée montante...). Nous nous sommes finalement décalés plus vers le sable sec après le départ des chars à voile.
L'installation à été un peu laborieuse car j'avais changé les lignes bâbord et tribord, Il fallait donc refaire un nombre de tours suffisant (je n'avais pas compté...) et replacer les butées mécaniques. Si cela est assez facile à faire sur le banc de test, c'est assez compliqué sur le sable lorsque les lignes ne sont pas tendues. Si les butées sont trop proches, on ne peut pas tirer à fond d'un côté. Si les butées sont trop éloignées, on risque de tirer de manière trop importante et de casser les capteurs, d'avoir du mou dans l'autre ligne.
Jean-Pierre s'est chargé d'enterrer un grand sac de course dans le sable, tout en passant une sangle autour. C'était un peu léger, mais j'avais oublié de prendre une pelle et on avait toujours la possibilité de se mettre sur la planche.
Nous avons d'abord testé l'électronique (avec le raspberry et pas d'ordinateur autre), cela fonctionnait.
Nous avons gonflé l'aile (6m2) et vérifié qu'aile volait bien. Au zénith elle était presque autostable, mais avait une tendance à décrocher un peu et à repartir en arrière dans la fenêtre, puis à redevenir puissante tout d'un coup.
L'électronique ne fonctionnait plus (était-ce la batterie utilisée pour le raspberry? Dur à dire car le voyant n'était plus visible dans la lumière du jour). J'ai donc finalement sorti le PC (j'avais pris une table pliante, pratique).
Le problème semblait venir de l'arduino, qui des fois se bloque pour une raison inconnue. Un rechargement du programme règle le problème.
Nous avons finalement lancé le cerf-volant avec l'ensemble connecté. Le réglage de la sangle sur la ligne centrale a permis de passer du contrôle manuel au contrôle joystick. Malheureusement, la butée sur la direction était trop proche et le cerf-volant est parti sur le bord de la fenêtre (à droite) alors que l'on tirait à fond vers la gauche. J'ai essayé de courir pour rattraper l'aile pour la poser et régler, mais elle a fini par repartir en arrière dans la fenêtre en arrivant proche du sol où il y avait moins de vent. J'ai raté l'aile et elle est repartie pleine fenêtre...
Elle est tombée une fois, est repartie, a arrachée son ancre, en entraînant la plate-forme (je n'avais pas encore eu le temps de revenir pour déclencher le largueur).
Heureusement, malgré les efforts important il n'y a pas eu de casse, sauf au niveau d'un "fusible" sur le câble du capteur de barre, ou le bout de scotch fusible a arraché l'un des 6 fils de connexions (les autres se déconnectant normalement).
Après rangement du matos, nous avons fait un petit débrief.
L'erreur de base est d'avoir refait les réglages sur la plage, dans un environnement difficile. Cependant les réglages étaient à mon avis assez proches de ceux testés à PlateformeC où je n'allais pas jusqu'à mettre la barre à 90°, ce qui semble pourtant nécessaire pour maîtriser le cerf-volant, mais difficile sur cette barre.
Un autre problème est que la ligne centrale n'était pas calée par rapport à la plate-forme, ce qui fait que ce réglage aurait de toute manière été susceptible de changer dans le transport.
Au niveau de notre réaction, je n'aurai pas dû partir vers l'aile, mais reprendre le contrôle en manuel et assurer (cela aurait dû être le premier test). Jean-Pierre ne connaissait en effet pas assez bien l'aile et le système pour reprendre le contrôle quand j'ai lâché le joystick. De manière plus générale, j'aurai dû refaire une présentation plus générale du système, de l'utilisation de la sangle, de l'utilisation du largueur, ... Mais nous étions un peu dans la précipitation avec notamment la contrainte de la mer qui montait et le temps perdu à refaire des réglages.
L'ancrage était suffisant pour un vol en bord de fenêtre, mais évidemment trop léger (même si il a bien tenu) pour un passage en pleine fenêtre.
Un autre problème de l'ancrage, est que le point d'ancrage de la planche était trop haut. La planche se retrouvait du coup un peu en l'air, ce qui n'était pas pratique pour se mettre dessus et de manière plus générale pour trouver une position confortable pour piloter (un couvercle solide sur lequel on puisse marcher serait un plus).
La solution des sacs semble assez bonne mais il en faut plus, plus profond, et avec un système de sangle permettant de tirer pour fixer la planche au sol. Pour réaliser tout cela, c'est surtout une pelle qui nous manquait.
Il faudra également revoir le "fusible" au niveau du capteur qui doit fonctionner sans dégât dans le cas "normal" d'un largage.
Nous avons également réfléchi à une check list pour de futurs tests.
Check list
- Pelle + sacs + sangles
- Gants
- Lunette de soleil
- Eau
- Pompe
- Table + paravent
- Chariot
En conclusion, ces tests nous ont permis de vérifier le fonctionnement de la plate-forme en extérieur (batteries, etc) et sa robustesse globale et d'identifier les problèmes à résoudre avant de nouveaux tests.
Point sur les conventions
Tension positive : on visse, rotation dans le sens horaire
Pour le bordé-choqué, on visse pour border. Etant donné la position de la visseuse, le fil doit donc s'enrouler sur la mèche en arrivant par au-dessus.
Pour le babord-tribord, on visse pour tirer à droite. Cela dépend évidemment de la manière dont sont fixés les lignes.
Le fil vert doit donc s'enrouler en arrivant par en dessous, le fil orange en arrivant par au dessus (dépend évidemment de la position de la poulis
Pour rester cohérent, on choisira donc rotation dans le sens horaire correspondant à une augmentation de la valeur du capteur d'angle de barre, ce qui est le cas sur le capteur avec le rouge à gauche lorsqu'on regarde le potard d'au dessus, les connections vers le bas. Cela implique une inversion de signe sur la sortie du PID, ce qui sera ajusté.
Au niveau de l'ordre des moteurs, le moteur servant pour le bordé-choqué était jusqu'à présent le 1.
Cependant, il serait possible de n'utiliser que le moteur de la direction sur un cerf-volant, et je vais donc changer cette convention.
Au niveau du joystick, le positif est vers la droite, et vers le bas, ce qui correspond par chance également au niveau des conventions choisies.
Pour le bordé-choqué, on visse pour border. Etant donné la position de la visseuse, le fil doit donc s'enrouler sur la mèche en arrivant par au-dessus.
Pour le babord-tribord, on visse pour tirer à droite. Cela dépend évidemment de la manière dont sont fixés les lignes.
Le fil vert doit donc s'enrouler en arrivant par en dessous, le fil orange en arrivant par au dessus (dépend évidemment de la position de la poulis
Pour rester cohérent, on choisira donc rotation dans le sens horaire correspondant à une augmentation de la valeur du capteur d'angle de barre, ce qui est le cas sur le capteur avec le rouge à gauche lorsqu'on regarde le potard d'au dessus, les connections vers le bas. Cela implique une inversion de signe sur la sortie du PID, ce qui sera ajusté.
Au niveau de l'ordre des moteurs, le moteur servant pour le bordé-choqué était jusqu'à présent le 1.
Cependant, il serait possible de n'utiliser que le moteur de la direction sur un cerf-volant, et je vais donc changer cette convention.
Au niveau du joystick, le positif est vers la droite, et vers le bas, ce qui correspond par chance également au niveau des conventions choisies.
jeudi 20 mars 2014
La nuit porte (bon?) conseil
La nuit, les cerveaux ne s'arrêtent pas de travailler.
Voici mes réflexions de la nuit. Une de mes préoccupations était d'avoir une version réduite du système de pilotage pour un cerf-volant 2 lignes (actuellement la ligne centrale me sert de référence pour l'angle de barre).
Mon autre préoccupation était de rendre plus robuste le capteur linéaire, des dérives lentes étant encore observées.
Une première idée a été d'utiliser le capteur linéaire pour mesurer le différentiel de longueur des deux lignes (sur un cerf-volant à 2 lignes, sans barre)
Une autre idée est de remplacer le capteur linéaire (simple mais encore un peu compliqué!) et le potentiomètre par deux potentiomètres en bout de barre et reliés à la ligne centrale au-dessus et permettant de retrouver à la fois l'angle de la barre et la position de la barre par triangulation.
Je suis du coup parti dans des réflexions sur l'utilisation généralisée des potentiomètres afin d'obtenir un système qui pourrait être purement analogique.
La difficulté reste de connaître l'orientation du cerf-volant (ce qui permet d'améliorer la précision du pilotage).
Les solutions pour l'instant envisagées sont :
Pour un cerf-volant de 5m de largeur à 30m cela donne 10° d'écart pour 90° de rotation. Cela suppose cependant l'utilisation des lignes arrières qui ne sont pas toujours tendues.
Voici mes réflexions de la nuit. Une de mes préoccupations était d'avoir une version réduite du système de pilotage pour un cerf-volant 2 lignes (actuellement la ligne centrale me sert de référence pour l'angle de barre).
Mon autre préoccupation était de rendre plus robuste le capteur linéaire, des dérives lentes étant encore observées.
Une première idée a été d'utiliser le capteur linéaire pour mesurer le différentiel de longueur des deux lignes (sur un cerf-volant à 2 lignes, sans barre)
Une autre idée est de remplacer le capteur linéaire (simple mais encore un peu compliqué!) et le potentiomètre par deux potentiomètres en bout de barre et reliés à la ligne centrale au-dessus et permettant de retrouver à la fois l'angle de la barre et la position de la barre par triangulation.
Je suis du coup parti dans des réflexions sur l'utilisation généralisée des potentiomètres afin d'obtenir un système qui pourrait être purement analogique.
- Avec un fil à plomb pour connaître l'élévation du cerf-volant à partir de la mesure de l'angle de la ligne (ou par rapport au sol)
- Avec une girouette pour connaître l’azimut de la ligne (ou par rapport au sol).
La difficulté reste de connaître l'orientation du cerf-volant (ce qui permet d'améliorer la précision du pilotage).
Les solutions pour l'instant envisagées sont :
- Caméra (comme ferait l'humain)
- Accéléromètre et gyro embarqué + liaison radio (ou fibre optique dans fil nylon comme suggérée par Jean-Pierre).
- Capteur infrarouge (utilisés pour les avions ou les drones)
Pour un cerf-volant de 5m de largeur à 30m cela donne 10° d'écart pour 90° de rotation. Cela suppose cependant l'utilisation des lignes arrières qui ne sont pas toujours tendues.
mardi 18 mars 2014
OA
Mardi, c'est open atelier à PlateformeC. Voici les tâches réalisées sur le projet :
Voilà, ça bouge, ça fait du bruit (surtout quand une pièce lâche et que les moteurs se mettent à tourner à fond, heureusement qu'il y a les butées mécaniques et les limiteurs de couple).
A prévoir
- Remplacement des connecteurs 12V par des connecteurs Tamya (femelle du côté de l'alimentation)
- Correction d'un bug lorsque le joystick était à fond à gauche ou vers le haut.
- Installation d'un petit cerf-volant qui servira à tester la boucle fermée avec la caméra et le traitement vidéo.
Voilà, ça bouge, ça fait du bruit (surtout quand une pièce lâche et que les moteurs se mettent à tourner à fond, heureusement qu'il y a les butées mécaniques et les limiteurs de couple).
A prévoir
- Corriger le bug dans les autres programmes.
- Améliorer la butée dans le cas où les moteurs choquent trop.
lundi 17 mars 2014
Ferme aérienne
Lorsque le kitesurf a commencé à se répandre, une inquiétude était la saturation des spots, avec toute la longueur des lignes, plus de place pour les planchistes.
La réalité fut bien différente. Les ailes volent en général assez haut et en se croisant à des distances normales (5m), les lignes du kiteur au vent passe (en général...) sans soucis au dessus du mat du planchiste sous son vent (70cm de rab pour un mat de 4m30 si l'on considère que le kite est à 45°. Le kiteur peut éventuellement relever son aile le temps du croisement.
Lors des croisements entre kite, la difficulté devrait être moindre, car les kites volent normalement de la même manière, mais ce n'est pas tout à fait le cas, car l'aile sous le vent peut monter à bien plus que 5m. Une aile au zenith sous le vent est ainsi un vrai obstacle pour le kiteur au vent, qui devra lofer ou faire monter son aile, avec une perte de vitesse.
Cependant, de manière globale, l'encombrement n'augmente pas (si on exclut les débutants...), et le vent est même mieux utilisé, les planchistes utilisant le vent au niveau de l'eau, les kiteurs le vent au-dessus, il n'y a moins de problèmes de dévent.
On peut aujourd'hui observer la même peur de la chute de densité pour une ferme éolienne aérienne comparée à une ferme éolienne classique. Il est en effet plus sage pour les prototypes de s'assurer qu'un cerf-volant ne puisse tomber sur rien (et donc en particulier pas sur un autre cerf-volant).
Mais à terme je pense que l'on peut aller vers une augmentation de la densité énergétique par m2 au sol en profitant du vent plus haut, et donc dans un plus grand volume.
Léo Goldstein a récemment écrit un papier qui va dans ce sens.
La réalité fut bien différente. Les ailes volent en général assez haut et en se croisant à des distances normales (5m), les lignes du kiteur au vent passe (en général...) sans soucis au dessus du mat du planchiste sous son vent (70cm de rab pour un mat de 4m30 si l'on considère que le kite est à 45°. Le kiteur peut éventuellement relever son aile le temps du croisement.
Lors des croisements entre kite, la difficulté devrait être moindre, car les kites volent normalement de la même manière, mais ce n'est pas tout à fait le cas, car l'aile sous le vent peut monter à bien plus que 5m. Une aile au zenith sous le vent est ainsi un vrai obstacle pour le kiteur au vent, qui devra lofer ou faire monter son aile, avec une perte de vitesse.
Cependant, de manière globale, l'encombrement n'augmente pas (si on exclut les débutants...), et le vent est même mieux utilisé, les planchistes utilisant le vent au niveau de l'eau, les kiteurs le vent au-dessus, il n'y a moins de problèmes de dévent.
On peut aujourd'hui observer la même peur de la chute de densité pour une ferme éolienne aérienne comparée à une ferme éolienne classique. Il est en effet plus sage pour les prototypes de s'assurer qu'un cerf-volant ne puisse tomber sur rien (et donc en particulier pas sur un autre cerf-volant).
Mais à terme je pense que l'on peut aller vers une augmentation de la densité énergétique par m2 au sol en profitant du vent plus haut, et donc dans un plus grand volume.
Léo Goldstein a récemment écrit un papier qui va dans ce sens.
Visualisation 3D dans navigateur
Aujourd'hui j'ai travaillé sur la visualisation 3D des mouvements du kite, ceci afin de mieux percevoir les résultats du simulateurs développées par Vincent, Quentin et Charles de l'Ecole Centrale.
Voici le résultat (il n'y a pas de modèle dynamique branché) http://www.nautilabs.com/webgl_loader_collada.html
Les modèles 3D ont été pris sur 3D warehouse. Je cherchais les fichiers collada (.dae). Souvent le format est .dmz, mais en changeant l'extension en .zip, on peut extraire des fichiers dont le .dae.
Le nuage représente la vitesse du vent réel.
Le drapeau représente l'angle du vent apparent (et la fréquence de ces oscillations correspondent à la vitesse du vent apparent).
Le code peut évidemment être obtenu à partir d'un simple navigateur, ou sur le dépôt github
Voici le résultat (il n'y a pas de modèle dynamique branché) http://www.nautilabs.com/webgl_loader_collada.html
Les modèles 3D ont été pris sur 3D warehouse. Je cherchais les fichiers collada (.dae). Souvent le format est .dmz, mais en changeant l'extension en .zip, on peut extraire des fichiers dont le .dae.
Le nuage représente la vitesse du vent réel.
Le drapeau représente l'angle du vent apparent (et la fréquence de ces oscillations correspondent à la vitesse du vent apparent).
Le code peut évidemment être obtenu à partir d'un simple navigateur, ou sur le dépôt github
dimanche 16 mars 2014
Pipas malucas
Une vidéo de Luca Wyss sur les pipas, ces jolis cerfs-volants brésiliens faits de ficelle et de papier (oui comme les mignonettes de Christophe!), et très prisés dans les favelas (pour leur prix abordable, ridicule pour nous) où les enfants (petits et grands) les font voler comme des oiseaux.
Luca a fait le tour de fabriques artisanales de ces cerfs-volants en amérique du Sud
http://pipasmalucas.tumblr.com/
um funk pra pássaros from Luca Wyss on Vimeo.
Luca a fait le tour de fabriques artisanales de ces cerfs-volants en amérique du Sud
http://pipasmalucas.tumblr.com/
um funk pra pássaros from Luca Wyss on Vimeo.
Camrap
Pour assurer la redondance au niveau des capteurs de barre, j'envisage d'utiliser une webcam.
L'idée est de filmer un motif qui puisse être facilement identifié et ne se répétant pas et dont la position des éléments permet de retrouver la position relative de la caméra.
J'ai trouvé un projet open source assez abouti sur
http://reprap.org/wiki/CamRap
Le principe est en fait le même que pour les crayons numériques.
A cause des problèmes de latence, et de flous je n'espère pas pouvoir faire des mesures avec du mouvement, mais cela devrait permettre de se recaler de manière absolu, les interruptions sur arduino permettant des mesures plus rapides (avec les fourches optiques par exemple)
J'ai pu charger le code sur github https://github.com/darkpaw/camrap et imprimer le motif, mais mes webcams ne sont pas supportées par pygame qui est utilisé dans le programme. J'ai fait un fork pour essayer de remplacer pygame par simplecv avec qui je n'ai pas de problème pour lire les images de mes caméras. A suivre...
L'idée est de filmer un motif qui puisse être facilement identifié et ne se répétant pas et dont la position des éléments permet de retrouver la position relative de la caméra.
J'ai trouvé un projet open source assez abouti sur
http://reprap.org/wiki/CamRap
Le principe est en fait le même que pour les crayons numériques.
A cause des problèmes de latence, et de flous je n'espère pas pouvoir faire des mesures avec du mouvement, mais cela devrait permettre de se recaler de manière absolu, les interruptions sur arduino permettant des mesures plus rapides (avec les fourches optiques par exemple)
J'ai pu charger le code sur github https://github.com/darkpaw/camrap et imprimer le motif, mais mes webcams ne sont pas supportées par pygame qui est utilisé dans le programme. J'ai fait un fork pour essayer de remplacer pygame par simplecv avec qui je n'ai pas de problème pour lire les images de mes caméras. A suivre...
samedi 15 mars 2014
Serre-ligne
Pour pouvoir accrocher le support de la camera sur les lignes, il est nécessaire d'avoir une sorte de serre-ligne, ou serre-fil.
Celui-ci est entre le serre-câble (à vis), le tendeur de tente, le taquet coinceur ou le simple nœud.
Cahier des charges :
Bonus :
http://www.thingiverse.com/thing:113570
http://www.k4mg.com/CNC/RepRap_Prusa_Mendel_Build/OriginalPictures/IMG_1206.JPG
On peut également faire de la récupération :
Mais la meilleure solution semble être le nœud (cabestan ou Machard), mais ça demande des connaissances
Celui-ci est entre le serre-câble (à vis), le tendeur de tente, le taquet coinceur ou le simple nœud.
Cahier des charges :
- Ne pas glisser (minimum traction dans un sens)
- Ne pas abîmer la ligne
- Se monter sans extrémité libre
- Pas de modification de la longueur de la ligne
- Léger
Bonus :
- Adaptation à plusieurs diamètres
- Matière durable
http://www.thingiverse.com/thing:113570
http://www.k4mg.com/CNC/RepRap_Prusa_Mendel_Build/OriginalPictures/IMG_1206.JPG
On peut également faire de la récupération :
 | |
| Réutilisation d'une languette de canette sur les conseils de JP |
H2020
H2020 est le nouveau programme de subvention pour la recherche européenne. H2020 se veut plus accessible, avec moins de paperasse.
Un axe de recherche identifié correspond à la réduction des émissions carbone (pourquoi pas). C'est probablement dans cette case que la recherche sur l'utilisation de l'énergie éolienne aérienne pourrait rentrer.
http://ec.europa.eu/research/participants/portal/desktop/en/opportunities/h2020/topics/1123-lce-02-2014.html#tab2
Le quartier de la création organise une journée coup de pousse sur les subventions européennes dont H2020.
http://creationduquartier.com/fr/webzine/financez-vos-projets-media-gr%C3%A2ce-aux-fonds-europ%C3%A9ens
Un axe de recherche identifié correspond à la réduction des émissions carbone (pourquoi pas). C'est probablement dans cette case que la recherche sur l'utilisation de l'énergie éolienne aérienne pourrait rentrer.
http://ec.europa.eu/research/participants/portal/desktop/en/opportunities/h2020/topics/1123-lce-02-2014.html#tab2
Le quartier de la création organise une journée coup de pousse sur les subventions européennes dont H2020.
http://creationduquartier.com/fr/webzine/financez-vos-projets-media-gr%C3%A2ce-aux-fonds-europ%C3%A9ens
Cage Darlet
Jean-Pierre B. de ping me parle souvent de la cage Darlet.
Son nom vient de son inventeur. La cage Darlet permet de bloquer le bridage d'un parapente et ainsi de bloquer son profil.
Pour en savoir plus, lire les nombreuses informations sur le site de la ffvl ou le site des utilisateurs de la Cage.
http://federation.ffvl.fr/actus/cage-un-autre-vol-libre
http://www.aspic.org/fr/taxonomy/term/1
Son nom vient de son inventeur. La cage Darlet permet de bloquer le bridage d'un parapente et ainsi de bloquer son profil.
Pour en savoir plus, lire les nombreuses informations sur le site de la ffvl ou le site des utilisateurs de la Cage.
http://federation.ffvl.fr/actus/cage-un-autre-vol-libre
http://www.aspic.org/fr/taxonomy/term/1
Lancement avec ballon d'helium.
Je me suis parfois posé la question de l'utilisation d'un ballon d'hélium pour lancer le kite lorsque le vent au niveau du sol manque, ou pour récupérer le kite si le vent tombe.
TU Delft avait déjà fait des essais il y a quelques années (à 4'41)
Une idée serait de pouvoir faire monter ou descendre le ballon sur les lignes du kite, pour pouvoir le faire redescendre une fois que le cerf-volant est en l'air (pour limiter la traînée dans le cas de la propulsion d'un navire), et pouvoir le relancer pour la récupération.
TU Delft avait déjà fait des essais il y a quelques années (à 4'41)
Une idée serait de pouvoir faire monter ou descendre le ballon sur les lignes du kite, pour pouvoir le faire redescendre une fois que le cerf-volant est en l'air (pour limiter la traînée dans le cas de la propulsion d'un navire), et pouvoir le relancer pour la récupération.
Dan Tracy
Dan Tracy va bientôt lancer un projet sur kickstarter pour une barre de kite (2 lignes) avec une manivelle permettant de rouler/dérouler les lignes rapidement pour une utilisation sur un kayak par exemple.
Dan n'en est pas à son premier projet dans le domaine du kiteboat, et rêvait notamment de tirer un jour de grands bateaux avec Pacific Sky Power
Dan n'en est pas à son premier projet dans le domaine du kiteboat, et rêvait notamment de tirer un jour de grands bateaux avec Pacific Sky Power
Radio
Voici quelques liens radiophoniques sur le sujet du cerf-volant ou plus généralement du retour du vent pour la propulsion des navires
Roland Jourdain, alias Bilou, rédacteur en chef de CO2 mon amour, sur France Inter
à 21'40 : "kite pas propulsion principale" (transcription approximative) Guillaume Le Grand
" Transport de marchandises à la voile, retour vers le futur" de Euradio
Le vent, ami ou ennemi des transports maritimes (1/3), sur France Info
à 1'45 "le moteur principal sera un kite" (transcription approximative) Yves ParlierRoland Jourdain, alias Bilou, rédacteur en chef de CO2 mon amour, sur France Inter
à 21'40 : "kite pas propulsion principale" (transcription approximative) Guillaume Le Grand
" Transport de marchandises à la voile, retour vers le futur" de Euradio
vendredi 14 mars 2014
Contrôle en boucle fermée
Aujourd'hui est un grand jour...
C'est d'abord la fin de mon congé création d'entreprise. Je reprends mon travail chez SIREHNA. Cependant, le projet robokite ne s'arrête pas, car je reprends pour l'instant à mi-temps par période de 15 jours. Et donc aujourd'hui je ne travaillais pas.
J'ai pu aller encore à PlateformeC pour travailler sur le prototype.
J'ai pu tester la version du code préparée hier soir.
J'ai d'abord coder un programme simplifié envoyant les ordres du joystick (captés avec pygame) pour commander les moteurs en vitesse.
J'ai ensuite modifié le code sur l'arduino pour que les moteurs contrôlent la position et l'angle de la barre en boucle fermée. Le joystick me servant à changer la position ou l'angle commandé.
Cela a bien marché et est une première (l'été dernier je n'avais commandé que l'angle). J'ai fait des réglages PID grossier (avec que du proportionnel), mais cela est suffisamment rapide et précis.
Une difficulté venait d'une des mèches qui sortait de la visseuse. Un bon coup de pince et le problème fut réglé.
Une autre difficulté fut la batterie qui finit par être déchargée à force de faire des tests. Peut-être me sera-t-il possible d'en emprunter pour en avoir plusieurs pour les tests en extérieur.
J'ai également eu des difficultés au niveau de la communication, et je n'ai pas réussi à utiliser l'interface dans le navigateur (qui marchait pourtant bien auparavant).
Enfin, le plus gros problème semble venir de l'encodeur linéaire qui perd parfois sa position, peut-être à cause d'une difficulté de gestion des priorités des "interrupts" entre softwareSerial et pinChangeInt. Je réfléchis à une redondance pour empêcher les dérives. Peut-être une webcam (12 euros) et un motif identifiable qui ne se répète pas (type code de gray, voir http://reprap.org/wiki/CamRap).
J'ai réussi à installer le programme simplifié de contrôle au joystick sur un raspberry. Cela marche tout aussi bien.
Il y a cependant parfois des comportements étranges, où les moteurs ne tournent pas alors que le joystick est poussé à fond. Les moteurs tournent lors du retour du joystick en position.
Autres avancées :
La semaine prochaine je renforcerai les connections des moteurs à la carte avec des connecteurs Tamya
C'est d'abord la fin de mon congé création d'entreprise. Je reprends mon travail chez SIREHNA. Cependant, le projet robokite ne s'arrête pas, car je reprends pour l'instant à mi-temps par période de 15 jours. Et donc aujourd'hui je ne travaillais pas.
J'ai pu aller encore à PlateformeC pour travailler sur le prototype.
 |
| Les actionneurs : treuils |
 |
| Les capteurs |
J'ai pu tester la version du code préparée hier soir.
J'ai d'abord coder un programme simplifié envoyant les ordres du joystick (captés avec pygame) pour commander les moteurs en vitesse.
J'ai ensuite modifié le code sur l'arduino pour que les moteurs contrôlent la position et l'angle de la barre en boucle fermée. Le joystick me servant à changer la position ou l'angle commandé.
Cela a bien marché et est une première (l'été dernier je n'avais commandé que l'angle). J'ai fait des réglages PID grossier (avec que du proportionnel), mais cela est suffisamment rapide et précis.
Une difficulté venait d'une des mèches qui sortait de la visseuse. Un bon coup de pince et le problème fut réglé.
Une autre difficulté fut la batterie qui finit par être déchargée à force de faire des tests. Peut-être me sera-t-il possible d'en emprunter pour en avoir plusieurs pour les tests en extérieur.
J'ai également eu des difficultés au niveau de la communication, et je n'ai pas réussi à utiliser l'interface dans le navigateur (qui marchait pourtant bien auparavant).
Enfin, le plus gros problème semble venir de l'encodeur linéaire qui perd parfois sa position, peut-être à cause d'une difficulté de gestion des priorités des "interrupts" entre softwareSerial et pinChangeInt. Je réfléchis à une redondance pour empêcher les dérives. Peut-être une webcam (12 euros) et un motif identifiable qui ne se répète pas (type code de gray, voir http://reprap.org/wiki/CamRap).
J'ai réussi à installer le programme simplifié de contrôle au joystick sur un raspberry. Cela marche tout aussi bien.
Il y a cependant parfois des comportements étranges, où les moteurs ne tournent pas alors que le joystick est poussé à fond. Les moteurs tournent lors du retour du joystick en position.
Autres avancées :
- Montage d'un boîtier de dérivation électrique qui protégera les 4 cartes électroniques.
- Préparation de mèches métalliques (pour remplacer éventuellement les mèches en bois).
La semaine prochaine je renforcerai les connections des moteurs à la carte avec des connecteurs Tamya
jeudi 13 mars 2014
Vers le contrôle en boucle fermé
Aujourd'hui j'ai essayé de fusionner le code du capteur de barre, avec le code de la commande des moteurs, l'objectif étant d'obtenir un contrôle en boucle fermé de la barre (angle et bordé-choqué).
Malheureusement, je suis tombé sur un problème d'incompatibilité d'une librairie utilisée pour l'encodeur linéaire (pinchangeint) et de la librairie utilisée pour communiquer avec la carte de contrôle des moteurs (softwareSerial)
http://forum.arduino.cc/index.php?topic=91264.5;wap2
Comme je disposais déjà de 2 arduinos, j'ai essayé de contourner le problème en utilisant les 2 arduinos et en rajoutant une communication de l'un à l'autre. Pour cela, le plus simple me paraissait de sortir une valeur analogique sur l'un et de venir la lire sur l'autre. Malheureusement cela me donnait 0 ou 5V de manière alternative, mais pas la valeur attendue. Cela est peut-être dû à la modulation pwm et à l'absence de filtre passe-bas.
Du coup, j'ai utilisé le protocôle I2C qui était présenté comme une solution standard pour discuter entre plusieurs arduinos. Je me suis basé sur :
http://www.instructables.com/id/I2C-between-Arduinos/step3/Programming/
Les codes de ce tutoriel ne fonctionnent cependant pas, mais les exemples d'utilisation existent de base dans les exemples arduino.
J'ai utilisé des résistances de pull up de 10kOhm.
Cela fonctionne mais demande d'avoir deux arduinos.
J'ai continué les recherches ce soir, et j'ai trouvé une solution logicielle au problème de compatibilité des librairies.
http://code.google.com/p/arduino-pinchangeint/wiki/Bugs
Malheureusement, je suis tombé sur un problème d'incompatibilité d'une librairie utilisée pour l'encodeur linéaire (pinchangeint) et de la librairie utilisée pour communiquer avec la carte de contrôle des moteurs (softwareSerial)
http://forum.arduino.cc/index.php?topic=91264.5;wap2
Comme je disposais déjà de 2 arduinos, j'ai essayé de contourner le problème en utilisant les 2 arduinos et en rajoutant une communication de l'un à l'autre. Pour cela, le plus simple me paraissait de sortir une valeur analogique sur l'un et de venir la lire sur l'autre. Malheureusement cela me donnait 0 ou 5V de manière alternative, mais pas la valeur attendue. Cela est peut-être dû à la modulation pwm et à l'absence de filtre passe-bas.
Du coup, j'ai utilisé le protocôle I2C qui était présenté comme une solution standard pour discuter entre plusieurs arduinos. Je me suis basé sur :
http://www.instructables.com/id/I2C-between-Arduinos/step3/Programming/
Les codes de ce tutoriel ne fonctionnent cependant pas, mais les exemples d'utilisation existent de base dans les exemples arduino.
J'ai utilisé des résistances de pull up de 10kOhm.
Cela fonctionne mais demande d'avoir deux arduinos.
J'ai continué les recherches ce soir, et j'ai trouvé une solution logicielle au problème de compatibilité des librairies.
http://code.google.com/p/arduino-pinchangeint/wiki/Bugs
lundi 10 mars 2014
Interface Homme Machine : joystick
Lors des essais de l'été dernier, j'ai d'abord utilisé un simple potard comme interface de contrôle. D'un côté, j'allais dans un sens, de l'autre dans l'autre sens. J'ai ensuite rajouté une boucle fermée mais toujours avec un contrôle par un potard.
Cela posait quelques problèmes car la plage de rotation du potard est trop grande pour être couverte facilement. De plus, le potard était monté sur une boîte contenant les circuits électroniques, donc il était posé au niveau du sol. Finalement le potard a fini par casser (au niveau de la connectique).
N'ayant pas de potard de rechange sous la main, j'ai ensuite utilisé mon téléphone portable. L'inclinaison du téléphone était utilisée pour contrôler la vitesse des moteurs. Cela avait l'avantage de permettre de contrôler sans fil (via wifi) et donc par exemple de pouvoir faire les tests seul en joystick manuel (je lançais le cerf-volant et essayais de le piloter à distance). Le problème est que sans information de retour sur la position de la barre, le contrôle était trop difficile. De plus la portée du wifi du téléphone portable étant limitée, il y avait souvent des coupures. Enfin dès que je voulais poser le téléphone, ou que je faisais une erreur, cela envoyait des ordres non désirés.
J'ai ensuite utilisé une radiocommande (récupérée de mon voilier radiocommandé). C'était assez pratique, notamment grâce au ressort permettant un retour à la position neutre. La portée radio était suffisante (mais l'antenne un peu gênante). Le trim est aussi une fonctionnalité que j'ai utilisée pour le contrôle de la barre en boucle fermé. Je n'avais pas testé le décodage par la carte arduino des commandes envoyées au servo, mais cela semble possible (pour pouvoir avoir un enregistrement des commandes).
Souvent, j'ai également directement utilisé une interface graphique avec des "sliders". C'est assez pratique car cela ne demande pas de matériel. Par contre, il est difficile à la souris d'aller cliquer sur le slider, puis de savoir où il est rendu sans avoir les yeux rivés sur l'écran. Pour régler cela, la gestion des sliders était également possible aux flèches du clavier, mais cela n'est pas très réactif, le retour à zéro est difficile (une solution aurait été d'utiliser par exemple la flèche du bas pour le retour au neutre, mais cela n'est pas prévu de base avec les sliders de html5), et on ne sait pas quand on arrive en butée non plus.
Une solution souvent utilisée est le joystick. Le joystick a l'avantage de pouvoir être utilisé à une main s'il est bien fixé. Mais lors des tests pour le pilotage du cerf-volant, cela se passe plutôt en extérieur, et j'essaie d'avoir le moins de matériel possible (pas de table). Une manette de jeu dotée d'un joystick me semblait donc plus pratique, car pouvant se tenir d'une main, le joystick ne bougeant qu'avec le pouce. Cela permet de passer d'un pilotage manuel d'une main (grâce à la barre), à un pilotage joystick de l'autre main par une personne seule. Une alternative serait d'avoir un petit joystick directement fixé sur la barre.
J'ai récemment acheté une manette de jeu ("gamepad") : la rumble pad 2 de Logitech (9 euros chez Happy Cash!).
A partir du site http://videlais.com/2013/12/24/html5-using-gamepads-as-input/, j'ai réussi à réaliser un programme de test.
Cela posait quelques problèmes car la plage de rotation du potard est trop grande pour être couverte facilement. De plus, le potard était monté sur une boîte contenant les circuits électroniques, donc il était posé au niveau du sol. Finalement le potard a fini par casser (au niveau de la connectique).
N'ayant pas de potard de rechange sous la main, j'ai ensuite utilisé mon téléphone portable. L'inclinaison du téléphone était utilisée pour contrôler la vitesse des moteurs. Cela avait l'avantage de permettre de contrôler sans fil (via wifi) et donc par exemple de pouvoir faire les tests seul en joystick manuel (je lançais le cerf-volant et essayais de le piloter à distance). Le problème est que sans information de retour sur la position de la barre, le contrôle était trop difficile. De plus la portée du wifi du téléphone portable étant limitée, il y avait souvent des coupures. Enfin dès que je voulais poser le téléphone, ou que je faisais une erreur, cela envoyait des ordres non désirés.
J'ai ensuite utilisé une radiocommande (récupérée de mon voilier radiocommandé). C'était assez pratique, notamment grâce au ressort permettant un retour à la position neutre. La portée radio était suffisante (mais l'antenne un peu gênante). Le trim est aussi une fonctionnalité que j'ai utilisée pour le contrôle de la barre en boucle fermé. Je n'avais pas testé le décodage par la carte arduino des commandes envoyées au servo, mais cela semble possible (pour pouvoir avoir un enregistrement des commandes).
Souvent, j'ai également directement utilisé une interface graphique avec des "sliders". C'est assez pratique car cela ne demande pas de matériel. Par contre, il est difficile à la souris d'aller cliquer sur le slider, puis de savoir où il est rendu sans avoir les yeux rivés sur l'écran. Pour régler cela, la gestion des sliders était également possible aux flèches du clavier, mais cela n'est pas très réactif, le retour à zéro est difficile (une solution aurait été d'utiliser par exemple la flèche du bas pour le retour au neutre, mais cela n'est pas prévu de base avec les sliders de html5), et on ne sait pas quand on arrive en butée non plus.
Une solution souvent utilisée est le joystick. Le joystick a l'avantage de pouvoir être utilisé à une main s'il est bien fixé. Mais lors des tests pour le pilotage du cerf-volant, cela se passe plutôt en extérieur, et j'essaie d'avoir le moins de matériel possible (pas de table). Une manette de jeu dotée d'un joystick me semblait donc plus pratique, car pouvant se tenir d'une main, le joystick ne bougeant qu'avec le pouce. Cela permet de passer d'un pilotage manuel d'une main (grâce à la barre), à un pilotage joystick de l'autre main par une personne seule. Une alternative serait d'avoir un petit joystick directement fixé sur la barre.
J'ai récemment acheté une manette de jeu ("gamepad") : la rumble pad 2 de Logitech (9 euros chez Happy Cash!).
J'ai pu tester son bon fonctionnement avec le programme jstest-gtk
J'ai ensuite réalisé un programme de test avec le module python pygame (à partir d'un cours sur openclassrooms). Le code est ici.
J'arrive bien à récupérer les informations du joystick (axes) et des boutons. Par contre, cela me paraissait difficile de combiner la gestion des événements de pygame et de tornado.
J'ai donc cherché à capter les signaux du joystick directement au niveau de l'interface graphique (dans un navigateur web).
Cela est possible grâce à l'API gamepad en cours de définition par le W3C http://www.w3.org/TR/2014/WD-gamepad-20140225/.Une implémentation fonctionne sous chrome(ium) pour l'instant. Elle peut-être testée sur html5rocks.
A partir du site http://videlais.com/2013/12/24/html5-using-gamepads-as-input/, j'ai réussi à réaliser un programme de test.
function runAnimation()
{
window.requestAnimationFrame(runAnimation);
var gamepads = (navigator.webkitGetGamepads && navigator.webkitGetGamepads()) ||
!!navigator.webkitGamepads || !!navigator.mozGamepads ||
!!navigator.msGamepads || !!navigator.gamepads;
for (var i = 0; i < gamepads.length; ++i)
{
var pad = gamepads[i];
console.log(pad.axes);
}
}
window.requestAnimationFrame(runAnimation);
Un code plus complet est disponible ici. Une (petite) difficulté a été de permettre à la fois le contrôle par le joystick, ou par les sliders de l'interface graphique. Une bonne chose est que les informations peuvent être récupérées en même temps par python et javascript. Ce qui peut permettre d'utiliser le joystick même si aucune interface graphique n'est lancée.
Il reste encore à ajouter un trim.
J'ai également testé sur mon téléphone mobile android, en connectant la manette en USB On The Go. Cela permettrait d'avoir un joystick mobile.
Pour cela j'ai servi les fichiers statiques avec :
python -m SimpleHTTPServer
Malheureusement, cela ne fonctionne pas pour l'instant, mais les développements sont en cours.
Cahier des charges (a posteriori) :
- Au moins 2 axes (droite-gauche, bordé-choqué)
- Utilisable d'une seule main
- Ergonomie (amplitude du mouvement)
- Utilisable en tenant la barre
- Données récupérables sur un PC
- Progressif
- Feedback sensoriel non visuel de la position du joystick + butée + neutre (tactile ou auditif?)
- Trim (avec protection contre le déréglage)
- Détrompeur pour limiter le risque de tenir le joystick à l'envers (voir à ce propos mes mésaventures sur mon blog perso, 2ème paragraphe )
Options :
- Retour d'effort
- Solide, étanche
- Retour au neutre ou maintien en position
dimanche 9 mars 2014
Sélections de liens
Voici quelques liens (pas forcément récents) trouvés sur le net.
D'abord un historique des tentatives d'utilisation de l'énergie éolienne aérienne (en allemand).
Une vidéo d'Ampyx power, une spin off de TU Delft qui mise sur du reel in/reel out avec un cerf-volant de type planeur.
Un TedX de Reinhart Paelinck du KU Louvain
La présentation de l'équipe Plume à l'issu des 24h de l'innovation de l'ESTIA sur un projet proposé par Yves Parlier et Fabien Griffon.
D'abord un historique des tentatives d'utilisation de l'énergie éolienne aérienne (en allemand).
Une vidéo d'Ampyx power, une spin off de TU Delft qui mise sur du reel in/reel out avec un cerf-volant de type planeur.
Un TedX de Reinhart Paelinck du KU Louvain
La présentation de l'équipe Plume à l'issu des 24h de l'innovation de l'ESTIA sur un projet proposé par Yves Parlier et Fabien Griffon.
samedi 8 mars 2014
Pierre Benhaïem et Flygenkite
Voici une vidéo de Pierre Benhaïem lors du concours Lépine 2011.
Il a fabriqué un petit prototype assez simple d'une micro-éolienne se fixant sur les lignes et alimentant un bandeau de leds. Si la production d'énergie électrique pour un retour vers la terre ne me parait pas une bonne idée, une production de quelques watts me semble intéressante pour alimenter et réduire la taille des batteries nécessaires à l'alimentation des capteurs embarqués et des leds pour la nuit.
Il a fabriqué un petit prototype assez simple d'une micro-éolienne se fixant sur les lignes et alimentant un bandeau de leds. Si la production d'énergie électrique pour un retour vers la terre ne me parait pas une bonne idée, une production de quelques watts me semble intéressante pour alimenter et réduire la taille des batteries nécessaires à l'alimentation des capteurs embarqués et des leds pour la nuit.
Capteur de barre.
Aujourd'hui j'ai pu finir (?) le capteur complet de la barre. Le capteur permet de mesurer à la fois le border-choquer et l'angle de barre. Cela permet ainsi de faire des mesures, même lors d'une utilisation manuelle de la barre.
Le capteur est fixé à la barre par un bout de sangle, percé pour laisser passer un potentiomètre. Sur l'axe de ce dernier est fixée une planchette en bois (avec des colsons...). Sur cette planchette en bois sont collés deux coulisseaux imprimés en plastique. L'un deux est équipé de 3 fourches infrarouges ce qui permet de mesurer optiquement les graduations sur la règle qui coulisse dans les coulisseaux. Cette règle est fixée parallèlement à la ligne centrale du kite (possible sur le côté seulement sur la barre que j'ai, mais possible devant ou derrière sur d'autres barres). Elle est attachée et tendue à ses extrémités par des bouts sur la ligne centrale. Des cales (coupées dans une plaque de mousse isolante) permettent d'assurer le parallélisme (mais il manque en fait une liaison, et lorsque la barre est tournée, il faut un peu de souplesse dans la règle).
La connectique est assurée par des connecteurs et un jeu de soudure et de gaine thermo pour relier les masses et les alimentations entre elles. Cela permet d'avoir un seul câble (environ 2m) avec 6 fils (masse, 5V, encodeur en quadrature 1, encodeur en quadrature 2, encodeur pour la référence absolue, potard pour l'angle) partant vers la carte d'acquisition.
.
Le montage n'est pas encore tout à fait étanche...
La précision de la mesure avec les différents jeux mécaniques reste à évaluer. Cela ne devrait pas être très précis, mais suffisamment pour l'application visée.
Des corrections pourront éventuellement être apportées par le logiciel (par exemple lorsque la barre est tournée, cela à un effet sur la mesure de la position). La mesure risque également d'être perturbée en fin de course (on atteint finalement les limites de la plage de mesure linéaire, à cause des mouvements en rotation).
J'espère maintenant pouvoir me ré-attaquer au contrôle en boucle fermée par les moteurs (je l'avais déjà fait l'été dernier, mais seulement avec un moteur et une mesure par un potentiomètre).
Le capteur est fixé à la barre par un bout de sangle, percé pour laisser passer un potentiomètre. Sur l'axe de ce dernier est fixée une planchette en bois (avec des colsons...). Sur cette planchette en bois sont collés deux coulisseaux imprimés en plastique. L'un deux est équipé de 3 fourches infrarouges ce qui permet de mesurer optiquement les graduations sur la règle qui coulisse dans les coulisseaux. Cette règle est fixée parallèlement à la ligne centrale du kite (possible sur le côté seulement sur la barre que j'ai, mais possible devant ou derrière sur d'autres barres). Elle est attachée et tendue à ses extrémités par des bouts sur la ligne centrale. Des cales (coupées dans une plaque de mousse isolante) permettent d'assurer le parallélisme (mais il manque en fait une liaison, et lorsque la barre est tournée, il faut un peu de souplesse dans la règle).
La connectique est assurée par des connecteurs et un jeu de soudure et de gaine thermo pour relier les masses et les alimentations entre elles. Cela permet d'avoir un seul câble (environ 2m) avec 6 fils (masse, 5V, encodeur en quadrature 1, encodeur en quadrature 2, encodeur pour la référence absolue, potard pour l'angle) partant vers la carte d'acquisition.
.
Le montage n'est pas encore tout à fait étanche...
La précision de la mesure avec les différents jeux mécaniques reste à évaluer. Cela ne devrait pas être très précis, mais suffisamment pour l'application visée.
Des corrections pourront éventuellement être apportées par le logiciel (par exemple lorsque la barre est tournée, cela à un effet sur la mesure de la position). La mesure risque également d'être perturbée en fin de course (on atteint finalement les limites de la plage de mesure linéaire, à cause des mouvements en rotation).
 |
| Chariot modifié pour intégrer la mesure d'angle. La pièce rouge du bas est un deuxième chariot, espacé grâce à une petite planche de bois, ce qui permet de transformer la liaison en une vrai glissière (plutôt qu'une rotule). |
 |
| Système d'accroche sur le potentiomètre avec des colsons (récupéré d'un proto précédent) |
 |
| Capteur sur la barre. On voit au dessus du capteur le bloc de mousse permettant d'écarter le bout tendant la règle de la ligne centrale. |
mercredi 5 mars 2014
Open atelier
Suite à des problèmes de chargeur sur mon ordi portable, j'utilise un raspberry pi en remplacement.
J'ai ainsi pu installer arduoscillo et robokite sur le raspberry et tester la connexion avec l'arduino.
Étant quelque peu familier de l'utilisation en ligne de commande, je n'ai pas rencontré de difficulté particulière, sauf pour communiquer avec l'Arduino
La commande suivante permet de recevoir les messages série de l'arduino (en connexion ssh)
screen /dev/ttyACM0 19200
Pour interrompre le défilement des info, il faut ouvrir un deuxième terminal et identifier le numéro du processus (pid) avec la commande
ps -ef
Il est alors possible de tuer le processus avec la commande (où pid est le numéro trouvé précédemment).
kill pid
J'ai ainsi pu tester une pince ampèremétrique (yhdc SCT-013-030, montage pour SCT-013-000, généralités), mais elle n'était pas suffisamment sensible pour le courant testé. De plus, cette pince ne fonctionne qu'en courant alternatif, et ne pourra donc pas me servir sur le projet (ou dans quelques années...).
J'ai discuté avec Jean-Pierre (maître cerf-volant) de ma problématique de trouver une solution pour faire une pince pour accrocher un fil sur un autre fil (un peu comme un tendeur de tente). Il m'a d'abord parlé de l'astuce de récupérer la languette d'ouverture sur une canette métallique (attention au passage du fil pour que ça ne soit pas coupant. Ne marche pas très bien avec des cordages lisses et glissants). Mais cela ne correspondait pas à mon besoin.
Il m'a ensuite parlé du nœud Machard (du nom de Serge, son inventeur français). Ce nœud semble bien répondre à mon problème, sans pièce compliquée. Et moi qui croyait connaître tous les nœuds, je ne connais que les marins, pas ceux d'escalade ! (EDIT : Victor m'a depuis montré un autre nœud également utilisé en escalade, mais plus joli!)
J'ai également retravaillé sur le système de mesure de tension dans les lignes ("tensiomètre" ou "dynamomètre" mais ces noms ont d'autres significations).
J'aimerai obtenir quelque chose proche de ceci.
Pour rappel, j'ai pour l'instant réalisé un circuit électronique avec une jauge de contrainte récupérée sur une balance de voyage et un amplificateur (INA125). J'arrive à récupérer une mesure de l'effort sur mon pc via une carte arduino. Je cherche actuellement à améliorer le support mécanique de manière à pouvoir simplifier la mesure sur une ligne, en venant "pincer" la ligne.
J'ai ainsi pu installer arduoscillo et robokite sur le raspberry et tester la connexion avec l'arduino.
Étant quelque peu familier de l'utilisation en ligne de commande, je n'ai pas rencontré de difficulté particulière, sauf pour communiquer avec l'Arduino
La commande suivante permet de recevoir les messages série de l'arduino (en connexion ssh)
screen /dev/ttyACM0 19200
Pour interrompre le défilement des info, il faut ouvrir un deuxième terminal et identifier le numéro du processus (pid) avec la commande
ps -ef
Il est alors possible de tuer le processus avec la commande (où pid est le numéro trouvé précédemment).
kill pid
J'ai ainsi pu tester une pince ampèremétrique (yhdc SCT-013-030, montage pour SCT-013-000, généralités), mais elle n'était pas suffisamment sensible pour le courant testé. De plus, cette pince ne fonctionne qu'en courant alternatif, et ne pourra donc pas me servir sur le projet (ou dans quelques années...).
J'ai discuté avec Jean-Pierre (maître cerf-volant) de ma problématique de trouver une solution pour faire une pince pour accrocher un fil sur un autre fil (un peu comme un tendeur de tente). Il m'a d'abord parlé de l'astuce de récupérer la languette d'ouverture sur une canette métallique (attention au passage du fil pour que ça ne soit pas coupant. Ne marche pas très bien avec des cordages lisses et glissants). Mais cela ne correspondait pas à mon besoin.
Il m'a ensuite parlé du nœud Machard (du nom de Serge, son inventeur français). Ce nœud semble bien répondre à mon problème, sans pièce compliquée. Et moi qui croyait connaître tous les nœuds, je ne connais que les marins, pas ceux d'escalade ! (EDIT : Victor m'a depuis montré un autre nœud également utilisé en escalade, mais plus joli!)
J'ai également retravaillé sur le système de mesure de tension dans les lignes ("tensiomètre" ou "dynamomètre" mais ces noms ont d'autres significations).
J'aimerai obtenir quelque chose proche de ceci.
Pour rappel, j'ai pour l'instant réalisé un circuit électronique avec une jauge de contrainte récupérée sur une balance de voyage et un amplificateur (INA125). J'arrive à récupérer une mesure de l'effort sur mon pc via une carte arduino. Je cherche actuellement à améliorer le support mécanique de manière à pouvoir simplifier la mesure sur une ligne, en venant "pincer" la ligne.
 |
| 1ère version. La vis permet de modifier de manière continue la position de la poulie et ainsi le rapport de démultiplication |
 |
| Support, jauge de contrainte et poulie |
 |
| Dernière version du prototype. Des crans sont utilisés à la place de la vis pour alléger le tout. Cela ne permet pas l'installation directe sur une ligne très tendue, mais un peu de mou peut toujours être mis dans la ligne (éventuellement avec un système de pince) pour installer le capteur. |
samedi 1 mars 2014
Encodeur linéaire : fin
J'ai eu quelques déboires avec la règle électronique dont j'ai déjà parlé ici à maintes reprises :
http://robokite.blogspot.fr/2014/02/diy-regle-electronique-ou-encodeur.html
http://robokite.blogspot.fr/2014/02/regle-electronique-cablage-et-programme.html
http://robokite.blogspot.fr/2014/02/regle-electonique.html
http://robokite.blogspot.fr/2014/02/open-atelier-slider.html
http://robokite.blogspot.fr/2014/02/regle-electronique.html
http://robokite.blogspot.fr/2014/01/open-atelier.html
Au niveau du circuit, la règle électronique utilise 3 opto-coupleurs. Ces composants sont constitués chacun d'une diode IR et d'un récepteur. J'ai trouvé un exemple de montage sur monclubélec. La diode est en série avec une résistance qui sert à limiter le courant passant dans la diode. La valeur proposée était de 270ohms. Les données techniques de la diode indique qu'elle peut tenir jusqu'à 60mA et a une chute de tension de 1.2 à 1.6V (à 20mA). Avec une alimentation en 5V, la différence de potentiel au borne de la résistance est donc de 3.8V ce qui donne une intensité (max) de 14mA. Cela semblait suffisant lors de l'utilisation des diodes séparément. Les trois montages des diodes étant identiques, j'ai pensé qu'il était possible de relier les trois circuits entre la résistance et la diode (où le potentiel doit être identique). Cela permettait alors de remplacer les trois résistances en parallèle par une résistance de 270/3=90 ohms. Une inquiétude était qu'en cas de rupture d'une diode, le courant soit supérieur dans les diodes restantes et les endommage également. Mais avec 90 ohms, cela restait bon (40mA sur 60mA) même avec une seule diode.
Cependant à l'usage, j'ai eu des problèmes, les diodes n'étant pas strictement identiques, le courant passait plus dans une des diodes que dans les autres. Le courant n'était alors pas suffisant dans une diode. Si l'interruption du flux infrarouge restait détectable sur les entrées analogiques, les entrées numériques ne voyaient plus la différence. Or elles sont nécessaires pour les "interrupts".
J'ai finalement séparé les trois circuits d'alimentation (et diminué la résistance à 120ohms, pour obtenir 30mA).
Une autre piste était d'améliorer la sensibilité du détecteur. J'ai ainsi changé les résistances de 4.7kOhms par des résistance de 2.5kOhms
http://robokite.blogspot.fr/2014/02/diy-regle-electronique-ou-encodeur.html
http://robokite.blogspot.fr/2014/02/regle-electronique-cablage-et-programme.html
http://robokite.blogspot.fr/2014/02/regle-electonique.html
http://robokite.blogspot.fr/2014/02/open-atelier-slider.html
http://robokite.blogspot.fr/2014/02/regle-electronique.html
http://robokite.blogspot.fr/2014/01/open-atelier.html
Au niveau du circuit, la règle électronique utilise 3 opto-coupleurs. Ces composants sont constitués chacun d'une diode IR et d'un récepteur. J'ai trouvé un exemple de montage sur monclubélec. La diode est en série avec une résistance qui sert à limiter le courant passant dans la diode. La valeur proposée était de 270ohms. Les données techniques de la diode indique qu'elle peut tenir jusqu'à 60mA et a une chute de tension de 1.2 à 1.6V (à 20mA). Avec une alimentation en 5V, la différence de potentiel au borne de la résistance est donc de 3.8V ce qui donne une intensité (max) de 14mA. Cela semblait suffisant lors de l'utilisation des diodes séparément. Les trois montages des diodes étant identiques, j'ai pensé qu'il était possible de relier les trois circuits entre la résistance et la diode (où le potentiel doit être identique). Cela permettait alors de remplacer les trois résistances en parallèle par une résistance de 270/3=90 ohms. Une inquiétude était qu'en cas de rupture d'une diode, le courant soit supérieur dans les diodes restantes et les endommage également. Mais avec 90 ohms, cela restait bon (40mA sur 60mA) même avec une seule diode.
Cependant à l'usage, j'ai eu des problèmes, les diodes n'étant pas strictement identiques, le courant passait plus dans une des diodes que dans les autres. Le courant n'était alors pas suffisant dans une diode. Si l'interruption du flux infrarouge restait détectable sur les entrées analogiques, les entrées numériques ne voyaient plus la différence. Or elles sont nécessaires pour les "interrupts".
J'ai finalement séparé les trois circuits d'alimentation (et diminué la résistance à 120ohms, pour obtenir 30mA).
 |
| Ajout des résistances directement sur le fil... |
 |
| Résistances recouverte de gaine thermo (il aurait mieux fallu en prendre de la transparente) |
 |
| Coulisseau sur règle (doublée) |
 |
| Connectique |
 |
| Circuit (3 résistances de pull up) et carte d'acquisition arduino |