JR 500 @ Home

TIPE

Etude d’un mouvement rectiligne

I – Présentation de l’expérience et des objectifs

Le but de cette expérience est d’étudier le comportement de la Wiimote lorsqu’elle est soumise à un mouvement rectiligne (non uniforme).

L’expérience en elle-même est on ne peut plus simple : on pose la wiimote à plat sur une table puis on la déplace de manière rectiligne sur une distance que l’on notera D0.

Ce schéma résume la situation :

Afin de simplifier l’étude, on considèrera que la table est parfaitement plane et qu’ainsi la force de pesanteur n’a aucune composante sur l’axe Y de la WiiMote.

Les mesures effectuées porteront, dans un premier temps, uniquement sur l’accélération AccelY de la Wiimote. Charge à nous ensuite de d’effectuer une double intégration pour retrouver la position PosY de la WiiMote en fonction du temps.

Nota : pour que le mouvement soit toujours rectiligne, nous utiliserons une glissière afin de la maintenir droite et ainsi éviter toute composante selon l’axe X.

II – Résultats et exploitation

A) Première série d’expériences

Deux expériences ont été réalisées : une dite « longue », id est on fait glisser lentement la wiimote le long de la glissière et une autre dite « courte », où la vitesse de déplacement est beaucoup plus importante.

On fixe D0 = 40cm = 0,4m

Voici le tableau récapitulatif des résultats des deux expériences :

A la vue des résultats, il paraît évident que la wiimote a vraiment du mal à mesurer de faibles accélérations. Ainsi, une vitesse plus importante de la manette lui confère une précision accrûe, dans une certaine mesure toutefois, puisque la précédente expérience (service au tennis) a rapidement mis en évidence la limite de la wiimote (limite en accélération : 50 m/s²).

B) Deuxième série d’expériences

Les expériences effectuées sont identiques aux précédentes à ceci près que la distance D0 choisie est beaucoup plus importante : on fixe D0 = 9m.

Voici le tableau récapitulatif des résultats des deux expériences :

Encore une fois, il apparaît clairement qu’une accélération plus importante permet d’avoir des résultats beaucoup plus précis. Cela démontre bien la non propension de la Wiimote à mesurer de faibles accélérations. A contrario, la mesure d’accélérations de l’ordre de 10 m/s² est précise, surtout d’après les résultats de la dernière expérience qui révèle une marge d’erreur de seulement 9,22%. En effet, compte tenu de toutes les approximations faites au cours de l’expérience (mouvement plan, composante de la pesanteur négligée sur Y, etc…), ce résultat peut être considéré comme très bon. Rappelons que la Wiimote n’est qu’un simple capteur grand public développé pour une console de jeu, la Wii et que son coût est très limité (moins de 50€) par rapport à d’autres capteurs professionnels coûtant souvent bien plus de 1000€.

III – Bonus : photos de l’expérience

TIPE

Mesure du Roll

I – Protocole

On mesure successivement des angles de 0, 10, 20, et 40°.

Graphe représentant l’angle roll en ° en fonction du temps en ms.

Commentaire

L’expérience a été plus que concluante dans la mesure où la wiimote est capable de déceler des variations d’angle de l’ordre du dixième de degré, variations qu’il n’est pas possible de confronter avec un protocole expérimental simple faisant intervenir notre propre appéciation. Sur le graphe, les écarts angulaires des valeurs mesurées par rapport aux valeurs théoriques attendues sont dus au fait que la table où sur laquelle se déroulait l’expérience n’était pas parfaitement droite.

Bonus : Photos de l’expérience

TIPE

Compte rendu de l’expérience n°2

Service au tennis

I – Expérience n°1 – Protocole & résultats

L’expérience considérée est très simple. Il s’agit en effet d’étudier la variation des composantes de l’accélération de la Wiimote lors d’un service au tennis. Pour cela, une étude de 15 secondes a été réalisée, comprenant une série de 3 services.

Voici le graphe obtenu après l’exploitation des mesures par un tableur :

En bleu, l’accélération en X; en orange, l’accélération en Y et en jaune l’accélération en Z.

Le service a été effectué avec une force relativement faible, telle que la vitesse de la balle devait approcher les 75/80 km/h. Cependant, même avec une faible intensité, on remarque clairement les limites de la Wiimote : les mesures ne peuvent dépasser 50 m/s²…

Approximons tout de même l’accélération réelle de la balle :

• On considère que la phase d’accélération est terminée lorsque la balle n’est plus en contact avec la raquette; en effet, la balle est ensuite en chute libre avec une vitesse initiale horizontale de 75 km/h, soit 20.8 m/s².

• La durée du contact entre la raquette et la balle est très brève : moins d’un quart de seconde très probablement.

• L’accélération horizontale calculée est donc de Ax = 20.8*4 = 83.2 m/s². D’importantes approximations ayant été faites, on pose Ax = 80 m/s².

On remarque donc que même dans le cas d’un service classique peu puissant, on a Ax > AxWiiMoteMax.

Conclusion : la Wiimote n’est pas du tout adaptée à mesurer de fortes accélération, sa limite étant fixée à environ 5g. Ainsi, les jeux de simulation de tennis sur Wii font illusion : lors d’un service ou d’un coup droit trop violent, la vitesse de la balle est fausse et ne peut dépasser une certaine limite définie par les développeurs du jeu.

II – Expérience n°2 – Protocole et résultats

L’expérience n°2 est identique à l’expérience n°1. Seule la force de frappe du service a été fortement revue à la baisse; à tel point que l’on pourrait presque parler de « Mini-tennis ».

Voici le graphe représentant, comme précédemment, l’évolution des trois accélérations en fonction du temps.

NOTA : Malgré la faible puissance du service, la valeur absolue de l’accélération maximale avoisine 35 m/s², ce qui reste proche de la valeur limite de mesure en accélération de la Wiimote.

Effectuons une première acquisition à l’aide la wiimote.

I - Protocole

Pour cette première acquisition, ne soyons pas trop ambitieux. L’objectif est d’étudier le “roll” de la Wiimote dans une situation très simple : on pose la wiimote sur une table et on l’incline de 45° sur le coté gauche. On lâche. La wiimote effectue alors des oscillations autour de sa position d’équilibre.

On choisit un temps de mesure de 10 s pour un pas de 50 ms.

II - Résultats

Voici la représentation graphique (faite avec oocalc) des mesures effectuées par le programme.

III - Exploitation

Que dire de cette première acquisition sinon qu’elle paraît assez proche de l’évolution réelle de la wiimote : on voit bien une variation régulière forte et décroissante du roll.

Je vous avais dit que je ferai un petit compte rendu de tout ce que j’ai dû coder pour parvenir à ce résultat. Ce jour est arrivé (peut être plus tôt que prévu).

Voici la liste non exhaustive des étapes de mon travail :

• choisir une librairie sur le net permettant au programme de se connecter à la wiimote par bluetooth
• parcourir la documentation de la librairie en question (wiiuse) et adapter la boucle typique préconisée à mon programme (ce qui n’est pas forcément simple)
• choisir une librairie graphique, consulter la documentation
• coder toutes les fonctions inhérentes à la graphie :
• tracer une ligne (ça parait bête mais même ça il faut le coder !)
• tracer une ligne en dégradé
• tracer un cercle
• tracer un cercle en dégradé
• écrire du texte : cela implique une gestion des polices, ce qui n’est pas simple
• gérer les images : ouvrir et afficher des images de formats multiples
• créer des boutons et gérer leur comportement en fonction de la position de la souris
• créer une interface de saisie de texte
• créer une interface de saisie de nombre
• créer différentes boites de dialogue : warning, question, message…
• Tout cela passe bien entendu par :
• une gestion du clavier unicode
• une gestion de la souris (position, clics…)
• une gestion du temps pour ne pas surcharger le processeur
• la programmation de certains outils mathématiques
• une gestion de la mémoire (déclaration des variables : type int, long, float, double, char…)
• une gestion des évènements initiés par la wiimote
• une gestion des fichiers : création, écriture…
• des phases de tests…
• etc…

Illustration : boite de dialogue (message) :

Cela faisait un bout de temps que je n’avais pas posté de messages concernant le tipe. Mais en ce 1er Mai 2009, il est important que je fasse un petit “upgrade”. En effet,  depuis le dernier post, beaucoup de choses ont changé. J’ai tout d’abord changé de sujet de tipe : il s’agit à présent d’étudier la Wiimote (oui vous savez la manette de la console Wii de Nintendo) en tant que capteur. Pour cela j’ai dû concevoir de A à Z un programme permettant de récupérer les mesures de position, vitesse, accélération… envoyées par la wiimote. La tâche fut rude et ce n’est pas peu dire. J’ai utilisé la quasi-totalité de mon temps libre à programmer ce logiciel (oui, même pendant les vacances, dès que j’avais un peu de temps, hop…), soit une bonne cinquentaine d’heures. Le plus dur a été de me remettre au langage C dont je n’avais que quelques notions et bien entendu de gérer toutes les erreurs de compilation… Au cours du développement, j’en ai accumulé plusieurs centaines, allant de l’oubli du ‘;’ à la mauvaise définition de pointeur en passant par d’autres joyeusetés bien plus embêtantes.

Cependant, le logiciel est maintenant opérationnel, en version alpha 0.1 of course, ce qui veut dire que plusieurs bugs subsistent… mais dans l’ensemble ça fonctionne ! C’est bien là le principal.

Je ferais un peu plus tard un compte rendu de tout ce que j’ai dû coder pour parvenir à ce résultat.

En attendant un petit screenshot du menu principal :

Voici quatre vidéos où l’on peut voir évoluer le robot mavin dans diverses situations. Les vidéos ont été trouvées sur youtube.com après avoir effectué la recherche “ma vin robot”.

-

-

-

-

Vidéo de présentation du MA-VIN :

-

Vidéo présentant le MA-VIN tentant de sortir d’un labyrinthe :

-

Vidéo présentant le MA-VIN tentant de sortir d’un labyrinthe “en dur” :

-

MA-VIN en mode “suiveur de ligne” :

JR 500.

Après avoir effectué quelques recherches sur les photodiodes (un des capteurs du robot mavin), j’ai trouvé un PDF (et oui encore un !) provenant de la firme Hamamatsu concevant - entre autres - des photodiodes. Ce dernier recèle de nombreuses informations techniques expliquant le fonctionnement des dites diodes à l’aide de schémas, graphes et calculs. Partant du principe que le fonctionnement général d’une diode est à peu près le même quelque soit le constructeur, l’analyse de ces ressources pourrait, en première approche, permettre de définir les limites théoriques du capteur.

-

Lien vers le pdf.

JR 500.

Juste un petit billet pour dire que je suis passé à côté de la catastrophe… En effet lors de l’installation de l’extension de backup, j’ai été contraint de changer le chmod d’un des dossiers du serveur (le mettre en 0777). Mais horreur en arrivant sur le site -> internal server error… Heureusement il y a findus, remettre un chmod 0705 a résolu le problème. Au pire j’avais toujours une précédente sauvegarde sous la main, mais quand même… Ou comment être sauvé par Benjamin Franklin.

JR 500.

Ainsi fut faite, en ce 24 janvier 2009, la commande du robot MA-VIN. Quoi dire de plus sinon qu’il me sera expédié sous 8 jours et répondra présent en tant que cobaye pour mes premières expérimentations fixées à l’aube (ou au crépuscule) des congés si grâcieusement accordés en l’honneur du festif carnaval.

Mais arrêtons l’exercice de style et concentrons nous sur le principal. Lors de ma commande (sur conrad.fr), j’ai pû remarquer que ce dernier proposait un guide complet d’utilisation disponible en libre téléchargement sur le mavin. Je le mettrai sous peu en ligne, voici d’ores et déjà le lien vers le pdf (j’hésite d’ailleurs à l’uploader sur mon serveur, de par sa taille conséquente : 4.1Mo/600Mo attribués).

Concernant le prix, inutile de le cacher, d’autant plus qu’il est disponible d’accès à tout un chacun. 159.90€. Est-ce jusitifié ? L’avenir nous le dira, mais d’après toutes les recherches effectuées jusqu’à présent, j’ai des raisons pour placer en ce robot un certain espoir. Si je me trompe. Tanpis. Ou plutôt tant mieux. En effet la présence de problèmes sur un appareil n’est pas rédhibitoire, à condition que l’on puisse l’étudier et ainsi établir les causes de son mauvais fonctionnement…

Je profite de ce billet pour annoncer la mise en place d’une extension sur wordpress (invisible sur le site) qui permet de faire des sauvegardes de la db (database => base de données) du site (backup). Elle devenait de plus en plus indispensable dans la mesure où le nombre d’articles étant croissant, je ne pouvais me permettre de perdre l’intégralité de mon tipe sur un simple coup du sort (comprendre ici crash du serveur). J’essairai donc de faire des sauvegardes le plus souvent possible.

-

JR 500.