Computer Vision • Semantic Segmentation • Data augmentation • Keras • TensorBoard • FastAPI/Flask • Docker/AWS •Tests unitaires
Segmentation embarquée pour véhicule autonome
-
Cadre
Vision embarquée temps réel
-
Domaine
Deep Learning (segmentation)
-
Approche
Benchmark + arbitrages + déploiement
-
Objectif
8 classes, focus “human”
Contexte & contraintes produit
Ici, la segmentation est un composant opérationnel d’une chaîne perception→décision : le critère n’est pas “un bon score”, mais une solution déployable et réactive, avec un modèle léger (cible <100 Mo) et une latence maîtrisée.
La difficulté centrale vient du déséquilibre de classes typique des scènes urbaines : les classes majoritaires (route/ciel) dominent l’apprentissage et dégradent les classes rares mais critiques (human, object). Le projet est donc piloté par des métriques utiles terrain (IoU par classe) et par un suivi expérimental strict (logs complets + visualisations TensorBoard).
Un modèle léger + un démonstrateur en ligne, pensé comme un mini-produit
Pipeline d’entraînement “terrain-first”
Pipeline Keras (DataGenerator custom)
• Encodage one-hot (8 classes)
• Augmentations + préparation des masques
• Sample weights dynamiques pour compenser le déséquilibre (classes rares/critiques)
Objectif : améliorer l’IoU par classe (humans/objects), pas seulement la moyenne
Entraînement & suivi
• Callbacks : early stopping, checkpoint, LR scheduling
• TensorBoard : courbes + métriques (suivi des essais)
Comparaison d’architectures & sélection
J’ai benchmarké plusieurs familles (U-Net + backbones, FPN, PSPNet, DeepLabV3+) en suivant une grille de décision simple :
• IoU global ne suffit pas → pilotage par IoU par classe
• Priorité à la classe human (obstacle critique)
• Compromis performance / robustesse / poids / latence
Le modèle final est le résultat d’un arbitrage assumé : meilleur compromis pour un usage embarqué.
Points clés
Objectif : 8 classes, priorité aux obstacles (human/object)
Contrainte produit : modèle léger (déploiement réaliste)
Pilotage : IoU global + IoU par classe (éviter l’illusion de la moyenne)
Itération outillée : comparaisons reproductibles (TensorBoard, diagnostics)
Benchmark (U-Net + backbones, FPN/PSPNet/DeepLabV3+) et sélection sur un critère simple : gain obstacles vs coût poids/latence/complexité.
Cheminement & arbitrages
1) Constats : bonne perf sur classes majoritaires, faiblesse sur classes rares (obstacles).
2) Action prioritaire : correction du déséquilibre → sample weights + pondération progressive (avant de complexifier le modèle).
3) Méthode : itérations courtes et comparables, avec TensorBoard (métriques par classe + projecteur 3D pour repérer séparabilité/confusions).
Démonstrateur en ligne
J’ai livré un démonstrateur complet, testable sans notebook: webapp pour visualiser la segmentation, et surtout un endpoint FastAPI /predict pour consommer le modèle par API et l’intégrer dans une chaîne acquisition → segmentation → décision (embarqué / cloud).
• API FastAPI : endpoint /predict (image → masque colorisé + temps de traitement + IoU si GT fourni).
• Webapp Flask : upload, visualisation avec superposition, légende dynamique, gestion du ratio/masques, etc.
• Docker + AWS EC2 : déploiement reproductible et tests de charge avec Locust.
Résultat: Qualité et performance testables
Qualité de segmentation (modèle retenu)
• meanIoU test : 0.7347
• IoU “human” : 0.4418 (classe prioritaire “obstacle critique”)
Réactivité & robustesse (mesurée)
• Inference : ~25 ms / image (ordre de grandeur à cette résolution)
• Charge (Locust) : plus rapide en local, hausse attendue sur EC2 (réseau + infra)
→ p50 ~100–200 ms (local) vs ~600–1200+ ms (EC2), p95 > 1 s sur certains paliers
Apports du projet
Du modèle à une fonctionnalité : segmentation + API + UI, testable en démo
Arbitrage produit assumé : privilégier l’usage (poids/latence/robustesse) plutôt que la performance “pure”
Focus sécurité/obstacles : pilotage par IoU par classe pour sécuriser les classes critiques (human/object)
Démarche rigoureuse & partageable : expérimentation tracée (TensorBoard, comparaison d’essais) + livrable pédagogique
Compétences techniques mobilisées
Modélisation segmentation : U-Net, DeepLabV3+, FPN, PSPNet (benchmark & sélection)
Données & entraînement : DataGenerator custom, augmentation, compensation du déséquilibre (poids dynamiques)
Évaluation & observabilité : IoU global + par classe, logging TensorBoard (analyse & diagnostic)
Mise en service : API FastAPI, webapp Flask (UI HTML/CSS/JS), packaging Docker, déploiement cloud
Stack & ressources
TensorFlow/Keras · Albumentations · TensorBoard · FastAPI · Flask · Docker · AWS EC2 · Locust