Courants en direct
Remarque : Cette page date un peu, mais les infos restent valables....
J'ai depuis sa rédaction changé de capteur ; il est plus réactif et je l'ai installé très récemment.
En cours de test...
Afficher force et direction du courant en réel sur OpenCPN
N.B. : les illustrations sont agrandissables
Ce travail devra permettre de "lire" en temps réel la vitesse et la direction du courant à l'endroit où se trouve le bateau.
Travail commencé à l'occasion du confinement, j'avais acheté il y a quelques temps déjà, deux capteurs MPU-9250. Autant les tester, au moins de façon virtuelle...
Actuellement, avec le plugin Tactics, il est déjà possible de faire apparaitre la force et la direction du courant en temps réel si et seulement si le bateau est équipé de capteurs spécifiques, style NKE, souvent sur bus NMEA2000.
Dans l'illustration ci-dessous, la vitesse et la direction du courant apparaissent en numérique dans le dashboard horizontal et on retrouve la visualisation de la direction du courant sous la forme d'une grosse flèche bleue sous le bateau.
Ainsi, de façon visuelle on "voit" de suite le sens du courant et sa vitesse, ce qui peut se révéler appréciable dans certains endroits.
____
Cela signifie concrètement que dans le Dashboard de Tactics, différents calculs permettent déjà d'obtenir ces données mais pour cela il faut que le bateau soit équipé d'un loch (pour le STW), d'un GPS (pour le SOG) et d'un anémomètre (pour le AWA) et d'un compas ou PA (pour le HDT).
Pour autant ces données ne suffisent pas, il est également nécessaire d'obtenir le ROLL (càd la gîte) et le PITCH (càd le tangage) pour calculer exactement la force et direction du courant et ces données ne sont fournies que par de rares marques de capteurs (NKE, par exemple, je crois...).
Rapide explication...
On peut déduire la force du courant en comparant la vitesse surface (STW) à la vitesse fond (SOG).
Si SOG > STW, il y a une opposition à l'avancée, le courant est donc contraire. Et lycée de Versailles...
MAIS cela n'est pas suffisant.
La force et la direction du vent, voire l'état de la mer, influent également sur la détermination du courant.
En fait, le bateau en se déplaçant sur un élément liquide est constamment dévié de sa route. Cette dérive subie par la bateau quand il avance à la voile est due à l'addition de la la force du vent (leeway) et de la force du courant (current speed).
Ainsi donc, en tenant compte du cap vrai (HDT) et de la dérive vent (LEEWAY), on peut théoriquement calculer par soustraction la force et l'angle du courant.
Et pour cela on a besoin de connaitre l'angle de gîte et de tangage du bateau....
La phrase NMEA0183 qui sera injectée dans OpenCPN pour fournir le ROLL et le PITCH sera de ce format : $IIXDR,A,-1.0,D,PTCH,A,-5.5,D,ROLL*5D , avec 'A' comme identifiant. N.B. : Pour le dashboard, il faut indiquer PTCH et non pas PITCH dans la phrase NMEA... |
Avec un capteur qui coûte moins de 4 roros, beaucoup de recherches et un peu de travail, il est possible d'estimer le ROLL et le PITCH, et donc - en injectant ces données sous forme de phrases NMEA au dashboard de Tactics (qui fera tous les calculs), d'afficher sur OpenCPN la force et la direction du courant en temps réel !
Le capteur qui permet (entre autres) de calculer le pitch et le roll est le MPU-9250, utilisé notamment pour stabiliser les drones en DIY.
Ces capteurs existent en "no-name" ou de marque, ex: Sparkfun comme ci-dessous...
Le souci avec ce capteur réside dans l'abondance de programmes arduino qui sont à chaque fois un peu différents selon le fabricant du capteur et bien entendu, aucune indication n'est donnée, d'où la nécessité de faire pas mal de recherches et de tests préalables...
Vidéo de ce que l'on peut obtenir...
J'ai réalisé une courte vidéo pour montrer la sensibilité du capteur.
Pour cela, j'ai utilisé une carte NANO que j'ai stockée dans un petit boitier réalisé par mes soins pour d'autres travaux. (par la suite, sur le bateau - vu que d'autres capteurs seront branchés - j'utiliserai une MEGA)
Sur le dessus de ce boitier, on aperçoit le capteur MPU-9250 fixée avec une vis en plastique.
La qualité de la vidéo n'est pas top, désolé, mais on constate malgré tout que les mouvements de gîte et de tangage du boitier sont bien pris en compte par le logiciel 3D sur l'écran du PC.
Egalement (mais je dois affiner ce point), le cap compas correspond puisque la simulation 3D pointe dans le même sens que le capteur quand je modifie son cap...
Il y aurait beaucoup à écrire.
Une remarque toutefois...
De très nombreux codes sont inspirés du code fourni par un certain Kris Winer. Un code que j'ai testé et qui semble fonctionner est le suivant : MPU2590BasicAHRS_I2C (le sketch se trouve facilement avec GoGole)
Mais, dans ce code s'agissant du capteur MPU-9250 de Sparkfun, il y a une erreur à corriger (je n'indique pas le numéro de ligne, différent selon les variables déclarées, etc., il suffit de faire un c/c avec la fonction recherche de l'IDE).
Partie du code où réside l'erreur
MahonyQuaternionUpdate(myIMU.ax, myIMU.ay, myIMU.az, myIMU.gx * DEG_TO_RAD,myIMU.gy * DEG_TO_RAD, myIMU.gz * DEG_TO_RAD,myIMU.my,myIMU.mx,-myIMU.mz, myIMU.deltat);
La modification n'est pas compliquée, il faut passer en négatif la donnée comme cela "- myIMU.mz". (axe Z du magnetomètre, indiquée en rouge plus haut)
A noter qu'en plus des capteurs MCU, il existe le BNO055 de chez Adafruit qui est réputé fonctionner de suite.
A ce jour je ne l'ai pas testé (il coûte 10 fois à 15 fois plus cher qu'un MCU !) et selon certains commentaires, ce capteur serait sujet à caution car la procédure d'étalonnage intégrée est assez mauvaise. Attendez-vous à une erreur de 5 à 10 degrés dans les angles d'orientation.