yaaap, un pilote automatique pour bateau

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 autopilot_computer · pypilot/pypilot Wiki · GitHub 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

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.

Bonjour FilBip,

Votre projet yaaap m’intéresse beaucoup! J'avais un pilote autohelm avec vérin type1 qui tombait régulièrement en panne. J'ai gardé le vérin qui fonctionne (avec embrayage).
A lire les post, le capteur cmps11 semble préférable, mais adaptation difficile ?
J'ai de la peine à trouver les éléments hard (sauf en chine mais avec des longs délais), vous auriez une piste?
J'ai en stock une arduino uno, compatible?
Merci pour votre partage!
Cordialement
Pascal

Bonjour Pako44444, un arduino uno fera l'affaire comme n'importe quel clone d'Arduino.
pour le vérin type 1 il faudra un contrôleur (pont H) plus costaud. Un IBT-3 ou 4 par exemple ou utiliser un driver de type ESC pour moteur classique (brushed) comme le Pypilot sur pypilot.org (à base Raspberry PI).
Il faudra aussi modifier mon code pour passer en mode PWM. Avec mon petit vérin, je n'envoie que des impulsions de 12V mais avec le type 1 plus puissant, il faudrait varier la puissance pour plus de progressivité.

Bonjour FilBip,

Je reviens vers vous après avoir bien progressé mais j'ai un souci avec le driver moteur. J'ai directement utilisé un ibt-2 (que j'ai testé avec une petite routine et qui fonctionne) mais rien ne se passe avec yaaap et le petit moteur que j'ai branché pour une simulation.
Est-ce que vous aviez testé votre programme avec : #define MOTORDRIVER 1 // BTN7970B ?

Quand j'utilise DEBUG j'ai un message d'erreur avec :"lcd.print(tillerCmd);"

Est-ce que vous pourriez m'expliquer un peu KP , KD et deadband ?

Bien cordialement
Pascal

Bonjour,

J'ai relu les messages du forum et trouvé les réponses pour KP, KD,... :))
Le moteur tourne mais j'ai dû remplacer analogWrite(RPWM, HIGH); par analogWrite(RPWM, 255);
Je vais attaquer le PWM.
Et j'ai branché R_EN et L_EN directement à VCC. Est-ce qu'il y a un intérêt à les utiliser?
A quoi sert la variable pulseState ?
Pascal

PS j'ai parfois des erreurs vraiment bizarre de linkage, suis-je le seul?

BDA343:
MERCI. Merci de votre réponse rapide

Test avec MPU9250BasicAHRC retourne :

MPU9250 I AM 73 I shoud be 71

FilBip:
Ooups, la version sur Github a la calibration en commentaire.
Dans setupMenu.ino:
case 4: //Calibration
// compassCalibration();

Bonsoir à tous,
Pourriez vous me donner le lien du dépot MPU9250BasicAHRC sur Github que je ne trouve pas?
Merci.

Bonjour,

J'ai bien progressé, on peut dire que ça marche! Si ça peut aider qlq'un...

Les erreurs de linkage ont disparu en utilisant une version précédente de l'environnement (Arduino 1.8.5)
Le capteur cmps12 est nettement plus stable et facile à utiliser que le MPU9250
voila un lien pour tester le capteur: https://www.robot-electronics.co.uk/files/arduino_cmps12_i2c.ino
En baissant la valeur de COMMAND_INTERVAL à 20 j'ai qlq chose de plus dynamique.

Merci encore à FilBip pour le partage

Bonne navigation