yaaap, un pilote automatique pour bateau

[vincenthure]

Je me dois d'apporter une correction concernant mon précédant post.
J'ai vanté les mérites du BNO055 en tant IMU car il intégre un processeur qui est capable de faire le calcul pour délivrer un cap compensé par le gite ( mode fusion ).
J'ai fais fabriquer un circuit imprimé pour intégrer tout ce petit monde et faire des essais plus précis. Je mes suis rapidement aperçu que les résultats n'était pas à la hauteur de mes espérances.
1/ le BNO055 dispose d'un système de calibration automatique et cela pose des problèmes car il ne fonctionne pas correctement. Il est impossible de le débrayer car il tourne en tache de fond et envoi des messages indiquant que la calibration n'est pas stable.
2/ Quand la calibration est bonne il faut sauver les datas dans les eprom de l'Arduino et les récupérer quand on rallume l'appareil pour éviter un long process de calibration. Je n'ai pas réussi à faire fonctionner cela correctement.
3/ d'après des discussions sur des forums il semble que le BNO055 ne soit pas adapté au mesure en mouvement, car la vitesse de déplacement du capteur degrade la precision du cap en mode fusion!
Bref, j'abandonne et je me tourne vers Adafruit Precision NXP 9-DOF Breakout Board - FXOS8700 + FXAS21002. Il ne dispose pas de processeur pour faire de calcul c'est donc Arduino qui doit s'en charger. l'avantage c'est que l'on a la main sur programme.
Adafruit propose cela : Adafruit_AHRS
Je vous tiens au courant
Vincent

[LizaVal]

Bonjour,

Bien lu le pb de BN 00 55.
De mon coté, je n'arrive pas à faire fonctionner mon MPU 6050, alors je ne suis pas prêt de vous rejoindre !
Au moins je sais envoyer un message sur le forum !
Saluts et Bonne Année.
Joël

[ozolli]

Bonjour,

Je ne suis pas sur un projet de pilote auto mais sur celui d'une centrale de navigation que je fais évoluer cette année après 3 ans sans y toucher.

J'ai testé le BNO055 et je confirme, comme beaucoup, qu'il souffre de son auto-calibrage très perfectible.
En l'état, sur un voilier, c'est inutilisable !

J'attends un Adafruit Precision NXP et un Adafruit Feather M0 pour tester ce 9-DOF. J'ai l'intention de l'utiliser avec la librairie NXPMotionSense de Paul Stoffregen et pas celles d'Adafruit.

https://github.com/PaulStoffregen/NXPMotionSense

Mon projet original : https://github.com/ozolli
Il n'est pas à jour avec les développements actuels mais je le ferai quand j'aurai avancé sur le NXP.

[vincenthure]

Je continue mes tests et la programmation avec le capteur NXP FXOS8700 / FXAS21002C.
J'ai rencontré pas mal de difficultés mais maintenant ça avance bien.
Voici comment j'ai résolu mes problémes:
le capteur est connecté avec un arduino (un mini)
j'utilise les librairies Adafruit correspondante aux capteurs et le Adafruit_Sensor-master
j'utilise le filtre   Madgwick contenu dans la librairie Adafruit_AHRS_master
J'ai effectué la calibration avec le logiciel MotionCal ( mettre le serial à 115200 )
J'ai reporté les valeurs dans mon sketch
Et ça fonctionne correctement
Une loop prends environ 7 millisecondes ce qui donne une fréquence de rafraichissement d'environ 140 hz, qu'il ne faut oublier de spécifier dans le filtre.begin() du setup.
Le systéme est très réactif et très fluide mais en valeur absolu la précision du compas n'est pas terrible.
C'est pour ça que je compte vérifier mon COS ( course over ground ) avec un capteur GPS qui calcul le cap entre 2 points successifs.
Les autres fonctions du pilote sont gérés par un autre arduino ( PID, bouton, affichage ).
La communication entre les deux arduino se fait ainsi:
une impulsion "low" est envoyé sur la pin 2 de l'arduino qui s'occupe du capteur.
Il génere alors une interruption qui envoie sur le port serie (soft)  la valeur du "yaw" en faisant une conversion float to bytes.
J'éspere que j'ai été clair
Vincent

[ozolli]

J'ai effectué la calibration avec le logiciel MotionCal ( mettre le serial à 115200 )
(...)
Le systéme est très réactif et très fluide mais en valeur absolu la précision du compas n'est pas terrible.

Est-ce que tu as effectué le calibrage avec le capteur en position définitive dans le bateau ?

Les masses métalliques environnantes (soft iron, hard iron) ont une influence primordiale dans le calibrage.
Pendant le calibrage c'est le bateau qui doit tourner, pas le capteur dans le bateau.

D'autre part, les librairies Adafruit ne tiennent pas compte des corrections à apporter à l'accéléromètre. C'est la raison pour laquelle j'opte pour la librairie NXPMotionSense.

Une autre alternative est d'utiliser la méthode de Merlin avec son logiciel Magneto. Voir ici : https://thecavepearlproject.org/2015/05/22/calibrating-any-compass-or-accelerometer-for-arduino/
C'est la méthode que j'ai utilisé jusqu'à maintenant

[BDA343]

Bonsoir,
Pas de doute , c'est Yaaap qu'il me faut.    Cela correspond exactement à mon projet .   
Très beau travail et un code beaucoup plus beau que celui que je peu écrire moi même,   ( ! Admiratif et reconnaissant)
Mais mes essais avec plusieurs nano / UNO et 3 Mpu9250 9265 etc buttent toujours au même endroit:
le code « freeze » après INIT ***.   Puis plus rien ?
Le Mpu9250 retourne l'erreur 6.
  (Semble ne pas pouvoir récupérer les paramètres EEPROM)

Ce message pour prise contact

Merci

[FilBip]

Bonjour,
le code retour -6 est dû à un mauvais identifiant de MPU9250.
voir dans le code de la méthode RTIMUMPU9250::IMUInit() dans le RTIMUMPU9250.cpp de la librairie "
"
    if (result != MPU9250_ID) {
         return -6;
    }
"
Le MPU9250_ID attendu = 71 (voir RTIMUMPU9250.h).
Je préconise de faire un test unitaire avec juste l'arduino et le mpu avec un programme de test minimal qui écrive toutes les étapes sur le port série pour valider la bonne initialisation de la communication arduino-mpu.

A+

[BDA343]

MERCI.  Merci de votre réponse rapide

Test avec MPU9250BasicAHRC retourne :

MPU9250 I AM 73 I shoud be 71
MPU9250 is on Line...
X axis .....   
.....
MPU9250 initialized for active data mode...
AK8963 I Am 48 should be 48...
Ak8963  initialises for active data mode...

Donc en effet il s'agit probablement de l'adressage I2C incorrect avec mes 92-65 (chinois)  et mon GY-91 MPU9250

Soit il me faut modifier des  RTIMUlib...  (mais un peu d'aide ne sera pas inutile )
Soit vous me communiquez la référence exacte de votre sensor 9250 et son distributeur .  Si cela fonctionne pour vous , Cela ira très bien pour moi.
Cordialement. BD

[FilBip]

faut juste modifier libraries/RTIMULib/RTIMUMPU9250.h pour remplacer
#define MPU9250_ID                  0x71
par
#define MPU9250_ID                  0x73

Et retester

[BDA343]

Ok et cela Fonctionne !     Magnifique et encore merci.
En fait j'avais déjà fait à plusieures reprises ces modifier sans succès ?
D'où Mon appel à l'aide.

Mon erreur.     (Si cela peu servir à d'autre)
 est d'avoir sauvegardée la bibliothèque dans un sous direction à côté ...
avant de modifier le fichier RTIMPU9250.h .

Erreur car la compilation ne prenais pas en compte la version modifiée du fichier ... 

A suivre. 
Cordialement

[BDA343]

Bonjour , 
Mon projet Yaaap progresse tranquillement et ma compréhension de votre code aussi.   (Mais m'impose lectures et recherches en parallèle car je ne suis clairement pas au niveau )     
Fonctionnement ok sur plaques d'essais ...  Sauf la calibration du capteur
8 horizontal ou vertical ... qui semble sans effet.
 Le Lcd montre «  5. Calibration »     8 et 8 et 8 , Mais pas de offset ?     Il semble que MPU9250 n'entre pas en mode Calibration.
Avez vous une suggestion ?

Aussi , pour info, les boutons 1 et 3 me semblent inversés dans le sous menu choix des actions , mais cela est plus simple .
Cordialement   BD

[FilBip]

Ooups, la version sur Github a la calibration en commentaire.
Dans setupMenu.ino:
      case 4: //Calibration
//          compassCalibration();
        break;
Il faut enlever "//" en début de ligne... Désolé
La calibration dure jusqu'à l'appui sur le bouton du milieu.

J'en profite pour ajouter un mot sur la sauvegarde des paramètres (option menu 6).
Il y a 2 calibrations. Celle du compas (en faisant des 8 ) et celle du gyroscope.
Par défaut, le gyro du mpu9250 est calibré à chaque démarrage (calcul gyroBias dans la lib RTIMULib). Sur un bateau, le démarrage doit être possible avec un MPU en mouvement. Il faut alors éviter ce calibrage.
Lors de la première sauvegarde sur EEPROM, le calibrage est écrit en EEPROM. Ensuite il est lu en EEPROM et non recalculé au démarrage. Jusqu'à un éventuel reset EEPROM (option 6) qui le remet à zéro et autorise un nouveau calibrage gyro.

[BDA343]

Merci.    C'est bien clair.
Une semaine de pause dans mon projet Yaaap pour cause de mise à sec de Christelle pour antifouling.
Mais je reste déterminé.
A suivre ...
Cordialement   BD

[BDA343]

Bonjour ,
Retour au projet, une petite question:  Yaaa.ino ligne 318.
int pulseWidth = 20 + abs(tillerCmd) * 18 / 10; // Higher command, longer pulse (20 to 200ms).   A quoi correspond le. « *18/10 » ?

Aussi si vous avez une petite explication pour ajuster la réactivité de la commande qui me semble lente même à 200ms. (sur ma table à vérifier en usage après réalisation réelle).   
De même le virement de bord ne semple pas réagir , Le cap commande prend bien +- 100 mais la commande vérin ne suit pas.

Aussi , il me semble que le TB6612 souffre beaucoup (vérin ST4000 dans mon application) , alors ils seront plusieurs dans la réalisation finale, en parallèle et empilés.
Merci

[FilBip]

Le mode classique de variation de vitesse consiste à faire varier le voltage en le découpant (PWM).
Mon vérin de ST2000 n'est pas très puissant et j'ai été déçu par mes premiers essais en mode PWM. J'ai opté pour des impulsions en 12V mais de durée variable (de 20ms à 200ms ou en continu).
Si ma commande est calculée à 50%, au lieu d'envoyer 6V (12 x 0.50), j'envoie 12V pendant 100ms.
Pour une commande à 100%, la durée de 200ms se traduit par 12V en continu jusqu'au calcul suivant. Avec un recalcul environ toutes les 200ms.

Avec un vérin plus puissant, il faut sans doute revoir tout cela et passer en mode PWM classique. un voltage faible pour de petits écarts et pleine puissance pour des écarts conséquents.
Il faut alors un autre driver pour le moteur les petits TB6612 sont limité à 1A par canal, soit 2A au total.
J'avais testé un BTN7970B avec succès mais une inversion de voltage fatale m'a fait essayer les petits TB6612 qui sont suffisants pour mon besoin. Le BTN est ancien mais en baisse sur ebay (chercher BTS7960B H-bridge, env 7$).

Le coeur du calcul est ici
  cmd = Kp * headingError + (Kd * deltaError) * 1000 / deltaTime;

La commande (-100 à 100) est la somme de l'erreur de cap et de la variation de l'erreur par le temps avec des coefficients Kp et Kd pour le réglage.
Kp est le coefficient "proportionnel" qui permet de régler l'influence de l'erreur de cap.
Kd est le coefficient pour la variation de l'erreur.
Quand l'erreur se réduit, le deltaError s'inverse, le bateau revient vers son cap et la commande doit déjà tendre à s'inverser.

J'étais parti d'un calcul PID mais le résultat n'était pas bon. De manière empirique, j'ai abouti à ce mode avec commande calculée sur des valeurs lissées sur 200ms.

Il faut augmenter Kp et Kd pour augmenter le gain et la réactivité, respectivement sur l'écart et sur la variation de l'écart.