CARIA Automotive · Cockpit

Première version de l’interface intérieure : accueil multimédia et instrumentation automobile, indépendants du matériel. Le projet scolaire original reste dans WebControl/ ; le cockpit utilise ui/ et server/.

Démarrage avec Docker

Prérequis : Docker Engine et Docker Compose, avec des conteneurs Linux.

docker compose up -d --build

Ouvrir http://localhost:8080 sur la machine hôte, ou http://ADRESSE_DU_SERVEUR:8080 depuis un écran connecté au même réseau.

docker compose ps
docker compose logs --tail=50
docker compose down

Le port est configurable avec CARIA_PORT dans un fichier .env à la racine (exemple : CARIA_PORT=8090). Deux services : Nginx sert l’interface et relaie /api/ vers le simulateur Node.js. Seul le port de l’interface est publié. Aucun périphérique ni privilège matériel n’est demandé.

Les images de base ne forcent pas l’architecture. La construction sur l’ODroid utilisera les variantes disponibles pour son système. Le modèle, l’OS et l’architecture de l’ODroid restent à confirmer avant de garantir la compatibilité, notamment si son OS est en 32 bits. Le déploiement Docker n’a pas pu être exécuté sur le poste de développement, où Docker est absent.

Démarrage sans Docker

Avec Node.js 22 ou supérieur, sans installation de paquet :

node server/server.mjs

Le serveur local sert également les trois fichiers de l’interface, sur le même port 8080. HOST et PORT permettent de modifier l’écoute. Docker reste la méthode prévue pour le déploiement final.

Fonctions disponibles

Accueil : heure/date de l’appareil, météo de démonstration, carburant/autonomie et accès à la musique.
Conduite : vitesse et régime moteur à aiguilles SVG, rapport, carburant, température moteur, tension batterie, consommation et trajet simulés.
Musique : sélection multiple de fichiers audio locaux, liste de lecture, lecture/pause, précédent/suivant, progression et volume via le lecteur natif. Les fichiers restent sur l’appareil qui affiche le navigateur ; ils ne sont pas transférés au serveur. La sélection doit être refaite après un rechargement. Une bibliothèque persistante sur disque/USB côté serveur pourra être ajoutée ensuite.
Streaming : lien Jellyfin préconfiguré vers https://media.cunatbrule.fr/web/, modifiable dans les réglages. Ouverture dans un autre onglet ; aucune intégration de compte ni lecteur vidéo Jellyfin embarqué à ce stade.
Réglages : ambiance jour/nuit, adresse du streaming, raccourcis pour ouvrir deux écrans et bouton plein écran. Les réglages sont conservés dans le stockage local du navigateur.

Le menu à gauche contient les quatre applications : accueil, conduite, musique et streaming. Les réglages sont en bas. La météo est fictive et explicitement marquée « DÉMO » ; l’heure est réelle. L’interface et la musique sélectionnée fonctionnent sans Internet tant que le serveur local est accessible. Jellyfin dépend de l’accès à son serveur.

Un ou plusieurs écrans

Instrumentation : http://ADRESSE_DU_SERVEUR:8080/#drive
Multimédia : http://ADRESSE_DU_SERVEUR:8080/#home

Chaque écran ouvre sa propre page. Les valeurs proviennent du même serveur. Le profil route/ville/arrêt se synchronise entre les onglets d’un même navigateur et d’une même origine ; sur deux appareils, sélectionner le même profil sur chacun. Les fichiers audio et réglages restent propres à chaque navigateur.

Docker héberge l’application ; l’affichage tactile, le son et le navigateur en mode kiosque restent gérés par l’OS de l’ODroid. L’écran peut aussi utiliser un serveur distant. Aucun environnement graphique n’est embarqué dans les conteneurs.

Architecture et suite CAN

Navigateur ODroid / tablette / second écran
                 │ HTTP :8080
                 ▼
         Interface Nginx (ui/)
                 │ /api/telemetry
                 ▼
         Simulateur Node.js (server/)

Étape suivante : passerelle Raspberry Pi CAN → données normalisées → interface

L’interface utilise HTML/CSS/JavaScript sans framework, sans CDN ni police distante. Les compteurs SVG s’adaptent à la résolution, avec une actualisation toutes les 500 ms et une transition d’aiguille. Le serveur utilise uniquement les modules standard de Node.js. Aucun gain de performance sur ODroid n’est encore mesuré.

La passerelle CAN est un futur composant : pas de décodage Mégane III, de SocketCAN ni de commande véhicule dans cette version. Elle pourra être écrite indépendamment en Python, Rust, C++ ou JavaScript. Le contrat proposé est décrit dans docs/architecture.md. Le passage à des données réelles nécessitera également une adaptation de leur validation et de leurs indicateurs dans l’interface.

Navigation, météo réelle, alertes radar et bibliothèque audio sur le serveur sont des étapes ultérieures. Les composants techniques choisis sont open source ; le dépôt historique n’a pas de licence globale, à définir avant une distribution publique du projet complet en tenant compte des fichiers tiers.

Validation

node --test server/telemetry.test.mjs
node --check ui/app.js

Tests exécutés : contrat HTTP, limites des données simulées, profil invalide, API en lecture seule et impossibilité d’accéder aux fichiers du projet historique via le nouveau serveur. Tests Chrome automatisés : quatre vues à 1280×800, 1024×600, 800×480 et 390×844, absence de débordement horizontal, réglages persistants, lien Jellyfin, lecture de deux WAV locaux, changement de piste et retour après coupure API. Les captures accueil et conduite ont été examinées. Défilement vertical possible sur petits écrans selon la vue.

À valider sur la cible : Docker/Compose, architecture ARM exacte, résolution et densité de l’écran, tactile, sortie audio, démarrage kiosque, consommation CPU/RAM et lecture Jellyfin réelle avec le compte utilisateur. Le lien Jellyfin a été vérifié dans l’interface, sans connexion au service ni test de son contenu.

Voir l’audit du dossier historique.

Références de déploiement : services et healthchecks Docker Compose, image officielle Nginx.

6.4 KiB Raw Blame History Unescape Escape