yaaap, un pilote automatique pour bateau

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

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+

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

faut juste modifier libraries/RTIMULib/RTIMUMPU9250.h pour remplacer

define MPU9250_ID 0x71

par

define MPU9250_ID 0x73

Et retester :)

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

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

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é :frowning:
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.

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

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

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.

Magnifique, Il me faudra quelques temps pour assimiler ces informations qui sont très claires, merci encore. Pour le pont en H, le Tb6612 supporte OK le vérin ST4000 (qui est proche du ST2000 avec 2,5A en blocage) Mais le TB6612 chauffe BEAUCOUP . Pour éviter sa protection thermique qui ne prévient pas , et comme je dispose de plusieurs modules ,j’ en installerai 2 ou 3 en || (avec »stackable header » ). Après ... Pour l’instant je préfère monter les marchés une par une.

Mais A quoi correspond le. « *18/10 » ?

Le 18/10 est une simple astuce pour éliminer des valeurs trop basses. J'évite les impulsions de moins de 20ms.

Si la formule était pulseWidth = abs(tillerCmd) * 2 le résultat irait de 0 à 200.

Avec la formule pulseWidth = 20 + abs(tillerCmd) * 18/10 le résultat va de 20 à 200.

Si la commande est nulle, on ne passe pas par là et le vérin reste en standby.

C’est clair. Enfin il me reste à comprendre un peu plus (donc à y travailler ) , puis construire la version réelle. Mais vous m’avez permi de bien progresser. MERCI. BD

Bonjour, Ayant écrit précédemment que le TB6612 chauffait beaucoup avec mon vérin ST4000, je me dois de corriger cette information qui est fausse. En effet il y avait une inversion D7 D8 … Après correction, cela fonctionne beaucoup mieux. Je suis très Impressionné par ce minuscule TB6612 NG !

En ce qui concerne setupMenu.ino, et après plusieurs essais, une solution donne un bon résultat. Ce n’est théoriquement pas correct, et je ne comprends pas réellement pourquoi cela fonctionne, mais cela fonctionne. ligne 91 ‘u’ par ’d’ ligne94 ‘d‘ par ‘u’ ligne 153 ‘d’ par ‘u’ ligne 156 ‘u’ par ’d’ Peut-être avez-vous une solution plus élégante ?

Cordialement BD

l'ordre des boutons 1/2/3 ou up/set/down est modifiable en fonction du montage en boitier.

Il est possible de changer l'ordre des boutons à plusieurs endroits. Soit échanger les connexions physiques sur A1, A2, A3, soit échanger A1 et A3 dans le code, soit changer le code dans upClick() et downClick()...

Merci. Mais mon problème était d’obtenir un comportement homogène: Bouton de gauche « descent » et bouton de droite « monte » à chaque niveau du menu. Or ce n’était pas le cas avant modification et je ne l’explique pas ? Les modifications apportées ne sont pas logiques... mais fonctionnent ? Il doit y avoir des ++ et - - antagonistes quelque part. Enfin, en attendant la livraison de pièces qui me manques , j’experimente avec des Kp et kd divers (jusqu’a 100 ) et commence à mieux comprendre le PID. A suivre

bonjour a tous ,

je viens de trouver votre forum tres interessant. je planche aussi sur un projet similaire . j'ai rencontré une partie des memes probleme que vous . j'ai en partie resolus certain point .

comme capteur de magnitude , j'utilise un cmps11 ==> pas de probleme de stabilité a la gite . comme pont h j'ait un ibt2 ==> aucune chauffe . je dois en + gerer un clutch , le verin est un type 1 .

je pense m'inspirer du yaaap pour ce faire .

y a t-il un interet a utiliser un accelerometre et le gyroscope vu qu'il n'y a pas de deviation avec la gite sur mon capteur ?

Le cmps11 semble intéressant et résout le gros problème de filtrage, fusion etc pour obtenir ce cap compas. Il fait tout le calcul de fusion avec son propre gyro et accéléromètre. Mon yaaap fonctionne mais reste perfectible. Si je devais partir de zero aujourd'hui je commencerais par essayer le pypilot (pypilot.org). Installable sur un Raspberry Pi Zero (moins cher que le cmps11). Voir https://github.com/pypilot/pypilot/wiki/autopilot_computer ou pypilot.org Il utilise un mpu9250 mais ce serait sans doute plus simple (et un poil plus cher) avec un cmps11.

Bonjour à vous tous, je termine la lecture de votre projet YAAAP en diagonale...et ne comprends pas votre choix de PA qui utilise uniquement le cap magnétique...un peu comme un barreur me direz vous. Vous constatez des erreurs et souvent cumulatives...alors pourquoi ne faites vous pas appel à une carte GPS de type OLIMEX

https://www.olimex.com/Products/Modules/GPS/MOD-GPS/

qui comporte une bonne antenne avec transmission de la trame texte NMEA sur liaison série...pour les erreurs COMPAS, utilisons les satellites ou les étoiles non ? à vous lire. Votre projet est passionnant ! Gilles

Ce pilote n'utilise pas seulement le cap magnétique mais la fusion des infos compas-accéleromètre-gyroscope. Si tu fait un tour sur toi même, pour le gps, tu n'auras pas bougé. Quand une vague pousse l'étrave de quelques degrés, il faut réagir à la barre avant de détecter un changement de route. C'est primordial en voilier. Le gps est pertinent dans le logiciel ou la centrale de nav pour transmettre le cap au pilote.