Go Down

Topic: Radar vitesse moyenne modélisme (Read 4098 times) previous topic - next topic

barbudor

1) Déjà effectuons la distinction entre résolution de la mesure et précision.
On parle de 1/1000eme
Sur une distance de 10m, cela suppose que la distance entre les 2 rayons lumineux soit exactement de 10m à mieux que 1cm.
Y compris le parrallelisme entre les rayons.

Sur un autre sujet, j'avais donné des indications pour mesurer la vitesse d'une bille qui roulait vite sur quelques dizaines de cemtimetres. Il s'agissait aussi de mesure un temps de l'ordre de la centaine de microsecondes avec une résolution de la microseconde. Tout a fait à la porté des timers de l'Arduino.

2) Plusieurs voitures ?
Plusieurs voitures en même temps dans la tranche de 10 m de mesure ?
S'il faut faire de la discrimination, la ca devient plus dur.

Barbuduino: Arduino sur Breadboard & VinciDuino: Clone Leonardo // WR703: Mini-routeur hacké // LauchPad MSP430 et Stellaris // Panda II Arduino-like .NetMF sous VisualC#
RTFC: Read That F.....g Code / RTFD: Read That F.....g Doc / RTFDS: Read That F.....g DataSheet / RTFS: Read That F.....g Schematic / Wot da ya wanna D.I.Y. today ?

Artouste


... Et pour la précision, si ça peut être au 1/1000sec, ça serait très bien !
...
Et Artouste, qu'entends-tu par conception méca bien pensée ? Car je vais être ingénieur méca dans 6 mois. Si tu parles des supports, je ferai des trépieds à partir de tôles alu en 12mm d'épais pour que ça soit du costaud !


en utilisant les seules ressources de l'IDE arduino avec un uno cadencé à 16MHz, il ne faudra pas compter sur une résolution < à 4µs .
...
alors si tu es un futur ingé meca, tu à surement tous les outils/materiaux pour réaliser des bons supports émetteurs/récepteurs:
ils doivent etre stables et offrir une petite capacité de reglages en X/Y (focalisation du faisceau laser sur le fond du tube recepteur)
perso si je devais faire, je mettrais sur les supports recepteurs une indication de bon positionnement/calage = au moins une led signalant
la bonne réception/tenue du faisceau.


Artouste



2) Plusieurs voitures ?
Plusieurs voitures en même temps dans la tranche de 10 m de mesure ?
S'il faut faire de la discrimination, la ca devient plus dur.


Bonjour barbudor
t'es pas à la plage ?  :smiley-mr-green:

je pense plus vu le lien sur le matos commercial, qu'il s'agit de verifier/comparer les performances relatives entre "engins" les uns après les autres.

jihelbi

Tu n'as pas compris le système doppler est forcément "débarqué" sinon il ne marche pas du tout.

JLB

barbudor


en utilisant les seules ressources de l'IDE arduino avec un uno cadencé à 16MHz, il ne faudra pas compter sur une résolution < à 4µs .


Tu peux utiliser le timer en mode capture a la fréquence max. C'est le hard qui capture la mesure donc pas de problème lié aux latences d'interruptions par exemple (tant que la mesure tient sur les 16 bits du compteur du timer).
Barbuduino: Arduino sur Breadboard & VinciDuino: Clone Leonardo // WR703: Mini-routeur hacké // LauchPad MSP430 et Stellaris // Panda II Arduino-like .NetMF sous VisualC#
RTFC: Read That F.....g Code / RTFD: Read That F.....g Doc / RTFDS: Read That F.....g DataSheet / RTFS: Read That F.....g Schematic / Wot da ya wanna D.I.Y. today ?

jihelbi

Sauf avec un ATtiny dont on peut configurer la clock timer à 16 MHz...

Revers de la médaille, sans quartz sa clock est peu précise sur l'oscillateur interne. Il faut donc imaginer un montage avec quartz (prévu sur l'ATtiny) et faire un chip dédié à cela (les ATtiny45 sont à 1,39 € sur Ebay).

JLB

Artouste



en utilisant les seules ressources de l'IDE arduino avec un uno cadencé à 16MHz, il ne faudra pas compter sur une résolution < à 4µs .


Tu peux utiliser le timer en mode capture a la fréquence max. C'est le hard qui capture la mesure donc pas de problème lié aux latences d'interruptions par exemple (tant que la mesure tient sur les 16 bits du compteur du timer).


Voui barbudor  :smiley-mr-green:
mais 16 bits ça ne nous fait que 65536 unités avant débordement  :smiley-mr-green:
et pour la simplicité de réalisation pour un "debutant" , j'en reste là à la résolution de la fonction micros() .

compte tenu des dispersions inévitables de la chaine de mesure , je pense qu'une relative precision intrinseque à ~4µs est déjà pas mal.
Ce qui compte là à mon avis c'est de faire de la comparaison de N échantillons avec la même chaine de mesure, pas de faire de la mesure de vitesse absolue en qualité "labo metrologique"  :smiley-mr-green:

Sinon , j'ai de la source BdT au rubidium étalonnée  en secondaire, mais evidemment là ça va être "beaucoup, beaucoup" plus cher    :smiley-mr-green:

dassault27

Si j'ai bien compris, si j'utilise l'horloge interne de l'arduino, j'aurai au max une précision de 4µs ? Si c'est ça pour commencer, ça serait pas mal ! Et quand je dis plusieurs voitures, c'est chacun son tour afin de voir la vitesse.
Après pour la technologie, je vais faire des trépieds avec des vis de réglages pour régler le X et Y ainsi qu'un faisceau laser pour pointer au bon endroit ! Et est-ce que un émetteur et récepteur IR en 940nm 36kHz pourrait faire l'affaire pour déclencher et arrêter le chrono ? Car d'après les radar de vitesse moyenne, la technologie utilisée est de l'infrarouge mais après quel type, je n'ai pas trouvé !


barbudor

@artouste

On en revient a la confusion entre résolution et précision

Ca ne sert à rien a faire une mesure en soft avec la fonction micros() si derrière la précision de la mesure est entachée d'une incertitude due au soft.
Que ce soit par une lecture de port, même en digitalReadfast() ou sur interruption, tu as une (grosse) incertitude sur la valeur lue qui peut être (bien) supérieure à 4 µs

Avec le mode de capture, plus d'incertitude.
Certes on est limité à 65535 impulsions mais il suffit de choisir la valeur de prescaler qui va bien pour couvrir la gamme souhaitée avec une résolution de 1/65000ème.

Barbuduino: Arduino sur Breadboard & VinciDuino: Clone Leonardo // WR703: Mini-routeur hacké // LauchPad MSP430 et Stellaris // Panda II Arduino-like .NetMF sous VisualC#
RTFC: Read That F.....g Code / RTFD: Read That F.....g Doc / RTFDS: Read That F.....g DataSheet / RTFS: Read That F.....g Schematic / Wot da ya wanna D.I.Y. today ?

Artouste


Si j'ai bien compris, si j'utilise l'horloge interne de l'arduino, j'aurai au max une précision de 4µs ? Si c'est ça pour commencer, ça serait pas mal ! Et quand je dis plusieurs voitures, c'est chacun son tour afin de voir la vitesse.
Après pour la technologie, je vais faire des trépieds avec des vis de réglages pour régler le X et Y ainsi qu'un faisceau laser pour pointer au bon endroit ! Et est-ce que un émetteur et récepteur IR en 940nm 36kHz pourrait faire l'affaire pour déclencher et arrêter le chrono ? Car d'après les radar de vitesse moyenne, la technologie utilisée est de l'infrarouge mais après quel type, je n'ai pas trouvé !



bonsoir
pourquoi veux tu utiliser un (des) émetteur de telco modulé en 38Khz ?
en situation une fois que tu t'es assuré du bon positionnement des faisceaux laser de départ et d'arrivée (détection de réception et validation par rupture) tu n'a besoin de rien d'autre :
le mobile déclenche la chronométrie par interception (coupure) du faisceau au point de départ et la chronometrie est interrompue à l'identique par interception sur le faisceau d'arrivée.
la réalisation effective de ton projet passe plus par une bonne étude mécanique des barrieres que par l'électronique :
L'important là est que tes barrieres soient faciles à positionner (verif de l'alignement rapide) et qu'une fois installée/positionnées elles soient tolérantes aux effets mecaniques exterieurs (vent, chocs, vibrations, ... etc)
cela passe AMHA par une base massive et une élévation indemne de vibrations à hauteur des lasers/capteurs en regard .
je suppose que la hauteur du point de visée est déjà +/- determiné ? , il est de quel ordre par rapport au sol ?


Artouste


@artouste

On en revient a la confusion entre résolution et précision

Ca ne sert à rien a faire une mesure en soft avec la fonction micros() si derrière la précision de la mesure est entachée d'une incertitude due au soft.
Que ce soit par une lecture de port, même en digitalReadfast() ou sur interruption, tu as une (grosse) incertitude sur la valeur lue qui peut être (bien) supérieure à 4 µs

Avec le mode de capture, plus d'incertitude.
Certes on est limité à 65535 impulsions mais il suffit de choisir la valeur de prescaler qui va bien pour couvrir la gamme souhaitée avec une résolution de 1/65000ème.



Bonsoir Barbudor
je repondais en meme temps que toi au topic
Pas de probleme pour ta demo sur l'incertitude du point d'unité de temps , mais à ce stade du projet je crois que l'accent doit plus être mis sur la conception mécanique des barrieres, quel que soit le traitement hard/soft derriere, il faut déjà avoir un TOP depart et un TOP arrivée à "deguster"  :smiley-mr-green:
Une fois ça déjà bien etabli, les interventions des petits genies du code, permettront d'approcher le max de ce qui est approchable en precision/résolution.

dassault27


bonsoir
pourquoi veux tu utiliser un (des) émetteur de telco modulé en 38Khz ?
en situation une fois que tu t'es assuré du bon positionnement des faisceaux laser de départ et d'arrivée (détection de réception et validation par rupture) tu n'a besoin de rien d'autre :
le mobile déclenche la chronométrie par interception (coupure) du faisceau au point de départ et la chronometrie est interrompue à l'identique par interception sur le faisceau d'arrivée.
la réalisation effective de ton projet passe plus par une bonne étude mécanique des barrieres que par l'électronique :
L'important là est que tes barrieres soient faciles à positionner (verif de l'alignement rapide) et qu'une fois installée/positionnées elles soient tolérantes aux effets mecaniques exterieurs (vent, chocs, vibrations, ... etc)
cela passe AMHA par une base massive et une élévation indemne de vibrations à hauteur des lasers/capteurs en regard .
je suppose que la hauteur du point de visée est déjà +/- determiné ? , il est de quel ordre par rapport au sol ?




Question mécanique, j'ai planché dessus avec les faisceaux à une hauteur de 50mm du sol. Pour savoir si les faisceaux pointent bien vers les récepteurs, je prévois de mettre des lasers avec des cibles en face. pour régler en 3D (X,Y et Z), je prévois de mettre les trépieds sur vis avec contre écrous pour être au pil-poil ! Et question poids, avec des trépieds fait dans de l'alu en 12mm d'épais, ça tiendra (par expérience).
Après question méca, c'est bon mais c'est comme je l'ai dit dans des posts différents, je suis complètement largué en électronique et c'est pour ça que j'ai ouvert ce post car je ne sais absolument pas quoi choisir comme type d'infraouge(car d'après moi, certains IR sont brouillés par le soleil...)

barbudor

#27
Aug 14, 2012, 10:53 pm Last Edit: Aug 14, 2012, 10:55 pm by barbudor Reason: 1
Un problème de l'IR c'est que ce n'est pas visible.
Pas pratique pour pointer.
Un laser rouge serait plus pratique.

Les capteurs IR de telco (qui demandent une modulation de 36 à 40kHz suivant les modèles) risquent d'être moins sensible sur du rouge. Mais je n'ai pas d'expérience perso la dessus.

Par ailleurs, une modulation risque aussi d'ajouter une incertitude sur la mesure si la période de modulation est importante par rapport à la mesure (36kHz = 27µs)
Barbuduino: Arduino sur Breadboard & VinciDuino: Clone Leonardo // WR703: Mini-routeur hacké // LauchPad MSP430 et Stellaris // Panda II Arduino-like .NetMF sous VisualC#
RTFC: Read That F.....g Code / RTFD: Read That F.....g Doc / RTFDS: Read That F.....g DataSheet / RTFS: Read That F.....g Schematic / Wot da ya wanna D.I.Y. today ?

Jean-François

A partir de tu peux lire une ou deux page qui t'intérresseront probablement.
Il est question de laser et d'interruptions.
MacBook intel core 2 duo  os X snow Leopard 10.6<br/> eMac PPc G4  os X Leopard 10.5<br/>powerbook G4 os X Leopard 10.5
imac PPC G3 os X Pa

Artouste



Après question méca, c'est bon mais c'est comme je l'ai dit dans des posts différents, je suis complètement largué en électronique et c'est pour ça que j'ai ouvert ce post car je ne sais absolument pas quoi choisir comme type d'infraouge(car d'après moi, certains IR sont brouillés par le soleil...)

Ok
Bon déjà un laser visible en rouge (ou autre dans le domaine visible)  ce n'est pas de l'infrarouge.  :smiley-mr-green:
Tu t'accroche sur l'infrarouge, pourquoi ?  8)
c'est justement là que par construction mécanique le capteur doit être "tubé", pour simple postulat le faisceau laser sera horizontal, il s'agit juste de mettre en condition coaxiale le faisceau laser et sa cible (le capteur photosensible)
Et comme tu va devenir bientot ingenieur, il va t'etre simple de calculer l'angle  d'ouverture d'un capteur diam 6mm positionné en  fond d'un tube diam 6mm, pour une longueur... allez de  50mm  :smiley-mr-green:

Go Up