Il mio capitolo sulla ricerca in robotica

Questo post racconta il mio percorso nella robotica, a partire dalla scoperta della mia passione per la robotica in FRC durante il liceo nel 2015 fino al mio periodo come assistente di ricerca al Colorado School of Mines Laboratorio Human Centered Robotics (HCR) da febbraio 2021 a settembre 2021. Nota che dalla fine del 2022, il Laboratorio HCR si è trasferito dal Colorado School of Mines all’University of Massachusetts Amherst, insieme al suo sito da hcr.mines.edu a hcr.cs.umass.edu.

Contesto

Ho iniziato i miei studi universitari al Colorado School of Mines nel semestre autunnale del 2018. Il mio corso di laurea era Informatica con un focus su Robotica e Sistemi Intelligenti. E mi sono laureato nella Primavera del 2022.

Ho avuto la fortuna di trovare la mia passione presto nella vita. Durante il liceo, ho trascorso una buona parte del tempo a capire cosa mi piacesse e in cosa potessi essere bravo. Dopo alcuni tentativi ed errori, sono riuscito a capire che la mia passione era l’informatica. Ma è stato anche durante questo periodo che ho scoperto di avere questo amore travolgente per costruire tramite il codice.

Alle Mines, ho avuto l’opportunità di lavorare presso il Laboratorio Human Centered Robotics (HCR) delle Mines sotto la supervisione del Dr Hao Zhang. Ho incontrato per la prima volta il Dr. Zhang nella Primavera del 2020 attraverso il suo corso “Human Centered Robotics” (CSCI473), e dopo il caos del COVID e degli impegni didattici, ho iniziato a lavorare nel suo laboratorio all’inizio della Primavera del 2021.

Corso Human Centered Robotics (CSCI473)

Il corso Human Centered Robotics (CSCI473) delle Mines è stato uno dei pochi corsi della mia esperienza universitaria che ha avuto un impatto profondo su di me. Il corso era tenuto dal Dr. Hao Zhang. L’intero voto del corso era composto da solo tre progetti, ognuno dei quali presentava un problema impegnativo che introduceva concetti fondamentali della robotica. Questi progetti consistevano in:

1. Apprendere Robot Operating System (ROS)
2. Apprendimento per rinforzo per il seguire un muro con il robot
3. Comprensione dei comportamenti umani da parte del robot usando rappresentazioni basate sullo scheletro

Apprendere Robot Operating System (ROS)

Questo è stato il primo progetto che ci è stato assegnato. Il progetto consisteva in tre compiti:

1. Configurare l’ambiente di sviluppo
2. Comprendere il simulatore Gazebo
3. Scrivere un “Hello World” in ROS

Per i compiti 1 e 2, dovevamo semplicemente configurare il nostro ambiente di sviluppo e seguire un tutorial introduttivo su Gazebo. Questo includeva:

• Configurare ROS Melodic, cosa che ho fatto sul mio portatile HP del 2011 che era abbastanza buono
• Installare e configurare ROS e Gazebo
• Seguire il tutorial di gazebosim e il tutorial di e-manual.

Il compito 3, invece, è stato una vera sfida. Il compito era usare turtlesim e far disegnare alla tartaruga il logo “M” delle Mines:

Questo compito, sebbene sembrasse semplice, è stato più difficile di quanto apparisse. Questo progetto alla fine mi ha introdotto al concetto di sistemi a ciclo aperto e a ciclo chiuso. Per la descrizione completa del progetto, consulta csci473-p1.pdf oppure puoi saperne di più su questo progetto e sulla mia soluzione nella pagina del progetto ROS Move Turtle.

Apprendimento per rinforzo per il seguire un muro con il robot

Questo è stato il secondo progetto che ci è stato assegnato, ed è stato uno dei progetti più difficili su cui abbia mai lavorato all’università. La descrizione del progetto era la seguente:

In questo progetto, gli studenti progetteranno e implementeranno algoritmi di apprendimento per rinforzo per insegnare a un robot mobile autonomo a seguire un muro ed evitare di scontrarsi con ostacoli. Gli studenti utilizzeranno la simulazione Gazebo in ROS Melodic per simulare un robot mobile omni-direzionale chiamato Triton, e useranno una mappa dell’ambiente fornita. Gli studenti utilizzeranno uno scanner laser sul robot per eseguire sensing e apprendimento, dove il robot è controllato usando comandi di sterzata e velocità. Gli studenti sono tenuti a programmare questo progetto usando C++ o Python in ROS Melodic eseguito su Ubuntu 18.04 LTS (cioè, lo stesso ambiente di sviluppo usato nel Progetto 1). Inoltre, gli studenti devono scrivere un rapporto seguendo il formato standard delle conferenze IEEE di robotica usando LATEX.

Per l’algoritmo di apprendimento per rinforzo, ci è stato indicato di usare Q-Learning. Abbiamo anche usato l’ambiente di simulazione Gazebo Stingray fornito dal corso. Stingray consisteva nel modello Triton e nella logica fisica. Ci è anche stato fornito un labirinto che il robot doveva seguire. Tutto sommato, l’ambiente sembrava così:

Non ho mai pubblicato la mia soluzione su GitHub o sul web perché non era molto buona e presentava numerosi difetti. Inoltre, far funzionare il codice nell’ambiente giusto è piuttosto difficile e fastidioso. Tuttavia, ho un video demo che ho inviato al corso, che mostra la mia soluzione. Puoi vederlo qui:

Per la descrizione completa del progetto, consulta csci473-p2.pdf

Comprensione dei comportamenti umani da parte del robot usando rappresentazioni basate sullo scheletro

Per il terzo progetto, la descrizione era la seguente:

In questo progetto, gli studenti implementeranno diverse rappresentazioni basate sullo scheletro (Consegna 1) e utilizzeranno Support Vector Machines (SVM) (Consegna 2) per classificare i comportamenti umani usando un dataset pubblico di attività raccolto da un sensore Kinect V1. Inoltre, gli studenti sono tenuti a scrivere un rapporto seguendo il formato standard delle conferenze IEEE di robotica usando LATEX nella Consegna 3.

Questo progetto è stato impegnativo ma non difficile come il secondo progetto. L’obiettivo principale era usare i dati del sensore Kinect V1 dal MSR Daily Activity 3D Dataset e le Support Vector Machines per classificare certe azioni/comportamenti umani. Per la descrizione completa del progetto, consulta csci473-p3.pdf oppure puoi saperne di più su questo progetto e sulla mia soluzione nel post del blog Predict Human Actions Using LIBSVM.

Conclusione CSCI473

CSCI473 è una delle migliori, se non la migliore, classi che ho seguito durante i miei studi universitari alle Mines. Tutti questi progetti mi hanno insegnato molto e mi hanno permesso di avere un catalogo interessante di progetti da mostrare e a cui riferirmi nel mio curriculum. È stato anche il primo corso in cui ho sentito di essere nel mio elemento, poiché non sono mai stato bravo nei test ma eccellevo nel completare progetti. È stato anche attraverso questo corso che ho incontrato il Dr. Hao Zhang, che alla fine mi ha aiutato a ottenere una posizione come assistente di ricerca presso il Laboratorio Human-Centered Robotics (HCR) delle Mines.

Sessione CS (Estate 2020)

Durante l’estate del 2020, tra il completamento di CSCI473 e l’ingresso nel Laboratorio HCR, ho seguito CSCI370 o “Ingegneria del Software Avanzata” come parte del mio programma di laurea in Informatica al Colorado School of Mines. CSCI370 è un corso che fa progettare, implementare e documentare soluzioni software per un’azienda. Permette agli studenti di applicare le conoscenze del corso a problemi di informatica nel mondo reale. Puoi saperne di più sul corso qui.

Nel corso, si decide quale progetto/azienda si desidera seguire. Il corso forniva PDF che descrivevano ogni progetto e azienda. Alla fine ho deciso di lavorare su un progetto proposto da un’azienda chiamata Lunar Outpost intitolato “Real Time Wheel Slip Detection and Error Corrections for Enhanced Lunar Navigation”. Poiché il nome è lungo, diamo al progetto un alias: “Rilevamento dello slittamento delle ruote”.

Il problema

Lunar Outpost è una startup che cerca di creare rover lunari autonomi. Sulla Luna, c’è molta polvere lunare che è nota per causare molto slittamento delle ruote. Questo non è ideale perché lo slittamento delle ruote può causare la perdita della posizione reale da parte dei sistemi autonomi. Sulla Terra, questo viene risolto usando i dati GPS per correggere qualsiasi scostamento causato dallo slittamento delle ruote. Ma il problema con il GPS è che funziona solo grazie alla presenza di 30+ satelliti di navigazione che orbitano costantemente intorno alla Terra e trasmettono segnali unici che permettono ai computer di calcolare la loro posizione. Ma sulla Luna, attualmente non esiste qualcosa come il GPS. Sapendo ciò, deve essere usato un metodo diverso dal GPS per rilevare lo slittamento delle ruote. Un rapporto più dettagliato sul problema del progetto può essere visualizzato qui.

Il team

Questo progetto non era semplice, quindi doveva essere realizzato in team. Il team era composto da cinque studenti del Colorado School of Mines:

Questo progetto non era semplice, quindi doveva essere realizzato in team. Questo team era composto da Mehmet Yilmaz (me), Kane Bruce, Braedon O’Callaghan, Liam Williams e Kevin Grant.

Il progetto ci ha richiesto conoscenze di ROS, C++, Python, Linux, Raspberry Pi e Arduino. La maggior parte di noi aveva esperienza in una o più di queste tecnologie, ma ero l’unico con esperienza in ROS poiché avevo usato ROS nel mio corso Human Centered Robotics (CSCI473) durante il semestre di primavera del 2020. Per questo motivo, all’inizio, ho aiutato a portare tutti al livello necessario su ROS e su come sviluppare per esso.

Sfide

In questo progetto ci sono state molte sfide. Ma la sfida più grande che abbiamo affrontato è stata non avere accesso a un robot del mondo reale per i test. Questo è stato dovuto al COVID che ha reso tutto remoto e ci ha impedito di lavorare nei laboratori/edifici di Lunar Outpost. A causa di ciò, abbiamo dovuto usare simulazioni.

Inoltre, abbiamo esaminato alcune ricerche accademiche del Laboratorio di Navigazione WVU per avere un’idea di come il problema dello slittamento delle ruote potesse essere risolto per il caso d’uso di Lunar Outpost, il che per noi, come studenti del secondo e del terzo anno universitario, è stato più difficile di quanto ci aspettassimo.

Un’altra sfida che abbiamo affrontato è stata la quantità di tempo a nostra disposizione per lavorare su questo progetto. CSCI370 è un corso di un mese. Ma il problema in sé è un problema enorme che molte aziende e accademici cercano di risolvere/perfezionare da decenni. Quindi un mese è tutt’altro che sufficiente per risolvere questa questione. Ma, nonostante tutte queste sfide, abbiamo perseverato e ci siamo assicurati di consegnare.

Conclusione

Dopo aver svolto tutte le ricerche e lo sviluppo, abbiamo determinato che è quasi impossibile simulare correttamente la fisica della luna digitalmente, quindi provare realmente questo algoritmo in una simulazione non è utile e non porterà a ricerche significative sulla rilevazione dello slittamento delle ruote nello spazio e sulla luna. Abbiamo concluso che allestire un ambiente di prova adeguato usando qualcosa come sabbia e hardware reale, come un robot Husky, è molto più importante per questo tipo di ricerca. Abbiamo aggiornato il codice di rilevazione dello slittamento delle ruote per funzionare come un nodo ROS e ha funzionato correttamente, potendo essere facilmente importato in hardware reale per i test. Questo progetto mi ha permesso di assumere un ruolo di leadership, educare i miei colleghi sullo sviluppo ROS e acquisire esperienza con Python, ROS e Gazebo affrontando un problema complesso che non avevo mai incontrato prima. Soprattutto, questa esperienza ha ulteriormente consolidato la mia passione per la robotica e ha rafforzato il mio desiderio di perseguire la ricerca nel campo, preparando il terreno per ciò che sarebbe venuto dopo nel mio percorso nella robotica.

Inizio nel Laboratorio HCR

Dopo aver completato CSCI473, la mia CS Field Session nell’estate del 2020 e il mio semestre autunnale 2020, ho deciso di intraprendere la ricerca in robotica. Ho avuto esperienze così positive sia con CSCI473 che con la CS Field Session che ho deciso di voler fare ricerca per il Laboratorio HCR. Poiché avevo incontrato il Dr. Zhang l’anno precedente, ho deciso di scrivergli un’email e chiedere di eventuali opportunità che il laboratorio potesse avere a gennaio 2021. In circa 2 settimane, il Dr. Zhang ha espresso interesse, mi ha presentato opzioni di ricerca e mi ha offerto un ruolo nel laboratorio. Ho quindi iniziato a lavorare per il laboratorio a febbraio 2021.

Video di Introduzione

Ecco il mio video di introduzione che ho registrato alcuni mesi dopo il mio ingresso nel Laboratorio HCR. È stato registrato a maggio 2021 e copre la ricerca su cui mi sarei concentrato nel Laboratorio HCR durante l’estate del 2021:

Il mio progetto

Durante il mio periodo nel Laboratorio HCR, mi sono concentrato principalmente sul progetto Triton. Il progetto Triton è un robot mobile sviluppato dal Human Centered Robotics Lab presso il Colorado School of Mines. È un robot terrestre triangolare con ruote omni alimentato dal Jetson Nano di NVIDIA.

Il Triton, in una panoramica semplice, era composto dalle seguenti parti:

• NVIDIA Jetson Nano
• Scheda carrier Seed Studio A205 di NVIDIA
• Arduino Mega
• Scheda Micro SD da 64 GB
• Scocca personalizzata stampata in 3D
• 3 ruote mecanum
• 1 batteria AR
• Circuiti personalizzati per la distribuzione di potenza e il cablaggio ottimizzati
• Telecamera Intel Realsense D435
• Alcuni LED

È stato progettato, costruito e prodotto intorno al 2018-2020 come robot a scopo didattico. Quando sono entrato, il Triton era abbastanza consolidato e il laboratorio stava considerando di realizzare una nuova versione. Tuttavia, il problema principale del Triton era il suo software. Il Triton poteva muoversi, ricaricarsi e funzionare in modo basilare ma non faceva nulla di realmente intelligente. Mancava persino della capacità di eseguire movimenti più avanzati.

Per iniziare ad affrontare questo problema, il laboratorio ha allestito un’area in cui potevamo tenere traccia del Triton. Per farlo, hanno creato un’area di 2 metri per 2 metri con 8 telecamere Optitrack Flex (infrarosse rosse) disposte a forma di quadrato a circa 6-7 piedi dal pavimento.

Oltre ad aver costruito quest’area, ogni Triton aveva tre sfere grigie attaccate sulla parte superiore della scocca.

Con questa configurazione, avevamo effettivamente costruito il nostro piccolo sistema GPS che ci permetteva di ottenere le coordinate esatte in metri di un Triton nella nostra area di interesse. Utilizzando le telecamere a infrarossi Optitrack e le sfere grigie Optitrack a forma triangolare, potevamo individuare le coordinate esatte di un Triton nella nostra area. Questo ci ha permesso di applicare un sistema a ciclo chiuso per una maggiore precisione nel movimento.

Il sistema Optitrack forniva dati di posizione e orientamento a circa 120Hz con accuratezza sub-millimetrica quando calibrato correttamente. I tre marcatori riflettenti di ogni Triton formavano un pattern triangolare unico che il sistema poteva tracciare come un corpo rigido. Il sistema di coordinate era calibrato in modo che (0,0) fosse al centro dell’area di tracciamento, con assi X e Y allineati alla geometria della stanza. Ma nonostante questi dati di posizionamento precisi, il Triton aveva ancora difficoltà nel movimento.

Con questa configurazione, una funzionalità chiave che volevamo fornire al Triton era la capacità di muoversi verso una coordinata specifica. L’utente, o il loro software, poteva fornire una coordinata (x, y) all’interno della propria area di interesse. Poi il robot si sarebbe mosso verso quella coordinata nel modo più veloce, accurato e fluido possibile. Quando sono arrivato, questa funzionalità esisteva ma non funzionava molto bene. Ecco una semplice animazione che mostra come funzionava la logica di movimento originale:

Non ho registrato la soluzione originale in azione, quindi ho creato questa semplice animazione che mostra la vecchia logica di movimento in azione. Sapendo questo, quali sono i problemi con questo metodo?

1. È davvero lento
2. Fa sì che il robot occupi molto spazio solo per raggiungere un punto specifico. Questo rendeva difficile utilizzare questa soluzione quando più Triton si muovevano contemporaneamente.

Quindi perché si verificava questo comportamento? Il problema era che il Triton prima ruotava, cambiando il suo alpha, finché non puntava verso il punto di destinazione entro un margine di errore specifico. Poi sprintava in avanti, e dopo che il suo theta era fuori dal target di una certa quantità, si fermava e ricominciava a ruotare finché l’alpha non era all’interno dell’intervallo accettabile per l’obiettivo target. Poi sprintava di nuovo e continuava così fino a raggiungere il punto. Inoltre, man mano che si avvicinava sempre più al punto obiettivo, la velocità di rotazione e di sprint diminuiva molto per assicurarsi di non oltrepassare il bersaglio. Questo risultava in un movimento innaturale del Triton, che impiegava un’eternità per raggiungere un punto obiettivo e richiedeva così tanto spazio solo per arrivare a un punto specifico. Quindi, con tutti questi problemi, e dato quanto fosse essenziale questa funzionalità per lo sviluppo del progetto Triton, quando ho iniziato a lavorare al Laboratorio HCR, il mio primo compito è stato sviluppare soluzioni più efficaci che permettessero al Triton di navigare meglio verso un punto obiettivo.

Sapendo questo, ho passato molto tempo a fare ricerche sul modo migliore possibile per affrontare questo problema. Ironia della sorte, stavo seguendo un corso chiamato Introduzione ai Sistemi di Controllo a Feedback (EENG307) a Mines. All’inizio di quel corso, abbiamo imparato il concetto di controllori ad anello aperto e controllori ad anello chiuso. Sapendo questo, e dopo alcune discussioni che ho avuto con il professore di quel corso e il mio intelligente coinquilino, è diventato chiaro che l’obiettivo di far arrivare il Triton a un punto obiettivo era un problema di sistema a ciclo chiuso.

Ora, dopo ampi test e ricerche, ho sviluppato due approcci distinti di controller per i Triton:

Metodo 1: Controllore Distanza-Theta

Questo approccio utilizzava due controllori proporzionali separati che giravano simultaneamente:

• Controllore di Distanza: Calcolava la distanza euclidea dall’obiettivo e applicava un guadagno proporzionale per determinare la velocità avanti/indietro
• Controllore Theta: Calcolava l’errore angolare tra l’orientamento attuale del robot e l’orientamento desiderato verso l’obiettivo, applicando un guadagno proporzionale separato per la velocità di rotazione

L’algoritmo calcolava continuamente la distanza euclidea dall’obiettivo e l’errore angolare tra l’orientamento corrente del robot e la direzione desiderata. Venivano applicati due guadagni proporzionali separati per generare rispettivamente velocità lineari e angolari.

Questo ha fatto sì che il Triton ruotasse naturalmente verso l’obiettivo muovendosi contemporaneamente in avanti, creando traiettorie curve e fluide. Il vantaggio principale era che il robot manteneva sempre il lato frontale orientato verso la destinazione, cosa cruciale per applicazioni basate su telecamera.

Metodo 2: Controller delle Coordinate X-Y

Questo approccio trattava il robot come un plotter 2D, con controllo indipendente del movimento X e Y:

• Controllore X: Ha controllato direttamente il movimento est-ovest basato sull’errore della coordinata X
• Controllore Y: Ha controllato direttamente il movimento nord-sud basato sull’errore della coordinata Y

L’implementazione calcolava gli errori delle coordinate X e Y in modo indipendente, applicava guadagni proporzionali separati, e poi trasformava questi componenti di velocità globali nel sistema di coordinate locale del robot usando matrici di rotazione. Questa trasformazione era necessaria perché il gruppo di ruote omni del robot richiedeva velocità nel proprio sistema di riferimento, non in coordinate globali. Questo metodo produceva i percorsi più diretti verso gli obiettivi ed era significativamente più veloce, ma la direzione del robot tendeva a deviare poiché non c’era un controllo esplicito dell’orientamento.

Per il metodo n.1, sono entrato in dettaglio completo su questo metodo nel mio Muovi la Tartaruga (TurtleSim) - blog. Ti consiglio vivamente di leggere questo blog per ottenere tutti i dettagli su come funzionano i controller PID in generale, così come su come funziona il metodo n.1. Ho sviluppato il metodo n.1 usando TurtleSim di ROS, poi ho trasferito quel codice sul Triton e l’ho aggiornato per tener conto di un ambiente più reale.

Il Metodo n.2 utilizzava un approccio abbastanza diverso ma ugualmente efficace. Invece di pensare all’orientamento del robot e alla distanza dall’obiettivo, questo metodo tratta il movimento come un problema su un piano di coordinate. Il controllore calcola continuamente l’errore sia nella direzione X che in quella Y separatamente. Per esempio, se il robot deve muoversi da (0,0) a (2,3), lo vede come la necessità di correggere un errore di 2 metri in X e un errore di 3 metri in Y. Due controller proporzionali funzionavano simultaneamente: uno regolava la velocità del robot nella direzione X basandosi sull’errore X, mentre l’altro gestiva il movimento nella direzione Y basandosi sull’errore Y. Questo creava un percorso più diretto verso l’obiettivo, simile a come si muove la testa di una stampante 3D, e permetteva movimenti diagonali fluidi. Il robot non aveva bisogno di girarsi esplicitamente per affrontare il suo obiettivo, rendendo questo metodo particolarmente efficace in spazi ristretti o quando è richiesta unposizionamento preciso.

Entrambi i metodi si sono dimostrati significativamente più veloci e più affidabili rispetto all’approccio originale. Per vedere questi nuovi metodi in azione, dai un’occhiata alla Playlist Tritons in azione, che mostra tutti i Triton in azione con i nuovi metodi.

Ciò che una volta richiedeva 30-45 secondi per un semplice movimento punto-punto ora richiedeva circa 8-12 secondi. Ancora più importante, il Triton poteva ora navigare più efficacemente in spazi ristretti, cosa che si è rivelata utile per i nostri scenari multi-robot.

Sfide di sviluppo e risoluzione dei problemi

Implementare questi controller non è stato semplice e ha comportato diverse sfide significative di debugging:

Trasformazioni del sistema di coordinate: Uno degli aspetti più insidiosi è stato ottenere correttamente le trasformazioni delle coordinate. Il sistema Optitrack forniva dati nel proprio sistema di coordinate, il robot aveva il suo sistema di coordinate locale, e dovevo convertire con precisione tra di essi. Le prime implementazioni avevano robot che si muovevano nella direzione sbagliata perché avevo confuso i calcoli delle matrici di rotazione.

Comportamento nel mondo reale vs. ideale: La sfida più grande è stata tenere conto dei fattori del mondo reale che non compaiono nella teoria del controllo dei libri di testo. Le ruote del robot avevano caratteristiche di attrito diverse, i motori non rispondevano in modo identico, e c’era sempre una certa latenza nella catena di comunicazione da Optitrack al software di controllo fino all’Arduino del robot. Ho passato settimane a sintonizzare i guadagni proporzionali e ad aggiungere filtri di deadband per tenere conto di queste realtà fisiche.

Problemi di oscillazione e stabilità: Le mie prime implementazioni soffrivano di problemi di oscillazione in cui i robot sorpassavano i loro obiettivi e vacillavano avanti e indietro. Questo mi ha insegnato l’importanza dei termini derivativi nei controller PID e la necessità di una corretta messa a punto dei guadagni. Alla fine ho optato per un controllo prevalentemente proporzionale con guadagni accuratamente tarati piuttosto che un PID completo, poiché l’ammortizzazione intrinseca del sistema era sufficiente per la maggior parte delle applicazioni.

Interferenze tra più robot: Quando più robot operavano simultaneamente, ho scoperto pattern di interferenza inaspettati. A volte i robot “litigavano” per lo stesso spazio o creavano situazioni di stallo in cui si bloccavano a vicenda indefinitamente. Questo mi ha portato a implementare meccanismi di coordinazione e algoritmi di evitamento collisioni.

Sistema di Controllo Multi-Triton

Una volta risolto il problema del movimento di un singolo Triton, la sfida successiva del laboratorio è stata far lavorare insieme più Triton simultaneamente. Questo è diventato uno dei miei principali ambiti di interesse e si è rivelato un contributo significativo al progetto.

Il sistema originale poteva controllare solo un Triton alla volta, il che limitava fortemente le possibilità di ricerca. Il laboratorio voleva simulare scenari in cui più veicoli autonomi dovevano coordinare i loro movimenti, come auto a guida autonoma che comunicano tra loro per ottimizzare il flusso del traffico e creare mappe SLAM (Localizzazione e Mappatura Simultanee) migliori.

Per risolvere questo, ho implementato un approccio di multiprocessing usando la libreria multiprocessing di Python. Ogni Triton ha avuto il proprio processo dedicato che poteva girare in modo indipendente pur essendo coordinato da un sistema di controllo centrale. Questo ha permesso a più Triton di muoversi simultaneamente senza interferire con i loop di controllo l’uno dell’altro.

Progettazione dell’Architettura Multi-Robot

L’architettura del sistema che ho sviluppato consisteva di diversi componenti chiave:

Processo del Controller Principale: Questo serviva come coordinatore centrale, gestendo le interazioni con l’interfaccia utente, la pianificazione dei percorsi e il coordinamento ad alto livello tra i robot. Manteneva lo stato globale e distribuiva i comandi ai processi dei singoli robot.

Processi Robot Individuali: Ogni Triton aveva il proprio processo Python dedicato che gestiva:

• Calcoli di controllo PID in tempo reale a ~50Hz
• Comunicazione con l’hardware del robot (Arduino/Jetson)
• Esecuzione del percorso locale e evitamento ostacoli
• Segnalazione dello stato al controller principale

Comunicazione tramite Memoria Condivisa: Ho usato gli oggetti multiprocessing.shared_memory e Queue di Python per abilitare una comunicazione efficiente tra i processi. Questo permetteva il coordinamento in tempo reale senza l’overhead della comunicazione di rete.

Meccanismi di Sincronizzazione: Per prevenire conflitti quando più robot dovevano coordinarsi (come evitare collisioni), ho implementato semafori e lock che permettevano ai robot di richiedere accesso esclusivo a certe aree dello spazio di lavoro.

La sfida è stata garantire che tutti i robot potessero operare i loro loop di controllo in modo indipendente mantenendo comunque la coordinazione globale. Ogni processo robotico eseguiva i propri calcoli PID e inviava comandi ai motori direttamente all’hardware, mentre il processo principale gestiva il coordinamento di livello superiore come l’evitamento delle collisioni e la pianificazione dei percorsi.

Il sistema multi-Triton ha aperto nuove possibilità di ricerca. Ora potevamo simulare:

• Scenari di comunicazione veicolo-vehicle
• Pianificazione di percorsi coordinati con evitamento ostacoli
• Comportamenti di robotica swarm
• Mappatura SLAM multi-agente
• Controllo di formazione e comportamenti di inseguimento

Ecco come appariva l’allestimento del laboratorio con più Triton in esecuzione simultanea:

Ho anche sviluppato un’interfaccia user-friendly che permetteva ai ricercatori di definire visivamente i percorsi per ogni Triton. Potevi letteralmente disegnare il percorso che volevi che ogni robot seguisse, e loro eseguivano questi percorsi con perfetta coordinazione. Questo è stato incredibilmente utile per impostare esperimenti complessi senza dover codificare manualmente ogni movimento.

Il sistema poteva gestire fino a 5 Triton simultaneamente, ognuno eseguendo i propri controller PID mentre veniva coordinato attraverso il sistema di controllo centrale. Le prestazioni erano impressionanti, con tutti i robot che mantenevano la loro precisione individuale mentre lavoravano insieme come una squadra.

Ecco una playlist che mostra i Triton in azione, dal controllo di un singolo robot alla coordinazione multi-robot: Playlist Tritons in azione

Integrazione del Sensore di Profondità e Correzione delle Coordinate

Un altro importante avanzamento su cui ho lavorato ha riguardato l’utilizzo delle telecamere di profondità Intel RealSense D435 montate su ciascun Triton. Mentre il sistema Optitrack ci forniva dati di posizionamento incredibilmente precisi, volevo esplorare come i robot potessero usare i loro sensori a bordo per migliorare la consapevolezza spaziale e correggere errori di coordinate.

L’idea era che i Triton potessero usare i loro sensori di profondità per rilevare altri Triton nelle loro vicinanze e incrociare le loro posizioni. Questo avrebbe servito a più scopi:

1. Correzione degli Errori: Se il sistema Optitrack avesse avuto qualche deriva di calibrazione o un’occlusione temporanea, i robot potrebbero usare la conferma visiva delle posizioni reciproche per mantenere sistemi di coordinate accurati.

2. SLAM Potenziato: Avendo più robot con sensori di profondità che lavorano insieme, avremmo potuto creare mappe dell’ambiente molto più ricche con punti dati ridondanti.

3. Evitamento delle Collisioni: Il rilevamento della profondità in tempo reale avrebbe permesso ai robot di rilevare ed evitare tra loro anche se il sistema di controllo centrale avesse avuto ritardi di comunicazione.

Ho iniziato a sperimentare algoritmi che avrebbero permesso ai Triton di:

• Rilevare altri Triton usando la loro caratteristica forma triangolare e i marcatori a sfera riflettente
• Calcolare posizioni relative e orientamenti usando i dati di profondità
• Confrontare queste misurazioni con i dati di Optitrack per identificare discrepanze
• Potenzialmente aggiustare il loro sistema di coordinate in tempo reale per mantenere l’accuratezza

Esperimenti di Visione Artificiale

Ho passato molto tempo a sperimentare una pipeline di visione artificiale che funzionava in diverse fasi:

Elaborazione dei Dati di Profondità: L’Intel RealSense D435 forniva sia flussi di dati RGB che di profondità. Ho lavorato principalmente con i dati di profondità, che arrivavano come un array 640x480 di misurazioni di distanza a 30Hz. La prima sfida è stata filtrare questi dati di profondità rumorosi per estrarre informazioni geometriche significative.

Tentativi di Rilevamento degli Oggetti: Ho sperimentato algoritmi di rilevamento a più fasi. Ho avuto qualche successo nel segmentare l’immagine di profondità per identificare oggetti a livello del pavimento (filtrando fuori pareti, soffitto, ecc.) e cercando oggetti con le giuste caratteristiche dimensionali, grossomodo un’impronta di 0,3x0,3 metri. Ho provato a usare il rilevamento dei bordi e l’analisi geometrica per identificare il profilo caratteristico del Triton, con risultati disparati.

Esperimenti di Riconoscimento dei Marcatori: Le tre sfere riflettenti su ciascun Triton sembravano la caratteristica di rilevamento più promettente. Ho sperimentato algoritmi di blob detection per identificare il pattern triangolare caratteristico di tre punti luminosi nell’immagine di profondità. Ho ottenuto risultati promettenti in condizioni di illuminazione controllata, anche se non erano costantemente affidabili.

Ricerca sulla Fusione delle Coordinate: Ho ricercato approcci per fondere le stime di posizione basate sulla visione con i dati di Optitrack, incluse implementazioni base del filtro di Kalman. Il concetto era dare più peso ai dati di Optitrack quando disponibili ma ricorrere alla visione quando necessario, anche se non sono riuscito a portare questo completamente funzionante prima della fine della mia permanenza nel laboratorio.

Sfide di Prestazioni: Far girare tutto questo processamento in tempo reale insieme ai loop di controllo del robot si è rivelato impegnativo. Ho sperimentato approcci di ottimizzazione per eseguire gli algoritmi a circa 10-15Hz senza sovraccaricare le capacità di elaborazione del Jetson Nano.

Purtroppo ho dovuto lasciare il laboratorio prima di poter completare appieno questo lavoro di visione artificiale. Sebbene avessi alcuni risultati iniziali promettenti e avessi imparato molto sull’elaborazione dei sensori di profondità, non sono riuscito a portare il sistema a uno stato completamente affidabile. È rimasta una direzione di ricerca interessante su cui altri potrebbero eventualmente costruire.

Ecco un video di me che testo gli algoritmi di visione artificiale:

Ecco come appariva la vista del sensore di profondità durante i miei esperimenti:

Sebbene non abbia completato l’integrazione del sensore di profondità, il concetto mostrava potenziale per applicazioni come la simulazione di scenari per auto a guida autonoma, dove i veicoli devono essere consapevoli l’uno dell’altro senza fare affidamento esclusivo su infrastrutture esterne. La direzione di ricerca che ho iniziato a esplorare potrebbe contribuire a lavori futuri nel laboratorio.

Documentazione e Conservazione della Conoscenza

Uno dei miei contributi più importanti al HCR Lab, e forse quello di cui sono più orgoglioso, è stato organizzare e preservare tutta la documentazione del progetto. Quando sono entrato nel laboratorio, la conoscenza del progetto Triton era dispersa su più piattaforme e formati. Informazioni critiche erano sparse tra:

• Vari account Google Drive appartenenti a diversi studenti che si erano laureati
• Vecchie email sepolte nelle caselle di posta
• Cartelle Dropbox casuali
• Molti repository GitHub
• Repository GitLab con organizzazione incoerente
• Note scritte a mano che solo alcune persone riuscivano a interpretare

Questa documentazione frammentata era un grosso problema. I nuovi studenti passavano settimane solo cercando di capire come iniziare, e conoscenze preziose venivano costantemente perse quando le persone si laureavano o lasciavano il laboratorio.

Mi sono preso la responsabilità di risolvere sistematicamente questo problema. Ho passato innumerevoli ore a rintracciare ogni pezzo di documentazione, codice, video e appunto relativo al progetto Triton. Poi ho organizzato tutto in un repository GitLab centralizzato con una struttura chiara e logica.

La documentazione centralizzata includeva:

• Guide alla Costruzione: Istruzioni passo-passo per assemblare i Triton da zero
• Configurazione Software: Guide complete per configurare l’ambiente di sviluppo
• Documentazione del Codice: Codice ben commentato con spiegazioni chiare
• Specifiche Hardware: Liste dettagliate dei componenti, schemi dei cablaggi e progetti PCB
• Guide alla Risoluzione dei Problemi: Problemi comuni e relative soluzioni
• Tutorial Video: Ho creato e caricato video istruttivi su YouTube, inclusi tutorial dettagliati sulla calibrazione di Optitrack:

Ho anche stabilito standard di documentazione per garantire che i contributi futuri fossero organizzati e accessibili. La struttura del repository che ho creato è diventata la base per tutto il lavoro successivo nel laboratorio.

Oltre a organizzare la documentazione esistente, ho creato diverse guide e tutorial originali che hanno colmato lacune critiche nella base di conoscenza. Questi includevano istruzioni dettagliate per i nuovi membri del laboratorio, guide complete alla risoluzione dei problemi e walkthrough video di procedure complesse.

L’impatto è stato immediato e duraturo. I nuovi studenti potevano raggiungere produttività in giorni anziché settimane. Il repository di documentazione che ho creato è ancora utilizzato dal laboratorio oggi, anni dopo la mia partenza. È diventato la singola fonte di verità per il progetto Triton e ha fatto risparmiare innumerevoli ore/giorni ai ricercatori futuri.

Mentoring e Trasferimento della Conoscenza

Uno degli aspetti più gratificanti del mio periodo al HCR Lab è stata l’opportunità di fare da mentore ad altri e condividere le conoscenze che avevo acquisito. Man mano che il mio lavoro progrediva e diventavo più esperto con i sistemi Triton, ho assunto crescenti responsabilità nella formazione dei nuovi membri del team.

Mentoring dei Successori nel Laboratorio

Mentre mi preparavo a lasciare il laboratorio per concentrarmi sul completamento della mia laurea e sul mio lavoro a eBay, mi sono assicurato di formare approfonditamente due persone che avrebbero preso in carico il progetto Triton dopo la mia partenza. Non si trattava solo di mostrare loro come funzionavano le cose, ma di assicurarmi che comprendessero veramente i principi sottostanti in modo da poter continuare a innovare.

Ho passato settimane lavorando a stretto contatto con loro, andando attraverso:

• Le basi matematiche dei sistemi di controllo PID
• L’architettura multiprocesso per il coordinamento di più robot
• L’integrazione del sensore di profondità e gli algoritmi di visione artificiale
• Il sistema di documentazione e come mantenerlo
• Tecniche di debug e modalità di guasto comuni

Il trasferimento della conoscenza è stato incredibilmente approfondito. Abbiamo affrontato insieme sessioni di debugging reali, li ho fatti modificare ed estendere il codice esistente, e mi sono assicurato che potessero impostare in modo indipendente nuovi Triton da zero.

Programma di Mentoring per Studenti delle Superiori

Forse ancora più gratificante è stata la mia esperienza di mentor per una studentessa delle superiori tramite il programma di outreach del laboratorio. È stata una grande opportunità per introdurre qualcuno alla robotica, all’informatica e alla ricerca in una fase formativa della sua istruzione.

Ho progettato un curriculum completo che comprendeva:

Fondamenti di Informatica:

• Concetti di programmazione usando Python come linguaggio principale
• Introduzione alla programmazione orientata agli oggetti
• Comprensione di algoritmi e strutture dati

Concetti di Robotica:

• Come funzionano i sensori e come interfacciarsi con essi
• Controllo degli attuatori e sistemi di motori
• Nozioni di base sui sistemi autonomi e sul controllo in retroazione

ROS (Robot Operating System):

• Comprendere il sistema di messaggistica publish/subscribe
• Creare nodi e servizi
• Lavorare con file di launch e server di parametri

Lavoro su Progetto Pratico:

• Abbiamo collaborato alla creazione di un servizio ROS che controllava il sistema LED sulla testa del Triton
• Ha imparato a scrivere codice pulito e documentato che si integrasse con i nostri sistemi esistenti
• Il servizio di controllo LED che ha creato è diventato una parte permanente del codebase del Triton

Ciò che ha reso questo mentoring particolarmente speciale è stato vederla passare dal sapere praticamente nulla sulla programmazione al contribuire con codice significativo a un progetto di ricerca attivo. È passata dal chiedere “Cos’è una variabile?” a fare debug autonomo dei problemi di comunicazione ROS e a scrivere le proprie implementazioni di servizi.

Il sistema di controllo dei LED che ha sviluppato ha permesso ai ricercatori di cambiare facilmente colori e pattern dei LED sulla testa del Triton tramite semplici comandi ROS. Questo potrebbe sembrare semplice, ma ha richiesto la comprensione dell’architettura ROS, dell’interfacciamento hardware e dei corretti pattern di progettazione del software. Il suo contributo è ancora utilizzato nel laboratorio oggi.

Il tutorato è stato istruttivo per me tanto quanto lo è stato per lei. Mi ha costretto a scomporre concetti complessi in parti digeribili e a riflettere davvero sui fondamenti di ciò che stavamo facendo. Insegnare a qualcun altro mi ha reso un ingegnere e ricercatore migliore.

Collaborazione con la ricerca di dottorato

Uno degli aspetti più gratificanti dal punto di vista professionale del mio periodo nel laboratorio è stato lavorare a stretto contatto con Peng, uno studente di dottorato la cui ricerca si concentrava sugli algoritmi per auto a guida autonoma. I miglioramenti software che avevo apportato al sistema Triton hanno aiutato a supportare la sua ricerca di dottorato.

La ricerca di Peng richiedeva un coordinamento multi-robot preciso e affidabile per simulare scenari di auto a guida autonoma. Prima dei miei miglioramenti al controllo del movimento e ai sistemi multi-robot, questi esperimenti erano molto più difficili da condurre. I robot erano più lenti, meno precisi e non riuscivano a lavorare insieme in modo altrettanto efficace.

I miei contributi hanno aiutato la ricerca di Peng in diversi ambiti:

Studi sulla gestione delle intersezioni: Con i controllori PID migliorati e il coordinamento multi-robot, Peng ha potuto simulare scenari di intersezioni in cui più “veicoli” (Triton) dovevano coordinare i loro spostamenti. Il miglior timing e posizionamento ha reso questi studi più fattibili.

Comunicazione tra veicoli: Il framework di multi-processing che ho sviluppato ha permesso a Peng di implementare e testare protocolli di comunicazione tra veicoli simulati. Ogni Triton poteva prendere decisioni pur coordinandosi con gli altri, in modo simile a come potrebbero operare le auto a guida autonoma.

Ricerca su SLAM e mappatura: Il lavoro di integrazione del sensore di profondità ha fornito a Peng dati aggiuntivi per la sua ricerca sulla localizzazione e mappatura simultanee. Avere più robot con capacità di sensing coordinate ha permesso esperimenti di mappatura più completi.

Ciò che ha reso particolarmente preziosa la nostra collaborazione è che non si è trattato solo di me che aiutavo la sua ricerca, ma di una vera partnership. La comprensione degli aspetti teorici dei veicoli autonomi da parte di Peng ha contribuito a informare le mie implementazioni pratiche. Il suo feedback e i suoi requisiti mi hanno spinto a rendere i sistemi più robusti e capaci.

Abbiamo trascorso molte ore insieme in laboratorio, debugando scenari, discutendo diverse strategie di controllo ed esplorando cosa la piattaforma Triton potesse realizzare. Peng è diventato sia un collega che un amico, e lavorare con lui mi ha insegnato molto su come funziona realmente la ricerca accademica.

I sistemi che ho costruito sono diventati una parte utile del lavoro di tesi di Peng. Vedere i miei contributi di ingegneria pratica supportare la ricerca nella tecnologia dei veicoli autonomi è stato davvero appagante. Ha rafforzato il mio interesse nel modo in cui una solida ingegneria e la ricerca possono lavorare insieme per creare risultati utili.

Anche dopo aver lasciato il laboratorio, Peng ed io siamo rimasti in contatto. Sapere che il mio lavoro continuava a contribuire a ricerche importanti anche dopo la mia partenza è stato estremamente gratificante.

Prospettiva: L’era pre-LLM dello sviluppo

Vale la pena notare che tutto questo lavoro è stato realizzato durante l’era pre-LLM dello sviluppo software. Tutto ciò è avvenuto tra il 2020 e il 2021 (principalmente nel 2021), prima che ChatGPT, Claude, Perplexity o strumenti di sviluppo potenziati dall’IA come Cursor IDE esistessero.

Ogni riga di codice è stata scritta da zero, ogni algoritmo è stato studiato attraverso articoli accademici e libri di testo, e ogni sessione di debug ha coinvolto metodi tradizionali come istruzioni di stampa, debugger e test metodici. Quando rimanevo bloccato su una trasformazione di coordinate o sul tuning di un PID, non potevo semplicemente chiedere a un assistente IA di spiegare il concetto o aiutare a fare il debug del problema.

Questo ha reso il processo di sviluppo significativamente più impegnativo ma anche più istruttivo. Ho dovuto:

Ricercare tutto manualmente: Capire la teoria del controllo PID significava leggere libri di testo e articoli accademici. Capire le trasformazioni di coordinate richiedeva lavorare attraverso la matematica a mano. Ogni concetto doveva essere compreso a fondo prima dell’implementazione.

Fare debug senza assistenza IA: Quando i robot si muovevano in direzioni inattese o oscillavano attorno agli obiettivi, dovevo tracciare metodicamente la logica, aggiungere output di debug e testare le ipotesi una per una. Non c’era un’IA che potesse suggerire problemi potenziali o aiutare a interpretare i pattern di errore.

Imparare dai primi principi: Senza la possibilità di chiedere rapidamente “come implemento il multi-processing in Python per la robotica?”, ho dovuto capire profondamente i concetti sottostanti. Questo mi ha costretto a costruire una solida base nella programmazione concorrente, nei sistemi di controllo e nella visione artificiale.

La documentazione era critica: Poiché non potevo fare affidamento su un’IA per spiegare il codice in seguito, ho dovuto scrivere documentazione e commenti estremamente chiari. Questa disciplina si è rivelata inestimabile quando ho trasferito conoscenze ad altri.

Guardando indietro, sebbene gli strumenti di IA moderni avrebbero accelerato molti aspetti dello sviluppo, lavorare senza di essi mi ha costretto a sviluppare capacità di problem-solving più profonde e una comprensione più completa dei sistemi sottostanti. È affascinante pensare a quanto diverso sarebbe potuto essere questo progetto con gli strumenti di sviluppo di oggi disponibili.

La difficile decisione di lasciare

Per quanto amassi lavorare nell’HCR Lab, verso la fine del 2021 mi sono trovato di fronte a una decisione difficile che molti studenti affrontano: bilanciare molteplici opportunità e responsabilità. Lavoravo contemporaneamente a tempo pieno come software engineer presso eBay, stavo finendo la mia laurea in informatica a Mines e contribuivo alla ricerca all’HCR Lab.

L’opportunità da eBay era significativa; era il mio primo ruolo importante come ingegnere del software, mi ha fornito un’esperienza industriale preziosa e un reddito solido. Tuttavia, cercare di mantenere il lavoro a tempo pieno, completare la mia laurea e contribuire in modo significativo alla ricerca era semplicemente insostenibile. Qualcosa doveva cedere.

Quando parlai con il Dr. Zhang della possibilità di ridurre il carico di corsi per concentrarmi maggiormente sul lavoro in laboratorio, lui mi sconsigliò fermamente. Il suo ragionamento era sensato: completare la mia laurea doveva essere la priorità, e l’esperienza in azienda presso eBay sarebbe stata preziosa per il mio sviluppo professionale. Riteneva che abbandonare i corsi per concentrarsi sulla ricerca, sebbene allettante, potesse non essere la decisione migliore a lungo termine.

Quindi, nel settembre 2021, dopo circa 8 mesi di lavoro intensivo in laboratorio, presi la difficile decisione di ritirarmi dal mio ruolo di assistente di ricerca per concentrarmi sul completamento della laurea e sul mio lavoro a eBay. Fu una delle decisioni professionali più difficili che dovetti prendere all’epoca.

Anche dopo aver lasciato ufficialmente il laboratorio, continuai a fornire supporto ogni volta che qualcuno aveva bisogno dei sistemi che avevo costruito. Aggiornavo la documentazione quando necessario, rispondevo a domande sul debug e aiutavo a risolvere problemi da remoto. Le connessioni che avevo creato e l’investimento che avevo nel successo del progetto non scomparvero solo perché non facevo più ufficialmente parte del team.

Riflessioni e sguardo indietro

Ora, nel 2025, quattro anni dopo, mi ritrovo a riflettere su quel periodo con emozioni complesse. Il mio percorso professionale mi ha portato profondamente nello sviluppo web e nell’ingegneria AI/ML, aree che sono state incredibilmente gratificanti e che mi hanno offerto enormi opportunità di crescita e impatto.

Eppure c’è una parte di me che si chiede “e se”. La robotica è stata, e onestamente lo è ancora, la mia vera passione. C’è qualcosa nel lavorare con sistemi fisici, vedere il tuo codice tradursi in movimento e comportamento nel mondo reale, che lo sviluppo web e persino il lavoro sull’IA non riescono a replicare completamente.

A volte mi chiedo cosa sarebbe successo se avessi preso una strada diversa. E se avessi trovato un modo per restare nella ricerca sulla robotica? E se avessi proseguito gli studi con la laurea magistrale subito dopo aver terminato la laurea triennale? E se avessi scelto di dare priorità al lavoro di laboratorio rispetto all’esperienza in azienda?

Ma riconosco anche che ogni percorso ha i suoi compromessi. Le competenze che ho sviluppato nello sviluppo web e nell’AI sono state incredibilmente preziose. L’esperienza in azienda mi ha insegnato lo sviluppo software su larga scala, il design dell’esperienza utente e le sfide pratiche del costruire prodotti usati da milioni di persone. Queste esperienze mi hanno reso un ingegnere migliore nel complesso.

Il lavoro che ho svolto nell’HCR Lab continua a influenzare il mio approccio ai problemi oggi. Il pensiero sistematico richiesto dai sistemi di controllo PID riemerge nel modo in cui progetto loop di feedback nei sistemi software. Le capacità di documentazione e conservazione della conoscenza che ho sviluppato sono state inestimabili in ogni ruolo successivo. L’esperienza di mentorship e insegnamento ha plasmato il mio modo di lavorare con sviluppatori junior e di contribuire alla condivisione della conoscenza nel team.

Soprattutto, l’esperienza mi ha insegnato che prospero quando lavoro su problemi tecnici impegnativi che hanno un impatto nel mondo reale. Che si tratti di ottimizzare algoritmi di movimento per robot o costruire sistemi di IA che aiutino gli utenti a raggiungere i loro obiettivi, la soddisfazione deriva dal risolvere problemi difficili che hanno importanza.

L’impatto duraturo

Riflettendo sull’esperienza all’HCR Lab, sono colpito da quanto ho realizzato in un tempo relativamente breve. I sistemi che ho costruito hanno cambiato in modo fondamentale il funzionamento della piattaforma Triton, e molti di questi miglioramenti sono ancora utilizzati oggi. Il repository di documentazione che ho creato è diventato la base di conoscenza per l’intero progetto. Le relazioni di mentorship che ho instaurato hanno avuto un impatto duraturo sulle persone con cui ho lavorato.

Ma forse, cosa più significativa, l’esperienza mi ha mostrato di cosa sono capace quando lavoro su problemi per cui ho una vera passione. In quegli otto mesi, ho:

• Ho migliorato il sistema di controllo del movimento dei robot che stava limitando la piattaforma
• Ho costruito da zero un sistema di coordinamento tra più robot
• Ho integrato capacità di visione artificiale e fusione di sensori
• Ho creato un sistema completo di documentazione e gestione della conoscenza
• Ho fatto da mentore a diverse persone e ho aiutato nel trasferimento di conoscenze
• Ho supportato la ricerca a livello di dottorato sui veicoli autonomi

Non si trattava solo dei risultati tecnici, anche se quelli hanno avuto per me un significato importante. Si trattava di imparare che con perseveranza e pensiero sistematico si possono dare contributi utili anche come studente universitario.

Il futuro e la robotica

Sebbene la mia carriera mi abbia portato in altre direzioni, la mia passione per la robotica non si è affievolita. Seguo ancora gli sviluppi nel campo, sono entusiasta dei progressi nell’apprendimento robotico e nei sistemi autonomi, e ogni tanto lavoro a progetti robotici personali nel mio tempo libero.

Chi può dire cosa riserva il futuro? Le competenze che sto sviluppando nell’IA e nell’apprendimento automatico sono sempre più rilevanti per la robotica. L’esperienza nel settore che ho acquisito mi ha insegnato come costruire sistemi robusti e scalabili. Forse c’è un futuro in cui questi diversi fili della mia esperienza si uniranno in modi inaspettati.

Per ora, sono grato per il tempo trascorso nel Laboratorio HCR e per le esperienze che mi ha fornito. È stato un periodo formativo che ha plasmato sia le mie competenze tecniche sia la mia comprensione dei tipi di lavoro che trovo più appaganti. Anche se a volte mi manca, so che le lezioni che ho imparato e gli approcci che ho sviluppato continuano a influenzare tutto ciò che faccio.

I robot Triton sono ancora lì, continuano a servire i ricercatori e a permettere lavori importanti. E questo è davvero meraviglioso.