Mon Chapitre de Recherche en Robotique

Ce post raconte mon parcours en robotique, commençant par la découverte de ma passion pour la robotique dans FRC pendant le lycée en 2015 jusqu’à mon temps en tant qu’assistant de recherche au Colorado School of Mines au Laboratoire de Robotique Centrée sur l’Humain (HCR) de février 2021 à septembre 2021. Notez qu’à partir de fin 2022, le Laboratoire HCR a déménagé du Colorado School of Mines à l’Université du Massachusetts Amherst, ainsi que son site de hcr.mines.edu à hcr.cs.umass.edu.

Contexte

J’ai commencé mes études de premier cycle au 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 trouver ma passion tôt dans ma vie. Pendant le lycée, j’ai passé beaucoup de temps à découvrir ce que j’aimais et ce dans quoi je pouvais exceller. Après quelques essais et erreurs, j’ai pu comprendre que ma passion était l’informatique. Mais c’est aussi à cette époque que j’ai découvert que j’avais un amour écrasant pour la construction à travers 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 lors de son cours “Robotique Centrée sur l’Humain” (CSCI473), et après le chaos du COVID et des cours, j’ai pu travailler dans son laboratoire au début du printemps 2021.

Cours de Robotique Centrée sur l’Humain (CSCI473)

Le cours de Robotique Centrée sur l’Humain (CSCI473) de Mines était l’un des rares cours de mon expérience universitaire qui a 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 des concepts fondamentaux de la robotique. Ces projets consistaient en :

1. Apprentissage du Système d’Exploitation Robotique (ROS)
2. Apprentissage par Renforcement pour le Suivi de Mur par Robot
3. Compréhension des Comportements Humains par le Robot en Utilisant des Représentations Basées sur des Squelettes

Apprentissage du Système d’Exploitation Robotique (ROS)

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

1. Configurer l’Environnement de Développement
2. Comprendre le Simulateur Gazebo
3. Écrire un “Hello World” en ROS

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 :

• Configurer ROS Melodic, que j’ai fait sur mon ordinateur portable HP de 2011 qui était suffisant
• Installer et configurer ROS et Gazebo
• Suivre le tutoriel de gazebosim et le tutoriel de l’e-manuel.

La tâche 3, en revanche, était un véritable 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 à Boucle Ouverte et à Boucle Fermée. Pour la description complète du projet, consultez csci473-p1.pdf ou vous pouvez en apprendre davantage 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 mettront en œuvre des algorithmes d’apprentissage par renforcement pour enseigner à un robot mobile autonome à suivre un mur et à éviter de heurter 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 des mesures et de l’apprentissage, où le robot est contrôlé à l’aide de commandes de direction et de vitesse. Les étudiants doivent programmer ce projet en C++ ou Python dans 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 de robotique IEEE standard en utilisant LATEX.

Pour l’algorithme d’apprentissage par renforcement, nous avons été instruits d’utiliser Q-Learning. Nous avons également utilisé l’environnement de simulation Gazebo Stingray fourni par le cours. Stingray se composait du modèle Triton et de la logique physique. Nous avons également reçu un labyrinthe pour que le robot puisse le suivre. Dans l’ensemble, l’environnement ressemblait à ceci :

Je n’ai jamais publié ma solution sur GitHub ou sur le web car elle n’était pas très bonne et comportait de nombreuses erreurs. 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 visionner ici :

Pour la description complète du projet, consultez csci473-p2.pdf

Compréhension des Comportements Humains par le Robot en Utilisant des Représentations Basées sur des Squelettes

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

Dans ce projet, les étudiants mettront en œuvre plusieurs représentations basées sur des squelettes (Livrable 1) et utiliseront des Machines à Vecteurs de Support (SVM) (Livrable 2) pour classifier les comportements humains en utilisant un ensemble de données d’activité public collecté à partir d’un capteur Kinect V1. De plus, les étudiants doivent rédiger un rapport suivant le format des conférences de robotique IEEE standard en utilisant LATEX dans le Livrable 3.

Ce projet était difficile mais pas aussi difficile que le deuxième projet. L’objectif principal était d’utiliser les données du capteur Kinect V1, provenant de l’Ensemble de Données d’Activité Quotidienne MSR 3D, et des Machines à Vecteurs de Support pour classifier certaines actions/comportements humains. Pour la description complète du projet, consultez csci473-p3.pdf ou vous pouvez en apprendre davantage sur ce projet et ma solution dans le post de blog Prédire les Actions Humaines en Utilisant LIBSVM.

Conclusion CSCI473

CSCI473 est l’un des, sinon 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 joli catalogue de projets sur lesquels réfléchir et me référer sur mon CV. C’était aussi le premier cours où je me suis senti dans mon élément, car je n’ai jamais été un bon candidat 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 en CS (Été 2020)

Pendant l’été 2020, entre la réalisation de CSCI473 et mon entrée au Laboratoire HCR, j’ai suivi CSCI370 ou “Ingénierie Logicielle Avancée” dans le cadre de mon programme de premier cycle en informatique au Colorado School of Mines. CSCI370 est un cours qui amène les étudiants à concevoir, mettre en œuvre et documenter des solutions logicielles pour une entreprise. Il permet aux étudiants d’appliquer leurs connaissances acquises en cours à des problèmes réels en informatique. Vous pouvez en apprendre davantage sur le cours ici.

Dans le cours, vous décidez sur quel projet/entreprise vous allez travailler. Le cours fournissait des PDF détaillant chaque projet et entreprise. En fin de compte, j’ai décidé de travailler sur un projet proposé par une entreprise appelée Lunar Outpost intitulé “Détection de Glissement de Roue en Temps Réel et Corrections d’Erreur pour une Navigation Lunaire Améliorée”. Comme le nom est long, appelons le projet “Détection de Glissement de Roue”.

Le Problème

Lunar Outpost est une startup qui essaie de créer des rovers lunaires autonomes. Sur la lune, il y a beaucoup de poussière lunaire qui est connue pour causer beaucoup de glissement de roue. Ce n’est pas idéal car le glissement de roue peut amener les systèmes autonomes à perdre la trace de leur position réelle dans le monde. Sur Terre, cela est résolu en utilisant des 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 30+ satellites de navigation tournant constamment autour de la Terre en orbite et transmettant des signaux uniques qui permettent aux ordinateurs de calculer leur position. Mais sur la lune, il n’existe actuellement rien de tel qu’un GPS. Sachant cela, une autre méthode que le GPS doit être utilisée pour détecter le glissement de roue. Un rapport plus détaillé sur le problème du projet peut être consulté ici.

L’Équipe

Ce projet n’était pas un projet simple, donc il devait être réalisé en équipe. L’équipe se composait de cinq autres étudiants du Colorado School of Mines :

Ce projet n’était pas un projet simple, donc il devait ê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 un peu 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 en ROS puisque j’avais utilisé ROS dans mon cours de Robotique Centrée sur l’Humain (CSCI473) pendant le semestre de printemps 2020. En raison de cela, au début, j’ai aidé à mettre tout le monde à jour sur ROS et comment développer pour cela.

Défis

Dans ce projet, il y avait beaucoup de défis. Mais le plus grand défi auquel nous avons été confrontés était de ne pas avoir accès à un robot du monde réel pour les tests. Cela était dû à COVID qui a rendu tout à distance et nous a empêchés de travailler dans le laboratoire/bâtiments de l’Avant-poste Lunaire. En raison de cela, nous avons dû utiliser des simulations.

De plus, nous avons consulté des recherches académiques du WVU Navigation Lab pour avoir 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 l’Avant-poste Lunaire, ce qui, pour nous, en tant que étudiants de deuxième et troisième année, était plus difficile que prévu.

Un autre défi auquel nous avons été confrontés était le 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 essaient de résoudre/perfectionner depuis des décennies. Donc, un mois est loin d’être suffisant pour résoudre ce problème. Mais, malgré tous ces défis, nous avons persévéré et nous nous sommes assurés de livrer.

Conclusion

Après avoir travaillé sur 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 vraiment essayer cet algorithme dans une simulation n’est pas bon et ne va pas produire de recherches significatives sur la détection de glissement des roues dans l’espace et sur la lune. Nous avons conclu qu’il était beaucoup plus important de 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, pour ce type de recherche. Nous avons mis à jour le code de détection de glissement des roues pour qu’il fonctionne comme un nœud ROS et il fonctionnait correctement et pouvait facilement être importé dans du matériel réel pour des 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. Plus important encore, cette expérience a encore renforcé ma passion pour la robotique et a renforcé mon désir de poursuivre des recherches dans ce domaine, préparant le terrain pour ce qui allait suivre dans mon parcours en robotique.

Début au laboratoire HCR

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 poursuivre des recherches en robotique. J’ai eu de si bonnes expériences avec CSCI473 et la session de terrain en informatique que j’ai décidé que je voulais faire des recherches pour le laboratoire HCR. Comme j’avais rencontré le Dr. Zhang l’année précédente, j’ai décidé de lui envoyer un e-mail pour lui demander s’il y avait des opportunités dans le laboratoire en janvier 2021. Environ deux semaines plus tard, le Dr. Zhang a exprimé son intérêt, m’a présenté des options de recherche et m’a offert un rôle dans le laboratoire. J’ai ensuite commencé à travailler pour le laboratoire en février 2021.

Vidéo d’introduction

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

Mon projet

Tout au long de mon temps au laboratoire HCR, je me suis principalement concentré sur le projet Triton. Le projet Triton est un robot mobile développé par le Human Centered Robotics Lab à la Colorado School of Mines. C’est un robot terrestre à roues omnidirectionnelles triangulaires alimenté par le Jetson Nano de NVIDIA.

Le Triton, en un aperçu simple, se composait des pièces suivantes :

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

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

Pour commencer à résoudre ce problème, 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ètres sur 2 mètres avec 8 caméras Optitrack Flex (infrarouge) disposées en forme de carré à environ 6-7 pieds au-dessus du sol.

En plus de cette zone, chaque Triton avait trois boules sphériques grises attachées au sommet de leur 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 en forme triangulaire, 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 dans le mouvement.

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, avec les axes X et Y alignés à la géométrie de la pièce. Mais malgré ces données de positionnement précises, le Triton avait toujours des difficultés avec le mouvement.

Avec cette configuration, une fonctionnalité clé que nous voulions fournir 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 leur zone d’intérêt. Ensuite, le robot se déplacerait vers cette coordonnée aussi rapidement, précisément et sans à-coups que possible. Lorsque j’ai rejoint, cette fonctionnalité existait mais ne fonctionnait pas très bien. Voici une simple animation montrant comment la logique de mouvement originale fonctionnait :

Je n’ai pas enregistré la solution originale en action, donc j’ai créé cette simple animation vous montrant l’ancienne logique de mouvement en action. Sachant cela, quels sont les problèmes avec cette méthode ?

1. C’est vraiment lent
2. Cela fait que le robot occupe beaucoup d’espace juste pour aller à un point spécifique. Cela a rendu difficile l’utilisation de cette solution lorsque plusieurs Tritons se déplaçaient.

Alors pourquoi ce comportement se produisait-il ? Le problème était que le Triton tournait d’abord, changeant son alpha, jusqu’à ce qu’il pointe vers le point cible dans une marge d’erreur spécifique. Ensuite, il sprinterait en avant, et après que son theta soit éloigné de la cible d’un montant spécifique, il s’arrêterait et commencerait à tourner à nouveau jusqu’à ce que l’alpha soit dans cette plage acceptable pour l’objectif cible. Ensuite, il sprinte à nouveau et continue de faire cela jusqu’à ce qu’il atteigne le point. De plus, à mesure qu’il se rapprochait de plus en plus du point cible, la vitesse de rotation et de sprint devenait beaucoup plus lente pour s’assurer qu’il ne dépasse pas. Cela a entraîné un mouvement non naturel du Triton, prenant une éternité pour atteindre un point cible, et nécessitant tellement d’espace juste pour atteindre un point cible spécifique. Donc, avec tous ces problèmes, et étant donné à quel point cette fonctionnalité était essentielle pour le développement du projet Triton, lorsque j’ai commencé à travailler au laboratoire HCR, ma première tâche était de développer des solutions plus efficaces qui permettraient au Triton de mieux naviguer vers un point cible.

Sachant cela, j’ai passé beaucoup de temps à faire des recherches sur la meilleure façon de résoudre ce problème. Ironiquement, je suivais un cours intitulé Introduction aux systèmes de contrôle par 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. Sachant cela, et après quelques discussions que j’ai eues avec le professeur de ce cours et mon colocataire intelligent, il est devenu clair que cet objectif de faire atteindre au Triton un point cible était un problème de système en boucle fermée.

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

Méthode 1 : Contrôleur Distance-Theta

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

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

L’algorithme calculait en continu la distance euclidienne vers la cible et l’erreur angulaire entre l’orientation actuelle du robot et la direction souhaitée. Deux gains proportionnels séparés étaient appliqués pour générer respectivement des vitesses linéaires et angulaires.

Cela a permis au Triton de tourner naturellement vers l’objectif tout en se déplaçant simultanément en avant, créant des chemins courbes fluides. L’avantage clé était que le robot gardait toujours sa face avant orientée vers la destination, ce qui était crucial pour les applications basées sur la caméra.

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 :

• Contrôleur X : Contrôlait directement le mouvement est-ouest en fonction de l’erreur de la coordonnée X
• Contrôleur Y : Contrôlait directement le mouvement nord-sud en fonction de 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 composants de vitesse globaux dans le cadre de référence local du robot à l’aide de matrices de rotation. Cette transformation était nécessaire car le système de roues omnidirectionnelles du robot nécessitait des vitesses dans son propre cadre de référence, et non dans des coordonnées globales. Cette méthode produisait les chemins les plus directs vers les cibles et était significativement plus rapide, mais l’orientation du robot dérivait puisque aucun contrôle d’orientation explicite n’était en place.

Pour la méthode #1, j’ai détaillé cette méthode dans mon blog Move Turtle (TurtleSim). Je vous 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 sur 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 voit cela comme ayant besoin de corriger une erreur de 2 mètres en X et une erreur 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 dans la direction Y en fonction de l’erreur Y. Cela créait un chemin plus direct vers l’objectif, similaire à la façon dont la tête d’une imprimante 3D se déplace, et permettait des mouvements diagonaux fluides. Le robot n’avait pas besoin de tourner explicitement pour faire face à sa cible, rendant cette méthode particulièrement efficace dans des espaces restreints ou lorsque un positionnement précis est requis.

Les deux méthodes se sont révélées significativement 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 autrefois 30 à 45 secondes pour un simple mouvement point à point prend maintenant environ 8 à 12 secondes. Plus important encore, le Triton pouvait désormais naviguer plus efficacement dans des espaces restreints, ce qui est devenu 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 significatifs :

Transformations de Système de Coordonnées : L’un des aspects les plus délicats était d’obtenir les transformations de coordonnées correctes. Le système Optitrack fournissait des données dans son propre cadre de référence, le robot avait son cadre de référence local, et je devais convertir entre eux avec précision. Les premières implémentations avaient des robots se déplaçant dans les mauvaises directions parce que j’avais mélangé les calculs de matrices de rotation.

Comportement Réel vs. Comportement Idéal : Le plus grand défi était de tenir compte des facteurs du monde réel qui n’apparaissent pas dans la théorie du contrôle des 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 un certain retard dans la chaîne de communication entre Optitrack, le logiciel de contrôle et l’Arduino du robot. J’ai passé des semaines à régler les gains proportionnels et à ajouter des filtres de zone morte pour tenir compte de ces réalités physiques.

Problèmes d’Oscillation et 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 appris l’importance des termes dérivés dans les contrôleurs PID et la nécessité d’un réglage approprié des gains. J’ai finalement opté pour un contrôle principalement proportionnel avec des gains soigneusement réglés plutôt que pour un PID complet, car l’amortissement inhérent du système était suffisant pour la plupart des applications.

Interférence Multi-Robots : Lorsque plusieurs robots fonctionnaient simultanément, j’ai découvert des motifs 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 indéfiniment. Cela m’a conduit à mettre en œuvre des mécanismes de coordination et des algorithmes d’évitement de collision.

Système de Contrôle Multi-Triton

Une fois que j’avais résolu le problème de mouvement 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 être une contribution significative au projet.

Le système original ne pouvait contrôler qu’un seul Triton à la fois, ce qui limitait sévèrement 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 mis en œuvre une approche de multi-traitement en utilisant la bibliothèque de multiprocessing de Python. Chaque Triton a obtenu son propre processus dédié qui pouvait fonctionner indépendamment tout en étant coordonné par un système de contrôle central. Cela a permis à plusieurs Tritons de se déplacer simultanément sans interférer avec les boucles de contrôle des autres.

Conception de l’Architecture Multi-Robots

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

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

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

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

Communication en Mémoire Partagée : J’ai utilisé les objets multiprocessing.shared_memory et Queue de Python pour permettre une communication efficace entre les processus. Cela a permis 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 mis en œuvre 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 s’assurer que tous les robots pouvaient faire fonctionner leurs boucles de contrôle indépendamment tout en maintenant une coordination globale. Chaque processus de robot exécutait ses propres calculs PID et envoyait des commandes de moteur directement au matériel, tandis que le processus principal gérait la coordination de haut niveau comme l’évitement de collision et la planification de chemin.

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

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

Voici à quoi ressemblait la configuration du laboratoire avec plusieurs Tritons fonctionnant simultanément :

J’ai également développé une interface conviviale qui permettait aux chercheurs de définir visuellement des chemins pour chaque Triton. Vous pouviez littéralement dessiner le chemin que vous vouliez que chaque robot suive, et ils exécuteraient ces chemins avec une coordination parfaite. Cela était incroyablement utile pour mettre en place des expériences complexes sans avoir à 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é par le système de contrôle central. Les performances étaient impressionnantes, tous les robots maintenant 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 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 ait donné 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 pouvaient utiliser leurs capteurs de profondeur pour détecter d’autres Tritons dans leur proximité et croiser leurs positions. Cela servirait plusieurs objectifs :

1. Correction d’Erreur : Si le système Optitrack avait un quelconque dérive de calibration ou une occlusion temporaire, les robots pouvaient utiliser la confirmation visuelle des positions 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 pouvions 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 se détecter et de s’éviter même si le système de contrôle central avait des retards de communication.

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

• Détecter d’autres Tritons en utilisant leur forme triangulaire distinctive et des 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 avec 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 arrivaient sous forme d’un tableau 640x480 de mesures de distance à 30Hz. Le premier défi était de filtrer ces données de profondeur bruyantes pour extraire des informations géométriques significatives.

Tentatives de Détection d’Objets : J’ai expérimenté avec des algorithmes de détection en plusieurs étapes. J’ai eu un certain succès à segmenter l’image de profondeur pour identifier des objets au niveau du sol (filtrant les murs, le plafond, etc.) et à rechercher des objets avec les bonnes caractéristiques de taille, ayant une empreinte d’environ 0,3x0,3 mètres. 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é avec 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 eu des résultats prometteurs dans des conditions d’éclairage contrôlées, bien que cela ne soit pas toujours fiable.

Recherche sur la Fusion de Coordonnées : J’ai recherché 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 temps au laboratoire.

Défis de Performance : Faire fonctionner tout ce traitement en temps réel aux côtés des boucles de contrôle du robot s’est avéré difficile. J’ai expérimenté des approches d’optimisation pour faire fonctionner les algorithmes à environ 10-15Hz sans submerger les capacités de traitement du Jetson Nano.

Malheureusement, j’ai dû quitter le laboratoire avant de pouvoir terminer complètement ce travail de vision par ordinateur. Bien que j’aie eu des résultats préliminaires prometteurs et que j’aie beaucoup appris sur le traitement des capteurs de profondeur, je n’ai pas réussi à amener le système à un état entièrement fiable. Cela est resté une direction de recherche intéressante sur laquelle d’autres pourraient potentiellement s’appuyer.

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 comme la simulation de scénarios de voitures autonomes, où les véhicules doivent être conscients les uns des autres sans se fier uniquement à une infrastructure externe. La direction de recherche que j’ai commencée à explorer pourrait potentiellement contribuer à des travaux futurs dans le laboratoire.

Documentation et Préservation des Connaissances

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 éparpillées sur plusieurs plateformes et formats. Des informations critiques étaient dispersées à travers :

• Divers comptes Google Drive appartenant à différents étudiants qui avaient obtenu leur diplôme
• De vieux e-mails enfouis dans les boîtes de réception
• Des dossiers Dropbox aléatoires
• Plusieurs dépôts GitHub
• Des dépôts GitLab avec une organisation incohérente
• Des notes manuscrites que seules certaines personnes pouvaient interpréter

Cette documentation fragmentée était un énorme problème. Les nouveaux étudiants passaient des semaines juste à essayer de comprendre comment commencer, et des connaissances précieuses étaient constamment perdues lorsque des 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 à traquer chaque pièce de documentation, de code, de vidéo et de note liée au projet Triton. J’ai ensuite tout organisé 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 des 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 de pièces détaillées, 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 d’instruction sur YouTube, y compris des tutoriels détaillés de calibration Optitrack :

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

Au-delà de l’organisation de la documentation existante, j’ai créé plusieurs guides et tutoriels originaux qui ont comblé des lacunes critiques dans la base de connaissances. Ceux-ci comprenaient des instructions de configuration détaillées 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 permis d’économiser d’innombrables heures/jours pour les chercheurs futurs.

Mentorat et Transfert de Connaissances

Un des aspects les plus gratifiants de mon temps au laboratoire HCR a été l’opportunité de mentorat et de partage des connaissances que j’avais acquises. Au fur et à mesure que mon travail progressait et que je devenais plus expérimenté avec les systèmes Triton, j’ai pris de plus en plus de responsabilités pour former de nouveaux membres de l’équipe.

Mentorat des Successeurs du Laboratoire

Alors que je me préparais à quitter le laboratoire pour me concentrer sur la fin de mon diplôme et mon travail chez eBay, je me suis assuré de former en profondeur deux personnes qui prendraient en charge le 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 vraiment les principes sous-jacents afin qu’ils puissent continuer à innover.

J’ai passé des semaines à travailler en étroite collaboration avec eux, en passant par :

• Les fondements mathématiques des systèmes de contrôle PID
• L’architecture de multi-traitement 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 approfondi. Nous avons traversé de vraies sessions de débogage ensemble, je leur ai fait modifier et étendre le code existant, et je me suis assuré qu’ils pouvaient configurer de nouveaux Tritons de manière indépendante à partir de zéro.

Programme de Mentorat au Lycée

Peut-être encore plus gratifiant a été mon expérience de mentorat d’un étudiant de lycée à travers le programme de sensibilisation du laboratoire. C’était une excellente occasion d’introduire quelqu’un à la robotique, à l’informatique et à la recherche à un stade formateur de son éducation.

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

Fondamentaux de l’Informatique :

• Concepts de programmation en 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 fonctionnent les capteurs et comment interagir avec eux
• Contrôle des actionneurs et systèmes de moteurs
• Les bases des systèmes autonomes et du contrôle par rétroaction

ROS (Robot Operating System) :

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

Travail de Projet Pratique :

• 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 un 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 de la base de code du Triton

Ce qui a rendu ce mentorat particulièrement spécial, c’est de voir sa progression, passant de presque rien à savoir sur la programmation à contribuer un code significatif à un projet de recherche actif. Elle est passée de “Qu’est-ce qu’une variable ?” à déboguer de manière indépendante 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 par 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 qu’il l’a été pour elle. Cela m’a forcé à 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

Un des aspects les plus gratifiants professionnellement de mon temps dans le laboratoire a été de travailler en étroite collaboration avec Peng, un étudiant en doctorat 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 au contrôle de mouvement et aux 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’intersections : 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. Le meilleur timing et le meilleur positionnement ont aidé à rendre ces études plus réalisables.

Communication véhicule à véhicule : Le cadre de multi-traitement 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 se coordonnant avec les autres, similaire à la façon dont les voitures autonomes pourraient avoir besoin de 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 sur la localisation et la cartographie simultanées. Avoir plusieurs robots avec des capacités de détection coordonnées a permis des expériences de cartographie plus complètes.

Ce qui a rendu notre collaboration particulièrement précieuse, c’est 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é à informer mes mises en œuvre pratiques. Ses retours et ses exigences m’ont poussé à rendre les systèmes plus robustes et capables.

Nous avons passé de nombreuses heures ensemble dans le 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 pratiques en ingénierie soutenir la recherche dans la technologie des 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é accompli pendant l’ère pré-LLM du développement logiciel. Tout cela a eu lieu entre 2020 et 2021 (principalement en 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 a été écrite à partir de zéro, chaque algorithme a été 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 je me retrouvais bloqué sur un problème de transformation de coordonnées ou de réglage PID, je ne pouvais pas simplement demander à un assistant IA d’expliquer le concept ou d’aider à déboguer le problème.

Cela a rendu le processus de développement significativement 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. Comprendre les transformations de coordonnées nécessitait de travailler les mathématiques à la main. Chaque concept devait être entièrement compris avant la mise en œuvre.

Déboguer sans assistance IA : Lorsque les robots se déplaçaient dans des directions inattendues ou oscillaient autour des cibles, je devais méthodiquement retracer la logique, ajouter des sorties de débogage et tester des hypothèses une par une. Il n’y avait pas d’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 multi-traitement en Python pour la robotique ?”, je devais comprendre profondément les concepts sous-jacents. Cela m’a forcé à construire une base solide en programmation concurrente, systèmes de contrôle et vision par ordinateur.

La documentation était critique : Puisque je ne pouvais pas compter sur l’IA pour expliquer le code plus tard, je devais écrire 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 forcé à développer des compétences de résolution de problèmes plus profondes et une compréhension plus approfondie des systèmes sous-jacents. C’est fascinant de penser à quel point ce projet aurait pu être différent avec les outils de développement d’aujourd’hui disponibles.

La décision difficile de partir

Autant j’aimais travailler dans le laboratoire HCR, autant à la fin de 2021, j’ai dû faire une décision difficile que de nombreux étudiants rencontrent : équilibrer plusieurs opportunités et responsabilités. Je travaillais simultanément à temps plein en tant qu’ingénieur logiciel chez eBay, finissant mon diplôme en informatique à Mines, et contribuant à la recherche au laboratoire HCR.

L’opportunité chez eBay était significative ; c’était mon premier rôle majeur en ingénierie logicielle, m’a fourni une expérience précieuse dans l’industrie et m’a offert un revenu solide. Cependant, essayer de maintenir un travail à temps plein, de terminer mon diplôme et de contribuer de manière significative à la recherche était tout simplement insoutenable. Quelque chose devait céder.

Lorsque j’ai approché le Dr Zhang au sujet de la possibilité de réduire 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 dans l’industrie chez eBay serait précieuse pour mon développement de carrière. Il pensait 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 dans le laboratoire, j’ai pris la décision difficile de me retirer de mon rôle d’assistant de recherche pour me concentrer sur l’achèvement de mon diplôme et mon travail chez eBay. C’était l’une des décisions professionnelles les plus difficiles que j’ai dû prendre à l’époque.

Même après avoir officiellement quitté le laboratoire, j’ai continué à fournir un 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 à des questions sur le débogage et aidé à résoudre des problèmes à distance. Les connexions que j’avais établies et l’investissement que j’avais 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

Maintenant, 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, il y a une partie de moi qui se demande “et si.” La robotique était, et honnêtement l’est encore, ma véritable passion. Il y a quelque chose à travailler avec des systèmes physiques, à voir votre code se traduire en mouvement et comportement dans le monde réel, 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 un chemin différent. Que se serait-il passé si j’avais trouvé un moyen de rester dans la recherche en robotique ? Que se serait-il passé si j’avais poursuivi des études supérieures immédiatement après avoir terminé mon diplôme de premier cycle ? Que se serait-il passé si j’avais choisi de prioriser le travail au laboratoire plutôt que l’expérience dans l’industrie ?

Mais je reconnais aussi que chaque chemin a ses compromis. Les compétences que j’ai développées dans le développement web et l’IA ont été incroyablement précieuses. L’expérience dans l’industrie m’a appris sur l’ingénierie logicielle à grande échelle, la conception de l’expérience utilisateur et les défis pratiques de la construction 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 fait dans le laboratoire HCR continue d’influencer la façon dont j’aborde les problèmes aujourd’hui. La pensée systématique requise pour les systèmes de contrôle PID se manifeste 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 des connaissances 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é la façon dont je travaille avec des développeurs juniors et contribue au partage des connaissances au sein de l’équipe.

Plus important encore, 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 des algorithmes de mouvement de robots ou en construisant des systèmes d’IA qui aident les utilisateurs à atteindre leurs objectifs, la satisfaction vient de la résolution de problèmes difficiles qui comptent.

L’impact durable

En regardant en arrière 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é la façon dont la plateforme Triton fonctionnait, et beaucoup de ces améliorations sont encore utilisées aujourd’hui. Le dépôt de documentation que j’ai créé est devenu la base de connaissances pour l’ensemble du projet. Les relations de mentorat que j’ai formées ont eu un impact durable sur les personnes avec lesquelles j’ai travaillé.

Mais peut-être plus significativement, l’expérience m’a montré de quoi je suis capable lorsque je travaille sur des problèmes qui me passionnent vraiment. Au cours de ces huit mois, j’ai :

• Amélioré le système de contrôle de mouvement des robots 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éé une documentation complète et un système de gestion des connaissances
• Mentoré plusieurs personnes et aidé au transfert de connaissances
• Soutenu des recherches de niveau doctorat sur les véhicules autonomes

Ce n’était pas seulement une question d’accomplissements techniques, bien que ceux-ci aient été significatifs pour moi. Il s’agissait d’apprendre qu’avec de la persistance 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

Bien que ma carrière m’ait conduit dans d’autres directions, ma passion pour la robotique n’a pas diminué. Je suis toujours les développements dans le domaine, je suis enthousiaste à propos des avancées dans l’apprentissage des robots et les systèmes autonomes, et je travaille occasionnellement sur des projets de robotique personnelle 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 qu’il y a un avenir où ces différents fils de mon expérience se rejoignent de manière inattendue.

Pour l’instant, je suis reconnaissant pour le temps que j’ai passé dans le laboratoire HCR et les expériences qu’il m’a fournies. C’était 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 Triton sont toujours là, servant toujours les chercheurs, permettant toujours un travail important. Et c’est plutôt merveilleux.