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.

 

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 !

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.

 

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.

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) :

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.

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)

 

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.