FORUM MOTARDS IDF

#HDJ

snowride a écrit:

Miwik a écrit:

shijo a écrit:Sur une moto sans tétons aux cale pieds, on devine comment qu'on va un peu trop loin?

Si t'as rien qui peut frotter, les pneus devraient te prevenir en commencant a glisser

Sachant que tu as des pneus qui décrochent progressivement et d'autres qui décrochent sans prévenir ça dépend des modèles

Ca continue à me chiffonner. Et comme je ne voudrais pas découvrir que j'étais aux limites en me retrouvant le cul au sol, je vais essayer de faire autrement. Avec un data logger, pour mesurer ce qui se passe, l'angle, angle max droite/gauche, et puis tant qu'à faire, vitesse et d'autres choses.

Pour le moment, c'est pas gagné. Au cours de premiers tests, l'écriture sur la carte SD (bruit sur le bus SPI) me pourrissait la réception GPS. Maintenant, avec cet autre proto, c'est la lecture de l'accéléromètre (bruit sur le bus I2C) qui me pourrit le signal GPS...

Ca existe tout fait, ce genre de trucs, et qui ne soit pas trop cher?

Miwik a écrit:

Echtélion a écrit:Je compatis...
La , tu n'as plus qu'à attendre un miracle....

Qu'il la quitte ?

Un U solide sur la moto et ça pourrait suivre?

Je suis sur que tu as deja tous les composants necessaires dans ta poche... ton smartphone.
Et qu'il existe surement une appli qui te le dira, ou au pire, comme apparement tu as du temps, ca sera toujours plus rapide de la dev que d'assembler toi meme ton truc.

Si vraiment tu veux savoir l'angle max de ta moto, j'aurais plutot procede comme ca :
tu montes sur ta meule pour que les suspensions se tassent, tu fixes des sangles pour les laisser a ce niveau de charge, tu penches ta moto jusqu'a ce que quelquechose touche et tu mesures l'angle.

Mais sinon, arretes de te prendre le choux pour des conneries et va rouler

Storm a écrit:Finalement, le motard est une petite nature.

Vers midi, je suis descendu de la moto. Mon cuir noir était chaud, chauffé par le soleil. Mon casque noir devait être chaud aussi. Et sur la route, ça brassait juste un air chaud. Une expérience dans un sèche linge devrait être assez similaire.

Edit... On va tous mourir! Que signifie alors cette vigilance rouge pour canicule? Le site de Météo France stipule que lors de pareil événement, "chacun d'entre nous est menacé, même les sujets en bonne santé". Les températures pourraient battre des records historiques ce jeudi à Paris, journée la plus chaude de cet épisode caniculaire.

Miwik a écrit:Je suis sur que tu as deja tous les composants necessaires dans ta poche... ton smartphone. ... comme apparement tu as du temps

Le téléphone enverrait tout "dans le cloud" et m'en retournerait de la pub

J'ai fini par trouver. Après des heures, que c'était ni les alims ni les bruits des bus. Je ne vais plus rouler beaucoup avant fin août, ça va me laisser du temps encore

Miwik a écrit:Je suis sur que tu as deja tous les composants necessaires dans ta poche... ton smartphone. ... comme apparement tu as du temps

Pour moi c'est surtout qu'à part en scotchant ton appareil à la moto....ba c'est l'angle du bonhomme qui est mesuré et pas de la machine

shijo a écrit:J'ai fini par trouver. Après des heures, que c'était ni les alims ni les bruits des bus. Je ne vais plus rouler beaucoup avant fin août, ça va me laisser du temps encore

Hello,

Je suis preneur de l'identification de la source des perturbations, car je suis en train de me faire un Alfano + captures infos + compteur maison (je posterai ça sur le forum).
Je pars sur la base de ce mec : http://dawa.panik-po.com/ (avec qui j'ai des contacts, mais j'attends mes derniers composants pour finaliser).

Pour les problématiques de perturbations sur des capteurs "loin", je vais passer par câble réseau pour profiter du plombage.

Dans ton cas, le capteur 9-axes me sembles tellement pas loin.
Peut-être que tu devrais faire un nettoyage "logiciellement".
Après tout tu ne prends pas 50° en une fraction de seconde....du coup si ta nouvelle valeur pour un axe est trop éloignée de ta précédente valeur, ignore là.

Ça serait ma piste si tu as toujours des soucis.

Muten a écrit:Je suis preneur de l'identification de la source des perturbations, car je suis en train de me faire un Alfano + captures infos + compteur maison (je posterai ça sur le forum).
Je pars sur la base de ce mec : http://dawa.panik-po.com/ (avec qui j'ai des contacts, mais j'attends mes derniers composants pour finaliser).

Pour les problématiques de perturbations sur des capteurs "loin", je vais passer par câble réseau pour profiter du plombage.

Première chose que je vois sur ce site, c'est un Arduino ou de cette famille et un récepteur GPS... plus une carte SD. Puis ça parle de plein de capteurs...

Mon soucis n'était pas les alims ou du bruit, comme me le suggérait le comportement du truc et quelques posts dans des forums. C'était juste un problème de code (que je cherche encore à résoudre). Carte SD + GPS + gyro + ... ça fait beaucoup de choses ou de données et d'interruptions qui pleuvent, et ça fait que selon le code, de temps en temps, ou tout le temps, les buffers perdent des données, notamment le ring buffer du port série où j'ai le GPS - avec pour conséquence, un fix souvent non valide.

Oui c'est sur base un Arduino.
Cependant le gars est actuellement en train de séparer pour avoir plus micro-proc en satellite du composant central.

Tu sembles arrivé à limite de capacité non ?
Si juste l'un ou l'autre fonctionne, et qu'en assemblant les 2 fonctionnalités tu as un pb...soit en effet niveau code tu as fait un truc pas très propre soit juste tu n'arrives pas à lire avant que ça soit réécrasé par une nouvelle interruption.

Dispo pour te donner un coup de main / regard extérieur si ça peut t'aider.

L'Arduino et tout ce qui peut graviter autour, avec un grand nombre de librairies à disposition, c'est top pour bricoler. Mais quand deux évènements se produisent alors que la CPU est occupée autre part... J'utilise un processeur rapide, un Teensy 3.2 (72MHz), mais le problème étant celui de la simultanéité d'évènements et d'un sketch globalement séquentiel, ça coince tout de même. J'essaye maintenant de résoudre le problème avec des threads et des yields, ainsi que en droppant des paquets du gyro.

J'ai pu configurer le gyro à 20hz seulement mais dans ce cas, il intègre largement les mesures et met 2 à 3 longues secondes à pondre un angle correspondant à la réalité. 2 à 3 longues secondes: le virage est passé et l'angle max n'a pas été rapporté... Je dois donc l'utiliser à 100Hz (autant d'interruptions) et dropper des paquets pour libérer du temps, pour la réception sans pertes des trames du GPS, lorsqu'elles arrivent. Puis synchroniser l'écriture SD et la gestion de mon afficheur avec les trames du GPS, pour une CPU plus disponible lorsque les trames GPS suivantes arriveront. Une usine à gaz.

Ca doit pouvoir fonctionner, au chausse pied, je vais insister. Car j'étais par moments malgré tout pas loin d'un résultat acceptable. Sinon, il va falloir que j'envisage une solution autour de Free RTOS, mais cela supposerait de reécrire ou de porter des librairies pour mes périphériques. Fastidieux. Un second processeur pour libérer du temps sur le premier, j'y pense pas, ça consommerait encore plus de courant. Ca devra fonctionner sur batterie.

Muten a écrit:Cependant le gars est actuellement en train de séparer pour avoir plus micro-proc en satellite du composant central.

Tu sembles arrivé à limite de capacité non ?

L'aspect séquentiel/mono tâche de la boucle du sketch, toujours occupé quelque part. Je crois que j'ai trouvé la bonne solution, à tester: https://create.arduino.cc/projecthub/fe ... ino-ebc3cc

Muten a écrit:Je suis preneur de l'identification de la source des perturbations, car je suis en train de me faire un Alfano + captures infos + compteur maison (je posterai ça sur le forum).
Je pars sur la base de ce mec : http://dawa.panik-po.com/ (avec qui j'ai des contacts, mais j'attends mes derniers composants pour finaliser).

J'ai progressé. Et puis aussi regardé ce qu'il a fait. Autour d'un Zero, un processeur à 48MHz. Pour lequel il semble exister une version au moins de FreeRTOS (un peu balaise à exploiter). Son sketch est séquentiel, typique Arduino, ses sources sont là: https://github.com/quichedood/DAWA/blob ... WA-5.0.ino

if (gps.available(GPS_PORT)) {
...
faire des choses
...
/**************************************************************
Read 9-axis data
**************************************************************/
bno.getEvent(&event);

/**************************************************************
Read I2C analog values
**************************************************************/
readAdcValues(anaValues); // Takes time to read all values (one voltage conversion = 12.2ms !)

Son projet et sa trame est intéressante. Il n'aurait qu'à en répartir des portions dans des threads, pour profiter de son M0 à 48MHz. Parle lui de ceci, de ce genre de solutions, simples: https://github.com/mikaelpatel/Arduino-Scheduler

Pour le moment, j'évalue encore le truc, avec mon Teensy (à 72MHz). Avec un thread main, et d'autres, séparés, un pour chacun des MPU, afficheur OLED, GPS et monitoring de batterie (pour le moment, je n'envisage pas de me raccorder sur la moto, mais de ne faire qu'un petit truc à poser dessus et sur batterie). Ca semble tenir la route, même avec le MPU à 100Hz. Alors avec le MPU à 20-25Hz, ça devrait finalement le faire facilement.

Le MPU à 20Hz ou plus? Pour remplir un ring buffer et pour en extraire l'angle max de la dernière seconde plutôt que de me contenter d'une valeur d'angle au pif de l'instant. Une seconde, c'est énorme, la moto a eu le temps de pencher d'un côté à l'autre.... ou encore de riper dans la seconde et de pencher autrement.

Ou encore un ring buffer avec les données des 10 à 20 dernières secondes, pour pouvoir regarder l'écran tranquillement, après être sorti de virages:

#define DATA_SAMPLES_ROLL 200
float max_roll[DATA_SAMPLES_ROLL];
int max_roll_recent_pointer;
float max_roll_trip_left, max_roll_trip_right;

roll = 0;
for (int i = 0; i < DATA_SAMPLES_ROLL; i++)
roll = max(roll, max_roll[i]);

En debug, pour le moment, avec le MPU à 100Hz, ça me donne ceci, et je devrais maintenant avoir encore du temps CPU pour assez d'autres choses, dont pour écrire toutes les secondes sur la carte SD. 5 choses ou boucles de type loop() qui s'exécutent en parallèle:

SD card present
OLED display update...
1.64
OLED display update...
OLED display update...
3,2019-07-25 21:51:01.000,***,***,,32,11910,5,225,0,13239,
Have a fix!
Running on mains
SD card present
OLED display update...
OLED display update...
OLED display update...
1.66
Battery : 4151mV, 0mA, 100%
3,2019-07-25 21:51:02.000,***,***,,218,11880,5,233,0,13708,
OLED display update...
Have a fix!
Running on mains
SD card present
OLED display update...
OLED display update...
OLED display update...
3,2019-07-25 21:51:03.000,***,***,,270,11860,5,241,0,14179,
1.66
OLED display update...
Have a fix!


Au lieu d'y avoir un setup() et une loop() uniques, il y en a plusieurs:

void setup() {
SPI.setSCK(14);
SPI.begin();

Wire.begin();
Wire.setClock(400000L);

Scheduler.start(setupDisplay, loopDisplay);
Scheduler.start(setupMPU, loopMPU);
Scheduler.start(setupGPS, loopGPS);
Scheduler.start(setupBattery, loopBattery);


J'ai encore pour projet d'ajouter un émetteur/récepteur radio de type NRF24L01+. Juste une loopRadio de plus. Dont je ne savais pas encore quoi faire exactement. J'aime bien son idée de lire les data DDA et de les enregistrer aussi... un module sous la selle et via radio, hop, dans la carte SD.

Vous feriez mieux de demander à la team modo de vous créer un sujet spécifique.

Echtélion a écrit:Vous feriez mieux de demander à la team modo de vous créer un sujet spécifique.

Je me suis fait la réflexion aussi.
Je pense qu'il faudrait démarrer du post p438523 de Shijo ( votre-humeur-du-jour-t2887-9725.html#p438523 )
Le titre pouvant être par exemple : DIY DataLogger - Connaître son angle, angle max droite/gauche, vitesse et bien d'autres choses.

Le mec de DaWa dans la version 5.2 n'avait pas finalisé justement la.....mesure d'angle....dommage pour toi.

Par contre je sais que même si sur le dépôt ça ne se voit pas forcément (car il dépose des versions finalisées ou presque) il continu de travailler sur une évolution.
Après forcément, plus tu rajoutes d'éléments, moins ton coût est faible.
Pour ceux qui prennent la lecture à ce moment, on parle pour environ de 70-80€ d'éléments qui prennent des infos véhicules (% d'ouverture des gaz, vitesse, freinage, G, rapport engagé, régime moteur, alerte de haut régime...) des infos annexes (angle, chrono sur piste avec ou sans tronçon, température piste, température pneu...) avec un affichage (ou pas selon l'usage) et enregistrement sur carte SD pour analyser à postériori et même dans le cas du mec qui a fait le Dawa affichage des infos sur ses vidéos :



Pour comparaison, un Alfano qui ne fait que le chrono piste se touche aux environs de 200-300€...

Speed Angle, GPS Lap Timer and Data Logger with Lean Angle Measurement, Price: USD 499

J'ai repéré d'autres solutions encore, autour de 1000 à 1500€. Je ne crois pas avoir besoin d'autant. Au départ, je voulais pouvoir analyser simplement l'angle et l'angle max. Avec un petit truc sur batterie, pour ne pas avoir à raccorder des câbles sur la moto. Puis j'ai commencé à ajouter d'autres choses.

Selon ce qu'on veut, ou selon ce dont on se contente, une solution customisée peut ne couter que 30-40€. L'Arduino, c'est modulaire. Un capteur en plus? On ajoute des fils et des lignes de code. Des capteurs en moins car sans intérêts pour soi ou car le budget pour ça est limité? On retire des lignes de code.

Lui aussi s'est fait un truc customisé: https://www.weekend-techdiy.com/motorcycle-datalogger

Oui et puis moi je suis sur des composants aliexpress, je fini avec le tout à 10-15€ (mais j'attends 4-6 semaines pour recevoir)

shijo a écrit:
J'ai progressé. Et puis aussi regardé ce qu'il a fait. Autour d'un Zero, un processeur à 48MHz. Pour lequel il semble exister une version au moins de FreeRTOS (un peu balaise à exploiter). Son sketch est séquentiel, typique Arduino, ses sources sont là: https://github.com/quichedood/DAWA/blob ... WA-5.0.ino

En fait je viens de voir qu'il a posé sa v6 depuis une dizaine de jours : https://github.com/quichedood/DAWA-6.1

Avec son 9 axes sur son propre µproc (Atmel SAMD21).

Par contre en bug connu, il a un souci d'optim actuellement sur l'angle justement ^^
"Angle d'inclinaison : Le composant est présent, l'algorithme aussi mais les valeurs dérivent dans le temps. C'est une problématique récurrente."

Muten a écrit:Par contre en bug connu, il a un souci d'optim actuellement sur l'angle justement ^^
"Angle d'inclinaison : Le composant est présent, l'algorithme aussi mais les valeurs dérivent dans le temps. C'est une problématique récurrente."

Je viens de résoudre un problème, chez moi. Selon mes codes, de temps en temps, ça m'affiche ponctuellement 180°, ou encore, passé 5 minutes, ça ne m'affiche plus jamais que 180°. Ballot. A vrai dire, je ne sais pas si ce sont mes codes, la librairie, ou mon MPU6050. Je viens de le résoudre provisoirement par un mpu.resetFIFO(); bien placé.

Sinon, pour ce que j'en ai lu, la dérive des gyroscopes est tout à fait normale. Et elle est à compenser par les accéléromètres. Pas d'accélération décelée, c'est une dérive du gyro? Soit il recherche ou attend d'autres librairies pour son capteur, soit il teste d'autres capteurs et librairies. Pour le moment, sur un coin de table, j'utilise ceci, sans savoir encore comment ça va fonctionner sur une moto: https://github.com/jrowberg/i2cdevlib/t ... U6050_DMP6

Chapeau bas à ceux qui arrivent a stabiliser durablement des drones avec ces trucs

Muten a écrit: son propre µproc (Atmel SAMD21)

J'ai regardé plus en détail. Le M0 (SAMD21) serait une version simplifiée du M4 (le Teensy 3.2 embarque un ARM Cortex M4). Le M4 apporte des instructions utiles à des maths (floats, etc). Ca pourrait le pénaliser (time consumming) s'il a quelques calculs à faire.

Muten a écrit:"Angle d'inclinaison : Le composant est présent, l'algorithme aussi mais les valeurs dérivent dans le temps. C'est une problématique récurrente."

A voir avec les vrais experts, sinon This vector is used to compensate for the yaw drift of the gyro, just as the gravity vector (which points up btw) is used to compensate for the pitch/roll gyro drift. So gyro + accelerometer + magnetometer will give you the accurate, stable angular position (rotation) of the system. This is the minimum needed and if you remove one sensor the rotation is either not accurate or not stable anymore. https://www.raspberrypi.org/forums/view ... p?t=127930

J'utilise sans plus un truc qui existe pour le MPU6050 et qui m'enchaine:

mpu.dmpGetQuaternion(&q, fifoBuffer);
mpu.dmpGetGravity(&gravity, &q);
mpu.dmpGetYawPitchRoll(ypr, &q, &gravity);

Des briques, des fils, et jusqu'ici, ça va

Bon. J'ai un proto. Bancale, mais qui va m'avancer. Ca va me permettre de tester le gyro sur une moto. Parait que ça n'aime pas les vibrations... Comment ça va se passer avec un mono ou un twin?

La réception GPS ne fonctionne plus. La faute au plastique de ma boite étanche?

J'ai codé la partie carte SD avec les pieds. A revoir et à compléter. L'alim sur batterie qui tient en place avec un peu de patafix, c'est ok. Le gyro c'est la galère:
- à la mise sous tension il retient sa position courante comme étant la référence nul/zéro degré. il y a peut être une option soft...
- s'il reste longtemps sur le même angle, ce nouvel angle fini par être la référence nul/zéro degré. il y a peut être une option soft...
- de temps en temps, alors qu'il reste à plat, il me pond un angle aberrant, 180°, tantôt 180° à droite, tantôt 180° à gauche. à creuser...

Muten a écrit:Oui et puis moi je suis sur des composants aliexpress, je fini avec le tout à 10-15€ (mais j'attends 4-6 semaines pour recevoir)

Va falloir y réfléchir. Ces composants pourraient avoir été mal stockés ou secoués durant le voyage? J'utilise ce genre de composants. Parfois, il m'en arrive dans des sachets plastiques plutôt que antistatiques... Avec mon MPU6050, un composant assez susceptible d'être sensible aux chocs, j'ai du mal.

Je me demande si un MPU6050 d'une autre source fonctionnerait différemment.

Muten a écrit:Par contre en bug connu, il a un souci d'optim actuellement sur l'angle justement ^^
"Angle d'inclinaison : Le composant est présent, l'algorithme aussi mais les valeurs dérivent dans le temps. C'est une problématique récurrente."

J'ai galéré, ces jours passés. Et je n'en ai peut être pas fini avec mon MPU6050. De temps en temps, il me pond des résultats absurdes, alors qu'il est à plat et immobile. Un extrait (je filtre maintenant les résultats):

16:01:09.789 -> Roll oops, was -173.81
16:03:27.795 -> Roll oops, was -0.00
16:04:31.761 -> Roll oops, was -0.03
16:07:26.778 -> Roll oops, was 6.60
16:08:26.786 -> Roll oops, was 120.65
16:08:31.783 -> Roll oops, was -143.42
16:08:36.781 -> Roll oops, was -180.00
16:12:09.797 -> Roll oops, was -130.38
16:14:24.764 -> Roll oops, was -141.72
16:15:50.758 -> Roll oops, was -0.24
16:15:57.755 -> Roll oops, was -1.28
16:15:58.754 -> Roll oops, was 18.81
16:16:15.745 -> Roll oops, was 40.37
16:19:58.780 -> Roll oops, was 125.03
16:20:05.736 -> Roll oops, was -173.59
16:20:29.763 -> Roll oops, was 6.61
16:20:38.758 -> Roll oops, was -154.20


Je le reécris, chapeau bas à ceux qui arrivent a stabiliser durablement des drones avec ces trucs.

Du côté du MPU6050, c'est un gros casse tête, comme j'aime.

Il m'envoie donc assez régulièrement des valeurs bidons, que j'élimine. Plus bas, -29, 180, -4, -165... juste n'importe quoi, facilement détectable car c'est manifestement ponctuel et souvent très éloigné des valeurs lues précédemment.

Mais une moto qui ripe et qui s'incline soudainement autrement, ce sont aussi de nouvelles valeurs très différentes des précédentes. Dans cet exemple, 4.66, 7.14, 9.90°... puis 120ms après, les valeurs lues se restabilisent à environ 22°:

14:52:33.425 -> MPU Roll oops, skipped, was -29.09
14:52:34.184 -> MPU 1 skipped in sec
14:52:35.820 -> MPU 91.50 samples/sec avg
14:52:43.434 -> MPU Roll oops, skipped, was 180.00
14:52:44.314 -> MPU 1 skipped in sec
14:52:45.869 -> MPU 91.30 samples/sec avg
14:52:50.782 -> MPU Roll oops, skipped, was 4.66
14:52:50.822 -> MPU Roll oops, skipped, was 7.14
14:52:50.822 -> MPU Roll oops, skipped, was 9.90
14:52:50.822 -> MPU Reinit roll buffer
14:52:50.902 -> MPU Initialise 22.10
14:52:50.902 -> MPU Initialise 22.08
14:52:50.902 -> MPU Initialise 21.76
14:52:50.902 -> MPU Initialise 21.63
14:52:50.902 -> MPU Initialise 21.83
14:52:50.902 -> MPU Initialised
14:52:51.422 -> MPU 14 skipped in sec
14:52:54.457 -> MPU Roll oops, skipped, was -4.42
14:52:54.457 -> MPU 1 skipped in sec
14:52:55.454 -> MPU Roll oops, skipped, was -165.08
14:52:55.454 -> MPU 1 skipped in sec
14:52:55.854 -> MPU 90.00 samples/sec avg
14:53:05.865 -> MPU 91.70 samples/sec avg

et là ce sont les mesures avec capteur immobile posé sur la table ou en conditions ?
Car il m'est venu à l'esprit les perturbations qui du point de vue du capteur sont parfaitement légitime : les vibrations (et encore pire si tu as peu de cylindres).
Je ne sais pourquoi, mais mon esprit imagine qu'au niveau de la selle arrière il y aurait moins de perturbation moteur/route...

Muten a écrit:et là ce sont les mesures avec capteur immobile posé sur la table ou en conditions ?
Car il m'est venu à l'esprit les perturbations qui du point de vue du capteur sont parfaitement légitime : les vibrations (et encore pire si tu as peu de cylindres).
Je ne sais pourquoi, mais mon esprit imagine qu'au niveau de la selle arrière il y aurait moins de perturbation moteur/route...

Pour le moment, il n'est que sur un coin de table. Mais pour mes tests, je le secoue, je le remue, ou je le laisse tomber (en rotation) pour faire fluctuer plus ou moins rapidement l'angle et vérifier mon code.

En pratique et sur un twin ou un mono, et avec les irrégularités de la route, je ne sais pas encore ce que ça va donner. C'est différent de drones, ça vibre autrement. Si ça pose un gros problème, le capteur pourrait être à suspendre comme on suspend les microphones:



Edit... Là, je l'ai secoué deux fois (du coup, l'inclinaison change trop brutalement, j'élimine car il pourrait s'agir de valeurs bidons), ça se passe plutôt bien, et en gras, c'est le "bruit", des valeurs bidons qui s’immiscent:

21:18:33.052 -> MPU Roll oops, skipped, was 0.00
21:21:07.124 -> MPU Roll oops, skipped, was -10.29 <- secousses
21:21:07.124 -> MPU Roll oops, skipped, was -7.75
21:21:07.164 -> MPU Roll oops, skipped, was -5.68
21:21:07.164 -> MPU Roll oops, skipped, was -3.51 <- très vite, de -10.29 à -3.51, on reprend...
21:21:07.164 -> MPU Reinit roll buffer
21:21:07.204 -> MPU Initialise 3.14
21:21:07.284 -> MPU Initialise 24.22
21:21:07.284 -> MPU Initialise 23.42
21:21:07.284 -> MPU Initialise 23.02
21:21:07.284 -> MPU Initialised, 15 samples where skipped
21:21:57.053 -> MPU Roll oops, skipped, was -4.43
21:22:20.511 -> MPU Roll oops, skipped, was 16.31 <- secousses
21:22:20.511 -> MPU Roll oops, skipped, was 19.45
21:22:20.551 -> MPU Roll oops, skipped, was 22.84
21:22:20.551 -> MPU Roll oops, skipped, was 26.37 <- très vite, de 16.31 à 26.37, on reprend...
21:22:20.551 -> MPU Reinit roll buffer
21:22:20.591 -> MPU Initialise 23.03
21:22:20.591 -> MPU Initialise 21.92
21:22:20.591 -> MPU Initialise 21.44
21:22:20.591 -> MPU Initialised, 5 samples where skipped
21:22:24.022 -> MPU Roll oops, skipped, was 0.00
21:22:27.056 -> MPU Roll oops, skipped, was -4.50
21:26:07.051 -> MPU Roll oops, skipped, was -4.50


Edit... Je vais arrêter de le secouer et de le cogner. J'ai l'impression que ça s’aggrave

21:35:28.000 -> MPU Roll oops, skipped, was -4.58
21:38:11.033 -> MPU Roll oops, skipped, was -4.51
21:38:37.995 -> MPU Roll oops, skipped, was 179.96
21:38:56.027 -> MPU Roll oops, skipped, was -35.80
21:42:42.028 -> MPU Roll oops, skipped, was -4.52
21:42:57.996 -> MPU Roll oops, skipped, was 0.13
21:42:58.994 -> MPU Roll oops, skipped, was 0.00
21:43:51.014 -> MPU Roll oops, skipped, was 45.99
21:46:32.016 -> MPU Roll oops, skipped, was 146.57
21:46:39.003 -> MPU Roll oops, skipped, was -179.99
21:46:59.044 -> MPU Roll oops, skipped, was 159.27
21:47:01.987 -> MPU Roll oops, skipped, was -4.51
21:47:03.976 -> MPU Roll oops, skipped, was 48.36
21:47:05.012 -> MPU Roll oops, skipped, was -0.00
21:47:07.001 -> MPU Roll oops, skipped, was -179.99
21:49:53.031 -> MPU Roll oops, skipped, was 138.27
21:50:45.985 -> MPU Roll oops, skipped, was -179.99
21:50:51.007 -> MPU Roll oops, skipped, was 156.60
21:50:54.996 -> MPU Roll oops, skipped, was -5.84
21:51:11.993 -> MPU Roll oops, skipped, was -4.52
21:51:12.993 -> MPU Roll oops, skipped, was -4.53
21:51:15.989 -> MPU Roll oops, skipped, was 176.03
21:51:20.022 -> MPU Roll oops, skipped, was -65.22
21:51:21.019 -> MPU Roll oops, skipped, was -4.54
21:54:47.973 -> MPU Roll oops, skipped, was -149.37

Encore quelques heures ou jours et des détails à régler...
- déplacer et nettoyer des portions pour la carte SD, ça pourrait maintenant aller vite
- voir plus en détail comment récupérer des trucs par la radio (dont les données ODB), si c'est comme le reste, ce sera pas simple
- envoyer les choses vers la carte SD (plus bien revérifier la fonction "formatage d'urgence")
- relire un peu le tout
- refaire un proto un poil plus fiable ou moins secoué et le monter sur une moto
- ensuite ou avant, vérifier des trucs du côté de la supervision de la batterie
- et toujours ces valeurs bidons du MPU6050... ça ira mieux avec un autre et pas pire sur une moto?

08:05:47.687 -> Main Alive ! Configuring SPI + Wire...
08:05:47.687 -> Main Now checking the battery...
08:05:47.687 -> Bat Setup starting...
08:05:48.727 -> Bat Started
08:05:48.727 -> Main If we get here, battery is Ok
08:05:48.727 -> Main Starting display and buttons tasks...
08:05:48.727 -> u8g2 Setup starting...
08:05:48.727 -> Buttons Setup starting...
08:05:48.727 -> Buttons Started
08:05:49.047 -> u8g2 Started
08:05:50.087 -> Main Now read any config file...
08:05:50.087 -> SDCard Setup starting...
08:05:50.087 -> SDCard Read hello: Bonjour !
08:05:50.087 -> SDCard Read utcoffset: 7200
08:05:50.087 -> SDCard Read radiosecret: ***..**
08:05:50.087 -> SDCard Read radiochannel: **
08:05:50.087 -> SDCard Config read from SD card.
08:05:50.087 -> SDCard We had read hello : Bonjour !
08:05:50.087 -> SDCard Started
08:05:50.087 -> Main Now starting other tasks...
08:05:50.087 -> Main Waiting for other tasks setups...
08:05:50.087 -> MPU Setup starting...
08:05:50.087 -> GPS Setup starting...
08:05:50.087 -> Radio Setup starting...
08:05:50.087 -> Radio Started
08:05:50.807 -> MPU Started
08:05:50.807 -> GPS SysTime set using RTC, to 02/08/2019 07:51:51
08:05:50.807 -> GPS Started
08:05:50.807 -> Main Tasks started
08:05:50.927 -> MPU Initialise 25.68
08:05:50.927 -> MPU Initialise 25.69
08:05:50.927 -> MPU Initialise 25.70
08:05:50.927 -> MPU Initialised, 8 samples where skipped
08:05:51.327 -> GPS Got a first fix !
08:05:51.327 -> GPS Setting time with UTC offset = 7200 seconds
08:05:51.327 -> GPS SysTime now set to 02/08/2019 08:05:52
08:05:51.327 -> SD.begin failed...
08:05:52.327 -> SD failed somewhere... since dead.
08:06:41.637 -> MPU Roll oops, skipped, was -8.90
08:06:47.117 -> Radio No peer, so shut off
08:06:52.317 -> SD failed somewhere... since dead.
08:07:47.117 -> Radio No peer, so shut off
08:07:52.317 -> SD failed somewhere... since dead.