Linux & Navigation (analyse d'idées)

super projet !!!

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).

@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 😉🖖

@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.

@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.

@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.

@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.

@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 :)

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"

@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.

@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.

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

@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.

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

Exactement.

(je ne commenterai pas sur la forme 😉)

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...

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 :)

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.

@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

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.

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.

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é.

@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.

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.

@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.

@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...

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

👍

Et une voiture, un bateau sans voiles ?

😄😂