img
img
  • 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

img img

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

img img

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

img img

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