"Intelligence" des pilotes auto

tous les pilotes d'aujourd'hui agissent en fonction de l'état de la mer et reagisent en concequence evidement plus ou moins selon leur perfectionnement ...

Je crois avoir lu (source ?) que les pilotes des VG étaient justement intelligents maintenant : il y a donc nécessité de les installer bien avant la course afin qu'ils "apprennent" à barrer le bateau. Ils se font avoir 2/3 fois sur un passage de vague puis réagissent de manière prédictive eux aussi...

Quelqu'un a une meilleure mémoire ?

1er article : olivierchapuis.blogs.voilesetvoiliers.com[...]vent-1/
Il y en a 5 je crois de mémoire.
C'était en 2009, c'est donc à peu prêt arrivé en version 'grand public' (averti tout de même .... Et avec bon budget ....)

Merci pour ces liens !
 
Ces articles semblent confirmer, au vu de la grosse expertise qui se retrouve derrière, que même dans les domaines très pointus de la régate internationale, les pilotes misent bien davantage sur la très haute précision technique que sur une réelle intelligence prédictive... Tout est fait pour avoir un signal net, très rapide, très clair ...
 
D'ailleurs, l'essentiel du sujet se concentre pour sur la direction du vent. Je ne sais pas à quel point c'est important de s'adapter instantanément à la direction du vent sur un imoca, mais sur un voilier de croisière, ce n'est pas 10° de plus ou de moins qui vont nous faire partir au tas. (bon, empanner, peut-être, et encore, faudrait naviguer sur la fausse panne, et cela ne vaut pas une retenue de bôme)
 
Du coup, j'ai l'impression que la compréhension des trains de vagues ne fait pas trop partie des prérogatives des pilotes. D'ailleurs, si c'était le cas, il n'y aurait pas besoin de réglage du gain, il se le réglerait tout seul en fonction de la houle.
 
En tout cas, je crois avoir bien compris ce que les pilotes savaient faire.

Je ne pense pas que la houle soit suffisament reguliere pour en deduire les moments ou il faut corriger.
Le parrametre le plus importants est le vent apparent, ensuite il faut caller la barre sur un angle moyen autour duquel on fera le moins de correction possible. Ce n'est pas de l'intelligence le pilote ne prend pas d'initiative (heureusement) par rapport a son algorithme de calcul.
Je suis en train de construire un pilote commandé par une tablette via BT, et je me pose la question de comment integrer l'accelerometre dans l'algorithme classique.
Ces capteurs sont tres sensible et je pense que tout simplement ils compensent l'acceleration perçue d'un coté en barrant sur l'autre bord par un algorithme adaptif, c'est a dire qu'il cherche constament a reduire son erreur.

PID = Proportionnel, Intégral, Dérivée. Un correcteur très classique beaucoup utilisé dans l'industrie

surement.
9 axes = 3 x 3 axes, ceux du gyro, acceléro et magnéto.
Le coût est dérisoire, mais ce qui coûte cher c'est la matière grise et l'industrialisation / certification derrière. C'est normal que ce soit si cher, enfin, travaillant dans l'industrie, cela ne m'étonne guère.

Avec les axes X, Y et Z pour les 3 senseurs, je ne vois que 9 axes.
Quels sont les 3 supplémentaires ?

Hep ! Blacknav, c'est pas ca : tel.archives-ouvertes.fr[...]ocument
C'est du lourd, mais je crois que ça va faire la lecture de la semaine.
Si j'avais eu ce sujet pendant mes études d'automatique, je crois que j'en aurai fait mon job...

Quand on tape le nom du thésard dans Google, on voit qu'il maître de conf, et ses publications : haltools-new.inria.fr[...]bli.php

S'il pouvait nous faire une petite ' causerie', ce serait passionnant...

Pour la fiabilité, la simplicité, l'efficacité un régulateur d'allure est une très bonne solution (mais pas pour les bateaux de course actuels).
Les principes des asservissements sont simples.
(Ne pas se laisser mpressionner par les matheux qui adorent se faire mousser avec de belles équations. Comprendre est le plus important que tout. On part d'une idée, après on met éventuellement en musique!

un truc qui agit directement avec le vent et la mer...plus facile a cerner... :pouce:

Réponse à Kaj
Pour connaître personnellement un responsable chez Nke, saches que l'option "vent réel" sur leur pilote facturée 800€ leur a coûté 2ans de salaire d'un ingénieur . Le problème dans le nautisme est que les éléments sont souvent de la haute technologie fabriqué en toute petite série. Ce qui explique souvent les prix exorbitant. Alors ton programme sur un ordi coûtera le même prix car ce n'est pas le support qui compte. Ces programmes sont très compliqués car il faut mettre en place des paramètres variables pour s'adapter à chaque carène: un 60 pieds open ne réagit pas pareil que nos bateaux de croisière. Quand je vois la complexité du mode d'emploi de mon pilote avec les menus, les sous-menus etc.... Mais quand c'est bien réglé, c'est rassurant de pouvoir compter dessus

j'aime bien ce discours sur le vent réel c'est calculé sur la route fond ,pas celle de surface
donc par courant traversier ,le pilote "intelligent" en mode vent a du soucis à se faire .avez vous pensé à un nouveau métier ,psy pour pilote intelligent ?
alain mdr 😸

Très vrai tout cela, d'autant plus que l'option vent réel est à 499 EUR (ce qui est déjà fort cher pour le plaisancier moyen). => www.argo650.com[...]015.pdf

Faire de la R&D à un cout, et pour une 'petite' boîte, jouer avec les gros n'est pas facile du tout.

Mon point de vue:
Je pense qu'en navigation côtière et dans les cailloux, un très bon pilote (malheureusement très cher) est nécessaire, sauf à barrer en permanence.
Au large, un régulateur d'allure semble être une bonne alternative.
Après, toutes les discussions sont ouvertes: on peut naviguer à la
Moitessier ( ce qui ne l'a pas empêché de se mettre 2 fois sur les cailloux si ma mémoire est exact).
Personnellement, je préfère être sur un bateau bien equipé. À partir du moment que l'on a décidé de pratiquer la voile, je pense qu'il faut accepter l'idée que c'est une passion onéreuse et qu'il faut assumer. Je ne suis pas riche, mais pour moi, c'est une raison de vivre et non un simple passe-temps.

Dans mon souvenir, Moitessier s'est mis 2 fois dans les cailloux parce qu'il ne savait pas où il était. Plusieurs jours auparavant, les conditions l'avaient empêché de faire un point sextan correct. De nos jours, le GPS supprime un tel problème.

Pour moi, il faudrait que les pilotes prennent en compte la gîte du bateau. Dans une rafale, le bateau n'a pas encore changé de cap que je suis déjà en train de tirer la barre pour empêcher le lofe. En vent arrière vous remarquerez que c'est globalement la même chose, que ce soit une vague ou le vent qui fait gîter le bateau.

Tu as une source d'information à citer ? Les capteurs 9 axes ne sont utilisés à ma connaissance que pour :
1 - remplacer le fluxgate par le magnétomètre
2 - affiner la réactivité de l'information cap avec le gyroscope.
Quel serait l'impact sur un algorythme de l'information "gîte" ?

Mon ST 2000 ayant rendu l'âme, mon choix s'est porté sur le Raymarine EV 100. J'étais un peu sceptique sur sa capacité à réagir en "3D" calculateur intelligent soi-disant ?
ladesirade4.blogspot.fr[...]he.html
En tout cas, c'est le jour et la nuit à toutes les allures et état de la mer, plus rapide, plus costaud et plus d'embardées intempestives (plus cher aussi).
Je ne fais que de la ballade côtière et mon bateau n'atteint pas les 25 nds c'est peut-être pour cela que le pilote me convient !!!...

Pourquoi ne pas faire un appel à la communauté pour créer ou plutot modifier/améliorer un logiciel libre pour le pilote (je pense par exemple, à OpenCPN....)
La rage des petits drones a apporté plusieurs auto-pilotes pour ces drones sur le marché. Ce sont de petits boitiers légers et bon marchés (60 -120 Euro) qui possèdent accelerometres, gyros, magnétomètres, pression barométrique et même souvent un GPS. Le logiciel à bord (qui est souvent libre "open source") fuse les données et permet de multiples autres fonctions (par exemple ArduPilot). Les données sont transmises sous le format MAVLink et les données les plus importantes peuvent être traduites au format NMEA ...

J'ai émis une suggestion similaire (sous mon autre pseudo) sur le forum de OpenCPN sous la rubrique "Feature Requests", mais elle reste sans réponse jusqu'à présent.
Malheureusement, je n'ai pas de connaissances en matière de programmation pour m'atteler à cette tâche .....

Un auto-pilote de drone réagit très rapidement sans quoi un drone serrait vite à terre, en morceaux (faible poids, dont faible inertie, donc très sensible au moindre soufle de vent, d'ou une nécessité de temps de réaction très rapide, surtout lorsque le drone vole près du sol entre des obstacles qui engendrent, en plus, des turbulences dans l'air)

Un auto-pilote de drone come ArduPilot pourrait commander un auto-pilote de bateau directement si on ajoute, dans son propre logiciele, la transformation du format interne de la commande vers le format de l'auto pilote du bateau p.e. NMEA. Il est probalement possible aussi de transformer un des signaux PPM de l'auto-pilote "drone" en un signal lisible par l'auto-pilote du bateau.

Un PC/tablette est cependant nécessaire pour donner la course à suivre, les WPs, les changement de cap à faire ou autres commandes (principalement changer les paramètres des PIDs du logiciel de l'auto pilote "drone" en fonction de l'état de la mer et des caractéristiques/réponse du bateau). Pour cela, par exemple, on pourrait utiliser une modification d'un logiciele comme "Mission Planner" (également open source) pour commander l'ArduPilot.

Comme BlackNav, je ne vois pas confier la barre à un PC...

Puisque ce fil est de haut vol :

tel.archives-ouvertes.fr[...]ocument

J'ajoute que Marc est un vrai marin, il a collecté les données de sa thèse lors d'une mini transat.

Le dernier né de NKE integre un mode 'surf' !!
Juste sorti, ici: www.nke-marine-electronics.fr[...]cessor/

Masse, autonomie d'un drone ... Il ne faut pas penser "drone" (jouet)
Les autopilotes de drone sont très sofistiqués.
Les capteurs internes (une centrale inertielle, GPS, baromètre), des entrées et sorties analogiques et digitales pour plusieurs capteurs additionnels et servos ou moteurs, plus un processeur et de la mémoire pour faire tourner le logiciel … pour 100 euros . . . Un tel pilot peut commander le moteur d’un gouvernail sans passer par un PC/tablette (ni même par le calculateur d’un autopilote car il le remplace par quelque chose de bien mieux)
Les logiciels libres (open source) sont dérivés sous plusieurs formes (multicoptères, avions, planeurs, bateaux, véhicules terriens). Une bonne partie des logiciels est formée par des boucles feed-back (désolé, je ne trouve pas le bon mot français) de type proportionnel-intégration-dérivation (PID) dont les paramètres peuvent être facilement changés pour prendre en compte inertie (masse) du bateau et l’état de la mer … Le logiciel peut également développer pour corriger les données du vent (ref NKE). Il faut bien sure avoir un PC ou une tablette pour modifier le logiciel et ses paramètres mais une fois réglé, le PC/Tablette n’est utilisé que pour introduire le données de navigation (waypoints, zone à ne pas traverser, etc . . ). Les entrées digitales peuvent être utilisées pour les commandes immédiates par simples boutons-poussoirs (mettre le pilote en fonction/en attente, ajouter +/- 1°, +/- 10° …).

En somme, si quelques programmeurs bénévoles s’y lancent, un logiciel libre peut être (relativement) facilement modifié pour obtenir un pilot qui pourrait être comparé au NKE (à une toute autre échelle de prix).

Pas de neurones disponibles avant 2017. Et je ne connais pas de langage orienté temps réel / industriel.
Mais on peut commencer le process, faire des POC, ...

Pour feedback c'est rétrocontrôle

Hello,
Pour ceux que ça intéresse, j'ai bien avancé dans mon projet. J'ai fini l'implémentation sur la carte Arduino Mega, passé le GPS en 20Hz, et terminé l'implémentation du PID en mode cap magnétique par l'IMU 9 axes et également le mode GPS en utilisant le cap du GPS haute fréquence.
Pour l'instant, j'ai implémenté l'IHM de contr?ole en C++/Qt sur PC, pour la phase de mise au point.
J'ai également trouvé le vérin chez un constructeur allemand : caractéristiques mécaniques de couple et vitesse angulaire ramenées à la mèche de safran comparable à un vérin LS hydraulique, contacteurs de fin de course, capteur de position analogique pour l'asservissement de l'angle de barre, étanche IP65. C'est un peu cher, dans les 500 €, mais je pense que ça vaut le coup !
Reste à faire : trouver le contr?oleur moteur 2 quadrants pour l'interface de puissance du vérin, réaliser l'asservissement de position du vérin, et mettre tout cela dans le bateau pour tester ! (au printemps...)
@+

Hydraulique ou électrique, le vérin ?

La carte MD03 (ref 0661-1 chez Selectronic) permet en pont en H 50V 20A. Elle est compacte (113x50) avec radiateurs et très bien réalisée. Plusieurs mode de programmation (doc sur internet).

En essai ou pour le fun, ou en dépannage, pour contrôler la puissance moteur, ou en dépannage on peut très bien utiliser quelques diodes et 2 relais auto. Bien que les mosfets aient beaucoup de vertus, en prévoir de rechange. L'étage de puissance reste un point faible, surtout s'il reçoit un ordre idiot.

Prédictive, c'est vite dit, surtout de nuit.
Très souvent alors que le train de vague semble régulier, on reçoit soudain et de façon aléatoire une vague beaucoup plus forte (cela est aussi vrai sur de très grandes distances observé par satellite), .

On y est, en série, en automobile avec les dispositifs de reconnaissance de panneaux et ceux qui identifient une personne ou un autre véhicule/vélo/etc pour la gestion des feux à LED.

Une utilisation automobile, c'est rapidement de la très grande série et donc une chute verticale des coûts.

Je pense qu'un dispositif capable de déterminer à 200 km/h dans un environnement encombré que le "machin" visible est un cycliste et de commander une extinction des LED correspondantes à l'angle occupé par le cycliste avant même que l'éclairage soit une gêne pour lui, devrait être en mesure de distinguer une vague.

Ca ne sert a rien de voir venir, on ne doit pas corriger avant la vague. Un barreur manuel corrige juste avec la sensation de monter descendre. D'autre part un bon barreur corrige peut. Pour cela il y a des algorithmes tres performants et finalement assez simple.

Up pour Blacknav, tu en es ou de ton développement ?

les pilotes utilisés par les coureurs intègrent pas mal de paramètres
force et direction du vent ,cap à suivre ,vitesse du bato ,angle de barre
avec un accéléromètre il ne prédisent pas l'avenir ,il suffit de leur adjoindre une boule de cristal ,mais ils sont extrèmement réactifs
leurs algorithmes intégrent les mouvement du bato et ils agissent en conséquence .
mais ceux là ils coûtent les deux bras et un oeil
alain

Salut,
C'est sympa de s'intéresser à mes travaux ! :-)

J'ai fait mes premiers tests en embarqué, mais en voiture. Tout fonctionne bien, mais c'est facile, rien n'est piloté pour l'instant... Le but est de voir comment se comportait l'IMU 9 axes et le GPS haute fréquence dans un véhicule qui bouge.
Eh c'est bluffant. Le magnéto capte bien le cap, malgré la cage de faraday de la voiture. L'acceléro permet bien de corriger l'orientation de la boîte : le cap est trouvé peu importe l'orientation du capteur. Bref, comme un tel portable.
Le GPS haute fréquence est également très réactif. Je l'ai réglé à 20 Hz pour le micro-contrôleur. Et je récupère les infos à peu près à 10 Hz sur le PC distant. A peu près, parce que j'ai implémenté un système non temps réel de question-réponse entre le PC et le micro-contrôleur, pour pouvoir y mettre un système de watch dog simple. L'avantage est de limiter la charge CPU au minimum dans l'embarqué.

J'ai sourcé trois vérins industriels, en faisant une comparaison des principaux pilotes auto existant sur le marché. J'en ai trouvé trois.

Prochaines étapes :
- ajouter un lecteur SD à l'embarqué pour pouvoir logger les infos à 20Hz directement dans l'embarqué.
- ajouter une liaison Wifi pour remplacer la liaison RS232 qui va vers le PC.
- implémenter l'étage de puissance pour l'asservissement du vérin.

...Et faire des tests pour de vrai ! :-)

Pour rebondir sur l'aspect "prédiction" : j'imagine qu'il est possible de prévoir une houle régulière à partir de l'analyse des flux du gyro. Un phénomène oscillant (houle par l'arrière) peut-être modélisée avec une FFT, par exemple. J'ai hâte de pouvoir faire des essais en mer pour voir ce que ça donne.

Pour l'instant, j'ai implémenté un PID. Le but est quand même d'avoir un pilote fonctionel alors avant d'essayer de modéliser quoi que ce soit, je pense qu'améliorer le PID par un "autotune-PID" permettrait déjà d'adapter les coefficients P, I, D en fonction de la dynamique du bateau : lent, rapide, etc...

Après, il y aura le mode vent à faire. Encore pas mal de boulot ! :-)

J'ouvre un fil pour ne pas polluer celui-ci, sujet connexe.
www.hisse-et-oh.com[...]mea0183

Salut,

Au final, je vais finir par ouvrir un blog ! ^_^
J'ai avancé : j'ai trouvé le vérin et je suis en train de mettre en place le Wifi.
Le vérin :
Pour trouver le bon vérin, j'ai fait une comparaison des pilotes sur le marché, en ratissant large : ST2000, TP32, mais aussi les

vérins pour pilote in-board l Lecomble&Schmidt, Raymarine, etc...
En prenant les caractéristiques indiquées dans les notices, j'ai calculé pour chacun ce qui importe réellement au final : le couple

en N.m et la vitesse angulaire en °/s, ramenés à la mèche de safran. Les différences sont importantes comme on peut s'y attendre.

Ci-dessous, le résultat de mes calculs, qui permet de comparer les performances mécaniques. A prendre avec des pincettes, car je me

suis peut-être trompé dans mes calculs d'une part, et les données sont issues de manuels utilisateur ou de revendeurs sur internet.
Ma référence est le ST2000, car c'est le pilote que j'utilise, et c'est lui que je vais observer pour voir si j'arrive à faire

mieux ! :-)
Dans la liste ci-dessous, je donne les vitesses angulaires en (°/s) puis le couple exercé sur la mèche de safran en (N.m).

barre franche :
ST2000 : 7 / 345
TP 32 : 7 / 391
SPX5 (maintenant EV100) : 10 / 293
inboard :
Raymarine T1 : 6.4 / 737
Lecomble & Schmidt ST16 : 4 / 855
Jefa : ? / 1000
(je n'ai pas trouvé de données de vitesse pour Jefa)

On voit grosso-modo, que les pilotes de barre franche semblent plus rapides que les in-board, mais que ces derniers sont deux à

trois fois plus puissants. Il est admis que les pilotes in-board sont plus performants que les pilotes de barre franche. Il

semblerait donc que le critère du couple soit prépondérant sur celui de la vitesse.
Partant de ces chiffres, je me suis mis en quête d'un vérin électrique industriel, avec la contrainte qu'il soit mécaniquement

compatible avec les fixations de mon actuel TP2000. J'ai envie de pouvoir faire du plug&play : mon bricolage VS TP2000, et passer

de l'un à l'autre en 10 secondes.

Le vérin que j'ai finalement trouvé (et j'ai galéré...) vient d'un fabricant allemand : DriveSystemEurope. Comparé à mon ST2000, il

sera un peu moins rapide : 6.5°/s contre 7°/s, mais beaucoup plus puissant 250 kg de poussée, contre 77 kg pour le ST2000. Ramené à

la mèche de safran, mon vérin allemand devrait avoir les même caractéristiques qu'un Lecomble & Schmidt ST16, mais 50% plus rapide.

En effet, le vérin allemand va permettre de faire du 6.6 °/s avec un couple de 890 N.m (4°/s et 855 N.m pour ST26). Je me pose

quand même la question de la solidité de l'accouplement mécanique sur la barre franche. Je crains que la petite tête d'homme sur la

barre franche ne supporte la poussée dans des conditions difficiles. C'est un risque.
De plus, ce vérin est muni de deux capteurs de fin de course et surtout d'un codeur analogique absolu qui me permettra de connaitre

la position de la tige et donc de l'angle de barre. Enfin, il est étanche IP65, ce qui veut dire d'après Wikipedia :
"totalement protégé contre les poussières" et "Protégé contre les jets d'eau de toutes directions à la lance (buse de 6,3 mm,

distance 2,5 m à 3 m, débit 12,5 l/min ±5%).". Je l'ai commandé, maintenant il faut attendre 8 semaines !

Pour patienter, je me suis attelé à l'interface Wifi. Pour l'instant, je communique avec le microcontrôleur via une liaison RS232. Et je suis en train d'intégrer ESP8266 pour remplacer le fil par une liaison Wifi. Ca commence à fonctionner, mais il faut encore que j'encapsule mon protocole dans les commandes AT comprises par l'ESP8266.

Voila, où j'en suis. Maintenant, il me faut attendre le vérin...

Salut BlackNav
Chuis pas matheux, pourtant c'est ainsi que j'ai compris les graphiques.
Sur l'axe horizontal, le couple,
sur l'axe vertical gauche, le temps de butée à butée (250mm de rayon pour le LD-12)
sur l'axe vertical droit, la consommation en Ampère.

Salut,
Je n'ai pas trouvé de notion de vitesse dans la doc de Jefa. Si tu en trouves cela m'intéresse !
Et tu as raison, pour augmenter la vitesse angulaire, il suffit de diminuer le rayon, à vitesse tangentielle constante. Ma contrainte est que je ne veux pas modifier les points de fixation dans le cockpit et sur la barre, pour pouvoir faire une comparaison directe avec mon brave ST2000.

Que de compétences nécessaires pour faire tout ça .... Bravo, veinard.

Merci ! :-)
voila une question intéressante : la notion du déplacement du bateau pour les pilotes. Je pense qu'il s'agit d'une approximation commerciale pour permettre une sélection approximative. Seules importent les notions de couple et de vitesse. Un voilier de 15t avec un safran très compensé ne sera pas plus difficile à barrer qu'un bateau de 2t avec aucune compensation.
Lecomble & Schmitt en parle très bien là :
www.ls-france.com[...]couple/
...et on voit que la notion de déplacement du navire n'intervient pas.

Merci, superbe document, bien écrit en plus

Salut,

Je remonte ce fil pour ceux que ça intéresse. J'ai pas mal progressé depuis !
Le pilote commence à fonctionner. Mais je vais changer de capteur 9 axes pour passer à un module MPU-9250 qui coûte beaucoup beaucoup moins cher, et est plus efficace que le module que j'utilise acutellement. Je l'ai reçu, il faut que je l'intègre maintenant.

La liaison Wifi fonctionne bien. Je implémenté une trame NMEA avec toutes les infos pour le debug et je génère aussi du flux NMEA standard à partir des infos des capteurs intégrés. Ca fonctionne bien sur iSailor. Du coup j'ai aussi implémenté un mulitplexeur NMEA, qui permettra de connecter une girouette et le flux NMEA de l'AIS pour tout avoir en Wifi.

J'ai ajouté à tout cela un capteur de courant et un baromètre. Le capteur de courant pour servir de détection de butée mécanique et éviter de tout exploser en faisant forcer le vérin. Le baromètre pour générer une trame NMEA standard et implémenter un "détecteur de tempête" (détecter une baisse brutale du baro et déclencher une alarme).

A faire pendant les longues soirées d'hiver :
- intégrer le nouveau capteur 9 axes.
- refaire des essais en mer
- ajouter un lecteur de carte SD pour avoir la fonction boîte noire
- ajouter des modules d'interface RS422 pour gérer des flux NMEA en entrée et en sortie.

L'idée au final est de faire un "boat brain".

c'est extrèmement intéressant ..
quand est'il de l'ecu qui fournit un courant proportionnel à la vitesse de déplacement du vérin en fonctions des données fournies par le capteur d'angle de barre ,le flushgate et le compas magnétique
et ceci pour ajuster la vitesse de correction et le couple nécessaire
au déplacement du safran ?????
avec le même pilote et le même vérin ,la réactivité et la consommation
seront différentes suivant le bato qui en est équipé .
sur mon boat j'ai un vérin robertson prévu pour un voilier jusqu'a 14m
et 12t mini .avec un ghp12 garmin
le mien ne fait que 9m et 5.5t en charge

finalement je me rend compte qu'il fonctionne mieux que le 4000w que j'avais avant et consomme moins .
.
les données de vitesse et de poussées sont les maxi que peut fournir le vérin si on l'alimente directement avec une batterie ce qui n'est pas le cas du calculateur .
alain

Bonjour !
Je fais un UP sur le forum pour avoir des nouvelles de ton pilote Blacknav !
Depuis pas mal de temps je fabrique moi aussi un pilote automatique pour mon bateau, le but étant de limiter les coûts au maximum.
J'en suis à 150€ et du point de vue électrique et mécanique tout fonctionne ! Actuellement je bloque sur le réglage du PID, avez vous surmonté cette difficulté ?
Quelle est la fréquence d'échantillonnage de ton programme ?

Willy

Moi je vous tire mon chapeau les gars :pouce:

Salut Liza !
Tu peux nous donner plus de détails sur ton montage ? Quel genre de servomoteur utilise tu et quel traitement appliques tu à l erreur ? (PID ? Ou simplement proportionnel ?)
Sur quel bateau l as tu testé ?

Bonne journée,
Willy

Bon, pour ceux que ça intéresse, voila où j'en suis :

je n'ai pas travaillé dessus depuis un bon moment. Et au fil du temps, j'ai ajouté des fonctions : interface wifi, baromètre, GPS haute fréquence, mesure de courant, etc...
Concernant le PID, j'ai un vrai phénomène d'instabilité, enfin je pense. J'ai une belle courbe de résonance... Mon algo de PID prend en entrée le cap du bateau, corrigé par le capteur 9 axes. J'ai donc une lib qui fait l'hybridation des 3 capteurs (magnéto, accéléro, gyro) pour sortir un cap précis et réactif. Ensuite, l'algorithme calcule l'erreur par rapport à la consigne et applique dessus les coefficients P, I et D, avec les notions d'intégrale et dérivée associées. La grandeur de sortie qui en résulte est alors envoyée à l'étage de puissance qui commande le vérin sur la barre franche. Mais c'est très très instable. J'ai essayé d'appliquer différentes méthodes de réglage, mais ce n'est pas convaincant. J'ai fait mes premiers essais sur un plan d'eau calme, au moteur, sans les voiles. Ça fonctionne à peu près, le pilote tient à peu près son cap, mais cela reste très instable. Et en tout cas, très en-deça des performances de mon ST2000.
Je me suis mis à potasser un peu plus et j'ai relu la thèse sur les pilotes auto dont le lien est donné dans le fil. J'ai aussi passé pas mal de temps sur le site NKE qui contient beaucoup d'information.
Il ressort un élément fondamental qui m'avait échappé : la grandeur de sortie de l'algorithme ne doit pas être la vitesse de sortie du vérin, mais la position du vérin. Quand il y a une erreur de X degrés, on pousse la barre pour donner un angle Y au safran (coefficient P). S'il il ne se passe rien, ou bien si ce n'est pas suffisant au bout d'un certain temps, on va pousser un peu plus (coefficient I). Et enfin quand le bateau revient sur son cap, on va ramener la barre dans l'axe, en ralentissant au fur et à mesure que le bateau revient (coefficient D). C'est bien comme cela qu'un barreur agit.
J'ai donc décidé de casser mon algo, pour essayer de calculer une estimation de la position de la barre en fonction des temps de commande du vérin. Je pose comme hypothèse que l'on enclenche le pilote avec un angle de barre à 0°. J'ai la doc technique du constructeur qui m'indique les vitesses de sortie de tige. Avec l'horloge temps réel de l'Arduino, il "suffit" alors de faire l'intégrale des temps de commande pour avoir une position du vérin. Et c'est cette position calculée qui doit être la sortie de l'algorithme du PID.
Et cela explique pourquoi le capteur d'angle de barre est si important sur les pilotes du commerce : cela permet au calculateur de passer d'un mode "position de la barre estimée" qui reste une estimation imprécise vu l'inertie mécanique par rapport à la précision d'une horloge temps réel, à une "position de la barre mesurée" qui est plus fiable et représente la réalité fidèlement. L'algorithme de conservation du cap est donc bien plus efficace dans le cas d'un fonctionnement avec capteur !

Sur mon vérin, j'ai un capteur analogique qui indique la position de la tige. Je pourrai en faire l'acquisition avec l'Arduino plutôt que d'essayer de calculer la position de la tige par la somme des temps de commande. Mais je voulais être sur le même pied d'égalité que le ST 2000 pour le battre.... ;-) cela dit, ils ont peut-être mis un capteur qui compte les tours du moteur. Faudrait que je l'ouvre pour en avoir le coeur net !

Voila donc où j'en suis. Malheureusement, du fait de problèmes perso, je n'ai pas pu retravailler dessus depuis quelques mois. Mais je vais m'y replonger, car il fait aussi multiplexeur NMEA et je voudrai le relier à mon AIS pour qu'il m'envoie les trames NMEA AIS sur iPad.

...et en attendant, je me suis procuré un très beau régulateur d'allure (Beaufort, modèle Castor). Une merveille de low-tech !

Bref, il faut continuer à faire vivre ce post "intelligence des pilotes auto". Le premier qui arrive à tenir un cap au près dans le clapot à gagné ! :-)

Voisin de votre analyse dont se fait une correction à effectuer avec le gouvernail d'un mobile avec de l'inertie évoluant dans un fluide:
Pour sortir un avion d'une vrille déclenchée il faut immédiatement mettre la gouverne de direction (à fond dans ce cas particulier) du côté opposé à la rotation et maintenir cette position tant que la rotation n'est pas stoppée (temps assez court dans ce cas) que la correction se fasse avant de ramener la gouverne au neutre.
Il y a en effet un retard entre l'action et le résultat.
Pour avoir douté de cette nécessité d'attendre, car ce jour la vrille prenait du temps à s'arrêter, un bon voltigeur s'est tué

Salut Blacknav, ta réponse est passionnante car elle correspond exactement aux problèmes que j ai rencontré avec mon pilote fait maison ! Je suis passé à la mesure de position de verin il y a deux semaines et ça a complètement réglé le problème d oscillations ! Cela dis mon pilote n arrive toujours pas à tenir longtemps un cap et dérive doucement au bout de 5 min... Je pense que ça vient du fait que je prends comme 0 pour la barre la position du vérin au moment où j enclenche le pilote donc avec une barre pas forcément droite ! La modification de code est minime, je vais tester ça ce week-end !
Je vous tiens au courant !
Merci à tous pour vos super contributions !
Willy

Mon système:

Côté méca j ai bricolé un vérin électrique avec un moteur continu 12v de récupération et une tige filetée, pour la position j utilise un capteur ultrasons qui mesure la distance jusqu'à la fin de course.

Côté élec mon étage de puissance c'est un pont en H avec deux relais et une batterie de voiture (qui fait toute l énergie à bord).
Comme contrôleur j utilise un arduino une avec un shield accéléromètre 9axes et un capteur infrarouge pour la télécommande !

Côté info après avoir beaucoup galéré à faire marcher tout les capteurs ensemble (infrarouge et ultrasons demandent tout les deux du vrai temps réel...) j ai un PID basique avec une erreur définie par l écart entre le cap consigne et le cap de l accéléromètre corrigé.

C est à peu près tout !
Ah si je me demandais si ça intéresserait des gens un pilote complètement open source et modifiable avec d éventuel kit ou avec des connaissances basiques ! Le miens me reviens pour l instant à 150€, on pourrait en faire profiter plus de gens !... Enfin si il se décide à fonctionner ! ????

Le mien marche depuis plusieurs saisons...(au moins 3 voire 4;) Une vidéo sous spi ici: photos.app.goo.gl[...]kldZ5x1

Cela ressemble sinon bien à ce qui a déjà été décrit ci-dessus
Arduino, capteur imu 9 axes (magnéto, accéléromètre et gyroscope)
Vérin Home made avec capteur de position par potentiomètre et rouages de démultiplication, vis à billes (plus efficace). La première version n'avait pas de capteur, juste une mesure du temps quand il était enclenché, cela marchait bien aussi

Mes développements récents ont porté sur le calibrage du magneto (enfin au point), un mode virement et tuning des paramètres du pid en live par une appli de téléphone (plus ergonomique que des boutons)

Mon algo (maison) me fait un taux de rafraîchissement de 400hz, ce qui est trop rapide par rapport aux réactions lentes du bateau (possibilité de moyenner pour avoir des fréquences plus lentes aussi)
Je trouve quand même que sur mon bateau qui est plutôt toilé et volage (+bastaques) quand les conditions se dégradent, ça reste moins efficace qu'un bon barreur.

J'ai l'impression que le pid souffre du retard de l'effet de la barre sur la correction (particulièrement visible à faible vitesse) et me demandais finalement si les solutions du commerce utilisaient pas justement des asservissement plus sioux...

L'arduino a trop peu de mémoire pour faire des approches plus statistiques mais si il a des pistes intéressantes, il existe d'autres puces plus puissantes pour tester ça

À suivre

Il n'y aucune différence conceptuelle entre un système bouclé analogique et le même traduit en numérique.
Les amplificateurs opérationnels analogiques permettaient à faible cout et

suite: à faible cout, à action immédiate sur les paramètres, de faire de très belles simulations. En 1960 Le simulateur de vol de "Caravelle" était purement analogique.
Il n'y avait pas ou peu de numérique sur Concorde
L'inconvénient de l'analogique est éventuellement l'imprécision relative et surtout la dérive inéluctable,
résolue par la transposition en numérique, depuis qu'on dispose d'échantillonneurs, de convertisseurs et de calculateurs accessibles à la hauteur du problème à traiter, tout le reste revenant au programme.
En 1970 le simulateur de Boing 727 était purement numérique.

P: c'est un coefficient qui agit sur la différence entre le cap que tu veux suivre et le cap que suit le bateau. En gros, plus l'écart de cap est important, plus le coup de barre est important.

I : coefficient appliqué à la somme des erreurs enregistrées. En gros, si le coup de barre donné par P n'est pas suffisant au bout de "x" secondes, alors I va en remettre une louche. Il continuera d'en ajouter tant que l'écart de cap ne diminue pas.

D : coefficient appliqué à la vitesse de réduction de l'erreur. En gros, quand P a donné un coup de barre, et I a rajouté des louches pour que ça réagisse, alors D calme le jeu pour pas que la barre revienne trop vite et le bateau empanne et vire de bord.

Bon, n'oublions pas que le PID est un algorithme d'asservissement très utilisé, mais assez basique. Je pense que les pilotes modernes utilisent des algo bien plus complexes.

A noter qu'un régulateur d'allure n'utilise que P, et ça fonctionne bien, paraît-il (pas pu tester le mien encore).

Euh Karnaugh?

Un PID n'est peut être pas suffisant, De vieux souvenirs reviennent en tête, avec des asservissements avec anticipation. J'ai oublié pas mal de choses, mais il,y a de la littérature sur le sujet.
Le chapitre 9 de ceci peut éventuellement apporter des infos à ceux qui veulent bien se replonger dedans... sitelyceejdarc.org[...]NTS.pdf

Ben, la différence, c'est qu'un drone est extrêmement réactif, parce que ses moteurs sont puissants et qu'il est léger.
Par rapport à sa réactivité, on pourrait peut-être considérer qu'ils ne sont pas super stables non plus, mais c'est largement suffisant.
De plus, s'ils sont dans un milieu instable (l'air, ca bouge tout le temps, et pas qu'un peu), ils sont dans un milieu tout à fait imprédictible.
Alors qu'un pilote, s'il pouvait analyser le train d'onde, il pourrait savoir où il se trouve, et "voir" la vague arriver.
C'est cela mon message initial : je tournais la barre avant que la vague ne fasse changer le cap.

L'air, ca reste relativement un fluide en mouvement. J'ignore comment faire intervenir la densité du milieu, et l'inertie, mais ca me parait pas si éloigné...

while True:
if cap <> consigne:
agir ():

A la place de la deuxième part puis je avoir une côte de boeuf?

je déterre ce fil avec un article sur les pilotes "intelligents" du VG
voilesetvoiliers.ouest-france.fr[...]c1492f8

Pour ceux qui veulent le même, c'est 15k€! ;-)

Et surtout: le gain de vitesse est de 3 à 4%, soit autant que celui apporté par les foils, pour un coût 15 fois plus faible (500 k€ une paire de foils, 30 k€ le pilote de l'IMOCA).
En plus, une modification du paramétrage est moins cher que le remplacement des foils.

En plus, il y aurait la possibilité de faire des "évitements de l'élan" en cas de découverte d'obstacles sur la route à moins de 200 m.

Les systèmes météo n'ont jamais permis aux leaders de s'échapper vers l'avant... Dalin, Bestaven ont été en tête très très longtemps et pourtant ils finissent juste devant tout le monde. A chaque fois, ils se sont retrouvés devant des murs...
Les 3 à 4 % sont peut-être mesurés sur d'autres navigations ?

Et un autre élément intéressant, si je peux me permettre, est que le vérin semble moins travailler sur Madintec, ce qui semble améliorer la fiabilité.

Hello
Enfin un fil intéressant...
@Blacknav: tu en es où dans ton développement ?

Aaaargh, tu ne voulais pas coder une ‘tite boucle d’asservissement par modèle inverse, histoire d’anticiper les réactions ? Ils embauchent chez NKE ...

J’en aurai bien fait mon boulot, mais maintenant c’est trop tard, j’ai décroché de ces développements. J’ai lu qu’ils cherchaient des tronches pour développer les futurs versions. Ils font aussi appel à des thésards...

C'est NKE qui a la pression.....