Finalement, une fois que j’ai mis le doigt dans cette histoire de rapport je n’ai plu pu m’arreter. J’ai passer presque toute la semaine a ecrire ! Je commence par presenter le projet, ensuite je vais mettre petit a petit au propre ce que j’ai fait jusqu’ici et qui est presente en vrac dans ce blog. Au passage, je redige en anglais, et j’utilise Latex.

Je continue aussi a lire le livre de Penrose.

Publicités

 

 

 

 

 

 

J’ai fini les modifications necessaires pour integrer mon mebius sur un Arduino, et apres quelques bugs inevitables resolus en deux temps trois mouvements, ca marche ! 😀

Une photo, pour la posterite 😉

Image

Rien de bien folichon pour l’instant, ca se contente de controller la luminosite d’une led en la ‘regardant’ via une photoresistance de sorte qu’elle atteigne une valeur imposee par l’utilisateur via un potentiometre. C’est le plus simple exemple possible : une entree, une sortie, et des composants qui reagissent selon une fonction unite (au bruit pres).

Maintenant je vais mettre un peu au propre les resultats de ce premier test.

A part ca j’ai commence a ecrire un rapport a propos de ce projet, ou j’aimerai mettre au propre et presenter tout ce que j’ai fait (et ferai). Je sais pas si le courage va me tenir bien longtemps mais de toute facon a terme il faudra bien que je le fasse alros autant commence des maintenant, petit a petit.

 

 

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.

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

Pas une minute a consacrer aux Mebius en 2 semaines, pas glop ! Mais aujourd’hui j’ai pu m’y remettre et tester les Mebius en mode ‘econome’.

Pour commencer, je refais un run dans les memes conditions que precedemment mais en mesurant la somme des poussees (gauche,droite). Sur le graphe ci-dessous, c’est la courbe rouge. Chaque valeur de poussee varie entre 0.0 et 1.0, la somme varie donc entre 0.0 et 2.0, et sur ce run on a une poussee totale egale a 1.07 en moyenne a chaque iteration. En bleu la distance a la cible, 0.01 en moyenne, pour une memoire disponible de 50ko, comme precedemment.

eco1

 

Ensuite je rajoute dans le fichier de configuration la contrainte ‘minimiser chaque poussee’, et je refais un run, cf graphe ci-dessous. Cote distance a la cible, on obtient 0.02, un peu plus que sur le run precedent, mais faisant plusieurs runs ca semble en moyenne donner des resultats similaires. Cote poussee totale, ca a significativement diminue. On a une poussee totale moyenne de 0.57, soit 53% du run precedent. Joli !

eco2

Mais je me suis demande jusqu’ou ca pouvait descendre. Alors j’ai refait un run en immobilisant la cible, cf graphe ci-dessous. A priori, une fois que le mebius s’est positionne dessus, la contrainte de minimisation de la poussee devrait l’amener a s’immobiliser totalement. Pourtant la poussee totale moyenne se stabilise autour de 0.14. Pour comprendre pourquoi le mebius ne s’immobilise pas il suffit de regarder la distance a la cible : elle se stabilise autour de 0.002. C’est tres petit mais pas nul : le mebius ne peut jamais se trouver exactement sur la cible a cause de la precision finie de ses valeurs de poussee. Les capteurs que je modelise dans cette exemple mesurant la distance exacte, le mebius ressent en permanence la cible un poil trop a gauche ou un poil trop a droite, et cherche en vain a ameliorer sa position.

eco3

 

Ensuite j’ai simplement reverifie qu’avec un coefficient de poussee variable tout se passe toujours bien, cf graphe ci-dessous. En terme de distance a la cible on obtient des resultats equivalents a ceux sans la contrainte de minimisation de la poussee. Cote poussee totale moyenne, en toute logique elle baisse proportionnellement a l’augmentation du coefficient de poussee.

eco4

Conclusion, meme avec plusieurs contraintes antagoniques le mebius arrive a converger vers une solution optimale.

 

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…