Robot mobile autonome : lever les verrous de la performance logistique

Plus de 20 000 points relais, 40 sites de tri, 200 millions de colis traités par an. À cette volumétrie, la moindre seconde perdue sur une chaîne de tri se chiffre en millions d’euros à l’année.

C’est le quotidien d’un acteur mondial de la logistique qui nous a sollicités en 2023. Avant de nous contacter, notre client avait testé plusieurs solutions robotisées existantes, le verdict :

• vitesses de déplacement plafonnées
• modes de navigation trop rigides
• impossibilité de densifier les flottes sur une même surface

Son objectif : concevoir un robot mobile autonome pour 30 à 40 % de gain de performance sur le processus de tri de colis. Rtone intervient dans le projet sur trois expertises simultanées : logiciel embarqué, électronique et gestion de projet multi-métiers.

Dans cet article, nous revenons sur les verrous techniques de ce projet et sur la manière dont nous les avons levés : navigation naturelle, localisation indoor, coordination de flotte et méthode de conception électronique.

Un plafond technique, pas organisationnel 

Le problème n’était pas organisationnel. Les installations, sont dimensionnées (en général) pour un flux fixe de l’ordre de 20 000 colis/heure, les machines imposent leur configuration au bâtiment et dictent le choix des locaux jusqu’au maillage territorial. Mais pendant ce temps, les volumes continuent d’augmenter.

Le brief client se résumait à une équation que les solutions du marché ne parvenaient pas à résoudre : augmenter le débit de colis par heure tout en réduisant le nombre de robots en action et les coûts d’opération.

Trois axes structurent ce besoin 👇

• La réduction des coûts opérationnels : le tri est un des postes de dépenses le plus lourd. Il fallait une solution légère en infrastructure, pour que le système de tri s’adapte au bâtiment et non l’inverse.
• La scalabilité technologique : les solutions existantes ne montent en charge qu’au prix d’une augmentation proportionnelle des infrastructures. Il fallait une montée en charge modulaire, capable de suivre la variation des volumes sans refonte complète.
• Le basculement de la contrainte : le blocage n’était ni humain ni organisationnel. Il était technique. La cible : un système robotisé capable d’atteindre de nouvelles cadences avec une précision millimétrée.

Traduit en langage projet, la contrainte de conception est très claire : faire évoluer une flotte de robots dans un environnement dynamique, sans aucune infrastructure au sol. Ni câbles, ni marqueurs.

Navigation en grille versus navigation naturelle : quelle différence ? 

La robotique mobile industrielle repose largement sur la navigation en grille. Le robot suit un réseau de repères matérialisés dans le bâtiment (marqueurs, balises) et se déplace de nœud en nœud. C’est une solution technique robuste, éprouvée, mais qui présente deux inconvénients rédhibitoires ici : l’infrastructure doit être installée puis maintenue, et les trajectoires sont contraintes par le maillage. Densifier une flotte revient alors à densifier la grille.

La navigation naturelle inverse la logique. Le robot se repère à partir des caractéristiques de son environnement, telles qu’il les perçoit. Aucune trajectoire n’est pré-tracée au sol : les chemins sont calculés, et peuvent se croiser librement.

C’est ce qui permet, sur une même surface, de faire circuler davantage de robots et de re-configurer une plateforme sans travaux.

Alors comment on s’y prend concrètement ?

Localisation indoor : une navigation sans marquage au sol 

Pour qu’un robot mobile autonome se déplace seul, il ne suffit pas de faire tourner ses moteurs. Nous avons développé une chaîne logicielle complète, dont la première brique est l’intégration de la localisation indoor haute précision.

La solution repose sur la technologie VSLAM. Le système fusionne en temps réel trois sources de données :

• La caméra : elle fournit les caractéristiques visuelles de l’environnement, qui servent de points de repère.
• La centrale inertielle (IMU) : elle maintient l’estimation pendant les mouvements rapides.
• Les encodeurs de roues : ils apportent la mesure du déplacement réel, y compris dans les zones visuellement pauvres.

De cette fusion, le robot déduit sa position, son orientation et sa vitesse, même au milieu de flux changeants et d’objets mouvants.

Une intégration en deux temps

1. La cartographie. Le VSLAM est lancé en mode apprentissage sur un robot piloté manuellement, que l’on fait circuler dans l’environnement. Le système construit la carte à partir des caractéristiques visuelles captées.

2. La relocalisation continue. Une fois la carte établie, le robot détermine sa position en permanence, en croisant les images, les données des encodeurs et de l’IMU.

La vraie force de ce système, c’est l’apprentissage en continu. Si l’environnement change, le robot s’adapte tant qu’il dispose de points de repère connus. Pour une plateforme dont les besoins évoluent avec les volumes et les configurations de tri, cette flexibilité est un atout majeur.

Gestion de flotte : déployer, coordonner et maintenir des robots mobiles

Savoir où l’on est ne suffit pas quand plusieurs dizaines de robots se croisent et se suivent en permanence à cadence soutenue.

Path planner : le planificateur de trajectoire 

Le path planner est un composant central du système de gestion de flotte. Il calcule en temps réel les trajectoires de chaque robot : il détermine aussi le timing précis de chaque passage.

C’est cette dimension temporelle qui fait la différence. En exploitant la position, la vitesse et la direction réelle de chaque robot, mises à jour en continu, le planificateur construit des trajectoires qui se croisent sans conflit. Les arrêts inutiles disparaissent, les collisions aussi.

MQTT et boucle fermée : le dialogue robot / gestion de flotte

Robot et path planner dialoguent en permanence, selon trois mécanismes :

• Réception des trajectoires : le path planner transmet les trajectoires par morceaux (position, vitesse, cap) via MQTT. Le robot les empile dans un buffer embarqué, sans jamais interrompre son mouvement.
• Retour de position en temps réel : environ 10 fois par seconde, le robot publie sa position estimée, sa vitesse et un indice d’incertitude. Le path planner s’appuie sur ces données pour ajuster les trajectoires suivantes.
• Correction dynamique : lorsque le robot détecte un écart significatif (retard, avance, chemin devenu inaccessible), il remonte immédiatement le diagnostic. La trajectoire est corrigée sans arrêt du robot.

Le motion control : lien final entre l’intention et le mouvement

Reste à transformer une trajectoire planifiée en rotation de roues. C’est le rôle du motion control : convertir une séquence de points de passage (positions, vitesses, horodatages) en commandes motrices concrètes.

Pourquoi l’avoir développé sur mesure ? Parce que la liberté de mouvement de la navigation naturelle rend cette brique d’autant plus critique. C’est elle qui traduit une position estimée en corrections motrices continues. Sans cette boucle de contrôle fermée, l’écart entre position estimée et position réelle se creuse à chaque virage — et la navigation naturelle devient inexploitable en conditions opérationnelles.

L’architecture repose sur trois couches :

• Réception et interpolation des trajectoires : un algorithme mathématique complexe interpole les points reçus pour reconstruire une courbe continue en position, vitesse et accélération, garantissant des transitions fluides.
• Algorithme de suivi de trajectoire : il maintient le robot sur sa consigne malgré les imperfections d’un positionnement sans repères fixes.
• Conversion cinématique et commande moteur : une couche d’abstraction traduit les consignes de vitesse linéaire et angulaire en vitesses de rotation individuelles pour chaque roue. Les commandes sont ensuite envoyées vers les contrôleurs moteur via le protocole CANopen.

L’ensemble forme un pipeline temps réel, de la réception de la trajectoire jusqu’à la commande moteur, exécuté sous RTOS pour garantir le respect des contraintes temporelles.

Zephyr OS : le choix technique pour la conception du robot mobile 

Pour garantir la robustesse du motion control et la fluidité de la navigation, l’adoption de Zephyr OS a été déterminante. Plus qu’un système d’exploitation, il a servi de levier d’architecture, sur quatre piliers :

• Abstraction et flexibilité matérielle : sa couche d’abstraction (HAL) et sa prise en charge native d’une vaste gamme de microcontrôleurs et de capteurs nous ont permis d’ajouter ou de remplacer des composants facilement.
• Fiabilité en environnement critique : la gestion avancée des threads et des priorités assure la stabilité logicielle indispensable à la sécurité du robot.
• Développement en avance de phase : Zephyr s’exécute sur architecture native, ce qui permet de développer et tester les algorithmes en simulation. Nous avons ainsi validé des comportements de flotte avant même la disponibilité des robots physiques. L’execution sur architecture native permet également aux équipe path planner de pouvoir facilement lancer des simulations qui éxécutent le même algorithme de motion control qu’un vrai robot.
• Focus sur la valeur métier : en nous appuyant sur les briques et l’outillage éprouvés de la communauté, nos équipes se concentrent sur la logique métier plutôt que sur les couches basses.

Pour aller plus loin, découvrez notre article dédié : Robots mobiles autonomes : pourquoi utiliser Zephyr OS ?

Conception électronique Fast-Track : développer le logiciel sans attendre les cartes

Dans un projet robotique, le développement logiciel est souvent suspendu à la livraison des cartes électroniques définitives. Sur un projet de cette échelle, cela signifie des mois de validation logicielle repoussés : un vrai effet tunnel.

Nous avons donc conçu le hardware pour servir le firmware, dès le premier jour, selon une méthodologie de conception électronique en Fast-Track.

• La carte One-Shot : dès le lancement, nous avons conçu une première carte fonctionnelle. Non définitive, mais suffisante pour que les développeurs attaquent la logique métier et le pilotage moteur en conditions réelles, sans attendre le design final du robot.
• Architecture multiboard : trois développements hardware ont été menés en parallèle pour la communication, la puissance et la sécurité. Cette segmentation a limité l’impact d’une modification technique sur l’ensemble du système.
• Collaboration interdisciplinaire continue : une coordination quotidienne entre les équipes électronique, firmware et mécanique a permis d’ajuster le design des cartes au fil des contraintes d’intégration découvertes.

C’est cette approche multiboard qui a permis de tenir les délais serrés de chaque phase, de produire le code du robot au plus tôt, et de mener tests et itérations en parallèle.

La gestion d’un projet robotique international 

Sur ce projet, la dimension organisationnelle était à la hauteur de la complexité technique.

Derrière la conception, une réalité plus exigeante encore : des équipes qui ne partagent ni la même langue, ni la même culture projet, ni les mêmes process.

La collaboration s’est donc construite autour d’un environnement de travail commun, lisible par tous, dans lequel chaque acteur comprend sa place et sa contribution : instances de partage régulières, documentation accessible, workshops d’intégration en physique, ateliers communs sur plusieurs jours…

Au-delà de l’exécution, nous avons occupé un rôle d’architecte système et de coordinateur transverse, avec un double enjeu : assurer la cohérence technique tout au long du projet, et préparer l’avenir via un tuilage et un transfert de compétences progressif, pour que le client puisse internaliser la solution.

« On ne peut pas mener un projet de cette envergure avec des équipes qui restent cloisonnées. C’est la rencontre et la création d’un environnement projet global qui permet de lever les différents verrous et d’avoir une équipe projet engagée et performante. Pour notre équipe, c’est un projet humainement riche et techniquement parlant, passionnant. » Benjamin Diard, Chef de projet Rtone

Pour conclure

Ce projet illustre ce que suppose réellement un robot mobile autonome industriel performant : ce n’est pas une brique, c’est une chaîne. Localisation VSLAM, planification de flotte, motion control, RTOS, architecture électronique : chaque maillon conditionne la performance du suivant. Retirez la boucle de contrôle fermée du motion control, et la navigation naturelle ne tient plus.

C’est aussi un projet où la méthode a compté autant que la technique. La conception hardware en Fast-Track et le rôle d’architecte système ont permis de passer d’un concept à des robots fonctionnels en 9 mois, puis à une flotte déployée sur site pilote en moins de deux ans.

La suite est déjà tracée. En 2026, la flotte est déployée sur un site de test à l’étranger, avec l’ambition de tripler le nombre de robots et de basculer en production à grande échelle. Trois priorités accompagnent ce passage à l’échelle : la fiabilité en exploitation continue, la collecte de metrics terrain pour alimenter l’optimisation, et l’internalisation progressive par les équipes du client.

👉 Vous avez un projet de robotique mobile en tête ? Parlons-en.