J'ai commencé le traitement vidéo permettant de retrouver les deux leds, ce qui permettra de retrouver la position et l'orientation du cerf-volant.
 |
| Les cercles fins correspondent aux positions trouvées par l'algorithme |
Le code est ici
lundi 11 novembre 2013
Cerf-volant dans la nuit
J'avais déjà posté la vidéo du cerf-volant équipé de LED scintillantes blanche et rouge
J'ai commencé le traitement vidéo permettant de retrouver les deux leds, ce qui permettra de retrouver la position et l'orientation du cerf-volant.
Le code est ici
J'ai commencé le traitement vidéo permettant de retrouver les deux leds, ce qui permettra de retrouver la position et l'orientation du cerf-volant.
Le code est ici
Scipy 2013
Scipy est une bibliothèque scientifique très célèbre pour python.
La conférence Scipy 2013 s'intéressait à Scipy mais plus généralement à l'utilisation de python pour les scientifiques, et par exemple à Sympy qui permet de faire du calcul symbolique avec python.
Parmi les nombreuses présentations en ligne, c'est celle de Pydy qui m'intéressait. Pydy est une bibliothèque pour la simulation de système dynamique, par exemple pour faire du contrôle (l'exemple correspondait à un pendule inversé à N degrés de liberté). Une alternative serait arboris, dont j'aime l'API mais qui n'est plus mis à jour, et n'a pas la même ambition.
Le site de Pydy est actuellement buggé, et l'installation pas encore évidente, mais j'ai réussi à le faire fonctionner à partir des sources.
Mon objectif est pour l'instant de faire un simple modèle de pendule, avant de coder les équations du vol d'un cerf-volant.
La conférence Scipy 2013 s'intéressait à Scipy mais plus généralement à l'utilisation de python pour les scientifiques, et par exemple à Sympy qui permet de faire du calcul symbolique avec python.
Parmi les nombreuses présentations en ligne, c'est celle de Pydy qui m'intéressait. Pydy est une bibliothèque pour la simulation de système dynamique, par exemple pour faire du contrôle (l'exemple correspondait à un pendule inversé à N degrés de liberté). Une alternative serait arboris, dont j'aime l'API mais qui n'est plus mis à jour, et n'a pas la même ambition.
Le site de Pydy est actuellement buggé, et l'installation pas encore évidente, mais j'ai réussi à le faire fonctionner à partir des sources.
Mon objectif est pour l'instant de faire un simple modèle de pendule, avant de coder les équations du vol d'un cerf-volant.
Oscilloscope
Je n'étais pas satisfait des oscilloscopes (pour visualisation des pins sur l'arduino) que j'avais trouvés sur le net :
-utilisation de langages que je ne maîtrise pas
-fréquence de rafraichissement visible.
J'ai donc modifié quelques projets pour avoir ma propre version d'un oscilloscope (toujours dans le navigateur avec HTML5).
J'utilise la bibliothèque javascript flotr2.js, développée dans le secteur financier.
J'ai d'abord essayé d'utiliser firmata (avec pyfirmata) pour sonder les données, mais c'était trop lent (3 données par secondes environ).
Finalement j'envoie les données de l'arduino en continue (toutes les 20ms environ) et vient les lire encore plus vite avec le PC (serveur tornado).
Les données sont ensuite envoyées vers le navigateur via websocket + JSON.
Les données une fois récupérées sont mises en forme par flotr2.
J'ai eu quelques problèmes de résolution, qui m'ont conduit à finalement envoyer les données sous forme d'entier (0 à 1023) puis à normaliser dans le navigateur pour avoir un résultat entre 0 et 1.
Le code source est là. Pour moi l'objectif est d'intégrer le tout dans l'interface de contrôle du cerf-volant.
Amélioration à prévoir :
- ajout de légende (fait)
- pouvoir stopper le défilement
- pouvoir choisir les voies à afficher
- pouvoir choisir la durée (30s, 5min, 30min, etc...)
- incorporer avec slider pour contrôle pwm
-utilisation de langages que je ne maîtrise pas
-fréquence de rafraichissement visible.
J'ai donc modifié quelques projets pour avoir ma propre version d'un oscilloscope (toujours dans le navigateur avec HTML5).
J'utilise la bibliothèque javascript flotr2.js, développée dans le secteur financier.
J'ai d'abord essayé d'utiliser firmata (avec pyfirmata) pour sonder les données, mais c'était trop lent (3 données par secondes environ).
Finalement j'envoie les données de l'arduino en continue (toutes les 20ms environ) et vient les lire encore plus vite avec le PC (serveur tornado).
Les données sont ensuite envoyées vers le navigateur via websocket + JSON.
Les données une fois récupérées sont mises en forme par flotr2.
J'ai eu quelques problèmes de résolution, qui m'ont conduit à finalement envoyer les données sous forme d'entier (0 à 1023) puis à normaliser dans le navigateur pour avoir un résultat entre 0 et 1.
Amélioration à prévoir :
- ajout de légende (fait)
- pouvoir stopper le défilement
- pouvoir choisir les voies à afficher
- pouvoir choisir la durée (30s, 5min, 30min, etc...)
- incorporer avec slider pour contrôle pwm
Kite line mount
Je réfléchis depuis quelques temps à un système léger pour monter mon téléphone sur les lignes avants.
J'avais pour l'instant réalisé un premier prototype avec des morceaux de bois, des colsons et un sandow (le téléphone était dans une house étanche).
Il y avait trop de bois (trop lourd, trop d'inertie).
Les colsons étaient fermés autour de la ligne et ce n'était pas pratique pour les enlever/remettre.
Le sandow ne tenait pas.
Cahier des charges
-léger
-équilibré
-peu d'inertie (pour bien suivre les mouvements des lignes
-accès à l'écran du téléphone et aux touches sur les côtés
-champ de vision de la caméra arrière libre
-démontable
-fixe ou glissant sur les lignes au choix
-s'adapte au niveau de la jonction de deux lignes en V, ou sur une ligne seule
J'avais trouvé des modèles commerciaux, mais je réfléchissais à imprimer un support avec une imprimante 3D. J'ai trouvé ce modèle http://www.thingiverse.com/thing:27109 pour une gopro.
J'ai fait un prototype (en carton!) afin de voir comment adapter ceci à un téléphone dans une housse souple (à noter le petit trou pour la caméra)
J'hésite à utiliser des pattes comme sur le système pour la gopro, ou à utiliser de simples baguettes de reliure. De même je pense que la plus grande partie du support peut se faire avec une plaque à découper, sur laquelle seraient vissés des embouts plastiques.
Edit 25/11/2013 : nous avons réfléchis à supprimer au maximum la structure avec Jean-Pierre. Cela pourrait donner quelque chose comme ça :
J'avais pour l'instant réalisé un premier prototype avec des morceaux de bois, des colsons et un sandow (le téléphone était dans une house étanche).
Il y avait trop de bois (trop lourd, trop d'inertie).
Les colsons étaient fermés autour de la ligne et ce n'était pas pratique pour les enlever/remettre.
Le sandow ne tenait pas.
Cahier des charges
-léger
-équilibré
-peu d'inertie (pour bien suivre les mouvements des lignes
-accès à l'écran du téléphone et aux touches sur les côtés
-champ de vision de la caméra arrière libre
-démontable
-fixe ou glissant sur les lignes au choix
-s'adapte au niveau de la jonction de deux lignes en V, ou sur une ligne seule
J'avais trouvé des modèles commerciaux, mais je réfléchissais à imprimer un support avec une imprimante 3D. J'ai trouvé ce modèle http://www.thingiverse.com/thing:27109 pour une gopro.
J'ai fait un prototype (en carton!) afin de voir comment adapter ceci à un téléphone dans une housse souple (à noter le petit trou pour la caméra)
J'hésite à utiliser des pattes comme sur le système pour la gopro, ou à utiliser de simples baguettes de reliure. De même je pense que la plus grande partie du support peut se faire avec une plaque à découper, sur laquelle seraient vissés des embouts plastiques.
Edit 25/11/2013 : nous avons réfléchis à supprimer au maximum la structure avec Jean-Pierre. Cela pourrait donner quelque chose comme ça :
 |
| Le système ne tient plus qu'avec des fils et des pinces (trombonnes ici!) |
 |
| Pour rappel, le premier prototype en bois (les fils ne sont pas utilisés) |
Correction bug magnétomètre
J'ai finalement trouvé le problème avec le magnétomètre. L'erreur ne venait ni de l'algorithme utilisé, ni de son implémentation, ni même de la qualité intrinsèque du magnétomètre.
Le problème semble être une erreur de signe dans les données reçues depuis le téléphone mobile. Le signe sur l'axe Y était inversé (les conventions sur les autres axes étaient les mêmes pour accéléromètre et magnétomètre sauf pour un des axes).
J'ai trouvé le bug grâce au développement d'un outil de visualisation de l'attitude du téléphone dans le navigateur (copie d'écran ou vidéo à venir)
Le code source est là
Le problème semble être une erreur de signe dans les données reçues depuis le téléphone mobile. Le signe sur l'axe Y était inversé (les conventions sur les autres axes étaient les mêmes pour accéléromètre et magnétomètre sauf pour un des axes).
J'ai trouvé le bug grâce au développement d'un outil de visualisation de l'attitude du téléphone dans le navigateur (copie d'écran ou vidéo à venir)
Le code source est là
mercredi 6 novembre 2013
Détermination de l'attitude à partir de 2 vecteurs d'observation
Actuellement, pour estimer l'attitude du téléphone, j'utilise le magnétomètre et l'accéléromètre (ce qui suppose peu de mouvement du téléphone). L'algorithme utilisé n'utilise que les directions, pas les amplitudes.
Un autre algorithme utilise les amplitudes. Il demande donc de connaître a priori le champ magnétique (amplitude et inclinaison avec la verticale), mais doit en échange permettre une plus grande robustesse aux accélérations.
En voici une implémentation en python que j'ai testé, mais cela ne résoud toujours pas mes problèmes d'irrégularité des mesures:
https://github.com/muzhig/ESOQ2
Un autre algorithme utilise les amplitudes. Il demande donc de connaître a priori le champ magnétique (amplitude et inclinaison avec la verticale), mais doit en échange permettre une plus grande robustesse aux accélérations.
En voici une implémentation en python que j'ai testé, mais cela ne résoud toujours pas mes problèmes d'irrégularité des mesures:
https://github.com/muzhig/ESOQ2
lundi 4 novembre 2013
Calibration magnétomètre
J'utilise le magnétomètre du téléphone portable.
Le cap évolue bien si le téléphone est debout ou couché, mais il peut avoir un biais et ce biais n'est pas le même lorsque le téléphone est couché ou debout.
Je pense que cela est dû à des problèmes d'offset.
Ces erreurs systématiques doivent pouvoir être corrigées par une calibration.
Ces erreurs sont décrites dans http://www.freescale.com/files/sensors/doc/app_note/AN4246.pdf. Les mesures se trouvent sur une ellipsoide décentrée au lieu d'une sphère. Il faut identifier cette ellipsoide pour pouvoir corriger. Un algorithme permettant d'identifier seulement le centre de l'ellipsoid est proposé dans ce document.
Un post sur le forum diydrones http://diydrones.com/forum/topics/magnetometer-soft-and-hard-iron-calibration s'intéresse également à la correction des mesures.
Le post http://www.varesano.net/blog/fabio/ellipsoid-sphere-optimization-using-numpy-and-linalg présente un algo en python mais qui ne traite pas le cas générique.
J'ai récupéré le fichier de test http://www.varesano.net/files/acc.txt et l'ai testé avec le code donné dans http://davidegironi.blogspot.it/2013/01/magnetometer-calibration-helper-01-for.html#.UnfKgHjSWRY. Le code est en matlab mais fonctionne en grande partie avec octave.
Le code complet que j'ai utilisé est ici
Pour l'acquisition des données, j'ai utilisé le script https://github.com/baptistelabat/robokite/blob/master/ObjectTracking/mobileState.py que j'ai légèremment adapté pour créer un fichier de sauvegarde.
Voici les résultats obtenus pour l'identification de l'ellipsoide
Ellipsoid center :
0.177 -0.107 0.566
Ellipsoid radii :
46.6 45.6 43.3
Ellipsoid evecs :
-0.816442 0.42536 -0.390503
0.319485 0.896097 0.308123
-0.480991 -0.126805 0.867507
Ellpisoid comp evecs :
0.948847 0.0100939 -0.0268862
0.0100939 0.948304 -0.00195987
-0.0268862 -0.00195987 0.984806
Et voici une image des données initiales (rouges) et corrigées (bleues)
Je trouve malheureusement que la différence n'est pas significative... A creuser.
Le cap évolue bien si le téléphone est debout ou couché, mais il peut avoir un biais et ce biais n'est pas le même lorsque le téléphone est couché ou debout.
Je pense que cela est dû à des problèmes d'offset.
Ces erreurs systématiques doivent pouvoir être corrigées par une calibration.
Ces erreurs sont décrites dans http://www.freescale.com/files/sensors/doc/app_note/AN4246.pdf. Les mesures se trouvent sur une ellipsoide décentrée au lieu d'une sphère. Il faut identifier cette ellipsoide pour pouvoir corriger. Un algorithme permettant d'identifier seulement le centre de l'ellipsoid est proposé dans ce document.
Un post sur le forum diydrones http://diydrones.com/forum/topics/magnetometer-soft-and-hard-iron-calibration s'intéresse également à la correction des mesures.
Le post http://www.varesano.net/blog/fabio/ellipsoid-sphere-optimization-using-numpy-and-linalg présente un algo en python mais qui ne traite pas le cas générique.
J'ai récupéré le fichier de test http://www.varesano.net/files/acc.txt et l'ai testé avec le code donné dans http://davidegironi.blogspot.it/2013/01/magnetometer-calibration-helper-01-for.html#.UnfKgHjSWRY. Le code est en matlab mais fonctionne en grande partie avec octave.
Le code complet que j'ai utilisé est ici
Pour l'acquisition des données, j'ai utilisé le script https://github.com/baptistelabat/robokite/blob/master/ObjectTracking/mobileState.py que j'ai légèremment adapté pour créer un fichier de sauvegarde.
Voici les résultats obtenus pour l'identification de l'ellipsoide
Ellipsoid center :
0.177 -0.107 0.566
Ellipsoid radii :
46.6 45.6 43.3
Ellipsoid evecs :
-0.816442 0.42536 -0.390503
0.319485 0.896097 0.308123
-0.480991 -0.126805 0.867507
Ellpisoid comp evecs :
0.948847 0.0100939 -0.0268862
0.0100939 0.948304 -0.00195987
-0.0268862 -0.00195987 0.984806
Et voici une image des données initiales (rouges) et corrigées (bleues)
Je trouve malheureusement que la différence n'est pas significative... A creuser.
Inscription à :
Articles (Atom)