Utilisation de l'EPOS4 par un environnement système ROS ?

Sujet :

• L'EPOS4 (ou IDX) peut-il être utilisé par ROS ?
• L'EPOS4 est-il compatible avec ROS et prêt pour ROS ?
• Quelle est la configuration recommandée par maxon pour le système ROS ?
• Existe-t-il des exemples de code d'application ROS recommandés ?

Solution :

Contexte technique :

L'EPOS4 offre une interface de bus CAN et EtherCAT, c'est-à-dire que l'EPOS4 peut être utilisé par n'importe quel environnement de système maître (et aussi ROS) qui offre des bibliothèques d'interface CANopen ou EtherCAT. Enfin, nous nous appuierons sur l'expérience d'un utilisateur pour mettre en œuvre un code d'application ROS commandant l'EPOS4 sur la base d'une telle bibliothèque d'interface.

ROS + EPOS4 : Défis typiques

Plusieurs utilisateurs ont déjà implémenté avec succès des applications ROS commandant l'EPOS4. Certaines solutions peuvent même être trouvées en utilisant Google et les mots-clés « EPOS » et « ROS » :

-> www.google.com/search?q=ROS+EPOS
maxon ne peut être tenu responsable de ces solutions tierces. Vous trouverez plus bas une solution ROS recommandée par maxon (-> solution ROS / EPOS4 recommandée par maxon).

La faisabilité de ROS pour une certaine application dépend des exigences du système en matière de performance en temps réel. Le développement réussi du code de l'application ROS exige enfin une certaine expérience de ROS, de la commande de mouvement et de la programmation.

• La configuration du système ROS et la sélection des bibliothèques constituent déjà un défi initial pour la plupart des utilisateurs de ROS.
• Des connaissances en commande de contrôle de mouvement basées sur le standard « CiA402 - CANopen device profile for drives and motion control » sont nécessaires pour l'implémentation du code.

ROS = solution prête à l'emploi pour les systèmes robotiques ?

Un malentendu courant est que ROS est censé être un environnement système prêt à fonctionner ou même un ensemble complet de codes d'application. Ce malentendu peut déjà être basé sur le terme « ROS - Robotic Operating System ». Cela ressemble à un ensemble complet et facile à utiliser pour les systèmes robotiques.
-> ROS n'est pas un ensemble de codes prêts à l'emploi !

• ROS est un écosystème de robots et de composants logiciels modulaires écrits principalement en C++/Python.
• ROS peut être considéré comme une énorme boîte de différents outils logiciels basés sur des versions spécifiques de Linux et de nombreuses bibliothèques tierces.
• L'ensemble du code et des bibliothèques de ROS est open source, mais souvent développé par des étudiants ou des chercheurs universitaires temporaires. Cela peut avoir pour conséquence que certaines bibliothèques ne sont pas régulièrement mises à jour ou que les fonctionnalités implémentées ont été concentrées sur les demandes d'une application concrète.
• Il existe souvent une forte dépendance entre les bibliothèques utilisées, Linux ou même les versions de matériel qui doivent s'adapter l'une à l'autre. Il en résulte qu'une certaine connaissance et expérience pratique est nécessaire pour savoir quels composants et bibliothèques de ROS s'intègrent ou doivent être adaptés, améliorés ou fixés pour l'utiliser d'une manière plus générale.

Configuration du système ROS et sélection des bibliothèques ?

Un « défi » initial commun est souvent de réussir à mettre en place une combinaison adéquate de l'environnement système ROS et Linux (et des outils logiciels) ainsi que des bibliothèques requises. Il ne s'agit pas d'un problème spécifique lié à l'utilisation de dispositifs ROS particuliers (comme l'EPOS4), mais de ROS en général. Bien qu'il existe de nombreuses bibliothèques pour les différentes interfaces et dispositifs présents sur http://wiki.ros.org, certaines de ces bibliothèques ne sont plus à jour, le code peut être incomplet et ne couvrir que les modes de fonctionnement et les caractéristiques de dispositifs spécifiques. La compatibilité des bibliothèques ROS concrètes ainsi que l'ensemble des fonctionnalités d'une bibliothèque doivent être vérifiés en fonction de l'environnement du système (par exemple, la version de Linux) et des exigences de l'application. Il s'agit d'une première étape importante pour mettre en place un système ciblant des dispositifs concrets de contrôle de mouvement (comme l'EPOS4) de la meilleure façon possible.

ROS1 versus ROS2 :

Il existe deux versions de ROS, ROS1 et ROS2. ROS1 est généralement utilisé lorsque ROS est demandé ou mentionné. ROS1 est le kit d'outils ROS original, principalement utilisé par les universités et les projets de recherche, mais avec quelques lacunes fonctionnelles pour les applications industrielles. ROS2 est un code entièrement nouveau conçu pour différents types de robots industriels (par exemple, les AGV dans les entrepôts).

• Le principal inconvénient de ROS1 est que ses capacités en temps réel ne sont pas aussi parfaites que celles requises par les robots industriels exigeant un mouvement multi-axes synchronisé ou coordonné contrôlé par le maître ROS. ROS1 n'offre pas non plus la sécurité des données requise pour les systèmes connectés à l'internet. C'est pourquoi ROS1 est principalement utilisé dans les projets d'étudiants mais n'est pas souvent utilisé dans les solutions industrielles.
  
  
• ROS2 est basé sur un code entièrement nouveau qui surmonte les lacunes de ROS1 en matière de temps réel et prend également en charge les aspects liés à la sécurité des données et aux droits d'accès. ROS2 est fortement encouragé par les entreprises industrielles (par exemple, Amazon). ROS2 semble être une solution très prometteuse pour les applications industrielles futures, mais il manque encore des interfaces (communication) ou des bibliothèques de dispositifs spécifiques. Les bibliothèques de ROS1 ne peuvent pas être utilisées car ROS2 est basé sur un nouveau code interne. Les applications ROS2 nécessitent souvent un matériel plus puissant (par exemple des cartes NVIDIA coûteuses) et la version la plus récente de Linux si les sujets en temps réel multi-axes sont ciblés.
   
• ROS2 et ROS1 ne sont pas compatibles (en raison d'une nouvelle base de code ROS2 complètement différente). Il est juste possible d'utiliser des composants logiciels de ROS1 dans un environnement système de ROS2 par le biais de ce que l'on appelle des ponts logiciels ROS1/ROS2. Une telle solution présente l'inconvénient que certaines des limitations de ROS1 sont toujours présentes.

S'initier à ROS

ROS est complexe. Il offre de nombreuses fonctionnalités utiles, mais son apprentissage prendra un certain temps. Des connaissances de base sur Linux et la programmation sont nécessaires, mais il y aura encore des efforts à faire pour entrer dans les bases de ROS et les comprendre correctement. Cela commence déjà par le câblage et la configuration corrects du bus CAN (-> topologie du bus CAN et terminaison du bus) qui sont obligatoires pour tout échange de données réussi, quel que soit le système maître utilisé. Enfin, de nombreux domaines d'expérience (ROS, Linux, programmation, CANopen, CiA402) sont nécessaires avant que les moteurs ne se déplacent conformément aux exigences d'une application.

La solution ROS1 + EPOS4 recommandée par maxon :

maxon a traité un projet avec un partenaire ROS expérimenté en 2021. L'objectif était de fournir des conseils concernant les principaux défis (tels que la configuration du système, la sélection de la bibliothèque, le contrôle multi-axes) auxquels sont confrontés les utilisateurs de ROS.

L'artefact résultant de l'exemple de projet ROS de maxon est un document sur l'installation de ROS1 et un exemple de code pour le contrôle multi-axes basé sur une bibliothèque CANopen Open Source tierce (-> http://wiki.ros.org/ros_canopen) et un générateur de profil ROS (-> https://moveit.ros.org) qui est nécessaire si l'EPOS4 doit être commandé en mode « CSP - Cyclic Synchronous Position ».

La configuration par Maxon d'un exemple de système logiciel ROS1 est disponible dans les liens publics suivants :
-> http://wiki.ros.org/maxon_epos4_ros1
-> https://github.com/Roboprotos/maxon_epos4_ros1

Le paquet présenté par ces liens contient ...

• ... un document qui décrit comment configurer un environnement ROS1 sur PC, Raspberry Pi ou NVIDIA, quelle version de Linux et quelles bibliothèques sont nécessaires et quelles performances en temps réel peuvent être attendues.
• ... quelques exemples de code pour commander l'EPOS4 via une application maître ROS1 en fonction des différents modes de fonctionnement de l'EPOS4 et du CAN.

Veuillez également noter les pages suivantes de tutoriels wiki.ros.org sur l'EPOS4 :

-> http://wiki.ros.org/ros_canopen/Tutorials 
-> http://wiki.ros.org/ros_canopen/Tutorials/UsingMaxonEPOS4inProfileOperatingModes 
-> http://wiki.ros.org/ros_canopen/Tutorials/UsingMaxonEPOS4inCyclicSynchronousOperatingModes 

Les documents et le logiciel ont été développés par le partenaire ROS expérimenté de maxon, Cyril Jourdan de la société « www.roboprotos.com ». Cyril Jourdan pourrait fournir un support limité via ses liens et son compte wiki.org ou github (->https://answers.ros.org/users/4040/cyril-jourdan). Il sera le premier point de contact en cas de questions ou de problèmes spécifiques à ROS en utilisant les documents ou les exemples de code. Roboprotos (et Cyril) est une société indépendante de conseil et d'ingénierie offrant de tels services à des tiers. S'il y a un besoin supplémentaire de formation ROS, de développement d'applications ROS, ou de services de conseil, cela peut être offert par Cyril Jourdan et Roboprotos directement. Ces services seront facturés par Roboprotos et vont bien au-delà des produits maxon ou du support ROS.

ROS2 + EPOS4

Si vous pensez déjà à ROS2, veuillez consulter le lien suivant qui contient un document ainsi que des exemples de code permettant d'utiliser ROS2 avec un pont ROS1 :
-> https://github.com/Roboprotos/maxon_epos4_ros2 

Quelques informations sur la version de base de ROS2 utilisée par ce paquet peuvent être trouvées par ce lien tiers :
-> https://docs.ros.org/en/foxy/index.html 

Solutions ROS alternatives de tierces parties (sans le support de maxon) :

• ROS + CAN + EPOS Command Library + EPOS
  Il existe également d'autres solutions ROS tierces basées sur la « EPOS Command Library », par ex.
  -> http://wiki.ros.org/epos_hardware   
  -> https://github.com/yoshito-n-students/eposx_hardware 
  Restrictions :
  Ces paquets peuvent ne pas être à jour et ne pas être basés sur la dernière version de « EPOS Command Library » ou EPOS4. maxon n'a pas testé ces paquets de code et ne peut pas fournir de support à ce sujet. Le fait que ces paquets soient basés sur la « EPOS Command Library » signifie également que seul l'échange de données SDO est pris en charge et qu'il n'est pas possible de le faire en temps réel. Une telle solution ne sera pas suffisante pour les applications qui doivent commander des applications multi-axes à un rythme rapide. La solution ROS / EPOS4 de Maxon (resp. Cyril Jourdan) mentionnée ci-dessus offre une bien meilleure base pour de telles applications.
  
  
• ROS + SOEM + EtherCAT + EPOS4
  Il existe une solution supplémentaire appelée « maxon EPOS EtherCAT SDK » présente sur github :
  -> https://github.com/leggedrobotics/maxon_epos_ethercat_sdk 
  Restrictions :
  Ce package a été développé par un étudiant en master du laboratoire de systèmes robotiques de l'ETH Zuerich. Il n'a pas été testé par maxon mais pourrait être intéressant en raison de la présence d'EtherCAT (au lieu de CAN). Il semble être basé sur ROS Noetic. Par conséquent, la performance en temps réel de ROS1 et du « SOEM - Simple Open EtherCAT master » pourrait être un point d'investigation intéressant basé sur les exigences de l'application. maxon ne peut pas fournir de support pour ce paquet de code et cette solution, mais M. Linghao Zhang qui l'a fourni sur github pourrait être ouvert à un retour d'information et à des questions (-> https://github.com/zoenglinghou or www.linkedin.com/in/linghao-zhang).
  Veuillez noter que la dernière mise à jour de ce package date déjà de 2021, c'est-à-dire qu'il n'est probablement pas à jour et qu'il ne semble plus y avoir de corrections de bogues ou d'améliorations.

Prochaines étapes ?

Nous espérons que ces conseils aideront à fournir un point de départ pour le développement d'une application ROS. Gardez à l'esprit que ROS n'est pas une solution prête à l'emploi, mais les documents et les exemples fournis par http://wiki.ros.org/maxon_epos4_ros1 et https://github.com/Roboprotos/maxon_epos4_ros1 peuvent être un bon guide de départ pour l'adaptation en fonction des exigences d'un système concret et d'une application.

Si vous envisagez un projet ROS industriel, veuillez nous communiquer plus de détails par le biais d'une demande de support (en particulier si vous avez l'intention d'utiliser ROS2) :

1. Type d'application
2. Nombre d'axes utilisés (ou devant être contrôlés par le maître ROS) ?
3. Y a-t-il un besoin de contrôle multi-axes et d'échange de données en temps réel ?
4. Environnement du système ROS utilisé ?
   (ROS1 ou ROS2, version Linux, bibliothèques ROS, ... ?)
5. Matériel utilisé par le maître de ROS ?
   (par exemple PC, Raspberry Pi, NVIDIA, ou ... ?)
6. Votre niveau d'expérience de ROS et des bibliothèques ROS ?
7. Votre entreprise et vos coordonnées

Des systèmes maîtres alternatifs au lieu de ROS ?

La plupart des applications industrielles sont basées sur des automates programmables (PLC) en tant que maîtres en temps réel. Les fournisseurs de PLC offrent également des bibliothèques de contrôle de mouvement ou NC (pour les contrôleurs de moteur basés sur CiA402 comme l'EPOS4) et des interfaces de bus CANopen ou EtherCAT. Dans le cas d'applications industrielles multi-axes ou robotiques, l'un des systèmes maîtres suivants (non ROS) est souvent utilisé :

• Beckhoff's TwinCAT & NC library
• OMRON's Sysmac NJ
• maxon's Master Motion Controllers, e.g. ...
  • maxon's MasterMACS
  • maxon's MiniMACS6
  • maxon's MiniMACS6-AMP
  • maxon's MicroMACS