yaaap, un pilote automatique pour bateau

Bonjour tous,

je vous présente yaaap (Yet Another Arduino AutoPilot).

Yaaap est un calculateur de pilote automatique pour bateau.
Il est construit autour d'une carte mini pro et le code tient de justesse dans les 32k de mémoire.

L'objectif était de remplacer le calculateur analogique d'un antique pilote pour barre franche Autohelm 2000.
L'ancienne électronique avec un fluxgate fonctionne encore mais est vraiment à bout de course avec des performances très éloignées de ce qu'on peut espérer avec un capteur inertiel IMU 9dof actuel.
Je conservé le vérin électrique qui fonctionne toujours parfaitement.

L'interface est réduite à 3 boutons et un écran LCD.
Il n'y a pas d'interface avec un équipement extérieur (GPS, télécommande smartphone) mais tout est possible...
Les fonctions de calibration et de réglage des principaux coefficients sont intégrées à l'interface.

Il n'y a pas de capteur de position de la barre. La barre est poussée ou tirée en fonction du besoin de correction.
La fin de course du vérin (ou toute surcharge) est détectée en mesurant l'intensité du courant vers le moteur.

Quelques détails
C'est l'excellente librairie RTIMUlib qui gère le MPU9250 et permet d'obtenir un cap compas stable et peu influencé par les mouvements du bateau.
Le code de la librairie RTIMUlib est légèrement modifié pour capturer et sauvegarder le gyroBias après initialisation immobile.
Sur un bateau en mer, il est rare d'être assez immobile pour permettre une bonne initialisation du gyro à chaque allumage. Il en résulte une dérive permanente (drift) qui fait perdre tout l'intéret du gyroscope.
Le calcul de la correction est un PID (asservissement proportionnel/intégral/dérivé) mais sans partie intégrale. L'angle précédent de la barre fait déjà office de terme intégral.
Le moteur est piloté par impulsions longues (10ms mini) voire en continu. Le mode PWM ne donnait pas de bons résultats. Même pour de petits débattements, toute la puissance est nécessaire et mon vérin n'a pas de marge de puissance hélas.

Les composants
1 carte mini pro ATMega328P 5V
1 capteur compas gyro accélérateur : MPU9250
1 capteur d'intensité moteur : ACS712
1 driver mosfet pour le moteur : TB6612FNG (2 canaux en parallèle pour gérer 2Amp nominal et des pointes à 6A).
1 convertisseur DC-DC 12V-5V 500mA mini
1 afficheur LCD I2C 16x2
3 boutons étanches
1 boite étanche
câbles, connecteurs, plaques époxy, etc
Sans les tests et quelques tâtonnements, le coût de l'ensemble est d'environ 30€ :slight_smile:

Le code
L'ensemble des sources pour IDE Arduino et la visualisation avec Processing sur PC/Mac sont téléchargeables sur GiHub.

Merci de votre attention. Toute contribution sera bienvenue.

tags: mpu9250, autopilot, tillerpilot

Bonjour,

J'ai entrepris un projet très similaire.
Ce topic est'il toujours actif?
Nous pourrions mettre notre énergie en commun pour faire un super pilote :slight_smile:

Vincent

Bonjour,
faites bien d'ajouter un message à ce fil. J'ai reçu une alerte mail alors qu'aucun message n'est envoyé quand des messages privés arrivent.
Le projet est toujours d'actualité. Le programme a un peu évolué après une première saison.
Les sources à jour sont toujours accessibles ici : GitHub - FilBip/yaaap: Yet Another Arduino AutoPilot

Mais surtout, tout peut être revu en utilisant un esp32 à la place du petit atmega328 !
Avec l'atmega on peut espérer traiter quelques dizaines d'échantillons par seconde reçus du MPU9250.
Avec l'esp32, beaucoup plus rapide, on peut tenter les 500 ou 1000 échantillons par secondes. Le lissage et la précision sont alors sans comparaison. Plus qu'à coder... Ce que je n'ai pas encore fait :slight_smile:

FilBip:
Avec l'esp32, beaucoup plus rapide, on peut tenter les 500 ou 1000 échantillons par secondes. Le lissage et la précision sont alors sans comparaison. ...

Je ne suis pas sûr de la pertinence des échantillons du MPU9250 à cette fréquence car (doc MPU9250) :

Gyroscope : Low Pass Filter Response Programmable Range 5 --> 250 Hz
Accéléromètre : Low Pass Filter Response Programmable Range 5 --> 260 Hz

ce qui limite à une centaine de Hertz l'exploitation de ces données.

Quand bien même il en est capable, je ne suis vraiment pas persuadé que l'amélioration du lissage à cette fréquence ait une quelconque influence sur la précision alors que le constante de temps d'un bateau est largement supérieure à une seconde.

Cordialement.

Pierre

je n'ai pas expérimenté mais la performance du filtrage s'améliore avec l'augmentation de la fréquence de rafraichissement. Voir les écrits de Kris Winner qui propose de bonnes implémentations pour MPU9250.
Voir entre autres GitHub - kriswiner/MPU9250: Arduino sketches for MPU9250 9DoF with AHRS sensor fusion.

Cordialement

FilBip:
... la performance du filtrage s'améliore avec l'augmentation de la fréquence de rafraichissement. ...

On est d'accord, c'est ce que d'ailleurs, j'ai écrit :

ChPr:
... je ne suis vraiment pas persuadé que l'amélioration du lissage à cette fréquence ait une quelconque influence sur la précision ...

Mais je le répète, lissage/filtrage ne veut pas dire précision.

En admettant qu'un échantillonnage à 10 Hz provoque des résidus de l'ordre de ± 0.5 °, cette valeur sera filtrée par la constante du bateau ( > 1 seconde) et vous aurez au final un résidu de l'ordre de 0.05 ° (soit une vibration de 0.75 mm au bout d'une barre de 1 mètre !! Elle doit en voir d'autres).

Dans ces conditions, un échantillonnage à 500 Hz vous donnera un résidu de 0.01 ° qui ramené au bateau ferait 0.001° : invisible. Certes mais la valeur moyenne sera la même avec les mêmes erreurs de calibration, du temps qui coule, ...

De plus, il est bien connu qu'aller titiller les performances aux extrêmes de capteurs et autres organes d'une chaîne de régulation entraîne systématiquement des instabilités liées aux bruits et différentes résonances inhérents (désolé, la règle du masculin s'applique encore sur les accords :wink: ) du système.

Cordialement.

Pierre

Bonjour,
Comme je vous l'ai dans un post précedent j'ai entrepris moi aussi la fabrication d'un pilote pour voilier :

Voici les choix techniques que j'ai pris ( pas définitf ) :

1 carte arduino nano avec un écran Crystaux Liquide et 5 boutons. Elle gère l'interface utilisateur , la visualisation des paramétres, les menus, la sauvegarde des preset en EEprom et envoie les commandes au deuxième arduino via un port série

1 carte arduino nano qui gère l'asservissement avec la library PID.

1 capteur IMU HNO055 ( magnétomètre 3 axes, accélerometre 3 axes, gyroscope 3 axes ) qui est pourvu d'un processeurs ARM pour calculer en temps réel les angles de Euleurs.

1 pilote de moteur MD10C R3 13 ampéres commandé en PWM et en sens de rotation

1 capteur de courant pour mesurer l'intensité demandé par le moteur

1 régulateur de tension 5 Volts

J'envisage de fabriquer un circuit imprimé pour connecter proprement tout ce petit monde.
Je vais brancher tout cela sur un moteur 12V 160W étanches (IP65) équipé d'un réducteur à vis sans fin qui entrainera ma barre franche via une chaine et un bout circulaire.

L'écriture du code et les essais commencent
mon compte Github est https://github.com/vincenthure/pilote
Je n'ai pas encore eu le temps de lire le code Yaap mais j'imagine que tu as du résoudre pas mal de problèmes.

Cordialement

Vincent Huré

Voici un schéma du projet
J'utilise deux arduinos car je trouve ça plus simple à programmer et plus efficace.
L'arduino qui assure l'asservissement n'a que cela à faire et son programme est très simple.
L'arduino qui sert d'interface utilisateur peux ètre modifier sans risque d'interférer avec l'asservissement.
Vincent

Main-board (1).pdf (28.3 KB)

Bonjour !

Je travaille aussi sur un pilote automatique pour mon voilier (kelt 620) à base d'arduino !
Après une très longue phase de mise au point mécanique (moteur électrique de gonfleur et tige fileté + écrou) mon pilote fonctionne très bien pour fixer la barre et la commander à distance grâce à une télécommande infrarouge.
Concernant l'asservissement, j'ai implémenté un PID sur arduino à partir du cap compas obtenu par un shield BNO055 dont j'ai essayé de faire varier les coeficients sans succès ...

Je pense que l'erreur vient du cap compas qui est faussé par la gite ... Avez vous rencontré ce problème ?

J'utilise la fonction float readEulerHeading(void) qui devrait me retourner le bon cap compas mais je doute vraiment de ce résultat !

Willy

Bonne année :slight_smile:
le plus difficile est effectivement de conserver le cap avec des coups de gite.
Le capteur magnétique est très sensiblement faussé quand le plan change. C'est la raison des calculs de fusion avec les données de l'accéléromètre et du gyroscope.
J'avais conservé la bibliothèque IMU de mon projet; bien qu'elle ne soit plus maintenue, parce qu'elle permettait de régler le "poids" du capteur magnétique dans la fusion.
J'ai obtenu la meilleure stabilité avec un poids très faible pour le capteurs magnétique. Ce qui donne une grande inertie et limite les variations dues au tangage et à la gite brutale.

Plus le bateau est petit, plus le pilotage automatique est délicat en raison de l'instabilité de route par rapport à une grosse coque.

Salut FilBip !

Merci pour la rapidité de ta réponse !

Si j'ai bien compris tu recommande de corriger les données du magnétomètre par celle de l'accéléromètre, c'est bien ça ?

Si oui y a t'il des formules/algorithmes génériques qui permettent d'effectuer ce traitement un peu plus facilement ?

Sinon il y a bien l'option du stabilisateur mécanique en roulis et tangage mais c'est cher et pas très joli :confused:

Qu'en pensez vous ?

Oui, il faut filtrer les données et réaliser quelques calculs pour obtenir une fusion correcte avec filtrage du bruit sur les données récoltées et lissage en fonction des données passées.
Je suis incapable de formuler les explications mathématiques. De nombreux articles existent sur le sujet. Ils sont en anglais en général. Chercher Kalman, Madgwick, quaternions,...
Le BNO055 est doté d'un logiciel de filtrage performant. De meilleure qualité que ce qu'on obtient avec les algorithmes des bibliothèques open-source (FreeIMU ou autres). C'est la raison de son prix supérieur au MPU9250.
Il faut tester le résultat de readEulerHeading() sur table avec du code qui affiche les données pendant qu'on fait bouger le capteur.
Voir aussi GitHub - kriswiner/BNO055: Teensiduino sketch for 9-axis BNO055 motion sensor + MS5637 pressure sensor qui n'utilise pas la bib adafruit pour le BNO055.

Bonjour,
J'utilise aussi un BNO055 et je confirme que l'on peut utiliser son processeur interne pour faire une lecture du cap avec correction tangage / roulis : euler angles. Je n'ai pas encore fais de test en condition réelle mais sur le bureau ça marche.
Si vous voulez jeter un oeil sur mon code il est sur github

J'ai prévu de mettre un lecteur de courant pour limiter l'intensité dans le moteur en cas de blocage.
Cet parti de code n'est pas encore écrite et je ne sais pas encore comment je vais faire.
La premiere option est une mise en veille avec un bip sonore....

Pour la lecture de l'intensité, j'utilise un acs712 avec temporisation en cas de surcharge sauf si inversion du sens de rotation.

Bonjour,

Je découvre ARDUINO depuis 2 mois et j'ai un projet très similaire au votre.
Je veux remplacer un pilote Autohelm ST 3000 qui "controle" un verin LECOMBLE ET SCHMITT 40ST16 à travers un pont en H à base de mofsets et diodes.
Pour l'instant j'ai installé de simples microswitches de fin de course qui agissent sur le pont en H.
Donc je vous lis avec beaucoup d'attention !
Saluts !

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

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

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.

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

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

vincenthure:
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 : Tutorial: How to calibrate a compass (and accelerometer) with Arduino | Underwater Arduino Data Loggers
C'est la méthode que j'ai utilisé jusqu'à maintenant