Aujourd'hui j'ai essayé de voir s'il était possible de trouver des alternatives aux programmes sensorUDP et IPWebcam que je conseille d'utiliser (voir le wiki) pour envoyer des données depuis le téléphone android.
sensorUDP a l'avantage d'être open source. Le code n'est malheureusement plus mis à jour.
Les problèmes principaux sont :
-impossible d'arrêter l'application sans la killer (elle reste à tourner en tâche de fond, sans même demander)
-le paramétrage doit être refait à chaque utilisation (adresse ip, port, débit d'information)
L'application "IMU+GPS-stream" a le même problème concernant le paramétrage, peut-être arrêtée, mais ne peut pas tourner en tâche de fond.
Je n'ai donc pas trouvé d'alternatives. N'hésitez pas à proposer une autre solution!
L'application IPWebcam est vraiment bien, mais le code source n'est pas disponible. J'ai trouvé Spydroid, mais qui ne fonctionne pas pour la vidéo sur mon téléphone. Je me suis par contre bien amusé avec la fonction qui permet de lancer des bruits d'animaux sur son téléphone depuis son ordinateur !
J'ai également réfléchi à l'achat d'un caisson étanche pour mon téléphone. Je voulais initialement bidouiller des tupperwares pour tout ce qui doit être protégé, mais ils ne sont en général pas assez transparent pour la camera, et ne permettent pas d'utiliser l'interface du téléphone, ce qui peut-être pratique. Il y aurait aussi la solution sachet en plastique zip lock mais j'ai vu quelques essais sur internet et la vidéo est mauvaise, à moins de découper le sac et de rajouter une lentille.
Il existe des caissons étanches suffisamment transparent et en plastique souple permettant d'utiliser l'écran. On en trouve pour 15 à 30 euros.
mercredi 31 juillet 2013
mardi 30 juillet 2013
Un peu de kite!
Le vent étant enfin de retour ici (à Quimiac), je suis allé faire un peu de kite à Pont-Mahé, ce spot qui est aussi un super lieu pour des essais.
J'ai commencé par naviguer, puis suis resté juste avec l'aile pour réfléchir quelques minutes à l'installation d'un système sur une aile existante.
Le vent était régulier d'une vingtaine de nœuds et j'utilisais une aile best waroo de 11m2 avec une barre best (environ 40cm de longueur).
Je ne connais pas la longueur de mes lignes, mais disons 25m.
J'ai d'abord essayé de mesurer l'angle de l'aile au zenith. Pas facile depuis le bas des lignes. Plus que 45°. Je pense environ 60°. J'ai ensuite essayé d'estimer la force dans le kite, en essayant de prendre à la main le point d'accroche des lignes avants. L'aile au zenith j'arrive à tirer l'aile à la main vers moi, mais c'est dur. Je pense que la traction est d'une dizaine de kilo.
Autre repère, l'inclinaison de mon corps par rapport à la verticale que je dirais d'environ 5°. Le centre de gravité étant situé à 55% de la stature, cela donne pour une taille de 1.8m un centre de gravité à 1m du sol.
Le couple lié au poids serait alors de 70N.m environ.
Si l'on considère l'équilibre avec le couple créé par le kite cela donne en considérant que le point d'accroche du kite est au niveau du centre de gravité
F*sin(90-69+5)*1=70N.m soit 12kg, ce qui est cohérent.
Notons au passage, que cette démarche de calcul, pourrait-être appliquée à des photos de kiter en navigation pour estimer la force et la puissance (si l'on connait la vitesse), comme le faisait Jim Drake, l'inventeur de la planche à voile (maintenant décédé) et que j'avais rencontré il y a quelques années.
Je me suis ensuite amusé à chronométrer le temps que je pouvais mettre à envoyer l'aile d'un bord de fenêtre à l'autre tout en conservant le contrôle, c'est à dire en passant presque par le zénith. Il faut environ 6s pour faire moins de 180° (disons 150°), soit 12s aller retour. Cela donne environ 25°/s.
Pour une latence actuelle du positionnement vidéo de 0.5s à 1s cela donne une idée des performances qui peuvent être attendues sans contrôle prédictif.
J'ai ensuite essayé de donner des commandes de barres +/100% et de voir le temps de réaction de l'aile.
Ce temps de réaction dépend du bordé-choqué. Je ne pouvais guère faire plus d'une 1s de chaque côté, soit 2s de période. Au delà le kite pouvait devenir trop puissant.
Lorsque la voile était choquée, le kite tournait d'environ 15°, sans qu'un régime permanent soit vraiment obtenus (retards importants)
Lorsque la voile était bordée, le kite tournait d'environ 45°.
Le retard n'est pas négligeable, surtout lorsque les lignes sont choquées. Les lignes arrières sont alors un peu flottantes (pas vraiment sous tension) et la vitesse de propagation des ondes dans un câble varie avec la racine carrée de la tension (voir l'article wikipedia http://fr.wikipedia.org/wiki/Onde_sur_une_corde_vibrante). Le retard est de l'ordre de 0.5s.
Heureusement, le kite est également moins sensible aux perturbations dans ce cas.
J'ai trouvé sur ce site http://www.michigankoi.com/KEVLAR-KITE-LINE-KITE-AND-LINE-sc-437.html un exemple de données sur les caractéristiques des lignes. Pour 50kg de résistance, on a donc environ 100g pour 300m. Je pense que c'est plus pour des lignes de kite qui ont des résistances de 300kg environ. Si l'on multiplie le poids par 6 (au pif...), et que l'on considère que la tension dans les arrières et 10% de celle des avants, et que l'on oublie de compter le nombre de lignes, on arrive à une vitesse de 70m/s et l'on retrouve environ le retard estimé de 0.5s (très grossièrement et aux ordres de grandeur d'erreur près.).
Concernant la stabilité de l'aile, l'aile est instable lorsque la voile est choquée, mais stable lorsque la voile est bordée. Il n'y aurait donc quasiment pas besoin de pilote automatique dans ce cas là!
J'ai très bien réussi à piloter en fermant les yeux. Pour cela, j'utilise surtout le ressenti des efforts au niveau du harnais, qui me donne la direction du cerf-volant. Cela reste cependant assez vague et n'est pas suffisamment précis pour faire du pilotage près du sol.
J'ai réfléchi à la disposition des capteurs.
Pour la caméra, c'est assez clair : il faut la placer sur les lignes avants à l'endroit où les deux lignes se séparent. Il y a alors un petit v d'une quinzaine de ° qui permettra de stabiliser la caméra. Les lignes avants sont tout le temps sous tension et bien dirigées vers le cerfs-volant. Je n'ai pas trouvé de vidéo sur youtube avec une gopro à ce niveau, mais je pense que çela a déjà été fait.
Pour le capteur d'angle de barre, je pense qu'il faut rajouter une petite gaine coulissante d'une dizaine de cm sur les lignes avant, sous la barre et fixer un levier entre cette gaine et la barre. Un petit potard verra ensuite l'affaire.
Il est apparu plus haut que la position du bordé-choqué est importante sur la dynamique de l'aile, même en rotation. Je n'ai pas trouvé de solution élégante pour faire cette mesure. Un système de poulie avec aller-retour? Un capteur optique? Une résistance linéaire?
Une autre difficulté est les mouvements de rotations de la barre autour de l'axe des lignes avants. Comment faire pour empêcher cette rotation et amortir les mouvements de barre afin que ce ne soit pas dangereux? En utilisant des petits sandows?
Je suis ensuite reparti naviguer. J'ai noté une dernière chose, qui est l'importance de l'horizon pour le placement de l'aile en navigation, notamment lors de la navigation au près. Le bas de l'aile est à environ 1 largeur à 2 largeurs du sol. Une telle précision ne peut je pense être atteinte que par un positionnement relatif (par exemple visuel).
J'ai commencé par naviguer, puis suis resté juste avec l'aile pour réfléchir quelques minutes à l'installation d'un système sur une aile existante.
Le vent était régulier d'une vingtaine de nœuds et j'utilisais une aile best waroo de 11m2 avec une barre best (environ 40cm de longueur).
Je ne connais pas la longueur de mes lignes, mais disons 25m.
J'ai d'abord essayé de mesurer l'angle de l'aile au zenith. Pas facile depuis le bas des lignes. Plus que 45°. Je pense environ 60°. J'ai ensuite essayé d'estimer la force dans le kite, en essayant de prendre à la main le point d'accroche des lignes avants. L'aile au zenith j'arrive à tirer l'aile à la main vers moi, mais c'est dur. Je pense que la traction est d'une dizaine de kilo.
Autre repère, l'inclinaison de mon corps par rapport à la verticale que je dirais d'environ 5°. Le centre de gravité étant situé à 55% de la stature, cela donne pour une taille de 1.8m un centre de gravité à 1m du sol.
Le couple lié au poids serait alors de 70N.m environ.
Si l'on considère l'équilibre avec le couple créé par le kite cela donne en considérant que le point d'accroche du kite est au niveau du centre de gravité
F*sin(90-69+5)*1=70N.m soit 12kg, ce qui est cohérent.
Notons au passage, que cette démarche de calcul, pourrait-être appliquée à des photos de kiter en navigation pour estimer la force et la puissance (si l'on connait la vitesse), comme le faisait Jim Drake, l'inventeur de la planche à voile (maintenant décédé) et que j'avais rencontré il y a quelques années.
Je me suis ensuite amusé à chronométrer le temps que je pouvais mettre à envoyer l'aile d'un bord de fenêtre à l'autre tout en conservant le contrôle, c'est à dire en passant presque par le zénith. Il faut environ 6s pour faire moins de 180° (disons 150°), soit 12s aller retour. Cela donne environ 25°/s.
Pour une latence actuelle du positionnement vidéo de 0.5s à 1s cela donne une idée des performances qui peuvent être attendues sans contrôle prédictif.
J'ai ensuite essayé de donner des commandes de barres +/100% et de voir le temps de réaction de l'aile.
Ce temps de réaction dépend du bordé-choqué. Je ne pouvais guère faire plus d'une 1s de chaque côté, soit 2s de période. Au delà le kite pouvait devenir trop puissant.
Lorsque la voile était choquée, le kite tournait d'environ 15°, sans qu'un régime permanent soit vraiment obtenus (retards importants)
Lorsque la voile était bordée, le kite tournait d'environ 45°.
Le retard n'est pas négligeable, surtout lorsque les lignes sont choquées. Les lignes arrières sont alors un peu flottantes (pas vraiment sous tension) et la vitesse de propagation des ondes dans un câble varie avec la racine carrée de la tension (voir l'article wikipedia http://fr.wikipedia.org/wiki/Onde_sur_une_corde_vibrante). Le retard est de l'ordre de 0.5s.
Heureusement, le kite est également moins sensible aux perturbations dans ce cas.
J'ai trouvé sur ce site http://www.michigankoi.com/KEVLAR-KITE-LINE-KITE-AND-LINE-sc-437.html un exemple de données sur les caractéristiques des lignes. Pour 50kg de résistance, on a donc environ 100g pour 300m. Je pense que c'est plus pour des lignes de kite qui ont des résistances de 300kg environ. Si l'on multiplie le poids par 6 (au pif...), et que l'on considère que la tension dans les arrières et 10% de celle des avants, et que l'on oublie de compter le nombre de lignes, on arrive à une vitesse de 70m/s et l'on retrouve environ le retard estimé de 0.5s (très grossièrement et aux ordres de grandeur d'erreur près.).
Concernant la stabilité de l'aile, l'aile est instable lorsque la voile est choquée, mais stable lorsque la voile est bordée. Il n'y aurait donc quasiment pas besoin de pilote automatique dans ce cas là!
J'ai très bien réussi à piloter en fermant les yeux. Pour cela, j'utilise surtout le ressenti des efforts au niveau du harnais, qui me donne la direction du cerf-volant. Cela reste cependant assez vague et n'est pas suffisamment précis pour faire du pilotage près du sol.
J'ai réfléchi à la disposition des capteurs.
Pour la caméra, c'est assez clair : il faut la placer sur les lignes avants à l'endroit où les deux lignes se séparent. Il y a alors un petit v d'une quinzaine de ° qui permettra de stabiliser la caméra. Les lignes avants sont tout le temps sous tension et bien dirigées vers le cerfs-volant. Je n'ai pas trouvé de vidéo sur youtube avec une gopro à ce niveau, mais je pense que çela a déjà été fait.
Pour le capteur d'angle de barre, je pense qu'il faut rajouter une petite gaine coulissante d'une dizaine de cm sur les lignes avant, sous la barre et fixer un levier entre cette gaine et la barre. Un petit potard verra ensuite l'affaire.
Il est apparu plus haut que la position du bordé-choqué est importante sur la dynamique de l'aile, même en rotation. Je n'ai pas trouvé de solution élégante pour faire cette mesure. Un système de poulie avec aller-retour? Un capteur optique? Une résistance linéaire?
Une autre difficulté est les mouvements de rotations de la barre autour de l'axe des lignes avants. Comment faire pour empêcher cette rotation et amortir les mouvements de barre afin que ce ne soit pas dangereux? En utilisant des petits sandows?
Je suis ensuite reparti naviguer. J'ai noté une dernière chose, qui est l'importance de l'horizon pour le placement de l'aile en navigation, notamment lors de la navigation au près. Le bas de l'aile est à environ 1 largeur à 2 largeurs du sol. Une telle précision ne peut je pense être atteinte que par un positionnement relatif (par exemple visuel).
lundi 29 juillet 2013
Veille
J'ai profité du week end pour faire un peu de veille technologique.
Je suis donc retourné sur un certain nombre de sites qui étaient soit dans les messages précédents de ce blog, soit sur la page http://code.google.com/p/robokite/wiki/Links
Voici les nouvelles intéressantes :
-Makani power racheté par Google
-Sky Sails qui se diversifie dans les systèmes de contrôle des économies d'énergie pour les propulsions classiques.
-ROS hydromedusa en version beta en juillet
-ROS conference : j'ai trouvé les conférences suivantes intéressantes ::
-Morse 1.01 release en Avril (ajout de tests)
En regardant les statistiques du site http://code.google.com/p/robokite/, j'ai vu que des visiteurs étaient arrivés à partir d'une recherche sur les termes automated kite control (et non automatic). En faisant cette recherche, je suis tombé sur quelques liens que je n'avais pas vu.
Notamment le brevet de de kitegen la société italienne. Ca m'a un peu énervé car il propose d'utiliser deux moteurs, un pour faire du différentiel et un pour rembobiner les lignes, ce qui est la base! Heureusement, leur système est également un peu particulier et ils ne brevètent pas seulement cela!
Cela m'a également permis de trouver ce bilan A LIRE de Uwe Fechner, en MSc à l'université de Delft. Il y a notamment des schémas d'architecture système intéressant.
J'ai également trouvé des discussions intéressantes datant de Mars et Avril sur le sujet
http://electronics.stackexchange.com/questions/61014/real-time-location-sensor-for-following-a-kite-in-the-air?noredirect=1#comment117178_61014
http://robotics.stackexchange.com/questions/1072/is-it-possible-to-make-kite-flying-robot/1675#1675
Je suis donc retourné sur un certain nombre de sites qui étaient soit dans les messages précédents de ce blog, soit sur la page http://code.google.com/p/robokite/wiki/Links
Voici les nouvelles intéressantes :
-Makani power racheté par Google
-Sky Sails qui se diversifie dans les systèmes de contrôle des économies d'énergie pour les propulsions classiques.
-ROS hydromedusa en version beta en juillet
-ROS conference : j'ai trouvé les conférences suivantes intéressantes ::
- utilisation du serveur Hadoop et le système de fichier distribué hdfs
- Robot web tools
-Morse 1.01 release en Avril (ajout de tests)
En regardant les statistiques du site http://code.google.com/p/robokite/, j'ai vu que des visiteurs étaient arrivés à partir d'une recherche sur les termes automated kite control (et non automatic). En faisant cette recherche, je suis tombé sur quelques liens que je n'avais pas vu.
Notamment le brevet de de kitegen la société italienne. Ca m'a un peu énervé car il propose d'utiliser deux moteurs, un pour faire du différentiel et un pour rembobiner les lignes, ce qui est la base! Heureusement, leur système est également un peu particulier et ils ne brevètent pas seulement cela!
 |
| Brevet kitegen |
Cela m'a également permis de trouver ce bilan A LIRE de Uwe Fechner, en MSc à l'université de Delft. Il y a notamment des schémas d'architecture système intéressant.
J'ai également trouvé des discussions intéressantes datant de Mars et Avril sur le sujet
http://electronics.stackexchange.com/questions/61014/real-time-location-sensor-for-following-a-kite-in-the-air?noredirect=1#comment117178_61014
http://robotics.stackexchange.com/questions/1072/is-it-possible-to-make-kite-flying-robot/1675#1675
dimanche 28 juillet 2013
Animation 3D avec openscad
Le code est là http://code.google.com/p/robokite/source/browse/kite.scad
Il est assez facile de faire une animation et d'exporter les images.
La ligne de commande suivante m'a ensuite permis de faire un gif animé :
convert -delay 1x8 `seq -f frame%05g.png 0 3 99` -coalesce -layers OptimizeTransparency animation.gif
Je ne détaille pas la commande, des explications peuvent être trouvées sur d'autres sites. Il faut avoir installé imagemagick.
OmegaSails dans les cowbayes
http://www.youtube.com/watch?v=Qvnfl6k71nM
Avel-vor technologie
Voici un lien vers un film réalisé sur le chalutier automatisé d'AvelVorTechnologie.
http://www.youtube.com/watch?v=0FLIQ2QF7gY&feature=youtu.be
http://www.youtube.com/watch?v=0FLIQ2QF7gY&feature=youtu.be
samedi 27 juillet 2013
Capteur d'angle des lignes
Voici un lien vers une vidéo du capteur d'angle des lignes utilisé sur le projet kite boat.
http://project.kiteboat.com/2013/02/line-angle-sensor-video/
Cela me rappelle le capteur développé par SIRHENA pour les mesures d'angle des funes de chalutier.
http://project.kiteboat.com/2013/02/line-angle-sensor-video/
Cela me rappelle le capteur développé par SIRHENA pour les mesures d'angle des funes de chalutier.
Makani Power racheté par Google
La nouvelle n'est pas toute fraiche, mais je ne l'avais pas encore vu. Rien de surprenant, étant donné les liens déjà fort qui existaient avec Google.
Pour en savoir plus, suivez ce lien :
http://www.thedailybeast.com/articles/2013/05/28/google-buys-flying-wind-turbine-company-makani-power.html
Pour en savoir plus, suivez ce lien :
http://www.thedailybeast.com/articles/2013/05/28/google-buys-flying-wind-turbine-company-makani-power.html
vendredi 26 juillet 2013
Traversée de Marsh Harbour
Voici (enfin) quelques photos de la traversée de Marsh Harbour que nous avions faite avec un copain planchiste sur l'annexe du Lagoon avec lequel nous avions traversé l'Atlantique.
jeudi 25 juillet 2013
Shopping
J'ai fait un peu les boutiques sur internet :
RS : très large gamme de produit
Farnell : j'avais déjà acheté chez eux les L6205, sans problème. J'aime bien les filtres pour la sélection des composants
Conrad : je ne connais pas trop
Gotronic : pas mal de chose spécialisée pour la robotique, mais aussi pas mal de choses générales en électronique. Je pense que je vais passer ma commande chez eux.
Je suis en train de craquer pour une module de commande de moteur Sabertooth et le module de contrôle Kangaroo. Il y a pour un centaine d'euros, mais les fonctionnalités proposées sont intéressantes et cela devrait être bien pour faire des prototypes plus rapidement et comme référence pour tester d'autres solutions moins onéreuses.
Je regarde également les motoréducteurs, dans l'idée que ça doit-être moins cher de les acheter directement que de démonter une visseuse. Malheureusement, je n'arrive pas à trouver de moteurs puissants.
Les moteurs de visseuse/perceuse sans fils sont entre 150 et 350 W (UWO) alors que je n'arrive à trouver que quelques watts pour des motoréducteurs à 200 euros!!
Les circuits de commande pour les moteurs brushless sont également beaucoup plus cher (environ 400euros), peut-être car je n'en trouve que pour de grandes puissances.
J'ai de nouveau regardé les moteurs des autos. Un démarreur de twingo fait 800W, celui d'une camionette fait 1400W. (source oscaro.com)
Les moteurs d'essuie glace feraient une centaine de watt pour un peu plus d'une centaine d'euro (avec réducteur)
J'ai également trouvé un bon site expliquant le fonctionnement de la direction assistée de la twingo http://chr.trouillard.free.fr/cdt/SSIDossiertechnique/DTDAE/DTDAE.htm. Ca me tenterait d'en trouver une à la casse. Le moteur fait 125W.
RS : très large gamme de produit
Farnell : j'avais déjà acheté chez eux les L6205, sans problème. J'aime bien les filtres pour la sélection des composants
Conrad : je ne connais pas trop
Gotronic : pas mal de chose spécialisée pour la robotique, mais aussi pas mal de choses générales en électronique. Je pense que je vais passer ma commande chez eux.
Je suis en train de craquer pour une module de commande de moteur Sabertooth et le module de contrôle Kangaroo. Il y a pour un centaine d'euros, mais les fonctionnalités proposées sont intéressantes et cela devrait être bien pour faire des prototypes plus rapidement et comme référence pour tester d'autres solutions moins onéreuses.
Je regarde également les motoréducteurs, dans l'idée que ça doit-être moins cher de les acheter directement que de démonter une visseuse. Malheureusement, je n'arrive pas à trouver de moteurs puissants.
Les moteurs de visseuse/perceuse sans fils sont entre 150 et 350 W (UWO) alors que je n'arrive à trouver que quelques watts pour des motoréducteurs à 200 euros!!
Les circuits de commande pour les moteurs brushless sont également beaucoup plus cher (environ 400euros), peut-être car je n'en trouve que pour de grandes puissances.
J'ai de nouveau regardé les moteurs des autos. Un démarreur de twingo fait 800W, celui d'une camionette fait 1400W. (source oscaro.com)
Les moteurs d'essuie glace feraient une centaine de watt pour un peu plus d'une centaine d'euro (avec réducteur)
J'ai également trouvé un bon site expliquant le fonctionnement de la direction assistée de la twingo http://chr.trouillard.free.fr/cdt/SSIDossiertechnique/DTDAE/DTDAE.htm. Ca me tenterait d'en trouver une à la casse. Le moteur fait 125W.
Connecteurs électriques
Je galère un peu avec les connecteurs : les dominos c'est facile à trouver, mais pas très pratique.
J'ai trouvé le lien suivant qui fait un bon inventaire des connecteurs utilisés en modélisme.
https://sites.google.com/site/tjinguytech/reviews/rc-connectors
Le connecteur XT60 me plait bien.
Il permet de supporter un courant jusqu'à 60A (plusieurs utilisateurs l'ont utilisés au-delà sans problème).
Il faut cependant souder à un moment (peut-être existe-t-il des modèles avec interface à vis?).
J'ai trouvé ce tutoriel en français : http://www.hpibajafrance.com/t24566-tuto-assemblage-de-connecteurs-xt60
J'ai trouvé le lien suivant qui fait un bon inventaire des connecteurs utilisés en modélisme.
https://sites.google.com/site/tjinguytech/reviews/rc-connectors
Le connecteur XT60 me plait bien.
Il permet de supporter un courant jusqu'à 60A (plusieurs utilisateurs l'ont utilisés au-delà sans problème).
Il faut cependant souder à un moment (peut-être existe-t-il des modèles avec interface à vis?).
J'ai trouvé ce tutoriel en français : http://www.hpibajafrance.com/t24566-tuto-assemblage-de-connecteurs-xt60
mercredi 24 juillet 2013
GPS RTK avec téléphone mobile
Depuis quelques temps, je me pose la question de la réalisation d'un GPS différentiel ou RTK avec un téléphone mobile.
Le GPS différentiel utilise des ondes radio pour affiner sa position à partir de la connaissance d'une erreur de position envoyée par une station fixe.
Le GPS RTK fonctionne de la même manière mais avec une correction plus précise car elle regarde la phase de la porteuse du signal GPS.
Si la correction RTK semble demander des ressources matérielles supplémentaires, la correction différentielle semble accessible.
L'envoi d'une correction différentielle en 3G semble tout à fait possible.
Un protocole nommé NTRIP pour la diffusion des messages de correction sur internet existe déjà.
http://infoscience.epfl.ch/record/83880/files/Serveur%20corrections%20GPS.pdf
Une application existe sur l'android market
https://play.google.com/store/apps/details?id=ru0xdc.rtkgps&hl=fr
Le code source de l'application est ouvert
https://github.com/illarionov/RtkGps
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3545552/
Il se base sur la bibliothèque libre rtklib
http://www.rtklib.com/
Ou sinon on peut également essayer de refaire entièrement un réseau GPS local comme le propose Astrium pour l'appontage des drones http://www.meretmarine.com/fr/content/comment-sabstenir-du-gps-pour-lappontage-des-drones
Le GPS différentiel utilise des ondes radio pour affiner sa position à partir de la connaissance d'une erreur de position envoyée par une station fixe.
Le GPS RTK fonctionne de la même manière mais avec une correction plus précise car elle regarde la phase de la porteuse du signal GPS.
Si la correction RTK semble demander des ressources matérielles supplémentaires, la correction différentielle semble accessible.
L'envoi d'une correction différentielle en 3G semble tout à fait possible.
Un protocole nommé NTRIP pour la diffusion des messages de correction sur internet existe déjà.
http://infoscience.epfl.ch/record/83880/files/Serveur%20corrections%20GPS.pdf
Une application existe sur l'android market
https://play.google.com/store/apps/details?id=ru0xdc.rtkgps&hl=fr
Le code source de l'application est ouvert
https://github.com/illarionov/RtkGps
http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3545552/
Il se base sur la bibliothèque libre rtklib
http://www.rtklib.com/
Ou sinon on peut également essayer de refaire entièrement un réseau GPS local comme le propose Astrium pour l'appontage des drones http://www.meretmarine.com/fr/content/comment-sabstenir-du-gps-pour-lappontage-des-drones
mardi 23 juillet 2013
Utilisation de la souris comme capteur
Aujourd'hui j'ai fait quelques tests afin d'étudier la possibilité d'utiliser une souris (optique) comme encodeur pour connaitre la position de la barre.
Je pensais qu'il n'y avait pas trop de difficulté...
De nombreux tutoriels expliquent comment utiliser la souris avec arduino directement en se branchant sur le circuit intégré. Je cherchais plutôt une solution purement logicielle, ne demandant pas de modifications sacrificielles d'animaux.
Dans la plupart des langages de programmation, des fonctions existent pour récupérer la position du curseur. Cette position est malheureusement saturée sur les bords de l'écran, ce qui limite l'amplitude du mouvement qui peut-être mesuré à quelques centimètres. Pourtant dans les jeux vidéo (First Person Shooter notamment) le joueur peut souvent faire des mouvements plus larges. L'astuce semble venir de la modification de la position de la souris qui est régulièrement ramenée au milieu de l'écran. Les écarts peuvent alors être mesurés et intégrés.
J'ai trouvé une bibliothèque pymouse permettant de gérer la position du curseur avec python http://doc.ubuntu-fr.org/pymouse
La seconde difficulté venait du fait que la souris n'est alors plus utilisable. Même en ajoutant une souris usb, le même curseur est attaché aux deux souris par défaut. Pour remédier à ce problème j'ai utilisé la capacité de linux à gérer plusieurs souris et plusieurs curseurs "multi-pointer x" http://doc.ubuntu-fr.org/mpx.
J'ai ainsi pu attacher le curseur principal (dont la position est retournée par les langages de programmation) à une souris externe et le curseur secondaire au trackpad de mon ordi.
Cela m'a permis de tester l'utilisation de la souris comme un capteur.
J'ai fait un petit programme python pour cela. Un problème restant est d'abord que le curseur principal reste affiché. J'ai essayé de le faire disparaitre avec l'utilitaire unclutter, mais il réapparait dès que la souris bouge.
J'ai fait quelques tests satisfaisants en déplaçant la souris sur une grande surface plane en essayant de ne pas modifier l'orientation.
J'ai ensuite fait des tests en mettant la souris sur la support de mèche de la visseuse électrique. La mesure semble correcte à basse vitesse, mais à partir d'une certaine vitesse, l'image doit devenir floue et le mouvement n'est plus détecté.
A creuser
Je pensais qu'il n'y avait pas trop de difficulté...
De nombreux tutoriels expliquent comment utiliser la souris avec arduino directement en se branchant sur le circuit intégré. Je cherchais plutôt une solution purement logicielle, ne demandant pas de modifications sacrificielles d'animaux.
Dans la plupart des langages de programmation, des fonctions existent pour récupérer la position du curseur. Cette position est malheureusement saturée sur les bords de l'écran, ce qui limite l'amplitude du mouvement qui peut-être mesuré à quelques centimètres. Pourtant dans les jeux vidéo (First Person Shooter notamment) le joueur peut souvent faire des mouvements plus larges. L'astuce semble venir de la modification de la position de la souris qui est régulièrement ramenée au milieu de l'écran. Les écarts peuvent alors être mesurés et intégrés.
J'ai trouvé une bibliothèque pymouse permettant de gérer la position du curseur avec python http://doc.ubuntu-fr.org/pymouse
La seconde difficulté venait du fait que la souris n'est alors plus utilisable. Même en ajoutant une souris usb, le même curseur est attaché aux deux souris par défaut. Pour remédier à ce problème j'ai utilisé la capacité de linux à gérer plusieurs souris et plusieurs curseurs "multi-pointer x" http://doc.ubuntu-fr.org/mpx.
J'ai ainsi pu attacher le curseur principal (dont la position est retournée par les langages de programmation) à une souris externe et le curseur secondaire au trackpad de mon ordi.
Cela m'a permis de tester l'utilisation de la souris comme un capteur.
J'ai fait un petit programme python pour cela. Un problème restant est d'abord que le curseur principal reste affiché. J'ai essayé de le faire disparaitre avec l'utilitaire unclutter, mais il réapparait dès que la souris bouge.
J'ai fait quelques tests satisfaisants en déplaçant la souris sur une grande surface plane en essayant de ne pas modifier l'orientation.
J'ai ensuite fait des tests en mettant la souris sur la support de mèche de la visseuse électrique. La mesure semble correcte à basse vitesse, mais à partir d'une certaine vitesse, l'image doit devenir floue et le mouvement n'est plus détecté.
A creuser
Interface Homme Machine
Je pense que le système devra avoir une interface homme-machine dédiée avec des contrôles mécaniques (boutons poussoir, potard, ...).
Mais pour pouvoir faire un paramétrage plus précis, le système disposera également d'un interface accessible via le réseau depuis un pc, une tablette ou un téléphone portable.
Je me suis initialement intéressé à Qt qui a un grand succès dans le développement d'applications. Mais l'intégration progressive de HTML5 dans les navigateurs doit maintenant permettre de réaliser toutes sortes d'applications portables.
J'ai donc tester les nouvelles possibilités offertes par HTML5, notamment les web sockets qui permettent une communication asynchrone en temps réel de manière propre, ainsi que les nouveaux éléments faisant partis des formulaires (slider).
Chromium et Firefox sont actuellement les navigateurs les plus avancés.
Enfin, je me suis intéressé à XDK html5 d'Intel http://html5dev-software.intel.com/ qui vient compléter la suite Cordova (autrefois PhoneGap) et qui permet de tester les applications mobiles en html5 pouvant facilement être déployées sur Android ou Iphone.
J'ai choisi de faire l'installation directement dans chromium.
J'ai eu quelques difficultés pour l'installation dans Ubuntu à cause de java.
J'ai d'abord essayé avec l'implémentation open-source openjdk, mais ça ne marchait pas.
J'ai alors installé la version officielle de java.
J'avais ensuite le message d'erreur "Chrome appears to be missing"
Ce message d'erreur apparait mais il n'y a en fait pas de problème, il suffit de se rendre à la page suivante:
http://localhost:58888/_emulator/_ide/index.html
Voici une petite image du résultat
Je ne suis pas aller plus loin dans le test de cet outils.
Par contre j'ai tester un plus en détail les websockets, qui permettent d'avoir une communication en continue dans le navigateur, et donc de faire des applications temps réel.
Cela demande un client récent (chrome ou firefox) mais également un serveur adapté. Tornado est un serveur en python qui semble bien convenir :
http://niltoid.com/blog/raspberry-pi-arduino-tornado/
Et voici une petit image du prototype :
Par ici pour le code source
Voici également pour rappel l'interface de High-Zenith-Power :
Et une image de l'interface de skysails :
Mais pour pouvoir faire un paramétrage plus précis, le système disposera également d'un interface accessible via le réseau depuis un pc, une tablette ou un téléphone portable.
Je me suis initialement intéressé à Qt qui a un grand succès dans le développement d'applications. Mais l'intégration progressive de HTML5 dans les navigateurs doit maintenant permettre de réaliser toutes sortes d'applications portables.
J'ai donc tester les nouvelles possibilités offertes par HTML5, notamment les web sockets qui permettent une communication asynchrone en temps réel de manière propre, ainsi que les nouveaux éléments faisant partis des formulaires (slider).
Chromium et Firefox sont actuellement les navigateurs les plus avancés.
Enfin, je me suis intéressé à XDK html5 d'Intel http://html5dev-software.intel.com/ qui vient compléter la suite Cordova (autrefois PhoneGap) et qui permet de tester les applications mobiles en html5 pouvant facilement être déployées sur Android ou Iphone.
J'ai choisi de faire l'installation directement dans chromium.
J'ai eu quelques difficultés pour l'installation dans Ubuntu à cause de java.
J'ai d'abord essayé avec l'implémentation open-source openjdk, mais ça ne marchait pas.
J'ai alors installé la version officielle de java.
J'avais ensuite le message d'erreur "Chrome appears to be missing"
Ce message d'erreur apparait mais il n'y a en fait pas de problème, il suffit de se rendre à la page suivante:
http://localhost:58888/_emulator/_ide/index.html
Voici une petite image du résultat
 |
| XDK html5 dans chromium sous ubuntu |
Je ne suis pas aller plus loin dans le test de cet outils.
Par contre j'ai tester un plus en détail les websockets, qui permettent d'avoir une communication en continue dans le navigateur, et donc de faire des applications temps réel.
Cela demande un client récent (chrome ou firefox) mais également un serveur adapté. Tornado est un serveur en python qui semble bien convenir :
http://niltoid.com/blog/raspberry-pi-arduino-tornado/
Et voici une petit image du prototype :
 |
| Prototype d'IHM utilisant sliders et websockets |
Par ici pour le code source
Voici également pour rappel l'interface de High-Zenith-Power :
vendredi 19 juillet 2013
Mauvais connexion internet, puis connexion à bas débit (en voilier) m'ont un peu empêché de donner des nouvelles. Le projet a cependant continuer à avancer.
La partie mécanique a été modifiée afin de réduire les frottements avec la planche en bois. Pour cela j'ai ajouté une structure en bois pour fixer le corps de la visseuse. La mèche est ainsi libre de tourner. Par contre, cela permet l'application d'un couple transversal sur la mèche ce qui n'est pas très bon.
J'ai complètement supprimé la bobine. J'utilise maintenant une mèche de perceuse de 10mm entourée de scotch. L'ajustement de la position des poulies de renvoi permet d'avoir un fil qui s'enroule à un endroit de la mèche et l'autre sur une autre partie de la mèche. Les fils sont fixés avec un nœud de cabestan plus une demi-clé. Les entailles de la mèches évitent le glissement.
J'ai pu tester ce montage lors d'un jour avec un peu de vent (en pilotage manuel). Et bien ça marche! Malheureusement, mes enregistrements hdf5 étaient corrompus à cause d'une fermeture malpropre du programme. Depuis j'ai corrigé le problème pour que le fichier ne soit pas corrompu même si le programme plante (utilisation de flush).
 |
| Un insecte avec des ailes? Non, un circuit intégré avec un radiateur |
 |
| La première version du banc de test |
J'ai complètement supprimé la bobine. J'utilise maintenant une mèche de perceuse de 10mm entourée de scotch. L'ajustement de la position des poulies de renvoi permet d'avoir un fil qui s'enroule à un endroit de la mèche et l'autre sur une autre partie de la mèche. Les fils sont fixés avec un nœud de cabestan plus une demi-clé. Les entailles de la mèches évitent le glissement.
 |
| Christophe et la nouvelle arme |
 |
| Ajout d'un baton centrale pour soutenir la barre et servir de support à la caméra |
J'ai pu tester ce montage lors d'un jour avec un peu de vent (en pilotage manuel). Et bien ça marche! Malheureusement, mes enregistrements hdf5 étaient corrompus à cause d'une fermeture malpropre du programme. Depuis j'ai corrigé le problème pour que le fichier ne soit pas corrompu même si le programme plante (utilisation de flush).
 |
| Le système mécanique et au loin le cerf-volant (à terre) |
 |
| La fixation rudimentaire de la caméra |