### 2.2.2.4 Démarche d'extension de la bibliothèque

Ce travail de mise en place du standard PLCopen MC a pour objectif de pouvoir également intégrer des actionneurs entraînés par des contrôleurs de mouvement industriels. La bibliothèque *rtrmac* fournit la possibilité d'utiliser la gamme B&R Automation par l'encapsulation de la bibliothèque propriétaire qui fournit l'implémentation du standard pour ce matériel, en dérivant les dix-huit classes présentées précédemment et le gestionnaire d'axe robotique. Cette démarche sera à reproduire pour l'ajout de nouvelles gammes de matériels de fournisseurs différents.

## 2.3 Une démarche d'unification du développement logiciel

Pour améliorer la performance globale d'un système mécatronique, il est nécessaire que la prise d'informations (la phase *Sense* du schéma *sense - plan - act*, figure 1.4) se fasse de façon synchrone avec le traitement de l'information. Le choix d'exploiter des composants industriels permet d'avoir accès à une très large gamme de capteurs et de cartes d'acquisitions qui échangent des informations avec le contrôleur central à une période d'échange maîtrisée.

Il est possible d'utiliser la bibliothèque *rtrmac* pour développer des interfaces logicielles pour l'acquisition de données de capteurs spécifiques. Dans cette section, nous en présentons deux exemples : le premier montre comment permettre à l'utilisateur d'accéder à des fonctions intégrées dans les cartes d'acquisition, le second présente la démarche de création d'un bloc fonctionnel associé à un capteur spécifique en agrégeant des informations composites.

### 2.3.1 Usage optimal des composants matériels

La bibliothèque *rtrmac* fournit une brique de base permettant la conversion d'une entrée analogique en image de la grandeur mesurée (cf. figure 2.17). Les fonctions présentes dans la classe de base *RbAnalogInput* sont les suivantes :

- conversion de la variable entière associée à la conversion numérique analogique de la carte en variable réelle,

- réglage d'offset,

- possibilité de dériver la grandeur mesurée.

Cette classe peut être utilisée pour développer de nouvelles interfaces pour exploiter des capteurs spécifiques ou être dérivée pour rajouter de nouvelles fonctions. En particulier, pour mesurer les interactions entre un système mécatronique et son environnement, nous sommes amenés à mettre en œuvre des capteurs de force multiaxes. Il est également souvent nécessaire de filtrer les entrées analogiques. Cette fonction de filtre dépend de la dynamique du capteur, de celle du contrôle-commande à réaliser et aura un impact sur la résolution finale de l'information mesurée. Les cartes d'acquisition permettent de réaliser certaines opérations d'amélioration du signal. Dans la logique d'exploitation de la capacité de puissance d'un système distribué, il est intéressant de pouvoir exploiter au mieux les fonctions fournies par les unités de traitement.

#### 2.3.1.1 Composant exploitant des fonctions embarquées dans la carte d'acquisition

Pour réaliser des mesures d'actions mécaniques qui transitent dans des mécanismes ou des chaînes de transmission de mouvement, nous utilisons régulièrement des jauges de déformation, intégrées dans des capteurs ou placées sur des corps d'épreuve dans les mécanismes que nous
concevons. Les cartes d'acquisition B&R Automation qui font la mesure et l'amplification par
pont de Wheatstone disposent également de filtres numériques évolués (cf. 2.27).

MATERIAL NUMBER :

X20AI1744

DESCRIPTION :

* 1 full-bridge strain gauge input

* Data output rate configurable from 0.1 Hz to 7.5 kHz

* Special operating modes (synchronous mode and multiple sampling)

* Configurable filter level

This module works with both 4-wire and 6-wire strain gauge load cells. The concept applied by the module requires compensation in the measurement system. This compensation eliminates the absolute uncertainty in the measurement circuit, such as component tolerances, effective bridge voltage or zero point offset. The measurement precision refers to the absolute (compensated) value, which will only change as a result of changes in the operating temperature.

<figure><img src="image_51.png" /></figure>

<figure><img src="image_52.png" /><figcaption>FIGURE 2.27 – Extrait de la présentation de la carte d'acquisition B&R X20AI1744. Caractéristiques générales et filtres implémentables.</figcaption></figure>

Dans une logique d'utilisation optimale des ressources de calcul disponibles et de traitement
au plus près de la mesure, il est intéressant d'exploiter au mieux les fonctions intégrées dans les
cartes d'entrées analogiques.

Pour cela, il est possible de réaliser des blocs fonctionnels dédiés, associés à des cartes d'en-
trées spécifiques, qui permettent d'offrir à l'utilisateur des interfaces permettant de contrôler les
fonctions prises en charge par la carte.

La carte B&R X20AI1744 permet d'amplifier et de convertir en valeur numérique la mesure de déformation donnée par le changement de résistance d'une jauge de déformation. L'amplification est définie par le facteur de jauge nominal et la carte permet d'effectuer plusieurs types de filtrage numérique. Le paramétrage du facteur d'amplification et le réglage des caractéristiques des filtres sont modifiables de façon synchrone par l'applicatif utilisateur.

Il est possible de créer une unité logicielle de programme associée à la carte d'entrée (cf. figure 2.28) à partir de la fonction élémentaire de traduction d'une entrée analogique en variable représentant une grandeur physique. Ce nouveau composant logiciel donne accès à l'utilisateur aux fonctions intégrées dans la carte à travers son interface d'entrée. Il ajoute également une description de la nature et de l'unité de la grandeur physique mesurée, dans l'esprit d'OPC-UA :
<figure><img src="image_53.png" /><figcaption>FIGURE 2.28 – Unité d'organisation de programme dédiée à la carte B&R X20AI1744 et table de mapping avec les entrées/sorties de la carte.</figcaption></figure>

le champ `EUInformation_unitId` de la structure de paramètres est renseigné avec la référence de cette grandeur définie dans la recommandation *Codes for Units of Measurement used in the International Trade* émise par le *United Nations Centre for Trade Facilitation and Electronic Business* [UNECE 2022]. Cette information peut être utilisée pour effectuer des conversions d'unités ou pour simplifier la création d'une table d'échange d'un serveur OPC-UA.

### 2.3.1.2 Composant intégrant plusieurs capteurs élémentaires

Dans le même principe d'améliorer la phase de prise d'informations, nous avons réalisé un bloc fonctionnel associé à la mesure d'une information composite obtenue à partir de plusieurs entrées analogiques.

Nous utilisons, au sein de l'équipe RoBioSS, des capteurs d'efforts multiaxes de la société Sensix pour des applications biomécaniques ou robotiques. Ils se présentent avec plusieurs facteurs de forme et des gammes de mesure très variables. La figure 2.29 en présente trois exemples : une plateforme de force exploitée pour déterminer les actions mécaniques exercées sur le sol par
un sujet ou un robot humanoïde et des capteurs d'efforts six composantes à intégrer dans des ergomètres, des dispositifs mécatroniques d'assistance, ou des cellules de cobotiques. Tous ces capteurs sont basés sur l'exploitation d'un groupe de jauges de déformations. Les capteurs délivrent une série de signaux analogiques amplifiés qui permettent d'obtenir le torseur d'actions mécaniques exercé sur le capteur à partir d'une matrice de calibration.

<figure><img src="image_54.png" /><figcaption>FIGURE 2.29 – Exemples de capteurs d'actions mécaniques Sensix, capteurs six axes et plate-formes de force disposées en chemin de marche.</figcaption></figure>

L'unité d'organisation de programme présentée figure 2.30 offre une interface unique pour l'ensemble de nos capteurs d'actions mécaniques. Ce composant logiciel est en cours de développement pour ajouter des fonctions de filtrage numérique des signaux générés similaires à celles de la carte analogique présentée précédemment. L'objectif de ce travail est de disposer d'une interface identique sur tous les blocs fonctionnels de gestion des entrées analogiques, les fonctions de filtrages étant prises en charge par la carte d'acquisition ou par l'automate, suivant les configurations matérielles utilisées.
<figure><img src="image_55.png" /><figcaption>FIGURE 2.30 – Bloc fonctionnel de capteurs d'actions mécaniques six composantes.</figcaption></figure>

### 2.3.2 Mise en œuvre d'algorithmes complexes

Dans notre stratégie de développement logiciel, l'exigence de pouvoir intégrer du code réalisé en C++ permet d'intégrer des bibliothèques tierces. Il est cependant nécessaire que ces dernières soient conçues pour un usage sur une cible temps-réel, qu'elles ne requièrent pas elles-même de nouvelles dépendances et qu'elles ne fassent pas usage d'allocation dynamique de mémoire dans la fonction exécutée périodiquement.

Lorsque ces conditions sont réunies, il est possible d'intégrer de nouvelles fonctions utiles sous la forme de classes fonctionnant comme des blocs fonctionnels. A titre d'exemple, je présente l'ajout d'une classe d'interpolation à partir de la bibliothèque *Reflexxes*. Cette classe est utilisée dans l'architecture de contrôle commande multiaxe présentée au chapitre 3.

Les bibliothèques Reflexxes permettent de générer en ligne des lois de commande de mouvement dont la destination peut varier de façon dynamique [Kröger 2011] [Kröger 2010]. Nous avons intégré la version II de cette bibliothèque qui permet de calculer à chaque instant une nouvelle consigne (*positions*, *vitesses*) pour un ensemble de composantes de vecteurs déplacements, en connaissant pour l'instant courant, les vitesses et positions actuelles, les limites en vitesses et en accélérations et la destination de ces mouvements.

L'exemple suivant illustre un cas d'utilisation de la méthode d'interpolation de consigne de position (*RMLPosition*) de la classe *ReflexxesAPI* de la bibliothèque *Reflexxes type II*. Cette méthode a été intégrée dans une unité d'organisation logicielle qui se comporte comme un bloc fonctionnel du standard IEC61131-3. Le bloc fonctionnel équivalent est présenté sur la figure 2.32 avec les structures qui lui sont associées.

Un programme C++ exécute périodiquement la méthode *Cyclic()* d'une instance de cet interpolateur. Ce programme correspond à un déplacement vers une destination absolue,
<figure><img src="image_56.png" /><figcaption>FIGURE 2.31 – Génération de consigne de position, *Reflexxes type II*, d'après [Kröger 2011].</figcaption></figure>

définie à l'activation de la variable **Execute**. Le mouvement prend fin lorsque la méthode **ReflexxesAPI::RMLPosition()** retourne l'information que l'algorithme de génération de trajectoire a atteint la cible prévue. Les entrées et sorties de l'interpolateur sont copiées dans une variable d'échange partagée avec le reste des programmes.

Ceci permet à un programme utilisateur d'exploiter la bibliothèque *Reflexxes* avec la même interface et le même comportement qu'un bloc fonctionnel compatible avec les préconisations de développement émises par PLCopen.

La figure 2.33 présente la spécification et le programme en Texte Structuré qui la traduit tels qu’un technicien de bureau d’études pourrait les réaliser. La fonction d’interpolation est utilisable par un professionnel de l’automatisme sans exigence de compétence complémentaire en développement informatique ou en algorithmique.
<table><thead><tr><th colspan="2">RbReflexxes</th></tr></thead><tbody><tr><td>VAR INPUT</td><td>VAR_OUPUT</td></tr><tr><td>Execute</td><td>Done</td></tr><tr><td>Abort</td><td>Busy</td></tr><tr><td>ContinuousUpdate</td><td>Error</td></tr><tr><td>rbROB_RFLX_IPalinp</td><td>Aborted</td></tr><tr><td></td><td>ErrorID</td></tr><tr><td></td><td>rbROB_RFLX_OPalinp</td></tr></tbody></table>

```
rbROB_RFLX_IPalinp
{
    double CurrentPositionVector[NAxes];
    double CurrentVelocityVector[NAxes];
    double
    CurrentAccelerationVector[NAxes];
    double MaxVelocityVector[NAxes];
    double MaxAccelerationVector[NAxes];
    double MaxJerkVector[NAxes];
    double TargetPositionVector[NAxes];
    double TargetVelocityVector[NAxes];
    bool SelectionVector[NAxes];
}

rbROB_RFLX_OPalinp
{
    double NewPositionVector[NAxes];
    double NewVelocityVector[NAxes];
    double NewAccelerationVector[NAxes];
}

Structure d'interface entre le programme C++
et des programmes IEC61131

RbReflexxesalinp
{
    bool Execute;
    bool Abort;
    bool ContinuousUpdate;
    rbROB_RFLX_IPalinp ip;
    bool Busy;
    bool Done;
    bool Aborted;
    bool Error;
    UINT ErrorID;
    rbROB_RFLX_OPalinp op;
    double Period;
}
```

<caption>FIGURE 2.32 – Interpolation en position Reflexxes : bloc fonctionnel équivalent.</caption>
<figure><img src="image_57.png" /><figcaption>FIGURE 2.33 – Spécification GRAFCET d'un exemple d'usage de l'interpolateur en position *Reflexxes*, code automate en ST et chronogrammes des déplacements générés.</figcaption></figure>
## 2.4 Conclusion

La bibliothèque *rtrmac* fournit des classes abstraites permettant d'attribuer aux classes dérivées un comportement homogène et régulier pour des composants logiciels répondant à des fonctions de toute nature, mais qui s'exécutent de façon périodique sur un système d'exploitation temps-réel dur. La bibliothèque dispose d'un ensemble d'outils nécessaires à la réalisation des fonctions d'intégration des composants matériels : adaptation des signaux d'entrée, régulation, gestion d'axes de mouvement quelle que soit la technologie d'entraînement électrique utilisée.

La structure d'une unité d'organisation de programme permet d'activer ou d'arrêter la fonction qu'elle réalise avec une interface utilisateur identique aux blocs fonctionnels des languages automates. Elle offre un mécanisme de validation des paramètres et une gestion des erreurs qui permettent aux programmes qui l'exécutent de ne pas rencontrer d'erreur fatale et mettre en place des stratégies d'attente d'action corrective de l'utilisateur ou d'abandon de la fonction demandée.

*rtrmac* peut être étendue pour :

- rendre accessibles les fonctions intégrées dans les cartes d'entrée-sortie,

- simplifier l'interface de capteurs composites,

- encapsuler les fonctions algorithmiques avancées de bibliothèques tierces.

Ces composants logiciels peuvent être exploités dans des programmes C++ ou, par l'intermédiaire de structures d'interface, dans les programmes codés en langage du standard automate, ce qui rend leur usage accessible aux spécialistes du monde de l'automatisme.

Le chapitre suivant porte sur l'extension de la bibliothèque *rtrmac* à une couche fonctionnelle supérieure à la gestion d'axe : le contrôle de mécanismes et de robots.
<figure><img src="image_58.png" /></figure>
# Développement d'une architecture personnalisable de contrôle de systèmes mécaniques

Cette partie présente le travail réalisé pour l'extension de la bibliothèque *rtrmac* au pilotage d'une grande variété de systèmes.

Cette évolution part du besoin généré par l'activité de l'équipe RoBioSS qui conçoit de nombreux dispositifs mécatroniques qui sont majoritairement en situation d'interaction avec des agents humains ou qui évoluent en environnement incertain.

Les exigences rencontrées sont les suivantes :

- développer un nouveau système robotique ou un banc de test dans une durée compatible avec la réalisation d'une thèse ou d'un projet de recherche et avec des ressources en ingénierie limitées,

- contrôler des systèmes très différents en termes de nombre d'axes d'entraînement, de nombre de capteurs à intégrer, de nombre d'effecteurs,

- pouvoir exploiter des transmissions mécaniques complexes,

- associer sur le même projet des acteurs avec des objectifs différents et des compétences en développement informatique variées.

La figure 3.1 présente une vue panoramique du travail réalisé pour la conception de cette architecture de contrôle-commande multiaxe. La figure est partagée en trois zones.

La description de la configuration matérielle fait apparaître les composants matériels des cellules robotiques que nous sommes amenés à développer. Comme présenté dans le chapitre 1.2.3, il s'agit d'une architecture où le traitement de l'information est réparti entre plusieurs calculateurs présents dans différents composants (PLC ou PC industriels, automate de sécurité, cartes électroniques, contrôleurs de mouvement). Certaines fonctions s'exécutent en parallèle, à partir d'informations différentes. C'est le cas de l'automate et de l'automate de sécurité qui ont des responsabilités différentes. Les calculateurs industriels modernes permettent également de travailler de manière redondante pour garantir la continuité de fonctionnement de l'installation en cas de défaillance du calculateur central.

La couche robotique de la bibliothèque *rtrmac* est structurée autour d'une décomposition en plusieurs espaces de description des mouvements : les actionneurs, les articulations pilotées, l'ensemble des articulations (qui peut être différent du groupe précédent dans le cas de mécanismes sous-actionnés), les axes de mouvement dans l'espace opérationnel. Les mécanismes de préparation du robot (mise sous tension, prise d'origine, couplage moteurs - articulations) et de gestion de l'arrêt d'urgence logiciel sont des éléments essentiels qui structurent le fonctionnement des programmes de gestion des robots. Ces éléments sont présentés aux sections 3.3 et 3.4.
Enfin, pour une application donnée, le logiciel de contrôle-commande est décomposé en
strates fonctionnelles dont :

— la responsabilité du développement peut être confiée à des acteurs différents

— l'exécution peut être affectée à un ou plusieurs calculateurs, selon la puissance de calcul disponible.

Ce point est détaillé à la section 3.2.2.

La première partie de ce chapitre présente les solutions industrielles disponibles ou en cours de développement pour le contrôle d'architectures robotiques. Je décris ensuite la démarche retenue pour la conception d'une nouvelle solution de contrôle générique de systèmes mécatroniques. Les deux parties suivantes portent plus précisément sur la définition des mécanismes et des robots. La dernière partie montre la mise en place de la démarche complète sur une architecture simple.
<figure><img src="image_59.png" /><figcaption>FIGURE 3.1 – Principe de réalisation d'un contrôleur de robot par extension de la bibliothèque *rtrmac*.</figcaption></figure>
## 3.1 Contrôle commande multiaxe industriel : des approches antagonistes

Le domaine de la programmation de machines industrielles multiaxes comporte un très grand nombre d'acteurs qui développent des solutions centrées sur leur matériel ou leur service et qui cherchent à étendre leur usage à des fonctions périphériques.

Les acteurs historiques sont les fabricants de composants de contrôle-commande, en particulier d'automates et de contrôleurs de mouvements et les fabricants de robots qui fournissent des quasi-machines avec des suites logicielles très évoluées et des solutions d'assistance et de maintenance. D'autres acteurs sont des fabricants de machine OEM qui développent leurs propres solutions pour leurs gammes de machine, à partir de technologies d'automatismes ou de commandes numériques et il y a également des entreprises d'ingénierie logicielle qui développent des solutions de contrôle externes ou des environnements de simulation pouvant générer des programmes exécutables par des automates, des baies robotiques ou des commandes numériques. Certaines suites logicielles peuvent générer, avec des post-processeurs, des programmes robots exécutés par les calculateurs des baies de commande. D'autres déportent dans un calculateur temps réel la génération de trajectoire et envoient des consignes de positions périodiques aux contrôleurs de robots.

La problématique du rapprochement entre les approches d'automatisme et de robotique est apparue dans les années 2010 [Nicolson 2016], [Unnikrishnan 2017]. Le constat de départ était la convergence entre les composants matériels présents dans les baies de commande de robot et les composants d'usage général des fabricants d'automatismes. Le second bénéfice attendu était la limitation du nombre de suites logicielles à acheter, installer et maintenir. Les aspects qui distinguent ces deux approches sont des différences de structuration de la conception du logiciel machine, des approches de développement très différentes entre ingénieurs automaticiens et ingénieurs robotiques et des contraintes de respect des normes de sécurité.

Le développement des fonctions de sécurité est traité de façon différente entre les fabricants de machines et les fournisseurs de robots, qui doivent, par ailleurs répondre à des contextes normatifs différents. Il s'agit des normes *Sécurité des machines : ISO 13849*, décembre 2015 et *Robots et dispositifs robotiques — Exigences de sécurité pour les robots industriels : ISO 1028* publiée en janvier 2011 et qui est en cours de révision. Pour les fabricants de robots, la connaissance complète de l'architecture de la machine permet de réaliser des fonctions intégrant le modèle cinématique du robot pour le contrôle de la validité de l'espace de travail et éventuellement le modèle dynamique pour la recherche d'impacts avec la surveillance des couples moteurs. L'approche des concepteurs de machine est basée sur le contrôle des axes de mouvement pour lequel le standard de sécurité logicielle fournit plusieurs blocs fonctionnels de surveillance. L'intégration de fonctions de sécurité prenant en compte l'architecture du robot est alors à la charge du concepteur et il est difficile, dans un automate de sécurité dont la puissance de calcul est limitée et les langages de programmation ont des fonctionnalités limitées, de recréer des fonctions de surveillance portant sur la position ou la vitesse du point de centre outil.

La possibilité prévue par [Nicolson 2016] de piloter des architectures robotiques par des systèmes de contrôle-commande d'automatismes s'est effectivement réalisée et les principaux acteurs de ce domaine proposent des bibliothèques logicielles très élaborées pour piloter des architectures robotiques. Certaines baies de commande de robot sont composées intégralement de composants d'automatisme standard, à l'exception de la carte de sécurité.
Pour le pilotage des robots à partir d'un PLC, [Unnikrishnan 2017] distingue trois types de configurations selon la prise en charge des fonctions robotiques (cf. figure 3.2) :

- *Self Hosted Kinematics* : cinématique auto-hébergée. Le processeur du contrôleur de mouvement prend en charge la planification des mouvements et les transformations cinématiques. Ceci n'est possible que pour des architectures mécaniques simples.

- *Self Hosted Custom Kinematics* : mécanismes personnalisés auto-hébergés. Les architectures mécaniques spécialisées conçues par les fabricants de machines de série (OEM) peuvent également être contrôlées par leurs développeurs qui implémentent les relations cinématiques dans le PLC.

- *Remote Hosted Kinematics* : mécanisme hébergé à distance. Les principaux fournisseurs de solution d'automation prennent en charge des robots tiers à l'aide de protocoles de communication propriétaires conçus en collaboration entre le fournisseur de commandes de mouvement et le fournisseur de robots. La programmation logique et l'initiation des commandes cibles seront effectuées sur le PLC. Dans un tel système, le contrôleur de robot assurera à la fois la planification de trajectoire et les transformations cinématiques.

<figure><img src="image_60.png" /><figcaption>FIGURE 3.2 – Solution de contrôles d'architectures robotique depuis un PLC.</figcaption></figure>

Cependant, il n'y a pas eu de convergence entre les solutions logicielles des fabricants d'automatismes et de robots. Avec l'apparition des cobots qui ajoutent d'autres modes de pilotage que le contrôle de position et la possibilité d'utiliser d'autres langages de programmation et de nouveaux types d'interfaces utilisateurs, l'offre de solutions techniques s'est encore étoffée.

Parmi les grands acteurs industriels, plusieurs stratégies sont actuellement en phase de déploiement. Une première est portée par le protocole de communication OCP-UA, présenté au
chapitre 2.1.2.2 qui cherche à proposer un modèle unifié de description et d'échange d'information avec les robots industriels des principaux acteurs du secteur. Un deuxième travail de standardisation est porté par la fondation PI qui a la charge de soutenir le développement des protocoles industriels PROFIBUS et PROFINET. En 2021, cette association a publié la version initiale de la spécification d'une bibliothèque de communication haut niveau entre robots industriels et PLC nommée SRCI pour *Standard Robot Command Interface*. A la suite de cette première étape, un travail de concertation a été engagé avec PLCopen pour envisager un travail d'unification du standard de commande multiaxe *PLCopen Motion Control Part 4 - Coordinated Motion*, avec la création d'un groupe de travail auquel j'ai pu participer.

## 3.1.1 Démarches de standardisation du pilotage multiaxe

### 3.1.1.1 Coordination de mouvement selon PLCopen

Dans l'approche PLCopen, le contrôle des machines multiaxes est traité de deux façons complémentaires. Il apparaît sous la forme de la création de relations de dépendance entre des axes esclaves et un axe d'entraînement principal (dans le document PLCopen Motion Control partie 1 et sous la forme de la coordination de mouvement entre axes articulaires pour obtenir le mouvement de l'effecteur (PLCopen Motion Control, partie 4).

Dans le cas de la conception de machines dédiées à la réalisation d'une tâche, il y a généralement un axe virtuel ou réel qui donne la cadence de fonctionnement de la machine ou de la ligne de production. Tous les mouvements complémentaires sont synchronisés sur celui de l'axe principal. Les dépendances entre axes sont de type boîte de vitesse, c'est à dire, qu'il y a une relation de proportionnalité entre le mouvement complémentaire et le mouvement principal avec éventuellement une possibilité d'avoir un décalage temporel pour ajouter une possibilité de réglage lors du fonctionnement ou pour corriger une dérive. Les situations de dépendance complexe entre le mouvement d'entraînement et un axe suiveur sont réalisées par des fonctions de cames électroniques qui décrivent les relations entre vitesses ou entre positions de ces deux axes, généralement sous la forme de fonctions polynomiales. Dans le cas de la réalisation de machines généralistes dédiées à la génération de mouvements, la notion d'axe d'entraînement n'existe plus et c'est le suivi de consignes dans l'espace opérationnel qui devient le point d'entrée du calcul de l'évolution des positions des moteurs.

Le document de PLCopen *Function Blocks for motion control : Part 4 - Coordinated Motion* porte sur la commande de groupes d'axes générant des mouvements multidimensionnels. La version 1.0 de ce document a été publiée en 2008, la version 2.0 rédigée en 2021, est en toujours en cours de finalisation. L'approche retenue est une extension de la commande uniaxiale définie dans les parties 1 et 2 du standard PLCopen Motion Control, elle présente :

- la définition des systèmes de coordonnées utilisables et des relations de transformation cinématiques entre eux,

- un ensemble de blocs fonctionnels décrivant des mouvements obtenus en combinant les actions des différents axes,

- un diagramme d'états du groupe d'axes qui coordonne les diagrammes d'états des axes élémentaires.

Les systèmes de coordonnées définis dans le standard sont les suivants :

- ACS : Axis Coordinate System : positions articulaires liées aux axes élémentaires,

- MCS : Machine Coordinate System : positions dans un repère fixe lié à la machine,
— *PCS* : Product Coordinate System : repère lié à la tâche dans l'espace de travail de la machine, il est défini par une relation de transformation géométrique à partir du repère MCS qui peut évoluer au cours du temps (il peut être lié au déplacement d'un convoyeur, par exemple).

Les positions définies dans ces différents repères sont liées par des relations cinématiques (entre *ACS* et *MCS*) et par des transformations cartésiennes ou cylindriques entre *MCS* et *PCS*. Les blocs fonctionnels se répartissent en plusieurs catégories :

— les blocs d'administration qui permettent :

— d'associer / de séparer les axes d'un groupe,

— d'affecter un modèle cinématique au groupe, le format de définition du modèle robôtique est laissé au choix du fournisseur de solution logicielle,

— de définir la fonction de conversion entre repères de travail.

— et les blocs fonctionnels de mouvement qui sont de deux types :

— des déplacements point à point, interpolés dans l'espace articulaire,

— des déplacements définis dans l'espace opérationnel, avec une interpolation linéaire ou circulaire ou avec une solution générique de génération de trajectoire.

Des fonctions complémentaires permettent de coordonner le mouvement d'un groupe d'axes avec un mouvement complémentaire externe pour réaliser des tâches de suivi d'objet, de dépose de produit (colle, peinture) ou de prise au vol. Ces fonctions de synchronisation ou de tracking (suivi du déplacement d'un convoyeur ou d'une table rotative) créent une relation maître-esclave (comme cela peut être le cas pour les axes individuels) entre l'axe externe et le groupe d'axes, ou inversement. Il est également prévu de pouvoir coordonner deux groupes d'axes entre eux avec une relation de transformation géométrique modifiable entre eux.

Les blocs fonctionnels de mouvement ont des entrées qui permettent de définir les transitions entre différentes commandes (cf. figure 3.3). Ce sont des extensions aux groupes d'axes de l'entrée *BufferMode* des blocs fonctionnels de mouvement présentés dans la section 2.1.4.3.

L'entrée *BufferMode* décrit le type de succession entre les deux mouvements, elle peut prendre les valeurs suivantes :

— *Aborting* interruption du premier bloc de mouvement et activation immédiate du second,

— *Baffered* le second mouvement commencera lorsque le premier sera terminé,

— *Blending-Previous* / *-Next* / *-High* / *-Low* la vitesse de transition est limitée à celle du premier ou du second mouvement, ou à la valeur maximale ou minimale des deux vitesses.

Les entrées *TransitionMode* et *TransitionParameter* décrivent la phase de raccord de la trajectoire au moment du changement de mouvement. Elles peuvent imposer la vitesse au moment du changement de consigne, une vitesse constante dans la phase de transition, la distance entre la trajectoire et l'intersection des deux segments (*P1P2* et *P2P3* sur la figure 3.3) ou d'autres contraintes laissées au choix des fournisseurs de solutions logicielles.
<figure><img src="image_61.png" /><figcaption>FIGURE 3.3 – Exemple de bloc fonctionnel de mouvement d'un groupe d'axes et illustration des types de transition entre deux déplacements *MC_MoveLinearAbsolute* vers les destinations P2 puis P3.</figcaption></figure>

### 3.1.1.2 Exemple de fonctionnement d'une bibliothèque robotique propriétaire

La figure 3.1.1.2 présente la chaîne de traitement de la génération de mouvement de la solution logicielle *mappRobotics* de B&R Automation. Elle permet de prendre en compte des architectures robotiques standards (bras de robot sériel, SCARA, robots parallèles Delta) ou de définir des architectures spécifiques. La stratégie de génération de mouvement est identique quelle que soit l'architecture.

La description du comportement attendu du robot est programmée dans les langages du standard IEC61131-3 avec les blocs fonctionnels de mouvement PLCopen Motion Control, partie 4 ou dans un fichier de script qui sera lu et interprété à l'exécution du programme. Ce second mode est identique au fonctionnement des contrôleurs de robots industriels et permet de charger des trajectoires ou des séquences de fonctions robotiques sans recompiler le code du logiciel.

Les ordres de mouvement sont les entrées de l'ensemble de fonctions logicielles *Motion chain* qui réalisent :

- la transformation des blocs fonctionnels en séquence de commandes de mouvement et l'interprétation des scripts

- le calcul de la trajectoire à partir la séquence de commande de mouvement en cours d'interprétation,

- l'adaptation de la trajectoire en fonction des limites des axes,

- l'inversion du modèle cinématique,
— la génération de consignes articulaires périodiques envoyées aux contrôleurs de mouvement.

Le traitement des programmes est décomposé en consignes de mouvement élémentaires nommées *Motion packets* qui sont traités par les modules logiciels de la *Motion Chain* en tâche de fond, au fur et à mesure du déroulement des scripts.

La figure 3.5 présente un exemple d'exécution par le processeur des tâches de génération de mouvement pour la partie robotique. La partie « génération de consigne » est exécutée périodiquement dans la classe de tâches la plus rapide. Les fonctions de préparation de la trajectoire sont exécutées en arrière-plan, avec les services systèmes non prioritaires. L'exécution de ce traitement dépend de la charge de travail du processeur et peut conduire à l'interruption temporaire du mouvement du robot.

<figure><img src="image_62.png" /><figcaption>FIGURE 3.4 – Chaîne de traitement logiciel d'un programme de génération de mouvement robotique, par la solution mappRobotics de B&R Automation.</figcaption></figure>

Le développement par les principaux fournisseurs de matériel d'automatisme de bibliothèques robotiques permet aux utilisateurs de réaliser des programmes de commande machine avec un haut niveau d'intégration d'architectures robotiques dans les situations où le PLC interagit avec les contrôleurs de mouvement ou avec une baie robotique donnant accès au contrôle en position articulaire. Ces bibliothèques fournissent également des fonctions complémentaires permettant :

— de charger des scripts qui permettent de modifier le fonctionnement du robot pendant l'exécution du programme automate,

— d'exécuter des programmes en code G, pour les utilisateurs de machines d'usinage, par exemple,

— de choisir les repères de travail et les repères outils,

— d'ajouter des fonctions de sécurité robotiques dans les programmes des automates de sécurité,

— de synchroniser simplement les mouvements du robot avec les mouvements d'axes externes.
<figure><img src="image_63.png" /><figcaption>FIGURE 3.5 – Exécution périodique et en arrière plan des modules de la motion chain B&R Automation.</figcaption></figure>

La solution B&R Automation permet également de définir des architectures mécaniques personnalisées en fournissant les modèles cinématiques tout en bénéficiant de la chaîne de génération de mouvements robotiques.

Cependant, ces solutions sont propriétaires et sont moins identiques entre fournisseurs de matériel que les bibliothèques de commande d'axe qui répondent à un standard plus contrai-gnant, ce qui rend difficile de mutualiser des développements pour les mettre en œuvre sur des plateformes concurrentes. La stratégie de traitement des ordres de mouvement est par ailleurs très consommatrice de ressources et est peu adaptée au développement de systèmes réactifs par rapport aux évolutions de l'environnement.

Le chapitre suivant présente une autre stratégie de standardisation du contrôle des robots industriels par un calculateur externe.

### 3.1.1.3 Interface standard robot - PLC selon la fondation PI

L'entreprise Siemens et l'association PROFIBUS & PROFINET International (PI) ont en-tamé en 2021 la création d'une interface logicielle unique permettant de contrôler des baies de robots industriels à partir d'automates programmables en collaboration avec plusieurs fabricants de robots industriels. La dernière version de la librairie robotique SIMATIC de Siemens implé-mente ce standard qui permet de faire exécuter, par un programme automate, des fonctions des contrôleurs de robots. Un travail collaboratif entre PI, PLCopen et l'association allemande VDMA essaie de rendre compatibles les standards.
L'approche développée par PI s'appelle *Standard Robot Command Interface to PLCs* [AG 2021]. Elle porte sur la définition d'un mécanisme de communication et sur la spécification de deux bibliothèques, l'une destinée à être implémentée côté PLC, la seconde côté contrôleur de robot. La réalisation des bibliothèques est à la charge des fournisseurs de composants.

L'objectif de l'interface robotique est de pouvoir développer le logiciel de pilotage d'un robot à partir de blocs fonctionnels de la bibliothèque de l'automate, sans nécessiter de programmation supplémentaire du côté du contrôleur de robot. Il s'agit donc d'une topologie de type *Remote hosted kinematics* où l'automate génère la séquence d'ordres de mouvements et reçoit les informations d'état du robot. La prise en charge du modèle cinématique et la génération de trajectoire sont à la charge du contrôleur de robot.

La communication entre les deux contrôleurs repose sur un protocole de communication basé sur Ethernet, non déterministe. La solution Siemens est construite sur une communication *Profinet*, mais l'interface *SRCI* n'est pas dépendante de cette solution. Le PLC et le contrôleur de robot échangent des datagrammes qui contiennent les données nécessaires à la réalisation des ordres de mouvements (dans le sens PLC vers robot) et les informations d'états du robot dans l'autre sens. Les deux calculateurs travaillent à leurs périodes respectives et la communication entre les deux permet un échange cyclique d'informations avec une période moyenne plus élevée. Cette solution permet aux fournisseurs de matériel de développer leurs solutions de façon relativement indépendante mais pose de nombreuses difficultés pour le contrôle fin des trajectoires ou lors de changement d'objectif en cours de mouvement.

La spécification *SRCI* prend également en charge les modes de contrôle standardisés des robots industriels, adaptés à un pilotage externe (mode automatique et modes de test à vitesses contrôlées), l'intégration de certaines fonctions de sécurité logicielles et des fonctionnalités dédiées à la gestion des outillages. Elle crée une interface homogène avec des quasi-machines ayant des définitions géométriques et des principes de fonctionnement parfois différents (par exemple, le paramétrage des transformations entre repères est différent selon les fabricants de robots).

La figure 3.6 présente de façon simplifiée la décomposition fonctionnelle proposée par la spécification SRCI. L'utilisateur développe son programme de gestion machine dans l'automate. Le fournisseur d'automate livre une bibliothèque donnant accès aux fonctionnalités robotiques, et des services permettant de mettre en œuvre le protocole de communication. Les blocs fonctionnels du programme utilisateur sont convertis en instructions de commande (par exemple *MOVE_LINEAR*), particularisées par des arguments (*Position*, *Velocity*, ...) et qui attendent en réponse un retour d'état ou de réalisation de la part du logiciel robot (*ACTIVE*, distance restant à parcourir ...).

Le fabricant de robot fournit une solution embarquée dans le contrôleur de robot. Celle-ci :

- met en œuvre, la communication, côté serveur,

- et transforme les ordres de mouvement en tâches qui vont interagir avec le générateur de mouvement et les autres fonctions robotiques disponibles.

Ce partage de tâches entre deux calculateurs introduit un nombre important de services intermédiaires. Les messages qu'ils échangent sont transmis par un protocole non déterministe à période moyenne plus longue que les périodes de travail des calculateurs. Côté robot, le générateur de trajectoire a besoin de connaître plusieurs commandes de mouvement à l'avance pour gérer les transitions. Toutes ces contraintes pénalisent la réalisation du contrôle-commande global. Elles imposent de mettre en œuvre :

- une mise en mémoire tampon des commandes de mouvement avec un traitement diffé-
<figure><img src="image_64.png" /><figcaption>FIGURE 3.6 – Architecture fonctionnelle de la solution SCRI.</figcaption></figure>

rencié suivant le mode d'exécution demandé (exécution des tâches en séquence, parallèle ou sur évènement)

— un mécanisme de déclenchement d'action (trigger) permettant de réagir rapidement à des évènements détectés par des capteurs externes (capteurs de présence, information caméra, capteur de position d'un convoyeur) câblés sur des cartes d'entrée de l'automate ou du robot.

Pour le développement de l'application côté automate, l'exécution distante des fonctions de mouvement a un coût important sur la garantie du comportement déterministe du logiciel de commande de la machine.

Par rapport aux blocs fonctionnels du standard monoaxe, les blocs fonctionnels de la solution SRCI présentent une interface plus complexe(cf. figure 3.7). Il est alors difficile d'interpréter les états de tous les blocs de mouvement pour connaître la situation instantanée du robot et la prendre en compte dans la couche logicielle de gestion machine.

La technologie SRCI est encore en cours de développement et un groupe de travail commun avec PLCopen a pour objectif de standardiser le développement des solutions de type *Remote Hosted Kinematics* où les fonctions robotiques sont appelées par le PLC de gestion d'une machine ou d'une ligne de production et où les fonctions robotiques sont exécutées dans les baies des robots. Les différences de paradigme de programmation, entre les scripts interprétés des contrôleurs de robot et les programmes exécutés périodiquement des contrôleurs industriels et l'exigence de développement une solution adaptée à tous les fabricants de robot rend difficile le travail de définition d'un standard.
<figure><img src="image_65.png" /><figcaption>FIGURE 3.7 – Comparaison des sorties d'information entre les blocs fonctionnels des standards PLCopen Motion Control (partie 1 : axe, partie 4 : axes coordonnés) et SRCI.</figcaption></figure>

3.1.2 Conclusion

<figure><img src="image_66.png" /><figcaption>FIGURE 3.8 – Comparaison de différentes solutions industrielles de pilotages de robots.</figcaption></figure>
L'offre de bibliothèques robotiques industrielles est très vaste et diversifiée. Pour les robots industriels standards, la situation actuelle où le fournisseur de matériel impose également l'usage de son logiciel de développement et son langage de programmation est en train d'évoluer. Les fabricants de matériel d'automatismes fournissent des bibliothèques robotiques propriétaires qui permettent de contrôler des architectures robotiques classiques ou personnalisables.

La figure 3.8 propose une classification des principales solutions technologiques selon deux axes :

- la possibilité de mettre en œuvre des fonctions robotiques évoluées (définition des trajectoires dans un outil de CAO, génération et simulation de scripts, identification des paramètres inertiels, optimisation de la dynamique du robot, gestion des outils, intégration de fonctions de sécurité liées au robot, intégration de capteurs de vision),

- l'aptitude à intégrer les axes d'un ou plusieurs robots industriels comme les autres d'axes de mouvement d'une machine de production.

Par rapport à ces deux critères, les solutions robotiques classiques, développées avec des composants spécifiques à partir de composants standards donnent accès à des fonctions robotiques évoluées mais nécessitent le développement d'un logiciel spécifique côté robot et une coordination entre les calculateurs. L'exemple 4 correspond à une solution propriétaire d'un fournisseur de matériel d'automatismes, qui permet de développer l'intégralité du logiciel de commande dans l'environnement de développement automate et de l'exécuter sur un seul calculateur. Les architectures pilotables sont limitées aux contrôleurs robotiques ouverts ou à la fourniture d'une mécanique de robot nue (sans contrôleurs de mouvements). La génération de trajectoires à partir de scripts en langage interprété ou en code G offre la possibilité de changer les trajectoires du robot à l'exécution du programme. Cependant la présence d'un mécanisme de planification de trajectoire fonctionnant en tâche de fond avec un horizon de quelques ordres de mouvement limite les possibilités de prise en compte des évolutions dynamiques de l'environnement. L'adoption de la technologie SRCI déplace les solutions robotiques dans le sens d'une meilleure intégration des robots dans le logiciel machine et supprime la nécessité de développer le logiciel robotique dans un autre environnement. Cependant, la prise en compte des évolutions de l'environnement est encore plus difficile dans la mesure où la coordination des fonctions de mouvement et leur exécution sont réalisés par deux calculateurs distincts, sans exigence de communication périodique, ni de fonctionnement déterministe.

La solution 3, basée sur une architecture matérielle à base de composants standards, d'un logiciel intégralement exécuté par un calculateur industriel de type PLC et d'une bibliothèque robotique construite sur la couche contrôle d'axe du standard PLCopen Motion Control correspond à la démarche que nous avons mise en œuvre et qui sera détaillée dans la suite de ce manuscrit. Elle va nous permettre de dissocier la génération de trajectoire et le calcul des consignes artificiels pour implémenter, sur des architectures robotiques classiques ou non conventionnelles des algorithmes de contrôle basés sur la résolution de problèmes d'optimisation.

Le revers principal de cette approche est que les fonctions optimisées des robots industriels ne sont pas accessibles. Ceci limite les performances atteignables, par exemple en termes de précision de suivi de trajectoire, puisque les fonctions de correction de la dynamique du robot sont maîtrisées (et non partagées) par les fournisseurs de matériel. Il faut également remarquer que fournir toutes les fonctions disponibles nativement sur un robot industriel nécessiterait beaucoup de développement. Cependant, le principe d'utiliser un calculateur industriel permet également de choisir d'exploiter les solutions technologiques des fournisseurs de matériel d'automatismes,
si celles-ci s'avèrent être mieux adaptées au cahier des charges de la machine.

## 3.2 Proposition d'une architecture logicielle pour le contrôle de mécanismes

Le contexte d'usage de notre bibliothèque de composants de contrôle-commande est celui de systèmes polyarticulés, constitués d'une partie opérative présentant un ensemble de pièces mécaniques supposées rigides reliées entre elles par des liaisons. Nous allons distinguer deux parties dans l'ensemble de ces composants mécaniques. Nous nommerons mécanisme le système de transformation de mouvement qui relie les sorties des actionneurs aux mouvements dans les liaisons entre segments. La partie robot décrit les relations qui relient les mouvements entre segments et le déplacement des effecteurs, composants portés par les segments terminaux (parfois également par des segments intermédiaires) qui vont interagir avec la matière d'œuvre sur laquelle travaille le système automatisé. Dans le cas d'un système destiné à déplacer un objet, l'effecteur est un préhenseur, mais il peut également s'agir d'un outil, d'une buse de peinture ou de colle, d'une torche ou d'une broche.

La fonction globale d'un système multiaxe est de contrôler la position de son effecteur ou le torseur d'actions transmises par l'effecteur sur l'environnement à partir du pilotage des actionneurs. La séparation entre mécanisme et robot fait apparaître deux groupes de relations :

- des relations de couplage qui relient les positions et les actions mécaniques motrices en sortie des actionneurs et les positions et actions transmises dans les liaisons entre segments,

- des relations de changement d'espace entre les mouvements des articulations et celui de l'effecteur ou entre les actions mécaniques articulaires et transmises vers l'extérieur.

Cette distinction entre « mécanisme » et « architecture robotique » est une simplification de la représentation de systèmes multicorps. Elle est basée sur une distinction des fonctions réalisées par les composants de transmission de puissance d'une part, et par l'agencement des liaisons du système polyarticulé, d'autre part. Elle s'appuie également sur l'existence de gammes de problèmes différents : certains systèmes sont intégralement des mécanismes : il n'y a pas de chaîne de transformation de mouvement après le niveau articulaire. Dans ce cadre, les enjeux de la modélisation sont la représentation des couplages entre actionneurs et degrés de libertés pilotés et la possibilité de prendre en compte des modèles de transmission plus complexes, lorsque ce niveau de définition est nécessaire. En effet, si l'on souhaite, dans un objectif de contrôle ou de surveillance, exploiter les mesures de couple actionneur, il faut pouvoir prendre en compte les écarts de comportement des transmissions par rapport au modèle linéaire idéal utilisé en première approche. Lorsque ces grandeurs sont identifiées, un modèle de transmission plus précis peut intégrer la déformation de la chaîne de transmission et les pertes par frottement.

La partie « architecture robotique » correspond également à un ensemble de problèmes spécifiques, traité abondamment par la littérature scientifique, qui portent sur la conversion de mouvements ou d'efforts entre les espaces articulaires et opérationnels.

### 3.2.1 Implémentation d'une solution robotique générique

Notre cahier des charges du logiciel de contrôle-commande d'un système multiaxe présente la fonction centrale suivante : fournir à l'utilisateur (opérateur ou système de contrôle de plus
haut niveau) un ensemble de fonctions permettant de contrôler les mouvements du robot avec une interface unifiée.

Cette fonction peut se décomposer en un ensemble de fonctions techniques (cf. 3.9). Pour les applications que nous souhaitons mettre en œuvre, nous avons choisi d'implémenter dans l'architecture générique de contrôleur de robot un nombre limité de fonctions élémentaires :

- déplacer chaque articulation en mode manuel,

- déplacer l'effecteur vers une position d'arrêt par une interpolation dans l'espace articulaire,

- déplacer l'effecteur vers une position d'arrêt par une interpolation dans l'espace opérationnel,

- suivre des consignes périodiques de positions articulaires,

- suivre des consignes périodiques de la vitesse de l'effecteur,

- suivre des consignes d'efforts articulaires (sur les architectures qui le permettent, en cours de développement),

- fournir les informations d'état du système (états du robot et de ses composants, informations géométriques, cinématiques et énergétiques).

<figure><img src="image_67.png" /><figcaption>FIGURE 3.9 – Gestionnaire de robot : fonctions techniques implémentées.</figcaption></figure>

A partir de l'identification de ces fonctions et des contraintes d'implémentation liées au type de matériel que nous avons choisi d'utiliser, il est possible de définir l'architecture de la bibliothèque de pilotage de robots. Pour cela, il est nécessaire de :

- définir les espaces de travail de robot,

- insérer une couche robotique dans la décomposition du logiciel de contrôle-commande,
entre la gestion des actionneurs et celle de la machine,

- définir les structures d'interface avec le programme utilisateur,

- ajouter un modèle abstrait de robotique dans la bibliothèque `rtrmac`,

- définir la stratégie de réalisation des fonctions complexes et identifier les bibliothèques externes à intégrer.

### 3.2.2 Décomposition hiérarchique du contrôle-commande

La figure 3.10 présente la décomposition de l'architecture des logiciels de contrôle-commande que nous avons réalisée. Cette décomposition est hiérarchisée par strates, de la couche proche du matériel à la couche supérieure de gestion machine qui sera elle-même intégrée dans la gestion d'un groupe de machines ou d'une ligne de production. Cette séparation en différentes couches prépare la répartition des tâches entre calculateurs et entre classes de tâches, selon le mécanisme présenté chapitre 2.1.3. Les couches inférieures ont besoin d'avoir une priorité plus importante et une période d'exécution plus courte que les couches suivantes.

<figure><img src="image_68.png" /><figcaption>FIGURE 3.10 – Architecture générique du logiciel de contrôle robotique.</figcaption></figure>

Le premier niveau réalise la conversion et le traitement des informations issues des capteurs, met en place les boucles de régulation correspondant à la topologie du système d'entraînement retenu (cf. chapitre 2.2.2) et met en forme les consignes pour les pré-actionneurs.

Le deuxième niveau exécute les gestionnaires d'axe moteurs. Le programme instancie et exécute les objets logiciels programmables (classes de contrôle-commande et classes de contrôle des paramètres) qui coordonnent l'usage des blocs fonctionnels PLCopen Motion Control.
Le troisième niveau est le gestionnaire de mécanisme ou de robot. Il exécute en interne des gestionnaires d'axes robotiques qui donnent accès au pilotage au niveau articulaire et masquent à l'utilisateur le pilotage direct des moteurs.

Le programme de gestion machine traduit la spécification d'une application particulière. Il sélectionne les fonctions robotiques utiles aux tâches à réaliser et les coordonne selon les instructions provenant de l'interface utilisateur. Si ces tâches sont définies dans l'espace opérationnel, la génération de mouvement articulaire est réalisée par un solveur externe au gestionnaire robot qui calcule les consignes de position par résolution d'un problème d'optimisation.

Nos logiciels de contrôle-commande sont associés à un jumeau numérique qui permet de mettre à disposition l'interface utilisateur et ajoute une représentation de la machine en environnement de réalité virtuelle. Cet aspect sera plus longuement détaillé dans le chapitre 4.1. Des algorithmes complémentaires permettant le contrôle haut-niveau du robot sont nécessaires. Ils peuvent être exécutés dans le contrôleur du robot ou à distance, par le jumeau numérique, par exemple.

Enfin, des tâches de service permettent d'échanger des informations sur un support Ethernet (par communication UDP ou OPC-UA) et de stocker des données calculées dans l'automate ou de suivre des séries de consignes fournies dans des fichiers.

### 3.2.3 Intégration dans la bibliothèque rtrmac

L'ajout de la fonctionnalité de pilotage de robots dans la bibliothèque *rtrmac* est réalisé par l'ajout d'un nouveau package, *RbRobot* qui contient la définition des nouveaux types de données, des nouvelles constantes et les classes permettant de définir deux unités d'organisation de programme :

- *RbMechanism* et *RbMechanismParamAuditor* sont des classes abstraites qui permettent le pilotage d'un groupe d'axes articulaires et la représentation des relations de couplage entre l'espace des moteurs et l'espace des coordonnées articulaires

- *RbRobot* et *RbRobotParamAuditor* sont des classes abstraites qui permettent le pilotage d'un groupe d'axes articulaires, la représentation des relations de couplage et les conversions entre espace opérationnel et espace articulaire.

Pour un nouveau robot ou un nouveau mécanisme, il faut créer :

- une bibliothèque C++ contenant les classes de contrôle-commande et de contrôle des paramètres qui dérivent d'un des deux jeux de classes de bases définies précédemment,

- et une bibliothèque IEC contenant les informations partagées avec les tâches codées avec d'autres langages : constantes définissant la taille des tableaux, définition du type de la structure de paramètres.

### 3.2.4 Définition des espaces de travail

La modélisation d'un système multiaxe en vue de son pilotage fait apparaître plusieurs espaces de travail qui vont permettre de décrire l'état du système ou de définir les consignes de génération de mouvement. Ce sont :

- L'espace des axes moteurs, repéré *Mot* qui donne accès au contrôle bas niveau des actionneurs via l'interface unifiée d'axe PLCopen Motion Control (cf. section 2.2.2.3).

- Axes articulaires pilotés : *Acs* (coordonnées exprimées dans l'espace articulaire, nommé « Axis Coordinate System » dans PLCopen Motion Control)
- Axes articulaires (axes pilotés et axes entraînés) : Jnt (Joints)

- Mouvements contrôlés de l'espace opérationnel : Mcs (coordonnées exprimées dans le repère machine, nommé « Machine Coordinate System »).

L'ensemble des mécanismes que nous souhaitons contrôler présente une variété qui nécessite de distinguer tous ces espaces. Certaines architectures sont en situation de redondance, le nombre de degrés de liberté actionnés est supérieur au nombre de dimensions contrôlées dans l'espace opérationnel. C'est le cas d'un bras robotique sur un axe linéaire : la cellule dispose de sept axes pilotables pour le placement en position et en orientation d'un effecteur. De façon opposée, certains mécanismes présentent un sous-actionnement : le nombre d'axes articulaires est supérieur au nombre d'actionneurs. Certains mouvements articulaires ne peuvent pas être directement contrôlés et dépendent des mouvements d'autres articulations.

Le tableau 3.1 présente plusieurs architectures pilotées dans le cadre de ce travail. Le robot 2R sériel représente la situation classique où les tailles de tous les espaces sont identiques, la cellule bras industriel et axe linéaire présente une redondance d'ordre 1. La main SeaHand est, quant à elle, fortement sous-actionnée.

<table><caption>TABLE 3.1 – Tailles des différents espaces pour plusieurs architectures de robots.</caption><thead><tr><th>Système</th><th>Actionneurs</th><th>Articulations pilotées</th><th>Articulations</th><th>Espace opérationnel</th></tr></thead><tbody><tr><td>Robot 2R enseignement</td><td>2</td><td>2</td><td>2</td><td>2</td></tr><tr><td>Bras 6 axes et axe linéaire</td><td>7</td><td>7</td><td>7</td><td>6</td></tr><tr><td>Main SeaHand</td><td>6</td><td>6</td><td>12</td><td>6</td></tr></tbody></table>

<figure><img src="image_69.png" /></figure>

Pour chaque robot, il est nécessaire de définir les relations qui permettent de passer entre les différents espaces (cf. Figure 3.11). Les relations MotToAcs et AcsToJnt correspondent au couplage cinématique direct réalisé par le mécanisme de transformation de mouvement. Les relations JntToAcs et AcsToMot représentent les relations inverses. La relation JntToMcs calcule la position et l'orientation du ou des effecteurs en fonction des positions articulaires. La relation inverse est difficile à généraliser. Elle n'est pas nécessaire pour les fonctions que nous avons décrites précédemment et n'a pas vocation à être dans le contrôle-commande bas niveau : elle pourra être fournie par le jumeau numérique.
<figure><img src="image_70.png" /><figcaption>FIGURE 3.11 – Relations entre espaces de représentation du robot.</figcaption></figure>

3.2.5 Intégration de bibliothèques tierces

Pour respecter notre objectif d'une dépendance minimale aux fabricants de matériel et aux environnements logiciels, nous avons choisi de limiter au maximum le nombre de bibliothèques tierces à intégrer dans les projets logiciels. Lorsqu'une dépendance devient nécessaire, il est important de retenir une solution stable, éprouvée en usage d'informatique temps-réel ou embarquée, si possible elle-même indépendante d'autres bibliothèques externes et dont les licences logicielles permettent l'usage en recherche et le transfert vers une solution industrielle.

Comme le domaine d'application des logiciels développés dans le cadre de ce travail n'inclut pas les fonctions de planification ou d'intégration de vision fournies par les intergiciels robotiques, les besoins d'intégration que nous avons rencontrés pour l'instant sont peu nombreux et nous n'avons ajouté que trois dépendances. Ces bibliothèques sont utilisées dans les programmes en C++. La démarche de création d'une interface pour utiliser une fonction externe dans les programmes en langages automates a été présentée au chapitre 2.3.2.

**Eigen** Les langages IEC 61131-3 et le C++ ne disposant pas d'une bibliothèque permettant de manipuler les matrices, nous avons choisi d'intégrer *Eigen* pour les opérations matricielles et les manipulations géométriques.

*Eigen* est une bibliothèque d'analyse numérique en C++ développée par Inria pour fournir des outils d'algèbre linéaire, les opérations matricielles et vectorielles, les transformations géométriques et des solveurs numériques. C'est un logiciel libre sous licence Mozilla Public License 2.0 qui a une communauté d'utilisateurs importante. Elle est intégralement composée de fichiers d'en-têtes ce qui la rend très facile à intégrer et applique le principe de la programmation générique avec les templates C++. Les matrices et vecteurs peuvent être alloués dynamiquement ou de façon statique, option que nous allons privilégier pour exécuter des programmes sur un runtime temps-réel.
**Reflexxes** Nous avons également besoin d'un mécanisme d'interpolation pour réaliser de la génération de mouvement simple, mais, contrairement aux générateurs de trajectoire des robots industriels, il est nécessaire que l'interpolation s'effectue de façon dynamique, à chaque pas de temps.

La bibliothèque de génération en-ligne de mouvements Reflexxes a été brièvement présentée au chapitre 2.3.2. Elle a été développée par l'entreprise Reflexxes, start-up essaimée du Robotics Institute de Technische Universität Braunschweig et qui a été rachetée par Google Inc.

Nous utilisons la version II de la bibliothèque Reflexxes qui a été publiée sous Licence publique générale limitée GNU, ou GNU LGPL (pour GNU Lesser General Public License). Cette bibliothèque permet de générer en-ligne des lois de mouvement à vitesses continues avec des bornes sur les vitesses et les accélérations. La destination des mouvements et ces bornes peuvent évoluer en cours de déplacement. Reflexxes type IV, sous licence commerciale, génère des mouvements pour lesquels les accélérations sont continues et les surraccélérations sont bornées.

**qpOASES** Pour développer des systèmes de contrôle réactif, nous avons besoin de résoudre des problèmes d'optimisation sous contraintes : la génération de consigne de vitesse doit produire des mouvements réalisables par le mécanisme, à chaque instant.

qpOASES [Ferreau 2017] est une bibliothèque open source de programmation quadratique réalisée à partir des travaux de H.J. Ferreau en 2006 pour réaliser un contrôle embarqué de la combustion d'un moteur diesel [Ferreau 2007], [Ferreau 2014]. Elle est publiée sous licence GNU Lesser General Public License (LGPL). Elle met en œuvre une stratégie de résolution rapide d'un problème d'optimisation sous contraintes qui est adaptée à un usage périodique pour un problème dont la formulation peut changer à chaque pas de temps. Les performances de qpOASES vont, dans un premier temps, permettre de résoudre l'inversion du modèle cinématique d'un robot sur les cibles que nous utilisons, avec une période de génération de consigne de l'ordre de 2ms. Le calcul des vitesses articulaires pourra, dans un second, répondre à des problèmes d'optimisation plus complexes.

## 3.3 Pilotage des mécanismes

Le premier type de système multiaxe que l'extension de la bibliothèque *rtrmac* permet de contrôler répond à la définition de mécanisme. Il s'agit d'un système réalisant une transformation de mouvement entre un ensemble d'actionneurs (dans notre cas, électriques : moteurs ou moteurs linéaires) et un ensemble d'axes de mouvement qui vont directement remplir des fonctionnalités.

La figure 3.12 présente les classes et la structure qui construisent l'unité d'organisation de programme de contrôle des mécanismes. Les classes *RbMC_Mechanism* et *RbMC_MechParamAuditor* sont des classes abstraites qui dérivent des classes *RbLConCParam* (qui implémente le modèle *Level-controlled* sans état d'achèvement) et *RbParam*, respectivement. Elles seront elles-mêmes dérivées pour décrire le comportement de mécanismes spécifiques et seront associées à une nouvelle structure de paramètres qui aura, au moins les champs présents dans la structure de base *MechParam)$_{typ}$*.

L'interface des classes dérivant de *RbMC_Mechanism* est la suivante, à chaque cycle :

- un tableau de structures d'informations d'axes robotiques renseigne sur l'état courant des moteurs (variable *mInfo*),
<figure><img src="image_71.png" /><figcaption>FIGURE 3.12 – Classes de base des modèles de mécanismes dans `rtrmac`.</figcaption></figure>

- un tableau de structures de commandes des axes moteurs est lu et peut être modifié (variable `mCmd`, tableau de structures de type `RbAxeRobInfoalin`, cf. chapitre 2.2.2.3),

- la variable `Cmd` contient les ordres envoyés par le gestionnaire machine au gestionnaire de mécanisme (variable `mCmd`, tableau de structures de type `RbAxeCmdalin`),

- la sortie `Info` permet de renseigner le gestionnaire machine sur l'état de tous les axes et du mécanisme.

La figure 3.13 décrit les échanges d'informations entre programmes. Le programme qui exécute les gestionnaires d'axes robotiques offre une interface unifiée vers les pré-actionneurs. Le programme de gestion de mécanisme ou de robot modifie les structures de commande des axes robotiques et utilise les structures d'information pour actualiser sa propre structure d'information et pour faire évoluer sa machine d'états. Ce programme échange des informations avec le programme de gestion machine qui a un rôle de coordination et d'interface avec l'utilisateur. Le programme de gestion modifie la structure de commande `Cmd` du robot pour déclencher des actions et lit l'état du robot dans la structure d'information `Info`.

L'unité d'organisation de programme **mécanisme** remplit les fonctions suivantes :

- exécution des gestionnaires d'axes articulaires sous la forme d'axes virtuels de type `RbJoint`,

- administration du groupe d'axes articulaires,

- administration du groupe d'axes moteurs externe,

- établissement d'une relation de couplage entre moteurs et articulations, et entre articulations pilotées et articulations liées,
- coordination des prises d'origine entre les deux groupes d'axes,

- mise à disposition de mouvements dans l'espace articulaire.

<figure><img src="image_72.png" /><figcaption>FIGURE 3.13 – Échange d’information entre programmes : gestionnaires d’axes moteurs, de mécanisme et machine.</figcaption></figure>

Les deux sections suivantes présentent plus précisément la démarche d'association des axes articulaires et des axes moteurs, puis les modes de pilotage possibles.

### 3.3.1 Description du couplage moteurs - articulations

Notre démarche de conception d'un gestionnaire de mécanisme repose sur les principes suivants :

- utiliser comme composants de base les unités d'organisation de programme d'axes robotiques présentées précédemment (cf. chapitre 2.2.2),

- externaliser les gestionnaires d'axes moteurs, ce qui permet de les tester et de régler leurs paramètres indépendamment du fonctionnement en groupe d'axes,

- réaliser un couplage entre axes en passant les moteurs en suivi de consigne périodique, de position ou de couple.

La description des phases de préparation du mécanisme (démarrage, arrêt, prise d'origine, création et rupture de la relation de couplage entre les axes moteurs et les axes articulaires) et la gestion de l'arrêt d'urgence logiciel sont présentées dans l'annexe A.

La difficulté de réalisation d'un gestionnaire de mécanisme générique repose en partie sur la diversité des situations de prises d'origine, cet aspect est également discuté dans l'annexe A.
<figure><img src="image_73.png" /><figcaption>FIGURE 3.14 – Classes mécanisme et robot : activation des modes de contrôle en position.</figcaption></figure>

La figure 3.14 présente les modes de déplacement en position articulaire utilisables et les transitions possibles entre ces modes :

- un mode de déplacement manuel de type *jogging* (MANUALMD_JOG_xxx), c'est un déplacement sur un seul axe tant qu'une demande d'avance ou de recul est active. Le mouvement s'arrête sur des positions de fin de course réglables.

- un déplacement vers une position d'arrêt avec coordination des mouvements ou non, avec une loi de vitesse saturée en vitesse et en accélération (AUTOMD_POS). Ce déplacement de base peut être interrompu par une demande d'arrêt avant d'atteindre l'objectif, ou par une nouvelle demande de mouvement avec un objectif ou des vitesses ou accélérations admissibles différentes. Ce fonctionnement correspond au mode d'interruption sans buffering du modèle PLCopen Motion Control, partie 4 (cf. section 3.1.1.1).

- un mode de déplacement de type *suivi de consigne de position périodique* (AUTOMD_CYCLICPOS) qui va permettre de mettre en place tous les modes de contrôles évolués, avec des algorithmes d'interpolation présents dans les blocs fonctionnels de pilotage de robot (comme la fonction d'interpolation dans l'espace opérationnel), soit avec des générateurs de consigne externes, exécutés dans l'OS temps-réel ou depuis un intergiciel tiers.

3.3.2 Applications

Cette section présente des exemples d'implémentation de notre architecture générique sur des mécanismes spécifiques. Pour ces deux exemples, l'intégration du logiciel de contrôle-commande
au plus près des contrôleurs de mouvement est nécessaire pour atteindre les performances attendues.

### 3.3.2.1 Pilotage d'une roue à inertie variable

A titre d'exemple, la fonctionnalité *pilotage de mécanisme* est utilisée pour le contrôle-
commande d'un système mécatronique conçu et réalisé dans l'équipe RoBioSS par Antoine Eon
et Arnaud Decatoire dans le cadre d'une prestation pour le CRITT Sport et Loisirs de Châtel-
lerault.

Il s'agit d'une roue à inertie variable contrôlée destinée à faire comprendre à des enfants des concepts physiques à partir d'informations proprioceptives. Un sujet assis sur un tabouret en liaison pivot d'axe vertical avec le sol, tient devant lui, bras tendus, une roue d'inertie par deux poignées sur l'axe de rotation de la roue. La vitesse de rotation et la valeur du moment d'inertie de la roue sont variables et contrôlées par le sujet qui va pouvoir expérimenter les principes de conservation du moment cinétique et d'effet gyroscopique.

<figure><img src="image_74.png" /><figcaption>FIGURE 3.15 – Roue à inertie variable et schéma cinématique du mécanisme.</figcaption></figure>

La roue présentée sur la figure 3.15 est motorisée par deux petits moteurs Brushless B&R 8LVA13 commandés par un contrôleur de mouvement ACOPOSmicro qui sont placés dans les poignées que tient le sujet. L'un des moteurs réalise l'entraînement de la roue, le second permet de déplacer radialement trois masses pour faire varier le moment d'inertie de l'ensemble. Le schéma cinématique décrit la transmission de puissance dans le mécanisme. Il permet de paramétrer les relations de couplage entre les rotations moteurs et les sorties du mécanisme, c'est à dire la rotation de la roue et la translation radiale des masses.

La tâche de gestion machine va sélectionner et coordonner les fonctions à utiliser dans ce cas précis. Ici, l'axe d'entraînement de la roue est piloté par paliers de vitesse réglables et la position des masses est définie par des paliers de position. La prise d'origine, dans le cas de ce mécanisme couplé avec des contraintes d'encombrement fortes, est réalisée par une fonction spécifique. La prise d'origine s'effectue sur une butée physique détectée par le dépassement d'un seuil de couple des moteurs.

Pour réaliser le logiciel de contrôle commande, il n'est pas possible d'utiliser directement l'unité d'organisation de programme de contrôle de mécanismes présentée sur la figure 3.12. En effet ce système demande des modes de pilotage différents pour les deux axes articulaires :
l'axe d'entraînement est piloté par des consignes de vitesses et l'axe de réglage de l'inertie, par des consignes de position. En outre, en raison de l'irréversibilité des liaisons vis/écrous et du frottement important dans le réducteur du moteur 1, la coordination des deux axes moteurs doit être très précisément réalisée pour ne pas bloquer le mécanisme.

Pour ces raisons, une classe spéciale de commande a été réalisée pour ce mécanisme. Elle exécute des blocs fonctionnels complémentaires de PLCopen Motion Control partie 1 pour confier au gestionnaire d'axe la coordination des deux axes moteurs. Il s'agit des blocs fonctionnels *MC_Gear* et *MC_Phasing*. Le premier crée une relation de couplage par un rapport de vitesses et le second permet d'ajouter un déphasage autour de cette relation.

Cet exemple permet d'illustrer l'intérêt d'adopter le standard PLCopen Motion Control pour pouvoir exploiter, lorsque le besoin émerge, des fonctions de mouvement complexes disponibles avec tous les équipements conformes au standard. Dans ce cas, un bénéfice complémentaire est que le transfert des fonctions de coordination entre moteurs à la carte de l'électronique de commande permet de choisir un calculateur central de plus faible puissance de calcul.

### 3.3.2.2 Extension au pilotage en couple articulaire

La figure 3.16 présente le banc d'apprentissage du geste *SHIVA* développé dans l'équipe RoBioSS par Arnaud Decatoire et Antoine Eon. Ce dispositif permet d'évaluer les stratégies d'apprentissage d'un geste défini par une séquence temporelle d'actions mécaniques à réaliser. Les premières applications de ce système portent sur l'amélioration des performances de sportifs et sur des méthodes de rééducation progressive, personnalisée à la morphologie et à l'état d'une personne blessée ou malade.

Le banc SHIVA est motorisé par un actionneur instrumenté également développé par Antoine Eon qui a conçu une gamme d'actionneurs électriques compacts et configurables pour ajuster la zone de fonctionnement couple / vitesse en fonction des exigences d'une application. Ces dispositifs appelés *ARM* (Actionneurs Robotiques Modulaires) sont constitués d'un moteur synchrone sans balais, d'un réducteur Harmonic Drive à rapport de réduction élevé et d'un capteur de couple en sortie de réducteur. Le choix de l'association moteur et réducteur permet de couvrir une large plage de spécifications. Le capteur de couple est intégré sur la bride de sortie du réducteur. Il est dimensionné en fonction du réducteur pour offrir la meilleure résolution possible avec la technologie retenue. Ce capteur est constitué d'un groupe de jauges de déformation dont le signal est conditionné par une carte B&R X20AI1744 présentée au chapitre 2.3.1. L'usage de ce capteur permet d'envisager la réalisation d'une commande en couple à partir de la mesure du couple transmis en sortie de réducteur. Ce travail est en cours de réalisation.

Sur le plan de l'architecture logicielle, cette nouvelle fonctionnalité impose une modification de la logique de couplage et de prise d'origine des groupes d'axes. La comparaison des stratégies de pilotage en position et en couple est présentée sur la figure 3.17. Dans le second cas, les axes moteurs sont contrôlés par des consignes de couple générées périodiquement à partir des couples articulaires désirés. Les axes moteurs sont les axes maîtres et les axes articulaires sont placés en suivi de consigne de position.
<figure><img src="image_75.png" /><figcaption>FIGURE 3.16 – Axe robotique modulaire (ARM) et intégration sur le banc SHIVA d’apprentissage du geste.</figcaption></figure>
<figure><img src="image_76.png" /><figcaption>FIGURE 3.17 – Logique de couplage entre axes moteurs et axes articulaires suivant les modes de pilotage (gauche : pilotage en position, droite : pilotage en couple).</figcaption></figure>
## 3.4 Pilotage des robots

Selon la décomposition que nous avons retenue, les systèmes de type robot se distinguent des mécanismes par l'existence d'un espace de travail complémentaire dans lequel les mouvements ou les tâches à réaliser sont définis. L'unité d'organisation de programme associée est décrite sur la figure 3.18, elle complète celle qui décrit le comportement des mécanismes en ajoutant des éléments de structure et des fonctions pour traiter le changement entre les espaces articulaire et opérationnel.

Pour pouvoir décrire la diversité des architectures que nous souhaitons pouvoir contrôler, nous distinguons les représentations suivantes :

- un groupe de *nMot* moteurs à piloter,

- un groupe de *nAcs* articulations pilotées qui sont liées aux moteurs par la transmission de puissance,

- un ensemble de *nJnt* articulations entraînées qui peuvent être plus nombreuses que les articulations pilotées,

- un groupe de *nMcsFrames* repères associés à un ou plusieurs effecteurs,

- un ensemble de *nMcsDof* degrés de libertés contrôlables dans l'espace opérationnels.

Les fonctions d'information *fkm()* et *updateMcsInfo()* permettent d'obtenir les positions et orientations des repères des effecteurs, leurs torseurs cinématiques et les matrices Jacobiennes associées qui relient les vitesses articulaires et les vitesses opérationnelles.

<figure><img src="image_77.png" /><figcaption>FIGURE 3.18 – Classes de base des modèles de robot dans *rtrmac*.</figcaption></figure>

Les stratégies de pilotage dans l'espace opérationnel implémentées pour l'instant sont présentées sur la figure 3.19. La définition des tâches à accomplir par le robot doit être formalisée
en termes de vitesse opérationnelle. Il y a deux possibilités de définition des consignes :

- des consignes instantanées de vitesses des degrés de liberté pilotables peuvent être générées par un contrôleur haut-niveau, embarqué dans le système de contrôle-commande du robot ou exécuté sur un calculateur externe (source 1),

- un déplacement vers un point d'arrêt dans l'espace opérationnel avec interpolation à vitesses et accélérations saturées sur les degrés de liberté pilotables (source 2).

La seconde option utilise un interpolateur pour générer les consignes de vitesses instantanées.

A partir des vitesses opérationnelles et des informations d'états du robot, les vitesses articulaires sont calculées par la résolution d'un problème d'optimisation sous contraintes qui inverse au mieux le modèle cinématique en assurant le respect de contraintes sur les vitesses articulaires. Cette démarche est présentée à la section 3.5.4.

La section suivante présente la démarche de construction d'un modèle de robot à partir d'une architecture mécanique simple.

<figure><img src="image_78.png" /><figcaption>FIGURE 3.19 – Stratégies de pilotage dans l'espace opérationnel.</figcaption></figure>

## 3.5 Illustration : contrôle-commande d'un robot sériel 2R

Pour valider l'approche proposée ici, j'ai implémenté la structure de contrôle sur un système robotique développé pour l'enseignement en licence professionnelle Automation et Robotique à l'université de Poitiers. Il s'agit d'un robot sériel à deux degrés de liberté en rotation dont la structure est légère, les deux moteurs étant fixés sur le bâti et qui ne présente pas de limite articulaire. Ce mécanisme présente un couplage dans la transmission ce qui nous permettra de
valider les fonctions de passage entre l'espace des moteurs et l'espace articulaire.

La figure 3.20 présente les composants de l'armoire de commande. Il s'agit de composants standards qui vont permettre d'évaluer la possibilité d'exécuter les logiciels que nous développons sur des architectures industrielles. Tous les contrôleurs de mouvement B&R ont la même interface logicielle avec la bibliothèque PLCopen Motion Control qui donne accès aux fonctions présentées à la section 2.1.4.1. La mise à l'échelle vers des machines de plus grandes puissances et présentant plus d'axes de mouvement est donc tout à fait directe.

La description du robot s'appuie sur les repères suivants :

— base : $R_0 = (O_1, (x_0, y_0, z))$

— bras 1 : $R_1 = (O_1, (x_1, y_1, z))$

— bras 2 : $R_2 = (O_2, (x_2, y_2, z))$

— l'effecteur est représenté par la position du Tool Center Point T et le repère associé
  $R_3 = (T, (x_3, y_3, z))$

Le paramétrage du système est défini dans trois espaces de dimension deux par :

— dans l'espace des moteurs, les positions angulaires $m_1, m_2$,

— dans l'espace articulaire : les positions angulaires $q_1 = (\vec{x}_0, \vec{x}_1)$, $q_2 = (\vec{x}_1, \vec{x}_2)$

— dans l'espace opérationnel : la position du TCP dans le plan $(O_1, x_0, y_0)$.
<figure><img src="image_79.png" /><figcaption>FIGURE 3.20 – Robot 2R sériel, vue du système et paramétrage.</figcaption></figure>
### 3.5.1 Description de la partie mécanisme

Ce mécanisme présente deux moteurs (dont les positions angulaires sont notées $m_1$ et $m_2$), deux articulations pilotées ($q_1$ et $q_2$) et trois étages de transmission, dont les rapports de transmission sont définis par les nombres de dents des poulies associées :

- A : entre le moteur 1 et l'axe 1, poulies de nombre de dents $Z_{M1}$, $Z_{1A}$,

- B : entre le moteur 2 et la poulie intermédiaire (3), paramètres $Z_{M2}$, $Z_{3B}$

- C : entre la poulie intermédiaire (3) et le bras (2), paramètres $Z_{3C}$, $Z_2$

Les relations de couplage directes en vitesse sont les suivantes :

$$ 
\begin{aligned}
\dot{q}_1 &= \frac{Z_{M1}}{Z_1} \dot{m}_1 \\
\dot{q}_2 &= \frac{Z_{3C}}{Z_2} \left( \frac{Z_{M2}}{Z_{3B}} \dot{m}_2 - \frac{Z_{M1}}{Z_1} \dot{m}_1 \right)
\end{aligned}
$$

Les relations de couplage inverses sont :

$$ \dot{m}_1 = \frac{Z_1}{Z_{M1}} \dot{q}_1 \qquad (3.1) $$

$$ \dot{m}_2 = \frac{Z_{3B}}{Z_{M2}} \left( \frac{Z_2}{Z_{3C}} \dot{q}_2 + \dot{q}_1 \right) \qquad (3.2) $$

(3.3)

Ces relations sont implémentées dans les méthodes `MotToAcs` et `AcsToMot` de la classe de contrôle de ce robot. Une fois le démarrage et la prise d'origine réalisés, les axes moteurs deviennent esclaves des axes virtuels liés aux articulations, les consignes positions moteurs sont calculées à chaque instant par l'exécution de la méthode `AcsToMot`.

### 3.5.2 Description de la partie robot

Le paramétrage associé au robot est illustré sur la figure 3.20. Les matrices de passage homogènes entre les repères associés aux différents solides sont définies ci-dessous. Les notations simplifiées $C1$, $S1$ représentent $cos(q_1)$ et $sin(q_1)$, les constantes $a_1$, $a_2$ sont les dimensions caractéristiques du système.

$$ T^{01} = \begin{pmatrix} C1 & -S1 & 0 & 0 \\ S1 & C1 & 0 & 0 \\ 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 1 \end{pmatrix} $$

$$ T^{12} = \begin{pmatrix} C2 & -S2 & 0 & a_2 \\ S2 & C2 & 0 & 0 \\ 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 1 \end{pmatrix} $$

$$ T^{23} = \begin{pmatrix} 1 & 0 & 0 & a_3 \\ 0 & 1 & 0 & 0 \\ 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 1 \end{pmatrix} $$

Les valeurs des paramètres géométriques du robot sont présentées dans la table 3.2.
<table><caption>TABLE 3.2 – Éléments caractéristiques du mécanisme et du robot.</caption><thead><tr><th>ZA<sub>M1</sub></th><th>ZA<sub>1</sub></th><th>ZB<sub>M2</sub></th><th>ZB<sub>3</sub></th><th>ZC<sub>2</sub></th><th>ZC<sub>3</sub></th><th>a<sub>2</sub></th><th>a<sub>3</sub></th></tr></thead><tbody><tr><td>30</td><td>60</td><td>30</td><td>32</td><td>31</td><td>32</td><td>202.24 mm</td><td>180 mm</td></tr></tbody></table>

### 3.5.3 Modèle cinématique

La matrice jacobienne naturelle $J$ relie la vitesse absolue du Tool Center Point (le point de référence du repère outil) du solide (2) et la vitesse de rotation absolue de (2) aux vitesses articulaires. Elle peut être obtenue à partir du calcul des torseurs cinématiques des liaisons et par la relation de composition des vitesses.

**Liaison 1 : pivot d'axe ($O_1, \vec{z}_0$)**

$$ \{C_{1/0}\} = \left\{ \begin{matrix} \vec{\Omega}_{1/0} = \dot{q}_1 \vec{z}_0 \\ \vec{0} \end{matrix} \right\}_{O} $$

$$ \text{avec } \vec{O_1 T} = (a_2.C1 + a_3.C12)\vec{x}_0 + (a_2.S1 + a_3.S12)\vec{y}_0 $$

$$ \vec{V}_{T,1/0} = \vec{V}_{O_1,1/0} + \vec{\Omega}_{1/0} \wedge \vec{O_1 T} = \dot{q}_1 (-(a_2.S1 + a_3.S12)\vec{x}_0 + (a_2.C1 + a_3.C12)\vec{y}_0) $$

**Liaison 2 : pivot d'axe ($O_2, \vec{z}_0$)**

$$ \{C_{2/1}\} = \left\{ \begin{matrix} \vec{\Omega}_{2/1} = \dot{q}_2 \vec{z}_0 \\ \vec{0} \end{matrix} \right\}_{O_2} $$

$$ \text{avec } \vec{O_2 T} = a_3.C12.\vec{x}_0 + a_3.S12.\vec{y}_0 $$

$$ \vec{V}_{T,2/1} = \vec{V}_{O_2,2/1} + \vec{\Omega}_{2/1} \wedge \vec{O_2 T} = \dot{q}_2 (-a_3.S12.\vec{x}_0 + a_3.C12.\vec{y}_0) $$

Finalement, la matrice $J$ telle que $(\vec{\omega}_{2/0}, \vec{v}_{T,2/0})_{R_0}^T = J \cdot (\dot{q}_1, \dot{q}_2)^T$ est :

$$ J = \begin{pmatrix} 0 & 0 \\ 0 & 0 \\ 1 & 1 \\ -(a_2.S1 + a_3.S12) & -a_3.S12 \\ a_2.C1 + a_3.C12 & a_3.C12 \\ 0 & 0 \end{pmatrix} $$

### 3.5.4 Pilotage dans l'espace opérationnel

Comme introduit dans la section 3.4, nous avons mis en place deux stratégies de pilotage en position dans l'espace opérationnel. Les deux approches partagent le même algorithme d'inversion du modèle cinématique pour calculer des consignes de vitesses articulaires instantanées. La figure 3.21 décrit la formalisation de ce problème. Les axes articulaires sont contrôlés par une consigne de vitesse qui doit être obtenue à partir des mouvements désirés dans l'espace
<figure><img src="image_80.png" /><figcaption>FIGURE 3.21 – Inversion modèle cinématique.</figcaption></figure>

opérationnel. Celle-ci est décrite sous la forme du torseur cinématique absolu de l'effecteur ou des vitesses instantanées de certains degrés de libertés dans l'espace opérationnel, dans le cas de robots pour lesquels l'effecteur ne dispose pas de six degrés de liberté.

Dans l'objectif de disposer d'un système de contrôle-commande robuste et pouvant réagir rapidement à des changements de consigne, nous avons choisi de formaliser la stratégie de calcul des vitesses articulaires sous la forme d'un problème d'optimisation sous contraintes qui rentre dans le cadre de la programmation quadratique.

Les données d'entrée du problème sont :

- la situation du robot à l'instant $t_k$ définie par ses positions et vitesses articulaires ($q_k$ et $\dot{q}_k$), la matrice jacobienne calculée à cet instant, $J$,

- les vitesses opérationnelles désirées à l'instant suivant : $\dot{x}_k^c$, fournies par l'algorithme de génération de trajectoire ou par la traduction d'une commande utilisateur dans le cas d'un mode téléopéré,

- un ensemble de limites actualisables à chaque instant portant sur les positions, vitesses ou accélérations articulaires et traduites en limites sur les vitesses articulaires.

La résolution du problème d'optimisation sous contraintes fournit les vitesses articulaires qui seront traitées comme consignes pour l'actionnement des articulations.

Ces vitesses $\dot{q}$ sont la solution de :

$$ \dot{q} = \operatorname{argmin}_{\dot{q}} \left( \frac{1}{2} \| J \dot{q} - \dot{x}^c \|^2 \right) $$
$$
\dot{q} = \operatorname{argmin}_{\dot{q}} \left( \frac{1}{2} \dot{q}^T J^T J \dot{q} - \dot{q}^T J^T \dot{x}^c \right)
$$

Si les contraintes portent sur le respect des limites d'accélération et de vitesse des articulations,
elles peuvent s'exprimer de la façon suivante :

$$
-\dot{q}_{max} \leq \dot{q}_{k+1} \leq \dot{q}_{max}
$$

$$
q_{\min} \le q_{k+1} \le q_{\max} \Rightarrow \frac{q_{\min} - q_k}{t_C} \le \dot{q}_{k+1} \le \frac{q_{\max} - q_k}{t_C}
$$

soit :

$$
\max(-\dot{q}_{max}, \frac{q_{min} - q_k}{t_C}) \le \dot{q}_{k+1} \le \min(\dot{q}_{max}, \frac{q_{max} - q_k}{t_C})
$$

La bibliothèque qpOASES résout des problèmes quadratiques mis sous la forme suivante :

$$
\min_x \left( \frac{1}{2} x^T H x + x^T g \right)
$$

avec :

$lbA \leq Ax \leq ubA$

$lb \leq x \leq ub$

— H, matrice Hessienne : $H = J^T J + \omega_0 \mathbf{1}$

— g, vecteur gradient : $g = -J^T \dot{x}_c$

— lb, ub, vecteurs limites : $lb = \max(-\dot{q}_{max}, \frac{q_{min}-q_k}{t_C})$, $ub = \min(\dot{q}_{max}, \frac{q_{max}-q_k}{t_C})$

Pour les architectures robotiques considérées pour l'instant, les problèmes quadratiques ren-
contrés ont les propriétés suivantes :

— la dimension du problème d'optimisation à résoudre est faible : le nombre de variables est de l'ordre d'une dizaine

— la matrice Hessienne et le vecteur gradient changent à tous les cycles automates,

— les bornes sur les inconnues peuvent varier suivant les tâches à remplir,

— le problème ne présente pas de contraintes couplées. En cas de mécanisme présentant un sous-actionnement, le respect des bornes sur les articulations contrôlées garantit, par construction, le respect des limites en déplacement sur les articulations couplées.

Sous ces hypothèses, la résolution du problème d'inversion du modèle cinématique se formule
de la façon suivante :

1. calculer la matrice Hessienne $H = J^T J$.

2. calculer le vecteur gradient $g = -J^T \dot{x}$

3. calculer les bornes inférieure *lb* et supérieure *ub* sur $\dot{q}$

4. obtenir la nouvelle consigne de vitesse articulaire $\dot{q}_{k+1}$ telle que :

$$
\min_{\dot{q}} \left( \frac{1}{2} \dot{q}^T H \dot{q} + \dot{q}^T g \right)
$$

avec :

$lb \le \dot{q} \le ub$
3.5.5 Suivi d'une consigne interpolée dans l'espace opérationnel

Pour illustrer le fonctionnement de la méthode de pilotage présentée précédemment, nous allons présenter un exemple de suivi de trajectoire. Il s'agit d'une succession de mouvements en ligne droite dans l'espace opérationnel. Les points de passage ont été choisis de telle sorte que la trajectoire de consigne du centre outil passe par des zones en dehors de l'espace de travail. Les deux bras du robot étant de longueurs $L_1$ et $L_2$ différentes, la surface contenant l'ensemble des positions accessibles est une couronne de rayon externe $L_1 + L_2$ et de rayon interne $L_1 - L_2$.

Deux exemples de stratégie de génération de la trajectoire de référence sont présentés<fnref n="1" /> :

- la trajectoire est interpolée entre deux points d'arrêt avec des limites en vitesse et accélération sur l'abscisse curviligne,

- la trajectoire est construite à chaque instant à partir d'un objectif à atteindre avec des limites en vitesses et en accélérations selon les deux axes du plan à partir de la situation instantanée $(x, \dot{x})$, avec la bibliothèque *Reflexxes type II*.

La figure 3.22 présente la trajectoire de référence avec le premier mode. Le centre outil suit le trajet $P_1 \to P_2 \to P_3 \to P_1$. Les segments $P_1 \to P_2$ et $P_3 \to P_1$ passent par des zones non accessibles. L'inversion directe du modèle cinématique n'a pas de solution à ces endroits et génère des erreurs d'exécution du code. Le problème d'optimisation sous contraintes fournit à chaque instant une solution approchée en vitesses articulaires compatible avec les limites spécifiées ou impose des vitesses nulles.

<figure><img src="image_81.png" /><figcaption>FIGURE 3.22 – Trajectoire de référence dans le plan $(x, y)$. Les dimensions sont en mm. Le disque correspond à une zone hors espace de travail.</figcaption></figure>

Les figures 3.23 et 3.24 présentent les mouvements réalisés avec les deux modes d'interpolation. Le passage des obstacles s'effectue sans arrêt du contrôleur avec des oscillations importantes des vitesses articulaires entre les valeurs de contraintes imposées. Les figures présentent :

- la trajectoire de consigne et la trajectoire réalisée,

- la position et la vitesse du centre outil dans le plan de déplacement,

- l'évolution des consignes et l'écart entre les positions du robot et les consignes.

Pour améliorer le comportement du système, il est possible de modifier l'expression de la fonction objectif qui va limiter ces oscillations. Cette approche est appelée régularisation de Tikhonov, elle consiste à ajouter un terme qui tend à minimiser les valeurs maximales des vitesses angulaires. Cette approche est régulièrement utilisée, par exemple dans le cas de la robotique

<footnote n="1">1. Ces trajectoires sont illustrées en vidéo sur src/koda.cnrs.fr.</footnote>
humanoïde où des systèmes avec des nombre de degrés de liberté élevés doivent répondre à des
plusieurs objectifs parfois incompatibles [Escande 2014], [Calinon 2017].

Les vitesses articulaires $\dot{q}$ sont alors solutions de :

$$
\dot{q} = \operatorname{argmin}_{\dot{q}} \left( \frac{1}{2} \| J \dot{q} - \dot{x}^c \|^2 + \frac{1}{2} \omega_0 \| \dot{q} \| \right)
$$

$$
\dot{q} = \operatorname{argmin}_{\dot{q}} \left( \frac{1}{2} \dot{q}^T (J^T J + \omega_0 \mathbf{1}) \dot{q} - \dot{q}^T J^T \dot{x}^c \right)
$$

La matrice Hessienne de notre nouvelle fonction d'optimisation s'écrit :

$H = J^T J + \omega_0 \mathbf{1}$

avec $\omega_0$, le coefficient de régularisation associé aux vitesses articulaires.

Les figures 3.25 et 3.26 présentent les nouveaux mouvements obtenus avec l'ajout du terme de régularisation de Thikonov. Les trajectoires sont lissées et les changements de signe des vitesses articulaires n'apparaissent plus. Dans le cas de l'interpolation directe, les consignes opérationnelles ne tiennent pas compte du retard pris par le robot lors du contournement de la zone inatteignable. Les consignes en sortie de l'interpolateur de la bibliothèque Reflexxes s'adaptent à la perturbation rencontrée. Dans les cas 3 et 4, où la régulation est activée, l'écart entre la consigne et la position réelle est presque nul pour l'interpolation par Reflexxes. Avec l'interpolation directe, cet écart augmente lorsque le robot prend du retard puis s'annule par le terme de correction intégré dans le calcul de la vitesse de consigne.

Une dernière amélioration peut être ajoutée. L'intérêt de minimiser les vitesses articulaires ne se présente que lorsque le robot s'approche de ses positions singulières. Comme le problème d'inversion du modèle cinématique est formalisé et résolu à chaque pas de temps, il est possible de pondérer le terme de régularisation en évaluant la proximité de la configuration du robot à ses configurations singulières. Deux critères qui évaluent cela ont été testés, ils portent sur l'état de la matrice jacobienne du robot. Les positions singulières sont atteintes lorsque l'une des valeurs propres de cette matrice s'annule. La figure 3.27 présente l'évaluation dans l'espace de travail du déterminant normalisé de la matrice jacobienne et par le rapport de la seconde valeur singulière sur la première. Cette approche est illustrée dans le cas d'une architecture robotique où la solution est triviale, mais elle peut être généralisée à des systèmes plus complexes.
<figure><img src="image_82.png" /><figcaption>FIGURE 3.23 – Interpolation directe, inversion du modèle cinématique sans régularisation. Trajectoires de consigne et réalisées (haut), déplacement et vitesse dans l'espace opérationnel (milieu), écart entre les consignes et les positions réelles (bas).</figcaption></figure>
<figure><img src="image_83.png" /><figcaption>FIGURE 3.24 – Interpolation par *Reflexxes*, inversion du modèle cinématique sans régularisation.</figcaption></figure>
<figure><img src="image_84.png" /><figcaption>FIGURE 3.25 – Interpolation directe, inversion du modèle cinématique avec régularisation.</figcaption></figure>
<figure><img src="image_85.png" /><figcaption>FIGURE 3.26 – Interpolation par *Reflexxes*, inversion du modèle cinématique avec régularisation.</figcaption></figure>
<figure><img src="image_86.png" /><figcaption>FIGURE 3.27 – Indicateurs de la proximité de positions singulières : déterminant normalisé de la matrice jacobienne et rapport des valeurs singulières de la matrice en fonction des positions articulaires. Haut : dépendance en ($q_1, q_2$), bas : évolution selon $q_2$.</figcaption></figure>
3.5.6 Conclusion

Finalement, la stratégie de pilotage dans l'espace opérationnel implémentée permet de séparer fonctionnellement la génération de trajectoire et le calcul des consignes articulaires instantanées.
La génération de trajectoire peut être :

— intégrée dans le logiciel de pilotage du robot dans le cas d'interpolation simple,

— calculée préalablement et chargée à partir d'un fichier,

— générée sur le PLC par une tâche spécifique au système à contrôler,

— générée sur un autre calculateur, à partir d'un jumeau numérique ou d'un système de téléopération.

Toutes ces stratégies peuvent fournir à chaque instant une consigne de position et de vitesse opérationnelle à atteindre à l'instant suivant. L'algorithme de calcul des consignes articulaires est alors défini ci-dessous.

Données d'entrées : $x_{i+1}^e, \dot{x}_{i+1}^e$ à atteindre au cycle suivant, situation courante du robot :
position, vitesse articulaires : $q_i, \dot{q}_i$, position, vitesse opérationnelles : $x_i, \dot{x}_i$.

1. calculer la consigne de vitesse corrigée : $\dot{x}_{i+1}^c = \dot{x}^e + k_p(x - x^e)$

2. calculer la matrice Jacobienne $J$ à partir de $q_i, \dot{q}_i$,

3. calculer le rapport entre les valeurs minimale et maximale des valeurs singulières $s_k$ de
$J : r_s = \text{abs}(\min_k(s_k)/\max_k(s_i))$

4. calculer la matrice Hessienne $H = J^T J - w_0 \mathbf{1}$ avec $w_0$ qui dépend de $r_s$,

5. calculer le vecteur gradient $g = -J^T \dot{x}_{i+1}^c$ à partir de la vitesse de consigne,

6. évaluer les limites sur $\dot{q}_{i+1}^e$ à partir des limites en accélération et vitesses des axes et éventuellement, en fonction de contraintes complémentaires liées à la tâche à réaliser,

7. déterminer la nouvelle vitesse de consigne $\dot{q}_{i+1}^e$ qui minimise $\frac{1}{2}\dot{q}_{i+1}^T H \dot{q}_{i+1} - \dot{q}_{i+1}^T g$,

8. calculer la nouvelle consigne articulaire $q_{i+1}^e = q_i + \dot{q}_{i+1}^e \cdot t_{cycle}$.

Ce chapitre présente ma contribution à l'extension de la bibliothèque *rtrmac* par un choix de formalisation du problème d'entraînement multiaxe. Cette formalisation est basée sur une description générique des architectures de mécanismes et de robot qui permet de traiter d'une façon homogène des systèmes très différents. Cette méthode, illustrée sur une architecture simple, est construite pour pouvoir être mise à l'échelle vers des systèmes avec des nombres d'axes plus importants.

La séparation entre les fonctions de génération de trajectoire et le calcul des consignes articulaires permet d'envisager d'autres stratégies d'optimisation par programmation quadratique, comme par exemple les approches basées sur la surveillance et la limitation de l'énergie cinétique des pièces en mouvement, cf. [Joseph 2020]. Les fonctions présentes dans la bibliothèque sont prévues pour être implémentées dans des calculateurs industriels conformes au standard IEC61131. Le logiciel de contrôle commande est exécuté dans un système d'exploitation temps-réel, au plus près des préactionneurs et des modules de conditionnement des capteurs. Cependant, les contraintes retenues sur le langage de programmation et l'intégration de bibliothèques tierces permettent d'étendre l'usage de notre approche à des cartes électroniques embarquées et à des simulateurs associés à des jumeaux numériques. Ces différents aspects sont présentés dans le dernier chapitre.
# Du jumeau numérique aux cartes embarquées

Ce chapitre présente plusieurs exemples qui illustrent la diversité des cas d’usages possibles de notre démarche de développement de logiciel de contrôle-commande. J’aborde tout d’abord la stratégie choisie par l’équipe pour le développement de jumeaux numériques connectés. Ces outils logiciels permettent de tester et valider le fonctionnement de systèmes mécatroniques en avance de phase sur la réalisation du dispositif physique, puis permettent à l’opérateur de contrôler le système en phase de production et peuvent également apporter une assistance à son maintien en condition opérationnelle.

Le principe de création d’un jumeau numérique connecté est, dans un premier temps, illustré par l’exemple d’un démonstrateur robotique simple associant un mode de simulation et un mode de conduite d’une maquette réelle. Ces deux situations utilisent la même version du logiciel de contrôle-commande.

La même approche est retenue pour la réalisation du logiciel de pilotage d’un préhenseur robotique sous-actionné. Dans un premier temps, la démarche de création des fonctions spécifiques à un nouveau robot est illustrée. Le développement du logiciel du prototype et son implémentation sur une architecture matérielle à deux calculateurs sont ensuite détaillés.

## 4.1 Conception de jumeaux numériques fidèles

La complexité croissante des machines, des dispositifs mécatroniques à concevoir, la nécessité de pouvoir simuler la gestion temporelle stricte, de reproduire fidèlement en simulation le comportement de la machine réelle, ont fait évoluer le besoin de simulation des systèmes cyberphysiques. C’est ce qui a fait émerger le concept de jumeau numérique connecté qui est élaboré dans ce chapitre.

### 4.1.1 Jumeau numérique : concept et définitions

La combinaison des technologies de l’automatisation et de la virtualisation doit contribuer à répondre aux défis de production de l’usine du futur par le développement de nouvelles solutions d’assistance et d’aide à la décision. Ces solutions pourraient permettre aux acteurs humains de valoriser leurs savoir-faire et de gagner en productivité et en confort pour répondre aux enjeux majeurs d’une production flexible et personnalisée. Ceci a conduit l’équipe RoBioSS à amorcer en 2017 une collaboration avec l’entreprise ITECA pour produire une première preuve de concept de jumeau numérique connecté entre une cellule de production robotique réelle et sa maquette virtuelle. En 2019, le laboratoire commun ANR MACH4 avec ITECA a été créé pour accélérer la production de jumeaux numériques connectés afin de relever ces défis.
<figure><img src="image_87.png" /><figcaption>FIGURE 4.1 – Scène virtuelle d’une cellule de production © ITECA.</figcaption></figure>

La figure 4.1 illustre une scène virtuelle d'une cellule de production industrielle. Cette maquette 3D qui représente la géométrie des pièces de la cellule ne constitue qu'une partie du jumeau numérique de l'installation.

Plusieurs définitions sont proposées dans la littérature mais elles sont souvent dépendantes
des domaines d'application. Les principaux domaines sont décrits ci-dessous.

**L'industrie de la construction et la ville intelligente**

L'adoption généralisée de la modélisation des informations du bâtiment (Building Information Modeling ou BIM) et l'émergence récente des applications de l'Internet des objets (IoT) offrent de nouvelles perspectives pour accompagner la prise de décision tout au long du cycle de vie des bâtiments. L'industrie de construction met en œuvre plusieurs stratégies pour accompagner cette prise de décision et réduire son impact carbone et le jumeau numérique des ouvrages dans le bâtiment constitue l'un de ses leviers stratégiques. Le jumeau numérique associe dans ce contexte : maquette numérique 3D et base de données associée, les liens et interactions entre les objets physiques et numériques, l'analyse comportementale de l'ouvrage soumis à diverses sollicitations (mécaniques, thermiques, énergétiques, etc.) [Deng 2021]. A titre d'exemple, EDF utilise la simulation numérique depuis des années pour prédire et analyser le comportement de ses structures et de ses ouvrages de production d'énergie en fonction des données collectées que ce soit sur le terrain ou via des campagnes d'essais spécifiques. Le développement récent des méthodes d'analyse des données basées IA et des techniques de réduction de modèle couplées avec des approches « data-driven » permettent d'envisager des modèles hybrides plus fidèles à la réalité couplant essais et calculs numériques. Au-delà de la construction, le jumeau numérique de la ville intelligente peut faciliter sa croissance, accompagner son évolution en testant des scénarios et en apprenant en permanence de l'environnement via la collecte des données capteurs et des matériels connectés [Soe 2017], [Chen 2018].
**L'énergie** La numérisation des industries de transformation de l'énergie grâce à la technologie des jumeaux numériques promet des améliorations progressives sur plusieurs aspects :

— la gestion et l'optimisation de l'énergie,

— l'amélioration de l'entretien et de la maintenance,

— la conception des nouveaux sites et l'amélioration des sites de production existants
[Morilhat 2018], et

— l'intégration des énergies renouvelables produites localement et régionalement [Yu 2022].
Le secteur de la production d'énergie nucléaire est certainement l'un de ceux pour lesquels les jumeaux numériques sont les plus élaborés. Les enjeux de la modélisation de systèmes complexes, de la taille et de la difficulté d'accès des installations, de conduite et de maintenance d'installation critique et de la formation des différents opérateurs sont tous présents. La figure 4.2 présente les différentes aspects à prendre en considération pour la réalisation du jumeau numérique d'une centrale nucléaire [Yadav 2021].

<figure><img src="image_88.png" /><figcaption>FIGURE 4.2 – Conception du jumeau numérique d'une centrale nucléaire, extrait de [Yadav 2021].</figcaption></figure>

**Le monde médical** La modélisation personnalisée du corps humain est un enjeu majeur dans le domaine médical, la modélisation fine de l'individu à partir de ses propres données de santé (obtenues à partir de techniques d'imagerie par exemple) offre la possibilité de créer son double virtuel. L'exploitation de cette représentation numérique permet d'accompagner le praticien pour envisager des prédictions et recommandations personnalisées pour le patient ou d'accompagner
le chirurgien dans la préparation d'interventions chirurgicales complexes, l'orthopédiste dans la production de prothèses adaptées. Les jumeaux numériques de services de santé, tels que rapportés dans la littérature[Bertezene 2022], permettent quant à eux de modéliser des systèmes complexes tels que des services d'urgence, de soins intensifs, de radiologie à partir des données qui sont collectées (nombre de patients sur une période donnée, examens, actes médicaux dans un service par type et par heure, etc.). Les objectifs poursuivis permettent de gérer plus efficacement les scénarios et les ressources (médicaments, disponibilité des équipements et fournitures, temps, personnels disponibles, flux de patients) en raison des aléas et des difficultés identifiées. Un jumeau numérique a été développé par Siemens Healthineers [GmbH 2018] afin d'améliorer les processus hospitaliers au sein du département radiologie de l'hôpital Mater Private Hospitals en Irlande et pour faire face à l'augmentation du nombre de patients et des temps d'attente associés. Une animation 3D réaliste y est associée à la collecte des données pour simuler les scénarios de fonctionnement du service.

## L'industrie et le contrôle de process
Le jumeau numérique est au cœur des enjeux propres à l'usine du futur. Il accompagne l'acquisition, l'échange et le partage de quantités de données variées contextualisées, accessibles au bon moment et au bon endroit constituant ainsi un outil majeur de la transformation numérique de l'industrie. Dans [Gregorio 2020], l'auteur rappelle que l'industrie aéronautique et spatiale, a été l'une des premières industries à exploiter le concept de jumeau numérique pour simuler numériquement le comportement mécanique des structures des aéronefs. Au-delà des défis posés par le développement de produits complexes, le jumeau numérique permet de superviser et gérer les performances de produits en fonctionnement afin d'en améliorer la sécurité, les performances et la satisfaction des clients. L'entreprise GE a ainsi créé une plateforme nommée « Predix » [Fuller 2020] utilisée pour l'analyse et la surveillance des données. De même Siemens a développé une plateforme appelée « MindSphere » avec un système basé sur le cloud qui connecte les machines et l'infrastructure physique afin d'accompagner la transformation de l'industrie par la production de jumeaux numériques basés sur les données et sur leur exploitation. A titre d'exemple, la figure 4.3, montre le jumeau numérique d'un robot connecté au produit réel et exploité avec un casque de réalité augmentée.

## La gestion de production
Dans le contexte de la production de biens manufacturés, le jumeau numérique a le potentiel de fournir une information continuellement actualisée sur les performances des machines et de la ligne de production [He 2019], [Mawson 2019]. La virtualisation de la production offre ainsi la possibilité de simuler et évaluer les différentes stratégies de fabrication et de planification. Les modèles virtuels se mettent à jour en fonction des données collectées provenant du monde physique, ce qui permet d'identifier et optimiser par la simulation dans le jumeau numérique le processus de production [Qi 2018].

Le concept de jumeau numérique est relativement récent puisqu'il a été introduit dans un livre blanc par Grieves en 2003 [Grieves 2014].

Les tableaux 4.1 4.2, d'après [Harper 2019] présentent les principales caractéristiques des jumeaux numériques et les liens avec les cas d'utilisation.

Plusieurs définitions sont proposées dans la littérature, une sélection d'entre elles sont introduites ci-dessous en respectant la chronologie des publications associées :

- La NASA définit le jumeau numérique comme étant une simulation multiphysique, multiéchelle et probabiliste intégrée d'un véhicule ou d'un système tel qu'il a été construit,
<figure><img src="image_89.png" /><figcaption>FIGURE 4.3 – Enrichissement d'une cellule robotique par ajout d'informations en réalité augmentée (© ITECA).</figcaption></figure>

<table><caption>TABLE 4.1 – Caractéristiques des jumeaux numériques [Harper 2019].</caption><thead><tr><td>Caractéristique</td><td>Définition</td></tr></thead><tbody><tr><td>Gestion documentaire</td><td>Archivage et suivi d'évolution de tous les documents associés à un équipement tout au long de son cycle de vie</td></tr><tr><td>Modèle</td><td>Représentation numérique de l'équipement qui contient ses propriétés et ses comportements</td></tr><tr><td>Représentation 3D</td><td>Propriétés d'un dispositif (mesurées ou simulées) mises en correspondance avec une représentation numérique en 3D</td></tr><tr><td>Simulation</td><td>Représentation d'un dispositif dans un environnement de simulation afin d'étudier son comportement</td></tr><tr><td>Modèle de données</td><td>Modèle de données normalisé pour la connectivité, l'analyse et/ou la visualisation</td></tr><tr><td>Visualisation</td><td>Représentation graphique de l'objet sur un périphérique de supervision</td></tr><tr><td>Synchronisation</td><td>Actualisation périodique du modèle sur des informations du monde réel</td></tr><tr><td>Analyses statistiques</td><td>Algorithmes et résultats de calcul basés sur les propriétés mesurées du dispositif</td></tr></tbody></table>

qui utilise les meilleurs modèles physiques disponibles, les mises à jour des capteurs, l'historique de la flotte, etc. pour reproduire la vie de son jumeau « réel » [Glaessgen 2012].

— Le jumeau numérique peut être défini comme une représentation virtuelle dynamique d'un objet physique ou d'un système tout au long de son cycle de vie, utilisant des données
<table><caption>TABLE 4.2 – Liens avec les cas d'utilisation [Harper 2019].</caption><thead><tr><th></th><th>Conception</th><th>Industrialisation</th><th>Exploitation</th><th>Maintenance</th></tr></thead><tbody><tr><td>Gestion documentaire</td><td>PLM</td><td>PLM</td><td>Instructions de conduite</td><td>Suivi modifications</td></tr><tr><td>Modèle</td><td>Prédiction des propriétés physiques</td><td></td><td>Optimisation</td><td>Diagnostic</td></tr><tr><td>Représentation 3D</td><td>Définition des composants et des ensembles</td><td>Instructions</td><td></td><td>Instructions</td></tr><tr><td>Simulation</td><td>Simulation pour la conception</td><td>Mise en service virtuelle</td><td></td><td></td></tr><tr><td>Modèle de données</td><td>Données d'ingénierie</td><td>Exigences de production</td><td>Données opérationnelles</td><td>Retour d'expérience</td></tr><tr><td>Visualisation</td><td></td><td></td><td>Etat de fonctionnement</td><td>Suivi des indicateurs de maintenance</td></tr><tr><td>Synchronisation</td><td></td><td></td><td>Actualisation en continu</td><td>Aide à la maintenance corrective</td></tr><tr><td>Analyses statistiques</td><td></td><td></td><td>Indicateurs de performance</td><td>Suivi de l'état de l'installation</td></tr></tbody></table>

qui s'actualisent pour permettre la compréhension de son évolution [Bolton 2018].

- Un jumeau numérique est une représentation numérique d'un article ou d'un assemblage physique utilisant des simulations intégrées et des données de service. La représentation numérique contient des informations provenant de sources multiples tout au long du cycle de vie du produit. Ces informations sont mises à jour en permanence et sont visualisées de diverses manières pour prédire le comportement actuel et futur, tant dans les environnements de conception que dans les environnements opérationnels, afin d'améliorer la prise de décision [Vrabič 2018], [Liu 2018].

- Une dernière définition considère le jumeau numérique comme une représentation numérique d'un produit unique et actif (appareil réel, objet, machine, service ou actif corporel) ou d'un système produit-service unique (un système composé d'un produit et d'un service associé) qui comprend ses caractéristiques, propriétés, conditions et comportements au moyen de modèles, d'informations et de données au sein d'une seule voire de plusieurs phases du cycle de vie [Stark 2019].

A partir de ces différentes approches, il est possible de converger vers les points synthétiques
suivants :

- Le jumeau numérique est une représentation numérique d'un système physique, constituée d'un ensemble de modèles du système, mise à jour en continu avec les données générées, acquises, stockées et consommées tout au long du cycle de vie du système physique;

- Comme évoqué dans [Fuller 2020], si les données circulent dans les deux sens entre un objet physique existant et sa représentation numérique, il s'agit d'un jumeau numérique. Une modification apportée à l'objet physique entraîne automatiquement une modification de sa représentation numérique et vice versa.

4.1.2 Particularisation du jumeau numérique pour les machines de production

Dans le domaine de l'industrie et particulièrement de l'automation et du contrôle multima-
chine ou multirobot dans l'environnement de production, on conçoit que le jumeau numérique
permet d'adresser au niveau applicatif, en temps réel, la supervision de processus, son opti-
misation, sa maintenance, son évolution ainsi que la formation des opérateurs. La connexion
continue du système réel avec son jumeau numérique permet ce mimétisme permanent entre les
environnements virtuel et réel.

Si on reprend les types de jumeaux numériques proposés dans [Syntec-Ingénierie 2021] illus-
trés dans le tableau 4.3, on conçoit que seul le jumeau numérique connecté avec ses homologues,
c'est-à-dire le jumeau numérique interconnecté offre le niveau d'interaction attendu pour ré-
pondre aux enjeux visés de l'usine du futur.

Il s'agit ainsi de proposer dans ce contexte, un jumeau numérique interconnecté capable de se connecter à la fois aux autres jumeaux numériques, mais également aux applications à travers les APIs (Application Programming Interfaces). Le succès de cette proposition de jumeau est fortement lié aux caractéristiques du jumeau numérique afin d'accompagner la totalité du cycle de vie du système physique depuis l'écriture du cahier des charges, jusqu'à la conception, au fonctionnement opérationnel et à la maintenance comme illustré sur la figure 5. Dans [Malakuti 2019], les auteurs montrent à travers l'exemple de l'industriel ABB la nécessité d'appuyer les caractéristiques des jumeaux numériques sur des standards pour répondre aux enjeux de consultation et de modification des bases de données et de connexion sécurisée au jumeau numérique par des logiciels clients différents.

Dans le contexte du soutien à l'automation, à la robotisation dans l'usine du futur, nous proposons une démarche de développement des jumeaux numériques basée sur des standards d'automatisation entre la machine simulée et la machine réelle. Cette stratégie offre le double avantage

- de pouvoir tester le comportement de la machine en amont,

- de pouvoir piloter de manière transparente soit la machine virtuelle à des fins de simulation ou de formation, soit la machine réelle en mode de contrôle supervisé, en mode de contrôle à distance ou en mode virtuel et réel simultanément.

Notre définition de la *fidélité de simulation* est relative à la reproduction du comportement cinématique et dynamique de la machine réelle dans l'environnement de simulation en s'appuyant sur le déterminisme temporel aussi bien du côté du système physique, que de sa représentation virtualisée.
<table><caption>TABLE 4.3 – Les différents types de jumeaux numériques [Syntec-Ingénierie 2021].</caption><thead><tr><td>Type de jumeau</td><td>Contenu du modèle numérique</td><td>Niveau d'échange des données</td><td>Utilisation, fonctionnalités</td></tr></thead><tbody><tr><td>4 Interconnecté</td><td>Interconnexion de plusieurs modèles numériques formant un ensemble fonctionnel cohérent</td><td>Échange entre différents jumeaux. Ensemble d'infrastructures.</td><td>Permet d'organiser un fonctionnement connecté et adapté pour un ensemble d'ouvrages, d'infrastructures ou d'équipements (smart city)</td></tr><tr><td>3 Communicant</td><td>Modèle numérique avec intégration des données acquises en temps réel (capteurs, IoT, actionneurs...)</td><td>Échanges bidirectionnels entre jumeaux numérique et réel (smart building, usine 4.0)</td><td>Permet de lier les données dynamiques ou temps réel d'un process pour le piloter, voire associer un algorithme qui réalise le pilotage du process</td></tr><tr><td>2 Dynamique</td><td>Modèle numérique avec intégration des données acquises en temps réel (capteurs, IoT...)</td><td>Interface entre les systèmes opérants, connexion unidirectionnelle</td><td>Extraction des données dynamiques et exploitation des données de fonctionnement (maintenance conditionnelle)</td></tr><tr><td>1 Statique</td><td>Modèle numérique d'objets avec informations non géométriques</td><td>Pas d'échange</td><td>Extraction de données d'entrée statiques pour conception, calcul et simulation</td></tr></tbody></table>

## 4.2 Démonstrateur numérique pour l'éducation

Cette section présente la réalisation d'une petite machine de production qui est associée à un jumeau numérique, comme illustré fig. 4.4. La totalité du développement matériel et logiciel a été réalisée par l'équipe Pprime dans le cadre des activités du Labcom ANR Mach4.

Il s'agit d'un robot cartésien deux axes dont l'effecteur évolue dans le plan vertical. Ce système est une version miniature de portiques cartésiens industriels, il nous sert à évaluer différentes modalités d'interaction entre un opérateur et un système automatisé en réalité virtuelle et est également utilisé comme support de travaux pratiques, en enseignement d'automation à
<figure><img src="image_90.png" /><figcaption>FIGURE 4.4 – Dispositif Mach4 Edlab : robot réel, usage et visualisation du jumeau numérique.</figcaption></figure>

l'université de Poitiers. Ce dispositif a été mis au point en collaboration avec ITECA et a été lauréat en 2021 de l'appel à projet EdLab de la région Nouvelle Aquitaine « Expérimentations de solutions numériques innovantes pour l'éducation et la formation professionnelle ».<fnref n="1" />

Ce robot est intégré dans une cellule de production sous la forme d'une machine de transfert automatisée avec le choix de scénarios de transfert de pièces entre convoyeurs ou de palettisation. Ces mises en situation représentent deux tâches industrielles courantes. Cette machine permet d'illustrer le concept de jumeau numérique connecté défini dans la section précédente. En effet, le même jumeau numérique peut être utilisé :

- en phase amont de la conception d'une machine pour tester et valider le logiciel de pilotage, évaluer a priori les performances de l'installation par l'estimation des cadences de production en fonctionnement nominal ou en mode dégradé ou pour former un opérateur,

- en conduite de ligne et en maintien en condition opérationnelle, comme interface utilisateur pour un conducteur de ligne ou un technicien de maintenance.

Dans ce second cas, la visualisation du jumeau numérique présente l'interface homme-machine qui s'affiche sur les écrans tactiles de conduite de la machine réelle. Ce logiciel est exécuté par l'automate programmable et mis à disposition par un protocole de prise en main à distance. Le serveur est exécuté par l'automate, le client par le périphérique distant (PC de supervision ou casque de réalité virtuelle).

<footnote n="1">1. Le principe de ce dispositif alliant maquette physique et jumeau numérique est présenté en vidéo sur src/koda.cnrs.fr.</footnote>
Cette IHM donne accès aux modes de fonctionnement implémentés dans le programme de gestion machine : modes de production automatique ou semi-automatique et mode manuel, par exemple. Un mode complémentaire permet de téléopérer la maquette à partir d'interfaces mises à disposition par la scène 3D du jumeau numériques. Ce sont des éléments d'interaction que l'opérateur peut manipuler à la souris, sur un écran tactile ou par les manettes des casques de RV, selon le périphérique choisi.

<figure><img src="image_91.png" /><figcaption>FIGURE 4.5 – Exemples de cas d'usage d'un jumeau numérique : simulation de l'environnement de la partie opérative (haut) ou mise à disposition virtuelle d'une cellule de grandes dimensions (bas).</figcaption></figure>

Dans le cas de l'usage de cet équipement pour des activités de formation, le jumeau numérique présente également d'autres aspects intéressants. Son premier usage est de mettre en scène le portique cartésien et de simuler des interactions avec d'autres éléments de la ligne de production. Il permet également de généraliser et d'abstraire le travail de génération de cycle de fonctionnement et de définition de trajectoire pour l'appliquer à des architectures similaires mais
de plus grande taille et de plus grande dynamique qui ne sont pas financièrement et matériellement accessibles pour des centres de formation (cf. figure 4.5). Enfin, sur des aspects purement éducatifs, un jumeau numérique permet de dupliquer une installation pour faire travailler des groupes en parallèle avant la phase de déploiement du logiciel sur l'installation réelle. L'ajout d'options de paramétrisation de la scène virtualisée et l'intégration dans le jumeau numérique de métriques mesurant la progression des étudiants en situation de développement du logiciel machine permettent d'envisager une personnalisation du travail à réaliser et de l'évaluation des compétences à acquérir.

Les deux modes de fonctionnement du dispositif sont présentés sur la figure 4.6 :

- il peut être utilisé en version *développement* avec le jumeau numérique en outil de visualisation, de diagnostic et d'auto-évaluation, puisque cet outil permet de valider les trajectoires programmées et la réalisation des fonctions de transfert ou de palettisation,

- lorsque les programmes sont validés en simulation, ils sont portés sur le système réel. Ce second mode de fonctionnement permet également d'évaluer plusieurs modes d'interaction entre l'utilisateur et le système automatisé.

<figure><img src="image_92.png" /><figcaption>FIGURE 4.6 – Architectures logicielles du dispositif en configuration de conduite (gauche) et en développement du contrôle-commande (droite).</figcaption></figure>

Le découpage logiciel du contrôle-commande est structuré en plusieurs couches qui correspondent à des fonctions techniques distinctes et à des niveaux de compétences différents (cf. figure 4.7). Cette structure hiérarchique est une version simplifiée de la structure générique implémentée dans la bibliothèque *rtrmac* présentée au chapitre 3.2.2.

Selon le niveau d'étude et l'objectif pédagogique choisi, les étudiants ont à réaliser ou à com-
pléter le programme correspond à l'une des couches fonctionnelles de la figure 4.7. Les premières applications portent sur la réalisation du programme de gestion machine ou sur la modification de l'interface homme-machine. Les étudiants des formations en automation pourront également produire un bloc fonctionnel de gestion, travailler sur la coordination d'axes et sur le paramétrage des interfaces matérielles.

<figure><img src="image_93.png" /><figcaption>FIGURE 4.7 – Décomposition fonctionnelle du projet de base du dispositif Edlab.</figcaption></figure>

Le système est en production (en situation d'assistance à la formation) depuis deux ans en licence professionnelle et en licence sciences pour l'ingénieur à l'université de Poitiers. L'activité de conception de dispositifs numériques pour la formation se poursuit dans le cadre du projet DemUP, lauréat de l'appel à projets PIA 4 AMI DEMOES « Démonstrateurs numériques pour l'enseignement supérieur » et qui a commencé en janvier 2022.

Les développements en cours portent sur l'ajout de dispositifs permettant de mesurer la progression des étudiants et la contribution de ces dispositifs d'assistance à l'acquisition de compétences professionnelles. Un second système automatisé avec un jumeau numérique associé est en cours de réalisation, avec un objectif d'intégration comme support d'enseignement de robotique et de dynamique des solides.

## 4.3 Création du modèle robotique d'un robot sous actionné

### 4.3.1 Présentation du préhenseur Seahand

Le projet Seahand, financé par l'Agence Nationale de la Recherche, portait sur la conception et la réalisation d'une main robotisée pour saisir des objets archéologiques fragiles en eaux pro-
fondes. Il a associé quatre partenaires : l'Institut Pprime, le LIRMM, le DRASSM (Département des recherches Archéologiques Subaquatiques et Sous-Marines), et le bureau d'étude Becom-d (Saint-Jean-de-la-Blaquière, Hérault).

Dans ce cadre, les travaux de thèse de Camille Mizera [Mizera 2019] ont porté, pour partie, sur la conception d'une architecture robotique permettant de réaliser un grand nombre de tâches opérées par un plongeur archéologue lors de fouilles sous-marines. La figure 4.8 présente quelques exemples de tâches de saisie nécessaires au plongeur qui peuvent être reproduites par le préhenseur robotique.

<figure><img src="image_94.png" /><figcaption>FIGURE 4.8 – Exemples de prises réalisables avec l'architecture choisie.</figcaption></figure>

Les contraintes de conception étaient nombreuses : le préhenseur doit être déplacé par un véhicule sous-marin téléopéré, la puissance électrique pour les actionneurs est limitée, l'électrique de commande doit être embarquée, la liaison avec le système de pilotage sur le bateau a une bande passante limitée et le préhenseur doit pouvoir évaluer et transmettre à l'opérateur une estimation des efforts d'interaction. Les exigences environnementales d'un travail en mer en grande profondeur sont évidemment très contraignantes.

Le travail de conception optimale a conduit au design d'une main à quatre doigts (trois doigts longs et un pouce en opposition), avec quatre articulations par doigt. Ce mécanisme est fortement sous actionné avec six moteurs qui entraînent quinze articulations. Ce préhenseur est présenté sur la figure 4.9. Les six motoréducteurs sont placés dans la partie arrière de l'avant-bras et les transmissions entre les poulies motrices et les poulies qui entraînent les articulations sont réalisée par des câbles textiles polymères.

Le travail de conception de l'électronique de commande a été réalisé en partenariat avec le Centre de Ressources Technologiques CATIE (Talence, Gironde). La solution réalisée est basée sur un microcontrôleur STM32 qui exécute le logiciel de contrôle-commande bas niveau et communique avec un contrôleur industriel. L'étage de puissance permettant le pilotage des
moteurs à courant continu est réalisé par des modules Escon qui fournissent une régulation courant - vitesse - position.

La partie suivante décrit le travail réalisé pour le développement du logiciel de contrôle-
commande de la main et se sépare en trois parties :

— la modélisation du robot et la création des objets logiciels programmables spécifiques pour le contrôle de ce système et leur validation en simulation,

— le développement du logiciel de pilotage d'un banc de test permettant de qualifier les performances d'un doigt,

— le développement d'une première version du logiciel de pilotage du préhenseur.

<figure><img src="image_95.png" /><figcaption>FIGURE 4.9 – Préhenseur Seahand.</figcaption></figure>

4.3.2 Description du système

La main Seahand constitue un bon exemple de mise en œuvre de la démarche de description de robot présentée précédemment pour plusieurs raisons. Ce mécanisme possède une architecture complexe avec un fort sous-actionnement et les effecteurs étant fixes sur l'avant-bras, les chaînes de transmission présentent des couplages. Enfin, le choix d'utiliser des transmissions par câbles permet aux doigts de s'adapter à l'objet à attraper, ce qui augmente les possibilités de saisie et permet également d'envisager d'évaluer les actions de saisie. Il sera par contre nécessaire de modéliser le comportement de ces transmissions de mouvement déformables pour les intégrer dans la commande.

Ce préhenseur robotique constitue également un exemple difficile à traiter de système multi-
robot puisque le pouce et le groupe constitué des trois doigts longs peuvent être décrits comme
deux robots dont la coordination est imposée par la tâche haut niveau de saisie de l'objet.

Les mouvements en sortie des motoréducteurs sont transmis par des câbles à des poulies liées
aux phalanges des doigts. Ces liaisons sont bidirectionnelles : deux câbles entre poulies motrices et réceptrices permettent le mouvement et la transmission d'effort dans les articulations dans les deux sens de rotation. Tous les motoréducteurs sont fixés sur le bâti de la main, la complexité de la conception de la main Seahand portait, en partie, sur la réalisation d'un routage des câbles qui permettent de découpler le mouvement d'abduction des doigts des mouvements de flexions entre phalanges.

<figure><img src="image_96.png" /><figcaption>FIGURE 4.10 – Seahand : paramétrage des moteurs et des articulations.</figcaption></figure>

**Modélisation de la partie mécanisme** La définition des modèles de transmission et des modèles robotiques de ce système fait l'objet de l'annexe B.

La partie *mécanisme* de notre système décrit le passage, via des transmissions poulies-courroies et les transmissions par câbles des positions moteurs à un nombre équivalent de positions articulations qui vont définir la configuration de l'ensemble du mécanisme. Ces six positions articulaires correspondent aux coordonnées ACS (axis coordinate system), définies dans le chapitre précédent. Les articulations retenues sont les abductions-adductions, les premières et deuxièmes flexions d'un doigt long (l'index, si le préhenseur est considéré comme une main droite) et celles du pouce. La figure B.1 de l'annexe B présente les relations qui vont définir les relations de couplage entre les positions moteurs et les positions ACS. Dans la suite de ce manuscrit, ces relations de couplage sont définies comme des relations linéaires, mais l'étude du
comportement visco-élastique des câbles est prévue dans les prochains mois. Les fonctions de
couplage pourront être adaptées en conséquence.

**Modélisation de la partie robot** Le traitement du pilotage en position dans l'espace opéra-
tionnel est réalisé selon la démarche présentée dans le chapitre 3.4 et illustrée sur la figure 4.11.
Les inconnues du problème d'optimisation sous contraintes sont les six positions articulaires
pilotées, les données d'entrées sont la vitesse opérationnelle de l'extrémité du pouce et celle de
l'un des trois doigts longs dont les mouvements sont couplés. Le choix du doigt qui impose le
mouvement d'entrée est choisi en fonction des zones de contacts retenues par l'algorithme de
saisie. Pour ce mécanisme redondant, les degrés de liberté pilotés dans l'espace opérationnel sont
sélectionnés par la tâche à réaliser.

<figure><img src="image_97.png" /><figcaption>FIGURE 4.11 – Pilotage en position dans l'espace opérationnel.</figcaption></figure>

Pour finir, la figure 4.12 présente les fonctions spécifiques de ce système qui permettent
de construire l'état du robot à partir des positions moteurs. Les relations de description du
mécanisme permettent de calculer les positions articulaires. Les positions des bouts de doigts $x_i$
et les matrices de rotation absolues des dernières phalanges $R_i$ sont obtenues à partir du modèle
géométrique direct, les vitesses des extrémités $\dot{x}_i$ et les vitesses angulaires des segments $\omega_i$, à
partir des modèles cinématiques.

La figure 4.13 décrit les relations inverses qui permettent d'obtenir les positions moteurs à
partir de consignes de vitesses articulaires ou des vitesses des effecteurs.
<figure><img src="image_98.png" /><figcaption>FIGURE 4.12 – Seahand : relations directes, construction de l'état du robot.</figcaption></figure>

<figure><img src="image_99.png" /><figcaption>FIGURE 4.13 – Seahand : calcul des consignes instantanées des positions moteurs.</figcaption></figure>
## 4.4 Développement du contrôle commande et implémentation

La figure 4.14 décrit les différents constituants de la plateforme de développement mise en
place pour la réalisation du logiciel de pilotage de la main Seahand. Le logiciel de contrôle est
déployé sur deux cibles matérielles : une carte électronique embarquée proche du préhenseur (qui
sera dans le sous-marin, dans la version de production) et un automate. La carte électronique
va réaliser les fonctions de bas niveau : le conditionnement des signaux des capteurs et l'alimen-
tation des moteurs et exécuter une partie des fonctions de contrôle. L'automate va exécuter les
fonctions de plus haut niveau et communiquer avec la carte électronique et le jumeau numérique.
Celui-ci va fournir l'interface de pilotage à l'opérateur et calculer les trajectoires permettant la
saisie de l'objet à attraper. La saisie d'objets de formes variées à partir d'un préhenseur sous-
actionné à plusieurs doigts est un problème complexe. Elle fait l'objet des travaux de thèse de
Bastien Arnaud dans l'équipe RoBioSS. Les algorithmes sont développés avec le logiciel Matlab
puis exportés sous forme d'une bibliothèque dont les fonctions sont exécutées par le jumeau
numérique.

<figure><img src="image_100.png" /><figcaption>FIGURE 4.14 – Présentation des principaux éléments du pilotage de la main Seahand.</figcaption></figure>

### 4.4.1 Architectures de contrôle-commande

Le développement du logiciel de pilotage du préhenseur a été réalisé sur deux dispositifs
complémentaires. Le premier est un banc de test destiné à évaluer les performances de manipu-
lation d'un doigt (cf. figure 4.15). L'architecture mécanique et la transmission sont identiques
à ceux du système réel, il est entraîné par trois motoréducteurs à courant continu. Cependant,
la partie commande est différente de celle du prototype de main pour lequel les contraintes
d'encombrement sont très exigeantes. Pour le banc de test, les modules de puissance sont des
composants industriels standards.

Le prototype de préhenseur robotique est équipé d'une carte électronique embarquée qui
<figure><img src="image_101.png" /><figcaption>FIGURE 4.15 – Banc de test d’un doigt robotique (vue de détail : doigt de la main Seahand).</figcaption></figure>

réalise une partie du contrôle-commande et la mise en forme de la puissance électrique des six moteurs qui mettent en mouvement les quinze articulations mobiles du mécanisme. La figure 4.16 présente les architectures matérielles des deux dispositifs, banc de test d'un doigt, à gauche et prototype de main, à droite. La figure 4.17 présente la décomposition logicielle pour les deux solutions. L'objectif de cette approche est de mutualiser au maximum les développements et de valider l'aptitude à la mise à l'échelle de la stratégie de développement présentée dans ce manuscrit. Les spécificités matérielles sont prises en compte par des tâches de régulation différentes.

L'adaptation des gestionnaires moteurs aux deux schémas de régulation est prise en charge par la bibliothèque `rtrmac`, le code de ces programmes est identique. Le gestionnaire de robot est également le même dans les deux cas, la spécificité de chaque robot (un seul robot sériel dans le premier cas, un groupe de doigts dans le second cas) est définie dans les classes associées aux objets programmables logiciels qui décrivent le comportement des robots *doigt* et *main*. La taille des espaces des actionneurs, des articulations, et de l'espace opérationnels sont différents. Les fonctions de couplage, le modèle géométrique direct et les modèles cinématiques sont définies pour les deux robots sous la forme de classes dérivées de la classe `RbMC_Robot` présentée sur la
<figure><img src="image_102.png" /><figcaption>FIGURE 4.16 – Comparaison des architectures matérielles entre le banc de test d’un doigt et la partie commande de la main Seahand et répartition des fonctions de pilotage moteur sur les différents composants.</figcaption></figure>
<figure><img src="image_103.png" /><figcaption>FIGURE 4.17 – Comparaison de l’implémentation du logiciel de commande entre le banc de test d’un doigt et celle prévue sur la partie commande de la main Seahand.</figcaption></figure>

4.4.2 Développement du logiciel de pilotage

Le développement du logiciel de contrôle-commande de la main a été réalisé dans l'environnement de programmation Automation Studio avec une configuration de simulation basée sur un automate virtuel et un jumeau numérique.

Pour évaluer les performances de l'environnement *rtrmac* pour le contrôle des robots, l'architecture de contrôle dans l'espace opérationnel présentée figure 3.19 a été implémentée sur une configuration de simulation, exécutée sur un automate B&R X20CP1586. Les résultats présentés ici portent sur la réalisation d'une séquence de déplacements interpolés dans l'espace opérationnel.<fnref n="2" />

Les points de passage sont définis sur la figure 4.18. Depuis la position de départ A, le TCP du pouce se déplace en ligne droite vers cinq points d'arrêt ($B_1 - B_2 - B_3 - B_4 - B_1$) puis le pouce revient à la position de départ avec un déplacement articulaire. Dans la première phase, la trajectoire attendue est réalisée par la librairie *Reflexxes* qui détermine une consigne instantanée de vitesse du TCP. L'inversion du modèle cinématique est réalisée par la solution à chaque pas de temps d'un problème d'optimisation par la librairie *qpOASES*. Les vitesses articulaires sont converties en consignes de déplacement moteur par le modèle de transmission. Les modèles d'axes fonctionnent en simulation et retournent les positions courantes des moteurs. Les positions articulaires et la position du TCP sont calculées par le modèle de transmission

<footnote n="2">2. Ce mouvement est présenté en vidéo sur src/koda.cnrs.fr</footnote>
et le modèle géométrique directs. L'ensemble des fonctions de la chaîne de pilotage sont donc utilisées.

<figure><img src="image_104.png" /><figcaption>FIGURE 4.18 – Points de passage de la trajectoire à effectuer et capture de la séquence simulée avec le jumeau numérique.</figcaption></figure>

La table 4.4 résume la durée d'exécution des tâches et la charge du processeur obtenues par l'utilisation du *profiler* fourni par le constructeur du matériel. Ce logiciel embarqué sur le PLC enregistre la répartition d'attribution du temps de travail du processeur aux programmes utilisateur et aux tâches systèmes. Tous les programmes de simulation de la régulation, de gestion des axes et du robot sont exécutés dans des tâches associées à la classe de tâches principale. Sa période d'exécution est de 1,6ms, sans débordement autorisé. La charge de travail est peu soutenue puisque le temps libre du processeur est de l'ordre de 50%. La tâche de contrôle du robot qui exécute les modèles directs, l'interpolation dans l'espace opérationnel et l'inversion du
modèle cinématique, a eu, sur le temps d'observation du profiler, une durée moyenne de 290 µs et une durée maximale de 317 µs.

Ces résultats sont obtenus avec un automate X20CP1586 qui est un composant moyen de gamme, destiné à des usages universels de contrôle de machines de production. Ses performances sont modestes au regard des composants généralement utilisés pour le pilotage de robots : il est équipé d'un processeur Intel Atom E680T à 1,6 GHz avec 512 Mo de SDRAM.

<table><caption>TABLE 4.4 – Rapport d'inspection du profiler de l'automate pendant l'exécution de la trajectoire test.</caption><thead><tr><th>Classe de tâches / tâches</th><th>% charge CPU</th><th>Durée nette moy. [µs]</th><th>Durée nette max. [µs]</th></tr></thead><tbody><tr><td>Idle tasks</td><td>48</td><td></td><td></td></tr><tr><td>Cyclic #1 [1, 6ms]</td><td></td><td></td><td></td></tr><tr><td>Timer</td><td>0.2</td><td>3</td><td>4</td></tr><tr><td>Hardware</td><td>2.2</td><td>35</td><td>41</td></tr><tr><td>Gest. axes</td><td>1.6</td><td>26</td><td>29</td></tr><tr><td>Gest. robot</td><td>18</td><td>290</td><td>317</td></tr><tr><td>Cyclic #2 [4ms]</td><td></td><td></td><td></td></tr><tr><td>Gest. machine</td><td>0.2</td><td>7</td><td>8</td></tr><tr><td>Com. UDP</td><td>0.3</td><td>11</td><td>17</td></tr></tbody></table>

### 4.4.3 Implémentation du contrôle-commande sur le prototype

La mise au point du prototype de préhenseur Seahand est en cours de réalisation. La décomposition fonctionnelle du contrôle-commande prévue initialement a dû être adaptée aux performances de la carte électronique embarquée. Celle-ci est basée sur un processeur STM32G474VET sur lequel le système d'exploitation FreeRTOS est installé au-dessus du runtime STM32Cube HAL du processeur STM32. Le runtime fournit les pilotes matériels, les bibliothèques et les services logiciels nécessaires pour interagir avec le microcontrôleur et ses entrées-sorties. FreeRTOS est un système d'exploitation léger qui prend en charge la gestion des tâches utilisateurs avec un ordonnancement périodique qui permet de se placer dans une organisation logicielle similaire à celle des automates programmables industriels. Plusieurs classes de tâches sont définies et sont exécutées sur interruption périodiques de timers système. La bibliothèque *rtrmac* est importée et les programmes utilisateurs développés dans l'environnement Automation Studio en C++ sont directement copiés dans STM32CubeIDE, l'environnement de développement associé au processeur utilisé.

La figure 4.19 présente l'architecture logicielle mise en œuvre sur le démonstrateur. Le comportement cyclique et périodique est réalisé par l'exécution de fonctions sur interruptions. Le groupe d'objets logiciels programmables *Cyclic #1* est associé à un timer de 4 ms, le groupe *Cyclic #2* à un timer de 20ms.

Pour la période d'exécution la plus rapide, la carte de contrôle réalise la mise en forme des données des codeurs, la régulation de position et la génération du signal PWM pour les modules
<figure><img src="image_105.png" /><figcaption>FIGURE 4.19 – Adaptation de l'architecture logicielle aux ressources disponibles.</figcaption></figure>

de commande des six moteurs à courant continu. Elle exécute également les gestionnaires d'axes moteurs du standard PLCopen Motion Control et un programme de coordination qui gère le groupe d'axes moteurs. Dans le groupe Cyclic #2, la carte traite les données issues des potentiomètres qui donnent l'estimation des positions de toutes les articulations de la main et met en place la communication UDP avec l'automate de gestion du robot. Automate et carte de contrôle échangent une structure d'information, renseignée par la carte et une structure de commande définie par l'automate. Un mécanisme d'échange de compteurs de vie permet de s'assurer de l'activité de la communication entre les deux composants.

L'automate communique également avec le jumeau numérique de la main qui anime une représentation numérique de la main, exécute l'interface homme-machine du préhenseur robotique et exécute les algorithmes de planification de la saisie. La spécification de la prise en main à distance par le jumeau numérique est définie sur le GRAFCET partiel de la figure 4.20. La variable *EnRemoteCtrl* est la variable permettant d'activer la prise en main à distance via l'IHM exécutée par l'automate. La variable *ComOK* évalue l'activité et la qualité de la communication UDP. L'étape 35 correspond à la situation d'arrêt due à un dépassement de l'écart admissible entre la situation réelle du préhenseur et la commande.

La stratégie de commande mise en place pour cette première version du prototype est la suivante<fnref n="3" /> :

— l'objet à saisir est placé par l'utilisateur du jumeau numérique dans le repère de la paume de la main,

<footnote n="3">3. Cette démarche est présentée en vidéo sur src/koda.cnrs.fr</footnote>
<figure><img src="image_106.png" /><figcaption>FIGURE 4.20 – Extrait de la spécification du gestionnaire de robot : prise en main distante par le jumeau numérique.</figcaption></figure>

- un algorithme de saisie est exécuté par le jumeau numérique pour déterminer les coordonnées articulaires permettant une saisie robuste,

- le jumeau numérique transmet au gestionnaire de machine exécuté par l'automate les coordonnées articulaires à atteindre et demande l'exécution du mouvement,

- la carte de contrôle exécute le déplacement coordonné dans l'espace articulaire et évalue l'écart entre les coordonnées articulaires mesurées et la position théorique imposée par les positions moteurs courantes. Si l'écart entre les positions théoriques et réelles dépasse une valeur limite, la fermeture du préhenseur s'arrête et l'utilisateur doit acquitter la demande d'ouverture du préhenseur.

### 4.4.3.1 Etat d'avancement

Le prototype est fonctionnel et a été mis en service à partir du logiciel développé en simulation en parallèle de l'installation et du paramétrage du système d'exploitation de la carte électronique. Le principe d'une plateforme de développement constituée de la bibliothèque *rtrmac*, du jumeau numérique *SmartUpp* et de *Matlab* a été mise en œuvre : le développement des algorithmes de saisie dans le cas d'un préhenseurs sous-actionné à plusieurs doigts est réalisé sous Matlab. Les fonctions qui convertissent la position et la géométrie de l'objet sont exportées en C++ et exécutée par le jumeau numérique. Celui-ci permet de faire changer les propriétés des objets saisis et transmet les positions articulaires de la séquence permettant la prise de l'objet à l'automate qui exécute le programme de gestion machine et délègue à la carte électronique la gestion des
axes moteurs.

Les tâches en cours de réalisation portent sur :

- la correction de défauts de conception mécanique pour augmenter la robustesse des trans-
  missions par câbles,

— la modélisation du comportement visco-élastique des câbles et son intégration dans la boucle de commande,

— la simplification de la couche de gestion du mécanisme (l'étage de liaison moteurs - articulations pilotées) pour pouvoir l'implémenter dans la carte électronique embarquée,

— le choix d'interfaces et la recherche de stratégies de téléopération de la main robotique par un opérateur en situation de conduite en réalité virtuelle,

— et, d'une façon plus générale, l'évaluation des performances globales du préhenseur.
# Conclusion

Le travail d'unification de la conception des logiciels de nos dispositifs mécatroniques s'est construit sur la synthèse de nombreux projets antérieurs. La version en cours de notre bibliothèque de contrôle-commande est actuellement utilisée sur six projets en parallèle et les retours d'expérience des différents cas d'usage sont en cours d'analyse.

La démarche retenue pour décrire les mécanismes et les architectures robotiques est adaptée aux mécanismes rencontrés. La diminution du temps de développement des nouveaux logiciels obtenue est compatible avec l'évolution du nombre de systèmes à développer.

L'un des objectifs majeurs de cette étude est le partage des responsabilités de développement. Cet aspect n'est pas encore évalué. La décomposition fonctionnelle retenue permet de confier à un automaticien les tâches de paramétrage des composants matériels. La réalisation des fonctions spécifiques pour un nouveau robot ou l'implémentation de nouveaux algorithmes peut être confiée à un chercheur ou un ingénieur sans prérequis de compétences en contrôle-commande industriel.

Les perspectives de mise en œuvre de ce travail sont nombreuses. Les choses sérieuses peuvent vraiment commencer. Les premiers développements que nous allons réaliser portent sur plusieurs aspects.

**Modélisation des mécanismes** Certains systèmes mécatroniques que nous avons conçus présentent des transmissions de mouvement dont le comportement doit être représenté finement pour pouvoir exploiter au mieux les dispositifs. C'est le cas des systèmes à transmission par câbles pour lesquels la modélisation des lois de comportement des câbles est nécessaire pour réaliser certaines fonctions. Pour les préhenseurs, cette étape est nécessaire pour évaluer les efforts de saisie et garantir le niveau de serrage des prises. L'extension des modes de pilotage au pilotage en couple articulaire est également un objectif scientifique pour lequel le travail de modélisation a été réalisé.

**Intégration de nouvelles lois de contrôle** Pour la partie contrôle haut-niveau, de nouveaux problèmes de calcul instantané de lois de consignes articulaires peuvent être développés. En particulier, des approches de limitation de l'énergie cinétique d'un robot en présence d'un opérateur ont été développées dans le cadre du projet européen COVR. Le travail réalisé dans cette thèse permet d'intégrer ces algorithmes dans le calculateur industriel pour minimiser les temps de réaction du système.

**Modèles dynamiques** La bibliothèque de contrôle multiaxe peut également être étendue pour intégrer des modèles dynamiques permettant d'évaluer des efforts d'interaction ou d'intégrer l'estimation des couples moteurs dans la régulation des axes. Des essais préliminaires ont montré l'intérêt d'utiliser des modèles spécifiques aux robots générés par des modèles paramétriques résolus par une approche formelle [Riccoboni 2022].

**Nouvelles architectures mécaniques** Enfin, de nombreux systèmes sont en cours de développement et vont pouvoir élargir la diversité des situations d'usage de notre solution de contrôle
multiaxe. Les prochaines applications vont mettre en œuvre des bras robotiques industriels dans des cellules à six, sept et treize axes coordonnés. Le portage de la bibliothèque *rtrmac* sur une nouvelle gamme de composants industriels est également en cours d'évaluation.
Annexes
<figure><img src="image_107.png" /></figure>
# Gestionnaire de mécanisme : phases de préparation

Une représentation simplifiée de la machine d'états des classes de gestion de mécanisme ou de robot est présentée sur la figure A.1. L'état `ACCESS_OK` correspond à la situation initiale, si tous les gestionnaires d'axes virtuels et réels peuvent être démarrés, l'état `DORMANT` s'active. Le mécanisme peut être ensuite démarré et référencé (ou référencé puis démarré). L'état où il est disponible pour démarrer un mouvement est l'état `STANDSTILL`. Les commandes `EnPowerOn`, `RqHome`, `EnStop` sont des champs de la structure de commande de type `RbRobCmdalin`. Ce sont des commandes à deux niveaux (de type `Enable` avec le préfixe `En`, ou à l'activation sur front montant de type `Request`). Les informations `PowerOn` et `IsHomed` sont des champs de la structure de type `RbRobInfoalin`, elles indiquent tous les axes ont démarré, et que toutes les prises d'origines sont faites, respectivement. L'activation de la commande `EnStop` provoque un arrêt d'urgence logiciel qui réalise un freinage rapide sur les axes articulaires. Lorsque cette commande est désactivée, la machine d'états évolue vers `STANDSTILL` si le couplage est toujours actif ou tous les axes sont arrêtés, le couplage est rompu et la machine d'états se place en `DORMANT`.

La figure A.2 présente plus précisément la réalisation des étapes de prises d'origine et de couplage. Suivant les mécanismes, la situation qui permet d'associer l'information des codeurs avec une configuration réelle peut être définie dans l'espace des moteurs ou dans l'espace des articulations. En général, la phase de calibration est réalisée sur des références physiques (repères, butées, information d'un capteur de position) liées aux articulations. Par contre, si les moteurs sont équipés de capteurs absolus ou si les valeurs des données des capteurs en position d'arrêt sont mémorisées, les prises d'origines suivantes sont réalisées à partir des informations des capteurs de position des moteurs. Ces deux possibilités se traduisent par des parcours différents de la machine d'états selon l'état de la variable `HomingFromAcsPos` qui est vraie lorsque la prise d'origine dans l'espace articulaire.

Lorsque les axes moteurs et les axes articulaires virtuels ont démarré et que la prise d'origine est faite, les axes moteurs passent en mode de suivi de consigne de position et le couplage est actif. A partir de ce moment, les consignes de position des moteurs sont calculées à partir des positions instantanées des axes articulaires par la méthode `AcsToMot` qui doit être définie pour chaque classe de mécanisme qui dérive de la classe abstraite `RbMC_Mechanism`.
<figure><img src="image_108.png" /><figcaption>FIGURE A.1 – Représentation simplifiée des phases de préparation d'un mécanisme ou d'un robot.</figcaption></figure>
<figure><img src="image_109.png" /><figcaption>FIGURE A.2 – Vue détaillée de la machine d'états des phases de prise d'origine et de couplage des axes moteurs et articulaires.</figcaption></figure>
<figure><img src="image_110.png" /></figure>
# Main Seahand : modélisation

## B.1 Mécanisme

La figure B.1 présente les relations définissant la transmission entre les six moteurs et les six articulations pilotées.

<figure><img src="image_111.png" /><figcaption>FIGURE B.1 – Main SeaHand, description du mécanisme. Conversion des positions moteurs en positions articulaires pilotées.</figcaption></figure>

La matrice $C_{mq}$ relie, pour un doigt, les variations de positions moteurs ($m$) aux variations de positions des articulations pilotées ($q$).
$$C_{ma} = \begin{pmatrix} \frac{D_{m1}}{D_{r1}} & 0 & 0 \\ 0 & \frac{D_{m2}}{D_{r2}} & 0 \\ 0 & -\frac{D_{m2}}{D_{r2}} \cdot \frac{D_{i23}}{D_{r3}} & \frac{D_{m3}}{D_{r3}} \end{pmatrix}$$

La figure B.2 illustre les relations les positions des articulations pilotées (ACS, notées q) et celles de l'ensemble des articulations (Joints, notées j).

<figure><img src="image_112.png" /><figcaption>FIGURE B.2 – Main SeaHand, description du mécanisme. Conversion des positions articulaires pilotées en positions articulaires.</figcaption></figure>

Les relations suivantes mettent en place les relations de couplage entre les articulations pilotées et l'ensemble des articulations pour le premier doigt long. La dernière flexion n'est pas directement actionnée, elle est liée par une relation de couplage aux deux précédentes flexions.
<figure><img src="image_113.png" /><figcaption>FIGURE B.3 – Vue partielle des transmissions par câbles.</figcaption></figure>

## B.2 Robot

Le paramétrage associé à un doigt est illustré sur la figure B.4. Les matrices de passage homogènes entre les repères associés aux différents solides sont les suivantes (on utilise les conventions $C1 = \cos(q_1)$, $S_1 = \sin(q_1)$) :

$$T^{01} = \begin{pmatrix} C1 & -S1 & 0 & 0 \\ S1 & C1 & 0 & 0 \\ 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 1 \end{pmatrix}$$

$$T^{12} = \begin{pmatrix} C2 & -S2 & 0 & L_1 \\ 0 & 0 & -1 & 0 \\ S2 & C2 & 0 & 0 \\ 0 & 0 & 0 & 1 \end{pmatrix}$$

$$T^{23} = \begin{pmatrix} C3 & -S3 & 0 & L_2 \\ S3 & C3 & 0 & 0 \\ 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 1 \end{pmatrix}$$

$$T^{34} = \begin{pmatrix} C4 & -S4 & 0 & L_3 \\ S4 & C4 & 0 & 0 \\ 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 1 \end{pmatrix}$$
<figure><img src="image_114.png" /><figcaption>FIGURE B.4 – Main SeaHand. Paramétrage d'un doigt.</figcaption></figure>

$$T^{45} = \begin{pmatrix} 1 & 0 & 0 & L_4 \\ 0 & 1 & 0 & 0 \\ 0 & 0 & 1 & 0 \\ 0 & 0 & 0 & 1 \end{pmatrix}$$

Le placement des doigts dans la paume est présenté sur la figure B.5. Le centre du repère robot *O* est au milieu de la paume.

Chaque doigt ne disposant que de trois degrés de liberté pilotés (abduction-adduction, première et deuxième flexions), les six degrés de liberté de la phalange terminale ne peuvent pas être contrôlés de façon indépendante. Les directions de l'espace opérationnel contrôlables choisis sont les trois composantes des vecteurs vitesses des TCP de l'index et du pouce. La matrice jacobienne naturelle du préhenseur regroupe deux matrices élémentaires indépendantes, l'une
<figure><img src="image_115.png" /><figcaption>FIGURE B.5 – Main SeaHand. Placement des quatre doigts sur la paume.</figcaption></figure>

pour l'index et la seconde pour le pouce. Ces matrices sont telles que :

$$ \dot{x}_{if} = J \begin{pmatrix} \dot{q}_1 \\ \dot{q}_2 \\ \dot{q}_3 \end{pmatrix} \quad \dot{x}_{th} = J \begin{pmatrix} \dot{q}_4 \\ \dot{q}_5 \\ \dot{q}_6 \end{pmatrix} $$

$\dot{x}_{if}$ et $\dot{x}_{th}$ sont les vecteurs vitesses des points terminaux des phalanges distales de l'index et du pouce, repérés $T$ sur la figure B.4.

Les matrices jacobiennes de l'index $J_{if}$ et du pouce $J_{th}$ s'expriment de la façon suivante :

$$ J_{if}(:, 1) = \begin{pmatrix} 0 \\ 0 \\ 1 \\ -S1.(L_1 + L_2.C2 + L_3.C23 + L_4.C234) \\ C1.(L_1 + L_2.C2 + L_3.C23 + L_4.C234) \\ 0 \end{pmatrix} $$
$$ J_{if}(:, 2) = \begin{pmatrix} S1 \\ -C1 \\ 0 \\ -C1.(L_2.S2 + L_3.S23 + L_4.S234) \\ -S1.(L_2.S2 + L_3.S23 + L_4.S234) \\ L_2.C2 + L_3.C23 + L_4.C234 \end{pmatrix} $$

$$ J_{if}(:, 3) = \begin{pmatrix} S1 \\ -C1 \\ 0 \\ -C1.(L_3.S23 + L_4.S234) \\ -S1.(L_3.S23 + L_4.S234) \\ L_3.C23 + L_4.C234 \end{pmatrix} $$

$$ J_{th}(:, 1) = \begin{pmatrix} 1 \\ 0 \\ 0 \\ 0 \\ -C1.(L_1 + L_2.C2 + L_3.C23 + L_4.C234) \\ -S1.(L_1 + L_2.C2 + L_3.C23 + L_4.C234) \end{pmatrix} $$

$$ J_{th}(:, 2) = \begin{pmatrix} 0 \\ C1 \\ S1 \\ L_2.C2 + L_3.C23 + L_4.C234 \\ S1.(L_2.S2 + L_3.S23 + L_4.S234) \\ -C1.(L_2.S2 + L_3.S23 + L_4.S234) \end{pmatrix} $$

$$ J_{th}(:, 3) = \begin{pmatrix} 0 \\ C1 \\ S1 \\ L_3.C23 + L_4.C234 \\ S1.(L_3.S23 + L_4.S234) \\ -C1.(L_3.S23 + L_4.S234) \end{pmatrix} $$

Ces relations permettent de particulariser, pour ce robot :

- les fonctions de couplage directe et inverse qui relient les positions moteurs, les articulations pilotés, puis toutes les articulations,

- les fonctions de transformation géométrique directe qui permettent d'obtenir le mouvement des quatre bouts de doigts,

- les éléments qui vont permettre de renseigner le problème d'inversion des modèles cinématiques.
<figure><img src="image_116.png" /></figure>
Bibliographie

[AG 2021] Siemens AG. *Specification of Standard Robot Command Interface to PLCs*, 2021. (Cité en page 105.)

[Al-Jaroodi 2012] Jameela Al-Jaroodi et Nader Mohamed. *Service-Oriented Middleware: A Survey*. Journal of Network and Computer Applications, vol. 35, no. 1, pages 211–220, 2012. (Cité en page 23.)

[Andersen 2015] Thomas Timm Andersen. *Optimizing the Universal Robots ROS Driver*. Rapport technique, Technical University of Denmark, Department of Electrical Engineering, 2015. (Cité en page 17.)

[Ando 2005] N. Ando, T. Suehiro, K. Kitagaki, T. Kotoku et Woo-Keun Yoon. *RT-Component Object Model in RT-Middleware—Distributed Component Middleware for RT (Robot Technology)*. In International Symposium on Computational Intelligence in Robotics and Automation, pages 457–462, Espoo, Finland, 2005. IEEE. (Cité en pages 27 et 31.)

[Arias 2010] Soraya Arias, Florine Boudin, Roger Pissard-Gibollet, Daniel Simon et INRIA Rhone-Alpes. *ORCCAD, Robot Controller Model and Its Support Using Eclipse Modeling Tools*. In CAR 2010 - 5th National Conference on Control Architecture of Robots, Douai, France, 2010. (Cité en page 33.)

[Arkin 1997] Ronald C. Arkin et Tucker Balch. *AuRA : Principles and Practice in Review*. Journal of Experimental & Theoretical Artificial Intelligence, vol. 9, no. 2-3, pages 175–189, 1997. (Cité en page 12.)

[Bakken 2001] D.E. Bakken. *Middleware*. In Encyclopedia of Distributed Computing, J. Urban and P. Dasgupta. Kluwer academic, dodrecht édition, 2001. (Cité en page 20.)

[Bertezene 2022] Sandra Bertezene. *Le jumeau numérique en santé : Apports organisationnels et limites épistémologiques dans un contexte de crise sanitaire*. médecine/sciences, vol. 38, no. 8-9, pages 663–668, 2022. (Cité en page 142.)

[Birrell 1983] Andrew D. Birrell et Bruce Jay Nelson. *Implementing Remote Procedure Calls*. In Proceedings of the Ninth ACM Symposium on Operating Systems Principles - SOSP '83, page 3, Bretton Woods, New Hampshire, United States, 1983. ACM Press. (Cité en page 20.)

[Blank 2005] Doug Blank, Deepak Kumar, Lisa Meeden et Holly Yanco. *The Pyro Toolkit for AI and Robotics*. AI Magazine, 2005. (Cité en page 27.)

[Bolton 2018] Ruth N. Bolton, Janet R. McColl-Kennedy, Lilliemay Cheung, Andrew Gallan, Chiara Orsingher, Lars Witell et Mohamed Zaki. *Customer Experience Challenges : Bringing Together Digital, Physical and Social Realms*. Journal of Service Management, vol. 29, no. 5, pages 776–808, 2018. (Cité en page 144.)

[Briod 2014] Adrien Briod, Przemysław Kornatowski, Jean-Christophe Zufferey et Dario Floreano. *A Collision-resilient Flying Robot*. Journal of Field Robotics, vol. 31, no. 4, pages 496–509, 2014. (Cité en page 8.)

[Briquet-Kerestedjian 2019] Nolwenn Briquet-Kerestedjian. *Impact Detection and Classification for Safe Physical Human-Robot Interaction under Uncertainties*. PhD thesis, Université Paris Saclay, 2019. (Cité en page 6.)
[Brooks 1986] R. Brooks. *A Robust Layered Control System for a Mobile Robot*. IEEE Journal on Robotics and Automation, vol. 2, no. 1, pages 14–23, 1986. (Cité en page 12.)

[Brooks 2005] A. Brooks, T. Kaupp, A. Makarenko, S. Williams et A. Oreback. *Towards Component-Based Robotics*. In IEEE/RSJ International Conference on Intelligent Robots and Systems, pages 163–168, Edmonton, Alta., Canada, 2005. (Cité en page 31.)

[Bruemmer 2006] David J Bruemmer. *The Robot Intelligence Kernel*. In The Twenty-First National Conference on Artificial Intelligence and the Eighteenth Innovative Applications of Artificial Intelligence Conference, Boston, Massachusetts, USA, 2006. (Cité en page 32.)

[Bruyninckx 2001] H. Bruyninckx. *Open Robot Control Software : The OROCOS Project*. In Proceedings ICRA. IEEE International Conference on Robotics and Automation (Cat. No.01CH37164), volume 3, pages 2523–2528, Seoul, South Korea, 2001. (Cité en pages 27, 31 et 37.)

[Bruyninckx 2003] H. Bruyninckx, P. Soetens et B. Koninckx. *The Real-Time Motion Control Core of the Orocos Project*. In IEEE International Conference on Robotics and Automation (Cat. No.03CH37422), pages 2766–2771, Taipei, Taiwan, 2003. (Cité en page 37.)

[Bruyninckx 2023] Herman Bruyninckx. Building blocks for complicated and situational aware robotic and cyber-physical systems. 2023. (Cité en page 61.)

[Calinon 2017] Sylvain Calinon et Dongheui Lee. *Learning Control*. In Ambarish Goswami et Prahlad Vadakkepat, editeurs, Humanoid Robotics : A Reference, pages 1–52. Springer Netherlands, Dordrecht, 2017. (Cité en page 132.)

[Calisi] Daniele Calisi, Andrea Censi, Luca Iocchi et Daniele Nardi. *OpenRDK : A Modular Framework for Robotic Software Development*. In IEEE/RSJ International Conference on Intelligent Robots and Systems, pages 1872–1877, Nice. (Cité en pages 27, 32 et 34.)

[Capra 2001] L. Capra, W. Emmerich et C. Mascolo. *Middleware for Mobile Computing : Awareness vs. Transparency*. In Proceedings Eighth Workshop on Hot Topics in Operating Systems, page 164, Elmau, Germany, 2001. IEEE Comput. Soc. (Cité en page 23.)

[Caputo 2013] Antonio C. Caputo, Pacifico M. Pelagagge et Paolo Salini. *AHP-based Methodology for Selecting Safety Devices of Industrial Machinery*. Safety Science, vol. 53, pages 202–218, 2013. (Cité en page 5.)

[Chacko 2013] Joseph Chacko, Neil Richards, Erin Schnabel et Katherine Tsui. *OBJECT REQUEST BROKER*, 2013. (Cité en page 21.)

[Chen 2018] Ximing Chen, Eunsuk Kang, Shinichi Shiraishi, Victor M. Preciado et Zhihao Jiang. *Digital Behavioral Twins for Safe Connected Cars*. In Proceedings of the 21th ACM/IEEE International Conference on Model Driven Engineering Languages and Systems, pages 144–153, Copenhagen Denmark, 2018. (Cité en page 140.)

[Cheng 2019] Gordon Cheng, Emmanuel Dean-Leon, Florian Bergner, Julio Rogelio Guadarrama Olvera, Quentin Leboutet et Philipp Mittendorfer. *A Comprehensive Realization of Robot Skin : Sensors, Sensing, Control, and Applications*. Proceedings of the IEEE, vol. 107, no. 10, pages 2034–2051, 2019. (Cité en page 10.)

[Chinello 2011] Francesco Chinello, Stefano Scheggi, Fabio Morbidi et Domenico Prattichizzo. *KUKA Control Toolbox*. IEEE Robotics & Automation Magazine, vol. 18, no. 4, pages 69–79, 2011. (Cité en page 17.)
[Chishiro 2009] Hiroyuki Chishiro, Yuji Fujita, Akira Takeda, Yuta Kojima, Kenji Funaoka, Shinpei Kato et Nobuyuki Yamasaki. *Extended RT-Component Framework for RT-Middleware*. In IEEE International Symposium on Object/Component/Service-Oriented Real-Time Distributed Computing, pages 161–168, Tokyo, Japan, 2009. (Cité en page 27.)

[Chitic 2018] Stefan-Gabriel Chitic. *Middleware and Programming Models for Multi-Robot Systems*. PhD thesis, Université de Lyon, Lyon, 2018. (Cité en pages 24, 26, 27, 29, 35 et 36.)

[Claraco 2010] Jose Luis Blanco Claraco. *Development of Scientific Applications with the Mobile Robot Programming Toolkit*. Rapport technique, Machine Perception and Intelligent Robotics Laboratory, University of Malaga, 2010. (Cité en page 33.)

[Company 2021] Shadow Robot Company. *Shadow Teleoperation System*. Technical specification, Shadow Robot Company, 2021. (Cité en page 17.)

[Computing 2012] Twin Oaks Computing. *What Can DDS Do for Android?*. Technical report, Twin Oaks Computing, Inc, 2012. (Cité en page 43.)

[Côté 2007] Carle Côté, Dominic Létourneau, Clément Raïevsky, Yannick Brosseau et François Michaud. *Using MARIE for Mobile Robot Component Development and Integration*. In Davide Brugali, editeur, Software Engineering for Experimental Robotics, volume 30, pages 211–230. Springer Berlin Heidelberg, Berlin, Heidelberg, 2007. (Cité en page 32.)

[Cousins 2010] Steve Cousins, Brian Gerkey, Ken Conley et Willow Garage. *Sharing Software with ROS [ROS Topics]*. IEEE Robotics & Automation Magazine, vol. 17, no. 2, pages 12–14, 2010. (Cité en page 33.)

[de Gier 2015] M R de Gier. *Control of a Robotic Arm : Application to on-Surface 3D-printing*. Master thesis, Delft University of Technology, 2015. (Cité en page 17.)

[De Santis 2008] Agostino De Santis, Bruno Siciliano, Alessandro De Luca et Antonio Bicchi. *An Atlas of Physical Human-Robot Interaction*. Mechanism and Machine Theory, vol. 43, no. 3, pages 253–270, 2008. (Cité en page 10.)

[Deng 2021] Min Deng, Carol C. Menassa et Vineet R. Kamat. *From BIM to Digital Twins : A Systematic Review of the Evolution of Intelligent Building Representations in the AEC-FM Industry*. Journal of Information Technology in Construction, vol. 26, pages 58–83, 2021. (Cité en page 140.)

[El Zaatari 2019] Shirine El Zaatari, Mohamed Marei, Weidong Li et Zahid Usman. *Cobot Programming for Collaborative Industrial Tasks : An Overview*. Robotics and Autonomous Systems, vol. 116, pages 162–180, 2019. (Cité en page 7.)

[Elkady 2012] Ayssam Elkady et Tarek Sobh. *Robotics Middleware : A Comprehensive Literature Survey and Attribute-Based Bibliography*. Journal of Robotics, vol. 2012, pages 1–15, 2012. (Cité en page 26.)

[Endo 2004] Y. Endo, D.C. MacKenzie et R.C. Arkin. *Usability Evaluation of High-Level User Assistance for Robot Mission Specification*. IEEE Transactions on Systems, Man and Cybernetics, Part C (Applications and Reviews), vol. 34, no. 2, pages 168–180, 2004. (Cité en page 31.)

[EPSG 2016] EPSG. *The 5 Major Technologies - 3rd Edition*. Industrial Ethernet Facts - Ethernet Powerlink Standardization Group, 2016. (Cité en pages 47 et 55.)
[Escande 2014] Adrien Escande, Nicolas Mansard et Pierre-Brice Wieber. *Hierarchical Quadratic Programming: Fast Online Humanoid-Robot Motion Generation*. The International Journal of Robotics Research, vol. 33, no. 7, pages 1006-1028, 2014. (Cité en page 132.)

[Fernandez 2006] J.A. Fernandez, C. Galindo et J. Gonzalez. *Integrating Heterogeneous Robotic Software*. In MELECON IEEE Mediterranean Electrotechnical Conference, pages 433-436, Benalmadena, Spain, 2006. (Cité en pages 27 et 32.)

[Ferreau 2007] Hans Joachim Ferreau, Peter Ortner, Peter Langthaler, Luigi del Re et Moritz Diehl. *Predictive Control of a Real-World Diesel Engine Using an Extended Online Active Set Strategy*. Annual Reviews in Control, vol. 31, no. 2, pages 293-301, 2007. (Cité en page 115.)

[Ferreau 2014] Hans Joachim Ferreau, Christian Kirches, Andreas Potschka, Hans Georg Bock et Moritz Diehl. *qpOASES: A Parametric Active-Set Algorithm for Quadratic Programming*. Mathematical Programming Computation, vol. 6, no. 4, pages 327-363, 2014. (Cité en page 115.)

[Ferreau 2017] Hans Joachim Ferreau. *qpOASES User's Manual*, 2017. (Cité en page 115.)

[Fischer 2019] H. Fischer, M. Vulliez, P. Laguillaumie, P. Vulliez et J. P. Gazeau. *RTRobMultiAxisControl: A Framework for Real-Time Multiaxis and Multirobot Control*. IEEE Transactions on Automation Science and Engineering, vol. 16, no. 3, pages 1205-1217, 2019. (Cité en pages 44 et 68.)

[Foundation 2021] OPC Foundation. *OPC UA: Academics Lecture*, 2021. (Cité en pages 53 et 56.)

[Fritsche 2015] Lars Fritsche, Felix Unverzag, Jan Peters et Roberto Calandra. *First-Person Tele-Operation of a Humanoid Robot*. In IEEE-RAS 15th International Conference on Humanoid Robots (Humanoids), pages 997-1002, Seoul, South Korea, 2015. (Cité en page 17.)

[Fryman 2012] Jeff Fryman et Björn Matthias. *Safety of Industrial Robots: From Conventional to Collaborative Applications*. 2012. (Cité en page 6.)

[Fuller 2020] Aidan Fuller, Zhong Fan, Charles Day et Chris Barlow. *Digital Twin: Enabling Technologies, Challenges and Open Research*. IEEE Access, vol. 8, pages 108952-108971, 2020. (Cité en pages 142 et 145.)

[Fuseiller 2019] Guillaume Fuseiller. *Perception et Génération de Trajectoires En Cobotique Dans Des Environnements Dynamiques*. PhD thesis, Université de Limoges, Limoges, 2019. (Cité en page 10.)

[Galluzzo 2010] Thomas Galluzzo et Danny Kent. *The OpenJAUS Approach to Designing and Implementing the New SAE JAUS Standards*. In AUVSI Unmanned Systems Conference, 2010. (Cité en page 33.)

[Garcia 2013] A. Sanchez Garcia, E. Estevez, J. Gomez Ortega et J. Gamez Garcia. *Component-Based Modelling for Generating Robotic Arm Applications Running under OROCOS Middleware*. In IEEE International Conference on Systems, Man, and Cybernetics, pages 3633-3638, Manchester, 2013. (Cité en page 37.)

[Garg 2021] Gaurav Garg, Vladimir Kuts et Gholamreza Anbarjafari. *Digital Twin for FANUC Robots: Industrial Robot Programming and Simulation Using Virtual Reality*. Sustainability, vol. 13, no. 18, page 10336, 2021. (Cité en page 18.)
[Gastebois 2017] Jérémy Gastebois. *Contribution à la commande temps réel des robots marcheurs. Application aux stratégies d'évitement des chutes*. PhD thesis, Université de Poitiers, Poitiers, 2017. (Cité en page 69.)

[Gerkey 2002] B.P. Gerkey et M.J. Mataric. *Sold!: Auction Methods for Multirobot Coordination*. IEEE Transactions on Robotics and Automation, vol. 18, no. 5, pages 758-768, 2002. (Cité en page 46.)

[Glaessgen 2012] Edward Glaessgen et David Stargel. *The Digital Twin Paradigm for Future NASA and U.S. Air Force Vehicles*. In 53rd AIAA/ASME/ASCE/AHS/ASC Structures, Structural Dynamics and Materials Conference; BR&gt;; 20th AIAA/ASME/AHS Adaptive Structures Conference; BR&gt;; 14th AIAA, Honolulu, Hawaii, 2012. American Institute of Aeronautics and Astronautics. (Cité en page 143.)

[GmbH 2018] Siemens Healthcare GmbH. *From Digital Twin to Improved Patient Experience-Case Study*, 2018. (Cité en page 142.)

[Gotha 2011] Nils Gotha, Klaus Bernzen, Wilfried Plaß, Joachim Unfried, Martin Schrott, Roland Schaumburg, Jan Braun, Alfred Möltner, Ryszard Bochniak, Djafar Hadiouche, Juergen Hipp, Harald Buchgeher, Candido Ferrio, Josep Lario, Yoshikazu Tachibana, Klas Hellmann, Jan Kosa, Burkhard Werner, Wolfgang Fien, Willi Gagsteiger, Hilmar Panzer, Edwin Schwellinger, Lutz Augenstein et Heiko Berner. *Function Blocks for Motion Control*. page 141, 2011. (Cité en page 61.)

[Gregorio 2020] Jean-Loup Gregorio. *Contribution à la définition d'un jumeau numérique pour la maîtrise de la qualité géométrique des structures aéronautiques lors de leurs processus d'assemblage*. PhD thesis, Université Paris-Saclay, 2020. (Cité en page 142.)

[Grieves 2014] Michael Grieves. *Digital Twin: Manufacturing Excellence through Virtual Factory Replication*, 2014. (Cité en page 142.)

[Haidegger 2013] Tamás Haidegger, Marcos Barreto, Paulo Gonçalves, Maki K. Habib, Sampath Kumar Veera Ragavan, Howard Li, Alberto Vaccarella, Roberta Perrone et Edson Prestes. *Applied Ontologies and Standards for Service Robots*. Robotics and Autonomous Systems, vol. 61, no. 11, pages 1215-1223, 2013. (Cité en page 5.)

[Harper 2019] K. Eric Harper, Somayeh Malakuti et Christopher Ganz. *Digital Twin Architecture and Standards*. 2019. (Cité en pages 142, 143 et 144.)

[He 2019] Rui He, Guoming Chen, Che Dong, Shufeng Sun et Xiaoyu Shen. *Data-Driven Digital Twin Technology for Optimized Control in Process Systems*. ISA Transactions, vol. 95, pages 221-234, 2019. (Cité en page 142.)

[Heckel 2006] Frederick Heckel, Tim Blakely, Michael Dixon, Chris Wilson et William D Smart. *The WURDE Robotics Middleware and RIDE Multi-Robot Tele-Operation Interface*. In AAAI Mobile Robotics Workshop, 2006. (Cité en page 31.)

[Henning 2004] Michi Henning et Mark Spruiell. *Distributed Programming with Ice*. Rapport technique, ZeroC, Inc, 2004. (Cité en page 39.)

[Henning 2008] Michi Henning. *The Rise and Fall of CORBA*. Communications of the ACM, vol. 51, no. 8, pages 52-57, 2008. (Cité en page 39.)

[Hoffmann 2016] Alwin Hoffmann, Alexander Poeppel, Andreas Schierl et Wolfgang Reif. *Environment-Aware Proximity Detection with Capacitive Sensors for Human-Robot-
*Interaction*. In IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pages 145–150, Daejeon, South Korea, 2016. (Cité en page 10.)

[Hoshi 2006] T. Hoshi et H. Shinoda. *Robot Skin Based on Touch-Area-Sensitive Tactile Element*. In Proceedings IEEE International Conference on Robotics and Automation, 2006. ICRA 2006., pages 3463–3468, Orlando, FL, USA, 2006. (Cité en page 7.)

[Ikuta 2003] Koji Ikuta, Hideki Ishii et Makoto Nokata. *Safety Evaluation Method of Design and Control for Human-Care Robots*. The International Journal of Robotics Research, vol. 22, no. 5, pages 281–297, 2003. (Cité en page 9.)

[Jakel 2011] R. Jakel, P. Meissner, Sven R. Schmidt-Rohr et R. Dillmann. *Distributed Generalization of Learned Planning Models in Robot Programming by Demonstration*. In IEEE/RSJ International Conference on Intelligent Robots and Systems, pages 4633–4638, San Francisco, CA, 2011. (Cité en page 8.)

[Jang 2010] Choulsoo Jang. *OPRoS: A New Component-Based Robot Software Platform*. ETRI Journal, vol. 32, no. 5, pages 646–656, 2010. (Cité en pages 27, 33 et 35.)

[Järvinen 1995] Jari Järvinen et Waldemar Karwowski. *Analysis of Self-Reported Accidents Attributed to Advanced Manufacturing Systems*. International Journal of Human Factors in Manufacturing, vol. 5, no. 3, pages 251–266, 1995. (Cité en page 5.)

[Ji 2007] Meng Ji et Magnus Egerstedt. *Distributed Coordination Control of Multiagent Systems While Preserving Connectedness*. IEEE Transactions on Robotics, vol. 23, no. 4, pages 693–703, 2007. (Cité en page 8.)

[Johns 2008] Kyle Johns et Trevor Taylor. Professional Microsoft robotics developer studio. Wrox Professional Guides. Wiley Pub, Indianapolis, IN, 2008. (Cité en page 32.)

[Joseph 2020] Lucas Joseph, Joshua K. Pickard, Vincent Padois et David Daney. *Online Velocity Constraint Adaptation for Safe and Efficient Human-Robot Workspace Sharing*. In IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pages 11045–11051, Las Vegas, NV, USA, 2020. (Cité en page 138.)

[Kagermann 2013] Henning Kagermann, Wolfgang Wahlster et Johannes Helbig. *Recommendations for Implementing the Strategic Initiative INDUSTRIE 4.0 – Securing the Future of German Manufacturing Industry*. Technical report, 2013. (Cité en pages 50 et 51.)

[Katti 2020] Badarinath Katti. *Ontology-Based Approach to Decentralized Production Control in the Context of Cloud Manufacturing Execution Systems*. PhD thesis, 2020. (Cité en page 53.)

[Kramer 2007] James Kramer et Matthias Scheutz. *Development Environments for Autonomous Mobile Robots: A Survey*. Autonomous Robots, vol. 22, no. 2, pages 101–132, 2007. (Cité en page 26.)

[Kranz 2006] Matthias Kranz, Radu Bogdan Rusu, Alexis Maldonado, Michael Beetz et Albrecht Schmidt. *A Player/Stage System for Context-Aware Intelligent Environments*. In Proceedings of UbiSys, 2006. (Cité en pages 27 et 32.)

[Kröger 2010] Torsten Kröger. On-Line Trajectory Generation in Robotic Systems, volume 58 of Springer Tracts in Advanced Robotics. Springer Berlin Heidelberg, Berlin, Heidelberg, 2010. (Cité en page 89.)
[Kröger 2011] Torsten Kröger. *Opening the Door to New Sensor-Based Robot Applications&#x2014; The Reflexxes Motion Libraries*. In IEEE International Conference on Robotics and Automation, pages 1–4, Shanghai, China, 2011. (Cité en pages 89 et 90.)

[Kruger 2006] Daniel Kruger, Ingo van Lil, Niko Sunderhauf, Robert Baumgartl et Peter Protzel. *Using and Extending the Miro Middleware for Autonomous Mobile Robots*. In Towards Autonomous Robotic Systems (TAROS), Guildford, 2006. (Cité en pages 27 et 32.)

[Kwak 2006] Jun-young Kwak, Ji Young Yoon et R.H. Shinn. *An Intelligent Robot Architecture Based on Robot Mark-up Languages*. In IEEE International Conference on Engineering of Intelligent Systems, pages 1–6, Islamabad, Pakistan, 2006. (Cité en pages 27 et 31.)

[Laconte 2019] Johann Laconte, Christophe Debain, Roland Chapuis, Francois Pomerleau et Romuald Aufrere. *Lambda-Field: A Continuous Counterpart of the Bayesian Occupancy Grid for Risk Assessment*. In IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pages 167–172, Macau, China, 2019. (Cité en page 10.)

[Laconte 2021] Johann Laconte, Elie Randriamiarintsoa, Abderrahim Kasmi, Francois Pomerleau, Roland Chapuis, Christophe Debain et Romuald Aufrere. *Dynamic Lambda-Field: A Counterpart of the Bayesian Occupancy Grid for Risk Assessment in Dynamic Environments*. In IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), pages 4846–4853, Prague, Czech Republic, 2021. (Cité en page 10.)

[Liu 2018] Zheng Liu, Norbert Meyendorf et Nezih Mrad. *The Role of Data Fusion in Predictive Maintenance Using Digital Twin*. In 44TH ANNUAL REVIEW OF PROGRESS IN QUANTITATIVE NONDESTRUCTIVE EVALUATION, VOLUME 37, page 020023, Provo, Utah, USA, 2018. (Cité en page 144.)

[Magnenat 2011] S Magnenat, P Rétornaz, M Bonani, V Longchamp et F Mondada. *ASEBA: A Modular Architecture for Event-Based Control of Complex Robots*. IEEE/ASME Transactions on Mechatronics, vol. 16, no. 2, pages 321–329, 2011. (Cité en page 33.)

[Malakuti 2019] S. Malakuti, J. Schlake, C. Ganz, K. E. Harper et H. Petersen. *Digital Twin: An Enabler for New Business Models*. In VDI Wissensforum GmbH, editeur, Automation 2019, pages 807–820. VDI Verlag, 2019. (Cité en page 145.)

[Maurice 2017] Pauline Maurice, Vincent Padois, Yvan Measson et Philippe Bidaud. *Human-Oriented Design of Collaborative Robots*. International Journal of Industrial Ergonomics, vol. 57, pages 88–102, 2017. (Cité en page 10.)

[Mawson 2019] Victoria Jayne Mawson et Ben Richard Hughes. *The Development of Modelling Tools to Improve Energy Efficiency in Manufacturing Processes and Systems*. Journal of Manufacturing Systems, vol. 51, pages 95–105, 2019. (Cité en page 142.)

[Metta 2006] Giorgio Metta, Paul Fitzpatrick et Lorenzo Natale. *YARP: Yet Another Robot Platform*. International Journal of Advanced Robotic Systems, vol. 3, no. 1, page 8, 2006. (Cité en page 32.)

[Michel 2004] Olivier Michel. *Cyberbotics Ltd. Webots™: Professional Mobile Robot Simulation*. International Journal of Advanced Robotic Systems, vol. 1, no. 1, page 5, 2004. (Cité en page 31.)

[Mizera 2019] Camille Mizera. *Développement d'un préhenseur multi-digital marinisé sensible en efforts dans un contexte de télémanipulation*. PhD thesis, Université de Poitiers, 2019. (Cité en page 151.)
[Mohamed 2008] Nader Mohamed, Jameela Al-Jaroodi et Imad Jawhar. *Middleware for Robotics: A Survey*. In IEEE Conference on Robotics, Automation and Mechatronics, pages 736-742, Chengdu, China, 2008. (Cité en pages 26 et 29.)

[Mohamed 2009] Nader Mohamed, Jameela Al-Jaroodi et Imad Jawhar. *A Review of Middleware for Networked Robots*. 2009. (Cité en pages 26 et 29.)

[Montemerlo 2003] Michael Montemerlo, Nicholas Roy et Sebastian Thrun. *Perspectives on Standardization in Mobile Robot Programming: The Carnegie Mellon Navigation (CAR-MEN) Toolkit*. Proceedings 2003 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS 2003), 2003. (Cité en page 31.)

[Morilhat 2018] Patrick Morilhat. *Digitalization of Nuclear Power Plants at EDF*. In Energiforsk Annual Nuclear Conference, 2018. (Cité en page 141.)

[Mouad 2014] Mehdi Mouad. *Architecture de COntrôle/COmmande dédiée aux systèmes Distributed Autonomes (ACO²DA) : application à une plate-forme multi-véhicules*. PhD thesis, Université Blaise Pascal, Clermont 2, 2014. (Cité en page 13.)

[Murphy 2000] Robin Murphy. Introduction to AI robotics. Intelligent Robotics and Autonomous Agents. MIT Press, Cambridge, Mass, 2000. (Cité en page 11.)

[Nagamachi 1986] Mitsuo Nagamachi. *Human Factors of Industrial Robots and Robot Safety Management in Japan*. Applied Ergonomics, vol. 17, no. 1, pages 9-18, 1986. (Cité en page 5.)

[Nesnas 2006] Issa A.D. Nesnas, Reid Simmons, Daniel Gaines, Clayton Kunz, Antonio Diaz-Calderon, Tara Estlin, Richard Madison, John Guineau, Michael McHenry, I-Hsiang Shu et David Apfelbaum. *CLARAty: Challenges and Steps toward Reusable Robotic Software*. International Journal of Advanced Robotic Systems, vol. 3, no. 1, page 5, 2006. (Cité en page 31.)

[Nicolson 2016] Edward Nicolson et Yaskawa America. *The Quest for a Single Controller*. page 10, 2016. (Cité en page 98.)

[Nof 1999] Shimon Y. Nof, editeur. Handbook of industrial robotics. John Wiley, New York, 2nd ed édition, 1999. (Cité en page 5.)

[Norman 1986] Donald A. Norman et Tim Shallice. *Attention to Action: Willed and Automatic Control of Behavior*. In Richard J. Davidson, Gary E. Schwartz et David Shapiro, editors, Consciousness and Self-Regulation, pages 1-18. Springer US, Boston, MA, 1986. (Cité en page 13.)

[Omarali 2017] Bukeikhan Omarali, Tasbolat Taunyazov, Askhat Bukeyev et Almas Shintemirov. *Real-Time Predictive Control of an UR5 Robotic Arm Through Human Upper Limb Motion Tracking*. In Proceedings of the Companion of the 2017 ACM/IEEE International Conference on Human-Robot Interaction, pages 414-414, Vienna Austria, 2017. ACM. (Cité en page 17.)

[Otani 2018] Kazuya Otani, Karim Bouyarmane et Serena Ivaldi. *Generating Assistive Humanoid Motions for Co-Manipulation Tasks with a Multi-Robot Quadratic Program Controller*. In IEEE International Conference on Robotics and Automation (ICRA), pages 3107-3113, Brisbane, QLD, 2018. (Cité en page 10.)
[Pang 2021] Gaoyang Pang, Geng Yang et Zhibo Pang. *Review of Robot Skin: A Potential Enabler for Safe Collaboration, Immersive Teleoperation, and Affective Interaction of Future Collaborative Robots*. IEEE Transactions on Medical Robotics and Bionics, vol. 3, no. 3, pages 681–700, 2021. (Cité en page 10.)

[Park 2011] Jung-Jun Park, Sami Haddadin, Jae-Bok Song et Alin Albu-Schaffer. *Designing Optimally Safe Robot Surface Properties for Minimizing the Stress Characteristics of Human-Robot Collisions*. In IEEE International Conference on Robotics and Automation, pages 5413–5420, Shanghai, China, 2011. (Cité en page 10.)

[Park 2016] Sungman Park, Yeongtae Jung et Joonbum Bae. *A Tele-Operation Interface with a Motion Capture System and a Haptic Glove*. In 13th International Conference on Ubiquitous Robots and Ambient Intelligence (URAI), pages 544–549, Xian, China, 2016. IEEE. (Cité en page 17.)

[Park 2020] Jaeho Park, Raimarius Delgado et Byoung Wook Choi. *Real-Time Characteristics of ROS 2.0 in Multiagent Robot Systems: An Empirical Study*. IEEE Access, vol. 8, pages 154637–154651, 2020. (Cité en page 45.)

[Parker 1998] L.E. Parker. ALLIANCE: An Architecture for Fault Tolerant Multirobot Cooperation. IEEE Transactions on Robotics and Automation, vol. 14, no. 2, pages 220–240, 1998. (Cité en page 46.)

[Passama 2014] Robin Passama, David Andreu, Didier Crestani et Karen Godary-Dejean. *Architectures de contrôle pour la robotique - Approches et tendances*. Robotique, 2014. (Cité en page 12.)

[PLCopen 2018] PLCopen. *Safety Software, Technical Specification, Version 2.0. Technical Committee 5*, 2018. (Cité en pages 61 et 62.)

[Ponsà Cobas 2020] Sergi Ponsà Cobas. *Strategies for Remote Control and Teleoperation of a UR Robot*. Master thesis, Escola Tècnica Superior d'Enginyeria Industrial de Barcelona, 2020. (Cité en page 17.)

[Pope 1998] Alan Pope. The CORBA reference guide : Understanding the common object request broker architecture. Addison-Wesley, Reading, Mass, 1998. (Cité en pages 21 et 22.)

[Portugal 2021] David Portugal, André G Araújo et Micael S Couceiro. *Improving the Robustness of a Service Robot for Continuous Indoor Monitoring: An Incremental Approach*. International Journal of Advanced Robotic Systems, vol. 18, no. 3, page 172988142110121, 2021. (Cité en page 8.)

[Qi 2018] Qinglin Qi et Fei Tao. *Digital Twin and Big Data Towards Smart Manufacturing and Industry 4.0: 360 Degree Comparison*. IEEE Access, vol. 6, pages 3585–3593, 2018. (Cité en page 142.)

[Qilin 2010] Li Qilin et Zhou Mintian. *The State of the Art in Middleware*. In International Forum on Information Technology and Applications, pages 83–85, Kunming, China, 2010. IEEE. (Cité en page 21.)

[Ramos 1996] C. Ramos. *A Holonic Approach for Task Scheduling in Manufacturing Systems*. In Proceedings of IEEE International Conference on Robotics and Automation, volume 3, pages 2511–2516, Minneapolis, MN, USA, 1996. (Cité en page 46.)
[Ravn 2014] O. Ravn, N. A. Andersen et T. T. Andersen. *UR10 Performance Analysis*. Rapport technique, Technical University of Denmark, Department of Electrical Engineering, 2014. (Cité en page 17.)

[Riccoboni 2022] Jean-Baptiste Riccoboni. *Modélisation dynamique d'arborescence - application à la robotique et à l'étude du mouvement humain*. PhD thesis, Université de Poitiers, Poitiers, 2022. (Cité en page 165.)

[Rodríguez 2016] Enrique Rodríguez, José Luis Blanco, José Luis Torres, José Carlos Moreno, Antonio Giménez et José Luis Guzmán. *A ROS Reactive Navigation System for Ground Vehicles Based on Tp-Space Transformations*. In Actas de Las XXXVII Jornadas de Automática 7, 8 y 9 de Septiembre de 2016, Madrid, pages 1213-1220. Universidade da Coruña, Servizo de Publicacións, 2016. (Cité en page 33.)

[Russell 2010] Stuart J. Russell, Peter Norvig et Ernest Davis. Artificial intelligence : A modern approach. Prentice Hall Series in Artificial Intelligence. Prentice Hall, Upper Saddle River, 3rd ed édition, 2010. (Cité en page 12.)

[Sandholm 1993] Tuomas Sandholm. *An Implementation of the Contract Net Protocol Based on Marginal Cost Calculations*. In AAAI Conference on Artificial Intelligence, 1993. (Cité en page 46.)

[Sanfilippo 2015] Filippo Sanfilippo, Lars Ivar Hatledal, Houxiang Zhang, Massimiliano Fago et Kristin Y. Pettersen. *Controlling Kuka Industrial Robots : Flexible Communication Interface JOpenShowVar*. IEEE Robotics & Automation Magazine, vol. 22, no. 4, pages 96-109, 2015. (Cité en page 18.)

[Schlegel 2012] Christian Schlegel, Andreas Steck et Alex Lotz. *Robotic Software Systems : From Code-Driven to Model-Driven Software Development*. In Ashish Dutta, editeur, Robotic Systems - Applications, Control and Programming. InTech, 2012. (Cité en page 32.)

[Schmidt 2005] M.-T. Schmidt, B. Hutchison, P. Lambros et R. Phippen. *The Enterprise Service Bus : Making Service-Oriented Architecture Real*. IBM Systems Journal, vol. 44, no. 4, pages 781-797, 2005. (Cité en page 24.)

[Schopfer 2010] Matthias Schopfer, Florian Schmidt, Michael Pardowitz et Helge Ritter. *Open Source Real-Time Control Software for the Kuka Light Weight Robot*. In 8th World Congress on Intelligent Control and Automation, pages 444-449, Jinan, China, 2010. (Cité en page 18.)

[Siciliano 2008] Bruno Siciliano et Oussama Khatib. Springer handbook of robotics. Springer, Berlin, 2008. (Cité en page 11.)

[Soe 2017] Ralf-Martin Soe. *FINEST Twins : Platform for Cross-Border Smart City Solutions*. In Proceedings of the 18th Annual International Conference on Digital Government Research, pages 352-357, Staten Island NY USA, 2017. ACM. (Cité en page 140.)

[Stark 2019] Rainer Stark et Thomas Damerau. *Digital Twin*. In The International Academy for Production Engineering, Sami Chatti et Tullio Tolio, editeurs, CIRP Encyclopedia of Production Engineering, pages 1-8. Springer Berlin Heidelberg, Berlin, Heidelberg, 2019. (Cité en page 144.)

[Syntec-Ingénierie 2021] Syntec-Ingénierie. *Le jumeau numérique au service du changement climatique*, 2021. (Cité en pages 145 et 146.)
[Wieczorek 2020] F.H. Wieczorek et J. Zhang. *Universal Teleoperation ROS Interface for Robotic Manipulators*. Rapport technique Bachelor thesis, Universität Hamburg Fakultät für Mathematik, Informatik und Naturwissenschaften and Universität Hamburg Fachbereich Informatik, 2020. (Cité en page 17.)

[Yadav 2021] Vaibhav Yadav, Vivek Agarwal, Andrei V. Gribok, Ross D. Hays, Adam J. Pluth, Christopher S. Ritter et Hongbin Zhang. *Technical Challenges and Gaps in Digital-Twin-Enabling Technologies for Nuclear Reactor Applications*. Letter Report U.S. Nuclear Regulatory Commission TLR/RES-DE-REB-2021-17, Idaho National Laboratory, 2021. (Cité en page 141.)

[Yim 2007] Mark Yim, Wei-min Shen, Behnam Salemi, Daniela Rus, Mark Moll, Hod Lipson, Eric Klavins et Gregory Chirikjian. *Modular Self-Reconfigurable Robot Systems [Grand Challenges of Robotics]*. IEEE Robotics & Automation Magazine, vol. 14, no. 1, pages 43–52, 2007. (Cité en page 8.)

[Yu 2022] Wei Yu, Panos Patros, Brent Young, Elsa Klinac et Timothy Gordon Walmsley. *Energy Digital Twin Technology for Industrial Energy Management: Classification, Challenges and Future*. Renewable and Sustainable Energy Reviews, vol. 161, page 112407, 2022. (Cité en page 141.)

[Zhang 2010] W. J. Zhang et Y. Lin. *On the Principle of Design of Resilient Systems – Application to Enterprise Information Systems*. Enterprise Information Systems, vol. 4, no. 2, pages 99–110, 2010. (Cité en page 9.)

[Zhang 2017] Tan Zhang, Wenjun Zhang et Madan Gupta. *Resilient Robots: Concept, Review, and Future Directions*. Robotics, vol. 6, no. 4, page 22, 2017. (Cité en page 8.)
Résumé

La conception de machines de production doit répondre à de nouvelles exigences : intégration
dans un système d’information étendu, capacité d’adaptation et de prise de décision décentralisée
et virtualisation. Le logiciel de pilotage des machines devenant de plus en plus complexe, de
nombreux intergiciels ont été conçus pour en simplifier le développement. La première partie de
ce mémoire présente les principaux intergiciels orientés robotique et en identifie les limites. Dans
le cas de la conception de systèmes mécatroniques qui doivent réagir rapidement et de façon
robuste à des perturbations de leur environnement, nous avons développé une solution logicielle
générique de contrôle multiaxe basée sur les caractéristiques suivantes :

— respect des standards IEC 61131 et PLCopen Motion Control,

— usage des protocoles de communication Ethernet temps réel,

— implémentation possible sur une variété de plateformes (PC, PLC, microcontrôleurs),

— architecture avec une distribution modulable des composants logiciels et des boucles de contrôle de bas niveau associées en fonction des ressources matérielles disponibles,

— intégration au plus bas niveau d’algorithmes de programmation quadratique,

— lien haute-fidélité entre machine réelle et machine virtuelle exploitant une simulation intégrée.

Le mémoire présente la démarche suivie pour concevoir de façon générique des logiciels de contrôle de mécanismes et de robots et illustre cette approche avec le développement logiciel d'un préhenseur multidigital sous-actionné et la création de jumeaux numériques connectés.

Mots clés : contrôle-commande multiaxe, middleware robotique, automates program-
mables industriels, développement logiciel, jumeau numérique
# Software development for reactive multi-axis control : from low-level control to connected digital twin

## Abstract

The design of manufacturing machines must meet new requirements : integration into an extended information system, adaptability, decentralized decision-making, and virtualization. As the control software for machines becomes increasingly complex, numerous middleware solutions have been designed to simplify their development. The first part of this thesis presents the main robotics-oriented middleware solutions and identifies their limitations. In the case of designing mechatronic systems that need to react quickly and robustly to disturbances in their environment, we have developed a generic software solution for multi-axis control based on the following characteristics :

- Compliance with IEC 61131 and PLCopen Motion Control standards

- Use of real-time Ethernet communication protocols

- Possible implementation on a variety of platforms (PC, PLC, microcontrollers)

- Architecture with modular distribution of software components and associated low-level control loops based on available hardware resources

- Integration of quadratic programming algorithms at the lowest level

- High-fidelity link between the real machine and a virtual machine exploiting integrated simulation.

The thesis presents how to generically design control software for mechanisms and robots and illustrates this approach with the software development of an underactuated multidigital gripper and the creation of connected digital twins.

**Keywords :** Multi-axis control, Robotic middleware, Programmable logical controllers (PLCs), Software development, Digital twin