Programmation de robots de service

Ce que nous faisons pour le client

Nous prenons votre plateforme de service — un robot de livraison, de désinfection ou d'accueil — et écrivons pour elle le logiciel opérationnel et les scénarios de comportement. La programmation de robots de service, chez nous, signifie le déploiement du stack sur l'ordinateur de bord, le réglage des pilotes du lidar, des caméras et de la base roulante, la construction de la carte des lieux et de la logique des itinéraires. Nous ne fabriquons pas le châssis lui-même et n'imprimons pas la carrosserie — c'est le matériel du client qui transporte et désinfecte, et nous préparons la couche de commande qui le fait agir de façon prévisible. Le travail comprend l'intégration à vos systèmes : appel d'ascenseur, ouverture de portes, remise de commande, transmission des statuts au système de gestion via une API. En sortie, vous recevez non une démo, mais une machine réglée qui exécute les tâches définies dans votre bâtiment.

Comment cela fonctionne au fond

Le robot construit et affine en continu la carte de l'espace d'après les données du lidar et de l'odométrie, puis se localise sur cette carte en temps réel. Par-dessus la localisation travaille le planificateur : il trace un chemin global jusqu'à la cible et recalcule aussitôt la trajectoire locale, en contournant les personnes, les chariots et les obstacles temporaires. Chaque action applicative — entrer dans une chambre, se placer près du comptoir, contourner une file — se décrit par un scénario distinct, avec ses conditions et ses réactions aux incidents. Nous réglons les seuils de vitesse, les zones de sécurité et le comportement en cas de perte de cible, pour que la machine s'arrête au lieu de percuter l'obstacle. C'est tout ce couple navigation et scénarios qui transforme le matériel du client en robot de service opérationnel.

D'où vient la robotique de service

Le point de départ est généralement considéré comme le robot Shakey, développé au Stanford Research Institute (SRI) de 1966 à 1972. C'était le premier robot mobile à usage général capable de raisonner sur ses propres actions : il percevait l'environnement, élaborait un plan, fractionnait la commande en étapes et se rétablissait après une erreur. La robotique de service commerciale démarra plus tard : Joseph Engelberger fonda la Transitions Research Corporation en 1984, et en 1988 livra le premier robot hospitalier HelpMate à l'hôpital de Danbury (Connecticut). HelpMate distribuait lui-même médicaments et échantillons dans les étages, et en l'espace d'une décennie de telles machines fonctionnaient déjà dans plus d'une centaine d'hôpitaux. C'est précisément cette lignée — du Shakey de recherche au HelpMate de série — qui a établi la logique de navigation et de scénarios sur laquelle repose toute la robotique de service actuelle.

Pourquoi la partie logicielle est critique

Dans un robot de service, la physique du châssis est secondaire — le résultat est déterminé par la précision de la localisation et la qualité des scénarios. Une erreur de positionnement de dix centimètres signifie que la machine ne passera pas la porte ou se placera à côté du comptoir de remise ; un décalage entre la carte et la réalité conduit à un blocage dans un couloir. C'est pourquoi le réglage des paramètres du planificateur, le filtrage du bruit des capteurs et la calibration des zones de sécurité influent sur le résultat plus que les caractéristiques des moteurs. Le robot roule et désinfecte avec son matériel, mais c'est le logiciel qui le conduit, et c'est de lui que dépend qu'il arrive sans collision ni intervention de l'opérateur. Une programmation de robots de service bien menée n'est pas une option supplémentaire à la plateforme, mais la condition sans laquelle celle-ci reste un assortiment immobile de composants.

Sur quel stack nous travaillons

L'outil de base, c'est ROS2, framework ouvert pour la robotique : c'est sur lui que se construit l'architecture en nœuds, l'échange de messages entre capteurs et commande, le lancement et le diagnostic des modules. La navigation, nous la réalisons sur le stack Nav2 — la solution standard pour ROS2, responsable de la construction de la carte, de la localisation, de la planification globale et locale du chemin et des arbres de comportement. Le couple ROS2 et Nav2 couvre tout le parcours du robot : de la réception du nuage de points du lidar à la commande précise envoyée à l'entraînement. La logique applicative — ordre des tâches, réactions aux événements, intégration aux ascenseurs et aux systèmes de gestion — nous l'écrivons par-dessus ce stack, pour le site précis du client. Le stack est ouvert et maintenu, la solution n'est donc pas liée à un fournisseur unique et évolue avec l'écosystème.

Quand sont apparus les outils clés

ROS (Robot Operating System) lui-même apparut chez Willow Garage : le dépôt du projet fut créé le 7 novembre 2007, et la version 1.0 sortit en 2010 et devint vite le standard sectoriel de la recherche et du développement. La première génération avait des limites architecturales pour les tâches de série et multi-robots, c'est pourquoi elle fut réécrite : la première distribution de ROS2, sous le nom d'Ardent Apalone, sortit le 8 décembre 2017. Nav2 fut développé comme successeur de l'ancien stack de navigation de ROS, refondu pour ROS2 en s'appuyant sur des approches issues du transport autonome. Ces dates sont importantes en pratique : nous travaillons sur la deuxième génération actuelle, conçue pour l'exploitation industrielle, et non sur une branche obsolète. Le stack est éprouvé par le temps et la communauté, ce qui réduit les risques lors de l'exploitation durable de votre plateforme.

Pourquoi vous pouvez nous le confier

Derrière le développement se trouve une équipe dont l'expérience cumulée en informatique dépasse 45 ans, et pour nous, un robot est avant tout une tâche d'ingénierie, et non de marketing. Nous ne promettons pas de miracles de votre matériel : nous évaluons lucidement ce que la plateforme est capable de faire et poussons le logiciel jusqu'à cette limite. Chaque scénario passe une vérification en simulation et sur banc avant que le robot ne sorte dans la zone de travail avec des humains — la mise en production ne se fait qu'après le déroulé des situations anormales. Nous répondons de la couche de commande : navigation, scénarios, intégrations et réglage du matériel du client, en laissant la fabrication du matériel à son constructeur. Cette approche partagée donne un périmètre de responsabilité clair et un résultat qui se reproduit, au lieu de paraître joli sur une seule démonstration.