Mouahahah (oh non pas lui 
)
Me revoilà avec plein de questions! (ta dernière réponse m'a beaucoup donné à réflexion)Son Of Sparda is Back ! No malaises ! Tes interventions sont toujours constructives et interressantes donc c'est un plaisir de te répondre
Par ailleurs, je suis heureux que mes réponses t'ai données à réflexions car c'est a ce prix que la robotique fera des progrés. Il est necessaire que les gens motivés s'investissent et la première étape et le dialogue et l'échange de concepts. Donc c'est tout bénef
Concernant les yeux de Caliban...
Pourquoi y en a t'il deux? Tu fais une synthése des deux comme pour l'oeil humain? Qu'est-ce que ça apporte?héhéhé, voila un sujet qu'il est interressant. En fait au départ, Caliban n'avait qu'un seul oeil et c'est sur cet unique oeil qu'ont été développés ses différents algo et process de la vision (point que j'aborderai plus bas). Cependant, aujourd'hui les deux sont actifs et complémentaires. En fait, Caliban recherche des mouvement et/ou forme sur ses deux yeux. Il existe alors deux possibilités. Soit la "cible acquise" se trouve dans le champs de vision des deux soit sur un seul (ferme un des yeux tu verras que ton champs de vision n'est pas le même). Bref, son mapping heuristique agit sur les servomoteur pour fait en sorte que la "cible" se retouve au centre du champs visuel de son oeil gauche (pourquoi le gauche ? -> parce que historiquement, c'est le premier que Caliban a apprit a exploiter). Une fois ceci fait, il recherche la "cible" acquise sur l'oeil gauche mais sur l'oeil droit. Si cette cible est connue comme un visage ou son jouet (taille réelle enregistrée dans sa base), il calcul la distance a laquelle se trouve l'objet (car sur l'oeil droit, la centre de la cible ne se trouvera jamais sur le centre de l'image donc il connait l'angle entre les deux images et, en connaissant l'angle et la taille de l'objet, il peut calculer la distance). Cela est trés important car en connaissant la distance à laquelle se trouve la cible, cela lui permet d'ajuster ses mouvement quand la cible bouge puisque plus cette dernière est proche, plus il devra bouger la tête pour ramener la cible au centre de son image de gauche. Bref, pour résumer, il tente d'amener une "acquisition" au centre de son champs de vision gauche en appliquant aux mouvement de sa tête une valeur moyenne puis une fois ceci fait, il détermine la distance de la cible pour ajuster l'amplitude de ses mouvements pour la "poursuivre" avec plus d'efficacité qu'en appliquant une valeur moyenne
Pour mon trés trés futur j'imaginais un telemetre, couplé à la webcam le robot pourrait faire des scans 3D du tonerre!C'est vrai que ce serait quelque chose d'enfer mais de notre coté, nous préférons utiliser des récepteurs le plus proche possible de ceux de l'homme car ce qui nous préoccupe avant tout et de reproduire le fonctionnement du cerveau humain. Mais je suis d'accord sur le fait que ce pourrait être un raccourci plus qu'efficace
Je me suis explosé les yeux en regardant la vidéo de caliban pour essayer de mater ton écran (la curiosité est un vilain défaut je sais ) On voit deux petites fenêtres, chaque "oeil"? Et la grande à l'air de comporter pas mal d'infos supplémentairesMDR ! Ravi que cette vidéo soit stimulante. Effectivement, les deux fenêtre sont les images perçues par chaque œil avec différents indicateurs s’affichant sur les images afin que nous puissions surveiller ce qu’il surveille . La grande fenêtre quand à elle permet d’afficher le « log de traitement » en temps réel afin que nous puissions voir comment la matrice heuristique est activée et quels sous procédures sont lancées quand et pourquoi. Il est cependant utile de préciser que l’interface a bien changée depuis cette vidéo et que les différentes notions exploitées se présentent a l’écran sous forme d’icones en mouvement liés entre eux. Mais je vais bientôt faire une vidéo de tout cela.
Pour le traitement du signal vidéo tu utilises open CV ? OH QUE NON ! Si OpenCv est une très bonne API, nous ne voulons l’utiliser en aucun cas. A cela deux raisons. La première est que nous ne voulons pas être dépendants de développements effectués par autrui. En effet, nous voulons pouvoir modifier les process a notre guise pour calibrer au mieux les procédures génériques aux besoins réels de Caliban. De plus cela nous évite de devoir faire des mises a jours foireuses car la compatibilité ascendante et descendante n’est pas toujours la priorité des codes Open source. Or nous avons suffisement de travail pour devoir nous occuper de vulgaires problèmes de compatibilité. La secondes raison est que nous voulons être maitres de ce qui se passe dans Caliban. Je m’explique. Sur certains algo « pipo » comme le moteur de synthèse vocale MbRola, oui et reouioui, on utilise l’existant car c’est très bien fait et n’est pas véritablement essentiel a Caliban (il n’a pas besoin de parler pour s’exprimer, il peut le faire via l’écran). C’est donc un gadget fort agréable mais un gadget quand même. En revanche, en ce qui concerne la vision, c’est sa fenêtre sur le monde qui est absolument essentiel pour les interractions qu’il peut avoir avec l’extérieur et donc vital pour son évolution. Ainsi, sur ce point, il est clair pour nous que nous devons maitriser de A à Z les processus exploités afin de pouvoir les ajuster si nécessaire.
Je serais trés curieux de savoir quelles transformations tu apportes à l'image pour l'analyse (style la détection des arrêtes). Nous utilisons des routines qui nous sont propres avec par exemple augmentation et/ou diminution de contraste et/ou luminosité, décomposition des images en matrices RGB avec augmentation et/ou diminution de certaines valeurs (R, G,
, translation sous forme de matrice numérique compressée des moyennes de différentes zone du champs de vision…etc. bref, le panel de routine est vaste et c’est la matrice heuristique qui décide desquels utiliser et quand en fonction de son expérience (succés ou pas de tel process dans tels condition -> le succés étant une décharge de « satisfaction » dans son Ca lorsque qu’une cible est acquise et poursuivie).
Ya pas longtemps je miroitais un client réduit, tu sais ces pc souvent utilisés dans les parcs à serveur genre dans les magasins ce serait génial pour ton caliban non? Vu que les calculs sont délocalisés sur le serveur (trés chouette au passage) l'ATX fait un peu gros pour une si petite tête avec tout ses slots vides enfin peut être en auras tu besoin pour rajouter des ports série/parallèle pour commander les moteurs je ne sais pas... Effectivement, ce serait sans doute une solution interressante avec un cout faible mais nous nous contentons de travailler sur de simple PC standard. D’un autre coté, je ne connais pas bien le Hardware (ca c’est le boulot de mon pote Jpeg) car je m’occupe essentiellement du software. Donc je ne suis pas une référence a ce niveau et je dis peut être des conneries. Quoiqu’il en soit, nous utilisons des PC de récup tunnés a mort par Jpeg
Pour les commandes externes, nous passons par un multiplexeur USB sur lequel sont branché des cartes SSC32 via des cables de connexion USB-RS232. c’est une méthode simple a mettre en œuvre et « pas-si-cher-que-ca »
...(j'imagine que tu as débuté avec une ATX parce que c'était ce que tu avais sous la main) Hé non ! Cette fois ci c’est raté ! Non, en fait le projet Caliban (anciennement HAL-9000) a débuté sur une machine bien différente… Tout a commencé il y a fort longtemps via une calculatrice HP-48Gx puis 49G avant de passer directement sur des PC. Bref, on a suivit notre bonhomme de chemin sans forcément se poser trop de question niveau hardware. Disons qu'aoujourd'hui, caliban doit en être a son dixième support machine...
