Jean-François:
En gros l'idée de départ était de faire une mesure avec les accéléros, gyro ou autres tout les 5 à 10 cm.
Avec une roue d'environ 2m de développement et 36 rayons cela fait environ 5,5 cm entre chaque rayon.... donc dans la fourchette de fréquence de mesure que j'envisageais au début (c'est peut-être pas la bonne piste...)
Bonjour JF
je crois qu'il faut que tu fasse là un point d’étape surtout concernant tes capteurs embarqués
Chaque capteur consomme du temps en acquisition/restitution
pour les acceleros/gyro par exemple selon les technos , tu peux facilement avoir un facteur 10
tu devrais déjà faire un tableau type excel de tous tes capteurs avec en regard le "real-time consumption"
Si j'ai bien compris , a part qq infos rafaichies en "temps reel" visualisable dans ton tupperware
tu es plus dans une démarche d'analyse à posteriori ?
Artouste:
je crois qu'il faut que tu fasse là un point d’étape surtout concernant tes capteurs embarqués
Chaque capteur consomme du temps en acquisition/restitution
pour les acceleros/gyro par exemple selon les technos , tu peux facilement avoir un facteur 10
tu devrais déjà faire un tableau type excel de tous tes capteurs avec en regard le "real-time consumption"
Pour l'instant je ne sais encore pas quels capteurs je devrais utiliser, pour la consommation temporelle des capteurs je suppose que cela ne se trouve pas dans la datasheet, il faudra faire des tests ?
Artouste:
Si j'ai bien compris , a part qq infos rafaichies en "temps reel" visualisable dans ton tupperware
tu es plus dans une démarche d'analyse à posteriori ?
C'est exactement ça, cela devrait m'aider (cela reste une supposition) à mettre au point mes châssis, en comparant les valeurs acquises entre chaque modification faite sur le châssis.
Durant ces prises de mesures, l'affichage en RT n'est pas important, pour la mesure de la vitesse à afficher il serait possible de déporter cela sur un autre MC.
Mais pour l'instant, je trouve l'exercice intéressant sur beaucoup de point, c'est le plus important.
Artouste:
je crois qu'il faut que tu fasse là un point d’étape surtout concernant tes capteurs embarqués
Chaque capteur consomme du temps en acquisition/restitution
pour les acceleros/gyro par exemple selon les technos , tu peux facilement avoir un facteur 10
tu devrais déjà faire un tableau type excel de tous tes capteurs avec en regard le "real-time consumption"
Pour l'instant je ne sais encore pas quels capteurs je devrais utiliser, pour la consommation temporelle des capteurs je suppose que cela ne se trouve pas dans la datasheet, il faudra faire des tests ?
Pour le bilan de consommation en temps, ça se trouve pour partie dans les datasheet si sortie numerique (time conversion)
si sortie ana c'est time dependant de la cible
Artouste:
Si j'ai bien compris , a part qq infos rafaichies en "temps reel" visualisable dans ton tupperware
tu es plus dans une démarche d'analyse à posteriori ?
C'est exactement ça, cela devrait m'aider (cela reste une supposition) à mettre au point mes châssis, en comparant les valeurs acquises entre chaque modification faite sur le châssis.
Et ... comment tu qualifie dans ta méthode d’évaluation comparative la precision de l’élément surement le moins fiable de la chaine de propulsion ?
à savoir le ... pedaleur ?
Durant ces prises de mesures, l'affichage en RT n'est pas important, pour la mesure de la vitesse à afficher il serait possible de déporter cela sur un autre MC.
Mais pour l'instant, je trouve l'exercice intéressant sur beaucoup de point, c'est le plus important.
Pour l'imprécision du pédaleur, il y a deux solutions (voire une troisième que je n'envisage pas ) :
Choisir un trajet test avec une descente suffisante évitant de pédaler, ensuite il faut que le pilote se tienne au mieux sur la ligne idéale du trajet (cela se faisait comme cela au technicum de Bienne pour les test de gaz des voitures à toute fin d'homologation, mais sur des rouleaux avec consigne de la vitesse à respecter et rapport à engagé )
Se dire que le pédaleur pilote est suffisament concentré pour avoir toujours la même vitesse à des points donnés (d'où l'importance d'afficher la vitesse en RT.) et suivre une ligne idéale du trajet test.
Trouver un endroit ou je puisse tracer une ligne au sol (qui s'effacerait à la première pluie).
Faire plusieurs fois le trajet test et faire une moyenne.
Jean-François:
Pour l'imprécision du pédaleur, il y a deux solutions (voire une troisième que je n'envisage pas ) :
Choisir un trajet test avec une descente suffisante évitant de pédaler, ensuite il faut que le pilote se tienne au mieux sur la ligne idéale du trajet (cela se faisait comme cela au technicum de Bienne pour les test de gaz des voitures à toute fin d'homologation)
Se dire que le pédaleur pilote est suffisament concentré pour avoir toujours la même vitesse à des points donnés (d'où l'importance d'afficher la vitesse en RT.) et suivre une ligne idéale du trajet test.
Trouver un endroit ou je puisse tracer une ligne au sol (qui s'effacerait à la première pluie).
Faire plusieurs fois le trajet test et faire une moyenne.
ça c'est facile !
sur un point donné , la vitesse est par définition nulle !
bon ! pendant qq semaines il y a eu des questions de posées , mais c'est encore un probleme de GPS en Suisse !
entre points prealablement référencés un calcul de vitesse est envisageable , mais sa precision est déja fonction de la precision de la BdT et de la precision "donnée/accordée" aux points référentiels (inscrit dans un pseudo cercle d'incertitude de rayon r ) .
mais j'ai compris ce que tu veux faire, projet sympa , amuse toi bien
Artouste:
si sortie ana c'est time dependant de la cible
Le breakout qui contient mon accéléro MMA7260QT me fournit des données en analogique, les gyros aussi....
Donc la sortie est influencée par la vitesse du lecteur (Arduino) ?
Artouste:
si sortie ana c'est time dependant de la cible
Le breakout qui contient mon accéléro MMA7260QT me fournit des données en analogique, les gyros aussi....
Donc la sortie est influencée par la vitesse du lecteur (Arduino) ?
c'est toi qui dois gerer ton taux d'acquisition, je crois avoir lu un max de 10Khz pour le sampling rate d'un uno.
ça dépend donc aussi de ton programme et de ce qu'il doit faire d'autre.
de plus ton gyro sort une valeur ana entre 0 et 3.3V , si tous tes capteurs ana sortent en 3.3 tu peux utiliser le 3.3V en AREF pour etre à pleine échelle.
si tu en a aussi en 5V c'est plus ch...t : soit tu prend 3.3V en AREF et tu converti tes capteurs 5V en 3.3
soit tu aura une résolution réduite pour tes 3.3V soit 678 restitué au max
J'ai fait un test en mettant la vitesse dans un tableau à chaque "top" rayons, le temps écoulé depuis le dernier top est également mis dans un tableau.
Tout les secondes, le tableau est inscrit dans la carte SD.
Et ça à l'air de fonctionner, il faut que je vérifie si le nombre de mesures est cohérent avec la vitesse.
J'ai fait un test en mettant la vitesse dans un tableau à chaque "top" rayons, le temps écoulé depuis le dernier top est également mis dans un tableau.
Tout les secondes, le tableau est inscrit dans la carte SD.
Et ça à l'air de fonctionner, il faut que je vérifie si le nombre de mesures est cohérent avec la vitesse.
En regardant mes données inscrites sur la SD, pour 12 km/h, j'ai ~16 ms entre chaque inscription, ce qui me fait ~4ms pour 48 km/h, ça reste cohérent avec mes 250 top/s à 50 km/h XD
L'accélero et les gyros sont en 3.3V, j'ai éventuellement un capteur de pression atmo qui lui est en 5V, mais pas sur que ça me serve vraiment dans cette application .
Autrement le magnétomètre est en 3.3V à 6V, mais fonctionne en i2C :
Features
Grove compatible interface
3-Axis Magneto-resistive type sensors
I²C serial interface
2.0cm x 2.0cm Grove module
1° to 2° Degree Heading Accuracy
Up to 116 Hz Maximum Output Rate
Built-In Self Test
Je suppose que ce qui nous intéresse est ce que j'ai mis en rouge ?
Si c'est le cas, on est out à partir de 24 km/h >>> 120 top seconde (115 >> 23 km/h).
En regard de la vitesse que je rafraichis tout les 6 rayons, je pourrais aussi utiliser ce magnétomètre à cette fréquence, le cap ne va pas énormément changer en 30 cm... et c'est un peu redondant piskon'a les gyros
Jean-François:
En regardant mes données inscrites sur la SD, pour 12 km/h, j'ai ~16 ms entre chaque inscription, ce qui me fait ~4ms pour 48 km/h, ça reste cohérent avec mes 250 top/s à 50 km/h smiley-lol
En fait tu stocke temporairement en tableau les delais entre top et tu enregistre ça une fois par seconde ?
donc tu ne connais pas a priori le nombre de delais à stocker , meme si le max est estimé à 250/" ?
tu enregistre 250 poste à chaque seconde meme si il n'y a pas eu de delai ?
d'autre par il se passe quoi à l'arret ? le delai entre top est infini, ça ne risque pas le debordement ?
(encore que avec un word 65536 ms ça nous fait quand même plus d'une minute entre top)
Jean-François:
L'accélero et les gyros sont en 3.3V, j'ai éventuellement un capteur de pression atmo qui lui est en 5V, mais pas sur que ça me serve vraiment dans cette application .
Autrement le magnétomètre est en 3.3V à 6V, mais fonctionne en i2C :
Features
Grove compatible interface
3-Axis Magneto-resistive type sensors
I²C serial interface
2.0cm x 2.0cm Grove module
1° to 2° Degree Heading Accuracy
Up to 116 Hz Maximum Output Rate
Built-In Self Test
Je suppose que ce qui nous intéresse est ce que j'ai mis en rouge ?
Si c'est le cas, on est out à partir de 24 km/h >>> 120 top seconde (115 >> 23 km/h).
116 c'est un max
50 Hz doit déjà être plus réaliste
15 Hz est l'output rate nominal
une lecture à ~10 Hz voir 5 compte tenu de ce que tu doit faire aussi d'autre doit déjà être pas mal.
Artouste:
En fait tu stocke temporairement en tableau les delais entre top et tu enregistre ça une fois par seconde ?
donc tu ne connais pas a priori le nombre de delais à stocker , meme si le max est estimé à 250/" ?
tu enregistre 250 poste à chaque seconde meme si il n'y a pas eu de delai ?
d'autre par il se passe quoi à l'arret ? le delai entre top est infini, ça ne risque pas le debordement ?
(encore que avec un word 65536 ms ça nous fait quand même plus d'une minute entre top)
J'ai codé ça de cette façon :
void setup(){
attachInterrupt(4, rpm_fun, FALLING);
}
void rpm_fun()
{
rpmcount++;
Top();
//Each rotation, this interrupt function is run twice
// top = 1 ;
}
void Top(){
val[top]=FilteredSpeed;
timeTop[top]=millis()-oldMillis;
top++;
}
void loop(){
...
for (int i=0;i<=top-1;i++){
myFile.print (val [i]);
myFile.print(",");
myFile.println (timeTop [i]);
}
// close the file:
myFile.close();
// Serial.println("done.");
oldMillis=millis();
top=0;
...
}
la fonction top() est appelée lors de l'interruption, si le rayon ne passe pas, il n'y a pas d'enregistrement dans le tableau.
Il faut que je regarde si je peux faire des tableaux à dimensions variables... mais comme ce paramètres et lié à la vitesse, c'est pas évident à trouver un truc qui fonctionne.
Artouste:
En fait tu stocke temporairement en tableau les delais entre top et tu enregistre ça une fois par seconde ?
donc tu ne connais pas a priori le nombre de delais à stocker , meme si le max est estimé à 250/" ?
tu enregistre 250 poste à chaque seconde meme si il n'y a pas eu de delai ?
d'autre par il se passe quoi à l'arret ? le delai entre top est infini, ça ne risque pas le debordement ?
(encore que avec un word 65536 ms ça nous fait quand même plus d'une minute entre top)
J'ai codé ça de cette façon :
void setup(){
attachInterrupt(4, rpm_fun, FALLING);
}
void rpm_fun()
{
rpmcount++;
Top();
//Each rotation, this interrupt function is run twice
// top = 1 ;
}
// close the file:
myFile.close();
// Serial.println("done.");
oldMillis=millis();
top=0;
...
}
la fonction top() est appelée lors de l'interruption, si le rayon ne passe pas, il n'y a pas d'enregistrement dans le tableau.
Il faut que je regarde si je peux faire des tableaux à dimensions variables... mais comme ce paramètres et lié à la vitesse, c'est pas évident à trouver un truc qui fonctionne.
pas un tableau à dimension variable , mais simplement connaitre avant d’écrire sur la sd le nombre de postes à écrire
une variable que tu incrémente à chaque assignation d'un délai et que tu utilise pour connaitre le nombre de postes effectivement utilisés.
Dans la boucle d’écriture tu limite l’écriture dans la sd au x postes effectivement utilisés.
ok
je ne sais pas comment tu structure ton fichier sur la sd, mais intuitivement
en "préambule" d'inscription des "délais top" j'inscrirais aussi la valeur top-1 pour depouillage futur.
mais bon ça c'est à discuter en fonction de l'exploitation du fichier log.
C'est comme pour le camembert , le faire d'abord ! l'affiner ensuite !
