Samedi soir les conditions étaient propices pour faire quelques tests.
Au moment de partir, mauvaise surprise, la mesure de l'angle de barre ne fonctionnait plus : un des fils relié au potentiomètre a lâché, malgré l'ajout du carénage, probablement à cause de la tension dans le fil. Un petit coup de fer à souder et le problème était réglé.
Une autre de mes inquiétudes était de ne pas réussir à lire sur mon écran (brillant). J'ai donc testé différents sacs, avec l'intention de les utiliser comme chambre noir, protégeant à la fois de la lumière et du sable.
Avant d'aller sur la plage, j'ai également vérifié la bonne tenue du capteur embarqué sur l'aile, en la gonflant dans le jardin et en simulant quelques crashs : rien à signaler de ce côté.
Cette fois, plutôt que de remplir des sacs de sables, nous avons profité de la coque d'un catamaran de sport pour servir d'ancre. La station sol a été fixée au niveau du chariot, par là où les efforts de la grand voile sont normalement transmis. Le vent était de mer et la marée montante, mais grâce au catamaran, on a pu se mettre au bord de l'eau grâce à la possibilité de pouvoir le déplacer facilement avec son chariot.
Nous avons commencé par dérouler les lignes. J'ai merdé à ce moment, ce qui nous vaudra une bonne demi-heure pour les démêler avec Jean-Jacques.
J'ai relancé les programmes sur l'ordi (les programmes ne se relancent pas bien après la mise en veille).
Une fois prêt, Antoine est venu nous filer un coup de main pour décoller l'aile. Pour que l'aile décolle, il a fallu raccourcir au maximum les lignes avant avec le trim pour choquer la voile.
Le vent était un peu irrégulier (peut-être aurions-nous dû aller plus loin sur la plage pour éviter les perturbations liées à la pointe au vent, et aux arbres sous le vent). Même en pilotage manuel, l'aile, une fois proche du zénith, avait tendance à décrocher et à tomber. Je ne l'ai pas envisagé à ce moment, mais peut-être que le surpoids lié au capteur embarqué, fixé vers le bord d'attaque y était pour quelque chose. Border plus la voile, une fois décollée, semble également grandement aider (c'est là qu'on se rend compte que le border-choquer n'est pas facultatif!).
Les premiers essais de pilotage au joystick ne donnaient pas satisfaction. D'abord la barre ne coulissait pas bien sur la ligne centrale, notamment si cette dernière n'était pas totalement sous tension. Changer la position des points d'accroche (pour les remettre aux extrémités de la barre) a réglé ce problème.
Le passage du contrôle manuel au contrôle en joystick étant délicat, j'ai essayé de décoller en contrôlant directement au joystick. L'aile était lancée en bord de fenêtre, mais même joystick à fond, impossible de faire partir l'aile vers le zenith. J'ai commencé par supprimer la poulie permettant un renvoi pour permettre un largage de l'aile (cela augmente théoriquement par 2 l'amplitude, aux petits angles en tout cas!). Mais cela n'était pas satisfaisant.
J'ai supprimé les élastiques. Mais cela ne marchait toujours pas...
A ce moment, j'ai eu l'impression que le moteur servant à la direction tournait dans le sens opposé au sens attendu...J'ai changé le signe dans le programme et rechargé : c'était toujours à l'envers. J'ai rechangé le signe et tout marchait...
Je crois aussi que c'est à ce moment que j'ai enlevé le capteur embarqué (dont les signaux n'étaient de toute manière pas reçus).
Toujours est-il qu'ensuite cela marchait beaucoup mieux. Mon père est allé lancer l'aile et Antoine m'aidait à piloter l'aile (en tirant directement sur les lignes), le temps qu'elle soit stabilisée et que j'ai pu prendre le joystick. Les lignes arrières étaient également plus bordées que sur les premiers essais (pas de contrôle si les lignes arrières sont lâchées et risque de décrochage). Cela va dans le sens d'ajouter une régulation sur le bordé choqué (en position ou avec un retour d'effort en se basant sur une mesure de la tension dans les lignes).
Le pilotage est assez agréable grâce à la régulation assurée par le capteur d'angle de barre (plus besoin de regarder la barre comme l'année dernière) Grâce au retour au neutre sur le joystick, il suffit de relâcher le joystick pour que l'aile arrête de tourner. Et mettre des petits coups de joystick (un peu trop réactif de base d'ailleurs) pour stopper l'aile si elle se met à partir d'un côté ou de l'autre. Malheureusement plus assez de mémoire pour avoir une vidéo!
Nous avons eu un souci avec le potentiomètre du capteur de barre qui s'est décroché une fois. Il est pour l'instant simplement encastrer, et il faudra prévoir une sécurité (vis, anneau brisé) pour que cela ne se reproduise plus (d'un autre côté cela peut aussi servir de fusible...).
Nous avons eu plusieurs fois des problèmes de surpattage, principalement au niveau des lignes de direction. Des élastiques, ou une régulation en tension pourraient régler cela (enerkite utilise un petit sytème assurant la tension sur le treuil principal). Il faut que je trouve un moyen de simuler (manuellement) une dévente sur le banc de test.
Nous avons voulu tester également le pilotage automatique, mais les signaux du capteur embarqué n'étaient pas reçus. Après avoir rapproché le capteur, du récepteur radio, et débranché/rebranché la pile, cela a fonctionné quelques secondes, avant de ne plus marcher. Y-a-t-il un problème de batterie (elle était chargée à bloc, ce qui permet d'avoir au moins 1h d'autonomie)? Ou un problème d'interférence avec le capteur de barre? Ou bien le capteur a-t-il pris un choc dans les crashs (pas visible en tout cas)? A creuser avant les prochains essais.
L'aventure du développement des systèmes de pilote automatique de cerfs-volants : idées, technologies et applications.
Pages
▼
lundi 27 juillet 2015
vendredi 24 juillet 2015
Evolutions du jour
Aujourd'hui :
Pour bientôt :
- Ajout de saturation logiciel de l'angle de barre quelque soit le mode.
- Amélioration de robustesse au déconnexion/reconnexion des câbles
Pour bientôt :
- Ajout d'une latte sur une barre de kite standard pour maintenir la barre afin d'utiliser le capteur de barre même pour un cerf-volant à 2 lignes.
- Faire tourner le programme sur le raspberry
- Réfléchir à la robustesse du capteur de barre (avant de le casser!), si le cerf-volant (et les lignes) traîne sur le sol.
- Prévoir un algo alternatif pour stabiliser (pour l'instant un écart, fais tourner les moteurs, alors qu'un écart pourrait commander directement une nouvelle position de la barre)
Ptites News
Voici une sélection de liens (principalement issus de la mailing list AirborneWindEnergy@yahoogroups.com).
Voici des tutoriels pour mettre une petite turbine sur un kite
http://www.instructables.com/id/Electricity-Generating-Kite/step5/Fly-it/
http://www.instructables.com/id/Kite-with-Wind-Powered-LEDs/
Une étude (pas toute récente) sur l'utilisation d'un kite pour faire des relevés météos
http://www.researchgate.net/publication/36170557_A_quantitative_study_of_kite_performance_in_natural_wind_with_application_to_kite_anemometry_microform_
Une vidéo d'un cerf-volant faisant office de navette sur la ligne d'un autre cerf-volant (avec une gopro comme charge)
Un article sur un programme irlandais visant à utiliser les cerfs-volants pour augmenter la portée des capteurs sur les navires.
http://www.engineersjournal.ie/ship-mounted-kite-system-enhance-efficiency-communications-unveiled-defence-forces/
Un article sur la pollution du transport maritime
http://www.lemonde.fr/planete/article/2015/07/22/la-pollution-du-transport-maritime-plus-dangereuse-que-celle-du-transport-automobile_4694015_3244.html
Une présentation de Nedeleg, en thèse à l'ENSTA Bretagne
http://www.ensta-bretagne.fr/index.php/nedeleg-mene-des-recherches-sur-la-traction-par-kite/
Voici des tutoriels pour mettre une petite turbine sur un kite
http://www.instructables.com/id/Electricity-Generating-Kite/step5/Fly-it/
http://www.instructables.com/id/Kite-with-Wind-Powered-LEDs/
Une étude (pas toute récente) sur l'utilisation d'un kite pour faire des relevés météos
http://www.researchgate.net/publication/36170557_A_quantitative_study_of_kite_performance_in_natural_wind_with_application_to_kite_anemometry_microform_
Une vidéo d'un cerf-volant faisant office de navette sur la ligne d'un autre cerf-volant (avec une gopro comme charge)
Un article sur un programme irlandais visant à utiliser les cerfs-volants pour augmenter la portée des capteurs sur les navires.
http://www.engineersjournal.ie/ship-mounted-kite-system-enhance-efficiency-communications-unveiled-defence-forces/
Un article sur la pollution du transport maritime
http://www.lemonde.fr/planete/article/2015/07/22/la-pollution-du-transport-maritime-plus-dangereuse-que-celle-du-transport-automobile_4694015_3244.html
Une présentation de Nedeleg, en thèse à l'ENSTA Bretagne
http://www.ensta-bretagne.fr/index.php/nedeleg-mene-des-recherches-sur-la-traction-par-kite/
jeudi 23 juillet 2015
Au boulot!
Hier de belles avancées (mais j'ai raté le vent!).
J'ai donc installé un banc de test en mode grenier (mon père recherche déjà ses boules de pétanque... )
Au niveau mécanique, j'ai modifié la position des élastiques, afin d'avoir un comportement moins élastique.
J'ai pu vérifier que les problèmes de pertes de données venant du capteur de barre, viennent bien d'un problème de surcharge de l'arduino de la station sol, et non d'un problème radio (même si j'ai pu également constater des problèmes d'interférence si le capteur embarqué est plus proche que l'émetteur du capteur de barre).
J'ai réussi à régler temporairement le problème en réduisant la fréquence à laquelle les ordres sont envoyés vers la carte Sabertooth. J'ai essayé ensuite d'améliorer l'ordonnancement des tâches en rajoutant des timers, mais le simple ajout d'un timer, suffisait à tout bloquer.
Je me suis ensuite rendu compte qu'il y avait un problème avec le code existant. Les fréquences d'envoi des feedbacks n'étaient par exemple pas respectées. Cela vient d'un problème d'utilisation de la librairie TinyGPS++ : je ne lisais pas certaines valeurs et ne regardais que si elles étaient mises à jour, pensant que la mise à jour signifiait qu'un nouveau message venait d'arriver. Or ceci n'est vrai que si on lit la valeur. Work in progress!
J'ai également pu tester une nouvelle manette (achetée aux puces de Quimiac le WE dernier). Ca fonctionne bien, mais la position des boutons n'est pas la même, ce qui m'a un peu surpris au début!
Tout à l'heure, je fais une petite démo pour Régis Leruste (cuistot par ordinateur), membre du fablab PlateformeC et voisin.
J'ai donc installé un banc de test en mode grenier (mon père recherche déjà ses boules de pétanque... )
Le banc de test. Des boules de pétanques servent de contrepoids pour simuler la tension dans les lignes |
Au niveau mécanique, j'ai modifié la position des élastiques, afin d'avoir un comportement moins élastique.
J'ai pu vérifier que les problèmes de pertes de données venant du capteur de barre, viennent bien d'un problème de surcharge de l'arduino de la station sol, et non d'un problème radio (même si j'ai pu également constater des problèmes d'interférence si le capteur embarqué est plus proche que l'émetteur du capteur de barre).
J'ai réussi à régler temporairement le problème en réduisant la fréquence à laquelle les ordres sont envoyés vers la carte Sabertooth. J'ai essayé ensuite d'améliorer l'ordonnancement des tâches en rajoutant des timers, mais le simple ajout d'un timer, suffisait à tout bloquer.
Je me suis ensuite rendu compte qu'il y avait un problème avec le code existant. Les fréquences d'envoi des feedbacks n'étaient par exemple pas respectées. Cela vient d'un problème d'utilisation de la librairie TinyGPS++ : je ne lisais pas certaines valeurs et ne regardais que si elles étaient mises à jour, pensant que la mise à jour signifiait qu'un nouveau message venait d'arriver. Or ceci n'est vrai que si on lit la valeur. Work in progress!
J'ai également pu tester une nouvelle manette (achetée aux puces de Quimiac le WE dernier). Ca fonctionne bien, mais la position des boutons n'est pas la même, ce qui m'a un peu surpris au début!
Tout à l'heure, je fais une petite démo pour Régis Leruste (cuistot par ordinateur), membre du fablab PlateformeC et voisin.
lundi 20 juillet 2015
Session de tests estivaux à Quimiac
Me voici à Quimiac pour potentiellement trois semaines (jusqu'au 7 aout). J'espère pouvoir faire avancer les développements de manière active en mode "grenier" (et non garage).
Si toi, lecteur, veux venir filer un coup de main et passer quelques jours au bord de la mer, n'hésite pas à me contacter.
L'objectif est de mieux rôder les tests sur la plage pour valider la nouvelle station sol et les nouveaux capteurs (suite aux tests peu concluants à Pornichet, et au Carnet cet hiver).
Avant cela, il va falloir remettre en place un banc de test pour résoudre quelques problèmes :
Au-delà de ces points, l'intégration de nouveaux capteurs est à prévoir :
Des algorithmes de pilotages de secours pourront alors être intégrés afin d'assurer une redondance, ou de permettre un choix dans les capteurs utilisés (éventuellement à terme une fusion de donnée, mais pas si simple à réaliser!)
Et pourquoi pas aussi rêver de tester le système sur l'eau, sur un bateau mobile, ou plus simplement à partir d'un bateau au mouillage.
Je laisse pour l'instant de côté la problèmatique d'autonomie énergétique du capteur embarqué (mini-éolienne en l'air) et la question de la production d'énergie.
En ce qui concerne la problématique du lancement/récupération, j'aimerais réaliser de petits tests avec des cerfs-volants monofils, sur un petit mat :
Pour faire voler un cerf-volant sans jamais le faire tomber, une solution pourrait-être un simple enrouleur élastique (un peu comme certaines laisses pour chien!). Si la tension est faible, la ligne se roule, créant un vent vitesse empêchant le cerf-volant de tomber. Si le vent est plus fort, le cerf-volant tire plus fort et déroule la ligne.
Si toi, lecteur, veux venir filer un coup de main et passer quelques jours au bord de la mer, n'hésite pas à me contacter.
L'objectif est de mieux rôder les tests sur la plage pour valider la nouvelle station sol et les nouveaux capteurs (suite aux tests peu concluants à Pornichet, et au Carnet cet hiver).
Avant cela, il va falloir remettre en place un banc de test pour résoudre quelques problèmes :
- mauvaise connexion radio avec le capteur de barre. Un retour à une connexion filaire (données+alimentation) est peut-être à envisager, éventuellement l'utilisation d'un autre kit radio.
- calibration et procédure de calibration du capteur de barre (suite au démontage/remontage)
- validation de la bonne tenue du capteur embarquée sur le cerf-volant, notamment en cas de violente secousse (chute du cerf-volant sur le sol).
Au-delà de ces points, l'intégration de nouveaux capteurs est à prévoir :
- mesure de la tension dans les lignes.
- une deuxième IMU montée sur les lignes au niveau du capteur de barre, et donnant l'orientation des lignes au niveau du sol.
- retour de l'intégration d'une caméra au niveau du sol (en wifi, ou en liaison filaire pour éviter les problèmes de latence observés).
Des algorithmes de pilotages de secours pourront alors être intégrés afin d'assurer une redondance, ou de permettre un choix dans les capteurs utilisés (éventuellement à terme une fusion de donnée, mais pas si simple à réaliser!)
Et pourquoi pas aussi rêver de tester le système sur l'eau, sur un bateau mobile, ou plus simplement à partir d'un bateau au mouillage.
Je laisse pour l'instant de côté la problèmatique d'autonomie énergétique du capteur embarqué (mini-éolienne en l'air) et la question de la production d'énergie.
En ce qui concerne la problématique du lancement/récupération, j'aimerais réaliser de petits tests avec des cerfs-volants monofils, sur un petit mat :
- faire voler le cerf-volant sans jamais le faire tomber
- utiliser des cerfs-volants en train pour un décollage avec vent faible au sol.
Pour faire voler un cerf-volant sans jamais le faire tomber, une solution pourrait-être un simple enrouleur élastique (un peu comme certaines laisses pour chien!). Si la tension est faible, la ligne se roule, créant un vent vitesse empêchant le cerf-volant de tomber. Si le vent est plus fort, le cerf-volant tire plus fort et déroule la ligne.
Petit tour sur le banc de test.
Jeudi et vendredi dernier, j'ai pu repasser au fablab Plateforme C avant sa fermeture estivale. J'ai remonté le banc afin d'essayer de tester les modifications réalisées lors de l'Open Atelier Version Etendue.
Le jeudi j'avais oublié le gamepad/joystick, mais j'ai pu vérifier le bon fonctionnement grâce à la possibilité d'utiliser un simple clavier en solution de secours (keyboard.py).
J'ai pu valider le fonctionnement des moteurs, des enregistrements, etc.
J'ai quelques soucis avec les informations reçues du capteur de barre. Celles-ci sont parfois freezées pendant environ une seconde... Ce qui peut-amener la boucle de régulation à des oscillations importantes.
Il faudra investiguer si ce problème apparaît à cause de perturbations radio, ou d'une saturation de la puissance de calcul de l'arduino.
J'ai également des problèmes sur l'amplitude max des mouvements de barre, qui dépasse difficilement +/-45° alors que l'on voudrait être à +/-90°.
Fabien Griffon de l'équipe Beyond The Sea (et d'autres) m'a plusieurs fois conseillé de faire disparaître la barre, mais j'aime l'idée de la garder en secours, et de pouvoir suivre les mouvements effectués par un pilote humain. Fabien me conseillait alors de mettre la barre seulement en parallèle (en venant accrocher les lignes de contrôle du pilote 1m au dessus de la barre, et non au dessus de la barre). J'ai fais quelques essais en déplaçant les points d'accroche, sur la barre, ou sur les lignes au dessus :
Le jeudi j'avais oublié le gamepad/joystick, mais j'ai pu vérifier le bon fonctionnement grâce à la possibilité d'utiliser un simple clavier en solution de secours (keyboard.py).
J'ai pu valider le fonctionnement des moteurs, des enregistrements, etc.
J'ai quelques soucis avec les informations reçues du capteur de barre. Celles-ci sont parfois freezées pendant environ une seconde... Ce qui peut-amener la boucle de régulation à des oscillations importantes.
Il faudra investiguer si ce problème apparaît à cause de perturbations radio, ou d'une saturation de la puissance de calcul de l'arduino.
J'ai également des problèmes sur l'amplitude max des mouvements de barre, qui dépasse difficilement +/-45° alors que l'on voudrait être à +/-90°.
Fabien Griffon de l'équipe Beyond The Sea (et d'autres) m'a plusieurs fois conseillé de faire disparaître la barre, mais j'aime l'idée de la garder en secours, et de pouvoir suivre les mouvements effectués par un pilote humain. Fabien me conseillait alors de mettre la barre seulement en parallèle (en venant accrocher les lignes de contrôle du pilote 1m au dessus de la barre, et non au dessus de la barre). J'ai fais quelques essais en déplaçant les points d'accroche, sur la barre, ou sur les lignes au dessus :
- si les points d'accroche sont au dessus de la ligne, la barre se met de travers et ne coulisse plus sur les fils (dès 1cm au dessus de la barre). Cela pourrait éventuellement être compensé par des élastiques tirant la barre vers le bas.
- si les points d'accroche sont proches du centre de la barre, cela permet en théorie pour une longueur de ligne donnée d'avoir un mouvement plus important de la barre. Dans les faits, une ligne se trouve tendue, l'autre complètement lâchée, mais à cause de la ligne centrale, et de la direction de la traction, la barre sature à environ 45°.
- si les points d'accroche sont au bout de la barre, l'amplitude nécessaire de changement de longueur de fil devient plus grande. Mais de même l'effort pour faire tourner la barre augmente avec l'angle. A cause de l'utilisation d'élastique, l'amplitude du différentiel de longueur de ligne limite alors le mouvement.
- si les points d'accroche sont au bout de la la barre, juste au niveau de l'accroche des lignes, mais accrochés de manière rigide à la barre, la barre peut coulisser correctement et on bénéficie d'un décalage de quelques centimètres permettant de gagner de précieux degrés d'amplitude max.
Le simple fait de décaler le point d'accroche de quelques centimètres perpendiculairement à la barre, permet de gagner en amplitude de mouvement. |
mardi 14 juillet 2015
Schéma électronique
Depuis quelques temps, je suis en retard sur la documentation, notamment sur les schémas d'architecture ou les schémas des circuits électroniques.
D'autre part, j'ai parfois des problèmes de robustesse, liés à l'utilisation des breadboards.
Pour certains circuits, j'ai fait le choix de me passer d'un circuit électronique. Mais pour d'autres circuits, ou pour faire plus propre, il me faut concevoir des shields autour des arduinos nano que j'utilise.
J'ai envisagé l'utilisation de différents outils libres : GEDA, Kicad et Fritzing.
J'ai tout d'abord regardé GEDA.
Je pense que GEDA est un outil de niveau industriel permettant de réaliser des circuits électroniques. Je l'ai trouvé assez peu intuitif, et ne permettant pas de réaliser de la documentation pour un montage breadboard par exemple.
Au contraire Fritzing semble bien mieux adapté pour réaliser de la documentation de circuit de test avec différentes cartes (arduino, raspberry pi)
Une difficulté était que les composants que j'ai utilisés n'étaient pas disponibles dans la bibliothèque de base (et pas trouvable sur internet).
J'ai trouvé un bon tutoriel donnant des conseils pour la réalisation de nouvelles pièces, petit à petit en partant d'anciennes.
Voici quelques limitations/critiques/remarques sur l'utilisation de Fritzing :
En ce qui concerne, le problème des fichiers zip sous git, cela ne semble pas prévu de base. Quelques "workaround" semblent possibles :
https://tante.cc/2010/06/23/managing-zip-based-file-formats-in-git/
http://stackoverflow.com/questions/8001663/can-git-treat-zip-files-as-directories-and-files-inside-the-zip-as-blobs
Cependant, le fait qu'un composant soit éclaté entre plusieurs répertoires ne permet pas d'utiliser un script générique pour mettre à plat les zip.
En attendant de réaliser un script dédié pour améliorer tout ça, ou de suggérer des modifs/extensions au code du programme, voici quelques images des résultats :
D'autre part, j'ai parfois des problèmes de robustesse, liés à l'utilisation des breadboards.
Pour certains circuits, j'ai fait le choix de me passer d'un circuit électronique. Mais pour d'autres circuits, ou pour faire plus propre, il me faut concevoir des shields autour des arduinos nano que j'utilise.
J'ai envisagé l'utilisation de différents outils libres : GEDA, Kicad et Fritzing.
J'ai tout d'abord regardé GEDA.
Je pense que GEDA est un outil de niveau industriel permettant de réaliser des circuits électroniques. Je l'ai trouvé assez peu intuitif, et ne permettant pas de réaliser de la documentation pour un montage breadboard par exemple.
Au contraire Fritzing semble bien mieux adapté pour réaliser de la documentation de circuit de test avec différentes cartes (arduino, raspberry pi)
Une difficulté était que les composants que j'ai utilisés n'étaient pas disponibles dans la bibliothèque de base (et pas trouvable sur internet).
J'ai trouvé un bon tutoriel donnant des conseils pour la réalisation de nouvelles pièces, petit à petit en partant d'anciennes.
Voici quelques limitations/critiques/remarques sur l'utilisation de Fritzing :
- Il n'est pas possible de relier des composants par de câbles (type USB) mais seulement fil à fil.
- Des imports sont possibles à partir de GEDA et Kicad (voir ligne de commande).
- Les pièces et les montages sont décrits par des fichiers textes (xml, svg). Ces fichiers sont cependant zippés lors d'un export/import. Faire à la fois le suivi de version (en terme de mémoire et de facilité de suivi des modifications), et installer simplement une bibliothèque n'est donc pas aisé.
- Les composants du montage sont décrits grâce à des chemins absolus. Les "sources" des schémas sont donc difficiles à partager entre plusieurs utilisateurs (du coup les composants non standards, sont ajoutés par défaut dans chaque partage, sans liberté à l'utilisateur d'installer ses propres composants)
- De plus, dans l'architecture des fichiers par défaut, les éléments d'un composants seront partagés entre différents répertoires.
- Certains composants sont par exemple dans /usr/share/fritzing/pdb/core/, d'autres dans ~/.config/fritzing
- J'ai eu des problèmes pour l'export svg (certains composants n'apparaissent pas)
En ce qui concerne, le problème des fichiers zip sous git, cela ne semble pas prévu de base. Quelques "workaround" semblent possibles :
https://tante.cc/2010/06/23/managing-zip-based-file-formats-in-git/
http://stackoverflow.com/questions/8001663/can-git-treat-zip-files-as-directories-and-files-inside-the-zip-as-blobs
Cependant, le fait qu'un composant soit éclaté entre plusieurs répertoires ne permet pas d'utiliser un script générique pour mettre à plat les zip.
En attendant de réaliser un script dédié pour améliorer tout ça, ou de suggérer des modifs/extensions au code du programme, voici quelques images des résultats :
Circuit emplificateur pour la jauge de contrainte |
On a marché sur la Lune
Il y a quelques temps j'évoquais l'idée d'un kite accroché au bout de la grue Titan. Cela pouvait poser des problèmes pour ce monument historique.
Cette année, dans le cadre du voyage à Nantes, une terre lumineuse a été suspendue sous la grue. Alors pourquoi pas un kite lumineux réalisant des figures acrobatiques l'année prochaine?
Cette année, dans le cadre du voyage à Nantes, une terre lumineuse a été suspendue sous la grue. Alors pourquoi pas un kite lumineux réalisant des figures acrobatiques l'année prochaine?
La terre sous la grue Titan |
lundi 6 juillet 2015
Mécatronique
La semaine dernière j'ai travaillé sur l'intégration des capteurs embarqués sur une plaquette rentrant dans une pochette étanche (normalement pour téléphone portable)
J'ai également amélioré l'intégration des capteurs dans le bras articulé servant de capteur pour la position de l'angle de barre.
La première chose a été d'allonger les bras qui étaient un peu courts pour certaines barres de kite. Je peux maintenant mesurer jusqu'à 38cm de border- choquer.
Une deuxième chose a été de déplacer la plaque pour monter l'arduino, l'antenne et la batterie de la partie se fixant sur la ligne avec un scratch pour la mettre sur le bras supérieur.
Cela permet de faciliter l'installation du composant, mais également d'avoir un effet pendule sur le bras.
J'ai également améliorer l'intégration pour pouvoir fixer fermement les composants.
Enfin, un carénage a été rajouté pour protéger les connections du potentiomètre qui avaient déjà lâché plusieurs fois.
J'ai également amélioré l'intégration des capteurs dans le bras articulé servant de capteur pour la position de l'angle de barre.
La première chose a été d'allonger les bras qui étaient un peu courts pour certaines barres de kite. Je peux maintenant mesurer jusqu'à 38cm de border- choquer.
Une deuxième chose a été de déplacer la plaque pour monter l'arduino, l'antenne et la batterie de la partie se fixant sur la ligne avec un scratch pour la mettre sur le bras supérieur.
Cela permet de faciliter l'installation du composant, mais également d'avoir un effet pendule sur le bras.
J'ai également améliorer l'intégration pour pouvoir fixer fermement les composants.
Enfin, un carénage a été rajouté pour protéger les connections du potentiomètre qui avaient déjà lâché plusieurs fois.
Nouveau capteur de barre |
Pour rappel, sans carénage, les fils cassaient régulièrement |
Carénage pour protéger les connections du potentiomètre |
Intégration capteurs embarquées |
Dual Aircraft Platform
Voici un article sur un système de transport aérien constitué de 2 kites reliés par un câble et volant grâce au gradient de la vitesse du vent entre les altitudes des deux kites.
Ultra Wide Band Positioning
Voici un projet kickstarter pour un système de positionnement proche du GPS, mais fonctionnant avec des balises locales, même à l'intérieur. Une piste pour un positionnement plus précis des kites?
jeudi 2 juillet 2015
Problème kit télémetrie.
Voici une petite liste de menu-tâche à faire
Suite à un problème d'arrachage du connecteur microUSB de la partie sol du kit de télémétrie, et devant la difficulté de ressouder des pièces aussi petites, j'ai changé la partie sol par une partie venant d'un précédent kit où j'avais cassé le connecteur sur la partie air..
Au début ça ne marchait pas.
j'ai téléchargé le logiciel de configuration http://ardupilot.com/downloads/?did=89 (.exe qui a tourné sous linux, grâce à wine ou mono). J'ai pu vérifier que la configuration s'établissait bien entre les deux parties, et rétablir la configuration par défaut.
Mais la communication ne fonctionnait pas. J'ai tenté d'inverser TX et RX (que je n'avais pas croisé) et ça a fonctionné!
Bon, j'avais déjà recommandé un nouveau kit avant de refaire la manip, mais cela va me permettre de gagner du temps sur les tests (et d'avoir un kit de rab!).
- Raccourcir les fils de connexion
- Modification du code afin d'utiliser les pins digitales pour créer une masse et une alimentation 5V (avec faible ampérage) pour l'IMU (pour simplifier le cablage en évitant d'avoir plusieurs connexions sur un même fil).
- Changement du connecteur 9V qui s'est abimé
Suite à un problème d'arrachage du connecteur microUSB de la partie sol du kit de télémétrie, et devant la difficulté de ressouder des pièces aussi petites, j'ai changé la partie sol par une partie venant d'un précédent kit où j'avais cassé le connecteur sur la partie air..
Au début ça ne marchait pas.
j'ai téléchargé le logiciel de configuration http://ardupilot.com/downloads/?did=89 (.exe qui a tourné sous linux, grâce à wine ou mono). J'ai pu vérifier que la configuration s'établissait bien entre les deux parties, et rétablir la configuration par défaut.
Mais la communication ne fonctionnait pas. J'ai tenté d'inverser TX et RX (que je n'avais pas croisé) et ça a fonctionné!
Bon, j'avais déjà recommandé un nouveau kit avant de refaire la manip, mais cela va me permettre de gagner du temps sur les tests (et d'avoir un kit de rab!).