Robotique industrielle open source : ROS 2, Modbus, OPC-UA et automates

Le verrouillage propriétaire n’est plus une fatalité

Pendant trente ans, automatiser une ligne de production signifiait choisir un automate d’une grande marque, sa console de programmation maison, son bus de terrain breveté et son logiciel de supervision facturé à la licence. Chaque maillon parlait un dialecte que seul le constructeur comprenait vraiment. Le jour où l’on voulait brancher un robot mobile, une caméra de contrôle qualité ou un tableau de bord web, il fallait acheter une passerelle de plus, signer un contrat de plus, et accepter de ne jamais regarder sous le capot.

Ce monde est en train de s’ouvrir. Trois familles d’outils libres permettent aujourd’hui de construire une cellule robotisée complète, de l’actionneur jusqu’au tableau de bord, sans dépendre d’un éditeur unique : ROS 2 pour la partie robotique et la coordination logicielle, les protocoles Modbus et OPC-UA pour faire dialoguer machines et superviseurs, et les automates ouverts conformes à la norme IEC 61131-3 comme OpenPLC pour la logique de commande temps réel. Ce guide relie ces trois mondes et trace le chemin pour les maîtriser un par un.

L’objectif n’est pas de remplacer un automate de sécurité certifié sur une presse de mille tonnes — ce serait imprudent. Il est de comprendre l’architecture de bout en bout, de prototyper vite, d’apprendre les protocoles qui font tourner l’industrie, et de garder la liberté d’auditer chaque ligne de code qui pilote vos machines.

🎯 Ce que ce parcours vous permettra de faire

• Installer un environnement ROS 2 fonctionnel et écrire vos propres programmes qui publient et consomment des données de capteurs et d’actionneurs.
• Simuler un bras robotisé, le décrire mathématiquement et le visualiser avant de toucher au moindre moteur réel.
• Lire et écrire les registres d’un automate en Modbus TCP depuis un script, comme le ferait un superviseur industriel.
• Exposer et consommer des données machine en OPC-UA, le standard d’interopérabilité de l’industrie 4.0, avec authentification et chiffrement.
• Programmer un automate logiciel en langage normalisé (Ladder, texte structuré) et le faire tourner sur un simple PC ou un nano-ordinateur.
• Construire une passerelle qui relie le monde ROS 2 et le monde automate, pour qu’un robot et une chaîne pilotée par PLC coopèrent.

🗺️ Le parcours, tutoriel par tutoriel

Cette série est conçue pour être suivie dans l’ordre, mais chaque tutoriel se tient seul. Le fil conducteur est concret : on part d’un robot logiciel isolé et on aboutit à une cellule miniature où un bras simulé, un automate ouvert et un superviseur échangent en temps réel. Voici l’itinéraire :

1. Installer ROS 2 et écrire son premier programme — on pose les fondations : l’installation propre, l’espace de travail, un nœud qui publie et un nœud qui écoute.
2. Simuler un bras robotisé — on décrit un robot en URDF, on le visualise dans RViz et on apprend à commander ses articulations par services.
3. Parler Modbus TCP en Python — on lit et on écrit les registres d’un équipement, brique de base de toute supervision industrielle.
4. Mettre en place un serveur et un client OPC-UA — on publie un modèle d’information machine, on s’y abonne, on le sécurise.
5. Programmer un automate ouvert avec OpenPLC — on écrit une logique en Ladder et en texte structuré, on la déploie, on l’expose en Modbus.
6. Construire la passerelle ROS 2 ↔ automate — on relie les deux univers pour qu’ils coopèrent autour d’un même procédé.

Chaque étape ajoute une brique vérifiable. À la fin, vous ne saurez pas seulement « ce qu’est » ROS 2 ou OPC-UA : vous aurez fait tourner les deux et vous les aurez fait se parler.

Pourquoi l’open source rebat les cartes de l’automatisation

Deux mondes longtemps séparés convergent : l’informatique de gestion (l’IT, ses serveurs, ses réseaux, ses bases de données) et la technologie opérationnelle (l’OT, les automates, les capteurs, les actionneurs qui agissent sur le monde physique). Cette convergence IT/OT est le cœur de ce qu’on appelle l’industrie 4.0. Or elle ne fonctionne que si les machines acceptent de parler des protocoles ouverts, documentés, et compréhensibles par des outils standards.

ROS 2 est né dans la recherche en robotique mais s’est professionnalisé : sa couche de communication repose sur le standard DDS (Data Distribution Service), une norme industrielle de l’OMG conçue pour les systèmes temps réel distribués. Modbus, créé en 1979 par Modicon, reste le protocole le plus répandu de la planète industrielle par sa simplicité. OPC-UA, normalisé sous la référence IEC 62541, est l’épine dorsale de l’interopérabilité moderne : indépendant du constructeur, du système d’exploitation et du réseau, avec un modèle de sécurité sérieux. Et les automates ouverts respectent IEC 61131-3, la norme internationale qui définit les cinq langages de programmation des automates.

Le résultat : on peut désormais assembler une chaîne complète à partir de briques libres, l’exécuter sur du matériel banal, et la faire évoluer sans demander la permission à un fournisseur. Pour apprendre, pour prototyper, pour les petites séries et pour comprendre en profondeur ce qui se passe à l’intérieur d’une cellule, c’est une révolution discrète mais réelle.

Les concepts fondamentaux

ROS 2 : un système nerveux pour robots

ROS 2 (Robot Operating System 2) n’est pas un système d’exploitation au sens classique : c’est un cadre logiciel — un ensemble de bibliothèques et d’outils — qui résout les problèmes récurrents de la robotique. Le principe central est la décomposition en nœuds : chaque fonction (lire un capteur, calculer une trajectoire, commander un moteur) vit dans un petit programme indépendant. Ces nœuds s’échangent des messages selon trois modèles complémentaires.

Les topics suivent un schéma publication/abonnement : un nœud publie un flux (la position d’un moteur, les images d’une caméra), et tout nœud intéressé s’y abonne, sans que l’émetteur sache qui l’écoute. Les services suivent un schéma requête/réponse, pour les actions ponctuelles (« ouvre la pince », « renvoie la température »). Les actions, enfin, gèrent les tâches longues avec retour d’avancement et possibilité d’annulation (« va à ce point », qui peut prendre dix secondes). Sous le capot, c’est DDS qui transporte tout cela, avec une découverte automatique des participants sur le réseau et des profils de qualité de service réglables.

Dans la version courante à long terme, Jazzy Jalisco (sur Ubuntu 24.04), le middleware par défaut est Fast DDS d’eProsima. C’est important : la qualité de service (fiabilité, persistance, profondeur de file) se règle finement, ce qui fait la différence entre un prototype qui marche sur le bureau et un système robuste sur un réseau encombré d’atelier.

Modbus : la lingua franca des registres

Modbus est volontairement minimaliste, et c’est sa force. Toute la communication tourne autour de quatre espaces de données : les coils (bits en lecture/écriture, typiquement des sorties tout-ou-rien), les discrete inputs (bits en lecture seule, des entrées), les input registers (mots de 16 bits en lecture seule, souvent des mesures) et les holding registers (mots de 16 bits en lecture/écriture, des consignes et paramètres). Un équipement maître interroge un équipement esclave en lui demandant « donne-moi 10 registres à partir de l’adresse 100 » ou « écris la valeur 1500 dans le registre 40 ».

La variante moderne, Modbus TCP, encapsule ces requêtes dans des trames TCP/IP sur le port 502. Pas de chiffrement, pas d’authentification native : Modbus suppose un réseau de confiance. Cette absence de sécurité est précisément l’une des raisons pour lesquelles la segmentation réseau est vitale en milieu industriel, point sur lequel nous reviendrons.

OPC-UA : l’interopérabilité avec un modèle d’information

Là où Modbus se contente d’échanger des nombres bruts dont le sens est implicite, OPC-UA (Open Platform Communications Unified Architecture) transporte un véritable modèle d’information. Une variable n’est plus « le registre 40001 » mais « la température du moteur 3, exprimée en degrés Celsius, de type Double, avec telle plage admissible ». Le serveur expose un espace d’adressage structuré, navigable, auto-descriptif. Les clients peuvent lire, écrire, et surtout s’abonner à des changements de valeur de façon efficace.

OPC-UA intègre nativement la sécurité : authentification des clients, signature et chiffrement des échanges via certificats X.509, et politiques de sécurité négociées. Normalisé en IEC 62541 et porté par la OPC Foundation, c’est le langage commun qui permet à un automate, un robot, un système de supervision et une plateforme cloud de se comprendre sans adaptateur propriétaire. C’est, à ce jour, la pièce maîtresse de l’usine connectée.

Les automates ouverts et la norme IEC 61131-3

Un automate programmable industriel (API, ou PLC en anglais) exécute en boucle, à intervalle fixe et garanti, une logique de commande : lire les entrées, calculer, écrire les sorties, recommencer. Cette cyclicité déterministe est ce qui le distingue d’un programme PC ordinaire. La norme IEC 61131-3 définit cinq langages standardisés pour écrire cette logique : le Ladder (LD, schéma à contacts hérité de l’électromécanique), le Function Block Diagram (FBD), le texte structuré (ST, proche du Pascal), la liste d’instructions (IL) et le Sequential Function Chart (SFC, pour les procédés séquentiels).

OpenPLC est une implémentation libre de cet écosystème : un éditeur pour écrire la logique dans les langages normalisés, et un environnement d’exécution (runtime) qui la fait tourner sur un PC, un Raspberry Pi ou des cartes industrielles, tout en exposant un serveur Modbus TCP intégré. C’est l’outil idéal pour apprendre la programmation d’automate sans investir des milliers d’euros dans une licence, et pour comprendre exactement ce qu’un automate fait à chaque cycle.

L’architecture cible : comment tout s’emboîte

Pour ne pas rester abstrait, fixons l’image de la cellule que cette série construit pièce par pièce. En bas, le terrain : un automate ouvert exécute la logique de sécurité et de séquence d’un petit procédé (par exemple un convoyeur avec un poste de tri). Il expose ses états en Modbus. À côté, un bras robotisé piloté par ROS 2 prend en charge les mouvements complexes (saisir, déplacer, déposer). Au milieu, une passerelle traduit : elle lit l’état de l’automate, le publie dans ROS 2, et inversement transmet les ordres du robot vers l’automate. Au-dessus, un serveur OPC-UA agrège l’ensemble en un modèle d’information cohérent, qu’un superviseur — ou demain une plateforme d’analyse — consomme de façon sécurisée.

Cette organisation en couches n’est pas arbitraire : elle reflète le modèle de Purdue, l’architecture de référence qui structure les réseaux industriels en niveaux, du terrain physique jusqu’à la gestion d’entreprise, avec des frontières contrôlées entre chaque niveau. Comprendre cette stratification, c’est comprendre où placer chaque protocole et, surtout, où placer les barrières de sécurité.

Les tutoriels de la série

Chaque tutoriel ci-dessous construit une brique de la cellule décrite plus haut. Suivez-les dans l’ordre pour bâtir l’ensemble, ou piochez celui qui répond à votre besoin immédiat.

• Installer ROS 2 Jazzy et écrire son premier programme — l’installation propre sur Ubuntu 24.04, l’espace de travail, et un duo de nœuds publication/abonnement qui fonctionne.
• Simuler un bras robotisé avec ROS 2 — décrire le robot en URDF, le visualiser dans RViz, commander ses articulations.
• Lire et écrire des registres en Modbus TCP avec Python — dialoguer avec un équipement industriel à l’aide de pymodbus.
• Serveur et client OPC-UA en Python — exposer un modèle de machine, s’y abonner, le sécuriser avec asyncua.
• Programmer un automate ouvert avec OpenPLC — écrire en Ladder et texte structuré, déployer, exposer en Modbus.
• La passerelle ROS 2 ↔ automate — relier robot et PLC autour d’un procédé commun.

La sécurité, dès la première ligne

Un réflexe doit accompagner tout ce parcours : les protocoles industriels historiques n’ont pas été conçus pour un monde hostile. Modbus n’a ni authentification ni chiffrement ; un automate ouvert exposé sur Internet est une cible. La règle d’or est la défense en profondeur appuyée sur la segmentation : le réseau de terrain (automates, capteurs) doit être isolé dans sa propre zone, séparé du réseau bureautique par un pare-feu, idéalement avec une zone démilitarisée industrielle pour les échanges contrôlés.

OPC-UA joue ici un rôle clé : c’est lui qui apporte authentification et chiffrement aux frontières où l’on remonte les données vers la supervision ou le cloud. La discipline consiste à parler Modbus uniquement à l’intérieur d’une zone de confiance, et à franchir les frontières avec OPC-UA correctement configuré. Ne jamais exposer un port 502 ou un automate directement sur Internet : c’est la première cause d’incident en milieu industriel.

Choisir le bon protocole pour le bon usage

Une question revient sans cesse quand on découvre cet écosystème : « puisque ROS 2, Modbus et OPC-UA transportent tous des données, pourquoi ne pas en garder un seul ? » Parce qu’ils ne résolvent pas le même problème, et qu’ils opèrent à des étages différents de l’architecture. Les confondre mène à des systèmes fragiles ; bien les répartir donne une cellule lisible et robuste.

Le tableau ci-dessous résume leurs domaines de prédilection. Lisez-le comme une boussole, pas comme une loi : dans la vraie vie, les frontières se chevauchent, et c’est précisément le rôle de la passerelle finale de les réconcilier.

La règle pratique qui découle de ce tableau : Modbus parle au plus près des machines, à l’intérieur d’une zone protégée ; OPC-UA porte les données aux frontières, là où la sécurité compte ; ROS 2 orchestre l’intelligence logicielle du robot. Aucun n’est « meilleur » dans l’absolu — chacun est le meilleur à sa place.

Comprendre la qualité de service, le détail qui fait la robustesse

Un concept de ROS 2 mérite qu’on s’y arrête dès le départ, car il explique la moitié des problèmes des débutants : la qualité de service (QoS). Comme DDS est conçu pour des réseaux réels, imparfaits, il laisse régler le comportement de chaque flux. Deux réglages dominent. La fiabilité : en mode « reliable », l’émetteur réémet jusqu’à confirmation de réception, idéal pour une consigne qu’on ne veut pas perdre ; en mode « best effort », on accepte des pertes en échange de latence minimale, parfait pour un flux vidéo où la dernière image compte plus que les précédentes. La durabilité détermine si un abonné qui se connecte en retard reçoit la dernière valeur publiée ou seulement les suivantes.

Le piège classique : un nœud qui publie en « reliable » et un nœud qui s’abonne en « best effort » ne se parleront jamais, car leurs profils sont incompatibles. Beaucoup de « mais pourquoi je ne reçois rien ? » se résolvent en alignant la QoS des deux côtés. Garder cette notion en tête évite des heures de débogage et distingue une intégration amateur d’une intégration solide.

Erreurs fréquentes à éviter

Questions fréquentes

ROS 2 peut-il remplacer un automate industriel ?
Non, et ce n’est pas son rôle. ROS 2 excelle dans la coordination logicielle complexe, la perception et la planification de mouvement. Un automate garantit un cycle déterministe et, dans ses versions certifiées, des fonctions de sécurité. Les deux sont complémentaires : l’automate tient la logique critique et temps réel, ROS 2 orchestre l’intelligence. La passerelle entre les deux est justement l’objet du dernier tutoriel.

Faut-il du matériel coûteux pour suivre cette série ?
Non. L’essentiel se fait sur un PC sous Ubuntu, en simulation. Modbus, OPC-UA et OpenPLC tournent entièrement en logiciel pour l’apprentissage. Un Raspberry Pi suffit ensuite pour héberger un automate ouvert réel. Le matériel d’actionnement n’arrive qu’une fois les concepts maîtrisés.

Quelle version de ROS 2 choisir ?
Pour apprendre et durer, une version à support long terme est préférable. Jazzy Jalisco, sur Ubuntu 24.04, est la LTS de référence au moment d’écrire ces lignes (support jusqu’en 2029). Les versions intermédiaires comme Kilted Kaiju existent mais ont un support plus court. Les tutoriels visent Jazzy.

Modbus ou OPC-UA : lequel apprendre en premier ?
Modbus, car il est plus simple et omniprésent : comprendre les registres éclaire tout le reste. OPC-UA vient ensuite, quand on a besoin d’un modèle de données riche et de sécurité. Dans la pratique, les deux cohabitent : Modbus au plus près du terrain, OPC-UA aux frontières.

OpenPLC est-il utilisable en production ?
Pour de l’apprentissage, du prototypage et des applications non critiques, oui. Pour des fonctions de sécurité des personnes, il faut un automate certifié selon les normes applicables. OpenPLC reste un outil pédagogique et de prototypage exceptionnel, et un vrai automate logiciel pour des cas non critiques.

Ai-je besoin de connaître le C++ pour ROS 2 ?
Non pour débuter. ROS 2 offre une interface Python complète (rclpy) qui suffit largement à tout ce parcours. Le C++ devient utile pour les nœuds très sensibles à la latence, mais ce n’est pas un prérequis ici.

Comment éviter d’exposer involontairement un automate ?
En ne donnant jamais à un équipement industriel une adresse routable depuis Internet, en plaçant le réseau de terrain derrière un pare-feu, et en ne franchissant les frontières qu’avec OPC-UA chiffré. La segmentation réseau est la mesure la plus rentable.

Pour aller plus loin

Les sources primaires à garder sous la main pendant tout le parcours : la documentation officielle de ROS 2 (docs.ros.org), les spécifications publiques de la Modbus Organization (modbus.org), la documentation de la OPC Foundation et la norme IEC 62541 pour OPC-UA, le texte de la norme IEC 61131-3 pour les langages d’automate, et le dépôt du projet OpenPLC. Pour la robotique mobile et aérienne, qui partage beaucoup de concepts avec ROS 2, les fondations théoriques de la navigation et de la fusion de capteurs constituent un complément naturel à cette série.

La suite logique est de commencer par le premier tutoriel : installer ROS 2 et écrire ses premiers nœuds. Tout le reste s’appuie dessus.