39 réponses à ce sujet

[Inounx]

Bonjour à tous,

comme certains on pu voir dans le post de ma présentation, je suis en train de réaliser avec Aquanum un petit robot d'intérieur : ROBERT. Nous avons commencé ce projet il y a quelques mois dans le but de faire un robot capable de se déplacer en environnement connu et inconnu principalement. Ce sera l'occasion pour nous de tester différentes techniques de localisation, de cartographie ou encore pour d'autres fonctionnalités plus tard, des techniques de vision par exemple. Pour plus de détails je vous laisse aller voir sur le blog d'Aquanum : Yoann Sculo (Catégorie Robert) ou encore sur mon blog qui est plus récent : Inounx Projects. Ce post est l'occasion de vous présenter un peu les avancées du projet mais aussi de discuter et de recevoir des conseils

Nous en sommes pour l'instant à travailler sur l'asservissement, mais avant de pouvoir réellement se pencher dessus il nous faut déterminer une "structure" (si l'on peut dire) électronique qui gérera les fonctions bas niveau du robot (relevés capteurs, asservissement).

Principaux objectifs :
Se déplacer en environnement connu, ou inconnu.
Cartographier l'environnement au fur et à mesure des déplacements
Eviter les obstacles
Pouvoir effectuer un trajet demandé d'un point donné à un autre.


Coté matériel nous avons :
- Un chassis circulaire alu (commandé chez Easy Robotics)
- Des moteurs Lynxmotion GHM-03 (7.2V, 291 rpm)
- Les encodeur Lynxmotion qui vont avec
- 3 capteurs Ultrason
- Une carte driver moteur (double pont en H, basé sur un L298)
- Une arduino qui s'occupera vraisemblablement de l'asservissement et des capteurs.
- Une carte "mère", qui est une Roboard RB-100 pour moi et une Foxboard G20 pour Aquanum.

C'est une description assez succinte pour le moment (Aquanum tu peux compléter si tu t'en sens hein ^^) on détaillera un peu plus au fur et à mesure (plus de détails sont disponibles sur nos blogs respectifs).

[Inounx]

Pour reprendre la discussion qui a commencé dans le post de ma présentation :

J'ai quelques idées pour la mise en oeuvre de l'asservissement de mon coté, yaurais quelques changement par rapport à l'idée de départ. Un pote ma donné l'idée d'utiliser le couple uC / FPGA et je pense que ça peut simplifier pas mal les choses pour certains traitements qui doivent être rapides, comme le décodage des signaux en quadrature, le comptage des impulsions, la mesure de leur durée etc on pourrai le faire très facilement. (et en plus faires d'autres choses à l'occaz). ça permettrait de décharger un peu le uC et de lui laisser gérer tout les capteurs en même temps. Je t'en reparlerais plus en détail, c'est ptetre pas le meilleur endroit que le sujet ou je me présente

C'est intéressant, votre histoire de Robert... Alors pourquoi ne pas ouvrir un sujet dédié?

Plusieurs remarques:
1) pour la mesure par plusieurs télémètres ultra-sons, il est apparemment possible d'émettre sur plusieurs sonars en même temps et de mesurer la réponse en retour de chaque capteur. Je ne pourrais malheureusement pas tester ça sur BOB3, car je suis limité par le PICBASIC qui ne sait pas faire ce genre de choses. Par contre, pour le robot suivant, ça serait à tester.

2) Pour le FPGA, est-ce que ça n'est pas trop "usine à gaz"? Est-ce que tu sais déjà programmer un FPGA?

Bref, si vous voulez en discuter plus longuement, je vous propose d'ouvrir un autre post.

Leon.

Ah bon ? il me semblait justement qu'il n'était pas possible d'émettre sur plusieurs en même temps pour des raisons de perturbations entre capteurs justement. Sauf peut être si on s'arrange pour travailler sur des fréquences sonores différentes. Enfin si tu as plus d'info je suis preneur.


Quand je dit FPGA, c'est cette famille de composant, ici on a en stock des CPLD Xilynx donc on fera avec ça si on valide la faisabilité et la comodité . Après Usine à gaz, d'un coté oui, d'un coté non. Comme un CPLD ou FPGA ce n'est ni plus ni moins qu'un réseau logique qu'on peut programmer comme on veut et ce sur une puce minuscule (1cm* 1cm a peu près pour ceux que j'ai). L'avantage ici c'est que tout le bloc décodage comptage peut etre facilement programmé à l'intérieur et modifiable à souhait. Il suffit de se fixer l'interface avec le uC. Cela peut aussi permettre de coder des fonctions de décodage "hardware" pour des capteurs ou autre je n'y ai pas encore trop réfléchi. Je sais tout a fait programmer ces bestioles en vhdl oui, j'ai fait ça quand j'étais à l'IUT et maintenant à l'IUP : j'ai pas forcément une maîtrise extrême de la chose mais comme tu l'as si bien dit, on est aussi la pour apprendre

Apparemment, si tu envoies les pulses EXACTEMENT en même temps, les capteurs ne se perturbent pas. Ils inhibent en effet la réception lors de l'émission de leur propre pulse. Après, pour la réception, les capteurs sont suffisamment directifs pour ne pas recevoir le pulse du voisin. J'essaye de retrouver des infos, et je compte bien tester ça également.

Leon.

Perso j'y crois pas trop au système d'émettre les US en même temps :/
D'abord parce que vu le % de tolérance sur les composant +-20% pour un condo par exemple il risque d'y avoir des décalages entre les émissions de chaque émetteur, sans compter les multiples réfractions possibles qui sont déphasées (en temps donc) à la réception.

Le mieux comme je l'ai conseillé dans un autre sujet, ce serait de moduler l'émission d'un US avec une basse fréquence genre 1 Khz pour le premier émetteur, 5 khz pour le second, 10 pour le troisième et 15 Khz pour le 4ème.
Avec un filtre passe-bande sélectif et basse-fréquence après la réception sur chaque capteur US.

Electron, je rappelle que nous ne faisons qu'utiliser des modules télémètres à ultra-sons tout fait du commerce, de marque "Devantech". Donc impossible, dans ces conditions, de bricoler une quelconque modulation. Seule solution : réaliser un module de A à Z.

Personnellement, je pense que ça fonctionne. Je ferais l'essai en temps et en heure, et je vous dirais bien évidemment si ça fonctionne ou non. Pourquoi je pense qua ça fonctionne? D'abord, parce que la génération du pulse est réalisée en software, donc quand on dit que c'est émis exactement en même temps, c'est vraiment très précis: delta inférieur à la microseconde. Ensuite, pour les réflexions multiples, il faut que l'angle de réception soit précis (à +/-30°), ce qui limite sacrément le risque. J'ai du mal à me représenter un schéma géométrique de rebond multiple qui arriverai AVANT le rebond principal d'un capteur, et dans un cône de 30°. Mais bon, je suis preneur de toute démonstration géométrique que ça peut exister.

Pour ce qui est d'une modulation basse fréquence, je vois mal comment interpréter le truc: En software? En hardware? Si tu reçois 2 signaux en même temps, mais avec des amplitudes et des modulations différentes, ça nécessite quand même du traitement du signal (DSP?) pour déterminer l'instant précis de début de réception d'un des 2 signaux. Si tu as des idées (software ou hardware) pour réaliser ça de manière simple et précise, je suis preneur. Un filtre hard sera difficile à mettre en oeuvre, à mon avis, car l'instant de détection "ça y est, j'ai reçu le signal 5kHz" va peut-être dépendre de l'amplitude du signal reçu. Une période de 5kHz fait quand même 6cm de longueur d'onde. On a besoin d'une précision bien meilleure que 6cm.

Leon.

Ok OK comme tu veux

Sinon pour ce qui est de la modulation BF, c'est juste un oscillateur qui va direct sur l'entrée modulation d'un oscillateur US
La modulation BF est générée juste pour une durée de temps de ms, ce qui envoie donc une onde US modulée en BF pendant ce temps-là quoi^^

Les deux oscillateurs (BF et US) peuvent se faire juste avec deux portes "nand" par oscillateur.
Puisque le circuit intégré à portes "nand" tel que le CD4011 comporte quatre portes "nand", tu as ainsi tes deux oscillateurs avec un seul circuit intégré "nand".

Quand aux capteurs US ce sont des US modulés qu'ils reçoivent et non de la BF donc la longueur d'onde reçue est trés petite (US) et non 6 cm^^

Mais bon j'ai donné une idée après faites comme vous voulez, cela ne me regarde plus

Ca m'intéresse, mais tu n'as pas répondu à ma question: comment veux-tu faire pour démoduler, ou plutôt détecter le bon signal avec un bon timing, sans être dépendant de l'amplitude? Je n'y connais pas grand chose, mais ça ne me parait pas simple. Le plus gros problème me semble bien être côté réception, et non côté émission.

Leon.

[Leon]

Merci pour avoir ouvert ce sujet!

Bon, c'est vrai que ça ressemble à BOB3, cette histoire, mais c'est complètement normal, avec un cahier des charges identique... On arrive rapidement à un robot rond, avec des roues étroites, aux dimensions permettant d'embarquer un minimum d'électronique, etc...

Pour la RoBoard, c'est un joli cerveau. Tu vas pouvoir en faire des choses avec ça.

Tu parles en parallèle de FPGA et d'Arduino... Est-ce que tu veux mettre les 2 dans un même robot, en plus de la RoBoard?Ca fait un peu beaucoup, non?

Pour l'asservissement, comment comptes-tu asservir ton robot? Pourquoi as-tu choisi de faire l'asservissement dans une Arduino, alors que tu as de la puissance de calcul à revendre dans ta RoBoard?

Leon.

[Inounx]

Pour la RoBoard, c'est un joli cerveau. Tu vas pouvoir en faire des choses avec ça.

Tu parles en parallèle de FPGA et d'Arduino... Est-ce que tu veux mettre les 2 dans un même robot, en plus de la RoBoard?Ca fait un peu beaucoup, non?

C'est une idée oui. En fait vu comme ça, ça fait peut être beaucoup mais c'est le plus simple je pense. Je partais sur le principe de diviser en deux l'électronique : une partie "bas niveau" composée donc de l'arduino, avec un CPLD (surtout là pour traiter les signaux en quadrature), tout ça pour gérer les capteurs, la tension batterie, l'asservissement "bas niveau" et peut être d'autre chose. La deuxième partie serait donc l'électronique "haut niveau"(la Roboard, ou la Fox pour Aquanum) plus orientée prise de décision et "gros" calculs. Le lien entre les 2 niveaux pourrait être une liaison série entre arduino et Roboard en RS232 par exemple.

Pour l'asservissement, comment comptes-tu asservir ton robot? Pourquoi as-tu choisi de faire l'asservissement dans une Arduino, alors que tu as de la puissance de calcul à revendre dans ta RoBoard?

L'asservissement est en 3 niveaux : un asservissement type PID pour la vitesse, l'acceleration et la position, et une partie génération de consigne (évolution des consignes au cours du temps sur une période à temps fini), et pour finir une partie génération de trajectoire (position du robot au cours du temps). Le principe serait donc vu la position du robot et celle à atteindre de générer une trajectoire, avec cette trajectoire de générer les courbes de consignes et de transmettre aux asservissements. Facile à dire mais pas autant à coder

L'arduino s'occuperai des asservissements, et la Roboard de la génération de trajectoire et des consignes. Je ne fait pas tout directement avec la Roboard parce que je n'ai pas un linux temps réel installé dessus et je ne contrôle donc pas les temps. ça peut devenir assez génant surtout que l'asservissement doit être rafraichi un minimum de fois par seconde. Dernière raison je réservai surtout la Roboard pour les calculs comme le calcul de trajectoire, la génération de la carte, et plus dans le futur un peu de traitement d'image.

Pour l'instant ce ne sont que des idées il faut voir si j'arrive à coder tout l'asservissement ce qui ne sera pas une mince affaire à mon avis. On le dit tout le temps mais faire la correspondance entre la théorie que l'on voit en cours et la pratique c'est pas évident ^^.

[Aquanum]

Tiens, tiens, je connais ce projet =)
Bonne initiative de créer ce post. Ça pourra être intéressant de discuter de tout ça à plus grand comité.
Je trouve que ce projet est d'autant plus intéressant que l'on part peu à peu sur des solutions différentes, tout en gardant la même base =) La différence de résultat final sera d'autant plus chouette !

Que dire de plus, effectivement à part que je suis une grosse feignasse ! Depuis que je travaille, mon temps libre total se résume à 2h max par jour. Très difficile de caser un peu de robotique là dedans. Donc je me suis acheté une carte Sabertooth. Comme ça, hop asservissement finger in the noze. Enfin, disons qu'envoyer des caractères ASCII pour commandes mes moteurs me semble plus simple, et je gagne un max de temps. Donc je suis dans la même ligne de pensée que Léon. Le temps c'est précieux, maintenant que j'ai un salaire je peux me permettre ce genre de raccourci.

J'utilise une carte Fox G20, fraichement récupérée du SAV. L'inconvénient d'être béta-testeur de la carte c'est que l'on ne reçoit pas forcément de version stable et éprouvée...

Quoi qu'il en soit, je me retrouve à présent avec une jolie distribution Debian. Je compte me remettre rapidement à Robert afin d'avoir un robot fonctionnel pour Caprica 2010 dans moins de 2 semaines... raaaaah

Vu que la doc n'existe pas encore sur la Fox, je me suis codé une librairie pour gérer les entrées sorties, et j'ai pu commencer à bidouiller tout ça. Problème, l'interfaçage des capteurs nécessite l'écriture de drivers (besoin de fonctions uniquement atteignables dans le kernel linux). En gros, de façon standard, je ne bénéficie pas d'assez de précision pour récupérer la durée de la salve UR, ce qui est embêtant, car la durée correspond à la distance. En dessous de 10/20 cm, la distance passe à 0m tellement la précision est pourrie.

En conséquence, je vais passer sur la carte Arduino comme Marc, et m'interfaçer à la Fox avec le port série. J'enverrai une trame texte avec par exemple <distance1>#<distance2>#<distance3> pour les 3 capteurs. Ça ira plus vite.
J'ai réussi à m'installer le Wifi sur ma fox, du coup mon robot devrait très certainement bien avancer ce week-end ! Il a intérêt.
Donc des news au prochaine épisode

[Leon]

Donc je me suis acheté une carte Sabertooth. Comme ça, hop asservissement finger in the noze.

Je ne vois pas trop la rapport. La carte Sabertooth est juste une carte de commande de moteur (pont en H), qui ne gère pas du tout l'asservissement du bidule. En gros, ça t'évites juste de câbler un L298 ou équivalent, c'est tout. Tu devras bien gérer derrière un asservissement quel qu'il soit.

Leon.

[Aquanum]

Oui effectivement je rectifie. L'asservissement est toujours à faire en effet.
Je voulais dire en fait que c'est plus simple à prendre en main qu'un double pont en H. C'est numérique et assez simple à gérer du point de vue du branchement.
Par contre, tu as raison, ce n'est pas pour autant simple à gérer.
Et comme je ne m'y connais absolument pas en asservissement, j'y vais à base de grosse bidouille

Pour l'instant je cherche surtout à voir comment ne pas avoir un robot qui dévie de sa trajectoire. Etant donné que la carte ne peut pas envoyer simultanément les ordres de départ aux 2 moteurs (semblerait-il) il y a un très très léger décalage entre chaque moteur (les faisant à la suite). Ce qui fait après un certain nombre de marche avant / stop / marche arrière une sacrée déviation.
Pour l'instant j'alterne à chaque fois le premier moteur qui a l'information, mais c'est pas super propre je trouve :/

[Electron]

Peut-être que tu pourrais envoyer l'ordre vers le premier moteur seulement lors de l'envoi de l'ordre vers le deuxième moteur, ceci grâce à un montage en circuits logiques ?
Ainsi les deux moteurs recevraient un ordre en même temps.
Après il faut voir comment concevoir ce circuit logique^^

[Leon]

Pour l'instant je cherche surtout à voir comment ne pas avoir un robot qui dévie de sa trajectoire. Etant donné que la carte ne peut pas envoyer simultanément les ordres de départ aux 2 moteurs (semblerait-il) il y a un très très léger décalage entre chaque moteur (les faisant à la suite). Ce qui fait après un certain nombre de marche avant / stop / marche arrière une sacrée déviation.
Pour l'instant j'alterne à chaque fois le premier moteur qui a l'information, mais c'est pas super propre je trouve :/

J'ai rapidement parcouru la doc de ta carte Sabertooth. Il y a un mode "mixage" (mixed mode) qui devrait répondre à ton problème: tu envoies des consignes d'avancement longitudinal, et de virage (et non plus des consignes moteur droit et gauche). Ca devrait te garantir une meilleur synchronisation, à mon avis.

Après, l'émission de données en RS232 est normalement assez rapide, avec des trames aussi courtes. Est-ce que tu arrives vraiment à un décallage significatif entre les 2 moteurs? Est-ce que c'est la carte qui rajoute un délai entre l'interprétation des 2 commandes?

Personnsllement, sur BOB2, la communication était plutôt lente entre le PC et le micro-contrôleur qui réalisait (entre autre) l'interface moteur. J'avais été confronté au même problème que toi initialement, quand je mettais à jour la vitesse d'un moteur puis de l'autre. La solution a été de ne mettre à jour les PWM des 2 moteurs dans le microcontroleur que quand les 2 consignes moteur ont été reçues. J'ai naturellement repris ça sur BOB3, bien que la communication soit infiniment plus rapide. C'est plus propre. Et puis ça limite les risques de déplacement bizarre si une trame est perdue (rare, mais ça arrive).

Leon.

[Leon]

Des news sur votre projet à vous 2?

Visiblement, le "petit Robert" d'Aquanum roule, alors on aimerai en savoir plus!

Leon.

[Aquanum]

En effet, il y a eu quelques avancées de mon côté comme de celui de Marc semblerait-il.
Je compte faire une petite vidéo de mon Robert qui roule d'ici ce soir.
C'est une première version très basique que j'ai bricolé en vitesse pour avoir un robot qui se déplace à Caprica 2010.
Seul problème ... le sol n'était pas plat et le robot se bloquait tous les 10 cm...

[Inounx]

Salut Léon,

de mon coté mon Robert roule aussi, mais juste pour tester la communication uC <-> carte moteur avec une gestion des collisions ultra simple ( 1 seul capteur US) , il n'y a rien d'implémenté au niveau asservissement encore.
Hier j'ai réussi à trouver du temps dans la journée et j'ai pu me faire un petit arduino shield avec tout les connecteurs nécessaires (5 connecteurs pour capteur US dont 3 vont être utilisés de suite et 2 autres pour prévoir de l'améliorer, 1 connecteur pour la liaison série avec la roboard, 1 connecteur Two Wire Interface, des connecteurs pour repiquer le 5v de l'arduino, un connecteur pour la liaison avec la carte driver moteur et un petit pont diviseur de tension pour mesurer la tension batterie). C'est vraiment plus propre et plus pratique pour les branchements
J'ai aussi fait une petite carte d'alimentation en essayant de respecter les bons principes : condo de stockage en entrée et condo de découplage, yen a aussi sur les toutes les autres cartes. Je pense que l'alim est pas trop crade, faudra que je vérifie. Donc cette carte alim elle permet "juste" (c'est son boulot quoi) de recupérer la tension batterie, de la filtrer un minimum, et de la dispatcher sur toutes les cartes qui en ont besoin. J'y ai aussi mis un petit régulateur linéaire 7805 pour avoir du 5v si je veux brancher un petit truc en plus. Je ferais un petit post sur mon blog pour les montrer plus en détail, mais pour l'instant j'attends d'avoir tout mes connecteurs. Prochaine étape typon de la carte à FPGA. Le codage interne avance doucement, surtout qu'on code avec un ami un petit protocole de liaison perso, et que ces foutues bestioles de FPGA sont super sensibles à tout les parasites qui trainent, faut faire gaffe au boucles de masses et autre joyeusetés.

Coté mécanique j'ai commandé pour yoann et moi chez EasyRobotics un support pour les 3 capteurs US que j'attends de recevoir.
Voir les pièces jointes pour le schéma de principe pour le décodage des signaux en quadrature, et des images de la modélisation du support capteur.

Je crois que c'est tout pour l'instant

Image(s) jointe(s)

• 
• 
• 

[Aquanum]

Hop ! Voici une petite vidéo de démonstration.
Hélas, Robert n'aime pas du tout la moquette, le carrelage, et le sol de Caprica 2010 ...
Ça m'embête pas mal, je songe à me trouver des roues plus larges.

[galactus]

kool la bête ^^

pense a des capteur de contact si l'IR ou l'US déconne ,notamment sur la hauteur

[Electron]

Sympa ce petit proto^^
Il se cogne pas mal, ça vient des capteurs ou du programme basique ?
J'aime bien la propreté de ta chambre, la mienne c'est un foutoir complet :/ (des fils et circuits partout), je rève d'un garage^^
Pourquoi tu as choisi le principe de contrôler chaque partie du robot par une carte séparée ?

Bonne idée Galactus^^

[Aquanum]

Alors pour répondre aux questions. Le capteur central n'est pas fonctionnel pour l'instant. Donc le comportement est assez primitif. Obstacle à droite je touche à gauche et inversement.
J'avais fait ça rapidement pour avoir une demo pour Caprica 2010, mais ça n'est pas réellement au point.

En fait j'ai deux soucis avec mes capteurs. Le premier est qu'il existe une distance minimale en dessous de laquelle le capteur UR fait un peut n'importe quoi. Par conséquent, il faudrait que j'installe un capteur SHARP pour les petites distances (la lumière va plus vite que le son). Mon second problème est plus complexe. Je travaille sur la carte ardunio pour l'acquisition des capteurs et envoie toutes les informations en boucle à la Fox. Mon soucis est en fait que la carte Fox effectue une acquisition de ces données de façon trop rapide. Par conséquent, mon buffer se retrouve saturé de données en doublon. Il lit plus vite que les données n'arrivent. Par conséquent, il reçoit par exemple 30 fois un signal (distance en dessous de 5cm). L'information sera traitée et le robot va éviter l'obstacle, sauf qu'il va se mettre à traiter les 29 autres sans savoir qu'il s'agit de la même acquisition. Par conséquent, le robot se met à dupliquer chaque action et ça devient tout bonnement infernal. J'ai mis une grosse rustine en réduisant la vitesse d'acquisition, mais c'est du gros bricolage. Je songe, pour résoudre ce problème, à inverser le sens de communication en demandant plutôt à la Fox d'aller chercher l'information elle même sur la carte Arduino.

Sinon, effectivement, je pourrais également complètement rajouter des capteurs de contact, cela pourrait se substituer à d'éventuels bugs des capteurs.

Electron, huhu, tu verrais la tête de ma chambre ...
J'ai pris la vidéo sur le palier de ma mezzanine.
J'habite chez mes parents, le temps de trouver un appart sur Paris, et j'ai 2 appartements en un + toute mon électronique éparpillée de partout. J'ai même pas la place de marcher moi même, alors un robot huhu

Pour les cartes séparées c'est simple. La carte Fox ne gère pas les entrées analogiques, donc je suis tout simplement obligé. De plus, l'acquisition des capteurs de façon autonome n'est pas forcément une mauvaise chose, c'est quelque chose en moins à traiter sur la carte mère. L'acquisition de capteur est idéalement le genre de chose qui se fait bien de façon autonome, ta carte mère n'a alors plus qu'à jongler entre des cartes filles via un bus de données. Si tu arrives à gérer de façon poussée ces cartes, tu peux même éventuellement songer à optimiser la gestion d'énergie. Par exemple une carte qui allume les cartes filles au besoin à partir d'ordres de la carte mère.

[Electron]

Ha ok Aquanum
Pourquoi les capteurs serait-ils gérés ? pourquoi ne pas les connecter directement à des portes logiques et des transistors pour qu'ils actionnent eux-mêmes la direction et l'avance/recule du robot ?
Cela éviterait l'emploi de plusieurs cartes spécialisées et la gestion de communication entre les cartes et la carte mère.
En gros que ton robot réagisse comme un beam evolué au niveau des obstacles.
Sinon pour ton problème de données qui s'accumulent, il y a une solution, c'est que la carte qui envoie une donnée, envoie alors une info à la carte Fox pour lui dire qu'elle peut lire le buffer.
Cela devrait pouvoir se faire je ne connais pas les cartes que tu utilise, il y a le système des interruption qui existe entre les périphériques d'un pc et le pc lui-même afin que celui-ci sache que des données sont prêtes à être lues.

[Cacao]

Bonjour Inounx et Aquanum !

Je suis tout nouveau sur le forum et encore plus nouveau dans le monde de la robotique mais je trouve votre projet sacrément intéressant. Les évolutions sont infinies

J'aurais donc juste une question concernant l'asservissement... Si tu penses que ça va être compliqué, pourquoi ne pas coupler les deux roues sur un seul moteur et guider ton robot avec une troisième roue plus en avant montée sur un servo ? De cette manière, tu sera sûr que ton robot ira dans une seule direction non ? Celle de ta roue directrice.
Le réglage se fera alors simplement sur l'étalonnage de la position neutre du servo.

Et pour Electron, si la direction est gérée par un système autonome, ma question est, comment va t'il faire pour connaitre la direction que prends le robot ainsi que les choix qu'il aura pris tout seul, puisque le but final est bien de réaliser une cartographie (si j'ai bien tout lu =) ?

[Electron]

Cacao +10

Remarque, le circuit qui gère les capteurs peut très bien envoyer une valeur à la carte mère pour lui donner la direction et la distance de l'obstacle qu'il détecte.

[Inounx]

Bonjour Inounx et Aquanum !

Je suis tout nouveau sur le forum et encore plus nouveau dans le monde de la robotique mais je trouve votre projet sacrément intéressant. Les évolutions sont infinies

J'aurais donc juste une question concernant l'asservissement... Si tu penses que ça va être compliqué, pourquoi ne pas coupler les deux roues sur un seul moteur et guider ton robot avec une troisième roue plus en avant montée sur un servo ? De cette manière, tu sera sûr que ton robot ira dans une seule direction non ? Celle de ta roue directrice.
Le réglage se fera alors simplement sur l'étalonnage de la position neutre du servo.

Salut

désolé pour le retard de la réponse mais en ce moment j'ai tout mes partiels qui tombent et je suis à fond dans les révisions. (Départ en stage dans moins de deux semaines direction Gostai puis Wany Robotics).
Pour en revenir à Robert j'ai de mon coté quelques petites nouveautés, c'est pas grand chose mais c'est toujours sa. D'abord par rapport à ce que tu disais Cacao, en effet on pourrait ce dire que c'est plus simple d'avoir un seul moteur sur les deux roues et une roue directrice mais c'est pas si évident que ça. Première chose, on est jamais sur de rien ^^, donc rien ne garanti à priori que si ta roue directrice est tournée que le robot ira dans sa direction (surtout en fonction des surfaces). Tu me dira on a le même problème avec les robots à deux roues motrices, même s'ils sont peu être un peu moins sensibles. Un autre point est que tu perd en degrés de liberté : faire un demi-tour avec un robot type voiture c'est un chouilla moins évident, et ça prend plus de place qu'un robot qui peut tourner sur lui-même.

Et pour Electron, si la direction est gérée par un système autonome, ma question est, comment va t'il faire pour connaitre la direction que prends le robot ainsi que les choix qu'il aura pris tout seul, puisque le but final est bien de réaliser une cartographie (si j'ai bien tout lu =) ?

La direction ne sera pas totalement gérée par un système autonome, c'est plus un système qui contrôle réellement les actions et un autre qui donne les ordres. Dans notre cas on aura un asservissement par moteur et ce sera la Foxboard (ou Roboard) qui enverra les ordre permettant d'aller plus ou moins ou on veut.

Coté "nouveautés" j'ai reçu les supports pour capteur US, et j'en ai monté un sur Robert, c'est très classe et vraiment pratique ! (voir photos en pièces jointes) j'ai eu le temps de terminer mes petites cartes et de proprifier un peu le robot : les cartes sont vissées sur la plateforme, tout les fils sont torsadés et avec un connecteur adapté. Du coup j'ai codé un petit programme d'évitement d'obstacles avec les 3 capteurs qui génère une commande aux moteurs proportionnelle au 3 distances des capteurs. Je ne suis pas mécontent du résultat pour le coup ^^ simple mais efficace. Je mettrai une petite vidéo d'ici la fin de semaine si j'ai le temps.

Ci-joint quelques photos comme je disais : 2 photos de robert avec les 3 capteurs US sur leur support, une photo de la carte d'alim et une de l'arduino shield.