Elharion

Voilà pour la photo zoomé.

Le but c'est d'avoir une base pour tester le code maison :

-contrôle commande du moteur

-réglage du PID

-Premiers algo de navigation

-Vérification que tout fonctionne comme prévu

Le tout sans avoir à courir derrière le robot ^^

J'implémente au fur et à mesure afin d'avoir des résultats et de pas être noyé par la complexité.

Le montage avec cardan c'est juste pour le fun ^^ (et parce que les accouplements directs c'est pas bon pour les moteurs ^^)

Ca y est il roule !!! Enfin non mais j'ai fait tourner un moteur DC avec une lib faites maison

Etape suivante, supprimer les delay qui trainent à droite à gauche (vive le temps réel !) et réfléchir à mon motion controller ^^

Histoire que ca reste simple dans le main ^^

C'est un petit tour pour wallPi mais un grand pas pour moi

Bonjour bonjour,

Après avoir lu attentivement le topic d'Oliver17 et ayant moi même pour objectif de mettre en place le même type de com, je poste ici pour pas polluer son topic ( http://www.robot-maker.com/forum/topic/11890-gcom-communication-pi-arduino/?p=92084).

Je me suis documenté sur l'UART et j'ai des idées que je voudrais partager avant de me lancer dans le code ^^. Ca me permettra aussi de vérifier que j'ai bien compris le principe.

Grosso modo les liaisons UART ne sont pas réellement structurées (par opposition à l'i2c par exemple). La ligne est à 1 au repos, quand quelqu'un prends la parole il fait un silence et ensuite transmet un octet.

A l'autre bout de la ligne on va donc recevoir un octet qu'on va stocker dans un buffer que le programme va traiter dans un second temps. Le hic c'est qu'on ne sait pas ce que cet octet représente (ni même le type de variable). Dans le cas d'une info sur plusieurs octets on se sait même pas où est la fin de l'information.

Ceci dit, l'intérêt de l'UART c'est qu'on en fait ce qu'on veut ( ou presque, l'UART cuira pas ma pizza).

Du coup est il imaginable de structurer mes messages de la façon suivante :

Octet 1 : integer de 0 à 255 indiquant un type d'information :

A la façon d'une ENUM on a une table de correspondance dans le soft, par exemple :

001 : commande de déplacement

002 : information du sonar

003 : angle du servo tartampion

Octet 2 : Integer de 0 à 255 indiquant le nombre d'octets qui vont suivre...

Octet 3 à i : l'information en elle même.

Comme ça quand je lis le buffer, je sais ce que je lis. Qu'en pensez vous ?

Mes cours de montage de roulement sont plutôt loin, mais si je me souviens bien c'est normal que ton roulement se comporte un peu comme une rotule (en tout cas pour les roulements à bille).

C'est en montant 2 roulements (avec la charge entre les 2) que tu vas créer une liaison pivot.

Au fait qu'est ce que tu entend par énormément de jeu axial ? ^^

Nota : à 1,52€ les 10, tu peux te permettre des montages un peu plus complexe à base de 2 roulements, ca sera toujours moins cher. Tant que tu as pas trop de jeu radial c'est pas genant ^^

Bonjour à tous,

A cause de certains faits de vie, je n'ai pas eu le temps de poster sur le forum pendant un looong moment.

Néanmoins, j'ai eu le temps de profiter de la littérature très riche sur la robotique et me renseigner sur pas mal de choses (notamment sur l'EKF-SLAM).

En parallèle j'ai expérimenté la génération d'une carte depuis un servo fixe avec un capteur US. (les photos sont pas terrible mais ca donne une idée ^^)

La bonne nouvelle c'est que j'ai de nouveau du temps pour m'y plonger plus sérieusement. La prochaine étape c'est d'assembler mon premier robot mobile ^^

Une question me taraude, est-ce que je peux commander sereinement sur RobotShop ? Pas de droit de douane surprise à l'horizon ?

Alors il y en a plusieurs :

Côté hard :

- Le GPIO est fragile, CMOS 3,3V non tolérant au 5V

- Une seule sortie PWM

- Pas d'entrée analogique

- Une fois enlevée les ports du GPIO qui servent à la com I2C, SPI, RS232, il reste plus grand chose

Côté soft :

- J'ai peu d'expérience en C/C++

- Je connais très mal linux

- J'ai pas spécialement envie de me pencher sur python

Alors en soit, rien n'est insurmontable dans ce que je viens d'énoncer. Mais partir sur une arduino qui me sort 50 E/S dont 15 PWM + 16 entrées analogique, avec une bibliothèque super bien documenté en C/C++ ça me parait beaucoup plus simple pour débuter.

Économiquement, pour 30€ de shield sur raspberry je ne serais pas encore à la capacité de la méga en E/S et en prime j'aurais une usine à gaz.

Après, je sais que rapidement je vais être limité au niveau puissance de calcul. Mais à ce stade, j'aurais déjà un robot qui fonctionne pour des choses très basique.

Dis moi si je me trompe, mais en synthèse l'arduino est beaucoup plus performante sur du bas niveau (pilotage E/S) et la raspberry sur le code haut niveau (com internet, algorithmes complexes, etc...)

Hors avant de faire le code haut niveau, vaut mieux s'occuper du bas niveau ^^

Voici le diagramme Fast à l'heure actuelle :

Les fonctions en verts sont les solutions retenues quand il y a des choix multiples.

Les 2 fonctions en jaune, je les prends pas au sérieux et on verra plus tard ^^

Mon premier questionnement se situe sur la méthode de triangulation où je réfléchis encore à la solution adéquate.

La problématique est la suivante :

Je vais piloter mes moteurs ce qui va faire avancer le robot. En connaissant la vitesse et le temps écoulé, je peux en déduire une position théorique. Mais c'est une boucle ouverte. Et ayant en tête l'objectif de faire du mapping, je pensais créer un repère cartésien représentant la pièce dans laquelle le robot va évoluer. Sauf que pour compenser toutes les incertitudes, il faut que le robot puisse se recalibrer.

J'ai d'abord pensé à des lasers pour aller chercher la distance par rapport aux murs. Mais ça ne marchera pas (meuble, obstacle quelconque ou encore mur par droit qui fausseront la mesure). 

La solution qui me paraitrait judicieuse serait de placer 2 émetteurs dans la pièces à des points fixes. A partir de là, avec un récepteur sur le robot, je peux trianguler sa position. C'est loin d'être parfait mais ça devrait le faire. Par contre j'ai aucune idée de la difficulté à mettre ce genre de technos en place... Est-ce compliqué ?

Edit : Est-ce vraiment utile ? ^^

Bonjour à tous,

Voici la présentation de mon avant avant projet ^^

Je vais essayer ici d'exposer les raisons de la création de ce projet.

Pour ceux qui n'ont pas lu ma présentation, je suis ingénieur en mécanique et production depuis quelques années. Malheureusement mon métier ne me permet plus de faire de la conception et ça me manque. J'ai aussi envie de mettre en avant et pourquoi pas de transmettre les méthodes que j'emploierai. J'ai vu pas mal de TPE et de PPE ici, c'est l'occasion de fournir des documents en exemple

Je me débrouille plutôt bien en conception mécanique, j'ai des notions en C et C++ (très basique et un peu lointaine les notions) et je m'y connais en VBA. Niveau élec par contre je suis une bille (vous savez celui qui comate contre le radiateur au fond, et bah c'était moi en élec ^^).

Au niveau du matos dispo j'ai un crayon et du papier (INDISPENSABLE !) quelques LEGO, une raspberry pi et une imprimante 3D ^^

Bon ceci étant dis, voici mes objectifs :

1) M'amuser !

2) M'amuser !

3) M'éclater sur un projet de conception

4) Éventuellement transmettre un savoir (mais on verra, je préfère rester humble)

Une contrainte s'ajoute au projet, madame veut que le robot soit utile ^^ pourquoi pas par exemple avoir un balais swiffer. Je cite "quitte a avoir ta connerie pleine de fils qui se balade dans le salon autant qu'il fasse le ménage en même temps" c'était de l'humour mais le message est passé quand même =)

Voilà comment je vois le projet. Je veux faire un rover parce que soyons honnête c'est plus simple qu'un bipède ^^

Et je veux y aller par étapes histoire de pas me décourager en partant tout de suite sur un truc énorme, incroyablement complexe.

Idéalement je veux faire un rover avec 2 bras - 6 axes et de l'intelligence à revendre. Pourquoi pas un joueur d'échec d'ailleurs...

J'ai déjà définis les 3 première étapes :

Phase 1 :

L’objectif de la phase 1 est simple : concevoir et faire fonctionner une base roulante modulaire. A ce stade du projet, le rover sera capable de suivre une série de commande prédéfinie. Il n’aura aucune intelligence particulière. Va devant, demi-tour, recommence, arrête toi.

De plus, je souhaiterai avoir un semblant d’interface pour pouvoir piloter les fonctions basiques via le contrôle à distance de la raspberry Pi.

Nota : Cette première phase devra prendre en compte le balais pour nettoyer l’appartement.

Phase 2 :

L’objectif de la phase 2 est de mettre en place un système anti-collision basique qui permettra à notre rover de s’arrêter face à un obstacle.

A ce stade le rover ne devrait plus se retrouver bloqué par des obstacles.

Phase 3 :

L’objectif de la phase 3 est de développer un algorithme de mapping de l’appartement et une routine qui permettra de vérifier régulièrement l’état de l’appartement et de mettre à jour la carte.

Le second objectif est de développer une routine de nettoyage de l’appartement ou le rover nettoiera de lui même l’appart en suivant un algo lui permettant de ne rien louper.

Concernant les premières contraintes techniques, je souhaite faire un hybride entre de l'impression 3D et du Lego. Je trouve que les composants avancés des lego technic (vérin, amortisseur, pompe, jeux d'engrenages) sont carrément efficace et pour un coût impressionnant.

Et surtout la prochaine étape sera de faire un diagramme FAST en ne me limitant pas à ces 3 phases mais en y mettant littéralement tout ce qui me passe par la tête.

Voilà pour le projet. N'hésitez pas à me faire part de vos commentaires. Je suis totalement ouvert à la critique ^^

Dites moi surtout ce que vous pensez de la démarche ?

Bonjour à tous !

Je m'appelle Elharion, j'ai 26 ans et je suis ingénieur en mécanique et production. Je m'intéresse depuis quelque temps à des projets de robotiques.

Je suis tout doucement en train de réfléchir à un petit projet de robots et je viens me renseigner sur ce forum.

Voili voilou ^^