6 réponses à ce sujet

[arcane]

bonjour a tous


bon deja pardon si je n est pas posté au bon endroit mais je savait pas ou le mettre


voila je voudrai discuter sur le comment vous construisez vos robots? je m explique voila je remarque que beaucoup de robot existant sont souvent construit sur le meme schema c est a dire que leur constructeur crée une bonne grosse carte avec un puissant processeur et un programme bien pensé...

je trouve que cette methode manque de charme et donne pas mal de contrainte je veut dire par la que ca demande une forte puissance de calcul et de memoire enfaite j ai l impression qu on passe a coter d un truc ne serait il pas mieux et peut etre plus simple pour la programation de soulager en quelque sorte le processeur central (pic etc...) de donner une certaine liberté de choix de mouvement au corp du robot?

en mettant des petit "cerveau" pour chaque parti du corp? j y connai rien en programation et je ne sait pas du tout comment vous vous y prennez mais ne serait il pas possible de faire des petit sous programme pour tel ou tel parti du corp?

en analogie avec le deplacement de la blatte des chercheur on realiser que le deplacement de la blatte ne demander casiment pas d effort de sont cerveau en gros il ordonne le deplacement des pattes mais c est tout apres pour les obstacles et le type de terrain ce sont en gros les pattes qui reagissent... ne serait il pas possible de faire un systeme similaire avec des robots?

regarder aussi chez l homme notre corp possede des mouvement non controler par notre cerveau ce sont des mouvement reflexe qui s anime suivant differente situation avec un tel systeme cela pourai donner une sorte de reflexe au robot non?

regarder aussi comment c est organiser le cerveau au fil de notre evolution d apres ce que j ai compris nous possedon 3 type de cerveau qui on chacun le role 1er: le cerveau reptilien il s occupe des fonction de base manger boir dormir en gros 2 eme: le cerveau ( j ai honte me rappel plus son nom lol) mais c est celui qu on a en commun avec tot les autre mamifere et ensuite le 3 eme le celebre neo cortex qui gere les emotion etc...

la nature a cree des systeme multiple pourquoi ne pas s en inspirer?


ps: desoler encore pour ce poste tres long et pardon encore si tout ce que j ai dit existe deja mais j attend vos avis sur la question et comment vous crée les cerveau de vos robot

[Aquanum]

L'idée est intéressante. Pour ma part (faible expérience pour l'instant) je n'ai travaillé que sur la centralisation par une carte mère.
Mais je compte maintenant partir plus vers une notion de "modules" indépendants pour mes prochains robots. Le tout fonctionnant sur un système de bus de données (I2C, CAN). Donc ça rejoint ton idée
En gros j'ai dans l'idée que chaque action, fonctionnalité est indépendante et fonctionne via un µC ou carte un peu plus puissante selon la fonction souhaitée.

Exemple:
- carte moteurs : je reprends ton idée qui est très intéressante. Envoyer une simple direction/vitesse à atteindre depuis la carte mère pourrait être judicieux. La carte gère alors d'elle même le déplacement. Le traitement ne se fait plus sur la carte mère mais de façon déportée. Cette petite carte peut alors dialoguer via le bus avec les cartes capteurs pour adapter le déplacement en fonction de ce que le robot perçoit.
- carte odométrie (mécanique, optique) : selon un mixe des deux la carte peut renvoyer une notion de vitesse et de chemin parcouru à tout autre carte le demandant, le traitement est également déporté.
- carte capteurs de distance (ultrasons, sharps, ...) : selon l'emplacement des capteurs, cette carte peut renvoyer une distance avec les obstacles proches, voir même s'occuper de générer des cartes du terrain d'elles mêmes (à voir si les cartes sont déportables)
- carte centrale inertielle : cette carte permet alors de calculer la position, vitesse, accélération, etc. et de la même façon que la carte odométrique calculer d'elle même le chemin parcouru. Après la carte mère peut faire une relation entre l'odométrie et les données de la centrale inertielle pour effectuer un correctif pour gagner en précision.
- carte alim (avec capteur de courant, consommation) : permet de gérer l'alimentation de façon autonome. Exemple, une carte n'est pas sollicitée, elle s'éteint d'elle même. Si la carte d'alim voit passer une trame sur le bus qui demande une récupération d'info sur la dite carte, la carte d'alim peut se charger de la rallumer pour qu'elle transmette l'information. Et au bout de X minutes, la carte pourra à nouveau s'éteindre (ne marche que pour les cartes non indispensables)
- carte de secours : j'y pensais justement hier soir, si la carte mère tombe en rade ou plante bah le robot se retrouve complètement bloqué. Il pourrait être intéressant de faire une petite carte qui se charge de faire un reset électronique de la carte mère, et si ça ne marche pas la carte de secours peut reprendre la main, mais de façon bridée. Par exemple tous les modules inutiles ou non indispensables sont désactivés, et la carte peut exécuter un certain nombre de commandes préprogrammées pour par exemple faire revenir le robot à un endroit donné pour être réparé ou autre.

J'aime beaucoup cette approche déportée, qui finalement donne plus d'importance au corps du robot.

Après à voir si l'intérêt est réel, et s'il y a un gain concret en terme de performances, conso d'énergie etc. Est-ce qu'une carte bien puissance ne vaut pas mieux que N moyennes ? La est la question. Mais je pense que tout se base sur les arguments de consommation et de fiabilité du robot.

[Jan]

Salut Arcane,

Je pense qu'il faut abandonner le programme dans le programme, si le programme principal lache tout lache...
Il faudrait un programme par membre ou fonction et un programme de supervision mais qui indique juste l'etat mais ne donne pas d'ordre de fonctionnement. Imaginez même un module débuggeur indépendant qui pourrait aller fouiner dans les membres divers regarder si tout va bien et recharger son programme si il trouve des anomalies. Une sorte de module "défense immunitaire" !
En fait les modules auraient des acces bien définis et correspondrait et agiraient les uns avec les autres en fonction de la définition initiale.
On pourrait même dans ce cas faire un module qui aurait la possibilité de changer les acces entre les modules, une sorte d'évolution ? Il faudrait avoir prévu ca matériellement au départ.
Je crois que Mark Tilden, inventeur des Beam, avait fait un tel robot où des problèmes n'empechaient pas la bonne marche de l'engin.

C'est vrai qu'on s'approche d'un organisme vivant ou un membre paralysé ou un même un des cinq sens manquant n'empeche en rien la remise en question de la vie ou de l'identité.

[arcane]

Salut Arcane,

Je pense qu'il faut abandonner le programme dans le programme, si le programme principal lache tout lache...
Il faudrait un programme par membre ou fonction et un programme de supervision mais qui indique juste l'etat mais ne donne pas d'ordre de fonctionnement. Imaginez même un module débuggeur indépendant qui pourrait aller fouiner dans les membres divers regarder si tout va bien et recharger son programme si il trouve des anomalies. Une sorte de module "défense immunitaire" !
En fait les modules auraient des acces bien définis et correspondrait et agiraient les uns avec les autres en fonction de la définition initiale.
On pourrait même dans ce cas faire un module qui aurait la possibilité de changer les acces entre les modules, une sorte d'évolution ? Il faudrait avoir prévu ca matériellement au départ.
Je crois que Mark Tilden, inventeur des Beam, avait fait un tel robot où des problèmes n'empechaient pas la bonne marche de l'engin.

C'est vrai qu'on s'approche d'un organisme vivant ou un membre paralysé ou un même un des cinq sens manquant n'empeche en rien la remise en question de la vie ou de l'identité.

bonjour a tous


content de voir que plusieur personne ont deja reflechi sur le sujet.oui bernard il me semble aussi que c est une des particularité des beam on a beau leur arracher une patte ils arrivent encore a avancer lol pour ceu qui est du^programme dans le programe disont que j y connait rien en programation helas mais c etait juste une idee a explorer.

merci a caliban pour tes lien c est tres interressant un de tes membre a une idee qui rejoint la mienne apres pour se qui est des inconveniant effectivement la demande en energie peu etre plus grande mais le systeme a de grande chance de rester stable par rapport a une seul carte central.

je n est pas votre niveau mais si je l avait j essayerai de construire un robot qui aurait sa structure fait en plusieur module pas forcement un robot humanoide d ailleur car le but est de simplifier et de rendre plus naturel les mouvements d un robot,comme ca on pourait reellement voir si l idee est viable.


voila en tout cas merci a tous d avoir repondu

[Electron]

Arcane ta peut-etre pas la connaissance mais t'est un petit génie

Et là juste une remarque :

la nature a cree des systeme multiple pourquoi ne pas s en inspirer?

C'est fou comme la nature a devancé la technique humaine^^ Là ce sont les systèmes à processeurs multicores.

[Leon]

Bonjour.

A mon avis, ton sujet peut se décomposer en plusieurs niveaux :

1) Pour un amateur qui veut réaliser un robot, qu'est-ce qui est le plus facile? Avoir un robot où tout est décentralisé, avec des dizaines de micro-contrôleurs à programmer et débugger? Ou alors un système central qui prend toutes les décisions? Pour moi, c'est la simplicité, donc 2° choix. Je précise bien pour un projet amateur. Rien que pour la partie débuggage, c'est à mon avis un gros argument.

2) On peut très bien décomposer la programmation d'un processeur central en plusieurs modules (programmes, tâches, thread) qui représentent chacun une des différentes fonctions que Arcane a déjà développé (réflexes, vision, émotions, etc)... Une partie du programme peut planter sans faire planter le reste. Pour ce qui est de la sécurisation de programmes dans un processeur centralisé, il existe pas mal de solutions, mais pas toujours simples à mettre en oeuvre: watchdog logiciel, watchdog matériel. La présence de microcontrôleurs bi-cores est en très grande partie là pour la sécurisation mutuelle de 2 processeurs côte à côte (je te surveille, tu me surveilles).

3) Si on veut vraiment faire un système avec des processeurs répartis, alors il faut voir que l'industrie a déjà bien étudié le sujet (automobile, aviation, automates industriels). Tout dépend du type d'interactions, mais ça peut devenir complexe... Il faut des outils de débuggage particuliers, ou alors les re-créer soi-même. Si on veut partir sur cette voie, il faut à mon avis bien réfléchir à la séparation des fonctions. Avoir des interactions les plus simples possibles, et les plus claires possibles entre les modules. Surtout si l'objectif final est la robustesse de ton système par rapport à une grosse défaillance, l'étude des défaillances et des impacts, ça peut prendre la tête rapidement. Crois-moi, c'est une partie de mon boulot (mon vrai boulot, celui qui me donne des sous). C'est intéressant, mais pas simple.

Leon.