Linux & Navigation (analyse d'idées)

Dans l'objectif d'aller plus loin qu'OpenCPN ou QTVLM je serais intéressé pour collecter les besoins techniques qui pourrait être mise œuvre dans le cadre d'une plateforme communautaire maritime Linux embarqué.

Avec mon équipe (30 ingé basée à Lorient) nous travaillons pour l'automobile et les bateaux de travail. Toutefois avec pas mal de marin dans l'équipe j'aimerais avoir une solution communautaire et opensource orienté bateau de loisir dérivées des travaux Linux que nous menons par ailleurs.

Techniquement nous utilisons un Linux embarqué orienté automobile (AGL) sur lequel nous avons déja ajouter quelques composants maritimes, notamment: NMEA2000, SignalK, CAN, J1939, Modbus, ... Nous aussi commencé des recherches sur des algos de radar, le décodage des cartes S57, l'AIS, la 4G, les interfaces bateau->cloud, ...

Mon but est de voir s'il serait possible de travailler en groupe pour produire des composants de code ouverts, modulaires et réutilisables. La cible un systèmes Linux embarqué configurable qui puisse supporter: navigation, alarmes, routage, météo, multi-media, collecte des données sur le cloud, ... A l'inverse d'OpenCPN que nous connaissons tous très bien, l'objectif d'avoir est une architecture microservices orrienté API et non pas un système monolithique rempli de dépendances.

Les cartes cibles sont évidemment communautaire type: Raspberry ou Mino, mais aussi plus pro type: IMX8, Nuc, STM32MP151, Renesas, ... Le tout soit sans écran avec le display sur tablette ou à l'inverse un ou plusieurs displays.

A ce niveau mon but c'est pas de faire de la pub, puisque je n'ai rien à vendre. Les échanges techniques se feront via la plateforme matrix.org sur la room #redpesk@sea:matrix.org . Tous les informaticiens intéressés sont les bien venus. On peux aussi envisager un hackathon que nous serions heureux d'héberger dans nos locaux (nous pouvons fournir le hard, les crêpes et la pâté Hénaff)

L'équipage
03 août 2020
03 août 2020

super projet !!!

03 août 2020

Très bon projet. Dommage d'avoir mis en mode débat, ça va limiter les contributions à 3 par personne...
Pour ma part je suis en train de mettre le point final avec des confrères à un projet dont j'ai parlé ici.
www.hisse-et-oh.com[...]n-linux

Ça devrait être prêt en septembre, avec un changement car une remise en question à été faite en mieux et plus simple, plus efficace et plus polyvalent. J'en parle très bientôt.
Mais je suis intéressé par ton projet.
Au plaisir

03 août 202003 août 2020

Je suis super intéressé pour y contribuer... pour Macintosh. Ca devrait être possible car le Mac a une base Unix (BSD). Ce que je regrette dans les produits Open Source sur Mac (et même trop souvent closed source), c'est que même s'ils fonctionnent correctement, leur interface utilisateur est très médiocre. Je suis convaincu que la bonne approche est celle que vous proposez: des composants qui proposent une API, et par dessus une interface utilisateur qui dépend de chaque plateforme et que chaque dévelopeur peut décider de peaufiner comme il l'entend.

Ma contribution serait donc de prendre chacun des composants, vérifier leur compatibilité sur MacOS (et iOS/iPad OS tant qu'à faire), les adapter le cas échéant, mettre en place la chaine de compilation installation (probablement sur Homebrew) et de fournir des interfaces avec les couches de haut niveau d'Apple quand c'est pertinent (Swift).

Concernant les architectures de processeur, il faudrait (au moins) deux cibles: l'architecture Intel, et l'architecture ARM. A mon avis s'il faut choisir, les versions 64 bits doivent avoir priorité sur les versions 32 bits, mais il est probablement facile de supporter les deux (enfin, les quatre au total).

03 août 202003 août 2020

@jdmuys malheureusement le MAC comme le PC est "out of scope". Nous visons les systèmes embarqués dédiés. Même si techniquement on peut en mode développement fonctionner sur des composants Intel et donc sur PC/MAC, nous visons principalement les architectures ARM avec des cartes à très faibles consommations et des niveaux d'assurance de services proche de ce qu'on peut trouver sur un ABS de voiture. Le but c'est d'avoir un système au moins aussi fiable qu'un Raymarine, Garmin, Simrad. On veut aussi booter en moins de 5 secondes.

Coté programmation c'est C/C++ sur Posix, pour l'application framework on va forcement réutiliser celui d'AGL (Automotive Grade Linux) sinon il faut réécrire le stack NMEA2000, J1939, ... On perdrait aussi la partie cybersécurité, les mises à jours on the air, ... Le but c'est pas de réinventer la roue, mais de récupérer un max de chose faite pour d'autres industrie. Au final un bateau c'est une voiture sans roue. Le stack AGL utilise énormément de fonctions du Kernel Linux (SocketCAN, Namespace, ...). Même si techniquement c'est toujours possible de passer d'un OS à un autre, le coût du portage est souvent prohibitif.

64bits: Même si techniquement on peut encore faire du 32bits, il y a trop de restriction, notamment sur la partie isolation/containers. La seule chose qui peut avoir un intérêt en 32bits, c'est de faire tourner un RTos pour quelques fonctions critiques ou très basse consommation. Certaines cartes embarquées possèdent un microcontrolleur associé ou on peut faire tourner un OS de type Zephyr pour des fonctions du type: alarme infraction, eau, mouillage, ...

03 août 2020

@fulup, bien entendu, je ne parle pas de mélanger le projet sur lequel je suis avec le tien. Comme tu dis ce sont 2 choses très différentes.
C'était juste pour te dire que ce genre de projet m'intéresse, mais que tant que je suis sur le mien, je ne peux malheureusement pas m'impliquer dans un autre.
Par contre, dès que j'ai terminé, je suis intéressé pour aider au tien.
Je note donc l'adresse de ta room matrix, et espère revenir vers toi dès que possible 😉🖖

04 août 2020

@juliusse. Faire une distro spécialisée basée sur une existante Debian, SuSe, Arch, Fedora, ... n'est pas très compliqué. C'est mettre en place le système d'intégration continue pour l'ensemble des plateformes hardware visées et la maintenance sur des années qui devient vite lourd. Dans mon cas la gestion de la distro et de l'intégration continue est déjà réglée redpesk.bzh[...]/ ça fait un soucis de moins.

03 août 202003 août 2020

@juliusse, J'ai pas sélectionné le mode débat intentionnellement, je n'ai même pas vu l'option :) Ceci dit le gros des discussions va rapidement être centré informatique, ce qui n'est pas vraiment l’objet d'hisse&ho.

J'avais vu ton projet au printemps, tu part dans une direction très différente de la notre. Ton but c'est de spécialiser une distribution pour y pre-installer des outils existants. Notre objectif c'est de créer des choses qui n'existe pas.

_A titre d’exemple, nos 2 projets maritime de l'été. _
1) saferoute: but vérifier que la route actuelle du bateau est safe. Nous avons développé du code pour découper les cartes marines S57 sous format d'hexagone (format H3 Uber), ensuite nous ajouter les points de sondes puis calculé la marée pour dire si le bateau rentre dans une zone risqué ou non. Le but c'est d'ensuite ajouter les routes AIS habituelles (que nous stockons depuis de long mois). Ensuite on ajoute les lignes de sondes, les chenaux, les balises, .... et on est capable d'avoir un avis sur la route suivie.
2) radar fusion: but fusionner les données de radar pas cher de voitures et drones pour comprendre l’environnement direct du bateau à 360° sur la zone 1/30m et sur 120° à 350m puis de fusionner ses informations avec un radar broadband pour la zone au delà des 350m. Objectif comprendre l'environnement dynamique du bateau pour ajouter des info au calcul de "safe-route'.

Conclusion: notre objectif n'est absolument pas de récupérer des vieux PC ou de faire une distribution maritime facile à installer. Le but est de créer l'outil de navigation de demain. Pour ça il y a beaucoup de code à écrire.

03 août 2020

Salut, une idée géniale si vous voulez vraiment "créer l'outil de navigation de demain" ce serait de consacrer du cerveau d'ingénieur à un protocole type AIS intégrant une technologie de Self Sovereign Identity. Dans la navigation de demain, la privacy des individus sera ainsi respectée.
Merci !

04 août 202004 août 2020

@tdm2023, le fonctionnement le protocole AIS n'est pas vraiment "privacy friendly". J'ai travaillé dans les années 2010 à l'écriture des normes SAML2+OpenID et je connais plutôt bien les problème de protection de la vie privée dans le monde digital. Toutefois le but de l'AIS est d'annoncer la position+cap+vitesse de son bateau. Le faire en mode offusqué n'aurait pas vraiment de sens, même s'il est toujours possible de faire comme les militaires et d'annoncer un MMSI bidon. Pour l'AIS il existe un effort de normalisation pour se protéger du deny de service et de sécurisation des trames, mais à ma connaissance aucun projet de "Federation/Offuscation de MMSI". C'est vrai que l'AIS est passé rapidement de simple outil de prévention des collisions à un outil de suivi de flotte, avec les avantages et les inconvénients attachés. Connaître le MMSI des ferry qui fond Groix/Lorient permet de prédire leur route et donc d'anticiper. On ne peut pas avoir le beurre et l'argent du beurre.

06 août 2020

Merci @Fulup pour ta réponse
J'en remets une petite couche puisque ça me parait très important et que ça n'est pas tout à fait hors sujet s'il s'agit d'imaginer "l'outil de navigation de demain" : penser et développer un système anti-collision respectant la privacy des usagers me semble être tout sauf un gadget. L'application STOP_COVID pour donner un exemple récent a suscité de nombreuses réactions et de nombreuses réflexions précisément autour de cette question de privacy et de traçage.
Et amha il est faux et potentiellement dangereux de dire "On ne peut pas avoir le beurre et l'argent du beurre." La privacy est un enjeu qu'il ne faut pas abandonner au fatalisme. Mes compétences s'arrêtent là, mais j'ai un proche très compétent dans le domaine (BlockChain et autres crypto technologies, etc.) et qui me dit que cette question de Self Sovereign Identity (c'est à dire, le principe que l'individu garde la souveraineté sur son identité, et n'a pas à la soumettre à une autorité tierce) est en plein essor, avec des recherches et de (très très) nombreux domaines d'application. Et il me semble que typiquement l'AIS pourrait être un tel domaine d'application. J'en ai parlé avec mon expert, voici quelques éléments de sa réponse :
"Comme tu me l'avais dit, il existe aussi sûrement des enjeux propres au domaine maritime (débit, priorités de certaines informations,..).

Je ne sais pas comment la solution arrivera : un système générique de SSI se répandra-t-il sur différents usages ou vaudrait-il mieux dès maintenant tenter de répondre précisément aux besoins des MMSI ?

En ce moment je travaille pendant une semaine sur des problématiques réllement connexes.
On manipule des objets tels que des verifiables credentials / claims signées et des preuves à divulgations nulles de connaissances (ZKP).
Les standards et usages commencent je crois assez clairement à émerger.

w3c.github.io[...]-model/
w3c.github.io[...]-cases/ "

Je prêche un peu dans le désert pour le moment j'ai l'impression. Mais si ces quelques éléments pouvaient contribuer à attirer l'attention de la communauté informatique/navigation sur cette problématique, ce serait déjà un pas en avant. Des solutions existent peut-être, il faut les inventer, pour avoir le beurre (sécurité) et l'argent du beurre (privacy).

06 août 2020

@tdm2023, le "Self Sovereign Identity" est clairement "out of scope". C'est un sujet intéressant, mais qui n'entre pas dans le cadre de ce projet, et je préfère pas pourrir le fils de discussion.

L'AIS a pas mal de soucis, il y a des ps mal de discutions en cours au niveau des organismes de normalisation maritime avec un focus important sur la partie piraterie en mer. Maintenant je n'ai pas la prétention d'avoir la moindre influence, ni le désir d'influencer les discussions en question. Quoi qu'ils décident rien ne sera en place avant plusieurs années.

Conclusion: le jour ou une nouvelle version sortira, on commencera à regarder.En attendant on reste sur l'existant.

04 août 2020

Le projet est super intéressant mais je crains que les technos envisagées ne soient pas super ouvertes pour un projet Open source.

Si c'est des microservices autant en profiter pour être un peu plus ouvert, notamment niveau UI: supporter une app serait quand même logique.

04 août 2020

@iclo420 tu as raison tout n'est pas couvert par de l'opensource. Toutefois une grosse partie est à minima en partie couverte. C'est à nous d'écrire les bouts qui manquent.

C'est la raison pour laquelle en début d'année nous avons publié des stacks ouvert compatible NMEA2000, J1939, CanOpen, Modbus, ... Cet été nous allons publier nos travaux sur le traitement des cartes marines S57, domaine ou presque tout est dispo mais en ordre dispersé. Dans beaucoup de cas, c'est juste une bonne doc qui manque d'en d'autre cas, il faut développer du code.

04 août 2020

"supporter une app", je nuancerais en disant "utilisable par une app".

C'est en tous cas l'esprit de ma proposition sur Mac.

Je comprends bien les objections qui ont été apportées, mais en proposant des API bien conçues, avec couplage réduit, on doit pouvoir limiter les composants inutilisables par une app.

D'ailleurs l'exemple fourni de "safe route" rentre plutôt bien dans ce scénario. Le "code pour découper les cartes marines S57 sous format d'hexagone (format H3 Uber)" pourrait parfaitement être encapsulé dans une bibliothèque bien portable.

04 août 202004 août 2020

@jdmuys, tu as raison sur la portabilité du code, tout peut tourner sur tout, c'est juste une question de ressources et de temps. Il n'en reste pas moins que sous peine de devoir réinventer la roue, c'est beaucoup plus rapide d'utiliser un framework existant que de repartir de zero.

La partie userspace tout est théoriquement portable, toutefois rien que les 2 fonctionnalités suivantes à passer sur Mac consommeraient déjà pas mal de temps.
- IPC et microservices iot.bzh[...]w-perfs
- Cybersecurité iot.bzh[...]systems

Encore plus risqué la partie Kernel: recréer l'équivalent de fonctionnalités Linux standard de type SocketCAN ou Remoteproc sur MacOS est beaucoup trop long pour en faire un projet viable (c'est sans doute pour ça que personne ne l'a jamais fait).

Enfin et c'est pas le moindre des soucis, il reste toute la partie "intégration continue". Nous avons un système qui permet de maintenir des distros embarquées de manière automatique sur ARM+INTEL. Ca nous à pris 2 ans à 15 personnes de le mettre en place docs.redpesk.bzh[...]ew.html

Écrire un stack CAN au dessus de SocketCAN/linux et LowCAN/AGL c'est trois petits mois de travail. Si tu part de zero c'est probablement une bonne année et encore ton système sera moins puissant que celui de Linux. Techniquement Macs ou Android sont de bonnes plateforme, coté ouverture c'est une autre discussion. Outre la politique commerciale d'Apple et Google qui me sorte par les trous de nez, je suis trop fainéant et ne n'ai pas de ressource illimitées pour envisager c'est deux plateformes.

Les Macs comme les PC ou tablettes pour Android peuvent dans certain cas être une bonne option pour l'affichage les IHM. Toutefois pour la partie embarquée c'est moins adapter qu'une carte IMX8. On a fait une demo d'un POC à CES en début d'année

à mon avis autant la partie IHM peut tourner sur n'importe quoi, autant porter le cœur du système sur autre chose que Linux n'a pas vraiment d’intérêt. Maintenant si quelqu'un veut le faire, le code source que nous produisons est public :)

04 août 2020

Je ne peux que souscrire à "le coeur du système sur autre chose que GNU/Linux n'a pas vraiment d'intérêt".

04 août 2020

Je dirais que ça conserve un intérêt certain mais que ça va mal filtrer le casting des potentiels contributeurs car on part sur une technoligie assez spécifique, même si ouvertes.

Il est plus facile de trouver / impliquer des personnes ayant des compétences en App Android ou Apple qu'en informatique embarquée.

Après ça peut quand même vraiment déboucher une alternative DYI sur le matériel en offrant une alternative aux solutions havituelles vendues "out of the box"

04 août 202004 août 2020

Je suis d'accord que le Mac n'est pas une bonne plateforme pour tout ce qui est contrôle. Il n'y a pas d'intérêt à écrire du code kernel pour Mac (possible mais sans intérêt).

Le Mac est pour moi une plateforme applicative. Ce qui m'intéresse c'est de le voir mieux supporté par les logiciels de navigation. Aujourd'hui il n'y a pas d'application de navigation (à ma connaissance) bien conçue pour Mac, probablement parce que un tel logiciel doit nécessairement avoir une partie de son code non portable. Les solutions cross-plateforme d'écriture d'interfaces utilisateur ne sont pas satisfaisantes (le pire étant l'abominable Electron).

Votre projet est intéressant dans cette perspective parce qu'il propose une approche modulaire avec des APIs, ce qui est à mon avis la bonne approche. Certains de vos modules ne sont pas pertinents pour une application, d'autres pourraient l'être davantage.

Il n'en reste pas moins que vos objectifs et les miens sont très différents. J'espère seulement qu'il pourra y avoir une intersection.

04 août 2020

@jdmuys l'approche par API doit permettre de bien isoler la partie IHM de la partie logique. Pour le graphique, il faut à minima une version HTML5 et une version native type QT. Maintenant la partie IHM même si elle est très importante reste relativement simple à gérer. Ce qui est compliqué c'est de calculer les tuiles de la carto pas de les afficher. Même chose pour un pilote auto, c'est la logique de routage et la commande du vérin qui sont compliqué pas la gestion des boutons +10/-10.

Faire une app quand on à les bonnes API c'est relativement simple, c'est quand on ne les a pas que c'est compliqué. Si Dave avait eu un set d'API équivalent à github.com[...]uto-api alors OpenCPN serait sans doute 10 fois plus simple.

05 août 2020

On est bien d'accord.

04 août 2020

@iclo420 c'est la difficulté des projets communautaires. Il faut trouver le bon compromis entre intérêt immédiat, compétentes et objectif final.

L'objectif premier de ce projet est de mettre en place une plateforme qui s'occupe des problèmes génériques non visibles et que personne ne prend le temps de traiter correctement: acquisition, sécurité, protocole de com, format de carto, connectivité, ... Ca reste avant tout de la techno embarquées, et effectivement trouver des compétences communautaires n'est pas forcement simple. A l'inverse il existe tous un tas de projets OpenSource industriels qui adressent une bonne partie de la problématique (SocketCan, AGL, GDAL, ...)

Je ne vois pas d’intérêts à refaire OpenCPN ou OpenCharter qui fonctionnent plutôt bien. Ma proposition est de réutiliser un max d'investissement des systèmes automobiles et industriels pour un usage plaisance. Vu le cout et les investissements fait dans l'automobile, il me semble plus viable de repartir de leurs développements et de refaire les IHM qui manquent que de faire l'inverse.

04 août 2020

"Je ne vois pas d’intérêts à refaire OpenCPN ou OpenCharter qui fonctionnent plutôt bien"

Sur Mac, OpenCPN fonctionne. C'est bien. C'est insuffisant.

04 août 2020

Bonjour,

Je suis très intéressé car concepteur de systèmes industriels sous Linux et justement je suis en train de réfléchir à une solution spécifiquement "bateau".
L'ensemble des développements étant open source, je me joindrais bien au projet.

Sur les solutions techniques et les IHM, il y a plein de débats possibles et c'est ce qui est intéressant.

Le lien sur la gamme de produit existants:
On réutilise déjà pas la techno automobile.

Pour que cela fonctionne il faut une structure technique qui héberge le projet et une équipe d'animation. Même si cela est fait en "best effort", sans un minimum de coordination cela n'avance pas du tout. Je participe déjà à des projets open source (Eclipse Foundation) dans l'IoT.

A bientôt

04 août 2020

@sterwen la plateforme IMX6 peut convenir à des systèmes sans écrans, par contre pour gérer un écran FHD il vaut mieux passer un IMX8, RCARM3, .... Sinon il existe tout un tas de systèmes semi-industriels du type de celui que tu as référencé qui sont de bonnes bases de travail. Coté bas coût la Rasbery-4 malgré ses défauts reste intéressante, dans le monde Intel les cartes up-board sont très biens même si aucunes de leurs cartes n'a de bus CAN intégré. Le but du projet est de faire du soft, le choix final du hardware c'est un peu la cerise sur le gâteau. Au final même si l'intégration de toute nouvelle carte prend un peu de temps, avec un BSP c'est pas non plus fin du monde. Dans la phase de développement initial la Rasbery et la UP-2 sont probablement les deux cartes de références les plus facile à se procurer par le commun des mortels. NXP, ST ou Renesas nous donne bien quelques échantillons de cartes automobile qui feraient de super cibles, malheureusement elles sont rarement simples à acheter.

Coté structure nous avons une infra de gestion et d'intégration continue et une bonne expérience de la coordination OpenSource. Sur les 5 dernières années mon équipe à fait 60% des contribution technique au projet Automotive de la Linux Foundation. Si la mayonnaise prend on sera toujours assez tôt pour passer le projet sous un chapeau du type Linux Foundation ou Apache. Ce type de fondation peut améliorer la visibilité, toutefois beaucoup de projets comme Signal-K ou OpenCPN vivent très bien sans.

05 août 2020

@fulup Je suis bien d'accord que ce projet ne doit pas être lié à un hardware donné. C'est bien ce qui m'intéresse d’ailleurs. Avoir une base logicielle qui peut se déployer sur plusieurs architecture matérielle doit être un objectif pour ce genre de projet.

Je suis d'accord que le iMX6 n'est pas adapté à des interfaces graphiques, mais les produits à base de iMX8 sont dans les tuyaux. D’autre part, je ne suis pas forcément fan des solutions tout en un pour les systèmes de navigation. En effet, il est pratique d'avoir un système fixe pour toutes les connexions mais le système d'affichage peut être mobile et/ou multiple. Si on ne fait que de l'acquisition (CAN, lignes séries, potentiellement ADC et GPIO et même centrale à inertie) et le traitement associé, l'iMX6 est un meilleur choix.
L'affichage est un problème important mais séparé. Des dispositifs de type tablette peuvent faire très bien l'affaire ou alors on peut développer un afficheur marin spécifique (et là un iMX8 est très bien adapté).

Je ne prétends pas avoir "LA" solution car en fonction des besoins plusieurs architectures peuvent exister et des solutions "tout en un" ont leur place également surtout pour de petites unités. Si le projet se lance, il devra être construit de manière suffisamment modulaire. Pour s'adapter à différentes architectures système et des hardware bien différents. Par exemple, laisser les Mac addict utiliser leur objet totem pour ce qui est affichage et bien sûr les rPiX car leur diffusion les rends incontournable surtout pour les phases de développement et tests. De plus il y aura toujours des bricoleurs qui préfèrent leur solution à une toute faite.

05 août 2020

@sterwen, je pars 100% ton point de vue.

05 août 202005 août 2020

Par exemple, laisser les Mac addict utiliser leur objet totem pour ce qui est affichage

Exactement.

(je ne commenterai pas sur la forme 😉)

05 août 2020

Bonjour,
super projet pour lequel j aurai été très heureux de contribuer et me motive même intégrer vos équipes à Lorient. Malheureusement, nous sommes désormais bien loin et les compétences en c/c++ le sont encore plus (on est vite largué quand on ne code plus). Au pire si vous cherchez des bêta testeurs on a plein de rpi à bord.
Bonne réussite,

librement votre

05 août 2020

Qui pourra le plus pourra-t-il le moins ?
Dit autrement, ces plateformes alternatives que vous souhaitez préparer pourront-elles faire fonctionner plusieurs rs232 pour véhiculer du nmea0183, un nunux assez orthodoxe pour faire tourner les grands classiques (ma sainte trilogie == KPLEX + qtvlm + opencpn) avec un écran ?
J'aime beaucoup mes framboises, mais leurs connectiques me sort un peu par les yeux...

05 août 2020

@BMayer, supporter plusieurs modèle d'acquisition NMEA183, N2K, Modbus, ... c'est quelque chose qui est déja résolu, par mon équipe, comme par d'autre ex: Signal-K. Ce qui est plus compliqué c'est faire une supervision d'un niveau d'eau,d'une ouverture de porte, ou des batteries en mode ultra faible consommation. Il y a aussi des capteurs complexes type radars, sondeurs ou camera qui ont souvent des API fermées, donc complexes à intégrer.

La sainte trilogie pour l'affichage doit forcement être dispo afin d'avoir une première solution rapidement. Par contre à terme il faut malheureusement entièrement réécrire OpenCPN, son code est beaucoup trop monolithique pour l'ajout de nouvelles fonctionnalités à un coup acceptable :
- support de plusieurs écrans avec partage des routes (table à carte, barre à roue, déport sur une tablette, ...)
- support d'input dédié (télécommande, bouton +10/-10, on/off, ...)
- préparation des routes à la maison et envoie sur le bateau via 4G, upload des trace sur le cloud, ...
- routage automatique prenant en compte les points de sondes, les stat AIS, ...
- ajout d'un pilot auto
- etc ...

Pour on commentaire sur les Framboise, la Rasbery n'est pas cher, et possède tout un tas de modules très intéressant, mais c'est c'est pas la carte que je choisirais pour faire le tour du monde. C'est la difficulté de la marinisation, on part d'un truc qui coute 50€ et quand on ajoute tout ce qu'il faut pour gérer l'humidité, la connectique, l’alimentation, l'isolation des entre/sortie on multiplie le prix par 10.

05 août 202005 août 2020

C'est un super projet, et je vous rejoindrais volontiers pour participer !
J'ai plus d'un projet industriel à mon actif, (des projets très grands publics que vous avez et allez très certainement utiliser) et ils ont toujours été passionnants.
Par contre, je ne sais pas si cela peut vous intéresser : en effet, je ne peux pas apporter grand chose sur le plan technique (et je serais même étonné que vous ayez réellement besoin d'aide), au mieux je peux suivre les discussions et comprendre leurs enjeux.
Mais je peux apporter quelque chose sur ce qui est le coeur de mon métier, à savoir la conception fonctionnelle.

En effet, la meilleure technologie du monde (je replacerais "meilleure" par "plus élégante") n'existe pas beaucoup si elle ne réponds pas à des besoins, et ne s'inscrit pas dans des processus viables (le business model n'étant que l'un des processus)
C'est dommage de réaliser de superbes technologies, qui restent en tant que démonstrateurs en mode "ki n'en veut ?"

En particulier, dans la présentation et dans les échanges techniques, il me semble que l'on s’intéresse beaucoup au "comment", mais trop peu au "quoi"
Bref, super intéressé pour contribuer, à voir si ma contribution peut être utile :)

05 août 2020

@peuwi, probablement que la raison principale du focus sur le 'comment' plutôt que le 'quoi' est du au fait qu'avant toute chose, la première étape de tout nouveau projet est de rattraper les projets existants au niveau fonctionnel. Au départ, nous pensions pouvoir repartir d'OpenCPN pour le découper un micro-service, mais après une analyse approfondi du code c'est pas une option viable. Pour la première étape la partie analyse fonctionnelle est donc plutôt simple. Il faut à minima intégrer les fonctionnalités principales d'outils comme:
- OpenCPN
- Signal-K
- kuzzle.io
Le tout dans un environnement ouvert, sécurisé maintenable à long terme et propice à l'ajout de fonctionnalité par une communauté distribuée. Avec mon équipe je pense pouvoir mette en place la plateforme générique et implémenter les services de bases (acquisition, connectivité, carto, ....). Toutefois seule la communauté peut adresser la diversité de l'environnement (radar, capteurs, board, display, ...) de plus il y a des domaines ou l'expertise de mon équipe reste limitée (cartes S57, serveur de tuile vectorielles, algo de pilot, ...).

06 août 2020

J'avais commencé à suivre le fil, j'ai décroché...
Pouvez répéter la question ?

Pour le Mac, facile de garder la (très bonne) base de l'ordinateur et d'y installer un Linux ou Debian quelconque.

06 août 2020

Pour le Mac, mon but c’est de garder l’excellent MacOS, pas de le remplacer par l’expérience utilisateur dégradée d’une distribution Linux.
C’est aussi de developer des applications vraiment natives qui exploitent l’ensemble des frameworks applicables, dont l’accélération GPU Metal, CoreImage... dans une base de code moderne (Swift, Combine, SwiftUI) sur les architectures X86 et Arm, économes en énergie.

Surtout pas des abominations Électron ou QT.

06 août 2020

@jdmuys, en toute sympathie, je ne pense pas que ce soit le lieu idéal pour jouer à la guéguerre des OS, ni pour ce genre de commentaires type "expérience utilisateur dégradée....".
Pour ce genre de trip, je te recommande ce forum.
www.jeuxvideo.com[...]ans.htm

06 août 202006 août 2020

ce n'est pas une guerre. Le Mac est une plateforme qui a une grammaire, et de nombreux détails la composent. Pour un utilisateur Mac, lui proposer de passer à Linux, comme le fait le post à qui je répondais, est une dégradation objective de son expérience utilisateur. C'est tout.

On peut aimer telle ou telle expérience utilisateur Linux. Ca c'est une affaire de goût, et chacun les siens. Mais dire que l'une peut remplacer l'autre est une erreur. Pas de guerre la dedans

06 août 2020

Désolé, je ne vois pas trop ce qu'est une "’expérience utilisateur".
Je me sers d'un OS, le plus simple d'utilisation possible, le moins cher, fiable, c'est tout.

06 août 202006 août 2020

@philgé, DFTT...😉

06 août 2020

C'est une grande chance que de ne pas savoir ce que c'est: on ne la voit pas et on n'en souffre pas quand elle se dégrade. Et Juliusse, ce n'est pas troller que de répondre à quelqu'un qui suggère de changer d'OS.

06 août 202006 août 2020

Mais le troll, c'est quand un sujet est intitulé linux et que quelqu'un vient sans cesse expliquer à quel point son Mac est formidable....
Quand à l'expérience utilisateur, dans le monde du libre, saches que la définition d'user friendly est différente.

06 août 2020

Je suis venu pour dire que l'approche est super bonne, et que je propose ma contribution pour rendre ce code compatible avec le Mac. Désolé que tu trouves que c'est troller.

Le monde du libre a une forte intersection avec le Mac. Et "User Friendly" c'est vrai ou faux indépendamment que le logiciel soit libre ou non (avec une question de degré bien sûr). Je ne vois pas trop en quoi la définition serait différente dans le monde du libre. Mais ça m'intéresse d'être éduqué.

06 août 2020

Les systèmes d'exploitation c'est comme pour la bouffe. On n'aime pas tous la même chose, un point c'est tout.

Comme dit précédemment, je pense qu'il faut un système à base d'API qui laisse un max de liberté aussi bien au niveau infra qu'au niveau des applications clientes. Si quelqu'un veut le support sur OS particulier et qu'il set prêt à l'écrire et le maintenir, je ne vois pas ou est le problème.

Ceci étant dit je fais une grosse différence entre Electron qui installe un sous système complet avec node-js+chrome+dépendances et QT qui link en natif en multi-plateformes. Technologiquement QT est un super outil (même si perso j'aime pas QML). QT est particulièrement bien adapté à l'embarqué et l'équipe de dev est très sympa. Son seul véritable défaut vient de sa double licence GPLV3/commerciale qui interdit de fait un système full "trust-boot".

Si on prend comme exemple, la navigation. L'affichage des cartes doit se faire par "WMS" en servant les tuiles de carto via un outil de type "mapcache" mapserver.org[...]pcache/ ensuite libre à chaque développeur d'utiliser mapbox, leaflet, QT, ... pour faire l'affichage.

06 août 2020

@fulup, tu devrais peut-être du côté de ce qui se fait en sports de plein air, oruxmaps par exemple
Qui au niveau intégration/couplage vaut largement ce qui se fait en nautisme.
www.oruxmaps.com[...]/cs/es

Je dis pas que c'est ce que tu cherches, mais ça peut donner des idées, en plus le dev est très porté OpenSource.

07 août 2020

@juliusse les application de tracking c'est la partie client/application cloud. Ma proposition c'est d'offrir des API type Highmobility github.com[...]uto-api et ensuite de laisser ensuite la communauté faire ce quelle veut.

06 août 2020

Oui je retire le qualificatif de abomination pour QT. C'est vrai que c'est un bon système dans ton contexte. C'est juste pas le bon système pour réaliser des UX natives Mac.

06 août 2020

Très bon projet.
"Débianeux" depuis le siècle dernier, le système de mon futur bateau sera bien sur opensource.
Je suivrai ce projet de près, ainsi que celui de Juliusse que je trouve aussi très bien.
Vu côté fonctionnalités utilisateur, quelles seront les différences par rapport à un OpenPloter?
Merci et encore tous mes encouragements aux volontaires.
De mon côté je testerai...

06 août 2020

@Patxaran, OpenPloter openmarine.net[...]plotter est une distribution marine qui pre-assemble des outils existants pour les processeurs ARMs. D'un point de vu fonctionnel c'est assez proche du projet de @juliusse si ce n'est que lui vise des vieux PC alors qu'OpenPloter vise avant tout des cartes embarquées bas coût type Rasbery.

De mon coté, je regarde à créer de nouvelle briques technologiques. L'objectif est de créer des fondations solides pour un système maritime de nouvelle génération. OpenCPN est un super outil, mais il est tellement monolithique qu'il est impossible de récupérer la partie carto pour faire une projection 3D ou déporter l'affichage sur deux écrans. Signal-K est plus modulaire mais la passerelle est écrite en node-js et ne répondra jamais au niveau de sécurité fonctionnelle nécessaire à un pilote automatique.

La plupart des outils de navigation actuelles ont commencé leur développement à une époque ou les fonctionnalités de Linux n'était pas ce qu'elles sont aujourd'hui. Il est temps de reprendre les composants fonctionnels de base, de les réécrire sur des bases plus moderne, comme par exemple SocketCan pour le NMEA2000 ou GDAL pour la partie cartographie.

Conclusion: l'objectif est de créer une base modulaire et composables afin que les développeurs puissent se concentrer sur la partie fonctionnelle et non pas sur la gestion de la plateforme.

06 août 2020

Un petit peu de hors-sujet en plus ; à force de lire des choses à propos de techno que je ne comprend ab-so-lu-ment pas, je reste viscéralement attaché à ma chtite console 24x80 (avec les caractères en couleur, je vous l'accorde)
:-D ok, je sors :-D :-D :-D

06 août 2020

@fulup:
merci. Une sorte de "framework".
Concernant l'OS, venant du monde VMS (Digital), je trouve que sa principale qualité est de se faire oublier.
AMHA ce qui me semble le plus difficile à sentir pour un Win ou un Mac addict, c'est que l'OS est complètement modulable : juste en ligne de commande avec ou sans applis Web, serveur graphique, choix du Window manager, avec ou sans Desktop, choix d'une apparence, etc....
Et à présent sur de l'embarqué il existe un projet Yocto qui permet de faire "son" Linux.
Donc faites au mieux avec ce que vous maîtrisez bien...

07 août 2020

Toujours la guéguerre des OS... Ca change de la gueguerre des matériaux de coques.

15 nov. 2020

"Au final un bateau c'est une voiture sans roue"

👍

Et une voiture, un bateau sans voiles ?

😄😂

Votre réponse

Merci de contribuer aux réponses sur HISSE ET OH !

Merci de vérifier de bien répondre au sujet. Fournisser des détails sur votre réponse et partager votre expérience et vos recherches !

Mais éviter de …

  • Demander de l'aide ou de répondre à une autre question (utiliser les commentaires dans ce cas).
  • Porter un jugement et manquer de respect dans votre réponse.
  • Pour plus d'information, consulter la FAQ et la Charte de HISSE ET OH !

Déposer un fichier ici ou Cliquer pour envoyer

Souvenir d'été

  • 4.5 (90)

novembre 2021