Mon idée se base sur plusieur projet à réunir en seul
http://www.pobot.org/Balises-et-camera.html

http://www-cs.engr.ccny.cuny.edu/~zhu/zOmniStereo01.pdf page7

http://le2i.cnrs.fr/IMG/publications/marhic2000.pdf

http://tel.archives-ouvertes.fr/docs/00/13/17/79/PDF/mallet-these.pdf

http://www.ensta-paristech.fr/~filliat/Courses/Polys/Filliat_RobotiqueMobile_ENSTAParisTech.pdf

http://robofoot.polymtl.ca/publications/ELE6904_smarleau.pdf

Je sais très prétentieux de vouloir comprendre des thèses mais adapter les idées des autres c'est ma spécialité.

Gyro49

Pourquoi prétentieux?
Après tout le but d'une thèse, c'est d'exposer les résultats d'un long travail de recherche Normalement une bonne thèse (je parle bien de la thèse en tant que document écrit) devrait permettre à un lecteur
ayant un minimum de background de comprendre ce qui a été fait
Maintenant, je reconnais que certains travaux scientifiques sont tellement abscons, et peu vulgarisés, que comprendre ce que raconte l'auteur quand on est pas l'un des 10 spécialistes mondiaux à qui il s'adresse, c'est parfois ambitieux

En tous cas c'est une approche intéréssante, que je ne connaissais pas. Avec OpenCV je connais l'approche simple de détection de "balises visuelles" dans une image, et en calculant la déformation géométrique due à l'inclinaison potentielle de l'objet, on calcule l'angle auquel on le voit, et en analysant sa taille perçue, on peut calculer sa distance. Du coup si on a une ou plusieurs balises sur le terrain, on peut calculer à quelle distance on est par rapport à ça.

Mais l'approche "kinect" pourrait être plus simple pour cartographier un terrain!

A ma connaissance, les seuls résultats intéressants avec des balises radio à courte portée utilisent le niveau de signal reçu, globalement le résultat ne semblait pas meilleur que le GPS.

Une autre hypothèse revenant à mesurer la vitesse de propa d'un signal radio (utilisé en aéronautique: DME) n'est pas applicable sur de si petites distances (3 10^8m/s).
Une triangulation non pas en temps de propa mais en vecteurs serait peut être plus performante.Mais alors il faut une espèce de gonio très sélective...
Un système multi-balises a été évalué avec succés avec des balises radio (ou IR pour donner le top départ) et US (la vitesse de propa n'étant plus que de 300m/s).
Sujet vaste et intéressant! tu pensais à autre chose?

Non, en effet, c'était mon idée. Ou des variantes. Justement l'ultrasonique, car avec la plus faible distance de propagation ça devient plus facile qu'avec des ondes électromagnétiques se déplaçant à C

Après sinon, oui, j'ai encore d'autres idées :
des balises IR, de forte puissance, émettant chacune un code différent. On peut reprendre les mêmes principes, mais sinon plutôt que de s'appuyer sur les délais de propagation utiliser le fait qu'on aura une réception d'autant plus importante qu'on est aligné avec la balise.


A part ça, je pense utiliser pour de plus petites surfaces un guidage inertiel, pour déduire la topologie du terrain. Si un robot possède un accéléromètre, il peut logiquement calculer en dérivant par rapport au temps le déplacement qu'il a effectué selon x,y, et z. Donc en arpentant une zone, il doit pouvoir dire "j'ai avancé de tant" selon chaque axe. Du coup il suffirait de parcourir la zone en la quadrillant... Reste le problème de la rectitude des trajectoires.
Il faut dire que pour ma part, j'ai envisagé ces solutions pour cartographier un plus petit espace, et contenant des obstacles. Mon idée était donc qu'avec un parcours répété plusieurs fois, en prenant des points de référence fixe, le robot pourrait finir par établir la position des obstacles en affinant sa mesure à chaque rencontre... l'idée était d'avoir un déplacement plus ou moins aléatoire, en notant la position des obstacles à chaque fois.


Sinon, pour une cartographie, voici une petite idée. On place un piquet à un endroit, et on y place le robot. Le robot ne serait pas mobile, mais un système fixe, doté d'un grand pied, d'une tourelle avec des servomoteurs permettant l'orientation d'un capteur de distance selon les deux directions (gauche-droite et haut-bas).
La tourelle serait sur une plateforme capable soit de connaitre son inclinaison par rapport à l'horizontale, ou alors de corriger cette inclinaison. Bref, on s'assure que la surface sur laquelle est la tourelle est plane. A partir de la, la tourelle scanne les alentours, avec un capteur de distance précis et assez fin, et note la position de chaque point mesuré. Avec un peu de calculs trigonométriques, on peut calculer la distance de chaque point. On peut ainsi connaitre la topologie du terrain car on obtient une carte 3D de celui ci... SI je prends le capteur ultrasonique maxbotix HRLV-EZ4, on a une précision de 1mm pour la détection de la distance d'un objet, pour une largeur de faisceau d'environ 60cm. Donc on pourrait en théorie calculer la position moyenne de points tous les 60cm pour une zone de 5m de rayon (ou un peu moins), c'est la portée du capteur.

Pour passer à la zone suivante, il suffirait de placer un second piquet, et de pointer la tourelle vers ce piquet. On aurait alors la position précise de ce piquet, et on déplace la tourelle à ce point. Du coup la tourelle peut prendre encore des mesures, et on sait ou se trouve la zone de mesure par rapport à la précédente.

A chaque fois la tourelle balaie la zone pour générer un nuage de points. Et en fin de compte, s'il s'agit d'automatiser, on peut imaginer de monter le tout sur un robot, qui se déplacerait de proche en proche, et le piquet servant de référence pour le second point pourrait être un second robot commandé par le premier (par exemple avec un canal radio pour les commandes, et une balise ultra-directionnelle que le gros robot chercherait à détecter pour savoir si le petit est bien à la bonne place, ou pour viser sa position précise!

Maintenant la question est de savoir dans quelle mesure un outil topographique classique ne serait pas intéressant à utiliser sur un robot mobile ^^

Bonsoir,

Excusez moi de rentrer dans votre conversation, mais je suis également sur la réflexion de la location d'un robot architecte d'intérieur comme celui-ci.

Mon hypothèse serait une localisation par la vue (OpenCV) est ce que vous ne pourriez pas l'appliquer également à votre projet en extérieur ?

Gyro49

Sinon ces solutions sont très intéressantes, en collant des balises à certains endroits on peut analyser un flux vidéo pour détecter la position précise des objets.
Dans les traitements optiques, une utilisation intéréssante serait un capteur type kinect, capable de donner la topologie d'une pièce...
Et il y a une piste également, c'est de faire un scanner 3D adapté. En utilisant un laser ligne, avec un servo pour faire un balayage, et une caméra, il est possible d'extraire un nuage de points, en utilisant certains logiciels.

Avec mon laser "ligne", j'obtiens largement plusieurs mètres de portée pour une belle ligne bien visible.

La méthode est assez simple et économique pour faire un scanner 3D (je ne l'ai pas testée personnellement toutefois):
http://www.instructables.com/id/Make-your-own-3d-scanner/
http://www.tinkernut.com/2010/02/03/how-to-make-a-3d-scanner/

Salut! Je constate que tu es parti sur le GPS, mais j'ai une petite idée simple :
Si les dimensions du terrain sont connues, ou qu'au moins on peut mesurer des distances de façon relativement fiable,
il me semble qu'une solution pour savoir ou se trouve le robot serait d'installer 3 balises radio non alignées(en triangle),
et un récepteur/émetteur sur le robot, et de calculer par triangulation sa position par rapport au signal reçu...

Cela permettrait d'avoir la position x,y du robot. Pour l'inclinaison en un point donné, si on prend un simple accéléromètre, placé
de façon à bien lire -1g quand le robot est à plat, sur l'axe Z. Lorsque le robot sera sur une pente, on aura une variation de
l'intensité de la force selon Z, et par trigonométrie, on peut calculer la pente (et savoir son sens avec X, si le robot monte, alors en s'arrêtant, il aura un X négatif, sinon si il est en descente, à l'arrêt il aura un X positif. (ou le contraire).

Du coup on connaîtrait la pente à chaque point, et en ayant un point de référence, on pourrait calculer l'altitude des points par approximation des dénivelées à des droites entre deux mesures...

Arduino peut aussi enregistrer facilement un fichier sur une carte mémoire SD.

Oui, mais il faut rajouter un composant coûteux, qui "mange" un certain nombre de GPIO, et dans ce cas un vrai arduino + 

le lecteur ont un coût supérieur à un raspi A+ (20€), sans compter la possibilité de regarder ou en est le test par le réseau, d'envoyer

les résultats par mail, etc...

 

J'imagine que s'il s'agit d'un mémoire de master pour une étude "one shot", ça ne change rien, mais si ça débouche sur une

thèse plus tard, ça vaut le coup d'envisager un système plus sophistiqué avec un raspi

Bonjour,

je me permets une petite remarque, mais il ne faut pas oublier le Raspberry Pi...

Avec un Raspi ça permet d'enregistrer les résultats dans des fichiers! (consultables

par le réseau). Avec la puissance de Unix on peut ainsi planifier les tests, leur durée,

compiler les données, générer un rapport, etc.

 

Mais bon, il est vrai qu'avec un Arduino + moniteur série, on peut également faire un script

qui récupère automatiquement les données par l'USB.

 

Coûteux genre 1€ ? ^^  http://www.ebay.fr/itm/Micro-SD-Storage-Board-Mciro-SD-TF-Card-Memory-Sh-IEld-Module-SPI-For-Arduino-IE-/281807990130?hash=item419d10ad72:g:J7gAAOSw9r1WAqxM

 

Un certain nombre de GPIO ? Genre 4 ^^: Les pin du spi : Miso, Mosi, Slave select, et SCK =) 

Pour le reste je suis d'accord ^^ Mais bon faut aussi voir combien de temps ça prend à mettre en place un système plus sophistiqué

Si on achète en chine, tout est moins cher ^^

En france c'est déja 10-15€ la breakout board.

Pour les GPIO, bah oui, 4 c'est pas mal à mon sens, mais bon j'ai pris l'habitude d'économiser les GPIO avec l'I2C, surtout que les GPIO restent dispos pour d'autres trucs alors qu'en SPI il faut à chaque fois ajouter un slave select pour chaque périhpérique!

Mais bon c'est vrai qu'avec Aliexpress et les sites chinois, c'est tellement pas cher qu'à la limite on prend un arduino mega et un lecteur SD pour 10€

 

Et le Raspberry Pi A+, n'a pas de port réseau, il faudrait donc ajouter un composant ...

Un dongle wifi USB a 5€, c'est négligeable ^^ Avec un Arduino, le seul truc pas cher c'est plus ou moins l'ESP8266!

 

 

Par contre je vous concède qu'étant un gros fan du Pi, je suis peut être un peu biaisé à vouloir en mettre partout ^^

Tu es fan du Pi, étrange, ici, je voyais plus les membres êtres fans de l'arduino.

Pour être franc, au début les deux m'ont paru envisageables, mais l'arduino a plus de fan ici, et je le découvre, la programmation me parait plus simple : je connais très bien le C/C++ et pas mal d'exemple sur le net...

Et comme toi, mais dans le sens opposé, en ce moment, se suis à fond dans l'arduino : j'apprends .

Apparament, la solution Raspberry Pi n'a pas été présenté aux intéressé, dommage.

Si tu regardes mon tuto sur le robot R.Cerda, tu verra que c'est basé sur du raspi.

Certes le Arduino est plus simple pour beaucoup de choses. En revanche, sur des aspects plus complexes, ou simplement lorsqu'il faut du multitâches, c'est bien plus compliqué sur un arduino. Si par exemple, tu dois lire un capteur qui prend du temps à répondre, et faire autre chose en même temps, sur un arduino, il faudra soit faire classiquement, et ajouter des interrupts, soit s'assurer d'avoir des librairies non bloquantes, sauvegarder le moment ou on a fait la requete, et analyser le timer pour voir si assez de temps s'est écoulé, etc.

Avec plein de traitements parallèles, ça devient vite chiant.

 

Avec le pi, tu lances un thread s'il le faut ou encore deux programmes en parallèle.

 

Et si les tâches deviennent lourdes c'est carrément plus simple sur un pi... par exemple faire de la cartographie en fonction du déplacement du robot, s'il faut stocker tous les points mesurés, on a de quoi sur le pi. Sur le Arduino la mémoire sature vite... Idem pour le réseau : des robots communiquants, c'est facile avec le pi : un dongle wifi par robot, et on utilise TCP/IP, qui est robuste, stable et standard, plutôt que de passer par tel ou tel module... (même s'il y a l'ESP8266 pour le arduino, et la ça change  bien la donne, même si ça reste bien plus compliqué que sur un raspi).

 

Si tu veux faire de la vidéo, avec du traitement d'image : la encore le pi est non seulement considérablement plus puissant, il peut aussi faire tourner opencv pour faire des choses impossibles sur le arduino (reco de formes, de visages, etc) et en plus pour moins cher qu'avec le Arduino et en qualité supérieure. Le module caméra du pi est a 25€, pour du 5mpixels, video full HD 30FPS, et il passe par le GPU du pi, donc ça mange à peine 2% de CPU de faire une capture full HD, alors que pour arduino, des modules vidéo adaptés, en 640*480 coutent souvent 50€ ou plus.

 

Donc bref, pour moi ça dépend, pour mes robots, je combine les deux. Le Arduino se charge des tâches de bas niveau comme piloter les moteurs en PWM, écouter le compte-tours de ceux ci, etc, et le Pi se charge des tâches de haut niveau comme la navigation, les communications, etc...

 

Mais attention hein, je ne dis pas qu'il faut laisser le Arduino au profit du Pi, chacun a ses avantages. Ces temps ci j'ai acheté des vingtaines de clones chinois de Arduinos Nanos, et j'en mets partout (gestion des lumières de la maison, systèmes embarqués, contrôle de mon aquarium, etc...)

Je suis AUSSI un gros fan de Arduino

Bonjour, je dis ça comme ça, mais ne serait il pas possible d'envisager un autre mode de déplacement?

 

On peut penser à un robot utilisant une sorte de reptation.

 

Il s'agirait d'avoir une sorte de bras, articulé, un peu comme un bras robot, mais avec davantage de segments.

 

une forme un peu comme ceci : |\/\/\/\/\/|

Chaque section contient un servomoteur assez costaud, et l'ensemble peut donc se plier en accordéon ou se déployer pour gagner en longueur.

Les sections terminales quand à elles comportent des patins qui permettent au robot de s'appuyer sur les parois du tube.

 

On imagine par exemple un servomoteur qui "pousse" deux patins perpendiculairement vers les bords, et par pression, cale le "pied" du robot.

 

Donc au départ, le robot cale son pied arrière sur la paroi du tube.

le corps s'étend, et ainsi il s'allonge. Il cale alors son pied avant vers les parois, de la même façon, et libère son pied arrière.

Il se contracte, et l'avant étant fixé, l'arrière se déplace.

 On libère alors le pied avant, on cale le pied arrière, et on recommence.

 

Avec une conception adaptée du pied avant, on peut alors pousser les "trucs" dans la canalisation en avançant à chaque fois.

Pour les coudes, il suffit d'un bon algorithme pour que le corps tourne pendant la poussée (donc une poussée asymétrique sur chaque servo pour faire l'angle).

 

Le système de "pieds" peut reprendre celui des tunneliers, qui ont des pistons qui poussent vers les parois quand ceux ci placent les bords en béton après le forage:

 

 

(o) fermé devient : (--o--) en ouvert. Idéalement, un système à trois points serait plus efficace, mais pas facile a dessiner en asci art ^^

j'essaie quand même : 

 

  ^

  o

(   )

 

devient : 

 

    ^

    |

   o

  /  \

(      )

 

 

Bon, le dessin est pas top, mais avec des angles de 120°, vous imaginez l'idée.

Si tu veux faire une machine en forme de singe, mais télécomandée, qui peut avancer, reculer, tourner à gauche ou à droite, oui, tu peux "hacker" une voiture télécomandée,
et ne rien programmer.

Maintenant, c'est une voiture télécomandée avec une autre "skin", et pas un robot. Si tu veux ajouter des fonctionnalités, il faudra pouvoir programer le bouzin.

Déjà, la voiture télécomandée, utilise t'elle une conduite différentielle? (cad deux roues motrices avec chacune leur moteur indépendant, et la possibilité de tourner
dans des sens opposés : pour tourner d'un coté, une roue tourne dans un sens, et l'autre dans l'autre sens, par ex). Dans le cas contraire,
si les deux roues de ta voiture télécommandées tournent toujours dans le même sens (soit les deux vers l'avant, soit les deux vers l'arrière), déjà tu aura du mal
pour faire le robot à trois roues, à moins de réussir à utiliser un mécanisme pour orienter la troisieme roue.

Mais passée cette étape, à moins que ta voiture télécomandée ne dispose de fonctionnalités suplémentaires (par exemple une tourelle orientable en appuyant sur un bouton),
tu ne pourra pas faire grand chose d'autre sans programmer. Si tu veux faire bouger les bras, il faudra par exemple utiliser un/des servomoteurs. A quoi vas tu les brancher?
Comment fera tu comprendre au robot que tu veux bouger de tel angle? dans tel sens? rien qu'avec une articulation, il te faut déjà deux commandes : tourner dans le sens direct, et dans le sens indirect.
Si on rajoute le second bras, ça fait 4 commandes. Si tu as un second degré de liberté sur chaque bras, ça te fait 4 commandes.

A moins de découper et d'assembler des bouts de plein de voitures télécomandées, et autant de télécomandes, je vois mal comment faire sans programmer.

En fait ça me semble BEAUCOUP plus simple de prendre ton idée, d'ajouter un Arduino, et de le programmer... D'autant que la programmation Arduino se fait par USB, est extrêment simple, et très puissante...

Ce que tu veux faire n'est pas compliqué avec un peu de programmation; par contre sans rien programmer, à mon avis il faut avoir un énorme sens de la bidouille, et avoir envie
de passer pas mal de temps dessus... Bref, ça me semble plus cher et complexe de faire le projet sans programmer en récupérant des morceaux de mécanismes radiocommandés.

Salut!
J'ai utilisé deux servos à rotation continue pour un robot, et parfois
le réglage de la position médiane prenait un peu de temps. De plus, après
un certain temps, je me rendais compte que le réglage "bougeait". Du coup
il fallait souvent re-régler le tout. Il me semble que l'un des servos
le faisait plus que l'autre...

Sinon, pour avoir un mouvement précis, c'est possible avec un moteur pas à pas,
mais aussi avec un moteur DC classique... Avec de la PWM on peut contrôler assez
précisément la rotation de chaque moteur.
Pour avoir quelquechose de réellement précis, il faudrait à mon sens avoir
un feedback sur la rotation des roues/axes des moteurs.
ça peut se faire avec des capteurs de réflectance, si la roue à des "créneaux",
ou au pire en peignant un motif noir et blanc, avec un photo-interrupteur qui détectera
le passage du moteur, ou avec une roue codeuse fixée sur l'axe de la roue, ou encore
mieux sur l'axe moteur.

Dans ce cas, tu sais de combien à tourné la roue, donc de combien à avancé le robot (moins
le glissement sur le sol).

Après il est possible de mesurer le mouvement réel du robot, mais ça demandera des capteurs plus chers.

Bonjour,

attention à la OLO, c'est pas cher, mais ça immobilise votre smartphone (qui coûte souvent plus cher que l'imprimante)

pendant toute l'impression. Vu que ça utilise la lumière de l'écran pour solidifier la résine, ça risque d'être très long, très très long.

Enfin, la zone d'impression est réellement minuscule...

 

Et n'oublions pas que c'est de la résine, donc il faut nettoyer les pièces après, jouer avec des produits chimiques, etc...

 

l'impression par SLA, c'est très chouette, et on peut avoir des détails fins, mais ça a des contreparties!

Je pense qu'un débutant devrait partir sur de la FDM, plus simple.

 

Et pour les robots, même chose, FDM plutôt, car on a rarement besoin de détails très très fins, mais d'une forme précise, 

et en FDM on a souvent des plus grands volumes qu'en SLA à même prix

 

Et n'oublions pas : le filament de plastique ne vieillit pas (j'ai des bobines qui ont quelques années, et l'impression est comme au premier jour!)

 

Attention toutefois à l'humidité avec les bobines de nylon : il faut les stocker dans un endroit sec (une boite fermée, par ex)

Bon courage alors

Je suis d'accord avec R1D1, les micros servos à 1.6kg/cm (a tout hasard, des tower SG92R?), c'est sympa,
mais avec la portée de ton bras, ça risque fort de ne pas suffire.
En toute logique, il faudrait avoir des servos de taille décroissante, les plus petits en bout de bras.

D'autre part, pour faire un bras robotique, je te conseillerais d'investir dans de bons servomoteurs,
avec des engrenages et un axe de sortie en metal.
J'ai des micro-servo avec engrenage et sortie en plastique, ça ne tient pas des masses...
Pourtant dans mon cas, il s'agit de faire tourner une masse raisonnable, dont l'essentiel du poids est supporté par
des roulements. Malgré tout, l'ensemble se sépare facilement.

Bref, à mon avis, un gros couple au niveau de l'épaule, et autant que possible au niveau du coude,
un plus petit pour le poignet, et un petit pour la pince de la main.

Du coup, ça a fonctionné comme tu voulais?

Bonjour,
Je suis en train de réaliser un petit robot qui fonctionne avec une télécommande radio (433Mhz si ma mémoire est bonne).
Les fonctions sont extrêmement simple : avancer, reculer, tourner à droite et gauche.
Le joystick est numérique à 5 interrupteurs.

Si le joystick de la télécommande est:
- "en haut", j'envoi un signal carré de fréquence 1kHz
- "en bas", j'envoi un signal carré de fréquence 2kHz
- "à gauche", j'envoi un signal carré de fréquence 4kHz
- "à droite", j'envoi un signal carré de fréquence 8kHz.

Ceci est imposé.

En revanche je voudrais rajouter une fonction : si j'appuie sur le joystick, j'allume une lumière sur le robot.
Je veux que si l'utilisateur demande d'avancer, relâche rapidement le joystick, appuie dessus et redemande d'avancer une lumière s'allume et le robot continue sa route.

Je me suis donc dit que j'allais ajouter une fréquence 16kHz d'émission. Mais c'est là ou je bloque.

J'avais pensé à :
si f = 16kHz alors lumière = 1 - lumière

Mais comment faire pour que si l'utilisateur reste appuyé, la lumière ne change d'état qu'une seule fois ?

Merci d'avance !!

PS: J'ai pensé aussi à si lumière allumé alors rapport cyclique du signal d'émission égal 50% et si on veut que la lumière soit éteinte alors 25%, mais ca complique un peu tout.

Pour ma part, j'ai eu cette problématique avec une interface utilisateur et des boutons poussoirs. Ma solution est d'utiliser une commande de type "toggle". Je m'explique.
Il y aurait une variable x quelquepart qui sert à reternir l'état précédent de la commande. Une seconde variable y stocke l'état de la commande reçue.
Enfin, une variable etatLampe, qui stockerait l'état de la lampe (allumé ou éteint).

Donc du coup tu fais par exemple:

x=0;
etatLampe=0;//eteint par défaut par exemple

loop()
{
   y=lireRadio()
   if(y==LIGHT)
   {
     if(y!=x)//si la valeur lue n'était pas déjà "LIGHT" à la précédente lecture,
     {
        etatLampe=not(etatLampe);//on inverse l'état. Si c'était allumé, on éteint, et vice versa.
        digitalPinWrite(ledPin,etatLampe);//et la ben on écrit effectivement l'état de la broche de controle de la led.
     }
   }
   //ici on insère les blocs des autres commandes
   x=y;//ne pas oublier de mettre à jour la variable "état précédent" pour le tour suivant!
}

Du coup, la commande de lumière ne prend effet que si l'on avait une autre commande avant. Si l'utilisateur maintient
alors que c'était éteint, la lumière s'allumera et le restera, jusqu'à ce que l'utilisateur lache et réappuie.
Idem pour le cas inverse.

Le système peut toutefois être sensible aux perturbations du signal radio, donc si l'utilisateur appuie en continu,
mais que le contrôleur voit ça comme plusieurs appuis, il pourrait clignoter (par exemple si il y a des perturbations).

Pour régler ce problème, une solution serait de ne changer l'état que si celui ci est similaire depuis au moins 100ms par exemple,
avec un compteur tout simple de tours de boucle, et une variable stockant quand la dernière lecture de la lampe a été faite.

Ainsi on filtrerait les microcoupures, et 100ms, c'est bien assez rapide pour que l'utilisateur ne remarque pas le délai à l'allumage/extinction.
Au pire on peut adapter cette valeur après des tests (utile si on veut envoyer du morse avec le robot ^^)

Si tu ne connais pas du tout tout ça, les capteurs analogiques simples seront peut être plus simples à utiliser que des capteurs I²C.
La question est de savoir si ton robot possède déjà une liste de capteurs, ou si vous devez choisir?

En dehors de ça, les codes que tu as posté, bah ils se contentent de lire la distance et de l'afficher...

Il te manque la partie évitement d'obstacle.

Si c'est un projet d'études, à mon avis, tu as largement le temps d'apprendre les bases de la programmation Arduino.
Pour ce qui est de faire un robot à évitement d'obstacle, c'est très simple à faire, et très rapide. C'est l'objet d'une après midi tout au plus pour avoir un système fonctionnel

Je pense que le mieux, c'est que tu essaies directement, car programmer un Arduino sans essayer, ça ne t'apportera pas grand chose
(ce que je veux dire, c'est que c'est en essayant sur le Arduino qu'on apprend des choses, et que sinon, on pourrait aussi bien te donner
du code fonctionnel, mais tu n'en retirerais rien, il te faut donc essayer pour voir !)

Et ce qui est intéressant, c'est que tu peux déjà faire des montages simples, avec juste un Arduino et un capteur, même si tu n'as pas le reste du robot...

Sympa l'idée mais il y en a un paquet />/>

- R2D2 et C3PO
- wall-e
- gigi de dragon ball gt
- Marvil dans le guide du voyageur intergalactique

Bon je suis sûr que j'en connais d'autre mais ils ne me viennent pas à l'esprit :'(

On aime pas les mêmes genre de robots ^^
(c'est pas un reproche hein!)

Par contre du coup les tiens seraient bien plus difficiles à construire!

Au passage si vous avez aussi des idées d'ordinateurs célebres, comme HAL9000 dans 2001, ça m'intéresse J'ai beau réfléchir, je ne vois que HAL! Ou "Maman", dans Alien, mais bon,
c'est juste un écran cathodique tout moche avec du texte vert! Certains concepts de SF ont salement vieilli ^^

Pour le bois, je te conseillerais plutôt le contreplaqué que le MDF. Le MDF est joli, donne de très bonnes finitions,
mais c'est un matériau assez flexible, trop à mon gout. En contrplaqué, je pense que tu peux faire plus fin.
Avec quelques poutrelles en alu pour faire la structure, et un peu de contreplaqué 5mm, tu as de quoi faire un chassis solide, à mon sens.

Sinon une solution, c'est de faire un chassis en poutrelles alu creuses , avec un treillis métalique pour la structure, et de la fibre
de verre/carbone/kevlar pour les surfaces. ça donnerait un truc léger et solide ^^

Attention toutefois avec la fibre de carbone, j'ai entendu dire qu'elle bloquait les ondes radio, donc les éventuels élements radio doivent "voir"
le monde extérieur.

Sinon il y a aussi le plexiglass, ou mieux le polycarbonate. Ce dernier est un matériaux au même rendu que le plexi, mais en nettement plus solide.

Quand tu dis que ton robot mesure 1m, il manque les autres dimensions ^^ 1m² de surface au sol? ou alors 1m³ de volume?

Parceque avec 1m de portée sur certains élements, tu aura des problématiques de souplesse avec des éléments légers, et des problématiques
de poids avec des éléments plus rigides.
Si tu as réellement une surface de 1m², je pense qu'il te faudrait une conception des sous éléménts triangulaires (un peu comme le principe des éléments de la tour effeil, des triangles) pour renforcer la rigidité de l'ensemble.

Hello!
Quand j'aurai plus de temps, j'ai pas mal de projets de robots à faire. Mais plutôt que de simplement faire des robots avec un design quelconque, je me dis que ce
serait fun de copier le design de robots célèbres, au cinéma, dans les jeux, les manga, BD, bouquins, etc...

Voici quelques uns des robots que j'ai trouvé iconiques, et que j'aimerais bien reproduire :

Le MonkeyLord, de Supreme Commander
Le AT-AT Walker, de Star Wars
Le Tachikoma, de Ghost In the Shell

Après il y en a pas mal d'autres, par exemple Les sentinelles, de Matrix, mais bonjour
la complexité du robot, sans compter que ce serait un sacré boulot rien que pour qu'il se déplace ^^
Bien sur je n'oublie pas le légendaire Terminator, T-800, mais bon, un robot bipède anthropomorphe, c'est un projet en soi ^^

Je me suis fait un mini PC inspiré de HAL9000, de 2001, l'odyssée de l'espace, il y a peu (le mien s'appelle HAL3000), mais bon, ce n'est pas un robot ^^

Il faudrait sans doute que j'aille voir du coté des univers de Gunnm, Blame, Shadowrun, ou encore de Warhammer40K!

Bref, j'en oublie sans doute plein d'autres! Et donc vous, vous pensez à quoi comme robots iconiques?
Ou alors au contraire, peu conus, mais avec un design qui vous a plu?

Il est génial ce robot!
On dirait un robot énervé
J'ignorais qu'on pouvait utiliser les cartes des servos de la sorte!
C'est très instructif!

Si tu travailles avec l'IDE Arduino (le logiciel téléchargeable depuis leur site), regarde dans Fichier > Exemples > Servo. Il y a normalement "Knob" et "Sweep" qui devrait pouvoir te permettre de faire ce que tu veux. Tu n'as normalement pas besoin du motor shield pour les piloter (s'ils ne consomment pas trop de courant, donne nous leur référence, histoire d'être sûr que c'est le cas).

Sweep devrait même être presque ce que tu veux faire.

Et même si les servos consomment trop, il suffit de brancher le VCC et la masse de ceux ci sur une source 5V (des batteries), en s'assurant bien que la masse des servos est connectée à la masse de l'Arduino, et ça roule

Et en effet, il suffit de modifier sweep, et de mettre comme bornes 0 et 45° par ex.

Et si il s'agit de synchroniser les servos, bah ça marche aussi, au pire un peu de delay entre l'envoi des commandes pour permettre au plus rapide
d'attendre le plus lent.

Ou sinon, un robot Raspberry Pi...
Avec, tu peux utiliser java, C, C++, C#, python, php...
Pour le travail vidéo, il suffit d'utiliser le surpuissant OpenCV, et le robot aura facilement une pile TCP/IP, avec de l'ethernet, du wifi, du bluetooth, ou n'importe quel réseau moderne...

Sans vouloir faire de pub, j'ai fait un tuto sur la construction d'un robot de ce type à base d'un Raspberry pi, pour environ 100€.

Et si tu as déja un robot fonctionnel, à mon avis ce serait TRES facile d'intégrer un raspberry pi pour faire cet aspect vidéo

Le premier but de ce Robot est d'être controllé à distance (over ip) et de streamer la vidéo pour le contrôle à distance.
Dans un deuxième temps, un auto pilotage pour rechercher une personne dans un environnement intérieur.

J'ai donc essentiellement besoin d'une camera et d'une connexion wifi.

Encore une fois je ne crois pas qu'il y ait déjà des robots tout faits avec un Raspberry pi.
Mais toujours est-il que le raspberry pi pourrait te permettre de remplir tous les objectifs dont tu parles.
Le tuto dont je t'ai donné le lien plus haut permet de faire une base robotique qui te permettra de faire tout ça.

Partant de là, il suffit juste d'ajouter une clé wifi, et une webcam.

Pour streamer un flux video depuis une webcam USB par le réseau, en wifi, j'ai fait un tutoriel :
http://forum.pcinpact.com/topic/165594-raspberry-pi-fabriquons-des-trucs/page__view__findpost__p__2749532

Donc en combinant ce tuto et celui cité dans mon précédent post, tu as de quoi remplir tes objectifs.

Et pour la partie suivante, tu peux très facilement installer openCV sur le Raspberry Pi (c'est un linux classique, qui est installé dessus), et utiliser les exemples fournis (facedetect pour détecter les visages, et je sais qu'il y a une fonction pour détecter des corps entiers. Pour ma part facedetect fonctionne assez bien, l'autre je ne l'ai pas essayé).

Faire du wifi sur un microcontôleur, c'est peut être possible, mais ça risque d'être compliqué.
Pour la vidéo, à moins que tu ne prennes effectivement une caméra IP wifi, qui serait juste alimentée par
le robot, il faudra que le robot soit capable de s'interfacer avec la caméra. Si tu prends une caméra IP,
il faut toujours trouver un moyen de mettre un composant wifi sur le microcontroleur, pour lui envoyer
des commandes et/ou recevoir les données du robot.

Et ça ferait deux emetteurs wifi au même endroit, peut être pas l'idéal pour l'efficacité du signal.

Bref, ça doit être possible, mais à mon avis ce sera bien plus simple si ton robot embarque un processeur complet, un OS classique, et soit capable de gérer lui même la webcam, et le réseau.

Et pour ça je ne vois pas mieux qu'un raspberry pi, qui est économique (30-35€), consomme relativement peu (2-3W maxi), est très compact, facile à trouver, léger, tout en étant capable de faire diverses taches...

Bonjour!

La différence, avec ce capteur, c'est qu'à priori, tu envoies un "ping", et qu'il mesure le temps mis pour que le signal lui revienne.

La distance n'est donc pas forcément accessible directement. D'un autre côté ça revient presque au même, car on peut

s'attendre à ce que ce soit quelquechose du genre D=f(T), ou D est la distance, et T le temps. avec un peu de chance, il s'agira même d'une fonction linéaire, du genre D=A*T+B ou A et B sont des valeurs quelconques.

 

Bref, dans tous les cas, il s'agira de trouver comment mesurer la valeur de retour du capteur. Dès lors, il faudra soit calculer la distance en trouvant la bonne fonction, soit utiliser cette valeur brute. Avec certains capteurs j'utilise la valeur brute, car je ne connais pas la fonction.

Dans ce cas, il suffit  de tester, et noter les valeurs limites (par exemple, si le capteur retourne 25, que ça correspond à environ 10cm, ou un truc du genre).

 

Pour l'algo, avec 3 capteurs, on reste sur des choses similaires, cependant, il faudra tester et adapter les valeurs. De même, il faudra adapter l'orientation du capteur. En effet, il convient pour bien optimiser le tout de savoir quelle est la largeur du faisceau, pour pouvoir le positionner.

En effet, le capteur infrarouge détecte vraiment devant lui, car c'est un rayon étroit. Mais les capteurs ultrasons ont un peu de dispersion, et détectent un peu sur les côtés.

Il faudra de ce fait s'assurer que le faisceau du capteur 1 n'est pas capté par le capteur 2, et vice versa.

A moins de n'activer les capteurs qu'à tour de rôle.

 

Bref, dans tous les cas, il faudra donc ajuster les distances à partir desquelles le robot considère que l'objet détecté est un obstacle, ainsi que la durée de rotation (le sleep(0.2))

En effet, dans mon cas, cette durée permettait de m'assurer que le robot tournait suffisamment pour que l'obstacle ne butte pas sur son "épaule", mais ça dépend du robot, de sa largeur, sa vitesse, etc.

 

Vu que tu as pris les roues pololu  de 32mm, il ira moins vite à moteur donné, donc il devra tourner plus longtemps. En contrepartie, ça permet un positionnement plus précis

Bonne continuation, si tu as besoin d'éclaircissements, n'hésite pas!

J'ai démonté R.Cerda, mais j'en construis un autre sur le même principe, en l'améliorant, donc je partagerai le code et les ressources