Projet E=m6 conception électronique

[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 plus 3) et d'éviter des obstacles fixes et un obstacle mobile (localisé par une balise). Il doit se commander seul.

J'ai déjà posté une conversation à ce sujet dans la section technologies (http://forums.futura-sciences.com/te...obot-e-m6.html) mais comme j'en arrive au développement proprement électronique du robot je crée un sujet dans cette section du forum.

Un petit point rapide:
-Nous pensons utiliser des moteurs à courants continus pour le déplacement. Ils seront commandés par un micro-contrôleur par l'intermédiaire d'un pont en H mosfet.
-Pour la localisation, on utiliserait des balises: il y en aurait 3 fixes (possibilité de les relier par un fil) et 1 sur le robot adverse. Les 2 balises sur les robots calculeraient leurs positions grâce aux balises fixes et celle sur le robot adverse la transmet via ondes radio à notre robot.

Nous aurions donc besoin d'aide pour la conception des balises.
Apparemment on ne peut pas utiliser des ondes radios car elles sont trop rapides et on ne pourrait pas mesurer de temps de décalage entre l'émission et la réception, mais si on utilise des ondes ultra son ne vont elles pas être très perturbées? Cependant si on peut quand même arriver à retrouver notre signal à l'aide d'un traitement approprié ça me semble être une bonne solution.
On m'a parlé d'un multiplexage temporel (en utilisant un câble pour les synchroniser) pour différencié les balises plutôt que d'une différentiation en fréquence. Qu'en pensez vous?

Cordialement.
-----

[invitef86a6203]

ci joint fichier balise infra rouge complet fichier Proteus et en format gif , implante pcb schéma
avec le code pic émission pic16f84 et la partie interrupt 16f876 réception du robot le TSOP de la balise est connecté sur le rb0 pour mesurer le burst de la balise reçue.

[invitefa6261c0]

Je te remercie pour ton dossier mais je ne suis pas sûr du principe de ces balises.
Est-ce que c'est le même que celle du site dont tu a joins l'adresse dans le dossier?
Par-ce que leur conception diffère un peu.
Cependant en utilisant des balises IR qui émettent dans toutes les directions et en faisant tourner le récepteur IR du robot sur un mât on peut à coup sûr faire de la triangulation. Et si, comme il est dis sur ce site, il n'y a en fait pas trop de problème de brouillage, ça me parait une très bonne solution.

[mat64]

si tu utilises de US, il y a un risque de brouillage en effet : c'est le cas ou l'adversaire utilise lui aussi des US, pour se localiser comme toi ou délibérément pour brouiller un système "ennemi".

Pour contrer ça :

- prévoir que les US émis ne soient pas une simple impulsion mais un petit message numérique avec CRC, de sorte que le destinataire du message soit sur de sa provenance

- prévoir éventuellement 2 fréquences
- soit 2 systèmes de balise, et on se mets d'accord avec l'adversaire avant le match, voir si c'est possible
- soit un système automatique qui saute sur une autre fréq en cas de brouillage, mais c'est plus compliqué

[A voir en vidéo sur Futura]

[invitef86a6203]

Je te remercie pour ton dossier mais je ne suis pas sûr du principe de ces balises.
Est-ce que c'est le même que celle du site dont tu a joins l'adresse dans le dossier?
Par-ce que leur conception diffère un peu.
Cependant en utilisant des balises IR qui émettent dans toutes les directions et en faisant tourner le récepteur IR du robot sur un mât on peut à coup sûr faire de la triangulation. Et si, comme il est dis sur ce site, il n'y a en fait pas trop de problème de brouillage, ça me parait une très bonne solution.

http://fribotte.free.fr/bdtech/Balis...s_theorie.html
Il n'y avait pas les images dans le zip...

le principe est le même, il est en infra rouge c'est tout.
pour le sonore je n'aurais pas trop confiance.
Les formules sont valables, pareil.
une tourelle sur un servo est plus fiable que de faire tourner le robot qui va déraper à coup sur.
D'ailleurs le problème numéro un est la différence entre les 2 moteurs pour aller droit , si on propulse avec 2 moteurs.

Reste à savoir s'il est autorisé de brouiller l'adversaire avec une fausse balise embarquée ou l'emploi de miroir pour brouiller par réflexion si l'on doit avoir une balise embarquée une balise fixe.

[invitefa6261c0]

si tu utilises de US, il y a un risque de brouillage en effet : c'est le cas ou l'adversaire utilise lui aussi des US, pour se localiser comme toi ou délibérément pour brouiller un système "ennemi".

Pour contrer ça :

- prévoir que les US émis ne soient pas une simple impulsion mais un petit message numérique avec CRC, de sorte que le destinataire du message soit sur de sa provenance

- prévoir éventuellement 2 fréquences
- soit 2 systèmes de balise, et on se mets d'accord avec l'adversaire avant le match, voir si c'est possible
- soit un système automatique qui saute sur une autre fréq en cas de brouillage, mais c'est plus compliqué

D'après ce que j'ai pu lire, les balises infrarouges ne sont pas trop brouillées par l'éclairage ambiant. Pour ce qui est des balises de l'adversaire, je pense que l'on peut coder le signal envoyé sur un petit nombre de bit ce qui va identifier de manière unique notre balise. Ainsi plus de problème d'interférence.

http://fribotte.free.fr/bdtech/Balis...s_theorie.html
Il n'y avait pas les images dans le zip...

le principe est le même, il est en infra rouge c'est tout.
pour le sonore je n'aurais pas trop confiance.
Les formules sont valables, pareil.
une tourelle sur un servo est plus fiable que de faire tourner le robot qui va déraper à coup sur.
D'ailleurs le problème numéro un est la différence entre les 2 moteurs pour aller droit , si on propulse avec 2 moteurs.

Je pense qu'on va utiliser un mât avec un moteur pas à pas pour faire tourner le récepteur IR ca nous permettra d'avoir la fréquence exacte et la position du capteur à tout instant si on doit en avoir besoin.

Reste à savoir s'il est autorisé de brouiller l'adversaire avec une fausse balise embarquée ou l'emploi de miroir pour brouiller par réflexion si l'on doit avoir une balise embarquée une balise fixe.

Non je ne pense pas qu'il soit autoriser de brouiller délibérément les balises de l'adversaire.

On pense également à mettre sur le mât tournant un émetteur récepteur ultra son pour avoir une cartographie du terrain autour du robot. Qu'en pensez vous?
Et comment arriver à traiter le signal pour arriver à déduire les formes des objets ?

[inviteb3bd5e58]

bonjour, j'ai quelques questions avant de te répondre ...

1 les impératif de tes balises sont elles spécifier? si oui où?
2 après faire des signaux différant pour chaque balise n'est ce pas envisageable?

[invitefa6261c0]

Je te joins un extrait des règles du concours.


Heu si pour les signaux différents mais c'est plus ou moins ce que je fais si je code mon signal non?

[inviteb3bd5e58]

oui le codage permet de différencier les signaux. leur provenance par exemple.
une balise par définition emet un petit signal qui dit je suis ici pour la base de triangulation. il suffit de pensée trois signaux différents et de trianguler dessus les calcul sont compliquer à mon gout pour pas grands choses.

je pense que pour la coup E=M6 avant de savoir si on fait des balises faut décider de la stratégie.
comment le robot définit où il est sur le terrain?

le capteur infra rouge à une sensibilité propre et avec l'éclairage ambiant variant va faloir le traiter fortement pour enlever les perturbations.
pour la détection d'obstacle mobile je voyais des célules de détection de présence ... ceux qui on des faiceau ciblé et qui regarde si on en coupe plusieurs sont facilement accécible pour l'info et le traitement c'est ton programme qui va définir comment réagie le robot.

bon c'est les grande ligne que je donne point de vu réflexion et idée après pour un problème spécifique avec un schéma on pourra plus aider je pense...

[invitefa6261c0]

oui le codage permet de différencier les signaux. leur provenance par exemple.
une balise par définition emet un petit signal qui dit je suis ici pour la base de triangulation. il suffit de pensée trois signaux différents et de trianguler dessus les calcul sont compliquer à mon gout pour pas grands choses.

Honnêtement pas tant que ça, avec le système en question on peut avoir les 3 angles que forment les balises et le robot et après on en déduit facilement la position et de manière assez précise.

je pense que pour la coup E=M6 avant de savoir si on fait des balises faut décider de la stratégie.
comment le robot définit où il est sur le terrain?

le capteur infra rouge à une sensibilité propre et avec l'éclairage ambiant variant va faloir le traiter fortement pour enlever les perturbations.
pour la détection d'obstacle mobile je voyais des célules de détection de présence ... ceux qui on des faiceau ciblé et qui regarde si on en coupe plusieurs sont facilement accécible pour l'info et le traitement c'est ton programme qui va définir comment réagie le robot.

Effectivement les capteurs sont fonction de la stratégie adoptée et je pense que les balises sont indispensable si on veut avoir un robot qui voit plus loin que le bout de son nez et pouvoir prévoir les 3 ou 4 prochains coups (cf le topic dont j'ai posté le lien plus haut et dans lequel on y réfléchi).
Pour le robot adverse, on utilisera je pense une balise pour avoir une idée de sa position et également les capteurs ultra-son qui vont cartographier le terrain. Il nous faut des capteurs qui fassent un peu tout si on ne veut pas en avoir 50 et le couplage US+balise me parait pas mal.

Pour ce qui est du schéma nous sommes en train de le chercher justement

[invitefa6261c0]

Bonjour,

désolé pour ce temps sans nouvelles mais j'avais d'autre choses à faire en parallèle.
Pour l'alimentation de mes moteurs, je joins le schéma du pont en H avec les optocoupleurs 4N35 pour isoler le PIC du pont.
Dites moi ce que vous pensez de mon schéma.

[invite29971eb1]

Ça ne marchera pas.....

Commençons par l'étage MOSFET, nous verrons l'étage opto plus tard.

La résistance de Gate d'un MOSFET est quasi-infinie, on peut négliger le courant qui circule dedans, donc, sur tes grilles tu auras 0 ou 24V par rapport à la masse.

Dans les "Absolute Maximum Ratings" de tes deux réfs de transistors, il est indiqué un Vgs max de 20V.....conclusion, attends-toi à les voir mourir par dizaines.

De plus, un MOSFET n'est pas un NPN, on ne met pas de résistance en série sur la gate, mais une résistance de quelques kilos ou dizaines de kilos reliée à la masse pour décharger la capa parasite de la Gate.

Maintenant l'étage opto....si tu branches ta led en direct sur le pic, rien ne limite le courant dans la led. Tu vas cramer la led, et le PIC. Ajoute une résistance.

Donc, on reprend calmement, et on recommence

[invitefa6261c0]

Ok pour le +24V ce ne sera peut être pas nécessaire, on pourra prendre du 12V et ok pour la résistance en série avec les diodes.

De plus, un MOSFET n'est pas un NPN, on ne met pas de résistance en série sur la gate, mais une résistance de quelques kilos ou dizaines de kilos reliée à la masse pour décharger la capa parasite de la Gate.

Heu je ne comprends pas... j'en mets une ou j'en mets pas? Et comment je commande mon MOSFET alors?

[invitefa6261c0]

Bonjour,

Nous avons bien avancé dans la conception de notre robot:
-Nous avons fait une carte d'alim stabilisée qui peut délivrer du 5/12 ou24 V
-Nous avons fait notre carte de puissance pour l'alimentation des moteurs et tout ca marche très bien.

Cependant, nous sommes allé à la coupe et nous avons remarqué que beaucoup de candidats utilisent des interfaces MIDI commandées par un PC embarqué.
Nous avons donc pensé à utiliser cette technologie nous même et d'embarqué un ePC sur notre robot (budget restreint oblige...). Nous avons contacté une entreprise (interface-Z) qui fait ce genre d'interface PC-actionneurs en MIDI mais ils nous on répondu qu'ils n'avaient aucun matériel qui puisse gérer la réception de donnée d'une roue codeuse (élément indispensable pour l'asservissement du robot...)

Que pensez vous de cette technologie? (temps de réponse?)
Connaissez vous des sites où je pourrais me procurer ce genre d'interface?

Cordialement

[inviteede7e2b6]

MIDI ? quelle drôle d'idée, ils ne seraient pas en train de vous enfumer les mecs ?

MIDI est la norme pour les instrument de musique , d'où mon hypothèse qu'on vous a joué du pipo.

en robotique , un bus I²C me semble bien plus cohérent.

quand à la programmation par roues codeuses , c'était ultra-moderne au siècle dernier... depuis on a inventé les PCs et les bus de communication.

[invite29971eb1]

MIDI ? quelle drôle d'idée, ils ne seraient pas en train de vous enfumer les mecs ?

MIDI est la norme pour les instrument de musique , d'où mon hypothèse qu'on vous a joué du pipo.

en robotique , un bus I²C me semble bien plus cohérent.

Pas mieux, le plus répandu ça doit être l'I²C effectivement....les plus pêchus vont utiliser du CAN

On trouve aussi un peu de liaison série en RS-485.

Je me demande aussi si certains n'ont pas "hackés" le protocole des servomoteurs AX-12

[invitefa6261c0]

MIDI ? quelle drôle d'idée, ils ne seraient pas en train de vous enfumer les mecs ?

MIDI est la norme pour les instrument de musique , d'où mon hypothèse qu'on vous a joué du pipo.

Ben écoute c'est l'interface proposée par cette entreprise...

quand à la programmation par roues codeuses , c'était ultra-moderne au siècle dernier... depuis on a inventé les PCs et les bus de communication.

Heu ok je veux bien mais c'est à dire?
Comment je gère l'asservissement de mon robot avec tout ça?

[invite29971eb1]

Ben écoute c'est l'interface proposée par cette entreprise...

Par l'entreprise certes, mais en aucun cas par une équipe de la coupe. Depuis 7 ans de coupe de France et de Belgique, je n'ai jamais vu une interface Midi dans un robot...

Heu ok je veux bien mais c'est à dire?
Comment je gère l'asservissement de mon robot avec tout ça?

C'est ça de pas utiliser les bons termes. Ce sont des codeurs incrémentaux que tu vas utiliser. Les roues codeuses sont des éléments de réglage manuels, pas des capteurs.

[inviteb3bd5e58]

pour ton idée de ePC pourquoi pas mais pour la roue codeuse non je ne connais pas d'interface qui la face actuellement.

[invite29971eb1]

A mon humble avis, il est tout à fait utopique de vouloir confier l'asservissement-moteur au PC. Il vaudrait mieux confier ça à un microcontrôleur dédié, le PC s'occupant de la planification de trajectoire et de "l'intelligence" du robot que beaucoup appelleront stratégie.

Il existe aussi des circuits spécialisés tels que l'HCTL-2020 qui gèrent eux-même le décodage du capteur, mais il faut ensuite récupérer les infos sur un bus parallèle, donc le microcontrôleur s'impose encore.

[invitefa6261c0]

http://www.lextronic.fr/P2219-platin...alizer-wl.html

Vous en pensez quoi?

Et pour les capteurs sur le moteur ok mais si la roue patine... il faudrait pas un truc pour prendre en compte la trajectoire réelle du robot?

[invite29971eb1]

http://www.lextronic.fr/P2219-platin...alizer-wl.html

Vous en pensez quoi?

J'ai pas testé, mais ça peut être une solution.

Et pour les capteurs sur le moteur ok mais si la roue patine... il faudrait pas un truc pour prendre en compte la trajectoire réelle du robot?

Et là, tu découvres le plus gros problème de tous les participants

Certains mettent les capteurs sur des roues non-motrices, d'autres lavent les roues entre chaque match pour éviter de perdre de l'adhérence etc.... en gros une solution par équipe

[invitefa6261c0]

Salut à tous,

Je vous informe que nous avons bien acheté la carte Serializer et qu'elle est très pratique. Cependant, pour alimenter cette carte, il nous faudrait une carte d'alimentation stabilisée avec en entrée 12 ou 24V et en sortie 6 et 10 V et pouvant supporter 2 A.
Quelqu'un aurait un site à me conseiller pour nous aider à la réaliser?