Tous les forums > Commentaires > Article : Ajouter un bouton physique MOB à OpenCPN

Ajouter un bouton physique MOB à OpenCPN

Amis marins,


Vous utilisez OpenCPN, ce merveilleux outil de navigation configurable à souhaits auquel ne manque
qu'un bouton pratique pour le 'Man Over Board'.
Il existe en effet un bouton sur le logiciel qui permet de lancer cette fonction (MOB), mais cela implique
que vous soyez devant votre écran, une souris à la main, ce (...)

Liste des contributions

20170519_113806
Léopold

Bin tu parles à des informaticiens qui écrivent des codes.... tu devrais monter ta boutique et aller de port en port (pour une modique somme ) proposer tes services.

lundi 05 mars 2018 10:43
Missing
1
yannbis

Bonjour, excellente idée!
J'avais pensé au sujet sans le réaliser.

Si je comprend bien il suffit d'envoyer "CTRL+espace" au PC sous Open CPN (il faut aussi que Open CPN soit bien la fenêtre active, c'est à ne pas négliger, c'est fait ici avec WindowFocus)

Il y a une autre solution 100% Hardware avec un arduino qui émule un clavier USB (du coup ça marche sur tout OS):
http://mitchtech.net/arduino-usb-hid-keyboard/
Cela permet de "convertir" n'importe quel bouton poussoir en une combinaison de touches clavier. Il peut il y avoir d'autres applications utiles (on peut imaginer marquer un WPT pour se souvenir d'un événement, moins dramatique que MOB)
Le WindowFocus doit dans ce cas être traité séparément par un petit outil logiciel intermédiaire (fait avec AutoIt sous windows par exemple). Idealement (pour GilletArom qui semble suivre de près Open CPN), une fonction intégrée à Open CPN qui scrute en permanence une combinaison de touches même lorsque la fenetre n'est pas active serait intéressant)
C'est assez facile à réaliser.

Merci du partage d'idée en tout cas.

lundi 05 mars 2018 11:58
Missing
milimetrik

merci, très bonne et très simple idée.

lundi 05 mars 2018 14:08
20170519_113806
Léopold

Je confirme et je signe monté ta petite entreprise et tu seras le ou la bien venu pour configurer nos ordi de nav. Du moins sur le mien...C'est bien de connaître des gens compétents comme toi

lundi 05 mars 2018 14:27
Missing
Flotteur

Et pourquoi pas ? Si quelqu'un tombe à l'eau, en général ou jette la bouée ou la perche IOR, à l'arrière du bateau, donc. On peut à se moment là appuyer sur le bouton et activer directement une trace sur OpenCpn ou autre traceur.
Je vais installer un bouton MOB, mais je pense le mettre dans la descente pour y accéder depuis l'intérieur ou l'extérieur.
Outre la fonction de MOB, il permet aussi de marquer rapidement la position du bateau à n'importe quel moment. Pratique, si par exemple quelque chose est tombé à l'eau (lire "Histoires de partir" et la canne à pêche tombée à l'eau qu'ils ont pu récupérer grâce à la trace GPS).

mercredi 04 avril 2018 21:19
Missing
1
(FREDO28)

Bonjour,
avant de vous casser le cerveau avec des systèmes et des systèmes, qui peuvent bien sur, être d'une grande aide, je conseille ( je suis formateur) avant tout, de connaitre la procédure et de s'assurer qu'on est bien capable de récupérer un homme à la mer dans toutes les conditions et sans mettre en danger son équipage, peu de personnes s’entraînent pour cela.

lundi 05 mars 2018 15:48
Missing
2
milimetrik

certains commentaires sont vraiment de nature à décourager des contributeurs à donner des idées ou à partager des infos....

qui a dit que la sécurité ne consistait qu'à mettre en mettre en place un bouton MOB couplé à son logiciel de navigation???

pas besoin d'être formateur pour considérer comme évidence que la priorité n°1 est de mettre en place et de maitriser une procédure de récupération d'homme à la mer ou de s'attacher quand les conditions l'exigent....

mais on peut aussi être intéressé par le fait d'optimiser le système informatique embarqué: on peut faire l'un ET l'autre.

lundi 05 mars 2018 16:41
Avatar_gilletarom
Gilletarom

@M@telot Pui

" C'est quoi un raspberry" :

Hum ... Question pas sérieuse s'abstenir ... Il suffit de demander à gogol .. Il sait lui

Par contre "GPIO 11 (pin 11)", la c'est nettement plus sophistiqué... Mais, c'est bien le diable si Gogol ne recèle pas la réponse dans sa mémoire ...

lundi 05 mars 2018 17:42 *** Message modifié par son auteur ***
Missing
1
milimetrik

@M@telot Pui

on a le droit de poser des question ou de dire que c'est compliqué mais peut-être pas de remettre en doute le bien fondé de la contribution parce qu'on ne l'a pas comprise.

Un raspberry = un ordinateur au format carte bancaire qui permet entre beaucoup de chose de faire fonctionner le logiciel open cpn qui peut remplacer très avantageusement et à moindre cout financier et énergétique ton traceur.

GPIO = des 'connecteurs' pour faire simple qui permettent d'échanger des informations avec le raspberry.

lundi 05 mars 2018 18:14
Missing
yannbis

Je pense que le bouton MOB vient en complément de toutes les remarques citées plus haut et est tout d'abord un outil d'anticipation.

Si quelqu'un tombe à la mer (cas à prévoir, même si on s'attache), et que l'on fait bien toutes les manœuvres répétées à l'avance, mais que ça ne fonctionne pas (à prévoir aussi) , alors à ce moment là on sera bien content d'avoir pu appuyer au bon moment sur un bouton bien placé . Alors on aura une position exacte à transmettre, sur laquelle baser un plan de recherche, en tenant compte de l'instant exact, de courants, du vent, etc...
Et si le temps est mauvais tout est plus compliqué, on descendra d'autant moins dans le carré cliquer sur MOB.

Mais, bien sur, si on a tout fait bien avant ça n'arrive pas!

En matière de sécurité, la complémentarité est plutôt un atout.

lundi 05 mars 2018 18:29
Avatar
Ecume29

Bonjour,
Tant qu'a "prévoir" la chute que l'on pense qui n'arrivera jamais , autant prévoir un peu plus loin... j'y ai pensé plusieurs fois, surtout lors des nav de nuit ...
Associer le MOB a un détecteur de présence ? (si plus de présence à la barre et dans le cookpit , MOB + alarme ... ou un emetteur bluetooth porté par l'homme à la barre et si plus de liaison , idem MOB + Alarme... L'émetteur pourrait etre le smartphone ... d'autres idées?

lundi 05 mars 2018 21:12
Missing
Kinefou

Bonjour,
Le smartphone est tout à fait capable de remplir cet office, mais en pratique, un petit bracelets bluetooth ('I5 Plus Smart Bracelet Watch Bluetooth 4.0 Waterproof' à 11.60€ chez Buyincoins) le remplacera aisément. J'ai testé avec le bluetooth du raspberry 3 et le bracelet bluetooth ci-dessus; ça marche sans problème sur un bateau de 12m, moyennant l'ajout d'un script sh sur le raspberry recherchant la présence du bracelet dans son champ et actionnant la commande Mob.sh en cas d'absence répétée; je poursuivrai ce post très prochainement pour détailler ce code qui semble intéresser du monde mais que je n'ai pas encore publié vu que je me suis fortement inspiré d'un article existant
http://clement.storck.me/blog/2016/02/detection-de-presence-en-bluetooth/
pour le créer.
A très bientôt pour la suite!

mercredi 04 avril 2018 17:12
Castle
samdam

merci aux contributeurs de cette excellente idée du bouton MOB:
c'est toujours un plus pour la sécurité, qui en plus ne coûte pas grand chose pour ceux qui bidouillent un peu opencpn et rpi.
Les autres ne sont pas obligés de s'y intéresser, surtout que je vois pas en quoi ça remettrait en cause les précautions habituelles pour ne pas tomber à la baille et récupérer un baigneur involontaire

+dans le même genre de ce que propose Ecume29 , pour les navigateurs solo, une sécu avec un émetteur faible distance étanche à porter sur soi, qui pousse la barre du pilote à fond et éventuellement coupe le moteur, si le récepteur à bord perd le signal plus de 10 ou 20 secondes suite chute à la mer (comme certains systèmes commerciaux il me semble)
Le mieux c'est évidement de pas tomber, mais tout ce qui augmente les chances de remonter à bord ou au moins ralenti l'éloignement du canot à la dérive, ne peut que contribuer à la sécurité
C'est pas ma priorité bidouille du moment, mais si j'ai le temps j'ouvrirai un post pour développer ce système (si pas déjà fait ce qui m'étonnerai pas vu la vitesse à laquelle les systèmes opencpn sur framboise se développent!)

lundi 05 mars 2018 23:55 *** Message modifié par son auteur ***
Img_7803
tanagra

Super idée que je vais mettre en œuvre durant ces journées pluvieuses......

mardi 06 mars 2018 00:00
Avatar
1
Ecume29

Une excellente base pour la réalisation du Bouton "MOB" ...
https://www.framboise314.fr/le-bouton-poussoir-un-composant-banal-o-combien-etonnant/

mardi 06 mars 2018 07:44
Img_7803
2
tanagra

Suite à ce super article, je mets en pièce jointe une adaptation "à ma sauce" pour OpenPlotter (RPI, OP 0.17, OpenCPN 4.8.2)

lundi 12 mars 2018 00:25
Avatar
Ecume29

Bonjour,
Génial, je cherchais la solution pour générer l'action dans OpenCpn. ..
Je tenterais la mise en oeuvre la semaine prochaine.
La meme solution pourrait etre utilisée pour déclencher le Mob si rupture de la liaison bluetooth avec le smartphone (evoquée plus haut)...
merci tanagra

jeudi 05 avril 2018 05:59
Avatar
1
Ecume29

Je n'ai pas résisté à tester rapidement ...
Génial tout simplement. Pour Tanagra, simplement rajouter le déclenchement à partir d'un test bluetooth (smartphone ou simple bracelet bluetooth) pour lancement du script ... et tout s'enchaine ...
Voir http://clement.storck.me/blog/2016/02/detection-de-presence-en-bluetooth/ pour la partie bluetooth.
J'en avais rêvé , bouton + bluetooth c'est fait!
Bravo et merci

vendredi 06 avril 2018 15:05
Missing
1
Kinefou

Chose promise, chose due, voilà la suite de ce post traitant de la mise en place du Mob sur raspberry par l'ajout d'un dispositif bluetooth.
N'en déplaise à m@telot.phi et pour compléter les posts de Ecume29 et de millimetrick que je remercie de leur soutien!
Le principe est très simple; la personne de quart porte un émetteur bluetooth sous forme d'un bracelet ('I5 Plus Smart Bracelet watch Bluetooth' pour moi). apairé avec le raspberry Pi 3 qui tourne dans la table à cartes avec OpenCpn (fenêtre non réduite car le script mob.sh ne marche pas sur une fenêtre réduite).Toutes les 5 secondes, le script presence.sh (détaillé plus loin) cherchera le bracelet: s'il le trouve, il continue en incrémentant la variable presence. S'il ne le trouve pas, il émet un beep (avec un petit buzzer) pour attirer l'attention. Ce bip sera émis 2 fois (1 absence, puis 2 absences). A la troisième absence (au bout donc de 15s), il déclanche le script mob.sh qui va s'occuper de lancer la sirène d'alarme et de pointer le point de chute sur OpenCPN, tout en se réinitialisant afin de ne pas marquer plusieurs Mob d'affilée.
Dans mon cas, j'ai prévu 2 bracelets, 1 bleu et un rose (on est souvent à 2 sur le pont lors des quarts).Chaque équipier porte un bracelet à son poignet. A chaque bracelet, correspond un script 'presence' sur le raspberry, à savoir 'presence .sh' pour le bracelet bleu et 'presence1.sh' pour le bracelet rose.Ces 2 scripts sont lancés depuis le bureau en créant 2 fichiers de commande 'bleu' et 'rose' et en les rendant executables. on les lance dans un terminal pour suivre le déroulement. Important: ne pas réduire la fenêtre de opencpn car xdotool compris dans le script mob.sh ne marche pas sur une fenêtre réduite!). Tant que les 2 bracelets sont à portée du pi, le script continue à tourner sans avertissements. Si l'un des 2 se trouve hors de portée, un bip est émis. Au bout de trois absences, c'est le branle bas, la sirène hurle, le point se marque sur la carte et si on suit une route, elle est automatiquement redirigée vers le point de chute pour guider le barreur (merci OpenCPN!!!)
passons à la pratique:
Je suppose que vous avez suivi la première partie de ce post et que tout fonctionne avec le bouton.
Il vous reste à apairer les bracelets (ou smartphone si vous acceptez de la sacrifier!!!), puis à créer le script 'presence.sh comme suit:

presence.sh

#!/bin/bash

BLUETOOTHADDR="CB:9E:FF:D5:66:6C" # Adresse Bracelet rose

SLEEPTIME=5 # Intervalle de recherche en secondes

COUNTPRESENT=0

COUNTABSENT=0

while true

sudo gpio mode 29 out #n'importe quel gpio non utilisé sur lequel on branche une led témoin
sudo gpio write 29 1 #On allume le temoin de présence

echo "$$">Pid_Rose

do


hcitool con > rose

grep $BLUETOOTHADDR rose >/dev/null

retval=$?

if [ "$retval" = 0 ]

then
COUNTPRESENT=$((COUNTPRESENT+1))

echo "$(date) - ROSE est à bord!!"

sudo rm rose

else

COUNTABSENT=$((COUNTABSENT+1))

echo $COUNTABSENT

sudo rm rose

fi

if [[ "$COUNTPRESENT" = 1 ]]

then

COUNTABSENT=0

fi

if [[ "$COUNTABSENT" = 1 ]]

then

COUNTPRESENT=0

sudo gpio write 29 0 #On éteins le temoin de présence

sudo python /home/pi/bip.py #bip d'avertissement à la première perte de contact

fi

if [[ "$COUNTABSENT" = 2 ]]

then

sudo gpio write 29 0

sudo python /home/pi/bip.py #bip d'avertissement à la deuxième perte de contact

fi

if [[ "$COUNTABSENT" = 3 ]] # On attend 3 pertes de contact successives pour être sûr que Rose est absent


then

sudo gpio write 29 0

COUNTPRESENT=0

echo "$(date) - Homme à la mer!!"

/home/pi/Desktop/mob.sh #On déclanche l'alarme et on pointe la chute sur OpenCPN


rm Pid_Rose

sudo kill $$ #On 'tue' le processus pour arrêter la boucle

fi

echo "$(date) - confirmation presence: $COUNTPRESENT"

echo "$(date) - confirmation absence: $COUNTABSENT"

sleep $SLEEPTIME #On attend 5 secondes

done

Pour le deuxième bracelet, on reprend le même code en le renommant presence1.sh et en changeant l'adresse par celle de ce bracelet
on peut également changer le gpio du témoin de présence (si on veut un témoin par bracelet).

Le code de bip.py peut être par exemple: (on branche un buzzer sur le pin physique N°13)

import RPi.GPIO as gpio

import time

gpio.setwarnings(False)

gpio.setmode(gpio.BOARD)

gpio.setup(13,gpio.OUT)

gpio.output(13,gpio.HIGH)

time.sleep(0.5)

gpio.output(13,gpio.LOW)

time.sleep(0.5)

print('BEEEP!!')

reste à définir 2 fichiers de commande appelé 'rose' et 'bleu'sur le bureau pour lancer ces scripts commodément:

rose
#!/bin/sh
sudo /home/pi/presence.sh

bleu
#!/bin/sh
sudo /home/pi/presence1.sh

En pratique, mon Raspberry tourne dans la table à cartes et je le connecte de ma tablette avec VNC.
Je lance OpenCPN que je déplace pour avoir accès à mes lanceurs 'rose' et 'bleu'.
Je lance les scripts en double cliquant sur ces lanceurs et en choisissant 'executer dans un terminal'.
Je contrôle sur les terminaux qui se sont ouverts, la bonne réception de mes bracelets (presence=1, absence=0) et je maximise OpenCPN.
Le système prêt est alors prêt et surveille la présence des bracelets.
A chacun d'optimiser la méthode pour s'adapter à ses besoins.
Il est facile d'adjoindre une commande qui coupe le moteur avec une electro-vanne placée sur l'arrivée de carburant et commandée par le raspberry dans le script mob.sh, mais cela s'avère inopérant lorsqu'on navigue à la voile!
Sous voile, en situation de Mob, la réaction dépend beaucoup des conditions de navigation et de l'équipage. Toujours est il que la plus évidente des réactions est de lancer immédiatement une bouée avec feux ou une perche IOR, d'arrêter le bateau en le faisant loffer bout au vent, d'affaler la Gd voile et de démarrer le moteur pour revenir sur les lieux de la chute en passant au vent de la cible.Je pense que pour réaliser cela, le contrôle humain et visuel reste le moyen le plus sûr.
La sécurité est avant tout une question de pratique et on ne saurait trop insister sur l'importance de l'entrainement 'à blanc' avec une simple bouée pour augmenter ses chances de succès en malheureux cas d'épreuve réelle que je ne souhaite à personne!!L'electronique n'est jamais qu'une aide qui ne doit pas nous faire négliger le bon sens et la pratique.

vendredi 06 avril 2018 17:31
Copie_de_croisi%c3%a8re_2009_073
Calypso2

le MOB est tres utile pour pecher le maquereau ... lorsqu'ils morts on fait MOB ça permet de revenir sur le banc...

donc c'est une bonne idée ,pas de temps a perdre lorsqu'ils est là

vendredi 06 avril 2018 17:36
Missing
Kinefou

Bravo à toi, tanagra!; Je n'avais pas encore eu le temps de lire ton adaptation à openplotter qui me fait découvrir un peu plus les incroyables ressources de cette distribution 'couteau suisse'. Je vais la mettre en œuvre très vite et je te remercie également pour les précisions utiles que tu as apportées à mon article.
Amicalement

samedi 07 avril 2018 12:02
Img_7803
tanagra

@Kinefou: La connexion Bluetooth pour le MOB: superbe idée !!! d'autant plus que le RPI 3 intègre le Bluetooth (je l'utilise pour aiguiller les alarmes sur une petite enceinte Bluetooth). Je vais regarder comment mettre en œuvre cette fonction sous OpenPlotter et je ferai un retour sur ce fil.

Pour l'option "Bouton Poussoir" MOB je pense préférable de protéger le RPI par un optocoupleur. Je vais mettre à jour ma petite doc en intégrant cette petite modification.

dimanche 08 avril 2018 10:34
Missing
yannbis

Bonjour,
projet vraiment très intéressant.
Une solution simple et restant économique pour les moins bidouilleurs, ou les windowsiens : acheter un accessoire qui fasse la conversion bouton poussoir->entrée de touches de clavier.
Par exemple ici pour moins de 7€, c’est une pédale USB programmable, vue par le PC comme un clavier.
https://www.ebay.fr/itm/PC-USB-Foot-Switch-Keyboard-Pedal-V3X/282336494404

Dans le cas d’un MOB on programme « CTRL+Espace ». En démontant, on doit facilement récupérer les 2 contacts pour déporter le bouton sous un format souhaité et étanche.
Bien sûr il faut que la fenêtre Open CPN soit active. Pour pallier à ce problème, je pense qu’un petit script intermédiaire peut faire le job, j’essaierai avec AutoIt et la fonction ControlSend ( https://www.autoitscript.fr/autoit3/docs/functions/ControlSend.htm)

Néanmoins la gestion de la fenêtre active semble un point dur potentiel niveau robustesse.
J’en profite pour relancer GilletArom pour voir si une intégration plus profonde dans Open CPN serait possible, en intégrant une veille des touches « MOB » même si la fenêtre est inactive .

Enfin quelques suggestions, notamment pour robustifier le système c’est primordial :
> Autotest du bouton au démarrage, permet de valider que toute la chaine hardware est OK, et aussi un bref coup de buzzer.
> Bouton d’acquittement (surtout dans le cas d’un système bluetooth, par exemple si on débarque un équipier mais qu’on continue la nav.)
Ces fonctions peuvent être faites par un appui long par exemple, en conservant une seule I/O

Je testerai volontiers dès que j’aurai un bateau

Yann

PS : dernière remarque, il y a des commentaires à la fois sur le forum et sur l’article on s’y perd un peu, ce n’est pas possible de centraliser ?

lundi 09 avril 2018 10:59

Répondre

Pour participer aux forums, vous devez être inscrit et identifié

Vous identifier | Créer un compte matelot

Retour forums