Recherche en robotique du laboratoire HCR

Ce billet de blog raconte mon parcours en robotique pendant mes études de premier cycle à la Colorado School of Mines, depuis la découverte de ma passion dans CSCI473, à travers mon projet CS Field Session à l’été 2020, jusqu’à mon travail de recherche au laboratoire Human Centered Robotics (HCR) de février 2021 à septembre 2021.

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. Au 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 réaliser 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 Human Centered Robotics (HCR) de Mines sous la direction du Dr Hao Zhang. J’ai rencontré le Dr Zhang 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.

Cours Human Centered Robotics (CSCI473)

Le cours Human Centered Robotics (CSCI473) de Mines était l’un des rares cours de mon parcours universitaire à avoir eu un impact profond sur moi. Le cours était dispensé 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 réalisée sur mon ordinateur portable HP de 2011, qui était suffisant
• Installation et configuration de ROS et Gazebo
• Parcourir 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 semblait 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 pour 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, et utiliseront une carte d’environnement qui vous est fournie. Les étudiants utiliseront un scanner laser sur le robot pour effectuer la détection et l’apprentissage, où le robot est contrôlé à l’aide de commandes de direction et de vitesse. Les étudiants sont tenus de programmer ce projet en C++ ou Python dans ROS Melodic fonctionnant sous 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, nous avons été instruits 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. Nous avons également reçu un labyrinthe pour que le robot le suive. En somme, l’environnement ressemblait à ceci :

Pour la description complète du projet, consultez 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 défectueuse. De plus, faire fonctionner le code dans le bon environnement est assez difficile et ennuyeux. Cependant, j’ai une vidéo de démonstration que j’ai soumise à la classe, montrant ma solution. Vous pouvez la voir ici :

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

Pour le troisième projet, la description du projet é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 par 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 difficile mais pas aussi ardu que le deuxième projet. L’objectif principal était d’utiliser les données du capteur Kinect V1, du MSR Daily Activity 3D Dataset, et des 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 cours que j’ai suivi 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 et à référencer sur mon CV. C’était aussi le premier cours où je me suis senti dans mon élément, car je n’ai jamais été bon en 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 Human-Centered Robotics (HCR) de Mines.

Session de terrain CS (été 2020)

Durant l’été 2020, entre la fin de CSCI473 et mon intégration au laboratoire HCR, j’ai suivi CSCI370 ou « Ingénierie logicielle avancée » 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 les connaissances acquises en cours à 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 fournissait 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é « Détection en temps réel du glissement des roues et corrections d’erreurs pour une navigation lunaire améliorée ». Comme le nom est long, appelons le projet « Détection du glissement des roues ».

Le problème

Lunar Outpost est une startup 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 roues. Ce n’est pas idéal car le glissement des roues 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 des roues. Mais le problème avec le GPS est qu’il ne fonctionne qu’avec plus de 30+ satellites de navigation qui tournent constamment autour de la Terre en orbite et transmettent des signaux uniques permettant aux ordinateurs de calculer leur position. Or, sur la Lune, il n’existe actuellement aucun GPS. En sachant cela, une autre méthode que le GPS doit être utilisée pour détecter le glissement des roues. 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 nécessitait que nous connaissions 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 puisque je l’avais utilisé dans mon cours Human Centered Robotics (CSCI473) au 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

Dans ce projet, il y avait de nombreux défis. Mais le plus grand défi que nous avons rencontré était de ne pas avoir accès à un robot réel pour les tests. Cela était dû au COVID qui a rendu tout le travail à distance et nous a empêchés de travailler dans les laboratoires/bâtiments de Lunar Outpost. En conséquence, nous avons dû utiliser des simulations.

Also, nous avons consulté des recherches académiques du Laboratoire de navigation WVU pour nous faire une idée de la façon dont le problème de glissement des roues pourrait être résolu pour le cas d’utilisation de Lunar Outpost. Ce qui, pour nous, en tant qu’étudiants de deuxième et troisième année de licence, était plus difficile que prévu.

Un autre défi auquel nous avons été confrontés était la quantité de temps dont nous disposions pour travailler sur ce projet. CSCI370 est un cours d’un mois. Mais le problème lui‑même est un problème massif que de nombreuses entreprises et universitaires tentent de résoudre/perfectionner depuis des décennies. Ainsi, un mois est loin d’être suffisant pour résoudre ce problème. Cependant, malgré tous ces défis, nous avons persévéré et nous nous sommes assurés de livrer.

Conclusion

Après avoir parcouru toutes les recherches et le développement, nous avons déterminé qu’il est presque impossible de simuler correctement la physique lunaire numériquement, donc essayer cet algorithme dans une simulation ne sert à rien et ne produira aucune recherche significative sur la détection du glissement des roues dans l’espace et sur la Lune. Nous avons conclu que mettre en place un environnement de test approprié en utilisant quelque chose comme du sable et du matériel réel, comme un robot Husky, est bien plus important pour ce type de recherche. Nous avons mis à jour le code de détection du glissement des roues pour qu’il fonctionne comme un nœud ROS et il a fonctionné correctement et pourrait être facilement importé dans du matériel réel pour les tests. Ce projet m’a permis de prendre un rôle de leadership, d’éduquer mes pairs sur le développement ROS, et d’acquérir de l’expérience avec Python, ROS et Gazebo tout en abordant un problème complexe que je n’avais jamais rencontré auparavant. Le plus important, c’est que cette expérience a renforcé ma passion pour la robotique et a consolidé mon désir de poursuivre la recherche dans ce domaine, préparant le terrain pour ce qui suivra dans mon parcours en robotique.

Starting At The HCR Lab

Après avoir terminé CSCI473, ma session de terrain en informatique à l’été 2020, et mon semestre d’automne 2020, j’ai décidé de me lancer dans la recherche en robotique. J’ai eu de si bonnes expériences avec CSCI473 et la session de terrain en informatique que j’ai décidé de faire de la recherche pour le HCR Lab. Comme j’avais rencontré le Dr Zhang l’année précédente, j’ai décidé de lui envoyer un courriel pour lui demander s’il y avait des opportunités au laboratoire en janvier 2021. Environ deux semaines plus tard, le Dr Zhang a manifesté son intérêt, m’a présenté des options de recherche, et m’a offert un poste au laboratoire. J’ai alors commencé à travailler pour le laboratoire en février 2021.

Introduction Video

Voici ma vidéo d’introduction que j’ai enregistrée quelques mois après mon arrivée au HCR Lab. Elle a été enregistrée en mai 2021 et couvre la recherche sur laquelle je me suis concentré au HCR Lab pendant l’été 2021 :

My Project

Tout au long de mon temps au HCR Lab, je me suis principalement concentré sur le projet Triton. Le projet Triton est un robot mobile développé par le Laboratoire de robotique centrée sur l’humain à la Colorado School of Mines. C’est un robot terrestre à roues omni triangulaires alimenté par le Jetson Nano de NVIDIA.

Le Triton, en aperçu simple, était composé des pièces suivantes :

• NVIDIA Jetson Nano
• Carte porteuse NVIDIA Seed Studio A205
• Arduino Mega
• Carte micro SD de 64 Go
• Corps imprimé en 3D personnalisé
• 3 roues mecanum
• 1 batterie AR
• Circuits personnalisés pour une distribution d’énergie et un câblage optimisés
• Caméra Intel RealSense D435
• Quelques LED

Il a été conçu, construit et fabriqué entre 2018 et 2020 comme robot à des fins éducatives. Au moment où j’ai rejoint le projet, le Triton était déjà bien établi, et le laboratoire envisageait de créer une nouvelle version. Cependant, le principal problème du Triton était son logiciel. Le Triton pouvait se déplacer, se charger et fonctionner de manière basique mais ne faisait rien d’intelligent. Il manquait même la capacité d’effectuer des mouvements plus avancés.

Pour commencer à résoudre cela, le laboratoire a mis en place une zone où nous pouvions suivre le Triton. Pour ce faire, ils ont créé une zone de 2 m par 2 m avec 8 caméras Optitrack Flex (infrarouge) disposées en forme carrée à environ 6‑7 pieds du sol.

En plus de cette zone, chaque Triton avait trois boules sphériques grises attachées au sommet de son corps.

Avec cette configuration, nous avions effectivement construit notre propre système GPS à petite échelle qui nous permettait d’obtenir les coordonnées exactes en mètres d’un Triton dans notre zone d’intérêt. En utilisant les caméras infrarouges Optitrack et les sphères grises Optitrack disposées en triangle, nous pouvions localiser les coordonnées exactes d’un Triton dans notre zone. Cela nous a permis d’appliquer un système en boucle fermée pour une meilleure précision de déplacement.

Le système Optitrack fournissait des données de position et d’orientation à environ 120 Hz avec une précision sub‑millimétrique lorsqu’il était correctement calibré. Les trois marqueurs réfléchissants de chaque Triton formaient un motif triangulaire unique que le système pouvait suivre comme un corps rigide. Le système de coordonnées était calibré de sorte que (0,0) se trouvait au centre de la zone de suivi, les axes X et Y étant alignés avec la géométrie de la salle. Mais malgré ces données de positionnement précises, le Triton avait encore du mal à se déplacer.

Avec cette configuration, une fonctionnalité principale que nous voulions offrir au Triton était la capacité de se déplacer vers une coordonnée spécifique. L’utilisateur, ou son logiciel, pouvait fournir une coordonnée (x, y) dans sa zone d’intérêt. Le robot devait alors se rendre à cette coordonnée aussi rapidement, précisément et sans à-coups que possible. Lorsque je suis arrivé, cette fonctionnalité existait mais ne fonctionnait pas très bien. Voici une simple animation montrant comment la logique de déplacement originale fonctionnait :

Je n’ai pas enregistré la solution originale en action, alors j’ai créé cette simple animation vous montrant l’ancienne logique de déplacement en action. En sachant cela, quels sont les problèmes de cette méthode ?

1. C’est vraiment lent
2. Cela oblige le robot à occuper beaucoup d’espace simplement pour se rendre à un point spécifique. Cela rendait difficile l’utilisation de cette solution lorsque plusieurs Tritons se déplaçaient simultanément.

Alors pourquoi ce comportement se produisait‑il ? Le problème était que le Triton tournait d’abord, modifiant son alpha, jusqu’à ce qu’il pointe vers le point cible dans une marge d’erreur spécifique. Ensuite il sprintait en avant, et après que son theta se soit écarté du cible d’une certaine quantité, il s’arrêtait et recommençait à tourner jusqu’à ce que l’alpha soit dans la plage acceptable pour l’objectif cible. Puis il sprintait de nouveau et répétait ce processus jusqu’à atteindre le point. De plus, à mesure qu’il se rapprochait du point cible, la vitesse de rotation et de sprint diminuait considérablement pour éviter tout dépassement. Cela entraînait un mouvement non naturel du Triton, une durée infinie pour atteindre le point cible, et nécessitait beaucoup d’espace simplement pour atteindre un point cible. Ainsi, avec tous ces problèmes, et étant donné l’importance cruciale de cette fonctionnalité pour le développement du projet Triton, lorsque j’ai commencé à travailler au HCR Lab, ma première tâche a été de développer des solutions plus efficaces permettant au Triton de mieux naviguer vers un point cible.

En sachant cela, j’ai passé beaucoup de temps à rechercher la meilleure façon d’aborder ce problème. Ironiquement, je suivais un cours intitulé Introduction aux systèmes de contrôle en rétroaction (EENG307) à Mines. Au début de ce cours, nous avons appris le concept de contrôleurs en boucle ouverte et de contrôleurs en boucle fermée. En sachant cela, et après une discussion avec le professeur de ce cours et mon colocataire très doué, il est devenu clair que cet objectif de faire parvenir le Triton à un point cible était un problème de système en boucle fermée.

Après des tests et des recherches approfondis, j’ai développé deux approches distinctes de contrôleur pour les Tritons :

Method 1: Distance-Theta Controller

Cette approche utilisait deux contrôleurs proportionnels séparés fonctionnant simultanément :

• Contrôleur de distance : calculait la distance euclidienne jusqu’à la cible et appliquait un gain proportionnel pour déterminer la vitesse avant/arrière
• Contrôleur de theta : calculait l’erreur angulaire entre l’orientation actuelle du robot et l’orientation désirée vers la cible, appliquant un gain proportionnel séparé pour la vitesse de rotation

L’algorithme calculait continuellement la distance euclidienne jusqu’à la cible et l’erreur angulaire entre l’orientation actuelle du robot et la direction désirée. Deux gains proportionnels séparés étaient appliqués pour générer respectivement les vitesses linéaire et angulaire.

Cela faisait que le Triton tournait naturellement vers l’objectif tout en avançant simultanément, créant des trajectoires courbes fluides. L’avantage clé était que le robot gardait toujours son avant orienté vers la destination, ce qui était crucial pour les applications basées sur la caméra.

Method 2: X-Y Coordinate Controller

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

• Contrôleur X : contrôlait directement le mouvement est‑ouest basé sur l’erreur de la coordonnée X
• Contrôleur Y : 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 indépendamment, 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 traction à 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 général des contrôleurs PID, 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 par rapport à 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 directions X et Y séparément. Par exemple, si le robot doit se déplacer de (0,0) à (2,3), il considère qu’il doit corriger 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 selon 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 des 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 en 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

La mise en œuvre de 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 les convertir 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 manière 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 vacillaient 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érence Multi-Robot : 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 s’empêchaient mutuellement de bouger 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 d’un seul Triton, 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 souhaitait 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 de manière indépendante 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 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 Individuels : 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 de trajectoires 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 de manière indépendante tout en maintenant une 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 chaque robot devait suivre, 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. Les performances étaient impressionnantes, tous les robots conservant leur précision individuelle tout en travaillant ensemble comme une équipe.

Voici une playlist montrant les Tritons en action, du contrôle d’un seul robot à la coordination multi-robots : Playlist Tritons en 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 :

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.

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

Évitement de Collisions : 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 leurs marqueurs sphériques réfléchissants
• Calculer les positions et orientations relatives en utilisant les 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 une chaîne 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 basiques. Le concept était d’accorder plus de poids aux données Optitrack lorsqu’elles étaient disponibles, mais de revenir à la vision en cas de besoin, 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 prometteurs au début et appris beaucoup sur le traitement des capteurs de profondeur, je n’ai pas réussi à rendre le système totalement fiable. Cela est resté 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 du 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 à explorer 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 e‑mails 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 énorme problème. 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 sur moi 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 incluait :

• 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 temps 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
• Techniques de débogage et 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 lycéen à travers le programme de sensibilisation du laboratoire. C’était une excellente opportunité 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 :

• Comment les capteurs fonctionnent 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 publier/souscrire
• Création de nœuds et de services
• Travail avec les fichiers de lancement et les serveurs de paramètres

Travaux pratiques de 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 les 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 LEDs 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 a été aussi éducatif pour moi que pour elle. Il m’a obligé à décomposer les concepts complexes en morceaux digestes et à réfléchir réellement 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 a été 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‑robot 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‑robot, Peng a pu simuler des scénarios d’intersection où plusieurs « véhicules » (Tritons) devaient coordonner leurs mouvements. Le meilleur timing et le 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 de mettre en œuvre 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 ses recherches de localisation simultanée et de cartographie. 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, c’était que ce n’était pas seulement moi qui aidais sa recherche, c’était un véritable partenariat. La compréhension par Peng des aspects théoriques des véhicules autonomes a aidé à orienter 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éboguant des scénarios, discutant de différentes stratégies de contrôle et explorant 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 pratique soutenir la recherche en technologie de véhicules autonomes a été 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é accompli 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 les 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’impression, 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. J’ai dû :

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 pleinement compris avant 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 aucune IA pour suggérer des problèmes potentiels ou aider à interpréter les motifs d’erreur.

Apprendre à partir des premiers principes : Sans la possibilité 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 forcé à bâtir une base solide en programmation concurrente, systèmes de contrôle et vision par ordinateur.

La documentation était cruciale : Puisque je ne pouvais pas compter sur une IA pour expliquer le code plus tard, j’ai dû 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 modernes d’IA 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 profondes 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 quitter

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

L’opportunité chez eBay était importante ; c’était mon premier poste majeur d’ingénierie logicielle, elle m’a offert une expérience industrielle inestimable et un revenu stable. Cependant, essayer de maintenir un travail à plein temps, 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 de laboratoire, il m’a fortement déconseillé de le faire. Son raisonnement était solide : terminer mon diplôme devait être la priorité, et l’expérience industrielle chez eBay serait précieuse pour mon développement de carrière. Il estimait que laisser tomber des cours pour se concentrer sur la recherche, bien que tentant, ne serait peut‑être pas 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 afin de me concentrer sur la finalisation de mon diplôme et mon travail chez eBay. Ce fut l’une des décisions professionnelles les plus dures que j’ai eu à prendre à l’époque.

Même après avoir officiellement quitté 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 de débogage et aidé à résoudre les problèmes à distance. Les liens que j’avais créés et l’investissement que j’avais mis dans le succès du projet n’ont pas simplement disparu parce que je n’étais plus officiellement membre 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 qui 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 reste, ma vraie passion. Il y a quelque chose dans le fait de travailler avec des systèmes physiques, de 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 immédiatement des études supérieures après mon diplôme de premier cycle ? Et si j’avais choisi de privilégier le travail de laboratoire plutôt que l’expérience industrielle ?

Mais je reconnais aussi que chaque chemin a ses compromis. Les compétences que j’ai développées en développement web et en IA ont été extrêmement précieuses. L’expérience industrielle m’a enseigné le génie logiciel à 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 m’ont rendu meilleur ingénieur dans l’ensemble.

Le travail que j’ai réalisé au HCR Lab 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 des 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.

Surtout, cette 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 durs qui comptent.

L’impact durable

En repensant à l’expérience du HCR Lab, 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’on travaille 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 de mouvement du robot qui limitait la plateforme
• Construit un système de coordination multi‑robot à 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
• Mentoré plusieurs personnes et aidé au transfert de connaissances
• Soutenu la recherche de niveau doctorat en véhicules autonomes

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

L’avenir et la robotique

Alors que ma carrière m’a 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 enthousiasmé par les avancées en apprentissage robotique et 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é dans le 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 assez merveilleux.