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.

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.

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

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 

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

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

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 :

Et une image de l'interface de skysails :

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.

Un insecte avec des ailes? Non, un circuit intégré avec un radiateur

La première version du banc de test

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.

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

Plus d'internet depuis 3 jours, donc plus de nouvelles, mais j'ai continué à avancer un peu.
Vendredi j'ai repris le support de la bobine afin de diminuer les frottements.

Avant

Après

Voici une petite vidéo du banc de test : 

"Cent fois sur le métier, remettez votre ouvrage"

Hier, j'ai fait une bonne journée en mode geek, malgré le soleil qui brillait ici.
J'ai corrigé de nombreux bugs, commencé à travailler vraiment sur la partie matériel, enfin "branché les lois de commande" sur les sorties de la vidéo d'une part et au moteur d'autre part

J'ai donc aujourd’hui à peu près quelque chose qui pourrait tenir un cerf-volant quelques secondes en l'air ! Il y a un an et demi quand je m'étais mis ce projet en tête, j'imaginais que ce serait l'histoire de quelques jours. Et je le pense toujours... J'espère en tout cas que ce sera le cas pour quelqu'un qui voudra reprendre le projet.

C'est parfois déprimant de voir comment au fur et à mesure des modifications on arrive à des choses compliquées, et qu' on peut faire mieux en quelques lignes?
"100 fois sur le métier remettre son ouvrage" résume bien cette journée.

Je ne sais pas si j'apprends vraiment de mes erreurs, car je les refaits encore et encore, mais j'arrive maintenant à les identifier et à les corriger plus vite.

Portage Android

Voici un lien vers un projet utilisant android et arduino.
Un bon lien à réutiliser si je décide de faire un portage du code que je développe actuellement sur android.
http://code.google.com/p/android-arduino-object-tracking-robot/

Ajout vidéos

J'ai enfin ajouté quelques vidéos sur Youtube. Les vidéos sont parfois presque comiques, c'est peut-être pour cela que je n'osais pas les poster ! Je pense que dans quelques années je pourrai en rire plus librement.

Juste pour info j'ai utilisé ffmpeg pour la compression avant l'envoi à Youtube.
J'ai utilisé les liens suivant pour m'aider au paramétrage :
https://support.google.com/youtube/answer/1722171?hl=en
http://www.jcartier.net/spip.php?article57

Voici un court extrait du dernier lien expliquant le fonctionnant de ffmpeg

"ffmpeg -i test.avi -ar 22050 -r 25 -s 320x256 -keyint_min 1 -b 500000 test.flv

- ffmpeg : c’est l’outil
- -i test.avi : c’est le fichier initial.
- -ar 22050 : c’est la fréquence d’échantillonnage audio de sortie.
- -r 25 : c’est le nombre d’images de sortie par seconde, à savoir 25.
- -s 320x256 : c’est la taille de la vidéo de sortie, soit 320 pixels par 256 pixels.
- -keyint_min 1 : c’est le nombre d’images clés : 1 image clé toutes les 1 images clés
- -b 500000 : c’est le bitrate vidéo (si l’on veut spécifier un bitrate audio, on ajoute -ab XXX avec XXX pour le bitrate en octets), soit 500 ko/s
- test.flv : C’est le nom du fichier de sortie."



Et voici la commande que j'ai utilisé
 ffmpeg -i input.MTS -r 25 -s 640x360 -b 1000000 -ab 128000 output.mp4
On peut également tourner la vidéo en utilisant  -vf "transpose=1"

 

Contrôle du moteur depuis le PC

 

Contrôle du moteur avec un potard

 

Contrôle du moteur en boucle fermée avec feedback visuel

 

Vol du cerf-volant lors de la transat (Crash test)

Pipa

Hier, j'ai réussi à bricoler un dissipateur thermique  (heatsink) pour le circuit intégré contenant le pont en H. J'ai utilisé pour cela une simple canette. Les parois sont très faciles à découper avec une simple paire de ciseaux.
J'avais peur que l'aluminium soit conducteur et qu'il y ait un risque de court-circuit, mais j'ai pu vérifier avec un ohmmètre qu'il est parfaitement isolant (peut-être à cause d'une couche superficielle? j'espère que ça tiendra dans le temps avec l'échauffement).
J'ai donc découpé un morceau de manière à entourer le circuit intégré et à faire des ailes au dessus. J'ai caler le tout avec un micro bout de scotch. Pour ceux qui voudraient tenter la même chose, penser à faire une marque pour bien savoir le sens du circuit intégré avant de l'envelopper.
Cela semble avoir bien fonctionné, et j'ai l'impression que le moteur peut maintenant donner un couple supérieur. Il faudra que je vérifie en remettant en place le banc et en mesurant le courant.

Aujourd'hui j'ai essayé de trouver des petits câbles de connexion à Angra dos Reis (Brésil pour ceux qui n'auraient pas suivi) afin de pouvoir disposer d'un deuxième pont en H, toujours afin de pouvoir augmenter la puissance. Mes recherches ont malheureusement été infructueuses.

Sur le chemin du retour, j'ai été surpris par plein de cerf-volants  (pipas) dans le ciel (alors qu'il n'y aucun vent ici). Les enfants (parfois plus tout jeunes) arrivent à faire voler de petits cerf-volants en pompant sur le fil.
J'ai acheté un de ces cerfs-volants pour 1 R$ (Reals, soit environ 35ct d'euro...). Il m'a fallu acheter également un fil, et fabriquer une queue.
Malgré l'aide des enfants, je n'ai pas réussi à faire décoller le cerf-volant comme eux. Il faut un très bon timing et un bon dosage de l'effort. J'essaierai de prendre des photos.

Thread en python

J'ai assez facilement réussi à utiliser les threads. Cela m'a permis de mettre en place le filtrage des données venues du téléphone portable.

J'ai fais un simulateur physique du kite avec un bâton et des bouts.
Cela me permet de faire des tests assez rapidement et de voir les problèmes des différentes solutions possibles avant d'aller plus loin.

Réflexions mécaniques

Caméra

Il faut que la caméra soit fixée de manière à toujours avoir le cerf-volant dans son champ de vision.
Il y a 3 solutions à ce problème :
1) plusieurs caméras
2) caméra avec lentille pour augmenter l'angle de vue
3) caméra mobile avec le cerf-volant
   a) caméra montée sur un système asservi (servo)
   b) caméra montée sur la barre. Permet d'avoir un retour de la position de la barre mais le cerf-volant sort du champ aux angles de barre important
   c) caméra fixée sur 1 fil : la caméra se retrouve sur un axe de rotation et risque de balloter.
   d) caméra montée sur un liaison pivôt sur la barre dirigée par les fils.


Système mécanique

L'architecture dépend du nombre de fils, de la possibilité ou non de rembobiner les fils
L'architecture doit compenser les efforts mécaniques
L'architecture doit permettre le largage de l'aile en toute sécurité

2 fils
1) 1 actionneur pour chaque fil
Cette solution ne permet pas d'équilibrer les efforts et demande des moteurs puissants. Elle a l'avantage de permettre de rembobiner les fils ou de gérer une commande de puissance
2) 2 fils reliés
Cette solution permet d'équilibrer les efforts. Des renvois peuvent-être utilisés pour guider le fil et pour équilibrer la direction des efforts sur l'axe moteur.
   a) tours morts autour d'une bobine
      Il faut faire plusieurs tours pour empêcher le glissement. Il y a risque de surpatter.
   b) Fils enroulés autour de deux bobines montées sur le même axe mais inversées.
3) système à barre
L'utilisation d'une barre est aujourd'hui la référence pour le kitesurf. Cela permet d'utiliser un harnais qui va permettre de supporter les efforts tout en conservant le contrôle. Le problème est donc de placer la barre
  a) 2 moteurs
     les efforts sont maintenant compensés. Il est donc envisageable d'utiliser 2 moteurs, ce qui doit permettre de faire en plus un réglage de la puissance
      I) avec 2 fils
        on perd la moitié de la puissance des moteurs
      II) avec 2 vérins
            un vérin peut tirer, l'autre pousser
   b) 1 moteur
     action directe sur la barre
     système de poulie
     avec un fil : difficulté car la longueur du fil et variable. Il va y avoir du mou qui peut donner une perte de contrôle.
     Cela peut-être compensé en enroulant le fil sur une spirale. ou en utilisant un système de ressort ou d'élastique.
  

Fusion de données accéléromètre et magnétomètre

J'ai finalement décidé de recoder le calcul de l'orientation du téléphone à partir des mesures brutes.
J'ai utilisé pour cela "Computes roll, pitch and yaw. See "Implementing a Tilt-Compensated eCompass using Accelerometer and Magnetometer Sensors" reference AN4248 de Freescale.
J'ai codé en python, en reprenant les équations mais sans l'ensemble des optimisations proposées. Pour une raison que j'ignore la fréquence de réception des trames tombent d'environ 80 (accéléromètre seul sans calcul) à 10 avec le magnétomètre (ce qui reste suffisant). J'en utilise de toute manière encore moins ensuite, mais avoir plus de trames permettrait de mettre en place un filtre pour réduire le bruit (plusieurs degrés sur le cap, peut-être lié aux perturbations électromagnétiques alentours).

Je pense que je vais donc essayer de faire un processus séparé (ou des threads) qui tournera plus vite et pourra faire le filtrage. L'information filtrée sera ensuite récupérée par l'application principale. En python différentes solutions ont l'air d'exister : subprocess, Queue.

Je réfléchis également à modifier complètement l'électronique de puissance que j'utilise. Mon problème vient de la limitation d'intensité qui demande soit de multiplier le nombre de circuit de commande ou peut-être de mieux refroidir les composants, mais je ne trouve pas trop comment faire (j'imagine qu'il faut coller des ailettes métalliques d'une manière ou d'une autre).

La solution alternative serait d'essayer de nouveau de réutiliser directement le mosfet (FQP50N06) présent sur les visseuses et d'ajouter un pont avec 2 (ou 4?) relais électromagnétiques pour inverser la tension (edit : un relais double inverseur devrait suffir) (edit : une difficulté d'utiliser le mosfet vient du fait qu'il nécessite une tension de 9V pour son contrôle et non 5 volt, un étage supplémentaire est donc souhaitable).
D'après la datasheet cela permettrait de tenir 50A par 60V soit 3000W soit environ 4 chevaux, l'équivalent d'un petit moteur d'annexe!
L'utilisation des relais me semble possible car leurs activations ne sera pas constante, mais seulement lors des changements de sens de rotation du moteur (peut-être toutes les 3 à 4 secondes, ce qui laisse de la marge d'utilisation avec 10 millions de cycles pour un démonstrateur).
Par contre la durée de vie sera rapidement réduite si j'essaie de faire du "dynamic braking" pour freiner le moteur à vitesse nulle.

MOSET FQP50N06 et son dissipateur thermique

J'ai également installé hdf5 et h5py dans le but de commencer à faire des fichiers de sauvegardes plus performants que les fichiers textes. Après des problèmes de manque d'header après la compilation des sources, j'ai finalement installé à partir de ce lien

J'ai l'impression que tout peut aller vite en python, mais j'ai tout de même pesté contre plusieurs choses aujourd'hui :
-je ne trouvais pas comment recharger un module : il faut faire reload
-j'ai des difficultés pour faire un simple produit matriciel : il faut utiliser dot (avec numpy.array).

Aujourd'hui j'ai essayé de corriger un bug dans l'interprétation de l'orientation envoyée par le téléphone.

Voici quelques captures d'écran de l'état des programmes développés.

D'abord le programme principal permettant de connaitre la position du cerf-volant. Pour le développement j'ai réutilisé la vidéo réalisée par High Zenith Power. A terme la vidéo sera envoyée à partir de la webcam d'un téléphone portable. La détection du cerf-volant se base sur la couleur, il est donc important qu'il y ait un bon contraste avec la couleur du ciel ou du paysage si le cerf-volant descend bas. Cela me permet d'obtenir le contour du cerf-volant (en bleu) et une position relative à la caméra, ainsi que l'inclinaison du cerf-volant en faisant la recherche du rectangle le plus petit (rouge) encadrant la forme.

Le rectangle vert correspond à la zone dans laquelle est réellement faite la recherche (en se basant sur la position précédente). Cela permet d'augmenter la fluidité du traitement. Le code utilise simpleCV et n''est pour l'instant pas optimisé. Un optimisation est nécessaire si l'on veut pouvoir contrôler des petits cerf-volants car la latence est de 0.5 à 1s actuellement.

La ligne rouge correspond à l'horizontale (évidemment cela ne correspond pas sur l'image, la vidéo étant un enregistrement et non un live).

Cette ligne rouge est obtenue à partir des informations d'orientation du téléphone (également envoyées en wifi). 

Le 330 correspond ainsi au gisement du cerf-volant.

Le couplage permet d'obtenir une position absolue du cerf-volant au lieu d'une position relative à la caméra. On entre dans le domaine de la réalité augmentée. Voir le code

 

La photo suivante est un essai de projection de la vidéo de la caméra sur un plan plus grand. En effet, il n'est pas possible de voir toute la fenêtre de vol avec la caméra. Du coup je fais une projection de la fenêtre de vol et je colle dessus l'image correspondant à une partie de la fenêtre de vol.

 

Pour finir pour aujourd'hui, un lien vers n projet étudiant intéressant que je n'avais pas encore vu :

http://www.youtube.com/watch?NR=1&feature=endscreen&v=demmPybYf2I
Ce qui est marrant c'est que les termes de recherche entrés dans Google il y a quelques mois ne donnent pas les mêmes résultats aujourd'hui.

News!!!

Voici plus de deux mois que je n'ai pas posté d'information sur ce blog...
Pourtant le projet n'est pas mort, mais j'ai pris des vacances, entrecoupées de quelques sessions de travail (pourquoi ne pas lier l'utile à l'agréable?).
Je suis maintenant posé pour 15 jours à Bracuhy (Brésil), où je devrais disposer de temps, d'outils et d'une connexion internet pour faire avancer le projet.

Je suis donc parti le 14 avril pour une traversée de l'Atlantique en voilier.
Avant cela, il y a eu quelques préparatifs qui ont fait que la publication d'information sur ce blog n'était plus la priorité.

Voici donc un résumé des avancées liées au projet.

VISION PAR ORDINATEUR

• prise en main de simpleCV (notamment lors des quarts nocturnes de veille)

• développement d'un algorithme de détection du cerf-volant à partir d'un flux vidéo et calcul des position et orientation relatives associées

• développement du traitement des informations d'attitude d'un téléphone android sur un pc distant

  

  L'application sensorUDP

• fusion de ces informations pour obtenir une position "absolue" du mobile

MOTORISATION
N'ayant pas pris le moteur et la batterie que j'utilisais en France (et oui c'est lourd dans un sac à dos), j'ai de nouveau eu à choisir un moteur et l'alimentation associée.
Après quelques recherches auprès de moteurs électriques que l'on trouve sur les automobiles (lève-vitre, essuie-glace, direction assistée, etc), mon choix s'est de nouveau porté sur la récupération d'une vielle visseuse/dé-visseuse/perceuse sans fil (pour l'anecdote, j'en ai même acheté une nouvelle, mais heureusement j'en ai trouvé des vielles avant de la démonter...).
Les principales difficultés dans le choix viennent du fait que les données techniques des moteurs sont difficiles à avoir. On arrive en général seulement à avoir le voltage. Il faut souvent démonter le matériel pour obtenir la référence du moteur. Et cela n'est parfois pas suffisant.
Il a donc fallu que je mette en place un banc de test.
Pour cela, j'utilise une bonbonne d'eau de 5 litres (qui à l'avantage d'avoir une poignée) que je remplis avec la quantité d'eau correspondant à la charge demandée. J'utilise une bobine de bout dans laquelle j'ai calé un bouchon de liège dans lequel j'enfonce un outil allant sur la visseuse.
En gros, cela m'a permis de voir que je peux espérer tirer une centaine de watt d'un moteur de visseuse. Malheureusement, pour l'instant je n'atteins qu'une trentaine de watt à cause d'une limitation en intensité au niveau du circuit de puissance. Il peut s'agir du mécanisme de limitation du courant ou du mécanisme de limitation de la température

SIMULATION
J'ai développé un simulateur de cerf-volant 2D au feeling.
Il s'agit d'un modèle cinématique qui ne repose pas vraiment sur les équations de la physique.
J'ai fait une simple interface avec juste un rectangle blanc sur fond noir avec contrôle grâce à la souris

Le petit rectangle blanc représente le cerf-volant dans le simulateur 2D

PILOTAGE
Le simulateur m'a permis de développer un algorithme très simple de pilotage.
Il n'utilise que l'information d'orientation du cerf-volant.
Il s'agit donc à la base d'une sorte de garde-cap.
Si le cerf-volant est horizontal, il va aller vers le haut.
En modifiant son inclinaison il va aller sur le côté de la fenêtre, ce qui permet d'orienter la traction (relativement à la direction du vent)
Je fais ensuite varier l'inclinaison du cerf-volant de manière sinusoïdale, ce qui permet de faire des 8 autour d'une position d'équilibre et ainsi d'augmenter le vent apparent et de faire descendre le cerf-volant dans la fenêtre pour avoir plus de puissance

simpleCV

Ce soir j'ai découvert simpleCV ici au hasard de mes recherches
SimpleCV est une surcouche python d'openCV, qui facilite grandement les développements. Je ne l'ai pas encore vraiment essayé, mais vu la simplicité des exemples, je pense que l'essayer c'est l'adopter.

USB On The Go

Je croyais jusqu'à présent qu'un périphérique USB ne pouvait être que périphérique sur un fonctionnement maître-esclave.

Et bien je viens de découvrir que depuis 2 ou 3 ans certains périphériques (notamment les tablettes tactiles et maintenant les téléphones) permettent le fonctionnement en esclave ou en maitre.
Cela s'appelle USB On The Go (OTG).

Et bonne nouvelle mon téléphone (xperia mini) semble être un des premiers à avoir bénéficié de cette amélioration (qui est rendue possible par des modifications matérielles et pas seulement logicielles).

Cela m'ouvre donc la porte à la connexion de périphériques directement sur le téléphone.

En fait initialement, pensant que cela n'était pas possible, j'avais derrière la tête d'utiliser la prise jack pour interfacer la plaque arduino directement avec le téléphone. Et c'est en trouvant quelqu'un qui l'avait déjà fait que j'ai vu que cette solution était dépassée, car ceci est possible bien plus simplement avec l'USB.

http://code.google.com/p/usb-serial-for-android/

OpenCV+ Python + Wecam (2)

Aujourd'hui j'ai continué à me plonger dans le programme de traitement d'image.

J'ai rajouté un enregistrement de l'image, ainsi que la possibilité de sauvegardé un cliché avec la date et l'heure en pressant une touche du clavier.

J'essaie de réutiliser la démo camshift mais en l'améliorant pour que l'histogramme soit initialisé :
- sur une image (fixe et prédéfini) et une zone d'image sélectionné
- ou à défaut sur une zone en mouvement

Et le résultat est affreux : je me suis filmé pendant 5 minutes sans y faire attention, et bien ça vaut son pesant de cacahouète.

Voici le code