Creation nouvelle interface Docker Vehicule et Multimedia
This commit is contained in:
@@ -0,0 +1,47 @@
|
||||
# Contrat et déploiement
|
||||
|
||||
## API de démonstration v1
|
||||
|
||||
`GET /api/health` renvoie `{"status":"ok","source":"demo"}`.
|
||||
|
||||
`GET /api/telemetry?profile=route` renvoie un instantané JSON. Profils : `route`, `ville`, `arret`. Un profil inconnu renvoie HTTP 400. Les écritures renvoient HTTP 405. L’API n’accepte aucune commande moteur.
|
||||
|
||||
| Champ | Type / unité | Usage |
|
||||
| --- | --- | --- |
|
||||
| schemaVersion | entier, 1 | Version du contrat |
|
||||
| source | `demo` | Provenance explicite |
|
||||
| timestamp | millisecondes Unix | Fraîcheur des données |
|
||||
| profile | texte | Profil simulé |
|
||||
| speedKph | nombre, km/h | Vitesse |
|
||||
| rpm | nombre, tr/min | Régime moteur |
|
||||
| gear | texte | Rapport, N à l’arrêt |
|
||||
| fuelPercent | nombre, % | Niveau carburant |
|
||||
| coolantCelsius | nombre, °C | Liquide de refroidissement |
|
||||
| batteryVolts | nombre, V | Batterie |
|
||||
| outsideCelsius | nombre, °C | Température extérieure |
|
||||
| rangeKm | nombre, km | Autonomie |
|
||||
| tripKm | nombre, km | Trajet fictif constant |
|
||||
| consumptionL100 | nombre, L/100 km | Consommation fictive |
|
||||
| weather | objet | Source, description, température fictives |
|
||||
|
||||
La vitesse et le régime évoluent ; les autres valeurs sont des exemples fixes, sauf la température moteur à l’arrêt. Il ne s’agit pas d’un modèle physique du véhicule. Le temps du serveur produit une animation cohérente entre clients utilisant le même profil.
|
||||
|
||||
Le client refuse les instantanés mal formés ou vieux de plus de 10 secondes, avec une limite de 3 secondes pour chaque requête. En cas de coupure il masque les aiguilles, remplace les mesures par des tirets et retente automatiquement. Les horloges du serveur et des écrans doivent être synchronisées ; un écart de plus de 10 secondes sera traité comme une donnée invalide.
|
||||
|
||||
## Passage à une source CAN
|
||||
|
||||
Prévoir un processus de lecture sur le Raspberry Pi, avec accès au périphérique CAN uniquement sur cette machine. La découverte des identifiants, facteurs, unités et fréquences des trames de la Mégane III reste à réaliser à partir des données du véhicule. Ne pas déduire les identifiants CAN de cette démonstration.
|
||||
|
||||
La passerelle produira le contrat normalisé, avec une source `can`, des valeurs manquantes explicites et un horodatage par signal si nécessaire. La version actuelle du client n’accepte volontairement que `demo` : adapter la validation, les limites par champ et les indicateurs source/fraîcheur lors de cette étape. Choisir ensuite le transport Raspberry → service (HTTP, MQTT ou WebSocket) selon le réseau et la fréquence nécessaires.
|
||||
|
||||
Le simulateur et la future passerelle doivent être sélectionnés explicitement ; ne jamais substituer silencieusement des valeurs fictives à une liaison CAN perdue.
|
||||
|
||||
## Évolutions indépendantes
|
||||
|
||||
- Bibliothèque audio persistante : volume en lecture seule, catalogue et prise en charge des requêtes Range ; la musique serait alors lue depuis le serveur plutôt que choisie dans l’appareil client.
|
||||
- Météo réelle : fournisseur à définir, position configurable, cache et date de dernière mise à jour.
|
||||
- Cartographie/radar : fournisseur open source, besoin hors ligne, zone géographique et données à définir avec l’utilisateur.
|
||||
- Affichage : kiosque Linux et configuration des moniteurs au niveau de l’OS ; paramètres propres à chaque écran si nécessaire.
|
||||
- Distribution : figer les images par version/digest une fois la première construction ARM validée ; ajouter une construction automatisée multiarchitecture au dépôt si son hébergement CI le permet.
|
||||
|
||||
Les tags Docker actuels suivent Node 22 Alpine et Nginx stable Alpine. Ils facilitent ce prototype mais ne rendent pas les builds strictement reproductibles.
|
||||
@@ -0,0 +1,57 @@
|
||||
# Audit initial — 12 septembre 2026
|
||||
|
||||
## Périmètre
|
||||
|
||||
Inventaire de tous les fichiers de travail de CARIA-AUTOMOTIVE, examen du serveur, des interfaces, des scripts de lancement, des modules et scénarios Python et des dépendances. `WebControl/` contient 53 fichiers, environ 2,33 Mo. Le projet comporte aussi `.gitignore`, un README initial minimal et les métadonnées Git. Les binaires, polices, bibliothèques JavaScript/CSS tierces et journaux ont été inventoriés ; ils ne font pas l’objet d’un audit exhaustif de leur contenu. Les certificats n’ont pas été reproduits dans le rapport.
|
||||
|
||||
L’application matérielle n’a pas été exécutée : elle initialise les GPIO et le port série et certains scripts commandent les moteurs. Aucune connexion au véhicule n’a été tentée.
|
||||
|
||||
## Organisation trouvée
|
||||
|
||||
| Dossier / fichier | Rôle |
|
||||
| --- | --- |
|
||||
| `WebControl/main.py` | Serveur Bottle, commandes robot, pages, résultats d’accès et commandes système |
|
||||
| `WebControl/MainCLIControl.py` | Menu CLI de lancement des scénarios/tests |
|
||||
| `WebControl/templates/` | Administration, accès, page de tests presque vide |
|
||||
| `WebControl/js/` et `css/` | jQuery, Bootstrap et compteur de vitesse bitmap |
|
||||
| `WebControl/images/` et `fonts/` | Fond du compteur, aiguille, police LED et Glyphicons |
|
||||
| `WebControl/modules/AlphaBot.py` | GPIO, moteurs PWM, servo, lidar série, obstacles et journalisation |
|
||||
| `WebControl/modules/*MFRC522*` | Lecteur RFID et accès SPI |
|
||||
| `WebControl/apps/` | RFID, scénario de porte, itinéraires, lidar et évitement d’obstacles |
|
||||
| `WebControl/tests/` | Essais physiques, pas une suite de tests unitaires |
|
||||
| `WebControl/logs/` | Journaux d’exécution, résultats et trajets JSON |
|
||||
| `WebControl/install/` | Liste figée de nombreux paquets du poste Raspberry Pi |
|
||||
| `WebControl/fixs/`, `webcontrol-launch.sh`, `NOTE.txt` | Redémarrage, Motion, RFID, crontab et sudo |
|
||||
| `WebControl/sendMyIP.py` | Exemple d’envoi d’adresse IP vers un endpoint fictif |
|
||||
| `WebControl/ssl/` | Certificat et clé présents dans le dépôt historique |
|
||||
|
||||
## Constats qui déterminent la nouvelle architecture
|
||||
|
||||
1. **Couplage matériel au démarrage** : `main.py` instancie `AlphaBot`, qui ouvre `/dev/ttyAMA0` et initialise les GPIO. L’interface ne peut donc pas être simplement transférée sur un PC ou ODroid sans le matériel et ces bibliothèques.
|
||||
2. **Chemins et adresses figés** : `/home/christian/WebControl`, adresses `192.168.253.194`, commandes `sudo`, dépendance à Motion. Le nouveau cockpit utilise des URL relatives et une configuration Docker.
|
||||
3. **Vitesse non mesurée** : le curseur historique pilote un rapport cyclique PWM ; ce n’est pas une vitesse réelle en km/h. Le nouveau compteur est alimenté par des valeurs explicitement simulées. Son mapping d’aiguille couvre directement -130° à +130°.
|
||||
4. **Distribution des fichiers trop large** : la route générique de Bottle sert depuis `./`, avec en plus des routes vers modules, scripts et templates. Avec le répertoire de lancement prévu, les sources et fichiers SSL peuvent être demandés via HTTP. La nouvelle image web ne copie que ses fichiers publics ; l’ancien dossier est exclu du contexte Docker.
|
||||
5. **Commandes système et robot accessibles par HTTP sans authentification apparente** : reboot, Motion, scripts et moteurs sont mélangés à l’administration. Ces fonctions ne font pas partie du nouveau cockpit, qui fournit une API en lecture seule.
|
||||
6. **Dépendances non portables** : le fichier d’installation ressemble à un export complet du système scolaire, incluant GPIO, bureau et paquets anciens. La nouvelle version n’en dépend pas.
|
||||
7. **Licence globale absente** : certains modules tiers contiennent des notices propres (MFRC522 notamment). Il faudra clarifier les licences avant diffusion publique du dépôt complet.
|
||||
|
||||
## Anomalies historiques repérées (non corrigées dans ce lot)
|
||||
|
||||
- `js/script.js` associe tous les boutons à `/cmd`, y compris ceux sans lien avec la conduite, et lie plusieurs événements aux curseurs.
|
||||
- `js/test_status.js` appelle `/test_status`, sans route correspondante dans le serveur lu.
|
||||
- Le template utilise `testRFIDCarDoor`, alors que le serveur attend `appRFIDCarDoor`.
|
||||
- `modules/joyit_mfrc522/__init__.py` importe `.SimpleMFRC522`, absent de ce sous-dossier ; un fichier homonyme est au niveau supérieur.
|
||||
- `itineraire_suivre_emergency_speed.py` attend sur `Ab.vitesse_queue.get()` avant de démarrer le producteur. `execute_maneuver` y a deux paramètres mais plusieurs appels en passent trois.
|
||||
- `AlphaBot.monitor_obstacle` utilise une variable globale du module, distincte de celle des scénarios ; sa boucle d’attente d’un obstacle ne consulte pas l’événement d’arrêt.
|
||||
- `AlphaBot.monitor_vitesse` peut boucler sans pause lorsqu’aucune trame n’est disponible.
|
||||
- Le scénario RFID attribue `scenario successful` puis compare le statut final à `movement successful`.
|
||||
|
||||
Ces éléments justifient de conserver le projet scolaire comme référence et de développer l’interface multimédia dans des dossiers dédiés. Ils ne constituent pas une certification du fonctionnement des autres chemins du robot.
|
||||
|
||||
## Références DEMO-Interfaces
|
||||
|
||||
Inventaire du launcher Python/Tkinter NUC (raccourcis Windows, applications, images, arrière-plans), de sa capture `Interface GUI 2025/interface.png` et des projets Tasker auto/moto (XML, APK et images). Le launcher repose sur des chemins Windows et des exécutables locaux. Inspiration retenue : applications clairement identifiables, grands boutons et thème sombre. La nouvelle interface réinterprète ces principes avec quatre accès latéraux et un accueil central ; les exécutables/APK n’ont pas été lancés et les assets tiers n’ont pas été copiés.
|
||||
|
||||
## Livraison de cette étape
|
||||
|
||||
`ui/` fournit les vues multimédia et conduite ; `server/` fournit les données de démonstration ; `compose.yaml` sépare les deux services. Le code historique reste inchangé. Voir le README pour les validations exécutées et les limites matérielles restantes.
|
||||
Reference in New Issue
Block a user