Aller au contenu


Photo
- - - - -

premier robot


  • Veuillez vous connecter pour répondre
8 réponses à ce sujet

#1 rick

rick

    Nouveau membre

  • Membres
  • 4 messages

Posté 23 août 2007 - 02:39

Salut,
je me présente donc :
Rick,
de formation initiale en électronique, je travaille depuis quelques années dans l'informatique ... (et oui, on ne peut pas tout réussir dans la vie ...)
ayant récemment décidé de me remettre 1 peu à l'électronique, j'ai acheté le bouquin "123 pic microcontroller" de Myke PREDKO (très bon à mon avis pour débuter ...) et me suis donc formé à la programmation des MCUs PIC.
... et là, pour mettre tout ça en application, je me lance dans la réalisation de mon premier projet à base de MCU (PIC16F684 notamment), à savoir un proto de plateforme robot d'exploration pouvant évoluer par la suite vers : tondeuse automatique, aspirateur auto, etc ...
J'ai imaginé un ensemble de MCU connectées entre elles et chacune chargée d'une tache spécifique. Pour l'instant, j'ai réalisé le soft du module de gestion des moteurs (servomoteurs, asservissement par roues codées et partie communication) ainsi que celui du module central de gestion des échanges entre les différents modules (là, j'attends encore quelques composants pour commencer les premiers montages de tests ...).
Ayant quelques doutes sur la partie gestion des communications, je souhaiterais donc, avant de poursuivre l'étude, l'avis d'amateurs éclairés sur les choix techniques que j'ai retenu.
Pour l'instant, il s'agit donc d'un module MCU central qui gère les communications pour tous les autres (5 ou 6 max). Il dispose pour cela d'une sortie dédiée à la génération d'un signal d'horloge de période 200us et qui synchronise les échanges avec les autres modules connectés. Les échanges sont constitués de messages sur 3 octets (1 pour cmd + 2 pour paramètre(s)). Cette horloge est donc commune à chacun des autres modules.
Puis, une PIN est réservée par module connecté et gére les entree/sortie des échanges (en mode synchrone). Le module central se connecte donc cycliquement à chacun des modules (esclaves) lui transmettant ainsi les messages en attente d'envoi (provenant des autres modules) et réceptionne ensuite les messages en provenance de ce module pour les stocker en attendant sa prochaine connexion avec chacun des modules destinataires ... Ensuite, il se déconnecte et passe au module suivant ...
Voilà, un peu compliqué non ?... ou pas ? C'est l'avis que j'attends. Ne suis-je pas en train de ré-inventer la poudre et n'existe-t'il pas déjà quelque chose qui implémenterait une structure approchante ou suis-je sur la bonne voie ?
Merci de vos conseils ...
A+

PS: je veux pas être trop long dans mon message mais, ce que j'attends en fait de la robotique dans un futur proche, c'est une nomalisation des composants et des fonctionalités de base que l'on retrouve toujours sous diverses formes dans les différents projets, ceci afin de pouvoir concentrer ensuite les efforts sur des problèmes plus complexes. A ce titre, le modèle de développement du système Linux pour ce qui est de l'informatique est à mon avis un modéle à suivre en la matière ... N'existe-il pas déjà des groupes de travail et de normalisation sur de tels sujets ?...

#2 JEF

JEF

    Membre chevronné

  • Membres
  • PipPipPipPip
  • 819 messages
  • Gender:Male
  • Location:St Cannat (13)

Posté 26 août 2007 - 06:29

bonjour

j'ai pas compris grand chose... je melange un peu....
euh,... c'est quoi c'est module? leur interet? ce qu'il envoi ? etc... ils doivent tous etre en half duplex a ce que j'ai compris...

tu pourrai pas faire 2 bus a la place?
- 1 contient les données µC vers module, composé de l'adresse des module, puis des donnés+parametre...
- 2 contient les données module vers µC, celui là, plus coriace, a chaque fois, il recoit le module precedent, et donne ses infos en plus. par exemple, le 1er module envoit ses information sur les 4er bit, le module d'apres recupere la donné serie, rajoute ses infos sur les 4 bits suivant, etc... et le dernier envoit au µC principal.

l'avantage c'est que sa fera moin de fil je pense, et puis, sur le PIC il y a RC7 je crois et RC6 specifique au transmission serie. je crois que je suis pas clair...

@++

Chaque jour est le premier du reste de ta vie.


#3 rick

rick

    Nouveau membre

  • Membres
  • 4 messages

Posté 27 août 2007 - 12:40

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 ...
@+

#4 Jan

Jan

    Webmaster

  • Membres
  • PipPipPipPipPip
  • 4 747 messages
  • Gender:Male
  • Location:Rhône Alpes

Posté 27 août 2007 - 08:04

Bonjour

Sympa comme idée...

Mais si pour des réalisation de robots on utilisait des modules déjà existant en informatique ?
Une carte mère, une alim, des disques durs, des cartes entrées/sorties...bref et c'est normalisé...
En gros se servir des standards normalisés de l'informatique pour la robotique.
Même composés de multiples composants, une carte informatique diverse devient elle même un composant normalisé.
C'est certain qu'il n'existe pas encore certaines cartes à interfacer avec une carte mère mais ce serait pas la mer à boire de les concevoir.

Je doute qu'une carte avec un pic devienne un standard, on te dira et pourquoi pas un avr...
Je pense que s'il existe une réalisation ultime c'est le pcbot.

Par contre l'approche module comme tu l'entends permettrait au robot, si concu de cette façon, qu'il puisse continuer à fonctionner un sens ou autre en moins sans être totalement paralysé. Qui a dit que je suis traumatisé par le multiplexage de ma voiture ? :lol:
Non mais en partant de ce principe, un oeil en moins chez un homme cela ne signifie pas la mort ou l'immobilisation définitive.

Sujet très intéressant pour moi :)

#5 _Yoda

_Yoda

    Habitué

  • Membres
  • PipPip
  • 152 messages
  • Gender:Male
  • Interests:http:/www.perso.iut-nimes.fr/fgiamarchi

Posté 27 août 2007 - 09:06

Le futur proche en robotique, c'est la carte FOX. :huh:
Mini PC sous Linux
Lien Carte FOX
Nous avons commencé à développer un peu.
Vraiment une petite carte
Port USB, nous y avons branché une caméra
Extension I2C, nous allons y branché les capteurs.

Mais le plus beau reste à venir, :)
elle est capable de recevoir le protocole de dialogue avec les environnements de programmation URBI et Microsoft Robotic Studio.
Ces deux EDI risquent de devenir incontournable dans l'avenir.

Il s'agit là d'un vrai tournant dans l'univers de la robotique ludique.
Enfin, nous ne serons plus obligé de développer une nouvelle carte tous les deux ans.
Et son cortège de fichiers spécifiques.

Seul hic, le prix :blink:
[url="http://www.robot-sumo.fr/"]Site Officiel du Tournoi de Robots Sumo
[/url]

#6 Jan

Jan

    Webmaster

  • Membres
  • PipPipPipPipPip
  • 4 747 messages
  • Gender:Male
  • Location:Rhône Alpes

Posté 27 août 2007 - 09:22

Pour info une réalisation avec une foxboard : http://www.robotbuilder.org

#7 rick

rick

    Nouveau membre

  • Membres
  • 4 messages

Posté 27 août 2007 - 09:43

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 :D , à l'image d'ailleurs de la poule qui continue à courir tête coupée ... :huh: )

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 !... B) 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 :unsure: ... mais bon ... )

#8 Jan

Jan

    Webmaster

  • Membres
  • PipPipPipPipPip
  • 4 747 messages
  • Gender:Male
  • Location:Rhône Alpes

Posté 27 août 2007 - 12:11

Les robots avec pc embarqués:

On en parle là:

http://robotpassion.free.fr/index.php?show...=crossign&st=15

et celui là : http://robotpassion.free.fr/index.php?showtopic=1928

Un site à voir http://www.whiteboxrobotics.com/

Maintenant tu peux te baser sur un vieux portable que tu auras trouvé sur ebay ou autre ca coutera bien moins cher...

C'est sur que dans la robotique actuelle on ne fait que réinventer la roue avant de placer notre propre innovation.

Je ne connais pas bien la Fox mais en quoi son utilisation est plus adaptée qu'une Epia ou autre du même genre ?

#9 _Yoda

_Yoda

    Habitué

  • Membres
  • PipPip
  • 152 messages
  • Gender:Male
  • Interests:http:/www.perso.iut-nimes.fr/fgiamarchi

Posté 28 août 2007 - 10:54

Les robots avec pc embarqués:


Je ne connais pas bien la Fox mais en quoi son utilisation est plus adaptée qu'une Epia ou autre du même genre ?


La taille bien sur et des périphériques plus ouverts ports entrée sortie, I2C
[url="http://www.robot-sumo.fr/"]Site Officiel du Tournoi de Robots Sumo
[/url]




0 utilisateur(s) li(sen)t ce sujet

0 members, 0 guests, 0 anonymous users