Suivi de trajectoire robot pour comparer deux contrôleurs

L'essentiel à retenir

Une petite simulation de suivi de trajectoire peut servir de banc d’apprentissage à une PME belge de 10 à 50 personnes. Le dépôt NeXTzhao/planning réunit ROS, Gazebo et deux logiques de contrôle : Pure Pursuit suit une trajectoire spline en visant un point situé devant le véhicule simulé, tandis que LQR corrige l’écart latéral par rapport à une trajectoire polynomiale de degré cinq. RViz permet de confronter la trajectoire réelle, en rouge, à la trajectoire planifiée, en vert.

L’intérêt n’est pas de désigner un vainqueur universel. Il est d’apprendre à formuler une comparaison propre : même environnement, observations explicites, écarts documentés et limites assumées. Le dépôt donne du code, des commandes de lancement et des résultats illustrés. Il ne fournit pas une solution robotique prête à intégrer.

Le coût réel se trouve donc moins dans le téléchargement que dans la préparation : environnement ROS Kinetic vieillissant, dépendances Ubuntu et Gazebo, compétences ROS et C++, temps d’exécution, puis interprétation. Utilisez ce projet pour comprendre. Pas pour certifier un choix industriel.

Le problème que ça résout

Quand une entreprise découvre le suivi de trajectoire, les mots arrivent souvent avant les images. Planification. Contrôle latéral. Erreur de suivi. Modèle du véhicule. Fonction de coût. Tout semble tenir dans un schéma jusqu’au moment où le véhicule simulé quitte la ligne attendue.

C’est là que ce dépôt devient utile. Il rend la correction visible.

Vous disposez d’une trajectoire planifiée, d’un véhicule simulé et d’un contrôleur chargé de réduire l’écart pendant le déplacement. Dans RViz, le README indique que le vert représente la trajectoire fournie par le module de planification et que le rouge représente le mouvement réel du véhicule. La comparaison cesse d’être une suite de termes abstraits. Vous voyez deux lignes qui peuvent coïncider, diverger puis se rapprocher.

Pour une PME belge de 10 à 50 personnes, ce support peut répondre à une question précise : comment faire découvrir deux logiques de contrôle à une équipe sans commencer par un prototype physique, une intégration complète ou une promesse de mise en production ?

La réponse tient dans un exercice borné. Vous installez un environnement documenté. Vous lancez chaque démonstration. Vous observez ce que le contrôleur reçoit, ce qu’il produit et la trajectoire qui en résulte. Ensuite seulement, vous comparez.

Cette séquence évite une confusion fréquente entre planifier un chemin et le suivre. Le dépôt mentionne aussi une optimisation A* avec lissage par filtre moyen. Cette partie concerne la construction ou l’amélioration d’une trajectoire. Pure Pursuit et LQR interviennent ensuite sur le suivi. Mettre ces briques dans le même projet aide à poser la bonne frontière : produire une ligne de référence ne suffit pas, encore faut-il commander le véhicule pour qu’il reste proche de cette ligne.

Le problème résolu est donc pédagogique. Relier une trajectoire, un algorithme de contrôle, un mouvement simulé et une erreur observable. Rien de plus. C’est déjà beaucoup.

Ce que c'est concrètement

NeXTzhao/planning est un dépôt principalement écrit en C++. Il a été créé en 2021, n’est pas archivé et son dernier push indiqué par les métadonnées consultées date du 4 septembre 2023. Son README documente un environnement Ubuntu avec ROS Kinetic et Gazebo, une compilation dans un espace de travail catkin, puis des lancements avec roslaunch.

Le premier démonstrateur s’appuie sur Pure Pursuit. Une spline sert à générer la trajectoire. Le contrôleur cherche un point placé plus loin sur cette courbe et oriente le véhicule pour le poursuivre. À mesure que le véhicule avance, le point de visée se déplace lui aussi. Cette mécanique se prête bien à une première lecture, car le lien entre cible, orientation et correction peut être observé dans le mouvement.

Le second démonstrateur utilise LQR pour le suivi latéral d’une trajectoire polynomiale de degré cinq. La logique mobilise un modèle du système, son état et un coût attribué aux écarts et aux corrections. Dans le cadre de ce dépôt, l’intérêt est de voir une autre manière de calculer la commande. On ne se contente plus de poursuivre géométriquement un point situé devant le véhicule. On formule la correction à partir d’un modèle et d’un arbitrage mathématique.

Les trajectoires utilisées par les deux exemples ne sont donc pas identiques. Pure Pursuit suit une spline. LQR travaille avec une trajectoire polynomiale de degré cinq. Cette différence interdit une conclusion paresseuse du type « la courbe rouge est plus proche, donc l’algorithme est meilleur ». Vous n’observez pas seulement deux contrôleurs interchangeables sur une expérience parfaitement identique. Vous observez deux chaînes de démonstration qu’il faut lire avec leur génération de trajectoire, leur configuration et leur contexte.

Voilà précisément le bon apprentissage. Une image de résultat n’est pas un verdict. Avant de comparer deux méthodes, il faut identifier ce qui change en même temps qu’elles.

Gazebo fournit la simulation. ROS orchestre les composants et les lancements. RViz affiche les trajectoires. Le README donne les commandes nécessaires et montre des résultats illustrés pour Pure Pursuit comme pour LQR. Le dépôt constitue ainsi un support d’étude reproductible à condition de reconstruire l’environnement attendu.

Il ne documente ni validation sur un robot industriel réel, ni contraintes de sécurité fonctionnelle, ni comportement face aux capteurs physiques, ni procédure d’intégration dans votre architecture. L’écart entre une simulation qui se lance et un système robotique exploitable reste entier.

Comment s'en servir

Étape 1. Écrire la question avant de lancer la simulation

Commencez par une question que l’expérience peut traiter. Par exemple : quelles différences de logique pouvons-nous expliquer après avoir observé Pure Pursuit et LQR dans les démonstrateurs fournis ?

Évitez une question trop large comme « quel contrôleur faut-il choisir pour notre robot ? ». Le dépôt ne connaît ni votre robot, ni vos contraintes, ni vos capteurs, ni votre environnement d’exploitation. Une simulation pédagogique peut éclairer des concepts. Elle ne peut pas décider à la place d’un cahier des charges.

Définissez aussi le résultat attendu de la séance. Une note de comparaison, un schéma des flux ROS, une liste de paramètres à étudier ou une explication orale par l’équipe suffisent. L’objectif est de produire de la compréhension vérifiable, pas une impression de mouvement réussi.

Étape 2. Isoler un environnement d'essai

Le README demande Ubuntu, ROS Kinetic et Gazebo, puis décrit la création d’un espace de travail catkin et sa compilation. Cet environnement a vieilli. Traitez-le comme un laboratoire isolé, sans le confondre avec votre environnement de production ou avec une base technologique choisie pour un nouveau produit.

Documentez les versions réellement utilisées, les dépendances ajoutées et les adaptations nécessaires pour obtenir une compilation. Si l’installation exige des corrections, consignez-les séparément du code du dépôt. Vous saurez ainsi distinguer le temps consacré à l’algorithme du temps consacré à la remise en route de l’environnement.

N’exécutez pas les commandes machinalement. Lisez ce qu’elles lancent, repérez les paquets concernés et identifiez les sujets ROS publiés dans RViz. Le but n’est pas seulement d’obtenir une animation. Il est de comprendre la chaîne qui la produit.

Étape 3. Rejouer Pure Pursuit sans le modifier

Lancez d’abord le scénario Pure Pursuit tel qu’il est documenté. Observez la trajectoire planifiée en vert et la trajectoire réelle en rouge. Notez les zones où leur écart devient visible, la manière dont le véhicule revient vers la référence et les éventuels comportements difficiles à expliquer.

À ce stade, ne cherchez pas à améliorer le résultat. Cherchez à raconter le mécanisme avec des mots simples : une trajectoire spline est générée, le contrôleur choisit une cible en avant, puis la direction évolue pour poursuivre cette cible mobile.

Une démonstration comprise vaut mieux que cinq paramètres changés au hasard.

Étape 4. Rejouer LQR avec la même discipline

Lancez ensuite le scénario LQR documenté. Repérez la trajectoire polynomiale de degré cinq, le suivi latéral et l’affichage dans RViz. Reconstituez la chaîne entre l’état utilisé par le contrôleur, le calcul de correction et le déplacement observé.

La comparaison doit rester descriptive avant de devenir évaluative. Pure Pursuit et LQR ne reposent pas sur la même logique. Le premier se lit d’abord comme une poursuite géométrique. Le second demande de comprendre le modèle et le coût utilisés pour calculer la commande.

Si votre équipe ne sait pas expliquer ces entrées, ne concluez pas encore sur la sortie. Revenez au code et aux paramètres. Ce détour n’est pas une perte de temps. C’est l’exercice.

Étape 5. Construire une grille de comparaison honnête

Utilisez une grille courte, adaptée à ce que le dépôt permet réellement d’observer. Vous pouvez relever la trajectoire de référence employée, les informations nécessaires au contrôleur, les paramètres exposés, l’écart visuel entre rouge et vert, la lisibilité du code et les difficultés de reproduction.

Séparez trois colonnes : observation, interprétation, question ouverte. « La courbe rouge s’écarte ici » est une observation. « Le réglage paraît trop agressif » est une interprétation à confirmer. « Quel paramètre influence cette correction ? » est une question de travail.

Cette séparation protège la discussion. Elle empêche une capture RViz de devenir une preuve qu’elle n’est pas.

Étape 6. Modifier une seule variable à la fois

Une fois les scénarios compris, choisissez un paramètre accessible et modifiez-le de manière contrôlée. Gardez une trace de la valeur initiale, de la nouvelle valeur et de l’effet observé. Revenez ensuite à l’état de départ avant un autre essai.

Le dépôt ne fournit pas, dans le README, un protocole complet de mesure comparative. Si vous ajoutez des indicateurs, décrivez leur calcul et leur périmètre. Une distance latérale moyenne, un écart maximal ou une stabilité visuelle ne racontent pas la même chose. Ne fusionnez pas ces notions dans une note unique sans justification.

L’expérience gagne en valeur quand elle devient répétable. Même entrée, même configuration, même observation. Sinon, vous comparez surtout des souvenirs.

Étape 7. Fermer l'exercice par une décision limitée

Terminez par une décision proportionnée aux preuves. Vous pouvez décider de poursuivre l’apprentissage de ROS, de reproduire les contrôleurs dans un environnement plus actuel, d’étudier leur formulation mathématique ou de construire un banc de test adapté à votre cas.

Vous ne pouvez pas déduire de cette démonstration qu’un contrôleur est prêt pour votre machine. Il manquerait encore la modélisation de votre système, les contraintes matérielles, les capteurs, les délais, les perturbations, les critères de sécurité et la validation dans votre contexte.

La bonne sortie n’est pas « nous avons choisi LQR » ou « Pure Pursuit suffit ». La bonne sortie est plus sobre : nous savons ce que nous avons observé, ce que nous avons appris et ce qu’il reste à prouver.

Ce que ça coûte vraiment

Le code est accessible. L’expérience, elle, consomme du temps et des compétences.

Premier coût : reconstruire l’environnement. Le README s’appuie sur ROS Kinetic, Gazebo, Ubuntu et catkin. Cette pile correspond à un contexte technique ancien. La faire fonctionner aujourd’hui peut demander un environnement dédié, des dépendances compatibles et une documentation interne des ajustements. Le coût n’est pas prévisible à partir du seul dépôt, car il dépend de votre poste, de votre maîtrise de ROS et des problèmes rencontrés.

Deuxième coût : lire du C++ et comprendre ROS. Lancer les fichiers fournis ne suffit pas pour comparer les contrôleurs. Il faut suivre les paquets, les paramètres, les sujets, les trajectoires générées et la commande calculée. Sans cette lecture, RViz montre un résultat, mais n’explique pas sa cause.

Troisième coût : préparer une comparaison qui ne triche pas. Les démonstrateurs n’utilisent pas la même génération de trajectoire. Toute comparaison sérieuse doit tenir compte de cette différence, fixer ce qui peut l’être et documenter ce qui ne l’est pas. Le temps consacré au protocole évite une conclusion faussement précise.

Quatrième coût : interpréter. Une trajectoire rouge proche d’une trajectoire verte paraît convaincante. Pourtant, une image ou un GIF ne décrit pas à lui seul les conditions initiales, les paramètres, les écarts numériques ni la sensibilité du résultat. Il faut décider quelles observations soutiennent réellement votre objectif d’apprentissage.

Le prix affiché est donc nul. Le coût utile se compte en préparation, compréhension et prudence. C’est moins séduisant qu’un GIF. C’est aussi plus proche du travail réel.

Pour qui ce n'est pas

Ce dépôt n’est pas adapté si vous cherchez un composant robotique prêt à intégrer, accompagné d’une maintenance active documentée, d’une licence explicite et d’un dossier de validation. Il ne répond pas à cette promesse.

Il ne convient pas non plus comme preuve qu’un contrôleur fonctionnera sur un véhicule ou un robot physique. Il ne reproduit pas automatiquement vos capteurs, vos actionneurs, vos latences, vos perturbations ni vos exigences de sécurité.

Passez votre chemin si personne dans l’équipe ne peut consacrer du temps à ROS, au C++ et à l’interprétation des essais. Dans ce cas, l’animation risque de devenir la conclusion. Or elle ne devrait être que le début de la question.

Enfin, n’utilisez pas ce dépôt pour organiser un concours rapide entre Pure Pursuit et LQR. Les deux exemples n’emploient pas exactement la même trajectoire de référence, et le README ne fournit pas de protocole comparatif commun. Le projet est intéressant pour apprendre à comparer. Il n’offre pas la comparaison prête à consommer.

Source : https://github.com/NeXTzhao/planning

FAQ

Quelle différence simple retenir entre Pure Pursuit et LQR ?

Dans cette démonstration, Pure Pursuit suit une trajectoire spline en visant un point placé devant le véhicule. LQR calcule une correction latérale à partir d’un modèle, de l’état du système et d’un coût associé aux écarts et aux commandes. Cette distinction aide à comprendre les deux logiques, sans suffire à désigner la meilleure pour votre cas.

Peut-on comparer directement les courbes affichées dans RViz ?

Vous pouvez les observer, mais une comparaison directe reste limitée. Le vert représente la trajectoire planifiée et le rouge la trajectoire réelle. Les deux démonstrateurs reposent toutefois sur des trajectoires générées différemment. Une proximité visuelle ne constitue donc pas, seule, une évaluation équitable des contrôleurs.

Faut-il connaître ROS avant de commencer ?

Une première découverte est possible en suivant la structure documentée, mais une comparaison sérieuse demande de comprendre l’espace de travail catkin, les paquets, les lancements et les sujets affichés dans RViz. Sans ces bases, vous pourrez voir le véhicule bouger sans savoir précisément pourquoi il se comporte ainsi.

Cette simulation peut-elle servir à choisir un contrôleur pour un robot réel ?

Elle peut nourrir votre compréhension et faire émerger les bonnes questions. Elle ne valide pas un choix pour un robot réel. Ce choix demanderait un modèle adapté, des critères mesurables, les contraintes du matériel, les capteurs, les délais, les perturbations et une démarche de sécurité propre à votre application.

Quel résultat attendre d'une première session ?

Pas un choix industriel. Visez une carte claire des deux chaînes de contrôle, une liste d’observations dans RViz, les différences de logique que votre équipe sait expliquer et les questions qu’un futur banc de test devra mesurer. Une simulation bien utilisée ne ferme pas le débat. Elle le rend enfin précis.

---

Publié le 26 octobre 2026.

Cet article est un outil d'orientation, pas un avis juridique. Pour une analyse adaptée à votre situation, consultez un professionnel qualifié.