yaaap, un pilote automatique pour bateau

[FilBip]

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€ 

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

Merci de votre attention. Toute contribution sera bienvenue.


tags: mpu9250, autopilot, tillerpilot

[vincenthure]

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

Vincent

[FilBip]

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 : https://github.com/FilBip/yaaap

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

[ChPr]

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

[FilBip]

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 https://github.com/kriswiner/MPU9250.

Cordialement

[ChPr]

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

... 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  ) du système.

Cordialement.

Pierre

[vincenthure]

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é

[vincenthure]

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

[Willy22]

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

[FilBip]

Bonne année
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.

[Willy22]

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 :/

Qu'en pensez vous ?

[FilBip]

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 https://github.com/kriswiner/BNO055 qui n'utilise pas la bib adafruit pour le BNO055.

[vincenthure]

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

https://github.com/vincenthure/sailing-autopilote-arduino

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

[FilBip]

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

[LizaVal]

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 !