Apartés

Bonne nouvelle, je me suis remis a l’oeuvre sur les Mebius depuis le debut de la semaine. Esperons que ca dure ! Pour l’instant je me concentre sur le probleme de l’absence de memoire dynamique sur l’Arduino. Je refais donc mon propre systeme de gestion de memoire.

J’ai achete The Emperor’s New Mind de Penrose, et je vais commencer a le lire assez rapidement je pense.

Publicités

Toujours pas de travail et toujours aussi peu productif cote Mebius…

J’ai passe ces dernieres semaines a mettre au propre un rapport sur un algorithme de detection de collision d’objets 3D que j’ai developpe pour un test d’embauche dans une boite de jeu video. Si le sujet vous interresse, jetez un oeil ici : http://www.bayashiinjapan.net/CollisionDetection/

Ma recherche d’emploi m’occupant beaucoup en ce moment je n’ai pas touche aux Mebius, mais j’ai quand meme pu realiser la plupart des exemples du starter kit de mon Arduino Uno. C’est vraiment facile a prendre en main, meme si je suis pas autant a l’aise sur la partie electronique que la partie programmation. Au moins ca m’a suffit pour me fixer les idees sur un premier montage equivalent a mon cas test de trackage de cible. Au dela de l’electronique une autre difficulte va etre de trouver comment fabriquer les elements mecaniques. Des Lego me seraient bien utile mais je n’en ai pas sous la main et je vais devoir reflechir a autre chose. Pour l’instant je vais finir le menage du code et sur les adaptations necessaires a une version embarquee sur Arduino.

A part ca j’ai fini de lire le G.E.B. de Hofstadter, que j’ai adore !

 

Ma recherche d’emploi m’occupant beaucoup en ce moment

Meme si je n’ai toujours pas retrouver de boulot ma situation s’est un peu amelioree et du coup je me suis un peu remis a travailler sur mes Mebius. Cette semaine j’ai fait beaucoup de menage dans le code.

Mais surtout la grande nouvelle c’est que je viens de recevoir un Arduino en cadeau d’anniversaire ! Je suis tout excite et ca va probablement me remotiver pour passer du temps sur les Mebius. Quel rapport ? Et bien je vois en un Arduino une merveilleuse plateforme de test pour sortir mes Mebius d’un environnement simule vers le monde reel. Il y a d’ailleurs deux facons de faire : soit tout embarque (je charge le mebius dans l’atmega et ca tourne en autonome), soit en deporte (le mebius tourne sur l’ordi mais ses I/O sont connectees a celles de l’arduino via une communication serie geree par l’atmega cote Arduino et un petit bout de code cote ordi).

Le tout embarque etant le plus excitant je vais probablement pas resister a m’y attaquer en premier, meme s’il pose le challenge d’arriver a faire tourner mon algo sur un Arduino Uno. J’y ai en fait deja beaucoup reflechis (depuis que j’ai decouvert l’Arduino) et ca me parait pas infaisable, mais le peu de memoire disponible rendra probablement le Mebius tres peu performant. Et puis si ca peut tourner sur un Uno ca sera super prometteur pour des versions plus puissantes. En mode deporte ca serait moins chouette mais ca permettrait deja de verifier que le Mebius est capable de reagir et interagir avec de veritables senseurs/acteurs.

Mais tout d’abord je vais finir le menage du code et me faire la main sur les exemples de code pour apprendre a programmer l’Arduino. J’en parlerai aussi ici. Ah, et puis avoir un truc physique dans le projet Mebius va aussi me donner l’occasion de mettre quelques photos (peut etre meme des videos ?) sur ce blog, histoire de changer des graphiques surement enigmatiques pour certains !

 

Meme si je n’ai toujours pas retrouver de

Rien fait depuis le dernier post, et je ne sais pas trop quand je vais pouvoir m’y remettre. Actuellement je cherche du boulot. Quand j’aurai trouve j’aurai l’esprit un peu plus libre et tranquille pour m’y replonger…

 

Rien fait depuis le dernier post, et je

Finalement la representation graphique du mebius en train de penser m’a emmene de plus en plus loin et voila deux semaines passees !
J’ai pu faire ce que je voulais, mais ca donne des choses dans ce genre (pour les curieux, le programme C genere un script POV-ray que j’execute pour produire l’image ci-dessous) :

Image

Pour moi qui sait ce que ca represente exactement c’est deja pas evident alors a expliquer ca va etre un roman, je laisse tomber. Par contre c’etait une bonne idee de le faire car ca m’a permis de me rendre compte de tout un tas de choses qui m’ont amene a ameliorer/corriger plusieurs bouts de l’algo. Du coup ca va plus vite, ca utilise moins de memoire et c’est plus performant. Cool !
Comme j’ai touche l’algo, je remet quelques courbes ici pour memoire des nouveaux resultats, a comparer avec les posts precedents.

Image

Distance a la cible avec modification du coefficient de deplacement. (sur le 3e intervalle le coefficient est trop faible par rapport a la vitesse de la cible, d’ou l’echec du mebius a converger)

 bigtest2

Distance moyenne a la cible en fonction de la quantite de memoire disponible et du nombre de reconfiguration du coefficient de deplacement. Wahoo, ca decoiffe ! Par rapport a la version precedente la distance moyenne minimale est divisee par deux, et elle est atteinte quelque soit le nombre de reconfiguration du coefficient de deplacement des 10ko de memoire (j’ai remplace la serie a 3mo par une serie a 3ko). En temps d’execution c’etait aussi 10% plus rapide (mais je n’ai toujours pas fait d’optimisation).

Maintenant, il y a encore autre chose que j’aimerai teste sur cette experience. Jusqu’a present je demandais au mebius de se tenir au plus proche de la cible, ce qu’il arrive a faire tres bien. Mais quand on regarde dans le detail ce qu’il fait, on se rend compte qu’il peut choisir de pousser a droite de 0.2 et a gauche de 0.1 pour se deplacer vers la droite de 0.1. Il a raison et ca marche tres bien, mais si on se place dans un contexte logiciel embarque ca pose un probleme : la probable consommation de resources inutilement. On peux imaginer des systemes ou (0.2,0.1) equivaut a (0.1,0.0) en terme de resources consommees, mais meme si ca peux exister il ‘en reste pas moins interressant de se pencher sur la question pour les systemes ou ce n’est pas le cas. Je peux tres simplement, via le fichier de configuration, lui demander de limiter autant que possible l’utilisation de ses ‘muscles’. D’un cote je lui demande de pas bouger pour economiser, de l’autre de bouger pour traquer la cible, comment va-t-il reagir ?
Egalement, avant l’experience suivante prevue, je pense que faire jouer le mebius au morpion permettrait de tester une autre problematique importante (qui etait aussi l’un des objectifs de l’experience suivante, mais noye dans un contexte plus complexe). Ca illustrerait aussi une application differente de celle du logiciel embarque, donc ca me semble interressant.
Enfin je continue a zieuter distraitement du cote de l’arduino, en cherchant une idee seduisante de collaboration mebius/arduino.

En faisant varier la quantite de memoire utilisee j’ai continue a faire des runs pour essayer de mieux comprendre ce qu’il se passe. Le probleme c’est que la composante aleatoire de l’experience rend l’interpretation des resultats difficile. Un coup ca a l’air de bien marche, un coup ca a l’air de trainer les pieds… Alors j’ai pris le taureau par les cornes et j’ai automatise une grosse serie de test pour ensuite calculer des moyennes en fonctions des variables. Precisement, j’ai fait ceci : sur l’experience de trackage de cible le long d’un axe d’une duree de 500.000 iterations, j’ai fait varier la quantite de memoire entre 1ko, 10ko, 500ko, 1mo, 3mo, et le nombre de variation du coefficient de deplacement (obligeant le mebius a se reconfigurer pour s’adapter) entre 0, 2, 4, 6, 8 et 10. En sortie j’ai recupere la moyenne de l’ecart a la cible sur tout le run, et la moyenne de l’ecart a la cible sur chaque deuxieme demi-periode entre deux variations de coefficient de deplacement (ca c’est pour mesurer la performance du mebius apres qu’il se soit reconfigure suite a un changement de coefficient en lui laissant le temps de se reconfigurer). Pour chaque combinaison memoire/nombre de variation de coeff de deplacement j’ai fait 10 run et ensuite calcule leur moyenne. Et roule ma poule !
Deja, ca fait un total de 150.000.000 d’iterations. Que ca ait tourne jusqu’au bout sans planter c’est plutot bon signe niveau stabilite du code. Ensuite j’ai aussi mesure le temps d’execution. Etant donne qu’il y a toute la partie simulation de l’environnement et calcul/stockage des resultats ca ne donne qu’une limite tres tres superieure a la vitesse d’execution des mebius seuls, mais on est a environ 20 microseconde par iteration (sur mon i3-2120 (3.30GHz × 4)). La aussi ca me satisfait pleinement. Au passage, a une telle vitesse d’execution, le rythme auquel j’impose une modification de son environnement est extremement eleve. S’il supporte ca je me dis qu’il serait largement capable d’encaisser d’importe quoi dans un systeme embarque lache dans le monde reel. Cote memoire c’est pareil ca semble peu gourmand a la vue des resultats qui suivent.
Et maintenant les resultats : 

Image

A part pour la quantite de memoire minimum qui est un peu au dessus de 0.1, on est toujours inferieur a un ecart de 0.1, c’est pas mal du tout. Avec 1ko le mebius a vraiment pas beaucoup d’espoir, ca correspond a une configuration ou il oublie quasi immediatement … Pour autant il s’en sort quand meme pas mal, surtout s’il est dans un environnement stable (coefficient de deplacement ne variant pas ou peu). Ca c’est grace a un mecanisme d’extrapolation qui lui permet de ne pas oublier completement meme quand il « oublie », mais je ne donnerai pas plus de details. Avec 10ko c’est mieux mais ca reste un peu short, donc logiquement les performances sont meilleures. Avec 500ko, 1mo et 3mo, on obtient des performances equivalentes qui diminuent lentement au fur et a mesure que l’environnement est de plus en plus instable. Ca n’apparait pas sur le graphique, mais les moyennes totales sont tres tres proches des moyennes sur les demi-periodes sur tout les runs, indiquant qu’a chaque fois le mebius s’est reconfigure tres rapidement apres un changement  de coefficient de deplacement.
Conclusion, ca fonctionne de facon tres satisfaisante et je suis content. Passe une certaine quantite de memoire minimale necessaire pour faire son boulot (quelque part entre 10ko et 500ko sur ce cas de test) le mebius s’en sort tres bien (ecart moyen a la cible tres faible), independamment de la quantite de memoire dispo (ecart similaire quelque soit la quantite de memoire) et s’adapte visiblement avec succes a un environnement instable (ecart a la cible variant peu quand le nombre de modification du coeff de deplacement augmente).
Maintenant que j’ai confiance en mes mebius sur cet exemple je vais pouvoir me concentrer sur le deuxieme cas test, plus complexe, realiste et interressant. Juste avant ca je vais peut etre faire un petit truc pour le fun : comme pour les mebius de premiere generation, j’aimerai bien « visualiser » ce qu’il se passe « dans la tete » d’un mebius. J’ai eu une idee qui devrait donner un resultat esthetique pas degueu, alors je vais probablement prendre quelques heures pour la coder…

 

 

En fait, qu’ils soient plus lents me preoccupait tellement que je n’ai pas pu m’empecher de chercher a savoir pourquoi. Alors j’ai continue a faire plein de run sur le premier cas de test. Je n’ai toujours pas compris pourquoi mais aujourd’hui j’ai remarque quelque chose d’interressant. Dans cette nouvelle version, je peux controler la quantite de memoire qu’utilise les mebius. J’ai ajoute ca dans l’optique « embarque » ou j’aurai besoin de les faire tourner dans un environnement avec peu de memoire. Je peux donc maintenant dire au mebius via le fichier de configuration ‘debrouille toi avec 1ko’. Et aujourd’hui je me suis rendu compte qu’en lui imposant d’utiliser peu de memoire je retrouve exactement les meme resultats que dans la version precedente. Si je le laisse utiliser beaucoup plus de memoire, il converge plus lentement. Aussitot je me suis dit ‘bug !’, et puis plus prudemment je me dis que c’est peut-etre un comportement normal mais imprevu de ce nouveau modele. Dans les deux cas j’ai maintenant une piste a explorer pour corriger ce probleme…

 

J’ai fini de nettoyer les bugs dans cette nouvelle version des mebius et j’obtiens les memes resultats que precedemment sur le premier cas de test, a la difference qu’ils sont plus lents a converger. Je vais maintenant regarder ce que ca donne sur le deuxieme cas test.

 

Hier j’ai fini de demeler le sac de noeud et resolu mon bug, grace a valgrind. Maintenant je dois verifier que ca fonctionne toujours sur le premier cas test (track de cible en 2D). Au premier run ca ne marchait pas, mais pas de quoi s’inquieter pour l’instant, on va regarder tout ca tranquillement…