Projet Robot E=M6

[invitefa6261c0]

Bonjour,

Je suis en école d'ingénieur et dans le cadre de mes études je dois réaliser en 2 ans un robot pour participer au concours E=M6.

Cette année nous devons construire un robot capable de se déplacer, de se localiser grâce à des balises fixes (au moins 3) et d'éviter des obstacles fixes. Il doit se commander seul.

Le problème est qu'on ne sait pas par où commencer.
Alors il nous faudrait des informations sur les différents "centres de contrôle" que l'on peut utiliser (micro contrôleurs ou carrément un système informatique), la manière des les coder ( langage C ou autre), les capteurs à utiliser (ultrason, radars...) et comment acquérir leurs informations (les cartes et tout ça...) et enfin les actionneurs et surtout comment leurs transmettre les informations de la partie contrôle.
Bien évidemment vos avis sur les solutions technologiques et des conseils pour la marche à suivre seront grandement appréciés.

Je vous remercie d'avance.
-----

[Zozo_MP]

Bonjour

Si vous ne savez pas par ou commencer, plutôt que de parler de langage C et de la vis de Ø 4 : commencez par regarder dans les boutiques de robot pour Hobby tout ce qui ce fait.

Après vous sélectionnez les cinq fonctionnalités (pas 6) dont vous avez besoin et vous regardez les modules qui font ça en standard dans les boutiques.

Une fois que vous avez défini le niveau macroscopique vous pouvez commencer à regarder les modules de niveau inférieur et ainsi de suite jusqu'à la ligne de code en C ou autre langage bien mieux adapté aux robots.

Un fois que que vous avez le fonctionnement théoriques de chaque modules vous pouvez soit les acheter dans ces boutiques soit les faire vous mêmes.

Regardez les concours de Robot sous youtube vous verrez beaucoup de solutions originales.

Une variante d'un auteur célèbre "Au marin qui ne sait où il va ; aucun vent ne seras favorable" (aussi lire la devise de Fred).

Laisser le fer à souder au fond du tiroir et travaillez sur le concept d'abord.
Discutez en avec nous : car la plupart des projets d'étudiants que je vois révèle de grosses erreurs et ça on peut vous l'éviter.

Cordialement

[invitefa6261c0]

Bonjour,

Vous avez raison monsieur, et je n'aurait pas posé ces questions si nous n'avions pas déjà effectué une analyse fonctionnelle de notre futur robot, mais je dois reconnaitre que je ne l'ai pas mentionné.
Vous trouverez donc ci-joint un diagramme pieuvre et un fast du robot avec certaines solutions techniques.
Dans un premier temps, peut être pourrions nous nous occuper que de la fonctionnalité n°1 : le mouvement.
Que pensez vous de 2 moto réducteurs et de chenilles? Outre le coté design, cette solution me semble adaptée, facile à mettre et place et à coder plus tard.
Que doit on utiliser pour transmettre aux moteurs la futur information de la partie commande?

Cordialement.

[Zozo_MP]

Bonsoir

On en reparle demain la solution chenille ne me plait guère.

En attendant pouvez-vous poster ou nous donner l'adresse du réglement.

Cordialement

[A voir en vidéo sur Futura]

[invitefa6261c0]

Bonjour,

le règlement 2011 n'a pas encore été publié, cependant vous pourrez trouver ici le réglement 2010.
Après analyse des différents règlements des années précédentes, il apparait que les restriction s'appliquant au robot et certaines fonctionnalités de bases sont récurrentes:
le démarrage par une tirette, le fait que le robot doit se déplacer, éviter des obstacles, reconnaitre des objets, les déplacer, se repérer dans la table de jeux avec ou sans balises...
Concernant les chenilles, je suis ouvert à une autre proposition.

Cordialement.

[Zozo_MP]

Bonjour

Vous remarquerez que le robot doit tourner très très rapidement sur son axe central pour s'orienter. Donc deux roues opposées est la meilleure solution.

Deux points fixes sous forme de patin et deux roues qui peuvent tourner dans le même sens ou en sens opposé ou a des vitesses différentes et le tour est joué.

Si vous voulez vraiment épater tout le monde vous faites qu'avec deux roues et un gyro stabilisateur. Comme les petits véhicules à deux roues sur laquelle la personne se tient debout ou assis.

Vous remarquerez que tous les robots que l'on voit sous youtube ont tous le même défaut.
Lequel ?

Cordialement

[invitefa6261c0]

Ok pour les roues, mais à la place des patins ne pourrait on pas utiliser une roulette libre de pivoter?
En ce qui concerne le défaut récurrent des autres robots je dois dire qu'hormis le fait qu'ils sont un peu lent et dans l'ensemble tous construits sur un modèle cylindrique, je ne vois pas...

Cordialement.

[Zozo_MP]

Bonsoir

Les roulettes qui tournent sont une calamité pour la précision (rappellez vous les roue avant des caddies).
Il vaut mieux des patins légèrement bombés (portion de sphère) et vous prévoyez des roues au cas ou il y aurait une pente à monter. Vous ne montez la roue que si vraiment necessaire.
Si vous tenez à la roue il faut avoir le décentrement minimum et avoir une roue légèrement plus courte de 3mm pour ne s'appuyer dans tous les cas que sur trois points.

L'autre point pas grave celui-là c'est que c'est construit beaucoup trop costaud.
On n'y reviendra.

Le défaut c'est que le robot travail de façon séquentiel donc une grosse perte de temps entre les changement de direction et également dans les séquences d'empilage dont certaines pourraient être réalisées pendant que le robot roule.

On peut en reparler
Donc Comme vous n'avez que 90 secondes Chaque demi seconde compte.
Il faut avoir une time line parfaite ce qui n'est pas le cas de ce que je vois sous youtube. C'est sur ce point que vous battrez les autres ardon que vous serez nettement plus performant que les autres.

Cordialement

PS : il faut revoir totalement votres FAST qui est trop slow

[invitefa6261c0]

C'est noté pour les patins et pour le défaut de programmation, nous essayerons de ne pas reproduire ces lacunes.
Je joins un FAST plus détaillé sans les solutions techniques que nous pourrons trouver ensemble. Je n'ai par ailleur pas détaillé la partie préhention de l'objet qui n'est pas encore d'actualité.

Cordialement.

[Zozo_MP]

Bonjour

Personnellement je n'aime pas beaucoup le FAST en dehors de l'analyse de la valeur et encore). Notamment par qu'il n'est pas conçu pour décrire une chaine fonctionnelle mais des grandes fonctions. Le gros manque de cette méthode (elle n'est pas faite pour ça) et la quasi impossibilité de faire de la systémique avec.

Comme nous ne sommes pas dans un cadre scolaire, nous pourrions aménager celui-ci en quelque chose plus proche d'un grafcet voir faire un grafcet.

L'avantage d'un grafcet c'est qu'il permet du début à la fin du projet de bien connaître les séquences et toutes les boucles de rétroactions.
Toutefois travailler à un niveau plus macroscopique en grafcet est moins aisé.

Il faudrait plutôt travailler avec deux méthodes conjointement GEMMA et GRAFCET. Gemma pour le niveau macro et fonctionnalité et grafcet pour le niveau infra.
On rajouterais la méthode Pert pour les délais du projet.

Nota : dans votre dernier Fast il manque "manipuler les objets" qui peut inclure par exemple un retournement ou une mise sur la tranche, etc...

Si vous voulez réussir votre projet on peut vous indiquer quelque trucs et tours de main.

Cordialement

[invitefa6261c0]

Bonjour,

je vous avouerais, monsieur, que je n'ai jamais utiliser cet outil et que malgré que je me sois renseigné sur internet, je ne sais pas trop comment l’utiliser.
J’ai sélectionner les cases qui me semblaient pertinentes mais que mettre dans ces différentes cases ?

Cordialement

PS: je laisse le ficher en .DOC pour que vous puissiez le compléter si vous voulez, je mettrai les fléches sous paint plus tard.

[Zozo_MP]

Bonjour Widleau

Juste pour vous mettre à l'aise il n'est pas d'usage sur le forum de servir du "Monsieur", donc le pseudo même écourté suffit.

Je regarde votre document et revient vers vous.

Cordialement

[mat64]

j'ai réalisé (dans ma jeunesse ) un robot e=M6.
Môssieur Zozo_MP à raison, d'abord concevoir avant de regarder les détails techniques. Ceci dit je vais donner quelques éléments "bas niveau" que tu pourras intégrer (ou pas...) dans ta réflexion.

Et en premier lieu définir le budget, les ressources (accès à du matériel d'usinage, fabrication de cartes, etc) et les compétences. ça conditionne tous les choix. Si les 3 sont limités, ça va être dur

- pour la partie commande, de nos jours il ne faut plus se casser la tête avec des petits microcontrolleurs. je te conseille de mettre du PC embarqué (il y en a de la taille d'une carte de crédit). ça ne veut pas dire qu'il n'y aura pas des petits microcontrolleurs autour.

- nous avions ultilisé la méthode des 2 roues plus un patin. ça marche bien. nous avions fait usiner un patin en téflon. on peut aussi utiliser une bille à la place du patin (genre ça) mais je pense que ce n'est pas bien adapté à la surface de la table (c'est toujours en bois ?).

bon courage. 2 ans c'est très court (vous êtes combien ?), donc utilisez un max de sous ensembles touts prêts.

[Zozo_MP]

Bonjour Mat64

Merci pour ton apport

Cordialement

[invitefa6261c0]

Bonjour,

alors pour te répondre, nous sommes 7 dessus avec en plus un directeur scientifique et un pilote.
On peut avoir accès à pas mal de ressources humaines grâce à l'école: professeurs, chercheurs, intervenants ... de plus, ce n'est pas un projet de loisir donc les connaissances actuelles (analyse fonctionnelle, mécanique, électronique de base, et programmation en C) pourront et devront être étoffées.
Pour le budget, nous n'avons pas de partenaire pour l'instant mais nous avons beaucoup de pièces de récup des robots des années précédentes donc pour commencer ça ira ou alors on peut avoir un peu de sous pour compléter.
Nos grosses problématiques ne sont pas vraiment la mécanique (on saura trouver le bon moteur et le bon réducteur en fonction du couple recherché) ou l'analyse fonctionnelle (elle est faite même si l'outil GEMMA nous sera utile pour définir le comportement du futur robot lors de la programmation) mais plutôt le coté électronique: la carte de puissance qui va alimenter nos moteurs (doit on prendre un hacheur pour fonctionner avec un moteur à courant continu ?), comment transmettre les ordres de la partie commande à cette carte (comment faire varier le rapport cyclique alors...), comment traiter les informations (le centre de contrôle et la programmation ?), comment acquérir les données des capteurs et enfin quel capteurs utiliser (carrément un radar ou on utilise les balises pour trianguler la position ou encore simplement des capteur infrarouges ou ultra son avec un compte de tour sur chaque roue pour calculer la position du robot dans l'aire de jeu).
Voilà, ce sont toutes les questions sur lesquelles nous avons besoin d'aide sachant également que nous n'avons pas le budget pour acheter chacune de ces cartes toute faite.

Cordialement.

[mat64]

nous sommes 7 dessus avec en plus un directeur scientifique et un pilote.

je pense que c'est la bonne taille. moins nombreux on a pas le temps, plus nombreux on passe du temps à faire de l'organisation. Si les 7 sont motivés et travailleurs c'est impec.

On peut avoir accès à pas mal de ressources humaines grâce à l'école: professeurs, chercheurs, intervenants

oui ben comptez p'tet pas trop la dessus...si c'est comme nous à l'époque on avait eu a peu près zéro aide (et pourtant il y avait de la ressource.) Mais c'est normal, c'est à vous de faire le boulot, pas aux profs.

Nos grosses problématiques ne sont pas vraiment la mécanique ... mais plutôt le coté électronique: la carte de puissance ... comment transmettre les ordres ...comment traiter les informations... comment acquérir les données des capteurs et enfin quel capteurs utiliser ...Voilà, ce sont toutes les questions sur lesquelles nous avons besoin d'aide sachant également que nous n'avons pas le budget pour acheter chacune de ces cartes toute faite.

- déjà vous dites que vous pouvez récupérer des pièces des robots précédents. C'est bien, mais il faudrait surtout pouvoir récupérer l'expérience des équipes qui ont construit ces robots. Contactez les...même si ils sont partis de l'école et dans leur vie professionnelle, ce sont surement des passionnés qui seront ravis de vous aider. Même si ils ne vous font que quelques messages par mail, ce sera un retour d'expé. précieux. Et faites-le tout de suite, il faut avoir un max d'infos avant de commencer.

- donc si je comprends bien : pas de budget pour acheter des cartes toutes faites, et pas vraiment de compétences (du moins pour l'élec), la ça va coincer. Débrouillez-vous : trouvez du blé ou un électronicien chevronné.

- concernant tes diverses questions, je peux te donner des pistes, mais chaque choix se fait en fonction du budget et des compétences dispo (+ quelques critères techniques ). Par exemple, je ne vais pas te conseiller un PC embarqué sous linux (ce que je choisirais avec mes connaissances actuelles) si personne parmi vous ne connais linux.
Au niveau budget : l'école nous avait dit à l'époque "servez-vous chez farnell dans la limite de X €"). Donc pour nous c'était vite vu : il fallait faire nous même. Par exemple la carte commande moteur : microcontrolleur + ponts en H mosfet, le micro recevait des ordres de vitesse de l'unité centrale. Mais pour vous, une carte de commande d'axes toutes faite sera peut être un meilleur choix, tout dépends à quels fournisseurs vous avez accès...

Dites-moi, on est en février, et vous n'avez fait que l'analyse fonctionnelle ? Je ne dis pas ça pour être désagréable, mais pour que vous ne soyez pas déçu dans 2 ans si le robot n'est pas prêt pour le concours (ce qui fut notre cas à l'époque)

[mat64]

pour détecter la position du robot :
- nous avions pensé que compter le nombre de tours de roues du robot était une mauvaise idée, car en cas de dérapage (notamment si l'autre pousse) on est dans les choux.
- un système relatif (déduire sa position de la position précédente) est risqué car les erreurs s'additionnent
- un système absolu (déduire sa position par rapport aux balises) est risqué aussi en cas d'occultation, parasitage, etc, et est plus lent
- nous avions donc choisi...les 2 :

un système relatif qui donne de l'info en continu :
2 roulettes placées derrière les roues motrices, pressées au sol par un ressort, et qui entrainent un capteur récupéré dans une souris (roue à lumières)

un système absolu par triangulation, basé sur le temps de vol d'ultrasons, la synchro étant faite par radio (on peut peut être aussi synchroniser en filaire avant le match et se fier à des horloges précises, à étudier)

le système absolu recale périodiquement le système relatif. prévoir des modes de repli si l'un des deux système est en rade.

Je ne peux pas te dire si ce système est bon, on avait pas eu le temps à l'époque de finir la mise au point.

[mat64]

et si vos questions concernent principalement l'électronique, mieux vaut poster dans le forum électronique.

[invitefa6261c0]

Bonjour,

Merci pour vos pistes de réflexion.
Ce sujet ne concerne pas seulement l'électronique puisqu'il y a aussi la programmation du robot.
Cependant, du point de vue de nos connaissances, nous ne sommes pas des néophytes. Nous avons de très bonnes bases en programmation C, nous connaissons bien le système d'exploitation Linux mais, même si nous avons de bonnes connaissances en électronique (électronique de puissance, filtres, transistors etc...), nous n'avons jamais utilisé de micro contrôleurs.
Il nous faudrait donc une sorte de fil conducteur pour la conception de nos cartes.

[invitefa6261c0]

Bonjour,


après être rentré de vacances et avoir discuté avec mes collègues , nous nous sommes rendu compte que notre connaissance en matière de micro contrôleurs était un peu faible.
Nous avons bien sur cherché sur le net mais nous n'avons rien trouvé de satisfaisant quand à leur utilisation pratique: qu'y a t il en entrée en sortie (courant/tension? continue/sinusoïdal/signaux plus complexes?), comment l'alimente t on? etc...
Pourriez vous éclairer notre lanterne?

[mat64]

le cours de référence sur les microcontrolleurs PIC :
http://www.abcelectronique.com/bigonoff/

[invitefa6261c0]

Bonjour,

Je joins le grafcet du comportement du robot.
Il décrit la stratégie globale du robot sans entrer dans le détail des fonctions.
Nous travaillons également dure sur les solutions techniques pour satisfaire ces différentes fonctions et en particulier sur l'utilisation des microcontrôleurs qui reste, pour l'instant, un peu abstraite.


Note: L'action Acquisition des données prend en compte la position du robot, la position des obstacles ou objets et si on a pris un objet ou non.
Nous pensions également ajouter une tempo pour le calcul de l'itinéraire afin que le déplacement de notre robot ne soit pas saccadé.

[Zozo_MP]

Bonjour

Ok pour le début de grafcet.
je crois que pour de l'interactif votre bloc 1 est déjà trop séquentiel.

Vous devriez stocker le résultat (position de l'objet ou du concurrent dans une pile (variables)
vous devriez avoir une boucle permanente sur cette fonction qui valide ou invalide en permanence les objets dans la pile (variable de stockage) indiquant que les coordonnées polaires des "n" prochains objets sont toujours valides ou non.
N'oubliez pas que certains objets peuvent changer de position du fait soit de vos manoeuvres soit de celles de votre concurrent. Dans les règles on n'est pas censé éviter de bouger les fruits récoltables par le concurrent (au contraire même).

Donc dans votre stratégie il faut définir si vous privilégié, la vélocité de l'engin ou la réflexion pour prévoir tous les coups jusqu'à la fin des 90s.
Un engin performant n'a pas besoin de connaître plus que les trois prochains coups.
Egalement rien de vous interdit de faire des manipulations d'objets pendant le déplacement vers un autre objet.

Bref sans délaisser le Grafcet, essayez de faire un schéma plus simple plus visuel qui montre tout ce qui peut travailler en parallèle et tout ce qui est en boucle itérative au sein d'un bloc ou entre blocs.
Cela vous aideras à y voir plus clair : sur ce que vous appellerez plus tard stratégie et également sur les impasses de votre programme tel qu'il est envisagé.

J'ai remarqué dans les derniers concours que les méthodes de tris des objets n'étaient pas très élaborés. Les gens cherchent leurs objets au lieu de tout ramasser à la volée sans réfléchir et de trier les couleurs ou formes au sein du robot lui même et de rejeter sur l'arrière tout ce qui est objets concurrents (comme du crottin derrière un cheval).
Avec cette méthode vous pouvez définir une stratégie de déplacement ultra rapide permettant de balayer toute la surface de jeu en un temps record. Vous avez juste à éviter le concurrent. En plus cela foutra la grouille chez votre concurrent.

Bon ! j'arrête car c'est trop passionnant votre truc

Cordialement

PS : ne confondez pas tactique de jeu et stratégie.

[invitefa6261c0]

Bonjour,

je vous remercie pour vos conseils et un de mes camarade est actuellement en train de réfléchir au programme mère du robot qui intégrera la stratégie et nous tiendrons bien compte de votre avis.

Plus généralement, nous pensons utiliser les 3 balises pour la localisation du robot et 1 pour celle du robot adverse: le robot envoie un signal aux balises et celles-ci renvoient un signal aux fréquences W0, 2W0, 3W0 et 4W0, on traite le signal avec 4 filtres passes-bande très sélectifs et on mesure le temps d'aller retour que l'on divise par 2. Ainsi on a une mesure simple de la distance et l'erreur de mesure est divisée par 2. Pour la localisation du robot adverse, comme nous n'avons qu'une balise, nous pensions effectuer 4 mesures: 3 pour avoir une position et la 4em pour avoir une idée de la vitesse. Même si ce n'est pas très précis, cela nous permettra d'avoir une bonne idée de sa position.
Pour constituer la balise, nous pensions utiliser un émetteur alimenté par un condo que l'on charge avec une pile et qui se décharge dans l'émetteur grâce à un interrupteur commandé à l'arrivé du signal.

En ce qui concerne l'alimentation des moteurs, j'ai une question concernant les micro-contrôleurs:
Soit t le temps de bit, si on veux transmettre ces 3 bits: 111 est-ce que l'on va avoir un signal continu égal à 1 pendant 3t ou est-ce qu'on va avoir, comme c'est le cas pour la transmission éthernet, 3 fronts montants situés aux alentours de t/2, 3t/2 et 5t/2 ?
Si, comme je l'espère nous sommes dans le 1er cas, alors le micro contrôleur pourrait directement (ou via un petit ampli) commander un hacheur qui lui-même contrôlerait un moteur à courant continu. Et le problème de la carte d'alimentation des moteurs serait réglé.

Cordialement

[mat64]

Plus généralement, nous pensons utiliser les 3 balises pour la localisation du robot et 1 pour celle du robot adverse: le robot envoie un signal aux balises et celles-ci renvoient un signal aux fréquences W0, 2W0, 3W0 et 4W0...

je suppose que tu parles d'ultrasons (les ondes radios se déplacent tellement vite qu'il est difficile de mesurer les temps de parcours avec des moyens à votre portée.)

pour faire ce que tu dis (w0, 2w0...) il faut des transducteurs à large bande, ça existe peut être mais ce n'est pas très courant. Il il y a une autre solution : le multiplexage temporel. La première balise émet un message, puis la seconde, puis la troisième. Si le reglement n'a pas changé, elles peuvent être reliées par un câble, donc pas de souci pour les synchroniser. Le message US envoyé contient un code par balise, ce qui permet au robot de savoir d'ou il vient. Autre avantage (selon moi parceque je suis plus à l'aise en numérique qu'en analogique) : pas de filtres à mettre au point.
Ensuite pour la balise du robot adverse, je pense que le mieux est de mettre le même système : elle reçoit les messages des balise et détermine sa position. Cette position est envoyée à votre robot par radio (il y a des modules tout fait pour l'émission/réception de messages numériques pas radio...surtout n'essayer pas de développer quelquechose pour ça !)

Pour la localisation du robot adverse, comme nous n'avons qu'une balise, nous pensions effectuer 4 mesures: 3 pour avoir une position et la 4em pour avoir une idée de la vitesse.

je ne vois pas bien le principe...le mieux selon moi c'est ce que j'ai mis ci-dessus

Pour constituer la balise, nous pensions utiliser un émetteur alimenté par un condo que l'on charge avec une pile et qui se décharge dans l'émetteur grâce à un interrupteur commandé à l'arrivé du signal.

je ne comprends pas à quoi sert le condo ? c'est pour générer une impulsion d'une certaine largeur ? Si c'est ça, vous faites fausse route : il faut des microcontrolleurs dans les balises.

En ce qui concerne l'alimentation des moteurs, j'ai une question concernant les micro-contrôleurs:
Soit t le temps de bit, si on veux transmettre ces 3 bits: 111 est-ce que l'on va avoir un signal continu égal à 1 pendant 3t ou est-ce qu'on va avoir, comme c'est le cas pour la transmission éthernet, 3 fronts montants situés aux alentours de t/2, 3t/2 et 5t/2 ?
Si, comme je l'espère nous sommes dans le 1er cas, alors le micro contrôleur pourrait directement (ou via un petit ampli) commander un hacheur qui lui-même contrôlerait un moteur à courant continu. Et le problème de la carte d'alimentation des moteurs serait réglé.

avec un microcontrolleur, tu génères ce que tu veux. tu peux soit
- piloter une sortie avec des instructions du type "passe la broche à 5v" et "passe la broche à 0v", que tu combines avec des boucles, temporisations, etc.
- programmer un périphérique intégré au micro qui va se charger de piloter la broche. par exemple un bloc PWM (c'est en général ce qu'on fait pour piloter un moteur).

et oui je te confirme qu'il faut quelquechose entre le micro et le moteur : en général on appelle pas ça un ampli, mais finalement, c'est l'idée. Je te conseille :
- optocoupleur pour séparer l'alim puissance et l'alim microcontrolleur
- pont en H de MOSFETS de puissance pour commuter la puissance vers les moteurs

Pose des questions si tu ne comprends pas ce que je raconte

PS: tu aurais beaucoup plus de réponses dans la section électronique du forum

[invitefa6261c0]

Bonjour,

je viens de créer une conversation dans la section électronique du forum (http://forums.futura-sciences.com/el...ml#post2908594) vous pourrez y suivre l'avancement de l'électronique du projet.

J'ai quelques petites questions:

je suppose que tu parles d'ultrasons (les ondes radios se déplacent tellement vite qu'il est difficile de mesurer les temps de parcours avec des moyens à votre portée.)

Les ondes ultra son ne vont elles pas être très perturbées?

- programmer un périphérique intégré au micro qui va se charger de piloter la broche. par exemple un bloc PWM (c'est en général ce qu'on fait pour piloter un moteur).

C'est quoi un bloc PWM ?

et oui je te confirme qu'il faut quelquechose entre le micro et le moteur : en général on appelle pas ça un ampli, mais finalement, c'est l'idée. Je te conseille :
- optocoupleur pour séparer l'alim puissance et l'alim microcontrolleur

Ok l'optocoupleur peut isoler électriquement le circuit de commande et le circuit commandé. Mais pour quoi faire? Un bon vieux transistor ne fait pas l'affaire?

[invitefa6261c0]

Bonjour,

désolé pour ce long laps de temps sans post mais j'avais du travail.
Je vous informe que notre groupe projet a bien avancé. Nous avons construit un premier robot basique qui nous a permis de nous familiariser avec les premiers concepts de la robotique.
Il se compose de:
- 1 capteur SRF 05
- 2 moteurs CC
- 1 carte d'expérimentation avec un PIC 18F
- 1 carte d'alimentation stabilisée
- 1 pont en H

Le code est simple: le robot avance, quand il détecte un objet il recule en tournant d'1/8 de tour et repart.
(ci-joint des photos du dit robot)

Pour notre robot de coupe nous allons utiliser une carte différente: nous voudrions utiliser la carte serializer WL ( http://www.lextronic.fr/P2219-platin...alizer-wl.html) commandée par un mini Pc que nous embarquerons sur le robot.
Cette carte nous permettrait de gérer 5 capteur US, plusieurs capteurs IR ainsi que 2 moteurs et plusieurs servo-moteurs.
Elle nécessite pour être commandée un logiciel qui puisse communiquer en ASCI via un port série.

Quelqu'un a-t'il déjà utilisé cette carte ?
Y a-t'il un logiciel avec lequel je puisse programmer en C et qui puisse commander la carte ?

[Zozo_MP]

Bonjour

Cela commence à prendre tournure votre affaire !

Deux remarques :

Pour le langage C le mieux serait d'ouvrir un fil dans le forum software de Futura-Sciences, car vous aurez là bas des spécialistes pointus et sûrement des bouts de codes routines.

L'autre remarque concerne vos moteurs qui actuellement sont placés à l'horizontal (normal pour un premier proto). Par la suite et pour des raisons de minimisation de l'encombrement, il vaudrait mieux qu'ils soient à la verticale.

Quand vous passerez à la partie mécanique j'espère que vous viendrez nous en parler sur le forum Techno.

Cordialement

[invitefa6261c0]

Ok pour les moteurs.
On en tiendra compte lors de la conception du robot final.

Pour suivre la discution software: http://forums.futura-sciences.com/lo...ml#post3091428

[polo974]

Pour les moteurs, je les mettrais directement dans l'axe de chaque roue et comme sur les R4 pour les barres de torsion, je décalerais les axes des roues motrices (celle à droite en avant, celle à gauche en arrière) et hop un gros gain de place sur les engrenages coniques qui disparaissent.
Pour la ligne droite, rien de changé mais il faudra bien sûr tenir compte de cette géométrie pour les virages, mais c'est très gérable (et en plus, ça en fera causer plus d'un...).

PS: pour mémoire les suspensions des R4 étaient à barre de torsion transversale sur le train arrière et donc la roue d'un coté était quelques cm plus en avant que l'autre.