Recherche en robotique du laboratoire HCR

Cet article raconte mon parcours en robotique, depuis la découverte de ma passion pour la robotique dans FRC pendant le lycée en 2015 jusqu’à mon rôle d’assistant de recherche au Human Centered Robotics (HCR) Lab de la Colorado School of Mines de février 2021 à septembre 2021. Notez que depuis fin 2022, le HCR Lab a déménagé de la Colorado School of Mines à l’University of Massachusetts Amherst, ainsi que son site de hcr.mines.edu à hcr.cs.umass.edu.

Contexte

J’ai commencé mes études de premier cycle à la Colorado School of Mines au semestre d’automne 2018. Ma spécialité était l’informatique avec un accent sur la robotique et les systèmes intelligents. Et j’ai obtenu mon diplôme au printemps 2022.

J’ai eu la chance de découvrir ma passion tôt dans ma vie. Pendant le lycée, j’ai passé pas mal de temps à déterminer ce que j’aimais et ce dans quoi je pouvais être bon. Après quelques essais et erreurs, j’ai pu constater que ma passion était l’informatique. Mais c’est aussi à cette époque que j’ai découvert mon amour débordant pour la construction via le code.

À Mines, j’ai eu l’opportunité de travailler au Laboratoire de robotique centrée sur l’humain (HCR) de Mines sous la direction du Dr Hao Zhang. J’ai rencontré le Dr Zhang pour la première fois au printemps 2020 grâce à son cours « Human Centered Robotics » (CSCI473), et après le chaos du COVID et les travaux de cours, j’ai pu travailler dans son laboratoire au début du printemps 2021.

Classe de robotique centrée sur l’humain (CSCI473)

Le cours Human Centered Robotics (CSCI473) de Mines était l’un des rares cours de mon expérience universitaire à avoir eu un impact profond sur moi. Le cours était enseigné par le Dr Hao Zhang. Notre note finale pour le cours était composée de seulement trois projets, chacun présentant un problème difficile qui introduisait les concepts fondamentaux de la robotique. Ces projets comprenaient :

1. Apprentissage du Robot Operating System (ROS)
2. Apprentissage par renforcement pour le suivi de mur par robot
3. Compréhension robotique des comportements humains à l’aide de représentations basées sur le squelette

🧩 Apprentissage du Robot Operating System (ROS)

C’était le premier projet qui nous a été assigné. Le projet comprenait trois tâches :

1. Configurer l’environnement de développement
2. Comprendre le simulateur Gazebo
3. Écrire un ROS “Hello World”

Pour les tâches 1 et 2, nous devions simplement configurer notre environnement de développement et suivre un tutoriel d’introduction à Gazebo. Cela incluait :

• Installation de ROS Melodic, que j’ai faite sur mon ordinateur portable HP de 2011 qui était suffisant
• Installation et configuration de ROS et Gazebo
• Suivre le tutoriel de gazebosim et le tutoriel d’e-manual.

La tâche 3, en revanche, était un vrai défi. La tâche consistait à utiliser turtlesim et à faire dessiner à la tortue le logo « M » de Mines :

Cette tâche, bien qu’elle paraisse simple, était plus difficile qu’elle n’en avait l’air. Ce projet m’a finalement introduit au concept de systèmes en boucle ouverte et en boucle fermée. Vous pouvez en savoir plus sur ce projet et ma solution sur la page du projet ROS Move Turtle.

🧩 Apprentissage par renforcement pour le suivi de mur par robot

C’était le deuxième projet qui nous a été assigné, et c’était l’un des projets les plus difficiles sur lesquels j’ai jamais travaillé à l’université. La description du projet était la suivante :

Dans ce projet, les étudiants concevront et implémenteront des algorithmes d’apprentissage par renforcement afin d’enseigner à un robot mobile autonome à suivre un mur et à éviter de percuter des obstacles. Les étudiants utiliseront la simulation Gazebo dans ROS Melodic pour simuler un robot mobile omnidirectionnel nommé Triton, en utilisant une carte d’environnement qui vous est fournie. Les étudiants utiliseront un scanner laser à bord du robot pour effectuer la détection et l’apprentissage, le robot étant contrôlé à l’aide de commandes de direction et de vitesse. Les étudiants sont tenus de programmer ce projet en C++ ou Python sous ROS Melodic fonctionnant sur Ubuntu 18.04 LTS (c’est‑à‑dire le même environnement de développement utilisé dans le Projet 1). De plus, les étudiants doivent rédiger un rapport suivant le format des conférences IEEE standards en robotique en utilisant LATEX.

Pour l’algorithme d’apprentissage par renforcement, on nous a demandé d’utiliser le Q-Learning. Nous avons également utilisé l’environnement de simulation Gazebo Stingray fourni par le cours. Stingray comprenait le modèle Triton et la logique physique. On nous a également fourni un labyrinthe pour que le robot le suive. Au final, l’environnement ressemblait à ceci :

Pour la description complète du projet, consultez le fichier csci473-p2.pdf. Je n’ai jamais publié ma solution sur GitHub ou le web car elle n’était pas très bonne et très imparfaite. De plus, faire fonctionner le code dans le bon environnement est assez difficile et agaçant. Cependant, j’ai une vidéo de démonstration que j’ai soumise au cours, montrant ma solution. Vous pouvez la visionner ici :

🧩 Compréhension robotique des comportements humains à l’aide de représentations basées sur le squelette

Pour le troisième projet, la description était la suivante :

Dans ce projet, les étudiants implémenteront plusieurs représentations basées sur le squelette (Livrable 1) et utiliseront des Machines à Vecteurs de Support (SVM) (Livrable 2) pour classer les comportements humains à l’aide d’un jeu de données d’activités publiques collectées à partir d’un capteur Kinect V1. De plus, les étudiants doivent rédiger un rapport suivant le format des conférences IEEE standards en robotique en utilisant LATEX dans le Livrable 3.

Ce projet était stimulant mais pas aussi difficile que le deuxième. L’objectif principal était d’utiliser les données du capteur Kinect V1 provenant du MSR Daily Activity 3D Dataset, ainsi que les Machines à Vecteurs de Support pour classer certaines actions/comportements humains. Vous pouvez en savoir plus sur ce projet et ma solution sur la page du projet Predict Human Actions Using LIBSVM.

Conclusion CSCI473

CSCI473 est l’un, voire le meilleur, des cours que j’ai suivis pendant mes études de premier cycle à Mines. Tous ces projets m’ont beaucoup appris et m’ont permis d’avoir un catalogue impressionnant de projets à mettre en avant sur mon CV. C’était aussi le premier cours où je me sentais vraiment à ma place, car je n’ai jamais été bon aux examens mais j’excellais dans la réalisation de projets. C’est également grâce à ce cours que j’ai rencontré le Dr Hao Zhang, qui m’a finalement aidé à obtenir un poste d’assistant de recherche au Laboratoire de robotique centrée sur l’humain (HCR) de Mines.

Session de terrain CS (été 2020)

Pendant l’été 2020, entre la fin de CSCI473 et mon entrée au laboratoire HCR, j’ai suivi le cours CSCI370 ou « Advanced Software Engineering » dans le cadre de mon programme de licence en informatique à la Colorado School of Mines. CSCI370 est un cours qui amène les étudiants à concevoir, implémenter et documenter des solutions logicielles pour une entreprise. Il permet aux étudiants d’appliquer leurs connaissances académiques à des problèmes informatiques du monde réel. Vous pouvez en savoir plus sur le cours ici.

Dans le cours, vous choisissez le projet/entreprise sur lequel vous travaillerez. Le cours fournit des PDF détaillant chaque projet et chaque entreprise. Finalement, j’ai décidé de travailler sur un projet publié par une entreprise appelée Lunar Outpost intitulé « Real Time Wheel Slip Detection and Error Corrections for Enhanced Lunar Navigation ». Comme le nom est long, nous l’appellerons « Détection de glissement de roue ».

Le problème

Lunar Outpost est une start‑up qui tente de créer des rovers lunaires autonomes. Sur la Lune, il y a beaucoup de poussière lunaire connue pour provoquer de nombreux glissements de roue. Ce n’est pas idéal car le glissement de roue peut faire perdre aux systèmes autonomes la trace de leur position réelle. Sur Terre, cela se résout en utilisant les données GPS pour corriger tout décalage causé par le glissement de roue. Mais le problème avec le GPS est qu’il ne fonctionne qu’avec plus de 30 satellites en orbite autour de la Terre transmettant des signaux uniques permettant aux ordinateurs de calculer leur position. Or, sur la Lune, il n’existe actuellement aucun GPS. Sachant cela, une méthode autre que le GPS doit être utilisée pour détecter le glissement de roue. Un rapport plus détaillé du problème du projet peut être consulté ici.

L’équipe

Ce projet n’était pas simple, il a donc dû être réalisé en équipe. L’équipe était composée de cinq étudiants de la Colorado School of Mines :

Ce projet n’était pas simple, il a donc dû être réalisé en équipe. Cette équipe était composée de Mehmet Yilmaz (moi), Kane Bruce, Braedon O’Callaghan, Liam Williams et Kevin Grant.

Le projet nous a obligés à connaître ROS, C++, Python, Linux, Raspberry Pi et Arduino. La plupart d’entre nous avaient de l’expérience dans une ou plusieurs de ces technologies, mais j’étais le seul à avoir de l’expérience avec ROS, car je l’avais utilisé dans mon cours Human Centered Robotics (CSCI473) au semestre du printemps 2020. En raison de cela, dès le début, j’ai aidé tout le monde à se familiariser avec ROS et à développer pour celui‑ci.

Défis

In this project there were a lot of challenges. But the biggest challenge we faced was not having access to a real world robot for testing. This was due to COVID making everything remote and preventing us from working in the Lunar Outpost’s lab/buildings. Due to this, we had to use simulations.

Also, we went through some academic research from the WVU Navigation Lab to get an idea of how the Wheel Slippage problem could get solved for Lunar Outpost’s use case. Which, for us, as undergraduate sophomores and juniors, was more difficult than we expected.

Another challenge we faced was the amount of time we had to work on this project. CSCI370 is a one month class. But the problem itself is a massive problem that many companies and academics have been trying to solve/perfect for decades. So one month is far from enough time to solve this issue. But, despite all these challenges we pushed through and made sure to deliver.

Conclusion

After working through all the research and development, we determined that it is almost impossible to simulate proper moon physics digitally, so really trying this algorithm in a simulation is no good and not going to yield any meaningful research in wheel slippage detection in space and on the moon. We concluded that setting up a proper test environment using something like sand and real hardware, like a Husky robot, is far more important for this type of research. We did update the wheel slippage detection code to work as a ROS node and it functioned properly and could easily be imported into real hardware for testing. This project allowed me to take a leadership role, educate my peers on ROS development, and gain experience with Python, ROS, and Gazebo while tackling a complex problem I had never encountered before. Most importantly, this experience further solidified my passion for robotics and reinforced my desire to pursue research in the field, setting the stage for what would come next in my robotics journey.

Commencer au laboratoire HCR

After completing CSCI473, my CS Field Session in the summer of 2020, and my Fall 2020 semester, I decided to pursue research in robotics. I had such great experiences with both CSCI473 and the CS Field Session that I decided I wanted to do research for the HCR Lab. Since I had met Dr. Zhang the year prior, I decided to email him and ask about any opportunities the lab might have in January 2021. Within about 2 weeks, Dr. Zhang expressed interest, presented me with research options, and offered me a role in the lab. I then started working for the lab in February 2021.

Vidéo d’introduction

Here’s my introduction video that I recorded a few months into my time in the HCR Lab. It was recorded in May 2021 and covers the research I would focus on in the HCR Lab during the summer of 2021:

Mon projet

Throughout my time in the HCR Lab, I mainly focused on the Triton project. The Triton project is a mobile robot developed by the Human Centered Robotics Lab at the Colorado School of Mines. It’s a triangular omni-wheel ground robot powered by NVIDIA’s Jetson Nano.

The Triton, in a simple overview, consisted of the following parts:

• NVIDIA Jetson Nano
• NVIDIA’s Seed Studio A205 Carrier Board
• Arduino Mega
• 64 GB Micro SD Card
• Custom 3D printed body
• 3 mecanum wheels
• 1 AR Battery
• Custom circuits for optimized power distribution and wiring
• Intel’s Realsense D435 Camera
• Some LEDs

It was designed, built, and manufactured around 2018-2020 as a robot for educational purposes. By the time I joined, the Triton was pretty established, and the lab was considering making a new version of it. However, the main issue with the Triton was its software. The Triton could move, charge, and function in a basic sense but did not really do anything intelligent. It even lacked the ability to make more advanced movements.

To start addressing this, the lab set up an area where we could keep track of the Triton. To do this, they created a 2-meter by 2-meter area with 8 Optitrack Flex (Infrared Red) Cameras in a square-like shape about 6-7 feet above the floor.

Along with having this area built, each Triton had three gray sphere balls attached at the top of their bodies.

With this setup, we had effectively built our own small-scale GPS system that allowed us to get the exact coordinates in meters of a Triton in our area of interest. By using the Optitrack infrared cameras and the Optitrack gray spheres in a triangular shape, we could pinpoint the exact coordinates of a Triton in our area. This allowed us to apply a closed-loop system for better accuracy in movement.

The Optitrack system provided position and orientation data at about 120Hz with sub-millimeter accuracy when properly calibrated. Each Triton’s three reflective markers formed a unique triangular pattern that the system could track as a rigid body. The coordinate system was calibrated so that (0,0) was at the center of the tracking area, with X and Y axes aligned to the room’s geometry. But despite this precise positioning data, the Triton still struggled with movement.

With this setup, one core feature we wanted to provide the Triton was the ability to move to a specific coordinate. The user, or their software, could provide a (x, y) coordinate within their area of interest. Then the robot would move to that coordinate as fast, accurately, and seamlessly as possible. When I joined, this feature existed but it wasn’t working very well. Here is a simple animation showing how the original moving logic worked:

I did not record the original solution in action, so I created this simple animation showing you the old moving logic in action. Knowing this, what are the issues with this method?

1. It’s really slow
2. It makes the robot take up a lot of space just to go to a specific point. This made it difficult for us to use this solution when multiple Tritons were moving around.

So why was this behavior happening? The issue was that the Triton first turned, changing its alpha, until it pointed toward the target point within a specific margin of error. Then it would sprint forward, and after its theta was off from the target by a specific amount, it would stop and start turning again until the alpha was within that acceptable range for the target goal. Then it sprints again and keeps doing this until it gets to the point. Also, as it got closer and closer to the goal point, the turning and sprinting speed would get much slower to make sure it didn’t overshoot. This resulted in the Triton having unnatural movement, taking forever to get to a target point, and requiring so much area just to get to a specific target point. So with all of these issues, and given how essential this feature was for the development of the Triton project, when I started working at the HCR Lab, my first task was to develop more effective solutions that would allow the Triton to better navigate to a goal point.

Knowing this, I spent a lot of time doing research on the best possible way of addressing this problem. Ironically, I was taking a class called Introduction to Feedback Control Systems (EENG307) at Mines. Early in that class, we learned about the concept of Open-loop controllers and Closed-loop controllers. Knowing this, and after some discussion I had with the professor of that class and my smart roommate, it became clear that this goal of getting the Triton to a goal point was a closed-loop system problem.

Now, after extensive testing and research, I developed two distinct controller approaches for the Tritons:

Méthode 1 : Contrôleur Distance‑Theta

This approach used two separate proportional controllers running simultaneously:

• Contrôleur de distance: Calculated the Euclidean distance to the target and applied a proportional gain to determine forward/backward velocity
• Contrôleur Theta: Calculated the angular error between the robot’s current heading and the desired heading to the target, applying a separate proportional gain for rotational velocity

The algorithm continuously calculated the Euclidean distance to the target and the angular error between the robot’s current heading and the desired direction. Two separate proportional gains were applied to generate linear and angular velocities respectively.

This resulted in the Triton naturally turning toward the goal while simultaneously moving forward, creating smooth curved paths. The key advantage was that the robot always kept its front face oriented toward the destination, which was crucial for camera-based applications.

Méthode 2 : Contrôleur de coordonnées X‑Y

Cette approche traitait le robot comme un traceur 2D, avec un contrôle indépendant des mouvements X et Y :

• X Controller : Contrôlait directement le mouvement est‑ouest basé sur l’erreur de la coordonnée X
• Y Controller : Contrôlait directement le mouvement nord‑sud basé sur l’erreur de la coordonnée Y

L’implémentation calculait les erreurs de coordonnées X et Y de manière indépendante, appliquait des gains proportionnels séparés, puis transformait ces composantes de vitesse globales dans le cadre de coordonnées local du robot à l’aide de matrices de rotation. Cette transformation était nécessaire parce que le système de transmission à roues omni du robot nécessitait des vitesses dans son propre référentiel, et non dans des coordonnées globales. Cette méthode produisait les trajectoires les plus directes vers les cibles et était nettement plus rapide, mais l’orientation du robot dérivait puisqu’il n’y avait aucun contrôle explicite de l’orientation.

Pour la méthode #1, j’ai détaillé complètement cette méthode dans mon blog Move Turtle (TurtleSim). Je recommande vivement de lire ce blog pour obtenir tous les détails sur le fonctionnement des contrôleurs PID en général, ainsi que sur le fonctionnement de la méthode #1. J’ai développé la méthode #1 en utilisant TurtleSim de ROS, puis j’ai transféré ce code vers le Triton et l’ai mis à jour pour tenir compte d’un environnement plus réaliste.

La méthode #2 utilisait une approche assez différente mais tout aussi efficace. Au lieu de penser à l’orientation du robot et à la distance jusqu’à l’objectif, cette méthode traite le mouvement comme un problème de plan de coordonnées. Le contrôleur calcule en continu l’erreur dans les deux directions X et Y séparément. Par exemple, si le robot doit se déplacer de (0,0) à (2,3), il considère cela comme une correction d’une erreur de 2 mètres en X et de 3 mètres en Y. Deux contrôleurs proportionnels fonctionnaient simultanément : l’un ajustait la vitesse du robot dans la direction X en fonction de l’erreur X, tandis que l’autre gérait le mouvement en direction Y en fonction de l’erreur Y. Cela créait un chemin plus direct vers l’objectif, similaire à la façon dont se déplace la tête d’une imprimante 3D, et permettait des mouvements diagonaux fluides. Le robot n’avait pas besoin de tourner explicitement pour faire face à sa cible, ce qui rendait cette méthode particulièrement efficace dans les espaces restreints ou lorsque un positionnement précis est requis.

Les deux méthodes se sont avérées nettement plus rapides et plus fiables que l’approche originale. Pour voir ces nouvelles méthodes en action, consultez la playlist Tritons in Action, qui montre tous les Tritons en action avec les nouvelles méthodes.

Ce qui prenait auparavant 30 à 45 secondes pour un simple déplacement point à point prend maintenant environ 8 à 12 secondes. Plus important encore, le Triton peut désormais naviguer plus efficacement dans des espaces restreints, ce qui s’est avéré utile pour nos scénarios multi‑robots.

Défis de Développement et Débogage

Mettre en œuvre ces contrôleurs n’était pas simple et a impliqué plusieurs défis de débogage importants :

Transformations du Système de Coordonnées : L’un des aspects les plus délicats était d’obtenir correctement les transformations de coordonnées. Le système Optitrack fournissait des données dans son propre cadre de coordonnées, le robot avait son cadre de coordonnées local, et je devais convertir entre eux avec précision. Les premières implémentations faisaient bouger les robots dans les mauvaises directions parce que j’avais confondu les calculs de matrices de rotation.

Monde Réel vs. Comportement Idéal : Le plus grand défi était de prendre en compte les facteurs du monde réel qui n’apparaissent pas dans la théorie du contrôle présentée dans les manuels. Les roues du robot avaient des caractéristiques de friction différentes, les moteurs ne répondaient pas de façon identique, et il y avait toujours une certaine latence dans la chaîne de communication d’Optitrack au logiciel de contrôle puis à l’Arduino du robot. J’ai passé des semaines à ajuster les gains proportionnels et à ajouter des filtres de zone morte pour tenir compte de ces réalités physiques.

Oscillations et Problèmes de Stabilité : Mes premières implémentations souffraient de problèmes d’oscillation où les robots dépassaient leurs cibles et oscillaient d’avant en arrière. Cela m’a enseigné l’importance des termes dérivés dans les contrôleurs PID et la nécessité d’un réglage adéquat des gains. J’ai finalement opté pour un contrôle principalement proportionnel avec des gains soigneusement réglés plutôt que le PID complet, car l’amortissement inhérent du système était suffisant pour la plupart des applications.

Interférences Multi‑Robots : Lorsque plusieurs robots fonctionnaient simultanément, j’ai découvert des schémas d’interférence inattendus. Les robots se « battaient » parfois pour le même espace ou créaient des situations de blocage où ils se bloquaient mutuellement indéfiniment. Cela m’a conduit à implémenter des mécanismes de coordination et des algorithmes d’évitement de collisions.

Système de Contrôle Multi‑Triton

Une fois que j’avais résolu le problème de déplacement du Triton unique, le prochain défi du laboratoire était de faire fonctionner plusieurs Tritons ensemble simultanément. Cela est devenu l’un de mes principaux axes de travail et a fini par constituer une contribution importante au projet.

Le système original ne pouvait contrôler qu’un seul Triton à la fois, ce qui limitait fortement les possibilités de recherche. Le laboratoire voulait simuler des scénarios où plusieurs véhicules autonomes devaient coordonner leurs mouvements, comme des voitures autonomes communiquant entre elles pour optimiser le flux de trafic et créer de meilleures cartes SLAM (Localisation et Cartographie Simultanées).

Pour résoudre cela, j’ai implémenté une approche multiprocessus en utilisant la bibliothèque multiprocessing de Python. Chaque Triton disposait de son propre processus dédié qui pouvait fonctionner indépendamment tout en étant coordonné par un système de contrôle central. Cela permettait à plusieurs Tritons de se déplacer simultanément sans interférer avec les boucles de contrôle des uns et des autres.

Conception de l’Architecture Multi‑Robot

L’architecture du système que j’ai développée comprenait plusieurs composants clés :

Processus Contrôleur Principal : Il servait de coordinateur central, gérant les interactions de l’interface utilisateur, la planification de trajectoires et la coordination de haut niveau entre les robots. Il maintenait l’état global et distribuait les commandes aux processus robot individuels.

Processus Robot Individuel : Chaque Triton disposait de son propre processus Python dédié qui gérait :

• Calculs de contrôle PID en temps réel à ~50 Hz
• Communication avec le matériel du robot (Arduino/Jetson)
• Exécution locale du chemin et évitement d’obstacles
• Rapport d’état au contrôleur principal

Communication par Mémoire Partagée : J’ai utilisé multiprocessing.shared_memory et les objets Queue de Python pour permettre une communication efficace entre les processus. Cela permettait une coordination en temps réel sans le surcoût de la communication réseau.

Mécanismes de Synchronisation : Pour éviter les conflits lorsque plusieurs robots devaient se coordonner (comme éviter les collisions), j’ai implémenté des sémaphores et des verrous qui permettaient aux robots de demander un accès exclusif à certaines zones de l’espace de travail.

Le défi était de garantir que tous les robots puissent faire fonctionner leurs boucles de contrôle indépendamment tout en maintenant la coordination globale. Chaque processus robot exécutait ses propres calculs PID et envoyait les commandes moteur directement au matériel, tandis que le processus principal gérait la coordination de haut niveau comme l’évitement de collisions et la planification de trajectoires.

Le système multi‑Triton a ouvert de toutes nouvelles possibilités de recherche. Nous pouvions désormais simuler :

• Scénarios de communication véhicule‑à‑véhicule
• Planification de trajectoires coordonnées avec évitement d’obstacles
• Comportements de robotique en essaim
• Cartographie SLAM multi‑agent
• Contrôle de formation et comportements de suivi

Voici à quoi ressemblait l’installation du laboratoire avec plusieurs Tritons fonctionnant simultanément :

J’ai également développé une interface conviviale qui permettait aux chercheurs de définir visuellement les trajectoires pour chaque Triton. Vous pouviez littéralement dessiner le chemin que vous vouliez que chaque robot suive, et ils exécutaient ces trajectoires avec une coordination parfaite. Cela était incroyablement utile pour mettre en place des expériences complexes sans devoir coder manuellement chaque mouvement.

Le système pouvait gérer jusqu’à 5 Tritons simultanément, chacun exécutant ses propres contrôleurs PID tout en étant coordonné via le système de contrôle central. La performance était impressionnante, tous les robots conservant leur précision individuelle tout en travaillant ensemble en équipe.

Voici une playlist montrant les Tritons en action, du contrôle d’un seul robot à la coordination multi‑robots : playlist Tritons in Action

Intégration du Capteur de Profondeur et Correction de Coordonnées

Une autre avancée majeure sur laquelle j’ai travaillé impliquait l’utilisation des caméras de profondeur Intel RealSense D435 montées sur chaque Triton. Bien que le système Optitrack nous fournisse des données de positionnement incroyablement précises, je voulais explorer comment les robots pouvaient utiliser leurs capteurs embarqués pour améliorer leur conscience spatiale et corriger les erreurs de coordonnées.

L’idée était que les Tritons puissent utiliser leurs capteurs de profondeur pour détecter d’autres Tritons à proximité et recouper leurs positions. Cela servirait à plusieurs fins :

1. Correction d’Erreur : Si le système Optitrack présentait une dérive de calibration ou une occlusion temporaire, les robots pourraient utiliser la confirmation visuelle des positions des uns et des autres pour maintenir des systèmes de coordonnées précis.

2. SLAM Amélioré : En ayant plusieurs robots avec des capteurs de profondeur travaillant ensemble, nous pourrions créer des cartes de l’environnement beaucoup plus riches avec des points de données redondants.

3. Évitement de collision: La détection de profondeur en temps réel permettrait aux robots de détecter et d’éviter les uns les autres même si le système de contrôle central subissait des retards de communication.

J’ai commencé à expérimenter des algorithmes qui permettraient aux Tritons de :

• Détecter les autres Tritons en utilisant leur forme triangulaire distinctive et les marqueurs sphériques réfléchissants
• Calculer les positions et orientations relatives à l’aide des données de profondeur
• Comparer ces mesures avec les données Optitrack pour identifier les écarts
• Ajuster potentiellement leur système de coordonnées en temps réel pour maintenir la précision

Expériences de vision par ordinateur

J’ai passé beaucoup de temps à expérimenter un pipeline de vision par ordinateur qui fonctionnait en plusieurs étapes :

Traitement des données de profondeur: L’Intel RealSense D435 fournissait à la fois des flux de données RGB et de profondeur. J’ai principalement travaillé avec les données de profondeur, qui étaient présentées sous forme d’un tableau 640x480 de mesures de distance à 30 Hz. Le premier défi était de filtrer ces données de profondeur bruyantes afin d’extraire des informations géométriques significatives.

Tentatives de détection d’objets: J’ai expérimenté des algorithmes de détection à plusieurs étapes. J’ai eu un certain succès à segmenter l’image de profondeur pour identifier les objets au niveau du sol (en filtrant les murs, le plafond, etc.) et à rechercher des objets avec les bonnes caractéristiques de taille, environ une empreinte de 0,3 x 0,3 mètre. J’ai essayé d’utiliser la détection de contours et l’analyse géométrique pour identifier le profil distinctif du Triton, avec des résultats mitigés.

Expériences de reconnaissance de marqueurs: Les trois sphères réfléchissantes sur chaque Triton semblaient être la caractéristique de détection la plus prometteuse. J’ai expérimenté des algorithmes de détection de blobs pour identifier le motif triangulaire caractéristique de trois points lumineux dans l’image de profondeur. J’ai obtenu des résultats prometteurs dans des conditions d’éclairage contrôlées, bien que ce ne soit pas toujours fiable.

Recherche sur la fusion de coordonnées: J’ai étudié des approches pour fusionner les estimations de position basées sur la vision avec les données Optitrack, y compris des implémentations de filtres de Kalman de base. Le concept était de donner plus de poids aux données Optitrack lorsqu’elles étaient disponibles, mais de revenir à la vision si nécessaire, bien que je n’aie pas réussi à faire fonctionner cela complètement avant la fin de mon séjour au laboratoire.

Défis de performance: Faire fonctionner tout ce traitement en temps réel parallèlement aux boucles de contrôle du robot s’est avéré difficile. J’ai expérimenté des approches d’optimisation pour exécuter les algorithmes à environ 10‑15 Hz sans surcharger les capacités de traitement du Jetson Nano.

Malheureusement, j’ai dû quitter le laboratoire avant de pouvoir terminer pleinement ce travail de vision par ordinateur. Bien que j’aie obtenu quelques résultats préliminaires prometteurs et appris beaucoup sur le traitement des capteurs de profondeur, je n’ai pas réussi à rendre le système totalement fiable. Cela restait une direction de recherche intéressante que d’autres pourraient potentiellement développer.

Voici une vidéo de moi testant les algorithmes de vision par ordinateur :

Voici à quoi ressemblait la vue du capteur de profondeur pendant mes expériences :

Bien que je n’aie pas terminé le travail d’intégration du capteur de profondeur, le concept montrait un potentiel pour des applications telles que la simulation de scénarios de voitures autonomes, où les véhicules doivent être conscients les uns des autres sans dépendre uniquement d’infrastructures externes. La direction de recherche que j’ai commencée pourrait potentiellement contribuer aux travaux futurs du laboratoire.

Documentation et préservation des connaissances

L’une de mes contributions les plus importantes au laboratoire HCR, et peut-être celle dont je suis le plus fier, a été d’organiser et de préserver toute la documentation du projet. Lorsque j’ai rejoint le laboratoire, les connaissances du projet Triton étaient dispersées sur plusieurs plateformes et formats. Les informations critiques étaient réparties entre :

• Divers comptes Google Drive appartenant à différents étudiants diplômés
• Anciens courriels enfouis dans les boîtes de réception
• Dossiers Dropbox aléatoires
• Plusieurs dépôts GitHub
• Dépôts GitLab avec une organisation incohérente
• Notes manuscrites que seules certaines personnes pouvaient interpréter

Cette documentation fragmentée était un problème majeur. Les nouveaux étudiants passaient des semaines à essayer de comprendre comment démarrer, et les connaissances précieuses étaient constamment perdues lorsque les personnes obtenaient leur diplôme ou quittaient le laboratoire.

J’ai pris l’initiative de résoudre ce problème de manière systématique. J’ai passé d’innombrables heures à retrouver chaque morceau de documentation, code, vidéo et note lié au projet Triton. J’ai ensuite organisé le tout dans un dépôt GitLab centralisé avec une structure claire et logique.

La documentation centralisée comprenait :

• Guides de construction : Instructions étape par étape pour assembler les Tritons à partir de zéro
• Configuration logicielle : Guides complets pour configurer l’environnement de développement
• Documentation du code : Code bien commenté avec des explications claires
• Spécifications matérielles : Listes détaillées des pièces, schémas de câblage et conceptions de PCB
• Guides de dépannage : Problèmes courants et leurs solutions
• Tutoriels vidéo : J’ai créé et téléchargé des vidéos pédagogiques sur YouTube, incluant des tutoriels détaillés de calibration Optitrack :

J’ai également établi des normes de documentation pour garantir que les contributions futures soient organisées et accessibles. La structure du dépôt que j’ai créée est devenue la base de tout travail ultérieur dans le laboratoire.

Au-delà de l’organisation de la documentation existante, j’ai créé plusieurs guides et tutoriels originaux qui comblaient des lacunes critiques dans la base de connaissances. Ceux-ci comprenaient des instructions détaillées d’installation pour les nouveaux membres du laboratoire, des guides de dépannage complets et des vidéos explicatives de procédures complexes.

L’impact a été immédiat et durable. Les nouveaux étudiants pouvaient se mettre à jour en quelques jours au lieu de semaines. Le dépôt de documentation que j’ai créé est encore utilisé par le laboratoire aujourd’hui, des années après mon départ. Il est devenu la source unique de vérité pour le projet Triton et a économisé d’innombrables heures/jours pour les futurs chercheurs.

Mentorat et transfert de connaissances

L’un des aspects les plus gratifiants de mon passage au laboratoire HCR a été l’opportunité de mentorer d’autres personnes et de partager les connaissances que j’avais acquises. Au fur et à mesure que mon travail avançait et que je devenais plus expérimenté avec les systèmes Triton, j’ai assumé une responsabilité croissante dans la formation des nouveaux membres de l’équipe.

Mentorat des successeurs du laboratoire

Alors que je me préparais à quitter finalement le laboratoire pour me concentrer sur la finalisation de mon diplôme et mon travail chez eBay, je me suis assuré de former en profondeur deux personnes qui prendraient le relais du projet Triton après mon départ. Il ne s’agissait pas seulement de leur montrer comment les choses fonctionnaient, mais de s’assurer qu’ils comprenaient réellement les principes sous-jacents afin de pouvoir continuer à innover.

J’ai passé des semaines à travailler étroitement avec eux, en parcourant :

• Les bases mathématiques des systèmes de contrôle PID
• L’architecture multiprocessus pour coordonner plusieurs robots
• L’intégration du capteur de profondeur et les algorithmes de vision par ordinateur
• Le système de documentation et comment le maintenir
• Les techniques de débogage et les modes de défaillance courants

Le transfert de connaissances a été incroyablement complet. Nous avons traversé ensemble de vraies sessions de débogage, je les ai fait modifier et étendre le code existant, et je me suis assuré qu’ils pouvaient installer de nouveaux Tritons de manière autonome à partir de zéro.

Programme de mentorat au lycée

Peut-être encore plus gratifiant a été mon expérience de mentorat d’un élève de lycée à travers le programme de sensibilisation du laboratoire. Ce fut une excellente occasion d’initier quelqu’un à la robotique, à l’informatique et à la recherche à un stade formatif de son éducation.

J’ai conçu un programme complet qui couvrait :

Fondamentaux de l’informatique :

• Concepts de programmation utilisant Python comme langage principal
• Introduction à la programmation orientée objet
• Compréhension des algorithmes et des structures de données

Concepts de robotique :

• Fonctionnement des capteurs et comment les interfacer
• Contrôle des actionneurs et systèmes moteurs
• Les bases des systèmes autonomes et du contrôle en boucle fermée

ROS (Robot Operating System) :

• Compréhension du système de messagerie publish/subscribe
• Création de nœuds et de services
• Travail avec les fichiers de lancement et les serveurs de paramètres

Travail pratique sur projet :

• Nous avons collaboré à la création d’un service ROS qui contrôlait le système LED sur la tête du Triton
• Elle a appris à écrire du code propre et documenté qui s’intégrait à nos systèmes existants
• Le service de contrôle LED qu’elle a créé est devenu une partie permanente du codebase du Triton

Ce qui rendait ce mentorat particulièrement spécial était de voir sa progression, passant de ne savoir pratiquement rien sur la programmation à contribuer du code significatif à un projet de recherche actif. Elle est passée de la question « Qu’est-ce qu’une variable ? » à déboguer de façon autonome des problèmes de communication ROS et à écrire ses propres implémentations de services.

Le système de contrôle LED qu’elle a développé a permis aux chercheurs de changer facilement les couleurs et les motifs des LED de la tête du Triton via de simples commandes ROS. Cela peut sembler simple, mais cela nécessitait de comprendre l’architecture ROS, l’interface matérielle et les bons modèles de conception logicielle. Sa contribution est encore utilisée dans le laboratoire aujourd’hui.

Le mentorat était aussi éducatif pour moi qu’il l’était pour elle. Il m’a obligé à décomposer des concepts complexes en morceaux digestes et à vraiment réfléchir aux fondamentaux de ce que nous faisions. Enseigner à quelqu’un d’autre m’a rendu meilleur ingénieur et chercheur.

Collaboration avec la recherche de doctorat

L’un des aspects les plus gratifiants professionnellement de mon temps au laboratoire était de travailler en étroite collaboration avec Peng, un doctorant dont la recherche se concentrait sur les algorithmes de voitures autonomes. Les améliorations logicielles que j’avais apportées au système Triton ont aidé à soutenir sa recherche doctorale.

La recherche de Peng nécessitait une coordination multi-robots précise et fiable pour simuler des scénarios de voitures autonomes. Avant mes améliorations du contrôle de mouvement et des systèmes multi-robots, ces expériences étaient beaucoup plus difficiles à réaliser. Les robots étaient plus lents, moins précis et ne pouvaient pas travailler ensemble aussi efficacement.

Mes contributions ont aidé la recherche de Peng dans plusieurs domaines :

Études de gestion d’intersection : Avec les contrôleurs PID améliorés et la coordination multi-robots, Peng pouvait simuler des scénarios d’intersection où plusieurs « véhicules » (Tritons) devaient coordonner leurs mouvements. Un meilleur timing et un meilleur positionnement ont rendu ces études plus réalisables.

Communication véhicule-à-véhicule : Le cadre de multiprocessus que j’ai développé a permis à Peng d’implémenter et de tester des protocoles de communication entre véhicules simulés. Chaque Triton pouvait prendre des décisions tout en restant coordonné avec les autres, similaire à la façon dont les voitures autonomes pourraient devoir fonctionner.

Recherche SLAM et cartographie : Le travail d’intégration du capteur de profondeur a fourni à Peng des données supplémentaires pour sa recherche de localisation et cartographie simultanées. Disposer de plusieurs robots avec des capacités de capteurs coordonnées a permis des expériences de cartographie plus complètes.

Ce qui rendait notre collaboration particulièrement précieuse, ce n’était pas seulement moi aidant sa recherche, c’était un véritable partenariat. La compréhension par Peng des aspects théoriques des véhicules autonomes a aidé à informer mes implémentations pratiques. Ses retours et exigences m’ont poussé à rendre les systèmes plus robustes et capables.

Nous avons passé de nombreuses heures ensemble au laboratoire, à déboguer des scénarios, à discuter de différentes stratégies de contrôle et à explorer ce que la plateforme Triton pouvait accomplir. Peng est devenu à la fois un collègue et un ami, et travailler avec lui m’a beaucoup appris sur le fonctionnement réel de la recherche académique.

Les systèmes que j’ai construits sont devenus une partie utile du travail de thèse de Peng. Voir mes contributions d’ingénierie pratiques soutenir la recherche en technologie de véhicules autonomes était vraiment gratifiant. Cela a renforcé mon intérêt pour la façon dont une ingénierie solide et la recherche peuvent travailler ensemble pour créer des résultats utiles.

Même après avoir quitté le laboratoire, Peng et moi sommes restés en contact. Savoir que mon travail continuait à contribuer à une recherche importante même après mon départ était extrêmement gratifiant.

Perspective : L’ère pré-LLM du développement

Il convient de noter que tout ce travail a été réalisé pendant l’ère pré-LLM du développement logiciel. Tout cela s’est déroulé entre 2020 et 2021 (principalement 2021), avant que ChatGPT, Claude, Perplexity ou des outils de développement alimentés par l’IA comme Cursor IDE n’existent.

Chaque ligne de code était écrite à partir de zéro, chaque algorithme était recherché à travers des articles académiques et des manuels, et chaque session de débogage impliquait des méthodes traditionnelles comme les instructions d’affichage, les débogueurs et les tests méthodiques. Lorsque j’étais bloqué sur une transformation de coordonnées ou un problème d’ajustement PID, je ne pouvais pas simplement demander à un assistant IA d’expliquer le concept ou d’aider à déboguer le problème.

Cela rendait le processus de développement nettement plus difficile mais aussi plus éducatif. Je devais :

Rechercher tout manuellement : Comprendre la théorie du contrôle PID signifiait lire des manuels et des articles académiques. Déterminer les transformations de coordonnées nécessitait de travailler les mathématiques à la main. Chaque concept devait être entièrement compris avant l’implémentation.

Déboguer sans assistance IA : Lorsque les robots se déplaçaient dans des directions inattendues ou oscillaient autour des cibles, je devais tracer méthodiquement la logique, ajouter des sorties de débogage et tester les hypothèses une par une. Il n’y avait pas d’IA pour suggérer des problèmes potentiels ou aider à interpréter les modèles d’erreur.

Apprendre à partir des premiers principes : Sans la capacité de demander rapidement « comment implémenter le multiprocessus en Python pour la robotique ? », je devais comprendre profondément les concepts sous-jacents. Cela m’a obligé à construire une base solide en programmation concurrente, systèmes de contrôle et vision par ordinateur.

La documentation était cruciale : Comme je ne pouvais pas compter sur l’IA pour expliquer le code plus tard, je devais rédiger une documentation et des commentaires extrêmement clairs. Cette discipline s’est avérée inestimable lors du transfert de connaissances à d’autres.

En regardant en arrière, bien que les outils d’IA modernes auraient accéléré de nombreux aspects du développement, travailler sans eux m’a obligé à développer des compétences de résolution de problèmes plus approfondies et une compréhension plus complète des systèmes sous-jacents. Il est fascinant de penser à quel point ce projet aurait pu être différent avec les outils de développement d’aujourd’hui.

La décision difficile de partir

Autant j’aimais travailler au laboratoire HCR, à la fin de 2021 j’ai été confronté à une décision difficile que de nombreux étudiants rencontrent : équilibrer plusieurs opportunités et responsabilités. Je travaillais simultanément à temps plein comme ingénieur logiciel chez eBay, je terminais mon diplôme en informatique à Mines, et je contribuais à la recherche au laboratoire HCR.

L’opportunité chez eBay était importante ; c’était mon premier rôle majeur d’ingénierie logicielle, elle m’a offert une expérience industrielle inestimable et m’a fourni un revenu solide. Cependant, essayer de maintenir un travail à temps plein, terminer mon diplôme et contribuer de manière significative à la recherche était tout simplement insoutenable. Il fallait faire des compromis.

Lorsque j’ai abordé le Dr Zhang à propos d’une éventuelle réduction de ma charge de cours pour me concentrer davantage sur le travail au laboratoire, il m’a fortement déconseillé de le faire. Son raisonnement était solide : terminer mon diplôme devrait être la priorité, et l’expérience industrielle chez eBay serait précieuse pour le développement de ma carrière. Il estimait que laisser tomber des cours pour se concentrer sur la recherche, bien que tentant, pourrait ne pas être la meilleure décision à long terme.

Ainsi, en septembre 2021, après environ 8 mois de travail intensif au laboratoire, j’ai pris la décision difficile de me retirer de mon rôle d’assistant de recherche pour me concentrer sur la finalisation de mon diplôme et mon travail chez eBay. Ce fut l’une des décisions professionnelles les plus difficiles que j’ai eu à prendre à l’époque.

Même après avoir quitté officiellement le laboratoire, j’ai continué à fournir du soutien chaque fois que quelqu’un avait besoin d’aide avec les systèmes que j’avais construits. J’ai mis à jour la documentation au besoin, répondu aux questions sur le débogage et aidé à résoudre les problèmes à distance. Les liens que j’avais créés et l’investissement que j’avais dans le succès du projet n’ont pas simplement disparu parce que je ne faisais plus officiellement partie de l’équipe.

Réflexions et retour en arrière

Aujourd’hui, en 2025, quatre ans plus tard, je me retrouve à réfléchir à cette période avec des émotions complexes. Mon parcours professionnel m’a conduit profondément dans le développement web et l’ingénierie IA/ML, des domaines qui ont été incroyablement gratifiants et ont offert d’énormes opportunités de croissance et d’impact.

Pourtant, une partie de moi se demande « et si ». La robotique était, et honnêtement l’est toujours, ma vraie passion. Il y a quelque chose dans le travail avec des systèmes physiques, voir son code se traduire en mouvements et comportements réels, que le développement web et même le travail en IA ne peuvent pas tout à fait reproduire.

Je me demande parfois ce qui aurait pu se passer si j’avais pris une voie différente. Et si j’avais trouvé un moyen de rester dans la recherche en robotique ? Et si j’avais poursuivi des études supérieures immédiatement après avoir terminé mon diplôme de premier cycle ? Et si j’avais choisi de privilégier le travail au laboratoire plutôt que l’expérience industrielle ?

Mais je reconnais aussi que chaque voie a ses compromis. Les compétences que j’ai développées en développement web et en IA ont été incroyablement précieuses. L’expérience industrielle m’a appris l’ingénierie logicielle à grande échelle, la conception d’expérience utilisateur et les défis pratiques de la création de produits utilisés par des millions de personnes. Ces expériences ont fait de moi un meilleur ingénieur dans l’ensemble.

Le travail que j’ai effectué au laboratoire HCR continue d’influencer ma façon d’aborder les problèmes aujourd’hui. La pensée systématique requise pour les systèmes de contrôle PID apparaît dans la façon dont je conçois les boucles de rétroaction dans les systèmes logiciels. Les compétences en documentation et en préservation du savoir que j’ai développées ont été inestimables dans chaque rôle depuis. L’expérience de mentorat et d’enseignement a façonné ma manière de travailler avec les développeurs juniors et de contribuer au partage des connaissances au sein de l’équipe.

Le plus important, c’est que l’expérience m’a appris que je m’épanouis en travaillant sur des problèmes techniques difficiles qui ont un impact réel. Que ce soit en optimisant les algorithmes de mouvement des robots ou en construisant des systèmes d’IA qui aident les utilisateurs à atteindre leurs objectifs, la satisfaction provient de la résolution de problèmes difficiles qui comptent.

L’impact durable

En repensant à l’expérience du laboratoire HCR, je suis frappé par tout ce que j’ai accompli en relativement peu de temps. Les systèmes que j’ai construits ont fondamentalement changé le fonctionnement de la plateforme Triton, et bon nombre de ces améliorations sont encore utilisées aujourd’hui. Le référentiel de documentation que j’ai créé est devenu la base de connaissances pour l’ensemble du projet. Les relations de mentorat que j’ai établies ont eu un impact durable sur les personnes avec qui j’ai travaillé.

Mais peut-être plus significativement, l’expérience m’a montré ce dont je suis capable lorsqu’il s’agit de travailler sur des problèmes qui me passionnent réellement. Au cours de ces huit mois, j’ai :

• Amélioré le système de contrôle du mouvement du robot qui limitait la plateforme
• Construit un système de coordination multi-robots à partir de zéro
• Intégré des capacités de vision par ordinateur et de fusion de capteurs
• Créé un système complet de documentation et de gestion des connaissances
• Encadré plusieurs personnes et aidé au transfert de connaissances
• Soutenu la recherche de niveau doctorat en véhicules autonomes

Il ne s’agissait pas seulement des réalisations techniques, bien que celles-ci aient été significatives pour moi. Il s’agissait d’apprendre qu’avec persévérance et une pensée systématique, on peut apporter des contributions utiles même en tant qu’étudiant de premier cycle.

L’avenir et la robotique

Bien que ma carrière m’ait conduit dans d’autres directions, ma passion pour la robotique n’a pas diminué. Je continue de suivre les développements du domaine, je suis enthousiaste face aux avancées de l’apprentissage robotique et des systèmes autonomes, et je travaille occasionnellement sur des projets robotiques personnels pendant mon temps libre.

Qui sait ce que l’avenir nous réserve ? Les compétences que je développe en IA et en apprentissage automatique sont de plus en plus pertinentes pour la robotique. L’expérience industrielle que j’ai acquise m’a appris à construire des systèmes robustes et évolutifs. Peut-être y aura-t-il un avenir où ces différents fils de mon expérience se rejoindront de manière inattendue.

Pour l’instant, je suis reconnaissant du temps que j’ai passé au laboratoire HCR et des expériences qu’il m’a offertes. Ce fut une période formatrice qui a façonné à la fois mes compétences techniques et ma compréhension des types de travail que je trouve les plus épanouissants. Même si cela me manque parfois, je sais que les leçons que j’ai apprises et les approches que j’ai développées continuent d’influencer tout ce que je fais.

Les robots sont toujours là, toujours au service des chercheurs, toujours en train de permettre un travail important. Et c’est plutôt merveilleux.