Mon chapitre de recherche en robotique

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

Contexte

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

J’ai eu la chance de trouver ma passion très tôt dans ma vie. Pendant le lycée, j’ai passé beaucoup de temps à essayer de comprendre ce que j’aimais et ce dans quoi je pouvais être bon. Après quelques essais et erreurs, j’ai réussi à déterminer que ma passion était l’informatique. Mais c’est aussi à cette époque que j’ai découvert que j’avais cet amour débordant pour la création à travers le code.

À Mines, j’ai eu l’occasion de travailler au Human Centered Robotics (HCR) Lab de Mines sous la direction du Dr Hao Zhang. J’ai rencontré le Dr Zhang pour la première fois au printemps 2020 dans le cadre de son cours « Human Centered Robotics » (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 Human Centered Robotics (CSCI473)

Le cours Human Centered Robotics (CSCI473) de Mines a été l’un des rares cours de mon parcours universitaire à avoir eu un impact profond sur moi. Le cours était enseigné par le Dr Hao Zhang. Toute notre note pour le cours ne reposait que sur trois projets, chacun présentant un problème difficile qui introduisait des concepts fondamentaux de la robotique. Ces projets consistaient en :

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

Apprendre le Robot Operating System (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 » 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 comprenait :

• Configurer ROS Melodic, ce que j’ai fait sur mon ordinateur portable HP de 2011, qui était suffisamment bon
• Installer et configurer ROS et Gazebo
• Suivre le tutoriel de gazebosim et le tutoriel d’e-manual.

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

Cette tâche, bien qu’elle semblât 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. 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 apprendre à 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, en utilisant une carte d’environnement qui vous est fournie. Les étudiants utiliseront un télémètre laser sur le robot pour effectuer la perception et l’apprentissage, le robot étant contrôlé à l’aide de commandes de direction et de vitesse. Les étudiants sont tenus de programmer ce projet en C++ ou en Python dans ROS Melodic fonctionnant sur Ubuntu 18.04 LTS (c’est-à-dire le même environnement de développement que celui utilisé dans le projet 1). De plus, les étudiants sont tenus de rédiger un rapport en suivant le format des conférences standard de robotique IEEE en utilisant LATEX.

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

Je n’ai jamais publié ma solution sur GitHub ni sur le web parce qu’elle n’était pas très bonne et fortement imparfaite. De plus, faire fonctionner le code dans le bon environnement est assez difficile et agaçant. Cependant, j’ai une vidéo de démonstration que j’ai soumise au cours, montrant ma solution. Vous pouvez la voir ici :

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

Compréhension par le robot 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 classifier des comportements humains à l’aide d’un ensemble de données d’activité publique collecté à partir d’un capteur Kinect V1. De plus, les étudiants sont tenus de rédiger un rapport en suivant le format des conférences standard de robotique IEEE en utilisant LATEX dans le Livrable 3.

Ce projet était चुनौतीुव même s’il n’était pas aussi difficile que le deuxième projet. L’objectif principal était d’utiliser des données de capteur Kinect V1, issues du MSR Daily Activity 3D Dataset, et des machines à vecteurs de support pour classer 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 sur l’article de blog Prédire les actions humaines à l’aide de LIBSVM.

Conclusion de CSCI473

CSCI473 est l’un des meilleurs cours, sinon le meilleur, que j’ai suivis pendant mes études de premier cycle à Mines. Tous ces projets m’ont beaucoup appris et m’ont permis d’avoir un catalogue de projets intéressant sur lequel réfléchir et auquel 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é bon aux examens, mais j’excellais dans la réalisation de projets. C’est aussi 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 Human-Centered Robotics (HCR) Lab de Mines.

Session de terrain en informatique (été 2020)

Pendant l’été 2020, entre l’achèvement de CSCI473 et mon arrivée au HCR Lab, j’ai suivi CSCI370 ou « Advanced Software Engineering » dans le cadre de mon programme de premier cycle en informatique à la Colorado School of Mines. CSCI370 est un cours qui amène les étudiants à concevoir, implémenter et documenter des solutions liées au logiciel pour une entreprise. Il permet aux étudiants d’appliquer les connaissances acquises dans leurs cours à des problèmes d’informatique du monde réel. Vous pouvez en apprendre davantage sur le cours ici.

Dans ce cours, vous pouvez décider du projet/de l’entreprise sur lesquels vous allez travailler. 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é « Real Time Wheel Slip Detection and Error Corrections for Enhanced Lunar Navigation ». Comme le nom est long, donnons au projet un alias : « Détection du glissement des roues ».

Le problème

Lunar Outpost est une startup qui tente de créer des robots lunaires autonomes. Sur la Lune, il y a beaucoup de poussière lunaire, connue pour provoquer beaucoup de glissement des roues. Ce n’est pas idéal, car le glissement des roues peut amener les systèmes autonomes à perdre la trace de leur position réelle. Sur Terre, ce problème est résolu en utilisant des 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’en ayant 30+ satellites de navigation en orbite autour de la Terre en permanence et en 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 des roues. Un rapport plus détaillé du problème du projet peut être consulté ici.

L’équipe

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

Ce projet n’était pas un projet simple, il devait donc ê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 exigeait 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 avec ROS puisque j’avais utilisé ROS dans mon cours Human Centered Robotics (CSCI473) pendant le semestre de printemps 2020. Grâce à cela, au début, j’ai aidé tout le monde à se mettre à niveau sur ROS et sur la manière de développer pour celui-ci.

Défis

Dans ce projet, il y a eu 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û au fait que COVID a rendu tout à distance et nous a empêchés de travailler dans le laboratoire/les bâtiments de Lunar Outpost. À cause de cela, nous avons dû utiliser des simulations.

De plus, nous avons parcouru certaines recherches académiques du WVU Navigation Lab afin d’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 Lunar Outpost, ce qui, pour nous, en tant qu’étudiants de deuxième et troisième année de premier cycle, était plus difficile que nous ne l’avions 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. Un mois est donc loin d’être suffisant pour résoudre ce problème. Mais, malgré tous ces défis, nous avons persévéré et veillé à livrer.

Conclusion

Après avoir travaillé sur toute la recherche et le développement, nous avons déterminé qu’il est presque impossible de simuler correctement la physique de la Lune numériquement, donc essayer réellement cet algorithme dans une simulation n’est pas bon et ne permettra pas d’obtenir des résultats de recherche significatifs sur la détection du glissement des roues dans l’espace et sur la Lune. Nous avons conclu que la mise en place d’un environnement de test approprié à l’aide de quelque chose comme du sable et du matériel réel, comme un robot Husky, est de loin plus importante pour ce type de recherche. Nous avons bien mis à jour le code de détection du glissement des roues pour qu’il fonctionne comme un nœud ROS, et il fonctionnait correctement et pouvait facilement être importé sur du matériel réel pour être testé. Ce projet m’a permis d’assumer 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 m’attaquant à un problème complexe que je n’avais jamais rencontré auparavant. Plus important encore, cette expérience a davantage consolidé ma passion pour la robotique et renforcé mon désir de poursuivre la recherche dans ce domaine, préparant ainsi 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 la recherche en robotique. J’avais eu de si grandes expériences avec CSCI473 et la session de terrain en informatique que j’ai décidé que je voulais faire de la recherche 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 au laboratoire en janvier 2021. En environ 2 semaines, le Dr Zhang a manifesté son intérêt, m’a présenté des options de recherche et m’a առաջարկé un rôle au 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 avoir commencé 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 omnidirectionnel triangulaire à roues omni alimenté par le Jetson Nano de NVIDIA.

Le Triton, dans un simple aperçu, était composé des éléments suivants :

• NVIDIA Jetson Nano
• Carte porteuse A205 Seed Studio de NVIDIA
• Arduino Mega
• Carte Micro SD de 64 Go
• Corps personnalisé imprimé en 3D
• 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é vers 2018-2020 en tant que robot à des fins éducatives. Au moment où j’ai rejoint l’équipe, le Triton était déjà bien établi, et le laboratoire envisageait d’en 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 dans un sens basique, mais ne faisait rien d’intelligent. Il n’avait même pas la capacité d’effectuer des mouvements plus avancés.

Pour commencer à remédier à cela, le laboratoire a aménagé 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 cet espace construit, chaque Triton avait trois sphères grises fixé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 forme triangulaire, nous pouvions déterminer avec précision 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 mouvement.

Le système Optitrack fournissait des données de position et d’orientation à environ 120 Hz avec une précision submillimé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 sur la géométrie de la pièce. Mais malgré ces données de positionnement précises, le Triton avait toujours du mal à se déplacer.

Avec cette configuration, une fonctionnalité essentielle 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. Ensuite, le robot se déplacerait vers cette coordonnée aussi vite, précisément et sans heurts que possible. Lorsque j’ai rejoint l’équipe, 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. 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 juste pour aller à un point spécifique. Cela rendait difficile pour nous d’utiliser 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, modifiant son alpha, jusqu’à ce qu’il pointe vers le point cible dans une certaine marge d’erreur. Ensuite, il se précipitait vers l’avant, et après que son theta s’écartait de la cible d’une certaine valeur, il s’arrêtait et recommençait à tourner jusqu’à ce que l’alpha soit dans la plage acceptable pour l’objectif cible. Puis il repartait en sprint et continuait ainsi jusqu’à atteindre 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 afin de s’assurer qu’il ne dépasse pas la cible. Cela entraînait un mouvement peu naturel du Triton, prenant une éternité pour atteindre un point cible et nécessitant une si grande zone juste pour atteindre un point cible spécifique. Ainsi, avec tous ces problèmes, et étant donné à quel point cette fonctionnalité était essentielle au développement du projet Triton, lorsque j’ai commencé à travailler au laboratoire HCR, ma première tâche a été 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 possible de résoudre ce problème. Ironiquement, je suivais un cours appelé Introduction aux systèmes de contrôle en rétroaction (EENG307) à Mines. Dès le 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 une discussion que j’ai eue avec le professeur de ce cours et mon colocataire très intelligent, il est devenu clair que cet objectif d’amener le 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 विकसितé deux approches de contrôleur distinctes pour les Tritons :

Méthode 1 : Contrôleur Distance-Theta

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

• Contrôleur de distance : calculait la distance euclidienne à 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, en appliquant un gain proportionnel séparé pour la vitesse de rotation

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

Cela faisait que le Triton se 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 sa face avant orientée vers la destination, ce qui était crucial pour les applications basées sur 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 en X et en Y :

• Contrôleur X : Contrôlait directement le mouvement est-ouest en fonction de l’erreur de coordonnée X
• Contrôleur Y : Contrôlait directement le mouvement nord-sud en fonction de l’erreur de coordonnée Y

L’implémentation calculait indépendamment les erreurs de coordonnées X et Y, appliquait des gains proportionnels séparés, puis transformait ces composantes de vitesse globales dans le repère local du robot à l’aide de matrices de rotation. Cette transformation était nécessaire parce que la transmission à roues omnidirectionnelles du robot exigeait des vitesses dans son propre repère, 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 n°1, j’ai expliqué cette méthode en détail 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 n°1. J’ai développé la méthode n°1 à l’aide de TurtleSim de ROS, puis j’ai transféré ce code vers le Triton et l’ai mis à jour pour l’adapter à un environnement plus réel.

La méthode n°2 utilisait une approche assez différente mais tout aussi efficace. Au lieu de penser à l’orientation du robot et à la distance jusqu’à l’objectif, cette méthode traite le mouvement comme un problème de plan de coordonnées. Le contrôleur calcule en continu l’erreur dans les directions X et Y séparément. Par exemple, si le robot doit aller de (0,0) à (2,3), il interprète cela comme la nécessité de 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 dans la direction Y en fonction de l’erreur Y. Cela créait une trajectoire plus directe vers l’objectif, similaire au déplacement de la tête d’une imprimante 3D, et permettait des mouvements diagonaux fluides. Le robot n’avait pas besoin de se tourner explicitement pour faire face à sa cible, ce qui rendait cette méthode particulièrement efficace dans les espaces restreints ou lorsque le positionnement précis est requis.

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

Ce qui prenait autrefois 30 à 45 secondes pour un simple déplacement d’un point à un autre prenait désormais environ 8 à 12 secondes. Plus important encore, le Triton pouvait désormais naviguer plus efficacement dans les espaces étroits, 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’a pas été simple et a impliqué plusieurs défis importants de débogage :

Transformations du système de coordonnées : L’un des aspects les plus délicats a été d’obtenir les bonnes transformations de coordonnées. Le système Optitrack fournissait des données dans son propre repère, le robot avait son propre repère local, et je devais convertir entre les deux avec précision. Les premières implémentations faisaient se déplacer les robots dans la mauvaise direction parce que j’avais confondu les calculs de matrice de rotation.

Comportement réel vs. comportement idéal : Le plus grand défi a été de prendre en 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 délai dans la chaîne de communication allant 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.

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 puis vacillaient d’avant en arrière. Cela m’a appris l’importance des termes dérivatifs dans les contrôleurs PID et la nécessité d’un réglage approprié des gains. J’ai finalement opté principalement pour un contrôle proportionnel avec des gains soigneusement réglés plutôt que pour un PID complet, car l’amortissement intrinsèque du système était suffisant pour la plupart des applications.

Interférences entre plusieurs robots : Lorsque plusieurs robots fonctionnaient simultanément, j’ai découvert des schémas d’interférence inattendus. Les robots se « disputaient » parfois le même espace ou créaient des situations d’impasse où ils se bloquaient indéfiniment mutuellement. Cela m’a conduit à mettre en place des mécanismes de coordination et des algorithmes d’évitement de collision.

Système de contrôle multi-Triton

Une fois le problème du mouvement d’un seul Triton résolu, le défi suivant du laboratoire a été de faire fonctionner plusieurs Tritons simultanément en coordination. C’est devenu l’un de mes principaux axes de travail et cela s’est finalement révélé une contribution importante au projet.

Le système original ne pouvait contrôler qu’un seul Triton à la fois, ce qui limitait fortement les possibilités de recherche. Le laboratoire voulait simuler des scénarios dans lesquels plusieurs véhicules autonomes devaient coordonner leurs mouvements, comme des voitures autonomes qui communiquent entre elles pour optimiser la circulation et créer de meilleures cartes SLAM (localisation et cartographie simultanées).

Pour résoudre ce problème, j’ai mis en œuvre une approche multiprocessus utilisant la bibliothèque multiprocessing de Python. Chaque Triton disposait de son propre processus dédié, pouvant fonctionner indépendamment tout en restant 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-robots

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

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

Processus de robots individuels : Chaque Triton avait son propre processus Python dédié qui prenait en charge :

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

Communication via 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 permettait une coordination en temps réel sans la surcharge de la communication réseau.

Mécanismes de synchronisation : Pour éviter les conflits lorsque plusieurs robots devaient se coordonner (comme éviter des collisions), j’ai mis en place 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 consistait à 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 directement les commandes moteur au matériel, tandis que le processus principal gérait la coordination de niveau supérieur comme l’évitement de collision et la planification des 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 coordonnée de trajectoires avec évitement d’obstacles
• Comportements de robotique en essaim
• Cartographie SLAM multi-agents
• Contrôle de formation et comportements de suivi

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

J’ai également विकसितé une interface conviviale qui permettait aux chercheurs de définir visuellement les trajectoires de chaque Triton. Vous pouviez littéralement dessiner la trajectoire que vous vouliez que chaque robot suive, et ils exécuteraient ces trajectoires avec une coordination parfaite. Cela était extrêmement 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 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 in Action

Intégration de capteurs de profondeur et correction des coordonnées

Une autre avancée majeure sur laquelle j’ai travaillé consistait à utiliser les caméras de profondeur Intel RealSense D435 montées sur chaque Triton. Alors que le système Optitrack nous fournissait des données de positionnement extrêmement 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 les autres Tritons à proximité et recouper leurs positions. Cela servirait à plusieurs fins :

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

2. SLAM amélioré : En faisant travailler ensemble plusieurs robots équipés de capteurs de profondeur, nous pouvions créer des cartes beaucoup plus riches de l’environnement 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 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 à l’aide des données de profondeur
• Comparer ces mesures aux données Optitrack pour identifier les écarts
• Éventuellement ajuster leur système de coordonnées en temps réel afin de maintenir la précision

Expériences de vision par ordinateur

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

Traitement des données de profondeur : L’Intel RealSense D435 fournissait à la fois des flux de données RGB et de profondeur. Je travaillais principalement avec les données de profondeur, qui se présentaient sous la forme d’un tableau 640x480 de mesures de distance à 30 Hz. Le premier défi consistait à filtrer ces données de profondeur bruitées pour en 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 obtenu quelques résultats en segmentant l’image de profondeur pour identifier les objets au niveau du sol (en filtrant les murs, le plafond, etc.) et en recherchant des objets présentant les bonnes caractéristiques de taille, avec une empreinte d’environ 0,3 x 0,3 mètre. J’ai essayé d’utiliser la détection des contours et l’analyse géométrique pour identifier le profil distinctif du Triton, avec des résultats mitigés.

Expériences de reconnaissance des 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 blob pour identifier le schéma 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 cela ne soit pas resté fiable de manière constante.

Recherche sur la fusion des 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 base de filtre de Kalman. 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 passage au laboratoire.

Défis de performance : Faire en sorte que tout ce traitement s’exécute en temps réel en parallèle des boucles de contrôle du robot s’est révélé difficile. J’ai expérimenté des approches d’optimisation pour faire fonctionner les algorithmes à environ 10-15 Hz sans surcharger les capacités de calcul du Jetson Nano.

Malheureusement, j’ai dû quitter le laboratoire avant de pouvoir mener à bien ce travail de vision par ordinateur. Bien que j’aie obtenu des résultats initiaux prometteurs et appris énormément sur le traitement des capteurs de profondeur, je n’ai pas réussi à amener le système à un état pleinement fiable. Cela est resté une orientation de recherche intéressante sur laquelle d’autres pourraient potentiellement s’appuyer.

Voici une vidéo de moi en train de tester 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 réel 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’une infrastructure externe. L’orientation de recherche que j’ai commencée à explorer pourrait potentiellement contribuer à de futurs travaux dans le laboratoire.

Documentation et préservation des connaissances

L’une de mes contributions les plus importantes au HCR Lab, 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 sur le projet Triton étaient dispersées sur plusieurs plateformes et dans plusieurs formats. Les informations essentielles étaient réparties entre :

• Divers comptes Google Drive appartenant à différents étudiants diplômés
• De vieux e-mails enfouis dans des boîtes de réception
• Des dossiers Dropbox épars
• Plusieurs dépôts GitHub
• Des dépôts GitLab à l’organisation incohérente
• Des notes manuscrites que seules certaines personnes pouvaient interpréter

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

Je me suis donné pour mission de résoudre ce problème de manière systématique. J’ai passé d’innombrables heures à retrouver chaque document, code, vidéo et note liés 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 mettre en place 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 mis en ligne des vidéos pédagogiques sur YouTube, y compris des tutoriels détaillés d’étalonnage Optitrack :

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

Au-delà de la simple organisation de la documentation existante, j’ai créé plusieurs guides et tutoriels originaux qui comblaient des lacunes critiques dans la base de connaissances. Cela comprenait des instructions détaillées de configuration pour les nouveaux membres du laboratoire, des guides de dépannage complets et des démonstrations vidéo de procédures complexes.

L’impact a été immédiat et durable. Les nouveaux étudiants pouvaient être opérationnels en quelques jours au lieu de plusieurs 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 fait gagner d’innombrables heures/jours aux chercheurs futurs.

Mentorat et transfert de connaissances

L’un des aspects les plus gratifiants de mon passage au HCR Lab a été l’occasion de mentorer d’autres personnes et de partager les connaissances que j’avais acquises. Au fur et à mesure que mon travail progressait et que je gagnais en expérience avec les systèmes Triton, j’ai pris de plus en plus de responsabilités dans la formation des nouveaux membres de l’équipe.

Mentorat des successeurs du laboratoire

Alors que je me préparais à quitter éventuellement le laboratoire pour me concentrer sur la fin de mon diplôme et sur mon travail chez eBay, j’ai veillé à former en profondeur deux personnes qui reprendraient 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’elles comprenaient réellement les principes sous-jacents afin qu’elles puissent continuer à innover.

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

• 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 la manière de 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é ensemble de vraies sessions de débogage, 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 autonome à partir de zéro.

Programme de mentorat pour lycéen

Peut-être encore plus gratifiante a été mon expérience de mentorat d’un élève de lycée dans le cadre du programme de sensibilisation du laboratoire. C’était une excellente occasion d’initier quelqu’un à la robotique, à l’informatique et à la recherche à un stade formateur de son parcours éducatif.

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 les interfacer
• Contrôle des actionneurs et systèmes moteurs
• Les bases des systèmes autonomes et du contrôle en boucle de rétroaction

ROS (Robot Operating System) :

• Comprendre le système de messagerie publication/abonnement
• Créer des nœuds et des services
• Travailler avec les fichiers de lancement et les serveurs de paramètres

Travail pratique sur un projet :

• Nous avons collaboré à la création d’un service ROS qui contrôlait le système de 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 des LED qu’elle a créé est devenu une partie permanente de la base de code du Triton

Ce qui rendait ce mentorat particulièrement spécial, c’était de voir sa progression, passant de la connaissance de pratiquement rien en programmation à la contribution d’un code utile à un projet de recherche actif. Elle est passée de « Qu’est-ce qu’une variable ? » à déboguer de manière autonome des problèmes de communication ROS et à écrire ses propres implémentations de services.

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

Le mentorat a été aussi formateur pour moi qu’il l’a été pour elle. Cela m’a obligé à décomposer des concepts complexes en éléments digestibles et à vraiment réfléchir aux fondamentaux de ce que nous faisions. Enseigner à quelqu’un d’autre a fait de moi un meilleur ingénieur et chercheur.

Collaboration avec la recherche doctorale

L’un des aspects les plus gratifiants sur le plan professionnel de mon passage au laboratoire a été de travailler étroitement avec Peng, un doctorant dont la recherche portait sur les algorithmes de voitures autonomes. Les améliorations logicielles que j’avais apportées au système Triton ont contribué à soutenir sa recherche doctorale.

La recherche de Peng nécessitait une coordination précise et fiable entre plusieurs robots afin de 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 à mener. 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 des intersections : Grâce aux 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 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, un peu comme les voitures autonomes pourraient devoir fonctionner.

Recherche SLAM et cartographie : Le travail d’intégration du capteur de profondeur a fourni à Peng des données supplémentaires pour sa recherche en localisation et cartographie simultanées. Le fait d’avoir plusieurs robots dotés de 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 qu’il ne s’agissait pas seulement de moi aidant sa recherche, mais d’un véritable partenariat. La compréhension qu’avait Peng des aspects théoriques des véhicules autonomes a permis d’éclairer mes implémentations pratiques. Ses retours et ses exigences m’ont poussé à rendre les systèmes plus robustes et plus performants.

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

Les systèmes que j’ai construits sont devenus une partie utile du travail de thèse de Peng. Voir mes contributions d’ingénierie pratique soutenir la recherche sur la technologie des véhicules autonomes a été vraiment épanouissant. Cela a renforcé mon intérêt pour la manière 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 a été extrêmement gratifiant.

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

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

Chaque ligne de code a été écrite à partir de zéro, chaque algorithme a été étudié à travers des articles académiques et des manuels, et chaque session de débogage impliquait des méthodes traditionnelles comme des instructions d’impression, des débogueurs et des tests méthodiques. Quand je bloquais sur un problème de transformation de coordonnées ou d’ajustement de 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 nettement plus difficile, mais aussi plus formateur. J’ai dû :

Tout rechercher 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 la mathématique à la main. Chaque concept devait être pleinement compris avant l’implémentation.

Déboguer sans assistance IA : Quand les robots se déplaçaient dans des directions inattendues ou oscillaient autour des cibles, je devais retracer méthodiquement la logique, ajouter des sorties de débogage et tester les hypothèses une par une. Il n’y avait pas d’IA pour suggérer des problèmes potentiels ou aider à interpréter des schémas 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é à construire des bases solides en programmation concurrente, en systèmes de contrôle et en vision par ordinateur.

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

Avec le recul, même si les outils d’IA modernes auraient accéléré de nombreux aspects du développement, travailler sans eux m’a forcé à développer des compétences plus profondes en résolution de problèmes 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 à disposition.

La décision difficile de partir

Même si j’aimais profondément travailler au HCR Lab, à la fin de 2021, j’ai dû faire face à une décision difficile que beaucoup d’étudiants rencontrent : équilibrer plusieurs opportunités et responsabilités. Je travaillais simultanément à temps plein comme ingénieur logiciel chez eBay, je terminais mon diplôme d’informatique à Mines, et je contribuais à la recherche au HCR Lab.

L’opportunité chez eBay était importante ; c’était mon premier grand poste d’ingénieur logiciel, elle m’offrait une expérience industrielle inestimable et me procurait un revenu stable. Cependant, essayer de maintenir un travail à temps plein, terminer mes études et contribuer de manière significative à la recherche était tout simplement insoutenable. Il fallait faire un choix.

Lorsque j’ai demandé au Dr Zhang s’il serait possible de réduire ma charge de cours pour me concentrer davantage sur le travail au laboratoire, il m’a vivement conseillé de ne pas 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 professionnel. Il estimait qu’abandonner 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 pour me concentrer sur l’obtention de mon diplôme et sur mon travail chez eBay. C’était l’une des décisions professionnelles les plus difficiles que j’ai eues à prendre à l’époque.

Même après avoir officiellement quitté le laboratoire, j’ai continué à apporter mon soutien chaque fois que quelqu’un avait besoin d’aide avec les systèmes que j’avais construits. Je mettais à jour la documentation au besoin, répondais aux questions sur le débogage et aidais à résoudre les problèmes à distance. Les liens que j’avais noués et l’investissement que j’avais dans la réussite du projet ne disparaissaient pas simplement parce que je ne faisais plus officiellement partie de l’équipe.

Réflexions et retour en arrière

Aujourd’hui, en 2025, quatre ans plus tard, je me retrouve à repenser à 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 m’ont offert d’immenses opportunités de croissance et d’impact.

Et pourtant, une partie de moi se demande « et si ». La robotique était, et est honnêtement encore, ma véritable passion. Il y a quelque chose dans le travail avec des systèmes physiques, voir son code se traduire en mouvement et en comportement 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 se serait passé si j’avais pris un chemin différent. Et si j’avais trouvé un moyen de rester dans la recherche en robotique ? Et si j’avais poursuivi des études supérieures immédiatement après avoir terminé mon diplôme de premier cycle ? Et si j’avais choisi de donner la priorité au travail de laboratoire plutôt qu’à l’expérience industrielle ?

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

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

Plus important encore, cette expérience m’a appris que je m’épanouis lorsque je travaille sur des problèmes techniques difficiles ayant un impact réel. Qu’il s’agisse d’optimiser des algorithmes de mouvement de robots ou de construire 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 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 nombre 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 de 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 important encore, cette expérience m’a montré de quoi je suis capable lorsque je travaille sur des problèmes qui me passionnent vraiment. Durant ces huit mois, j’ai :

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

Il ne s’agissait pas seulement des réalisations techniques, même si elles avaient pour moi une grande valeur. Il s’agissait d’apprendre qu’avec de la persévérance et une pensée systématique, on peut apporter des contributions utiles même en tant qu’étudiant de premier cycle.

L’avenir et la robotique

Bien que ma carrière m’ait conduit dans d’autres directions, ma passion pour la robotique ne s’est pas atténuée. Je suis toujours l’évolution du domaine, je suis enthousiaste à propos des avancées dans l’apprentissage des robots et les systèmes autonomes, et il m’arrive occasionnellement de travailler sur des projets personnels de robotique 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 aura un avenir où ces différents fils de mon expérience se rejoindront de manière inattendue.

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

Les robots Triton sont toujours là, servant encore les chercheurs, permettant toujours des travaux importants. Et cela, c’est vraiment merveilleux.