ROS 2 en production : ce qu'une flotte de robots nous a appris

Le contexte

La robotique est une de nos quatre expertises, au même titre que le web, la data et le cloud. On en parle moins parce qu’elle se voit moins. Pourtant, c’est là que le code rencontre le monde physique, et où une erreur ne se règle pas par un rollback.

Sur un projet de navigation autonome pour une flotte de robots industriels (hub Tokyo, ROS 2 et vision), on a tiré des leçons qui valent au-delà de ce projet précis.

Six leçons de terrain

1. ROS 2 n’est pas ROS 1 avec un numéro en plus. Le passage au DDS pour la communication change la donne sur la fiabilité et la configuration réseau. Le sous-estimer coûte cher.
2. Le temps réel se conçoit, il ne se rattrape pas. Les contraintes temps réel doivent guider l’architecture dès le premier jour. On ne « rend pas temps réel » un système conçu sans.
3. La simulation n’est pas la réalité. Un comportement validé en simulation échoue sur le terrain pour des raisons triviales : lumière, poussière, sol irrégulier. Le test physique reste irremplaçable.
4. La flotte n’est pas un robot multiplié. Coordonner plusieurs robots introduit des problèmes propres : conflits de trajectoire, partage de zone, reprise après panne d’une unité.
5. L’observabilité s’applique aussi aux robots. On veut savoir ce qu’a « vu » et « décidé » un robot à un instant donné. Sans logs exploitables, le debug devient une enquête.
6. Edge et cloud, chacun son rôle. La décision critique reste sur l’edge, proche du capteur. Le cloud sert à l’analyse, l’entraînement, la supervision. Mélanger les deux crée de la latence là où il ne faut pas.

Les anti-patterns

Concevoir sans contrainte temps réel et l’ajouter ensuite. Tout valider en simulation. Traiter une flotte comme un robot isolé. Mettre la décision critique dans le cloud. On les a tous croisés, parfois chez nous avant de corriger.