Chapitre 04
MDH & autres paramétrisations

1. Pourquoi d'autres conventions ?

Au chapitre 3, nous avons paramétré la chaîne cinématique avec la convention de Denavit-Hartenberg classique (dite distale : le repère i est attaché à l'extrémité distale — côté effecteur — de la liaison i). Quatre paramètres par liaison — θ_i, d_i, a_i, α_i — et la transformation ^i-1T_i = Rot_z(θ_i)·Trans_z(d_i)·Trans_x(a_i)·Rot_x(α_i). C'est minimal (4 paramètres au lieu de 6) et universellement tabulé par les constructeurs. Alors pourquoi aller plus loin ?

Deux limites structurelles apparaissent dès qu'on sort de l'enseignement :

• La convention DH n'est pas unique. Le placement des repères laisse des degrés de liberté (sens de z_i, choix de l'origine quand les axes se coupent…). Deux ingénieurs peuvent produire deux tables DH différentes pour le même robot. Pour de la documentation, c'est gênant ; pour de la calibration automatique, c'est un piège.
• Elle se comporte mal sur des axes parallèles. Quand deux axes consécutifs sont (nominalement) parallèles, la perpendiculaire commune qui définit a_i n'est plus déterminée de façon unique : une infime erreur d'orientation fait « sauter » le paramètre d de façon discontinue. Le modèle devient mal conditionné — un cauchemar pour l'identification numérique.

Ces deux défauts ont motivé plusieurs paramétrisations alternatives : la DH modifiée de Craig (autre placement des repères, très répandue en calibration), le paramètre de Hayati (qui répare spécifiquement le cas des axes parallèles), le produit d'exponentielles (géométrique, sans singularité), et le format URDF de ROS (arborescent, issu de la CAO). Ce chapitre les présente et vous aide à choisir.

2. La DH modifiée (MDH, convention de Craig)

La convention DH modifiée — popularisée par John J. Craig dans son Introduction to Robotics — utilise les mêmes quatre paramètres (θ, d, a, α) mais les place différemment. C'est la source d'innombrables confusions : une table DH « brute » est inexploitable si l'on ignore de quelle convention elle relève.

2.1 Placement du repère : proximal au lieu de distal

Différence fondamentale : en MDH, le repère R_i est attaché à l'extrémité proximale de la liaison i (côté base), c'est-à-dire sur l'axe de la liaison i elle-même. En DH classique, il était sur l'axe de la liaison i+1 (extrémité distale). Conséquence directe sur l'indexation : les paramètres géométriques du segment portent désormais l'indice i-1.

• α_i-1 : angle entre z_i-1 et z_i, mesuré autour de x_i-1 ;
• a_i-1 : distance entre z_i-1 et z_i, le long de x_i-1 ;
• θ_i : angle entre x_i-1 et x_i, autour de z_i (variable si liaison rotoïde) ;
• d_i : distance le long de z_i (variable si liaison prismatique).

2.2 Ordre du produit

Parce que le repère est placé « en amont », l'ordre des quatre transformations élémentaires est inversé et regroupé différemment de la DH classique. On commence par la partie indexée i-1 (rotation puis translation en x), puis la partie indexée i (rotation puis translation en z) :

À comparer avec la DH classique : ^i-1T_i = Rot_z(θ_i)·Trans_z(d_i)·Trans_x(a_i)·Rot_x(α_i). Les briques sont les mêmes ; leur ordre et l'indice de a, α diffèrent — d'où une matrice finale de forme distincte.

2.3 La matrice 4×4 MDH explicite

En développant le produit ci-dessus (avec cθ = cos θ_i, sθ = sin θ_i, cα = cos α_i-1, sα = sin α_i-1), on obtient :

Notez la colonne de translation : a_i-1 apparaît « en haut » (sur x), tandis que d_i se projette sur y et z via sα, cα. C'est exactement l'inverse de l'agencement classique — d'où l'importance de ne jamais mélanger les deux formes.

2.4 Tableau comparatif DH classique vs MDH

2.5 La fonction ST

On la construit sur le même modèle que DhTransform du chapitre 3 (mêmes types T_MAT4, passage par VAR_IN_OUT). Ici on passe explicitement les paramètres, la variable articulaire étant supposée déjà ajoutée à theta (rotoïde) ou à d (prismatique) par l'appelant.

// Transformation homogène i-1 -> i selon la convention DH MODIFIÉE (Craig).
//   T := Rot_x(alpha_prev) * Trans_x(a_prev) * Rot_z(theta) * Trans_z(d)
// alpha_prev, a_prev : paramètres géométriques indexés i-1
// theta, d           : incluent déjà l'éventuelle variable articulaire.
FUNCTION MdhTransform : BOOL
VAR_INPUT
    alpha_prev : LREAL;   // rad — alpha_{i-1}
    a_prev     : LREAL;   // m   — a_{i-1}
    theta      : LREAL;   // rad — theta_i (offset + q si rotoïde)
    d          : LREAL;   // m   — d_i    (offset + q si prismatique)
END_VAR
VAR_IN_OUT
    T : T_MAT4;           // résultat
END_VAR
VAR
    ct, st, ca, sa : LREAL;
END_VAR
    ct := COS(theta);
    st := SIN(theta);
    ca := COS(alpha_prev);
    sa := SIN(alpha_prev);

    // Ligne 0
    T[0,0] := ct;        T[0,1] := -st;       T[0,2] := 0.0;   T[0,3] := a_prev;
    // Ligne 1
    T[1,0] := st * ca;   T[1,1] := ct * ca;   T[1,2] := -sa;   T[1,3] := -d * sa;
    // Ligne 2
    T[2,0] := st * sa;   T[2,1] := ct * sa;   T[2,2] := ca;    T[2,3] := d * ca;
    // Ligne 3 (homogène)
    T[3,0] := 0.0;       T[3,1] := 0.0;       T[3,2] := 0.0;   T[3,3] := 1.0;

    MdhTransform := TRUE;
END_FUNCTION

La cinématique directe complète s'obtient ensuite comme au chapitre 3, en chaînant les ^i-1T_i par Mat4Mul : ⁰T_n = ⁰T₁·¹T₂·…·^n-1T_n. Seul le bloc élémentaire change entre DH et MDH ; l'ossature de chaînage est identique.

3. Le paramètre de Hayati (axes parallèles)

La MDH règle l'ambiguïté de placement, mais pas le problème des axes parallèles : c'est un défaut de la famille DH tout entière, quelle que soit sa variante. Le modèle Hayati-Roberson (1983) le corrige en remplaçant le paramètre d, pour les liaisons concernées, par un petit angle de rotation β autour de l'axe y.

Autrement dit, on ajoute un facteur Rot_y(β) et on supprime Trans_z(d) uniquement là où deux axes sont nominalement parallèles.

3.1 Pourquoi ça marche

L'intuition tient en une phrase : on paramètre l'erreur qui peut réellement se produire. Quand deux axes sont parallèles :

• le paramètre d (translation le long de z) n'est pas identifiable : glisser le repère le long de deux axes parallèles ne change rien d'observable sur la pose de l'effecteur. Numériquement, la colonne correspondante du Jacobien d'identification est quasi nulle → matrice mal conditionnée, solution instable.
• en revanche, un petit défaut d'orientation (les axes ne sont jamais exactement parallèles en réalité) est parfaitement observable : il fait diverger les axes et se voit sur la pose. C'est précisément ce que capture β, la petite rotation autour de y.

En troquant un paramètre non identifiable (d) contre un paramètre identifiable (β), le modèle redevient continu et bien conditionné : petit défaut réel ⟶ petite variation de paramètre. C'est le standard de fait pour la calibration de bras à poignet ou à épaule dont les axes sont coplanaires/parallèles.

4. Le produit d'exponentielles (POE, screw theory)

Le produit d'exponentielles (POE) adopte un point de vue radicalement différent, issu de la théorie des torseurs (screw theory, Brockett, Murray-Li-Sastry). Au lieu de placer des repères intermédiaires liaison par liaison, on décrit le mouvement de chaque axe comme un vissage (rotation + translation combinées autour d'une ligne de l'espace), exprimé une fois pour toutes dans la base.

4.1 La formule

où :

• S_i est le torseur (screw axis) de la liaison i, exprimé dans la base à la pose de référence (robot au « repos ») ;
• q_i est la variable articulaire (angle si rotoïde, déplacement si prismatique) ;
• M = ⁰T_n(0) est la pose de l'effecteur au repos (une simple matrice 4×4 constante).

Un torseur est un couple S = (ω ∈ ℝ³, v ∈ ℝ³) : ω est la direction de l'axe (unitaire pour une liaison rotoïde, nul pour une prismatique) et v le moment (v = −ω × p, où p est un point de l'axe). Six nombres au total. On lui associe la matrice [S] ∈ se(3) de l'algèbre de Lie (4×4) :

et e^[S]q est l'exponentielle matricielle de [S]q — une transformation homogène 4×4. Sa partie rotation se calcule par la formule de Rodrigues (pour ω unitaire) :

La partie translation fait intervenir un terme intégral analogue ; on retient surtout que tout se ramène à une matrice 4×4 une fois q connu.

4.2 Avantages et inconvénients

5. URDF / format xyz-rpy (écosystème ROS)

Dans l'écosystème ROS (Robot Operating System), les robots sont décrits en URDF (Unified Robot Description Format), un XML arborescent. Chaque joint relie un repère parent à un repère enfant par :

• un offset fixe (l'élément <origin>) : une translation xyz (3 nombres) et une rotation rpy — roll-pitch-yaw, angles de Cardan (3 nombres) ;
• un axe de mouvement (l'élément <axis>) : la direction de rotation (rotoïde) ou de translation (prismatique).

La transformation parent→enfant vaut donc Trans(xyz)·Rot(rpy)·Mouvement(q), où Rot(rpy) = Rot_z(yaw)·Rot_y(pitch)·Rot_x(roll) (convention ROS). C'est très proche d'une matrice 4×4 : facile à convertir.

On peut convertir une ligne DH en offset xyz-rpy (et réciproquement) : il suffit de développer le produit DH en une matrice 4×4, d'en extraire la translation (xyz) et d'en déduire les angles de Cardan (rpy) par les formules d'extraction usuelles.

6. Tableau comparatif de toutes les paramétrisations

7. Recommandation pratique

Il n'y a pas de « meilleure » convention dans l'absolu — seulement une convention adaptée à votre contexte. Une grille de décision simple :

• Enseignement, code legacy, tables constructeur ⟶ DH classique. C'est ce que tout le monde connaît et ce que fournissent les fabricants.
• Calibration géométrique ⟶ MDH comme ossature, + Hayati partout où des axes sont parallèles. C'est le duo de référence de l'identification.
• Robustesse maximale, recherche, robots atypiques ⟶ POE, sans singularité mais plus lourd.
• Vous travaillez déjà dans ROS ⟶ URDF, pour bénéficier de tout l'outillage (RViz, MoveIt) et de l'export CAO.

Exercices

PROGRAM P_TestMdh
VAR
    T       : T_MAT4;
    ok      : BOOL := TRUE;
    PI      : LREAL := 3.14159265358979;
END_VAR

MdhTransform(alpha_prev := 0.0, a_prev := 0.5,
             theta := PI / 2.0, d := 0.2, T := T);

// Contrôles clés (tolérance sur flottants)
IF ABS(T[0,0] - 0.0)  > 1E-9 THEN ok := FALSE; END_IF
IF ABS(T[0,1] + 1.0)  > 1E-9 THEN ok := FALSE; END_IF   // -sin = -1
IF ABS(T[0,3] - 0.5)  > 1E-9 THEN ok := FALSE; END_IF   // a_prev
IF ABS(T[1,0] - 1.0)  > 1E-9 THEN ok := FALSE; END_IF   // sin = 1
IF ABS(T[2,3] - 0.2)  > 1E-9 THEN ok := FALSE; END_IF   // d * cos(alpha)
// ok = TRUE si la matrice correspond à la prédiction

Récapitulatif