A priori tu dois pouvoir t'affranchir de l'i2c et faire une simple communication série entre ton programme Python sur l'ordinateur et ton Arduino.
Il te suffit donc de brancher le câble USB classique entre l'ordi et l'Arduino.

Très bien, merci !

Mais sais-tu comment mon programme arduino peut utiliser les résultats du programme esclave python ?

Bonjour,

A priori c'est faisable. Voici un lien vers un projet analogue utilisant une Raspberry Pi pour faire le traitement vidéo avec OpenCV, mais tu peux utiliser aussi un ordinateur plus classique pour faire ce traitement vidéo:
http://blog.oscarliang.net/raspberry-pi-face-recognition-opencv/

Bon courage

Oui, voilà c'était l'idée. S'affranchir d'une raspberry et tout faire directement avec l'ordinateur.

Il suffit donc que je branche l'arduino en USB ? (pour avoir la liaison I2C)

Merci.

Bonjour à tous,

Comment allez-vous ? Je ne suis pas venu depuis un moment sur le forum (trop de travails /> ...)


Je viens vous présenter mon projet de deuxième année en classes prépa PT (Physique Technologie).
Tout d'abord, le thème de l'année est : ECHANGE, TRANSFERT.

Nous sommes un groupe de 3 élèves, et nous avons choisi de travailler sur un "robot" chirurgical nommé Hipprocrate. Je ne rentre pas en détail dans son fonctionnement. Le but de notre étude consiste à modéliser et analyser quelques aspects de son fonctionnement ; qui sont :

1/ Verrouillage de cible par asservissement visuel

Le robot fixé sur un rail horizontal motorisé devra s'aligner avec un objet (choisi par l'utilisateur). L'asservissement visuel est réalisé grâce à une caméra en aplomb de la scène (non embarquée donc).

Rapport au sujet : Etude cahier des charges en stabilité et reconnaissance d'images (c'est toujours mieux de pas confondre le coeur et l'intestin pour un robot autonome /> )

2/ Télémétrie ultrason

Evaluer la distance entre le robot et l'objet choisi (déjà réalisé l'année dernière grâce à une télémétrie ultrason)

Rapport au sujet : Encore une fois, c'est mieux de savoir ou s'arrêter avant d'opérer.


A l'heure actuelle, si la partie théorie est en partie conçue, il reste une petite question de conception, qui je pense, pourra être résolue grâce à vous.

En l'état, on se demande :

*Peut-on faire notre traitement d'image avec openCV et python et renvoyer les résultats d'analyses sur un programme Arduino directement ? (car on utilise une Arduino NANO en microcontroleur)


Merci d'avance de votre aide,
N'hésitez pas à donner votre avis sur le projet, ou d'éventuelles suggestions, nous sommes preneurs de toute remarque.

Bonne après-midi,
Jbarso78

Après les ultrasons, ça ! />/>
Tu commences à me rattraper ! =) bientôt je te chercherais juste sur mais talons mes tu seras devant ! />/>
( d'ailleurs j'ai retrouvé mes derniers travaux sur les ultrasons mais bon maintenant tu en as plus besoin ^^ )

Bref !
Je travaille justement là dessus donc j'espère bien que la raspberry pi est suffisante pour cela ... Après faudra pas lui demander trop d'images par secondes non plus de ce que j'ai pu en lire ! Mais je verais bien à moins que tu le découvres par toi même avant ! ( un exemple parmis tant d'autre de ce que j'ai pu lire : http://stackoverflow.com/questions/16609921/usb-webcam-runs-slowly-on-raspberry-pi-with-opencv )

En gros pour le traitement d'image j'ai reçu ma web cam hier et là je m'intéresse à ce tuto : http://programmaticponderings.wordpress.com/2013/02/09/opencv-and-cvblob-with-raspberry-pi/

Et puis pour un robot raspberry pi avec L298 on est en train d'essayer de monter un projet de robot collectivement sur le même principe ! Normalement demain j'imprime une carte de moteur et si je me trouve une belle plaque je fixe mes roues dessus. On verra si je fais le premier tour de roue demain soir ! ^^


Bon par contre pour répondre à ta question, je ne suis pas sur que partir là dessus pour ton TIPE ( Bien que le sujet soit intéressant ) ne soit une très bonne idée ... "le restituer au robot." est selon moi la seule partie répondant au sujet imposé dans l'explication que tu donnes de ton sujet. ( Après ce n'est que mon point de vue ... ) Par contre rien ne t'empêche de développer quand même ce que tu veux faire : d'ailleurs je t'y encourage />/> mais d'axer ton TIPE surtout sur la partie Echange et transfert ... Et donc par exemple développer un protocole de communication propre ... par ultra-son par exemple ! ( c'est les chiens qui vont apprécier x) ) ou n'importe quoi d'autre plus basé sur la communication, pour transférer et échanger des données ...

En tout cas je te souhaite bon courage ! ( d'ailleurs comment s'est passé ton TIPE cette année ? bien j'espère ! ça faisait un petit moment qu'on ne t'avait pas vu sur le forum />/> )

à bientôt !

Salut,

Mais non, je ne te rattraperai pas. J'ai beaucoup à apprendre et parfois l'ambition dépasse les réelles capacités :on_the_quiet:/>

Bref, pour le TIPE de cette année, je passe à l'oral la semaine prochaine. Dans l'ensemble, c'est plutôt pas mal je pense. On reste très simple avec plusieurs parties qui répondent à un cahier des charges qu'on s'est fixé (contrôle des moteurs, réaliser une télémétrie, détecter un obstacle, éviter un obstacle).

Pour celui de l'année prochaine, à vrai dire, c'est avec un professeur que nous sommes arrivés à l'asservissement visuel. Pour répondre au sujet "Echange et transfert", j'aurai articulé le travail en 2 phases :

1/ Transfert de flux vidéo au PC (asservissement visuel)
2/ Echange "intellectuelle" entre le robot et l'Homme (communiquer "où je veux qu'il aille", qu'il me prévienne s'il a rencontré un obstacle et quelle procédure a t-il lancé : évitement, arrêt total, sans influence)

Sur des situations vraiment simplifiées évidemment pour le TIPE, mais ça reste deux grosses parties à expliquer toutefois.


See you,
Jbarso78



ps: contrôle des moteurs par L298 avec la raspberry PI je suis preneur car pour le si peu que je connaisse la raspberry a des PWM (à la bonheur!). Aussi, je dois réinvestir dans des moteurs et des roues parce que sur l'ancien projet c'était trop faible en puissance. Je me fournis sur ce site : http://www.milleniumrc.fr/ (si tu as des conseils je suis encore une fois preneur)

Bonjour à tous,

J'ai déjà au l'occasion de me présenter partiellement pour mon dernier projet en date (Détecter et éviter obstacles par ultrasons).
Aujourd'hui, et surtout, pour le projet de classe préparatoires aux grandes écoles en deuxième année, je me suis penché sur un nouveau projet : intéressant, plus pointu mais qui toutefois gardait un esprit sensiblement équivalent.

Je m'explique.


En deuxième année de classe préparatoires, nous devons proposer un projet à notre concours et le présenter devant un jury.


Thème (imposé par le concours) : Echange et Transfert

Objectif : Réaliser un asservissement visuel et permettre au robot de naviguer selon un chemin simplifié mais avec obstacles

Idées : Afin de réaliser un asservissement visuel , je pensais utiliser une simple caméra reliée à mon ordinateur portable en USB. Cette caméra m'offre un flux vidéo que je peux extraire grâce à OpenCV et traiter à l'aide de python (binérisation matricielle de mon flux). Je devrais créer un algorithme capable d'interpréter l'environnement et de le restituer au robot.

Matériels à disposition :
-> Chassis robot en plexi (déjà réalisé dans le projet précédent)
-> Emetteur-Récepteur ultrason
->Moteur à courant continu contrôlé par L298
-> Rasberry PI
-> Webcam Logitech classique
-> Macbook pro (avec logiciels : python et opencv)

Questions :

-> Que pensez-vous de ce petit projet ?
-> Devrais-je privilégier une détection d'obstacle grâce à l'asservissement visuel ou par ultrasons directement implanté sur le robot ?
-> Rasberry PI est-elle suffisante pour le contrôle de toutes ces fonctionnalités ?



Voilà voilà,
Merci d'avance,
Jbarso78

Je viens tout juste de voir que tu avais répondu ici !
Peux tu mettre le schémas de ton montage actuel ? ( emission + réception avec les valeur des composaant si possible )
As tu trouvé ton aop ? As tu trouver une autre solution ? ( pour savoir si je cherche un peu ou si j'arrive trop tard après la guerre x) )

J'ai gardé le même schéma qu'on avait dit. J'ai juste investi dans deux accumulateurs rechargeables pour donner une tension symétrique +9V -9V parce que de toute manière la réception de l'ultrason est en sinusoïdale et mon offset est nul donc pas le choix.
L'autre solution, c'est celle que l'on avait évoqué au tout début avec un offset (+ masse virtuelle).

Merci quand même,
En ce moment, on programme pour éviter des obstacles : ça avance ! Moi je me consacre au suivi le ligne par webcam maintenant comme tu peux le voir

Cordialement,
JBarso78

Merci geek maxou, je cours lire ce sujet !!!

Mmmh super cette petite carte rasperry !
Par contre, tu le programmes comment ? A lui tout seul il ne peut pas assurer le traitement d'image si? J'ai vu qu'il était compatible python c'est déjà ça.

L'idée de l'ordinateur sur le robot est bonne mais irréalisable j'ai pas d'ordinateur de cette taille.


Cordialement,
Jbarso78

Bonjour,


Oui #include <Servo.h> est essentiel (enfin je crois bien )

Pour un simple balayage du servomoteur selon un angle, tu as le tutoriel d'arduino à ta disposition : SWEEP

Bon courage,

tu as quoi comme moteur ? Le chassis du robot est déjà fait ?

Les moteurs, ce sont des petits moteurs : Moteur CC

Le châssis oui est déjà fait, je te donne une photo :
Il est possible d'ajouter un échange mais après il faudra voir si les moteurs suivent...

Là encore, ke suis loin d'être un spécialiste de l'arduino mais : Le plus simple qui me viendrait à l'esprit c'est de prendre votre plus petit et plus léger ordinateur pourtable, de le mettre sur le robot, qu'il fasse le traitement d'image et qui communique directement avec l'arduino genre en processing ou autre via la prise usb ...

Je pense que tu as déjà bien assez de problèmes pour rajouter encore des problèmes de communication derrière ...

ça aurait pu être en effet le plus simple si on possédait ce fameux mini ordinateur />

Toutefois, un macbook pro ça va faire lourd ahah!
Donc je sais qu'il y a encore pleins de petits soucis de communication à négocier enfin...

Une autre idée possible : utiliser un téléphone portable blackberry connecté en bluetooth au PC. Par contre après la liaison PC Arduino est une énigme. Au pire on laissera un câble de 10mètres et on laissera ce problème de côté. Je sais que la Arduino a un bus I2C exploitable pour cela.


Cordialement,
Jbarso78

Re-bonsoir tout le monde,

J'étais déjà intervenu sur ce forum afin de susciter de l'aide afin de réaliser mon robot qui évite les obstacles. Le projet grâce à votre aide avait alors bien avancé et les résultats sont aujourd'hui satisfaisants. (voir le sujet ici DETECTEUR D'OBSTACLES)

Bref, ce petit robot, dans le cadre de nos TIPE, a une deuxième fonction à remplir.

En effet, iBango (c'est son petit nom />/> ) doit également suivre une ligne. Pour cela, on essayera de ne pas se contenter de capteurs photodiodes classiques. Nous souhaitons faire du traitement d'image. Je m'explique :


Matériels à dispositions :
-> Webcam Logitech (câble USB)
-> Arduino Nano V3.0
-> Servomoteur
-> Mac

Objectifs :
-> Suivre une ligne
-> Anticiper les virages serrés ou les impasses

Première idée :
-> Traitement d'image avec la webcam montée sur servomoteur. On fera une binarisation de l'image avec OpenCV, par exemple.

Les interrogations :
-> L'idéal est de laisser aucune liaison entre le PC et la webcam pour satisfaire les mobilités du robot : Module Wi-fi possible ?
-> Est-ce un traitement faisable ?
-> Comment réaliser les multiples liaisons entre PC Webcam et arduino ? Webcam par wi-fi sur pc, mais comment renvoyer une information analogique à la arduino qui pourra interpréter ce signal et intervenir sur les moteurs CC? (commander par un L293D pour information)




Voilà voilà, j'espère que des spécialistes pourront apporter leurs expériences,
Cordialement,
Jbarso78

Bonjour, bonjour.

Après un deuxième essai, il y a de nouveaux résultats : assez décevants faut-il avouer.
D'abord les piles alcalines 9V ne délivrent plus que du 6V sûrement du a leur utilisation. Faut-il alors penser a des accumulateurs rechargeables 9V ?

De même nous ne sommes pas sur que nos salves générées soient acceptables. Suffit-il pour créer des salves de jouer tel un interrupteur sur le high et low de la pin ?

Aussi nous portons une réflexion sur le matériel choisi. Nous avons un TL084 (Datasheet) qui comporte 4aop et une tension symétrique +9V -9V. N'existerai t-il pas d'autres aops tels qu'on alimente notre aop (je parle des tensions symétriques) en 0V et 9V ?

Je sais pas si j'ai été très claire,
Merci d'avance.

Cordialement
Jbarso78


PS: Evolution du projet en vidéo -> Détection d'obstacle partielle

Les ordre de grandeurs semblent bon : je te fais confiance et ne reprendrais pas les calcul />/>
Je reprend uniquement la conclusion :


"Donc pour conclure, tu envois des pulses cadencés à 40KHz pendant un temps de 0,3ms et tu laisses un temps d'attente pour recevoir l'écho de ce signal émis de l'ordre de 30ms puis tu recommences... "

Du coup je te laisse compter le nombre de pulse que tu es censé émettre pendant ces 0,3ms />/> je ne pense pas que cela soit 7 mais un peu plus... />/>

Mmmmmh, je vote pour 12 pulses. Ultrasons 40kHz = 25us périodique et 0,3ms/25us=12

du deux en un que demander de plus ? />/>

Je me demande bien ! />

Faire un télémetre à ultra son optimal est déjà un bon TIPE
Faire un double asservissement de moteur à courant continu aussi ...
Allez vous réellement faire deux TIPE ? ^^
Après si vous vous mettez à deux équipes ... pourquoi pas ! Des TIPE à deux personnes ça se fait ... il suffit d'être 4 ... Par contre une question : est ce que te camarades sont aussi motivé que toi ? x) Moi perso ... mon TIPE je l'ai fais casi tout seul ... Et des fois c'est pas facile ... Surtout que mes profs ne savaient malheureusement pas comment m'aider x) ( et me camarades encore moins x) ) Et je ne connaissais pas encore ce forum ! x) bref ... Essaye d'éviter cette galère />/> Et d'ailleurs tu devrais suggérer à tes camarades de se mettre aussi sur le forum, qu'ils puissent partager eux aussi dans cette discussion !

On est un groupe de trois.
Sachant que je travaille plus sur l'ultrasons, un autre programmation, et le dernier sur le suiveur de ligne.

C'est vrai qu'on met peut être la barre trop haut. On va rester plus terre à terre.

Sinon pour un montage en tout analogique et plus simple : c'est suffisament claire dans mon esprit mais peut être pas suffisament pour l'écrire tel quel mais je vais essaye :

en fait tu as deux systèmes indépendant qui gèrent chacun un moteur.

Le système indépendant est composé : d'un capteur à ultra son tout ou rien et de plusieurs capteur de présence de ligne ( 3 par exemple) qui permettent de détécter la ligne de manière continue ( la ligne ne doit pas pouvoir se mettre entre deux capteur sans être détectée ni par l'un ni par l'autre )
Tout ces capteurs tout ou rien passent chacun dans un amplificateur inverseur de manière à réduire en valeur absolue leur niveau de sortie et qu'ils ai chacun leur niveau propre.

Exemple : si le capteur à ultrason est activé on à du -5V si le 1er capteur de ligne est activé on a du -1V le deuxième -2V et le 3ème -3V ...

Tout ces signaux rentrent ensuite dans un sommateur inverseur

Pour obtenir un signal qui va varier par pallier en fonction des capteur activés ( normalement 1 voir 2 à la fois mais pas plus en théorie )
du coup tu vas obtenir un signal compris entre 0 et 9V

ce signal va alors être comparé à un signal triangulaire variant de 0 à 5V

de manière à générer un PWM qui va commander un moteur.

ainsi même si ton robot ne va pas droit, il va heurter la ligne qui fera accélerer le moteur en défaut de vitesse de manière à ce qu'il se remette sur le droit chemin =)

Après à toi de trouver le bonne valeur pour que cela soit stable !

Et tu peux faire encore un peu mieux en gardant la même idée si tes capteurs ne sont pas logique mais analogique.

Et avec cela il n'y a même plus besoin de carte arduino ...


Après tu peux reprendre la même idée en la programmant et en passant par ta carte arduino =) ça reprend un peu le principe de la logique flou pour gérer la vitesse de tes moteurs =)

( Si j'ai le temps je me ferais le petit robot en tout analogique et un gérer par un pic pour voir ce que ça donne =) )

J'ai bien pris note de ton "asservissement". Je vais sûrement le garder pour ma culture technique car, comme tu l'as dis, asservissement moteur CC + télémétrie + suiveur de ligne, ça commence à faire beaucoup.

On va surement simplement imposer une vitesse de moteur plus rapide qu'une autre avec notre arduino et on se contentera le plus possible d'un petit zigzag par ci par là pour le moment.


Cordialement,
Jbarso78

Salut, on a bien profité le samedi, maintenant on reprend les choses sérieuses />

Je te suggère néanmoins de refaire les calculs par toi même ... Car pour un tipe la méthode est tout aussi importante que le résultat ...

Bon j'ai refait tous mes calculs.

J'ai considéré d1=5cm la distance minimale de détection d'un obstacle (à cause de ma zone dite aveugle).
J'ai donc t1=0,3ms

Après on pose t2=t1+t(dmax) où t(dmax) est le temps pour une distance maximum de détection.
Pour dmax=5mètres (je crois que nos ultrasons ne détectent vraiment qu'à 2,5m donc on est large..)
On utilisera alors t(dmax)=30ms

Et donc t2=30,3ms

Le signal d'émission sera alors 1/(t1+t2) périodique soit 32,7Hz


Donc pour conclure, j'envoie 7 pulses de 0,3ms et je laisse un temps d'attente de l'écho de l'ordre de 30ms puis je renvoie mes 7 pulses etc...jusqu'à obtenir mon écho.




En parlant d'écho d'ailleurs, je me suis renseigné sur plusieurs petits points que nous avions mentionné.
La datasheet de l'Arduino Nano V3.0 stipule "Operating Voltage (logic level) 5V". Toutefois mon prof m'a plutôt parlé de 3,3V. Donc soit je laisse comme ça (avec objet je suis à 5,04V actuellement je crois). Où j'amplifie un petit peu plus le récepteur : à voir..

De même, en sortie du comparateur, je vais brancher un buzzer et une résistance pull-down (22kOhms), pour obtenir une tension de sortie supérieure à 0V (comme tu l'as conseillé).


ps: en faites je voulais savoir, tu m'as dit de mettre t2 large, c'était pour éviter les échos parasites non? Car mes ultrasons disparaissent en fonction de la puissance qu'ils dissipent non? Donc en prenant un temps assez grand j'aurai beaucoup de chance d'éviter tout parasite d'écho envoyé bien avant?

Oui un double asservissement de la sorte est efficace mais c'est pas aussi simple que ça pour la suite dans le cas de l'utilisation de capteurs incrémentaux ... En effet ce que tu vas avoir en retour c'est le comptage du nombre de fois que ta roue denté est passée au niveau de ta fourche optique... Du coup tu vas devoir traiter cette information sur une unité de temps pour retourner ta vitesse sous forme d'une valeur ! il faut donc choisir une base de temps pendant laquelle tu dois compter les passage pour avoir un résultat sous forme de passages / unitées de temps. Tu te heurte maintenant à un nouveau problème qui est l'échantillonage et au temps de retard ....

En bref pour avoir un système des plus efficaces il te faut pouvoir compter un maximum de passage en un minimum de temps sachant que tu es limité par : la fréquence à laquelle est cadencé ta arduino et les dimensions de tes "dents".

La vitesse max de ton robot va intervenir dans les calcul pour le choix du temps d'échantillonnage mais le temps de réponse de ton moteur doit être pris en compte pour limiter ta vitesse max de manière à avoir un ensemble cohérent et stable ...

Il est préférable pour ce type d'asservissement de fixer la " roue denté " sur l'arbre de ton moteur CC et pas sur l'arbre de la roue si tu as un réducteur intermédiaire...

Bref tu as pas mal de boulot devant toi ^^
et une fois que tu aura gérer d'un côté le double asservissement et de l'autre la mesure de distance, il faudra bataille pour mettre les deux ensemble ...

Autre point de détail important, si le but est uniquement de suivre une ligne, un tel type d'asservissement n'est pas réellement nécessaire ... Il y a même moyen de faire des petits robot tout simple en tout analogique permettant de suivre une ligne et d'éviter des obstacles .... avec des moteur à courant continu ... et le montage ne serait pas nécessairement plus grand que ta carte arduino !

C'est vrai que là, on s'embarque peut-être dans un projet trop pointu. Comme l'a dit le prof, il faut faire attention à ne pas en faire trop, on pourrait croire que ce n'est pas nous qui l'avons réalisé.

On a donc deux possibilités :

- soit on poursuit le double asservissement des moteurs avec fourche optique (difficulté ++)
- soit on trouve un modèle simplifié ? Car actuellement, ce n'est pas marrant. Il ne va pas du tout droit. Pourrais-t-on imposer une vitesse plus rapide à une roue par rapport à l'autre et cela nous suffirait ?

Qu'entends-tu par montage plus simple ?




Cordialement,
Jbarso78

Okok, donc pour la fonction : éviter les obstacles, on garde ce que l'on avait dit :

Envoie de salve de 0,2ms puis temps d'attente de L'Echo de 60ms.

On fera les premiers tests et les programmes bientôt.


Pour l'asservissement de la vitesse des moteurs, nous pensons utiliser des capteurs optiques. On fixerait a chaque roue une roue dentée et on intercalera le capteurs entre les dents "dentées".
Pensez-vous qu'un double asservissement de la sorte soit efficace ? J'ai juste à faire un diagramme bloc pour bien visualiser ce que je dois faire : capteur, correction, en entrée j'ai une tension et en sortie je cherche a traduire en rotation d'un moteur si j'ai bien compris la base...


Cordialement,
Jbarso78

Pour régler ton probleme il sufit d'inverser les entrée de ton comparateur tu inversera tes états logique je te l'ai déjà dis dans un autre message ^^
Par contre dans le cas que tu me décris là tu ne mesure plus la distance tu fais uniquement un capteur tout ou rien : objet ou pas objet... Et c'est pas pareil que si tu mesure réellement la distance ! Car dans ce cas là pas besoin de s'embeter à genérer un signal émeteur par la arduino : tu laisse toujours l'emetteur en marche à 40Khz et tu écoute avec le récepteur pour voir si tu entends un echo... Au besoin tu limite la puissance dissipé dans l'émetteur pour limiter la porté des echo ...

ok pour inverser mon système logique j'avais du le monter dans l'autre sens dès le début c'est pour ça...
Donc finalement, si je veux mesurer la distance je me suis embêté à vouloir envoyer des pulses alors qu'il ne l'était pas nécessaire? Pourtant si je laisse mon signal créneau 40kHz se générer dans mon émetteur, je perdrai ma notion de "chrono" gérée par arduino non?

Je te demande deux temps et tu me donne 2 fréquences ? x) surtout qu'au final ce que je cherchais à te faire trouver c'est le signal que ta arduino doit émettre : un signal créneau périodique de periode 1/(t1+t2) de temps haut t& et de temps bas t2 ....

Donc : try again ;)en plus il faut prendre en compte t1 dans le calcul de t2 car t2 = t1 + le temps de parcourt aller retour de la distance la plus longue qu'on veut mesurer !

j'ai changé les temps en fréquence pour avoir un ordre de grandeur.
fréquence du signal de créneau=x Hz pour, je dois m'arranger pour que 1/x=t1+t2 donc

oui tu es censé lancer un chrono,
non tu n'auras pas les deux courbes superposer car il faut choisir t1 et t2 de manière à ce que cela ne soit pas superposé pour les distances min et max que tu choisis.

Conseil :choisis comme distance max la distance max jusqu'à laquelle tu reçoit encore un echo et ne prend pas plus court ... ( au pire prend un peu plus grand ^^ ) car sinon tu peux avoir des problèmes .

Oui, je vois.

Au final, j'aurai 7 pulses. Je laisse quelques secondes pour orbserver si j'ai un echo. J'ai un echo je mesure le déphasage entre émission et réception qui me traduit la distance.

tu as aussi des photodiodes pour suivre une ligne ?

En fait peux tu rappeler tout ce que tu as sur ton robot et qu'est ce qu'il doit faire ? x)

Robot ; éviter les obstacles et suivre une ligne

c'est plus un devis là mais bien de factures dont on parle ! />/>/> Par contre c'est très généreux de ta part le 13 ème mois ^^ Il était pas prévu dans mon contrat ! />/>/>

Au plaisir />

tu reçoit un signal créneau, déjà ce créneau il faudrait que tu te débrouilles pour qu'il soit compris composé de temps bas à 0V et de temps haut à 5V ( ou au moins supérieur à 3.3V a peu près, il faut se référer à la datasheet de la arduino pour voir au dessus de quel tension un signal est considéré comme un 1 logique) .

Ton signal reçut est donc composé de 0 et de 1. Par conséquent une pin digitale peut parfaitement comprendre ce signal ! pas besoin de pattes analogique qui de toute façon ne comprendrait pas mieux le signal ...

Ok pour le signal logique généré. Toutefois, sans objet, il y a environ 5V en sortie donc 1 logique. Et s'il y a un objet, en sortie, un créneau qui passe par 0V : 0 logique. Enfin, ça ne devrait pas être l'inverse ?
Finalement, je dois dire que quand le 1 logique est activé sur ma PIN digital de l'arduino : il n'y a pas d'objet et quand j'ai 0 logique il y a un objet et je dois lancer ma procédure pour l'éviter.
C'est bien ça ?

Maintenant vient l'analyse des signaux :

Premier signal envoyé par ta arduino:
ta arduino envoit un 1 logique de durée t1 suivit d'un zéro logique de durée t2

le 1 logique pendant t1 permet d'activer l'envoit d'un certain nombre n de 1 logique à 40Khz via le NE555.
Le 0 logique pendant t2 est un temps qu'il faut mettre à profit pour écouter l'echo de tes salves.

Il faut choisir t1 en fonction de la plus courte distance que tu veux mesurer et t2 en fonction de la plus longue distance que tu veux mesurer.

Je te laisse faire les calculs />/>/>/> ( J'attends la démarche complète ce coup ci />/>/>/> )

Très bien, très bien allons-y. Faisons fumer nos cerveaux.

Soit d1 la plus courte distance que l'on souhaite mesurer. On pose d1=10cm (on dit que c'est 5cm la zone aveugle mais je me méfie)
donc t1=0,3x2=0,6 ms (pour que l'onde fasse l'allée retour) => f1=1666Hz

Soit d2 la plus longue distance que l'on souhaite mesurer. On pose d1=80cm (pour se laisser la marge compte tenu que le robot avance quand même..)
donc t2=2,35x2=4,7ms (pour que l'onde fasse l'allée retour) => f2=212Hz

le signal retour va être sous forme de créneau, il faut mesurer le temps entre le début de l'envoit et le premier 1 logique reçut et ou le temps entre la fin de l'envoit et le dernier 1 logique reçu ... Il peut aussi être intéressant de compter le nombre de 1 logique et verifier qu'on en a bien n.

si j'envoies 7 trains t1, j'aurai un temps t3 telle que t3=4,2ms.

Mais imaginons, j'ai un objet à 20cm. Alors j'envoie mon train d'onde et elle revient en 1,1ms. Donc sur un oscilloscope on aura presque les deux "courbes" superposées. Mais moi je suis censé juste lancer un "chrono" quand je lance mon premier pulse et arrête mon chrono dès que j'ai un système logique sur ma pin de sortie ?

Ensuite pour mesurer le distance entre le robot et l'objet j'ai deux paramètre à prendre en compte :

1/ la distance parcourue par mon onde émise/reçue : d4=t4*v(son) avec t4 le temps de déphasage entre émission et réception
2/ distance parcourue par le robot pendant ce temps : d5=t4*v(robot)

J'ai donc une relation pour la distance (d6) entre mon robot et l'objet à l'instant qu'il reçoit l'information qu'un objet est présent : d6=d4-d5

Après petit programme (exemple : ligne droite avec pour objectif de s'arrêter devant un objet)

if 60<d6<80 then vitessmotor baissé de...
if 40<d6<60 then...

(etc)


J'espère avoir bien exposé mon truc quand même />/>/>

Alors oui il n'est pas si aisé que cela de rendre un robot stable en ligne droite cependant c'est loin d'être impossible en plus il y a certaines astuces qui permettent de simplifier la tâche ...


Donc tu es obligé d'avoir au moins un capteur quelconque ! mais ça tombe bien tu en fais un : le capteur de distance à ultrason ^^ c'est pour ça que je te suggérait de regarder mon TIPE... car en fait j'asservis en vitesse les deux roues de mon robot avec un unique capteur par contre c'est un capteur exterioceptif ( donc qui dépend de l'environement extérieur ) Ce qui fait que mon robot à des propriétés assez intéressante : il suit la trajectoire décrite par l'objet qu'il longe et reste du coup à distance constante de cet objet ! Bon par contre moi j'ai fais tout le "programme " de mon robot uniquement avec des aop ^^ et donc en tout analogique ( pas de carte programmable ^^ ) Cela aussi était un aspect intéressant ! Mais toi tu peux reprendre le principe en le faisant avec la arduino =)

Si tu as plus de questions sur mon TIPE n'hésite pas !

Je vois je vois. Ne penses-tu pas je pourrai plutôt asservir en vitesse mes moteurs grâce à mes photodiodes ? Car en effet, pour éviter des obstacles, avoir un robot qui roule pas forcément droit ce n'est pas embêtant. En revanche pour suivre la ligne />/>/>

PS : Je dois mettre la facture à quelle nom pour le consulting ? />/>/>/> x)

Dépose un devis, je passerai à la comptabilité régler ton 13ème mois />/>/>

hum en fait tu n'as pas mis le pont diviseur de tension et tu met tout ça directement sur la patte de ta arduino ???
Tu as fais la mesure avec ou sans la arduino de brancher ??

Je crois bien l'avoir fait avec l'arduino branché et je viens de penser : cela est mauvais non?? Je vais remettre mon pont diviseur de tension avec deux résistances 10kOmhs comme convenu en début.

Par contre si tu veux quand même faire une mesure de distance avec ce procédé ça veut dire que tu n'as pas compris tout une partie de ce que j'ai dis ... car malheureusement c'est pas possible tel quel ...

Pour cela ce que tu dois exploiter c'est le temps entre début de l'émission et début de réception de l'écho ou le temps entre la fin de l'emission et la fin de réception de l'écho voir les deux />/>/> !

Si si, j'ai bien compris cette partie : ce qui m'intéresse c'est le déphasage entre le signal d'émission et celui de récepteur. Mais je croyais que je devais avoir un signal centré autour de 0V car un pin digital ne lit que les niveaux hauts et bas non ? Dois-je mettre plutôt sur un PIN Analog qui "comprendra le créneau" ?

De même, j'en profite pour t'interroger car j'ai fait le point en programmation et je crois que tout n'est pas très très claire (embêtant pour poser toutes les variables... /> )
En effet, j'envoies des 7 pulses de 300Hz sur le PIN d'entrée relié au NE555 qui lui émet une onde de 40kHz à mon émetteur ultrason. Mais quand on fixe à 300Hz, cela signifie que l'onde pourra détecter environ jusqu'à 50cm c'est bien ça? Mais si j'ai un objet situé à 20cm, le temps que j'envoie mes 7 pulses, j'aurai déjà un signal en retour.

Je me trompe? Tu vois ce que je veux dire? Je crois que je fais une confusion pour le coup ahah!

Attention la tu fais l'amalgame entre asservissement et correcteur d'asservissement ! Dans ton lien on parle de correcteur PID.
Pour faire un asservissement il te faut un point de repère mesurable sur lequel influe la donnée que tu veux asservir... et pour mesurer cette donnée il te faut un capteur
Par exemple la vitesse d'un robot en m.s-1 entrainé par un moteur, en la mesurant tu peux asservir la vitesse de rotation de ton moteur !

si tu veux asservir en vitesse un moteur par rapport à un autre il te faut un point de repère ... Il y a plusieurs façon de faire ... et ça dépend aussi du type de capteur que tu veux utiliser ^^ il y a des capteurs proprioceptif ou exterioceptif ... Moi l'asservissement de mon tipe est basé sur un capteur exterioceptif... Pour du proprioceptif il faudrait mesuré la vitesse de rotation des deux moteurs et l'asservissement derrière est plus complexe ...

Renseigne toi un peu sur le principe de l'asservissement : consigne actionneur boucle de retour écart et errueur ... et après on reverra les correcteurs />/>/>

à bientôt !

Je vais voir ça avec mon prof de sciences industrielles demain (même s'il m'avait dit que ce serait trop dur de rendre mon robot stable en ligne droite..)
Mais n'existe pas un moyen sans capteur? Deux PWM de l'arduino gère les vitesses de deux moteurs. Je peux pas créer quelque chose en programmant?



J'ai l'impression de me répéter mais M-E-R-C-I ! />

En fait il manque juste un schémas du tout et les points sur lequel tu t'es branché pour les prise de mesures ^^ Sinon c'est un bon compte rendu ! =)

Voilà, voilà :


Les modifications faite par rapport au premier circuit :

1/ Le transistor sur la sortie du NE555 a sauté (quand je dis sauté c'est que je l'ai enlevé). Je l'avais bien branché (avec la datasheet) et ça marchait je l'ai enlevé et ça marchait très bien donc j'ai pas plus réfléchi..
2/ Mise en place d'un amplificateur non inverseur puis un circuit bouchon pour filtrer

Hum le fais d'avoir un signal continu positif est parfaitement logique ! =)

D'après ton premier schémas ( si tu as bien réutilisé exactement le même ^^ d'où l'utilité une fois encore de remettre le schémas />/>/> ) si tu as aucun objet devant ton capteur, ton récepteur ne reçoit rien. Il reste donc muet. Ton filtre lui ne change pas la donne du coup en entré du comparateur tu as d'un côté tu as 0V qui rentre du côté - et quelque chose de positif qui rentre du côté + du à ton pont diviseur de tension... du coup en sortie de ton comparateur tu as + Vsat - 1,3V (car le tl084 n'est pas un AOP rail to rail ) = 7,7V et donc en sortie du pont diviseur de tension que tu as mis en sortie de ton comparateur tu as à peut près 7,7/2 ( en fonction de la précision de tes résistances que je suppose à 5% />/>/> ) ce qui donne un résultat compris entre 3,65 et 4,05 V />/>/>

Par contre on a pas 5V quand même ^^ Sinon j'ai fais une petite erreur quelque part ... genre : le 1,3V n'est pas nécessairement exacte mais je dois pas être très loin =) à toi de me le dire ^^

Si si, sans objet j'ai quand même 5V. En faites dans mon comparateur, je pensais plus à un truc plus simple à exploiter :

PAS D'OBJET = 0V en sortie donc en arriver sur ma arduino (pin récepteur)
OBJET = créneau

il faut asservir en vitesse les moteurs

On vient de commencer le chapitre asservissement. Mais même après avoir lu ton TIPE, je n'ai pas bien vu de texte relatif à ça. Est-ce cette histoire de epsilon qui tend vers 0 ?
Peut être, pourrai-je suivre ce tutoriel : Asservissement moteur ?

Je pense donc je suis />/>/> Et je suis donc je pense ! Et je pense en avoir assez dis sur ces belles paroles />/>/>

Quel poète ! />/>

Je suis de retour.

Cablage terminé et programme simple (qui envoie continuellement des salves) : DONE ! (bien sur on changera le programme après..)


Je vous donne les résultats obtenus. Ne pas hésiter à donner votre avis.


Photo 1 : Signal "créneau" reçu par l'émetteur ultrasons.

Résultats : conforme à nos attentes en terme de fréquence. Toute fois, on obtient pas un signal créneau parfait : pb décharge du condensateur ?

Photo 2 : Signal reçu juste à la sortie du récepteur ultrasons.

Résultats : Signal sinusoïdal assez convaincant.

Photo 3 : Signal en sortie du circuit bouchon pour filtrer nos fréquences.

Résultats : Signal propre et exploitable par le comparateur (à mon sens)

Photo 4 : Signal en sortie du comparateur.

Résultats : Créneau propre et intéressant à exploiter avec la programmation. Toutefois, petit soucis (ça aurait été trop beau /> ) : je n'ai pas un signal "centré" autour de 0V. Quand il n'y a pas d'objet, on a, en sortie du comparateur, un signal continue de 5V.



Qu'en pensez vous ?


Jbarso78

Par contre je viens juste de voir que j'avais rater quelque messages en février ^^ Dont les tiens x) Vous utilisez donc des L298 ? />/>/> Vous avez pas eu trop de problème avec ? Par curiosité vous le branchez comment et avec quoi autour surtout ? />/>/>
Je gère les moteur pas à pas de mes robots avec des L298 ^^ Ils sont plutôt capricieux ces CI parfois />/>/> faut pas prendre de risque et bien les protéger =) par contre vous ça n'a pas du vous posez de problème pour les petits moteurs que vous avez =)

Comme tu dis, vu les petits moteurs que nous avons, nous avons botter en touche. Le L298 était délicat à utiliser, on s'est rabattu sur un L293D plus basique et suffisant (me semble t-il). Je suis en train de finir le branchement dessus. On va voir si une pile 9V suffit pour l'alimentation des moteurs. Au pire, batterie lipo ou pile rechargeable pour des résistances internes beaucoup plus faible.

Par curiosité, Après tu compte faire PT ou PSI ?

PT et même PT* j'apprécierai ahah. Je suis au lycée Livet, tu dois sûrement connaître. La SI pour le moment, ce n'est pas mon premier talent. J'étais "SVT-iste" donc ça vient petit à petit.

PS : il est très bien ce schémas c'est difficile de faire beaucoup plus simple ... Ton prof t'a dit ce qui ne lui plaisait pas dedans ? En tout cas moi pour mes TIPE, ce que je faisait dépassait mes profs de prépa ... Du coup j'avais aucune aide de leur part x) Robotique c'était pas leur domaine ^^ Cela ne m'a pas empécher d'avoir 17,5 en TIPE =)

J'avais vu ce circuit. Je vais m'en inspirer.
Notre professeur de SI est très inspiré par les micro-controleurs et l'automatisme donc c'est lui qui nous oriente aussi. A cela tu rajoutes un prof de physique imbattable en électronique et finalement, on s'en tire avec une bonne équipe pédagogique.

Sans oublier ton aide bien sûr />/>

J'ai écris un peu vite, en effet.. mais je t'assure 30<20 : on voit que vous perdez tout en école d'igné

Je te donne l'évolution du projet lundi soir.

A bientôt,
Cordialement

En tout cas on voit bien le formalisme prépa ! C'est claire et efficace mais ... c'était presque ça : à un facteur 2 près />/>/>/>
En effet n'oublis que le son fait "l'allé retour " />/>/>/>

Ahah en effet, donc D=(v*T)/2

Certes j'ai parlé d'un signal à 4 KHz mais c'était uniquement un chiffre un peu au pif ^^ j'aurais pu aussi bien dire 400 Hz ^^ Le but était surtout de te faire comprendre la forme générale du signal en train d'impulsions et une façon parmis tant d'autre de le générer.
En fait si tu fais quelques calculs ou si tu test tu va voir que 4 KHz c'est pas bon ^^ Je te laisse voir pourquoi />/>/>/> ( En 25 ms le son a le temps de parcourir quel distance ? et toi tu veux quel portée ? Quel lien entre le temps d'attente max et la porté max que tu veux ? />/>/>/> Du coup tu choisis un signal de quel fréquence ? )

J'ai envie de dire qu'une détection jusqu'à 50cm suffit. Donc 300Hz, ça m'a l'air bien !

Je pense que j'ai pas forcément été assez claire dans ma question en fait mais tu as vu à moitié ou je voulais en venir. Dans le cas où tu ne reçois pas d'écho, qu'est ce que ça veut dire ? Juste qu'il n'y a pas d'objet ? Tu crois qu'une boite d'oeuf ça renvoit aussi bien les ultrasons qu'un mur en béton ? Comment gérer ce cas inconnu ? C'est ça la vrai question />/>/>/>

Ah là je vois. Je dirai que les ondes émises réfléchissent, mais pas de façon "symétrique", et ne reviennent jamais au récepteur. Donc soit je n'ai pas d'objet soit l'onde ne revient pas.
Solution possible : rajouter un détecter de contact pour éviter le choc ou monter les ultrasons sur servomoteurs pour élargir la plage de "vision" ?

Non tu n'as pas forcément besoin d'un écran surtout sur un robot mobile, c'est dure de regarder le petit écran lorsqu'il se déplace ^^
En fait l'écran ou n'importe quel périphérique servant d'affichage t'est utile pour faire des test et du débugage.
L'écran permet ( une fois que tu le maitrise />/>/>/> ) d'afficher aisément des informations complexes ( comme une distance mesuré par exemple ^^ )
Le but étant de pouvoir voir si ton capteur mesure correctement la distance. Tu peux avoir le mode tout ou rien : je suis loin des obstacles j'éteint une led, je suis tout près j'allume. Cependant si tu ne reçois pas d'écho : tu es loin ou près ? />/>/>/> Vide ou matériaux absorbant droit devant ? />/>/>/> du coup tu peux faire clignoter la led ^^

C'est simple et efficace ^^ Cependant vous ce que vous voulez faire c'est un robot, autant qu'il soit mobile rapidement ^^ Du coup au lieu d'allumer et d'éteindre une led vous pouvez faire tourner un moteur. Et en fonction de la distance mesurer le faire tourner plus ou moins vite . ( Et je ne parles pas encore de changement de sens car cela complexifie un l'électronique mais ça on y viendra plus tard />/>/>/> )

Je sais que devant l'US il y a une zone où il se voit pas. Après il devrait "voir" entre cette distance et 50cm (si programmer à cette distance). En gros, dans mon programme, pour D>40 pas de modification de la vitesse des roues, 30<D<20 on ralentit de tant la vitesse des moteurs et etc... ça va comme stratégie ça non ? Après peut être que la distance de détection à 1m me donnerait plus de marge à voir..

Alors là c'est moi qui ne te suit plus ... quel fréquence ? il y en a deux x) celle des pulse de 40 KHz imposé par la structure du capteur, et celle à laquelle tu envois dés séries de X pulses.
De même je ne vois pas le lien entre l'une ou l'autre des fréquence et le fait que le robot doit être autonome ni d'une régulation ^^

Quel est le but du robot ? Se déplace en évitant des obstacles ? Autre ?

Oh non, c'est moi qui a commencé à mélanger un peu tout mais j'ai compris enfin je crois.

J'envoie un signal de 300Hz avec mon arduino qui lance un signal 40kHz à l'émetteur US qui partout 50cm (enfin l'onde). Ensuite le reset remet à zéro la mesure et etc...
Enfin j'espère avoir été clair.



Cordialement,
Jbarso78

En conclusion tu es arrivé d'un coup à une suite de choix corrects ^^ ( Moi qui avait prévu de t'y emmener au fur et à mesure en te posant des questions etc ... mais en fait même pas besoin. Chapeau =) )

Non mais oh je suis redevant de ton aide !

Par contre juste histoire de te mettre sur la voie pour du code : si tu commandes l'émission de pulse via la arduino et que tu as beau attendre, tu ne reçois rien : tu fais quoi ? />/> Et combien de temps tu attends avant de retenter d'envoyer des pulses ? />/>/>

J'ai un expert codeur dans mon groupe ahah. Mais je serai obliger de comprendre moi aussi. Je dirai que je change la fréquence du pulse. Mais bon, cela dépend si déjà mon récepteur à un objet face à lui.

Avec ma liaison PIN Arduino digital -> RESET NE555, j'envoie à une fréquence de 4kHz (en suivant tes conseils) donc soit tous les 0,25ms si mon calcul (de tête /> ) est juste.

Ce que je n'ai pas encore bien vu, c'est comment je gère la fréquence des pulses que j'envoie ? Sachant que le robot soit être autonome ensuite je dois réguler tout ça.

Comment tu ressort l'information de distance à partir du temps que tu calculs? />/>

Notons T le temps de retard qu'à le signal de réception sur le signal d'émission; v = vitesse du son et D la distance des US à l'objet.

J'ai v*T=D, je pense tout simplement.

Dernière question niveau Hard : Quel périphérique tu utilise pour ressortir l'information de distance ? />/> ( Si tu as pas un écran LCD sous la main pour commencer faire clignoter des led c'est déjà très bien />/> Mais tu peux aussi générer un PWM qui alimente un moteur par exemple />/> à toi de voir ! )

Je sais pas vraiment si j'ai besoin d'afficher sur un écran ma distance objet<->robot. Enfin ce serait sûrement plus rigoureux..
Ton histoire de PWM j'ai pas suivi.

Dans l'idée de nos programmes, je pensais envoyer des pulses à 4kHz et en sortie du comparateur j'ai un "système logique" : si 1 = objet = calcul distance = en fonction du résultat modification vitesse/sens de rotation moteur.

C'est ça grossièrement, non?




Merci beaucoup en tout cas,
Jbarso78