Raspberry et OpenCPN: pas si top que ça
Hi,
Comme beaucoup j'essaie un raspberry pi4 avec opencpn pour moderniser un peu l'électronique de mon bateau à moindre frais.
Mais voilà, quand on coupe le jus le pi s'arrête, brutalement.
Donc à chaque démarrage openCPN se plaint d'avoir été mal arrêté (popup de 15s).
Et parfois (2 occurrences chez mois) il écrabouille son fichier de configuration.
Autre souci: décès prématuré de la carte microSD. Et là pas d'bol la licence des cartes oesenc est perdue.
On peut ajouter un petit switch pour arrêter proprement le Pi avant de couper le jus. Moins de problèmes donc mais une action manuelle systématique à faire. Mais il y a aussi des coupures inopinées à bord ...
Je vais faire un nouvel essai avec un SSD externe, un petit contacteur, et une licence carto sur dongle USB.
M'enfin voilà il faut tout refaire et j'ai perdu quelques euros.
HTH comme on dit.
Salut,
Ben oui, il faut connaitre les limites de ce genre d'installation. C'est du DIY donc il ne faut pas faire sans savoir (ou se renseigner)
On ne coupe pas brutalement un RaspBery Pi sous peine de tuer la carte SD, c'est le seul point faible de ce système tel qu'il est de base.
Le passage sur SSD devrait bien améliorer les choses.
Il y a aussi des systèmes qui détectent la coupure de courant et qui font le shut down propre (maintien sur une petite batterie le temps du shut down)
Quand on sais à quoi s'en tenir, c'est un système très fiable, je l'utilise depuis des années sans jamais un plantage en nav.
Il y a quelques temps j'avais envisager d'en monter quelques un pour rendre service, mais au premier que j'ai fait, je passais mon temps en maintenance, je n'ai pas compris tout de suite, car le mien était super fiable, jusqu'au jour ou j'ai vu comment le gars le coupait en coupant le jus au tableau malgré mes consignes. Après un rappel de la cause de mortalité c'était bon.
j'ai arrêté c'est trop chronophage et c'est destiné à ceux qui ont l'habitude, je ne maintien que le miens et j'ai quand même une carte SD d'avance déjà configurée au cas ou. Le problème le jour ou j'en aurais besoin, sera de la retrouver 😊
Il y a aussi des systèmes qui détectent la coupure de courant et qui font le shut down propre (maintien sur une petite batterie le temps du shut down)Très intéressant, tu as un lien stp ?J'ai cherché sans succès. Bon, sans trop insister non plus j'avoue.·le 25 jan. 2021 21:03
C'est quand même la base d'arrêter le système avant de couper l'alimentation.
Pour arrêter un ordi tu ne coupes pas la multiprise !
Exactement, comme dit jdmuys c'est pénible de devoir arrêter "logiciellement" le pi. Je ne dis pas que c'est un mauvais setup, juste que ce n'est pas la panacée. J'ai un pi depuis des années en média center, il est très facile à éteindre d'un simple raccourci clavier.
Mon setup à bord est sans écran, sans clavier, juste une boîte noire quoi.
Je suis pas débile je sais que c'est pas bien l'arrêt brutal, mais (par exemple) pourquoi openCPN ouvre-t-il son fichier de paramètres en écriture ? Juste pour enregistrer trois réglages persistants .. un second fichier à part aurait été une bonne idée.
Le but de mon message est juste de rappeler qu'un pi c'est fragile, qu'une carte SD aussi, et qu'openCPN peut pourrir son fichier de config, que la licence oesenc est invalidée si on réinstalle l'OS.
Le fait que le Pi (comme tous les ordinateurs) n'aime pas les coupures intempestives de courant vient du fait qu'il a un buffer sur les entrées et sorties des dispositifs de stockage, en l'occurrence la carte SD. Quand on coupe le jus, si certains fichiers étaient ouverts en écriture, le contenu du buffer est perdu, et le fichier potentiellement corrompu (voire le systeme de fichier, si on était en opération dessus à ce moment la).
Pour un systeme embarqué, il y a bien une solution: c'est de passer le systeme en lecture seule. Linux tolère bien ce genre de modif moyennant quelques réglages (les fichiers temporaires sont gardés en ram etc), et si on veut changer quelque chose dans la configuration, il faut par contre redemarrer le pi en mode écriture, mais ca ne devrait pas etre tous les jours.
Si par exemple on est arrivé à un systeme bien configuré et satisfaisant au quotidien, on passe la partition systeme en lecture seule, et pour le stockage des traces gps par exemple (ou du log de nav, ou que sais-je) on peut utiliser une clé usb ou une partition configurée sans buffer. Si plantage il y a, soit c'était pile pendant l'écriture du log, et c'est pas de chance, on a perdu le log mais le reste va bien, soit c'était à un autre moment, et la c'est transparent.
j'ai pas de lien à partager, faut se renseigner sur les systemes linux read-only.
Quelqu'un a-t-il expérimenté l'alim du Pi par une batterie 5V de recharge de téléphone, elle-même rechargée par l'alim 12/5V ?
Ça permettrait de ne plus couper le Raspberry Pi (le III B + dans mon cas) en nav prolongée ?
C'est là que l'on atteint les limites du rpi. A part pour le plaisir de faire soi même, le rpi reste inférieur à une machine classique, le mieux étant un PC industriel sur 12v.
Le rpi pour moi c'est réservé à ceux qui maîtrisent l'électrotechnique, et qui ont une expérience de Linux conséquente.
Si on veut un système pour naviguer au large, la fiabilité et la stabilité sont importants. La consommation n'est plus un point fort, un système complet rpi4 4go, avec écran est à un niveau équivalent à une machine classique sous linux avec les scripts adéquats(et en plus beaucoup qui ont des pi ont des capacités de production en panneaux ou autres plus que conséquents). En perfs, il est largué.
Honnêtement, je pense que l'installation d'un rpi comme centrale de nav principale est conditionnée à la maîtrise et une solide expérience en linux. Je vois souvent passer des questions sur le thème montrant l'inverse. Beaucoup d'utilisateurs (attention, il y en a aussi qui maîtrisent) se contente de recopier des scripts sans savoir ni comprendre ce que veulent dire ls, tar, et autres commandes de base.(et veulent faire marcher un pypilot). C'est dommage, mais à l'ère du script kiddie je ne suis pas étonné.
C'est juste un humble avis de quelqu'un tournant sous Linux et/ou BSD depuis 1998, versé dans des projets OpenSource au niveau perso et pro.
Ps: attention, il y a sur HEO des gens compétents en la matière, qui ont des réflexions productives.
Ps2: il serait bien de se faire confirmer par l'équipage qu'un RTFM est conforme à la charte, l'expérience prouve que cela est bien plus productif pour faire progresser un débutant.
Bonne journée à tous.
@ Juliusse.. tu as raison sur les limites du Rpi
Sur les domaines que je maitrise un peu plus j'ai tendance comme toi à donner une vision "pessimiste" aux non initiés.
Sur les domaines que je maitrise moins (linux!) je pars optimiste tout en n'étant pas naïf sur les difficultés à venir!
Je ferais la différence entre :
- des systèmes évolutifs type Open Plotter sur lesquels on va faire des mises à jour, ajouter/supprimer de nouveaux logiciels/matériels, ce qui peut s'avérer compliqué à long terme, on va vite être confronté à linux dans le dur...
- de briques plus autonomes type Pypilot Muxberry, qui ont une vocation de boite noire, ça marche, on n'y touche plus.
Effectivement, pour ma part sous linux je me contente de recopier des scripts, j'ai tout de même une vague idée de ce que ça fait et j'essaie de me documenter.
On se retrouve souvent confronté au développeur (auquel je ne jette pas la pierre) qui partage un bel outil mais qui a du mal à vulgariser son installation et son usage. Donc RTFM, OK mais àa dépend aussi de la doc (et là encore je ne jette pas la pierre car ça prend du temps et ce n'est pas simple de vulgariser)
Je trouve qu'on propose aussi souvent ds solutions trop complexes (c'est un bon moyen de "sélectionner" les utilisateurs, ce n'est pas idiot)
Parfois les tutos Rpi expliquent comment installer l'OS, puis SSH, les scripts etc... alors qu'on peut partager une image de la carte SD
On arrive tout de même à de belles choses je trouve.
J'ai installé Open Plotter sans souci avec son GPS. Pas encore utilisé intensivement, ni interconnecté, je vais certainement avoir qq soucis à venir comme sur toute interface, mais je suis confiant.
Je suis en cours d'install de Muxberry, ça se passe plutôt bien même si la doc est un peu obscure pour un débutant. J'essaierai de contribuer à l'améliorer
Bonjour Candide,
je ne comprends pas bien ta configuration. Tu utilises un serveur VNC pour utiliser OpenCPN exécuté sur le Pi depuis une interface tablette ou autre ?
Sans interface déportée sinon je ne comprends pas l'utilisation que tu fais d'opencpn sur le Pi en mode boîte noire. Et s'il y a une interface déportée via VNC, tu dois pouvoir arrêter le Pi logicielement ?
Hello,
Pour clore ce topic, il existe bien une belle alim sécurisée pour le Pi4, dispo sur le net à 55 balles.
Truc très sexy que je vais m'empresser de commander.
Et puis il y a directement dans raspi-config une option overlay fs qui permet de monter la SD en lecture seule, avec trois lignes de script on doit pouvoir réduire à quasi 0 les risques de corruption du fs.
Allez je réactive mes bloqueurs de pubs et j'vous souhaite du bon vent à tous et vivement le printemps !!
@yannbis: regarde sur kubii.fr, cherche pijuice, tellement fun ce truc, pourquoi s'en priver !!
Sur la fonction de base évoquée ici (permettre un arrêt maitrisé du Rpi) je ne vois pas d'écart majeur entre la version ebay à 10€ évoquée ci dessus et la version Pijuice.
mais je me trompe peut être?
Juste pour tes histories de carte SD. Apres en avoir cramé .... 4 en un an, je suis passé au SSD.
C'est incomparablement plus performant.
J’ai aussi mis un SSD, pour utiliser le Pi également comme serveur de fichiers (docs du bateau) et serveur de musique.
Ensuite, je prévois de l’utiliser comme serveur OpenCPN/Signalk pour des afficheurs NMEA. Tests concluants en utilisant une liseuse Kobo comme afficheur (-> portable, étanche, basse consommation).
Bonjour, je n'ai pas fouillé le sujet, mais je me pose la question de l'intégration du SSD. Il existe des SSD de petit format ou c'est forcément comme un petit HDD?
Astuce pour quitter "proprement" OpenCPN depuis un script:
kill -USR1 `pidof opencpn`
Tout bêtement.
Bonjour à tous,
Pour le problème de coupure du raspi j'utilise un UPS à accus 18650 qui est plus cher que les modèles E-Bay.
Il se trouve que je l'avais déjà pour un autre projet. L'autonomie en usage est de plusieurs heures si besoin. Il dispose d'un script python qui éteint proprement le raspi si les batteries baissent trop. Évidemment on peut faire ce que l'on veut de ce script ;)
Et j'envisage de le doter d'un bouton qui lancerait un "shutdown -h" propre. Et aussi le démarrer quand il est arrêté...
A plus,
