FORUM MOTARDS IDF | MOTO PARIS ET ILE DE FRANCE

[shijo]

j'ai peut être un bug quelque part. Depuis peu, je n'ai plus que des valeurs MPU bidons pendant quelques temps après le démarrage... Qu'est-ce que je fais de travers?

J'anticipais un peu le truc, d'éventuels gros bugs.... Dont en raison de l'agitation là dedans. Alors j'avais déjà ajouté un watchdog (qui est aussi à revoir un peu...). La TODO list devient:

- 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?
- revoir les timings du watchdog

18:46:31.678 -> MPU Rate was 91.60 samples per sec
18:46:41.685 -> MPU Rate was 91.30 samples per sec
18:46:51.485 -> Radio No peer, so shut off
18:46:51.685 -> MPU Rate was 91.60 samples per sec
18:46:54.886 -> WDog Alive
18:46:55.966 -> GPS SysTime updated via RTC
18:46:56.006 -> SD failed somewhere... since dead.
18:47:01.685 -> MPU Rate was 91.30 samples per sec
18:47:11.686 -> MPU Rate was 91.60 samples per sec
18:47:21.686 -> MPU Rate was 91.30 samples per sec


Il me reste plein de place en RAM et en flash. Par contre, la CPU devrait déjà être pas mal occupée... dont plus du tiers du temps CPU pour le traitement des données du MPU.

Le croquis utilise 95884 octets (36%) de l'espace de stockage de programmes. Le maximum est de 262144 octets.
Les variables globales utilisent 12032 octets (18%) de mémoire dynamique, ce qui laisse 53504 octets pour les variables locales. Le maximum est de 65536 octets.

[shijo]

Je continue

La radio, c'est un peu ch!ant aussi. Ce que je compte utiliser (pour pas cher, nrf24l01+, RF24, RF24Network) n'est peut-être pas prévu pour en envoyer autant à ces rythmes. Ca fait gérer les collisions et les pertes (dont en raison des bruits que font toutes les WiFi dans mon secteur). Puis synchroniser les horloges des CPU (plutôt instables même si ce sont des quarts) pour qu'elles travaillent à peu près en même temps...

Mais ça semble pouvoir fonctionner. Avec un intérêt évident: se passer au maximum de fils dans tous les sens, à poser et à raccorder sur la moto. Par exemple, avec un affichage et des boutons au guidon, et avec le reste n'importe où.

Un truc de plus à finir de débuger et à valider. Dont en raison des décalages dans le temps liés à la radio, qui fluctuent également.

1565193329 Sending dummy packet... ok (took 11.90ms)
1565193330 Sending dummy packet... ok (took 11.90ms)
Packets out : 2153 sent, 3 resent, 0 failed
Packets in : 0 bad CRC, 0 bad NetID
Time synch : 1 sec max diff, current diff is 1565193324(in) / 1565193323(RTC)
1565193331 Sending dummy packet... ok (took 8.94ms)
1565193332 Sending dummy packet... ok (took 9.00ms)
SysTime update via RTC
1565193333 Sending dummy packet... ok (took 8.94ms)
1565193333 Got PACKET_TIME 1565193334 64 max diff 1
1565193334 Sending PACKET_ALIVE... ok
1565193334 Sending dummy packet... ok (took 8.94ms)
1565193335 Sending dummy packet... ok (took 29.66ms)
1565193336 Sending dummy packet... ok (took 8.99ms)
1565193337 Sending dummy packet... ok (took 8.94ms)
1565193338 Sending dummy packet... ok (took 8.94ms)
1565193339 Sending dummy packet... ok (took 8.99ms)
1565193340 Sending dummy packet... ok (took 8.94ms)
1565193341 Sending dummy packet... ok (took 8.99ms)
1565193342 Sending dummy packet... failed (took 43.00ms)
1565193342 Sending dummy packet attempt 2... ok (took 11.90ms)
1565193343 Sending dummy packet... ok (took 11.90ms)
1565193343 Got PACKET_TIME 1565193344 64 max diff 1
1565193344 Sending PACKET_ALIVE... ok
1565193344 Sending dummy packet... ok (took 11.90ms)
1565193345 Sending dummy packet... ok (took 11.90ms)
1565193346 Sending dummy packet... ok (took 8.93ms)
1565193347 Sending dummy packet... ok (took 8.94ms)
1565193348 Sending dummy packet... ok (took 8.93ms)
1565193349 Sending dummy packet... ok (took 8.93ms)
1565193350 Sending dummy packet... ok (took 8.99ms)
Packets out : 2178 sent, 4 resent, 0 failed
Packets in : 0 bad CRC, 0 bad NetID
Time synch : 1 sec max diff, current diff is 1565193344 (in) / 1565193343 (RTC)
1565193351 Sending dummy packet... ok (took 8.94ms)
1565193352 Sending dummy packet... ok (took 8.94ms)

[Muten]

À refaire tes paquets pour corriger le décalage dans le temps, tu risques de te prendre la tête si tu n'as pas déjà une mesure de l'inclinaison fiable.

Je suis plus partant d'une fiabilisation avant d'optimiser avec du sans fil, mais chacun vois midi à sa porte.

Par contre oui, d'avoir l'affichage en satellite sans fil, pas de soucis, c'est distinct de la mesure.

Tu as un dépôt où je peux voir ce que tu as déjà fait ?

Sinon pour revenir à ton besoin d'origine...perso après la tétine : j'ai encore le cale-pied qui frotte avant que ce soit le pot (qui est en bas et qui a déjà frotté )

[shijo]

Je suis allé dans tous les sens, pour voir ce qui pouvait rentrer dans la boite, pour évaluer aussi les difficultés.

Maintenant que beaucoup de choses y sont déjà (batterie, affichage, boutons, carte SD, MPU, GPS, RTC, radio, qui bavarde un peu avec une autre), j'ai de plus en plus de comportements bizarres. Une grosse opération de nettoyage et de reécriture s'impose, quelques réflexions encore également

Je crois que j'ai un ancien compte github... Pour le moment, une partie est par là:
https://github.com/bk4nt/tests/tree/master/MBLogger

Par ici, d'autres brouillons, après un moment à jouer avec deux RF2401L+:
https://github.com/bk4nt/tests/

Resterait à monter ce proto sur une moto pour voir comment le MPU supportera le traitement. Bientôt. Puis si ça ne fonctionnait pas, j'insisterais encore, dont avec une petite mousse pour amortir les vibrations.

Là, c'est encore énorme. Mais en poussant le bouchon, ça pourrait tenir dans un gros paquet de cigarettes. Le truc en haut à droite, avec une radio aussi, il y manque des bricoles et il serait connectable à la prise ODB:

[shijo]

J'ai tout cassé. Voilà

L'idée des threads doit être bonne. Pour faire plusieurs choses en même temps plutôt que séquentiellement avec le modèle "if (now() - last >= interval)", toujours susceptible d'être bloqué quelque part. Pour le moment, j'utilisais ceci, avec des yield(), qui fonctionne bien:

https://github.com/mikaelpatel/Arduino-Scheduler

Mais avec tout dans la boite, c'est finalement instable. Au bout de quelques minutes à secondes, l'affichage (dont les routines prennent beaucoup de temps) est bruité, un peu pixelisé, puis plante... quand ça ne reboote pas (le watchdog). Il se passe aussi des choses étranges avec la couche radio/paquets, même si elle fonctionne bien (il y des delay() dans les sources, interprétés par le Scheduler...). Et le nombre de mesures MPU plafonne, à 80/90 par seconde, avec parfois des oops (encore inexpliqué, ce phénomène).

Un moment, j'ai arrêté le thread affichage, puisque ça plantait. J'avais l'antenne GPS déconnectée (ça envoie des tartines toutes les secondes, à traiter aussi). J'ai vu 100 mesures MPU par secondes... et plus aucun oops.

J'ai donc arrêté des threads, pour voir l'effet. Avec juste la radio et le MPU, ça plafonne encore, à 95 mesures/seconde. Avec juste le MPU, ça monte finalement à 100 mesures par secondes, et il n'y a plus de oops. Juste ces 100 mesures, et essentiellement les temps de transfert MPU via I2C, ça prend environ 0,2 secondes par secondes. Manifestement, un rien ralentit leur rythme... et dans l'ensemble, avec tout dans la boite, ça fini instable.

100 mesures par secondes (sans oops): c'est utile à filtrer postérieurement et pour résoudre d'éventuels problèmes liés aux vibrations.

Au lieu du Scheduler, je vais maintenant tester avec ceci, ChibiOS/RT, une version compatible avec mon Teensy et l'IDE Arduino (pour toutes ses librairies). Ca devrait permettre de gérer des priorités, ce que le simple Scheduler ne permet pas:

https://github.com/greiman/ChRt

Coté bonnes nouvelles, depuis 2 jours, un Teensy 4.0 est disponible (19$, le prix du Teensy 3.0). "Teensy 4.0 Brings 600 MHz Cortex-M7 to the Arduino World"
https://blog.hackster.io/teensy-4-0-bri ... d451477918
https://hackaday.com/2019/08/07/new-tee ... ller-form/

Mais je ne suis pas sûr qu'un processeur plus rapide suffira. Car les goulots d'étranglement se situent sur les entrées/sorties I2C et SPI, leur rythme et le temps que ça bouffe en bloquant la CPU... donc, je vais voir ce que ça peut donner avec ChibiOS/RT.

https://github.com/greiman/ChRt/tree/ma ... les/chCoop
// This example illustrates cooperative scheduling. Cooperative scheduling
// simplifies multitasking since no preemptive context switches occur.
//
// You must call chYield() or other ChibiOS functions such as chThdSleep
// to force a context switch to other threads.
//
// Insert a delay(100) in loop() to see the effect of not
// using chThdSleep with cooperative scheduling.
//
// Setting CH_TIME_QUANTUM to zero disables the preemption for threads
// with equal priority and the round robin becomes cooperative.
// Note that higher priority threads can still preempt, the kernel
// is always preemptive.
//

[shijo]

Pas un morceau sans galères ou choses bizarres... ChibiOS/RT avec encore l'univers Arduino, son IDE et les librairies pourrait être une solution acceptable.

J'arrive enfin à 100 mesures MPU/seconde, et à simultanément 50 paquets radio/seconde (pas besoin d'autant). Le truc curieux maintenant, c'est que j'ai la plupart du temps 100 mesures MPU, mais parfois 99 ou 101... Hier, et d'autres façons, j'avais plutôt 100 mesures par secondes, ni plus, ni moins. De temps en temps 99 seulement, la CPU doit encore parfois être à la traine, occupée autre part...

Radio : 20045 out, 0 failed, 50 packets/second
MPU : 100 samples/sec, 99 min, 101 max, 0 FIFO resets, last roll is 0.12
Radio : 20096 out, 0 failed, 51 packets/second
MPU : 101 samples/sec, 99 min, 101 max, 0 FIFO resets, last roll is 0.12
Radio : 20146 out, 0 failed, 50 packets/second
MPU : 100 samples/sec, 99 min, 101 max, 0 FIFO resets, last roll is 0.12
Radio : 20197 out, 0 failed, 51 packets/second
Stack : 100 740 192 740 52724 272
MPU : 100 samples/sec, 99 min, 101 max, 0 FIFO resets, last roll is 0.10


https://github.com/bk4nt/tests/blob/mas ... biOSRT.ino

[shijo]

Je suis plus partant d'une fiabilisation avant d'optimiser avec du sans fil, mais chacun vois midi à sa porte.

Pour le moment, j'ai plus d'écran. Je n'arrive pas à faire fonctionner le driver avec ChRT, ça plante, au bout de 2 minutes voire 30 secondes, écran noir, puis ça reboote (le watchdog). J'ai perdu un peu de temps là dessus... Le sans fil sera donc une très éventuelle solution, pour afficher les choses autre part

Avec un autre driver mais beaucoup plus basique pour l'écran, j'ai un écran de 3 lignes, le GPS, le MPU (enfin stable, sans oops, et systématiquement à 100 mesures/seconde), la radio... pfff

WDog Alive (since 2.22 hours)
WDog Battery : 4153mV, 0mA, 100%
GPS Got a fix in 41us, 24us, 1813us
GPS 3 10 142ms 12/08/0019 10:38:09
MPU 100/sec, 100 min, 100 max, 1671us, 1678us
MPU 0.11, 6.70 min, 6.29 max
Radio 79824 out, 0 failed, 10pps
Stack 1496(MPU), 916(radio), 268(GPS), 252(display), 448(watchdog), 384(debug) 23952(main) 248(ISR)
Display Alive, lastly sendBuffer took 3127us
GPS 1pps
GPS Got a fix in 39us, 24us, 1813us
GPS 3 10 148ms 12/08/0019 10:38:10
MPU 100/sec, 100 min, 100 max, 1671us, 1678us
MPU 0.12, 6.70 min, 6.29 max
Radio 79834 out, 0 failed, 10pps
Stack 1496(MPU), 916(radio), 268(GPS), 252(display), 448(watchdog), 384(debug) 23952(main) 248(ISR)
GPS 1pps
GPS Got a fix in 27us, 24us, 1813us
GPS 3 10 140ms 12/08/0019 10:38:11
MPU 100/sec, 100 min, 100 max, 1670us, 1676us
MPU 0.11, 6.70 min, 6.29 max
Radio 79844 out, 0 failed, 10pps
Stack 1496(MPU), 916(radio), 268(GPS), 252(display), 448(watchdog), 384(debug) 23952(main) 248(ISR)
Display Alive, lastly sendBuffer took 3105us
GPS 1pps
GPS Got a fix in 26us, 24us, 1813us
GPS 3 10 142ms 12/08/0019 10:38:12
MPU 100/sec, 100 min, 100 max, 1671us, 1677us
MPU 0.11, 6.70 min, 6.29 max

[shijo]

À refaire tes paquets pour corriger le décalage dans le temps, tu risques de te prendre la tête si tu n'as pas déjà une mesure de l'inclinaison fiable.

Je suis plus partant d'une fiabilisation avant d'optimiser avec du sans fil, mais chacun vois midi à sa porte.

J'étais assez confiant. Je viens de tester la partie MPU sur le twin, et malgré de grosses vibrations (j'ai mon assemblage mécanique à revoir, mon proto vibrait sur la moto), les mesures du MPU me paraissaient tout à fait correctes, pas influencées du tout par ce qui se passait dessous.

Le MPU6050 n'est pas des plus rapides ni des plus sensibles. Le plus récent MPU6500 a ses capteurs MEMS plus petits pour une vitesse d'échantillonnage plus rapide et une plus grande précision, lui serait plus susceptible d'être sensible à des vibrations. Je conserve donc ce MPU6050 et ses 100 mesures par seconde.

J'ai probablement un peu de trigo à faire car le boitier n'est pas tout à fait à l'horizontal sur la moto. Et car du fait de mes assemblages mécaniques, l'alignement du MPU avec la moto est quelconque. En circu, c'est largement exploitable, je conserve les valeurs max des deux dernières minutes, soit du temps pour aller lire l'écran après la sortie de virages ou de ronds points.

17.4°, la moto est posée sur sa béquille, c'est le buffer de deux minutes; précédemment en circu, 35.4° max à gauche, 36.8° max à droite:

[Muten]

Plutôt que de la trigo, défini un réglage du zéro relatif lorsque tu appuies sur un bouton / menu...
Plus simple et viable à plus long terme en fonction de tes installations

[shijo]

Plutôt que de la trigo, défini un réglage du zéro relatif lorsque tu appuies sur un bouton / menu...
Plus simple et viable à plus long terme en fonction de tes installations

C'est plus compliqué que ça. Avec la librairie que j'utilise, le MPU à plat (l'axe du pitch), ça va, mais lorsqu'il est positionné en piquant ou en relèvant du nez (l'axe du pitch non à zéro), ça introduit des erreurs dans le roll.

Si je le place à 90° (le pitch), pour 45° en roll, le roll me sort 80°... Et je suppose que monté sur la moto avec un pitch à 4-5°, le roll est également pas très juste.

En l'état actuel, j'ai plutôt roll = fonction de roll et de pitch...

[shijo]

Je suis plus partant d'une fiabilisation avant d'optimiser avec du sans fil, mais chacun vois midi à sa porte.

Pour le moment, je bloque ici, autour d'un problème d'initialisation ou de mathématiques dans la librairie MPU6050:
https://github.com/jrowberg/i2cdevlib/i ... -523924231

Avec pour conséquence, un roll et un pitch erronés dès qu'ils sont tous les deux différents de zéro. Sinon, tout le reste doit pouvoir fonctionner.

PS: je ne sais pas encore comment le MPU6050 va digérer les G, si roll et pitch y seront insensibles ou non... Un BNO080 m'arrive d'ailleurs, un jour. Ce dernier pourrait embarquer des maths plus évolués et distinguer G/roll/pitch.

[shijo]

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."

Qu'il regarde un peu ceci: On a vu précédemment que le gyroscope dérive et l’accéléromètre présente des mesures brusques "parasites". On va donc combiner les 2 en se débarrassant des variations "lentes" du gyroscope (filtre passe haut) et des variations "rapides" de l’accéléromètre (filtre passe-bas). Pour cela, on utilise un "filtre complémentaire". http://gilles.thebault.free.fr/spip.php?article32

Avec ce que je viens de trouver, je crois que c'est vraiment un hasard si les drones bricolés restent en l'air.

Pour le moment, j'en suis dans ces eaux là, encore un peu perdu entre XYZ, ZYX et ZXY: