Architecture ROS2 reconfigurable avec commande IK à faible latence
Mark3 est une plateforme robotique modulaire qui permet de reconfigurer dynamiquement la structure d'un bras robotique, puis
de piloter son effecteur via une résolution IK à faible latence. La pile combine orchestration de nœuds ROS2,
mise à jour dynamique de la description robot, simulation et ciblage assisté par vision pour des validations sur banc.
Objectif
Concevoir une plateforme robotique modulaire orientée démonstration et R&D, capable d'assembler différents modules d'axes
puis de les commander avec une chaîne logicielle unique, du paramétrage à la visualisation 3D.
Communication: topics pour configuration, positions cibles, angles articulaires et flux caméra; service dédié pour la résolution IK.
Architecture ROS2 distribuée: la commande, la perception et la mise à jour du modèle sont séparées pour garder des sous-systèmes testables et remplaçables.
Design électronique modulaire
Choix techniques
Pourquoi ROS2 ?
ROS2 a été choisi pour la séparation claire des nœuds, la communication distribuée native et l'intégration directe simulation + perception.
Pourquoi cette architecture ?
Le solveur IK en service et la propagation d'état par topics permettent de reconfigurer la chaîne d'axes sans ré-écrire toute la pile de contrôle.
Réactivité du contrôle
La boucle est pensée pour un comportement interactif à faible latence: envoi de cible, résolution IK, publication articulaire, retour visuel.
Détails techniques clés
Type d'IK: solveur de cinématique inverse basé sur le Jacobien, exposé en service ROS2.
Reconfiguration: mise à jour dynamique de la chaîne d'axes avec régénération URDF et rechargement à l'exécution.
Interfaces ROS2: 6 topics principaux + 1 service IK dans la version logicielle actuelle.
Injection vision: les détections YOLO sont projetées en estimation 3D puis réinjectées dans la supervision/commande.
Fonctions déjà validées sur banc : retour maison, conversion cible cartésienne vers angles, reconfiguration dynamique, publication d'états.
Simulation, contrôle et perception
Démonstrations logicielles : reconfiguration d'axes, envoi de cibles cartésiennes, recalcul et application des angles.
Comportements: retour maison, trajectoires lissées et mise à jour de l'état robot en continu.
Contrôle: boucle IHM vers solveur IK puis publication ROS2 vers visualisation et suivi d'états.
Résolution de la cinématique inverse: principe et adaptation
Le problème est formulé comme une minimisation de l'erreur de pose entre la cible cartésienne et la pose courante de l'effecteur:
on cherche un incrément articulaire \( \Delta q \) qui réduit \( e = x_{\text{cible}} - f(q) \). À chaque itération, le solveur
linéarise localement la cinématique directe via la jacobienne \( J(q) \), puis met à jour les articulations avec une pseudo-inverse
(ou une forme amortie quand le problème devient mal conditionné).
\[
\Delta q = J^{+} e
\quad \text{ou} \quad
\Delta q = J^{T}(J J^{T} + \lambda^{2} I)^{-1} e
\]
Modèle variable: lors d'une reconfiguration, la chaîne cinématique est reconstruite (types d'axes, DH, limites), puis la jacobienne est régénérée pour cette nouvelle topologie.
Adaptation automatique: le solveur ne dépend pas d'un robot fixe; il dépend de la description courante du robot, donc la dimension de q, la structure de J et les contraintes changent dynamiquement avec la configuration.
Contraintes: les angles/courses sont projetés dans les bornes articulaires après chaque mise à jour, et la solution est rejetée si l'erreur résiduelle reste hors tolérance.
Critère d'arrêt: convergence sur norme d'erreur, nombre maximal d'itérations, ou stagnation de la réduction d'erreur.
Injection en boucle ROS2: la cible arrive via topic, la résolution passe par /solve_ik, puis les angles sont republiés sur /pos/angles et joint_states pour fermer la boucle de supervision.
Initialisation MLP: une estimation initiale de q plus proche de la solution réduit le nombre d'itérations et le temps de convergence sur une partie des cas tests.
Évaluation IK: avec et sans initialisation MLP
Réduction des itérations
~3x de réduction médiane (1269 -> 419)
L'initialisation MLP fournit un point de départ bien plus proche d'une solution valide qu'une initialisation aléatoire.
Réduction du temps
~4x de réduction médiane (2.0s -> 0.5s)
Le gain dépasse la baisse d'itérations grâce à moins de calculs de jacobienne, moins de surcoût numérique par pas et un coût d'inférence MLP négligeable (~1 ms).
Précision inchangée
5 mm d'erreur médiane (deux méthodes)
L'approche hybride accélère l'initialisation sans dégrader la précision finale garantie par le solveur numérique.
Limites actuelles
Hardware en cours d'intégration: la chaîne logicielle est validée en simulation et sur banc, l'intégration complète physique continue.
Axe de translation: support encore partiel dans l'état actuel de l'implémentation.
Mes contributions
Conception de l'architecture logicielle ROS2 multi-nœuds et des interfaces de communication.
Développement et intégration de la chaîne de commande basée sur le service IK (/solve_ik + topics de cibles).
Mise en place du workflow de description robot dynamique (génération URDF + rechargement après reconfiguration).
Conception de l'architecture électronique modulaire et du design PCB des modules d'actionnement.
Réalisation du design CAO de tous les modules, de la base du robot et des préhenseurs.
Intégration des sorties YOLO dans la pile ROS2 pour la supervision avec localisation 3D.
Développement du workflow de simulation et de validation sur banc des comportements modulaires.
État du projet
Validé aujourd'hui
Architecture ROS2 et flux de communication multi-nœuds
Résolution IK à faible latence et publication d'états
Simulation 3D et intégration perception YOLO
Chaîne d'intégration
Montée en maturité hardware module par module
Convergence mécanique-électronique-logicielle
Validation physique complète sur plateforme intégrée