Projet d’équipe de dernière année. 2026-2027. En cours.
Usine 4.0, en cours, et trois études personnelles
Cette année, ma promotion mène un projet d’équipe sur l’Usine 4.0 (Industrie 4.0, usine connectée). Il est en cours : cette page n’en montre donc rien. Elle montre ce que j’ai étudié de mon côté sur le même thème : combien de robots mobiles une allée d’usine peut accueillir avant de se bloquer, et, plus brièvement, jusqu’où faire confiance aux chiffres d’un tableau de bord d’usine et d’un contrôle qualité visuel.
En trois lignes
- Problème
- Le projet de promotion sur l’Usine 4.0 (Industrie 4.0, usine connectée) est en cours, donc il n’y a encore rien à en montrer. Sur le même thème, j’ai pu étudier seul une question : combien de robots mobiles autonomes une allée d’usine peut-elle accueillir avant de se bloquer ?
- Ce que j’ai réalisé
- De mon côté, pas pour le projet de promotion : amr-traffic-lab, une étude par simulation à graine aléatoire fixée, avec un nouvel A* sur grille, un axe temporel, une table de réservations et du Conflict-Based Search, sur trois plans d’usine dessinés à la main, avec un contrôle de sécurité qui recompte les conflits à chaque pas de temps.
- Résultat
- De l’étude personnelle, pas du projet de promotion : le gestionnaire à réservation ne s’est jamais bloqué (0 simulation d’une heure sur 600). Dans l’atelier ouvert, il livre 24 % de commandes de plus par heure que le gestionnaire naïf avec 16 robots, et aucune collision n’est survenue sur 3 473 858 pas de temps simulés.
Contexte
Le projet de promotion
Cette année, 2026-2027, ma promotion mène un projet d’équipe de dernière année sur l’Usine 4.0 (Industrie 4.0, usine connectée), l’un des principaux secteurs visés par la formation SRI. Il est en cours.
C’est tout ce que cette page en dit. Aucun partenaire, aucune plateforme, aucun robot ni résultat n’est revendiqué.
Ce que j’ai étudié seul
Le thème a soulevé une question que mon travail à l’AIST avait laissée ouverte. J’y ai écrit un planificateur A* pour un seul robot sur une grille d’occupation, et préparé une interface ROS 2 pour Kachaka, un robot mobile qui s’arrime sous une étagère et la transporte. Un seul robot sur une carte vide ne rencontre jamais la première question que l’usine connectée (Usine 4.0) pose à une flotte : que se passe-t-il quand une douzaine de robots partagent une seule allée ?
amr-traffic-lab est ma réponse, un projet personnel réalisé en octobre 2026 avec l’aide d’une IA, indépendant du projet de promotion. Deux études personnelles plus courtes sur le même thème viennent juste après, dans les résultats.
Ce que j’ai réalisé
Ce que contient l’étude
Le plan est une carte texte transformée en grille 4-connexe d’allées, de stations de prise, de stations de dépose et de chargeurs. Une cellule fait 1 m et un pas de temps dure 1 s. J’ai écrit pour elle un nouvel A* sur grille (pas le planificateur de l’AIST), puis lui ai ajouté un axe temporel, une table de réservations et du Conflict-Based Search.
Deux gestionnaires de trafic traitent les mêmes commandes, tirées avec la même graine aléatoire. Le naïf suit son propre plus court chemin, cède la place quand la cellule devant est prise et replanifie après une attente aléatoire. Le gestionnaire à réservation planifie chaque trajet contre une table de tous les chemins engagés, de sorte que les conflits de sommet et d’échange sont exclus dès la planification, et le plus ancien trajet inachevé n’attend jamais : sur un plan bien formé, la flotte ne peut pas se bloquer.
Le Conflict-Based Search, pour un ensemble fixe de paires départ-arrivée, minimise la somme des coûts des chemins. Ses réponses sont comparées à une recherche exhaustive en espace d’états joint qui ne partage aucun code avec lui.
Un pas de temps simulé
- 01Commandes à graine fixéede la prise à la dépose, une file qui ne se vide jamais
À chaque pas de temps, jusqu’à la fin de l’heure ou l’interblocage de la flotte
- 02Répartiteur (dispatcher)robot libre le plus proche, verrous de stations
- 03Gestionnaire de traficnaïf : son propre itinéraire A*, attente, replanification locale. Réservation : A* espace-temps contre la table de réservations
- 04Déplacement joint du pas de tempsun pas de temps dure 1 s, une cellule fait 1 m
- 05Contrôle de sécuritéconflits de sommet et d’échange, recomptés à partir des positions
- 06Positions au pas de temps suivantlivraisons et test d’interblocage
Résultats
Résultats de l’étude personnelle
Tout ce qui suit, jusqu’aux deux études plus courtes à la fin, vient d’amr-traffic-lab, ma propre étude par simulation. Rien de cela n’est un résultat du projet de promotion.
0 / 600
simulations d’une heure bloquées avec le gestionnaire à réservation, sur trois plans et dix tailles de flotte jusqu’à 16 robots, 20 graines par cellule.
427,2→528,9commandes/h
Atelier ouvert, 16 robots : commandes livrées par heure avec le gestionnaire naïf, puis avec le gestionnaire à réservation (24 % de plus). Chacune est la moyenne de 20 simulations d’une heure à graine fixée.
0
conflit de sommet ou d’échange sur 3 473 858 pas de temps simulés (1 200 simulations, les deux gestionnaires), comptés par un contrôle qui ne partage aucun code avec les planificateurs.
| Ce qui a été mesuré | Valeur | Comment le lire |
|---|---|---|
| Atelier ouvert, 16 robots : commandes par heure, naïf puis réservation | 427,2 → 528,9 | Le gestionnaire naïf se bloque rarement dans l’atelier ouvert (3 simulations sur 200), c’est donc la comparaison juste. Dans les allées étroites, il se bloque dans 95 simulations sur 200. |
| Allées étroites, 16 robots : simulations bloquées avec le gestionnaire naïf | 19 / 20 | Commandes par heure : 117,7 (plage de 2 à 445) contre 776,1 avec la réservation. |
| Couloir unique, 2 robots ou plus : simulations bloquées avec le gestionnaire naïf | 180 / 180 | Structurel, pas une surprise : une voie unique sans zone de croisement bloque tout gestionnaire qui laisse les robots entrer par les deux bouts et ne recule jamais. Un verrou qui n’admet qu’un sens à la fois serait une référence plus juste, et l’étude n’en mesure pas. |
| Couloir unique, gestionnaire à réservation : commandes par heure avec 10 robots, puis 16 | 299,7 → 303,4 | Le seul vrai palier : l’allée est la limite, avec 27,7 % du temps de trajet passé à attendre la voie à 16 robots. Sur les deux autres plans, la courbe monte encore à 16 robots. |
| Allées étroites, 8 agents, planification en une passe : instances résolues par CBS, puis par planification par priorités | 5 / 25 → 17 / 25 | Le CBS retourne la somme des coûts optimale mais épuise son budget de 2 000 nœuds. La planification par priorités répond en millisecondes (médiane de 2,38 ms contre 944 ms). |
| CBS contre une recherche exhaustive sur 400 petites instances aléatoires | 334 / 334 | Le coût égale l’optimum en espace d’états joint sur chaque instance que le CBS a terminée. Sur les 336 instances résolubles, 2 ont épuisé le budget. |
Deux études plus courtes sur le même thème
usine40-cell-pipeline fait passer une cellule de production simulée par OPC UA, MQTT, PostgreSQL et Grafana et compare l’OEE (taux de rendement synthétique) du tableau de bord au journal d’événements du simulateur. visual-quality-gate réimplémente PaDiM et PatchCore sur cinq catégories de MVTec AD et demande ce que coûte un contrôle qualité visuel quand il faut choisir son seuil.
Ce sont deux projets personnels d’octobre 2026, indépendants du projet de promotion. Un résultat de chacun :
| Ce qui a été mesuré | Valeur | Comment le lire |
|---|---|---|
| usine40-cell-pipeline : plus grand écart entre l’OEE stocké par le pipeline et l’OEE du journal d’événements, sur 3 600 fenêtres de station de 30 s | 0,000 pp | Rien n’est perdu ni inventé entre l’automate simulé et le tableau de bord ; cela ne montre pas que l’OEE est le bon indicateur. Une coupure du broker de 60 s en QoS 0 laisse 45 fenêtres sur 240 avec un OEE faux. |
| visual-quality-gate : bonnes pièces refusées par PatchCore WR50-10% quand le seuil, fixé sur des bonnes pièces mises de côté, vise 5 % | 43 / 408 (10,5 %) | Sur 3 graines, soit 2,1 fois la cible, alors que 85 pièces défectueuses sur 1 353 (6,3 %) passent quand même. |
Ce qui a échoué ou reste inachevé
0 / 25
instances en une passe des allées étroites à 12 agents que le Conflict-Based Search a résolues dans son budget de 2 000 nœuds. La planification par priorités en a résolu 3 sur 25.
Le projet de promotion n’est pas terminé. Il est en cours, donc rien n’en est montré, mesuré ni revendiqué sur cette page.
Le résultat du couloir est structurel. Le gestionnaire naïf ne recule jamais, et une voie unique n’a pas de zone de croisement : son résultat sur le couloir surestime donc ce que les réservations apportent par rapport à un verrou qui n’admet qu’un sens à la fois. L’atelier ouvert et les allées étroites sont les comparaisons les plus justes.
Le CBS ne passe pas à l’échelle ici. C’est du Conflict-Based Search simple, avec un budget de nœuds et sans aucune des améliorations qui rendent les solveurs modernes rapides, et il ne peut pas prouver qu’une instance est insoluble. C’est une référence pour de petites instances seulement.
Un monde de grille. Les déplacements prennent un pas de temps sur une grille 4-connexe : pas d’accélération, de temps de rotation, d’empreinte de robot ni d’erreur de localisation. Les chemins réservés sont exécutés parfaitement, alors qu’une vraie flotte a besoin de marges ou de replanification quand un robot est en retard.
Une demande sans fin, ni batteries, ni machines. Les chargeurs sont des places de stationnement, les stations sont toujours prêtes et la file de commandes ne se vide jamais. L’étude mesure la capacité, pas le temps d’attente d’une commande dans une file.
Trois plans dessinés à la main, des flottes jusqu’à 16. Dans l’atelier ouvert et les allées étroites, la meilleure flotte est une borne inférieure, puisque la courbe monte encore à 16 robots, le maximum que les chargeurs peuvent garer. Les allées à sens unique, la solution d’ingénierie habituelle, ne sont pas étudiées.
Les deux études plus courtes sont petites. usine40-cell-pipeline fait tourner une cellule simulée, et une erreur d’OEE nulle montre que rien n’est perdu ni inventé en chemin, pas que l’OEE est le bon indicateur. visual-quality-gate couvre cinq des quinze catégories de MVTec AD, et sa plus grande banque mémoire PatchCore (WR50-10%) a refusé des bonnes pièces environ deux fois plus souvent que la cible.
Crédits
amr-traffic-lab est un projet personnel écrit en octobre 2026 avec l’aide d’une IA : ses commits portent la mention Co-Authored-By. Chaque nombre de cette page est régénéré par un script versionné, et un second script vérifie le README contre les résultats.
usine40-cell-pipeline et visual-quality-gate sont aussi des projets personnels d’octobre 2026, écrits avec l’aide d’une IA et versionnés avec une mention Co-Authored-By ; leurs nombres sont régénérés par des scripts versionnés.
L’A* sur grille de l’étude est du code nouveau, pas le planificateur du stage à l’AIST.
Les méthodes viennent de la littérature : A* espace-temps avec table de réservations (Silver, 2005), Conflict-Based Search (Sharon, Stern, Felner et Sturtevant, 2015), et le cadre en flux continu (lifelong) bien formé (Ma, Li, Kumar et Koenig, 2017 ; Čáp, Vokřínek et Kleiner, 2015).
Liens
- amr-traffic-lab : l’étude par simulation (dépôt)
- La même étude sur la page du labo, avec sa vidéo
- usine40-cell-pipeline : la cellule simulée, d’OPC UA à Grafana (dépôt)
- visual-quality-gate : PaDiM et PatchCore comme contrôle qualité (dépôt)
- nav_3dgs_pano : le planificateur A* à un seul robot du stage à l’AIST
- KachakaNavigation : l’interface ROS 2 préparée pour le robot Kachaka