rick

Certes, pourquoi pas un module à base de avr, du moment qu'il s'interface avec les autres modules et qu'il comprend les messages qu'il reçoit et execute les tâches qui lui sont affectées ...

Suffit sans doute de le programmer de sorte que ...

Sinon, intéressante en effet, la carte FOX, mais bon effectivement le niveau de prix n'est plus le même ... (et puis bon, ma femme va encore me dire que je passe tout mon temps sur l'informatique !... lol )

Une telle carte pourrait d'ailleurs constituer le module "cerveau" de l'ensemble, si besoin est (selon la complexité finale et le niveau d'intelligence attendue).

Quoiqu'il en soit, je reste intéressé par l'idée de répartir "l'intelligence" dans les "organes" du robot. (j'aime aussi assez l'idée d'un robot de combat qui s'est fait éclater et dont la pince continue de ramper après son assaillant , à l'image d'ailleurs de la poule qui continue à courir tête coupée ... )

Cela me parait moins complexe dans la conception et la réalisation globale de l'ensemble et dans son perfectionnement ultérieur.

Enfin, à voir... Pour l'instant, je pense que vais m'attaquer aux modules plus complexes et voir si l'idée tient la route en restant sur des composants "simples" et en évaluer ainsi les limites ...

(Je viens de réécrire la partie comm selon la norme I2C - que, je l'admet, je ne connaissais pas jusqu'à présent- et, du coup, cela me libère une place folle en mémoire - <18% - et plus besoin d'une ligne de comm par module, un seul bus pour tous !... ce qui étend d'ailleurs considérablement le nombre de modules inter-connectables - bon, il est vrai que j'aurais plutôt choisi par exemple le 16F690, l'I2C était déjà dedans ... mais bon ... )

Merci Jef pour ta réponse.
Il est vrai que c'est un peu difficile de faire court ...
Un module c'est un MCU et son électronique associée (capteurs, moteurs, ...) dédié à une tache spécifique : par exemple, gestion du mouvement des roues.

Un autre module (ou des autres) sera affecté la gestion des capteurs d'environnement (par ex, des obstacles aléatoires rencontrés, d'une vision ultrasons, infra-rouge, etc ...), un autre pour la mémorisation de l'environnement déjà découvert (cartographie des lieux), un pour le positionnement géographique du robot dans cet environnement, pour le calcul des trajectoires et la détermination des commandes à envoyer au module de déplacement, un pour l'interaction avec l'utilisateur (gestion de la télécommande ou du panneau de config), etc ... un éventuellement pour la maintenance de l'ensemble (procédures de calibrage de ses caractéristiques techniques -exemple : calibrage des vitesses relatives des 2 roues -pour rouler droit- calibrage des valeurs de déplacement par rapport aux diamètres effectifs des roues et au nombre de code barre - calibrage du différentiel des vitesses de roues dans les trajectoires courbes, etc ... tu vois, ça peut aller assez loin dans la complexité ... ;o)
... bref, tout ce que l'on peut imaginer selon le degré de perfectionnement que l'on souhaite (ou qu'on a le courage) d'atteindre au final ...

Leur interet est de simplifier le problème global en le décomposant en sous-pb (à l'image de la programmation object en informatique) et, aussi, de permettre de s'adapter aux faibles ressources des MCU middle-range afin de rester sur des coûts de mise en oeuvre matérielles les plus faibles possibles (budget oblige) ... un module implémentera en fait tout ce qui pourra entrer dans la mem de son MCU en terme de code, de data et d'I/O ...

Ensuite, il faut bien faire communiquer tout ça ensemble : les modules entre eux pour trasmettre les infos captées, les ordres de réaction résultants, etc ...

En gros, tu vois où je veux en venir, à une certaine normalisation de tout ça qui permettrait ensuite de disposer de modules que l'on peut assembler entre eux au gré des besoins ... et de pas tout recommencer à zéro entre deux projets de réalisation ...

Pour ce qui est de la communication, pareil :
Il faut que cela reste simple ... mais un minimum évolutif. et que le nombre de pins utilisées, la taille du code nécessaire sur un MCU pour communiquer avec l'ensemble n'empêche pas ensuite d'implémenter la fonction de base qui lui est initialement affectée ... :-) (actuellement, la partie comm occupe + de 30% du code disponible dans mon module de gestion des roues ... peut être aussi que le choix d'un 16F684 n'est-il pas des plus optimum !... mais bon, je suis soudainement pris de fainéantise aigue lorsqu'il s'agit de passer à la manipulation du perchlo, alors ... bref, c'est l'objet de mes "recherches" actuelles de voir ce qu'il est possible de faire et jusqu'où on peut aller).

Voilà, en gros, les objectifs ...
@+