Capitolo della mia ricerca in robotica

Questo post racconta il mio percorso nella robotica, a partire dalla scoperta della mia passione per la robotica nell’FRC durante il liceo nel 2015 fino al mio periodo come assistente di ricerca presso il Colorado School of Mines’s Human Centered Robotics (HCR) Lab da febbraio 2021 a settembre 2021. Si noti che dalla fine del 2022, l’HCR Lab si è spostato dal Colorado School of Mines alla 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 2018. La mia laurea era in Informatica con un focus su Robotica e Sistemi Intelligenti. E mi sono laureato nella primavera 2022.

Sono stato fortunato a trovare presto la mia passione nella vita. Durante il liceo, ho dedicato molto tempo a capire cosa mi piacesse e in cosa potessi essere bravo. Dopo un po’ di tentativi ed errori, sono riuscito a capire che la mia passione era l’informatica. Ma fu anche in questo periodo che scoprii di avere questo travolgente amore per costruire attraverso il codice.

Al Mines, ho avuto l’opportunità di lavorare presso il Human Centered Robotics (HCR) Lab del Mines sotto la guida del Dr Hao Zhang. Ho incontrato per la prima volta il Dr. Zhang nella primavera 2020 durante il suo corso “Human Centered Robotics” (CSCI473), e dopo il caos del COVID e del lavoro del corso, sono riuscito a lavorare nel suo laboratorio all’inizio della primavera 2021.

Corso Human Centered Robotics (CSCI473)

Human Centered Robotics (CSCI473) del 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 soli tre progetti, ognuno dei quali presentava un problema impegnativo che introduceva i concetti fondamentali della robotica. Questi progetti consistevano in:

1. Apprendimento del Robot Operating System (ROS)
2. Reinforcement Learning per il Wall Following del Robot
3. Comprensione dei Comportamenti Umani da parte del Robot Usando Rappresentazioni Basate sullo Scheletro

Apprendimento del Robot Operating System (ROS)

Questo fu il primo progetto che ci venne assegnato. Il progetto consisteva in tre attività:

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

Per le attività 1 e 2, dovevamo semplicemente impostare il nostro ambiente di sviluppo e seguire un tutorial introduttivo su Gazebo. Questo includeva:

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

L’attività 3, invece, era una vera sfida. Il compito era usare turtlesim e far disegnare alla tartaruga il logo “M” del Mines:

Questo compito, sebbene sembrasse semplice, era più difficile di quanto apparisse. Questo progetto mi introdusse infine al concetto di sistemi ad Anello Aperto e ad Anello 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.

Reinforcement Learning per il Wall Following del Robot

Questo fu il secondo progetto che ci venne assegnato, ed era uno dei progetti più difficili su cui abbia mai lavorato al college. La descrizione del progetto era la seguente:

In questo progetto, gli studenti progetteranno e implementeranno algoritmi di reinforcement learning per insegnare a un robot mobile autonomo a seguire un muro ed evitare di urtare gli ostacoli. Gli studenti utilizzeranno la simulazione Gazebo in ROS Melodic per simulare un robot mobile omnidirezionale chiamato Triton, utilizzando una mappa dell’ambiente fornita. Gli studenti utilizzeranno uno scanner laser a distanza sul robot per eseguire il sensing e l’apprendimento, mentre il robot viene controllato tramite comandi di sterzata e velocità. Gli studenti sono tenuti a programmare questo progetto usando C++ o Python in ROS Melodic in esecuzione su Ubuntu 18.04 LTS (cioè lo stesso ambiente di sviluppo usato nel Progetto 1). Inoltre, gli studenti sono tenuti a scrivere un report seguendo il formato delle conferenze standard IEEE di robotica usando LATEX.

Per l’algoritmo di reinforcement learning, ci fu chiesto di usare Q-Learning. Usammo anche l’ambiente di simulazione Gazebo Stingray fornito dalla classe. Stingray consisteva nel modello Triton e nella logica fisica. Ci fu inoltre fornito un labirinto da far seguire al robot. Nel complesso, l’ambiente appariva così:

Non ho mai pubblicato la mia soluzione su GitHub o sul web perché non era molto buona e aveva molti difetti. Inoltre, far funzionare il codice nell’ambiente corretto è abbastanza difficile e fastidioso. Tuttavia, ho un video demo che ho consegnato alla classe, 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 del progetto era la seguente:

In questo progetto, gli studenti implementeranno diverse rappresentazioni basate sullo scheletro (Deliverable 1) e utilizzeranno Support Vector Machines (SVM) (Deliverable 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 report seguendo il formato delle conferenze standard IEEE di robotica usando LATEX nel Deliverable 3.

Questo progetto era impegnativo ma non tanto difficile quanto il secondo progetto. L’obiettivo principale era usare i dati del sensore Kinect V1, provenienti dal MSR Daily Activity 3D Dataset, e le Support Vector Machines per classificare determinate 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 di CSCI473

CSCI473 è uno dei migliori, se non il migliore, corsi che abbia seguito durante i miei studi universitari al Mines. Tutti questi progetti mi hanno insegnato molto e mi hanno permesso di avere un bel catalogo di progetti su cui riflettere e da citare nel mio curriculum. È stato anche il primo corso in cui mi sono sentito nel mio elemento, poiché non sono mai stato bravo nei test ma eccellevo nel portare a termine progetti. È stato anche grazie a questo corso che ho incontrato il Dr. Hao Zhang, che alla fine mi ha aiutato a ottenere una posizione come assistente di ricerca presso l’Human-Centered Robotics (HCR) Lab del Mines.

CS Field Session (Estate 2020)

Durante l’estate del 2020, tra il completamento di CSCI473 e l’ingresso nell’HCR Lab, ho seguito CSCI370 o “Advanced Software Engineering” come parte del mio programma universitario di informatica presso il Colorado School of Mines. CSCI370 è un corso che richiede agli studenti di progettare, implementare e documentare soluzioni relative al software per un’azienda. Consente agli studenti di applicare le conoscenze acquisite nei corsi a problemi reali di informatica. Puoi saperne di più sul corso qui.

Nel corso, puoi decidere su quale progetto/azienda lavorare. Il corso forniva PDF che descrivevano ogni progetto e azienda. Alla fine decisi di lavorare su un progetto pubblicato da un’azienda chiamata Lunar Outpost chiamato “Real Time Wheel Slip Detection and Error Corrections for Enhanced Lunar Navigation”. Poiché il nome è lungo, diamogli l’alias di “Wheel Slippage Detection”.

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ò far perdere ai sistemi autonomi la traccia della loro posizione nel mondo reale. Sulla Terra, questo viene risolto usando i dati GPS per correggere qualsiasi scostamento causato dallo slittamento delle ruote. Ma il problema del GPS è che funziona solo grazie a 30+ satelliti di navigazione che orbitano costantemente intorno alla Terra nello spazio e trasmettono segnali unici che consentono ai computer di calcolare la loro posizione. Ma sulla luna, attualmente non esiste qualcosa come un GPS. Sapendo questo, per rilevare lo slittamento delle ruote deve essere usato un metodo diverso dal GPS. Un resoconto più dettagliato del problema del progetto può essere visualizzato qui.

Il team

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

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

Il progetto richiedeva di conoscere un po’ 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 primaverile 2020. Per questo motivo, all’inizio, ho aiutato tutti a mettersi al passo con ROS e con il modo di 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 era dovuto al COVID, che rendeva tutto remoto e ci impediva di lavorare nei laboratori/edifici di Lunar Outpost. A causa di ciò, abbiamo dovuto usare simulazioni.

Inoltre, abbiamo esaminato alcune ricerche accademiche del WVU Navigation Lab per avere un’idea di come il problema dello slittamento delle ruote potesse essere risolto per il caso d’uso di Lunar Outpost, cosa che per noi, come studenti del secondo e del terzo anno universitario, è stata più difficile del previsto.

Un’altra sfida che abbiamo affrontato è stata la quantità di tempo che avevamo per lavorare a 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 è ben lontano dall’essere abbastanza tempo per risolvere questo problema. Ma, nonostante tutte queste sfide, abbiamo resistito e ci siamo assicurati di portare a termine il lavoro.

Conclusione

Dopo aver affrontato tutta la ricerca e lo sviluppo, abbiamo determinato che è quasi impossibile simulare correttamente la fisica lunare in digitale, quindi provare davvero questo algoritmo in una simulazione non è utile e non porterà a nessuna ricerca significativa nel rilevamento dello slittamento delle ruote nello spazio e sulla luna. Abbiamo concluso che allestire un ambiente di test 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 rilevamento dello slittamento delle ruote per farlo funzionare come un nodo ROS e ha funzionato correttamente e poteva essere facilmente importato su hardware reale per i test. Questo progetto mi ha permesso di assumere un ruolo di leadership, istruire i miei compagni sullo sviluppo in ROS e acquisire esperienza con Python, ROS e Gazebo mentre affrontavo 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, gettando le basi per ciò che sarebbe venuto dopo nel mio percorso nella robotica.

Iniziare al laboratorio HCR

Dopo aver completato CSCI473, il mio CS Field Session nell’estate del 2020, e il semestre autunnale 2020, ho deciso di dedicarmi alla ricerca in robotica. Ho avuto esperienze così positive sia con CSCI473 sia con il CS Field Session che ho deciso di voler fare ricerca per l’HCR Lab. Poiché avevo incontrato il Dr. Zhang l’anno precedente, ho deciso di mandargli un’email e chiedergli delle opportunità che il laboratorio avrebbe potuto avere nel gennaio 2021. Nel giro di circa 2 settimane, il Dr. Zhang ha mostrato interesse, mi ha presentato opzioni di ricerca e mi ha offerto un ruolo nel laboratorio. Ho quindi iniziato a lavorare per il laboratorio nel febbraio 2021.

Video introduttivo

Ecco il mio video introduttivo che ho registrato dopo alcuni mesi nel mio periodo all’HCR Lab. È stato registrato nel maggio 2021 e copre la ricerca su cui mi sarei concentrato all’HCR Lab durante l’estate del 2021:

Il mio progetto

Durante il mio periodo all’HCR Lab, mi sono concentrato principalmente sul progetto Triton. Il progetto Triton è un robot mobile sviluppato dal Human Centered Robotics Lab della Colorado School of Mines. È un robot terrestre omni-wheel triangolare alimentato dal Jetson Nano di NVIDIA.

Il Triton, in una semplice panoramica, consisteva nelle seguenti parti:

• NVIDIA Jetson Nano
• Seed Studio A205 Carrier Board di NVIDIA
• Arduino Mega
• Scheda Micro SD da 64 GB
• Corpo personalizzato stampato in 3D
• 3 ruote mecanum
• 1 batteria AR
• Circuiti personalizzati per una distribuzione dell’alimentazione e un cablaggio ottimizzati
• Fotocamera Realsense D435 di Intel
• Alcuni LED

È stato progettato, costruito e realizzato intorno al 2018-2020 come robot a scopo educativo. Quando mi sono unito io, il Triton era ormai abbastanza consolidato, e il laboratorio stava valutando di farne una nuova versione. Tuttavia, il problema principale del Triton era il suo software. Il Triton poteva muoversi, caricarsi e funzionare in senso basilare ma in realtà non faceva nulla di intelligente. Gli mancava persino la capacità di eseguire movimenti più avanzati.

Per iniziare ad affrontare questo problema, il laboratorio ha predisposto 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 (a infrarossi) disposte in una forma simile a un quadrato, a circa 6-7 piedi sopra il pavimento.

Oltre a questa area costruita, a ciascun Triton erano attaccate tre sfere grigie nella parte superiore del corpo.

Con questa configurazione, avevamo praticamente costruito un 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 disposte in forma triangolare, potevamo individuare con precisione le coordinate esatte di un Triton nella nostra area. Questo ci ha permesso di applicare un sistema a ciclo chiuso per una migliore accuratezza nel movimento.

Il sistema Optitrack forniva dati di posizione e orientamento a circa 120 Hz con precisione submillimetrica quando correttamente calibrato. I tre marker riflettenti di ciascun Triton formavano un motivo triangolare unico che il sistema poteva tracciare come corpo rigido. Il sistema di coordinate era calibrato in modo che (0,0) fosse al centro dell’area di tracciamento, con gli assi X e Y allineati alla geometria della stanza. Ma nonostante questi dati di posizionamento precisi, il Triton continuava a faticare con il movimento.

Con questa configurazione, una funzionalità fondamentale che volevamo fornire al Triton era la capacità di muoversi verso una coordinata specifica. L’utente, o il suo software, poteva fornire una coordinata (x, y) all’interno della sua area di interesse. Poi il robot si sarebbe mosso verso quella coordinata il più velocemente, accuratamente e senza soluzione di continuità possibile. Quando mi sono unito, 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 di questo metodo?

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

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

Sapendo questo, ho dedicato molto tempo a fare ricerca sul modo migliore possibile per affrontare questo problema. Ironia della sorte, stavo seguendo un corso chiamato Introduction to Feedback Control Systems (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 con il mio intelligente coinquilino, è diventato chiaro che questo obiettivo di portare il Triton a un punto obiettivo era un problema di sistema a ciclo chiuso.

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

Metodo 1: Controllore Distanza-Theta

Questo approccio utilizzava due controllori proporzionali separati che funzionavano simultaneamente:

• Controllore della distanza: Calcolava la distanza euclidea dal bersaglio e applicava un guadagno proporzionale per determinare la velocità in avanti/indietro
• Controllore theta: Calcolava l’errore angolare tra la direzione attuale del robot e la direzione desiderata verso il bersaglio, applicando un guadagno proporzionale separato per la velocità di rotazione

L’algoritmo calcolava continuamente la distanza euclidea dal bersaglio e l’errore angolare tra la direzione attuale del robot e la direzione desiderata. Due guadagni proporzionali separati venivano applicati per generare rispettivamente le velocità lineare e angolare.

Questo faceva sì che il Triton si girasse naturalmente verso l’obiettivo mentre si muoveva simultaneamente in avanti, creando traiettorie curve fluide. Il vantaggio principale era che il robot manteneva sempre la parte frontale orientata verso la destinazione, cosa cruciale per le applicazioni basate su telecamera.

Metodo 2: Controllore di coordinate X-Y

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

• Controllore X: Controllava direttamente il movimento est-ovest in base all’errore della coordinata X
• Controllore Y: Controllava direttamente il movimento nord-sud in base all’errore della coordinata Y

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

Per il metodo #1, ho spiegato in dettaglio questo metodo nel mio blog Move Turtle (TurtleSim). Consiglio vivamente di leggere questo blog per ottenere tutti i dettagli su come funzionano in generale i controllori PID, così come su come funziona il metodo #1. Ho sviluppato il metodo #1 usando TurtleSim di ROS, poi ho trasferito quel codice su Triton e lo ho aggiornato per tener conto di un ambiente più reale.

Il metodo #2 utilizzava un approccio piuttosto diverso ma altrettanto 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 sia nella direzione Y separatamente. Per esempio, se il robot deve muoversi da (0,0) a (2,3), vede la cosa come la necessità di correggere un errore di 2 metri in X e un errore di 3 metri in Y. Due controllori proporzionali lavoravano simultaneamente: uno regolava la velocità del robot nella direzione X in base all’errore X, mentre l’altro gestiva il movimento nella direzione Y in base all’errore Y. Questo creava un percorso più diretto verso l’obiettivo, simile a come si muove la testina di una stampante 3D, e consentiva movimenti diagonali fluidi. Il robot non aveva bisogno di ruotare esplicitamente per affrontare il bersaglio, rendendo questo metodo particolarmente efficace in spazi ristretti o quando è richiesto un posizionamento preciso.

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

Quello che prima richiedeva 30-45 secondi per un semplice movimento da punto a punto ora richiedeva circa 8-12 secondi. Ancora più importante, il Triton poteva ora navigare in modo più efficiente in spazi ristretti, cosa che è diventata utile per i nostri scenari multi-robot.

Sfide di sviluppo e debug

L’implementazione di questi controllori non è stata semplice e ha comportato diverse sfide significative di debug:

Trasformazioni del sistema di coordinate: Uno degli aspetti più difficili è stato ottenere correttamente le trasformazioni delle coordinate. Il sistema Optitrack forniva dati nel proprio sistema di riferimento, il robot aveva il suo sistema di riferimento locale, e dovevo convertire accuratamente tra i due. Le prime implementazioni facevano muovere i robot nella direzione sbagliata perché avevo confuso i calcoli delle matrici di rotazione.

Comportamento reale vs. comportamento 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 regolare i guadagni proporzionali e ad aggiungere filtri 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 superavano i loro obiettivi e ondeggiavano avanti e indietro. Questo mi ha insegnato l’importanza dei termini derivativi nei controllori PID e la necessità di una corretta regolazione dei guadagni. Alla fine mi sono orientato principalmente verso un controllo proporzionale con guadagni attentamente tarati piuttosto che verso un PID completo, poiché lo smorzamento intrinseco del sistema era sufficiente per la maggior parte delle applicazioni.

Interferenza multi-robot: Quando più robot operavano simultaneamente, ho scoperto schemi di interferenza inaspettati. I robot a volte “si scontravano” per lo stesso spazio o creavano situazioni di stallo in cui si bloccavano a vicenda indefinitamente. Questo mi ha portato a implementare meccanismi di coordinamento e algoritmi di evitamento delle 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 simultaneamente più Triton. Questo è diventato uno dei miei principali ambiti di attenzione ed è finito per essere un contributo significativo al progetto.

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

Per risolvere questo problema, ho implementato un approccio multiprocesso usando la libreria multiprocessing di Python. Ogni Triton aveva il proprio processo dedicato che poteva funzionare in modo indipendente pur essendo coordinato da un sistema di controllo centrale. Questo permetteva a più Triton di muoversi simultaneamente senza interferire con i loop di controllo degli altri.

Progettazione dell’architettura multi-robot

L’architettura di sistema che ho sviluppato era composta da diversi componenti chiave:

Processo del controllore principale: Questo fungeva da coordinatore centrale, gestendo le interazioni dell’interfaccia utente, la pianificazione del percorso e il coordinamento di alto livello tra i robot. Manteneva lo stato globale e distribuiva i comandi ai singoli processi robot.

Processi dei singoli robot: 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 locale del percorso ed evitamento degli ostacoli
• Segnalazione dello stato al controllore 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 consentiva un coordinamento in tempo reale senza il sovraccarico della comunicazione di rete.

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

La sfida era garantire che tutti i robot potessero eseguire i propri loop di controllo in modo indipendente pur mantenendo il coordinamento globale. Ogni processo robot eseguiva i propri calcoli PID e inviava direttamente i comandi motore all’hardware, mentre il processo principale gestiva il coordinamento di livello superiore come l’evitamento delle collisioni e la pianificazione del percorso.

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

• Scenari di comunicazione veicolo-veicolo
• Pianificazione coordinata del percorso con evitamento degli ostacoli
• Comportamenti di robotica di sciame
• Mappatura SLAM multi-agente
• Controllo di formazione e comportamenti di inseguimento

Ecco come appariva la configurazione del laboratorio con più Triton in esecuzione simultaneamente:

Ho anche sviluppato un’interfaccia intuitiva che consentiva ai ricercatori di definire visivamente i percorsi per ciascun Triton. Si poteva letteralmente disegnare il percorso che si voleva che ogni robot seguisse, e loro eseguivano questi percorsi con una coordinazione perfetta. Questo era incredibilmente utile per impostare esperimenti complessi senza dover programmare manualmente ogni movimento.

Il sistema poteva gestire fino a 5 Triton simultaneamente, ognuno con i propri controllori PID, pur essendo coordinato tramite il sistema di controllo centrale. Le prestazioni erano impressionanti, con tutti i robot che mantenevano la propria accuratezza individuale mentre lavoravano insieme come squadra.

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

Integrazione del sensore di profondità e correzione delle coordinate

Un altro grande avanzamento su cui ho lavorato riguardava l’utilizzo delle telecamere di profondità Intel RealSense D435 montate su ciascun Triton. Sebbene il sistema Optitrack ci fornisse dati di posizionamento incredibilmente precisi, volevo esplorare come i robot potessero usare i propri sensori di bordo per migliorare la consapevolezza spaziale e correggere gli errori di coordinate.

L’idea era che i Triton potessero usare i loro sensori di profondità per rilevare altri Triton nelle vicinanze e confrontare le rispettive posizioni. Questo avrebbe avuto molteplici scopi:

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

2. SLAM migliorato: Facendo lavorare insieme più robot con sensori di profondità, potevamo 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 rilevarsi ed evitarsi a vicenda anche se il sistema di controllo centrale avesse avuto ritardi di comunicazione.

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

• Rilevare altri Tritons usando la loro caratteristica forma triangolare e i marcatori sferici riflettenti
• Calcolare posizioni e orientamenti relativi usando i dati di profondità
• Confrontare queste misurazioni con i dati Optitrack per identificare discrepanze
• Potenzialmente regolare il proprio sistema di coordinate in tempo reale per mantenere l’accuratezza

Esperimenti di visione artificiale

Ho dedicato 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 sia di profondità. Ho lavorato principalmente con i dati di profondità, che arrivavano come una matrice 640x480 di misurazioni di distanza a 30Hz. La prima sfida era filtrare questi dati di profondità rumorosi per estrarre informazioni geometriche significative.

Tentativi di rilevamento degli oggetti: Ho sperimentato algoritmi di rilevamento multistadio. Ho ottenuto un certo successo segmentando l’immagine di profondità per identificare gli oggetti a livello del pavimento (filtrando muri, soffitto, ecc.) e cercando oggetti con le giuste caratteristiche dimensionali, un’impronta di circa 0,3x0,3 metri. Ho provato a usare il rilevamento dei bordi e l’analisi geometrica per identificare il profilo distintivo del Triton, con risultati alterni.

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

Ricerca sulla fusione delle coordinate: Ho studiato approcci per fondere le stime di posizione basate sulla visione con i dati Optitrack, incluse implementazioni di base del filtro di Kalman. Il concetto era dare maggiore peso ai dati Optitrack quando disponibili, ma ricorrere alla visione quando necessario, anche se non sono riuscito a far funzionare completamente tutto questo prima della fine del mio periodo nel laboratorio.

Sfide di prestazioni: Far girare tutta questa elaborazione in tempo reale insieme ai loop di controllo del robot si è rivelato impegnativo. Ho sperimentato approcci di ottimizzazione per far 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 pienamente questo lavoro di visione artificiale. Sebbene abbia ottenuto alcuni risultati iniziali promettenti e abbia imparato molto sull’elaborazione dei sensori di profondità, non sono riuscito a portare il sistema a uno stato pienamente affidabile. È rimasta una direzione di ricerca interessante su cui altri potrebbero potenzialmente costruire.

Ecco un video in cui mi sono messo alla prova con gli algoritmi di visione artificiale:

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

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

Documentazione e preservazione della conoscenza

Uno dei miei contributi più importanti all’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 sparsa su più piattaforme e formati. Le informazioni critiche erano distribuite tra:

• Vari account Google Drive appartenenti a diversi studenti che si erano laureati
• Vecchie email sepolte nelle caselle di posta
• Cartelle Dropbox casuali
• Più repository GitHub
• Repository GitLab con organizzazione incoerente
• Appunti scritti a mano che solo persone specifiche potevano interpretare

Questa documentazione frammentata era un enorme problema. I nuovi studenti passavano settimane solo per capire come iniziare, e la conoscenza preziosa veniva costantemente persa quando le persone si laureavano o lasciavano il laboratorio.

Mi sono assunto il compito di risolvere sistematicamente questo problema. Ho trascorso innumerevoli ore a rintracciare ogni pezzo di documentazione, codice, video e nota relativi 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 del software: Guide complete per configurare l’ambiente di sviluppo
• Documentazione del codice: Codice ben commentato con spiegazioni chiare
• Specifiche hardware: Elenchi dettagliati dei componenti, schemi di cablaggio 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 colmavano lacune critiche nella base di conoscenza. Questi includevano istruzioni dettagliate di configurazione per i nuovi membri del laboratorio, guide complete alla risoluzione dei problemi e walkthrough video di procedure complesse.

L’impatto fu immediato e duraturo. I nuovi studenti potevano mettersi al passo in giorni invece che in settimane. Il repository di documentazione che ho creato è ancora oggi utilizzato dal laboratorio, anni dopo la mia partenza. È diventato l’unica fonte di verità per il progetto Triton e ha fatto risparmiare innumerevoli ore/giorni ai ricercatori futuri.

Mentoring e trasferimento di conoscenze

Uno degli aspetti più gratificanti del mio periodo nell’HCR Lab è stato 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 dei sistemi Triton, mi sono assunto una responsabilità crescente nella formazione dei nuovi membri del team.

Formazione dei successori del laboratorio

Quando mi stavo preparando a lasciare eventualmente il laboratorio per concentrarmi sul completamento della mia laurea e sul mio lavoro in eBay, mi sono assicurato di formare a fondo 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 davvero i principi di fondo così da poter continuare a innovare.

Ho passato settimane a lavorare a stretto contatto con loro, affrontando:

• Le basi matematiche dei sistemi di controllo PID
• L’architettura di multi-processamento per coordinare 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 di conoscenze è stato incredibilmente accurato. Abbiamo affrontato insieme vere sessioni di debug, li ho fatti modificare ed estendere il codice esistente e mi sono assicurato che fossero in grado di configurare autonomamente nuovi Triton da zero.

Programma di mentorship per studenti delle superiori

Forse ancora più gratificante è stata la mia esperienza di mentorship con una studentessa delle superiori attraverso il programma di divulgazione 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 copriva:

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 motore
• Le basi dei sistemi autonomi e del controllo in retroazione

ROS (Robot Operating System):

• Comprensione del sistema di messaggistica publish/subscribe
• Creazione di nodi e servizi
• Lavorare con file di avvio e parameter server

Lavoro pratico sul progetto:

• 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 integrava con i nostri sistemi esistenti
• Il servizio di controllo LED che ha creato è diventato una parte permanente della codebase di Triton

Ciò che ha reso questa mentorship particolarmente speciale è stato osservare la sua progressione da una persona che non sapeva praticamente nulla di programmazione a qualcuno che contribuiva con codice significativo a un progetto di ricerca attivo. È passata dal chiedere “Che cos’è una variabile?” al fare debug in autonomia di problemi di comunicazione ROS e scrivere le proprie implementazioni di servizi.

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

La mentorship è stata tanto educativa per me quanto lo è stata 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 era incentrata sugli algoritmi per auto a guida autonoma. I miglioramenti software che avevo apportato al sistema Triton aiutarono a sostenere la sua ricerca di dottorato.

La ricerca di Peng richiedeva una coordinazione multi-robot precisa 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 accurati e non riuscivano a lavorare insieme con altrettanta efficacia.

I miei contributi aiutarono la ricerca di Peng in diverse aree:

Studi sulla gestione delle intersezioni: Con i controllori PID migliorati e la coordinazione multi-robot, Peng poteva simulare scenari di incroci in cui più “veicoli” (Triton) dovevano coordinare i loro movimenti. La migliore temporizzazione e il posizionamento resero questi studi più fattibili.

Comunicazione veicolo-veicolo: Il framework di multi-processing che sviluppai permise 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 dover operare le auto a guida autonoma.

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

Ciò che rese la nostra collaborazione particolarmente preziosa fu il fatto che non si trattava solo di me che aiutavo la sua ricerca, ma di una vera partnership. La comprensione di Peng degli aspetti teorici dei veicoli autonomi aiutò a informare le mie implementazioni pratiche. Il suo feedback e i suoi requisiti mi spinsero a rendere i sistemi più robusti e capaci.

Trascorremmo molte ore insieme nel laboratorio, facendo debug di scenari, discutendo diverse strategie di controllo ed esplorando ciò che la piattaforma Triton poteva realizzare. Peng divenne sia un collega sia un amico, e lavorare con lui mi insegnò molto su come funziona davvero la ricerca accademica.

I sistemi che costruii divennero una parte utile del lavoro di tesi di Peng. Vedere i miei contributi ingegneristici pratici sostenere la ricerca nella tecnologia dei veicoli autonomi fu davvero appagante. Rafforzò il mio interesse per il modo in cui una solida ingegneria e la ricerca possono lavorare insieme per creare risultati utili.

Anche dopo aver lasciato il laboratorio, Peng e io restammo in contatto. Sapere che il mio lavoro continuava a contribuire a una ricerca importante anche dopo la mia partenza fu estremamente gratificante.

Prospettiva: l’era pre-LLM dello sviluppo

Vale la pena notare che tutto questo lavoro fu realizzato durante l’era pre-LLM dello sviluppo software. Tutto ciò ebbe luogo tra il 2020 e il 2021 (soprattutto nel 2021), prima che esistessero ChatGPT, Claude, Perplexity, o strumenti di sviluppo basati sull’IA come Cursor IDE.

Ogni riga di codice fu scritta da zero, ogni algoritmo fu studiato tramite articoli accademici e libri di testo, e ogni sessione di debugging coinvolgeva metodi tradizionali come istruzioni di stampa, debugger e test metodici. Quando rimanevo bloccato su un problema di trasformazione delle coordinate o di regolazione PID, non potevo semplicemente chiedere a un assistente IA di spiegare il concetto o aiutarmi a fare debug del problema.

Questo rese il processo di sviluppo significativamente più impegnativo, ma anche più formativo. Dovetti:

Ricercare tutto manualmente: Comprendere la teoria del controllo PID significava leggere libri di testo e articoli accademici. Capire le trasformazioni delle coordinate richiedeva di lavorare a mano attraverso la matematica. 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 alcuna IA a suggerire potenziali problemi o ad 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?” dovevo comprendere a fondo i concetti sottostanti. Questo mi costrinse a costruire una base solida nella programmazione concorrente, nei sistemi di controllo e nella visione artificiale.

La documentazione era fondamentale: Poiché non potevo affidarmi all’IA per spiegare in seguito il codice, dovevo scrivere documentazione e commenti estremamente chiari. Questa disciplina si rivelò preziosissima quando trasferivo conoscenze ad altri.

Guardando indietro, mentre i moderni strumenti IA avrebbero accelerato molti aspetti dello sviluppo, lavorare senza di essi mi costrinse a sviluppare capacità più profonde di problem solving 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 decisione difficile di andarsene

Per quanto amassi lavorare nell’HCR Lab, verso la fine del 2021 mi trovai ad affrontare una decisione difficile che molti studenti incontrano: bilanciare molteplici opportunità e responsabilità. Lavoravo simultaneamente a tempo pieno come software engineer presso eBay, stavo terminando la mia laurea in informatica al Mines e contribuivo alla ricerca nell’HCR Lab.

L’opportunità in eBay era significativa; era il mio primo importante ruolo di software engineering, mi forniva un’esperienza preziosa nel settore e mi garantiva un reddito solido. Tuttavia, cercare di mantenere un lavoro a tempo pieno, completare la 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 mio carico di corsi per concentrarmi maggiormente sul lavoro nel laboratorio, mi consigliò fortemente di non farlo. Il suo ragionamento era sensato: completare la laurea doveva essere la priorità, e l’esperienza nel settore 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.

Così, nel settembre 2021, dopo circa 8 mesi di lavoro intensivo nel laboratorio, presi la difficile decisione di fare un passo indietro dal mio ruolo di assistente di ricerca per concentrarmi sul completamento della laurea e sul mio lavoro in eBay. Fu una delle decisioni professionali più difficili che abbia dovuto prendere in quel periodo.

Anche dopo aver lasciato ufficialmente il laboratorio, continuai a fornire supporto ogni volta che qualcuno aveva bisogno di aiuto con i sistemi che avevo costruito. Aggiornavo la documentazione quando necessario, rispondevo alle domande sul debugging e aiutavo a risolvere i problemi da remoto. I legami che avevo creato e l’impegno che avevo nel successo del progetto non scomparvero solo perché non facevo più ufficialmente parte del team.

Riflessioni e uno 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, ambiti che sono stati incredibilmente gratificanti e hanno offerto enormi opportunità di crescita e impatto.

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

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

Ma riconosco anche che ogni percorso ha i suoi compromessi. Le competenze che ho sviluppato nello sviluppo web e nell’IA sono state incredibilmente preziose. L’esperienza nel settore mi ha insegnato l’ingegneria del software su larga scala, il design dell’esperienza utente e le sfide pratiche della realizzazione di prodotti che milioni di persone usano. Queste esperienze mi hanno reso un ingegnere migliore nel complesso.

Il lavoro che ho svolto nell’HCR Lab continua a influenzare il modo in cui affronto i problemi oggi. Il pensiero sistematico richiesto dai sistemi di controllo PID si riflette nel modo in cui progetto i loop di feedback nei sistemi software. Le competenze di documentazione e conservazione della conoscenza che ho sviluppato sono state preziosissime in ogni ruolo successivo. L’esperienza di mentorship e insegnamento ha plasmato il modo in cui lavoro con sviluppatori junior e contribuisco alla condivisione delle conoscenze del team.

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

L’impatto duraturo

Guardando indietro all’esperienza nell’HCR Lab, mi colpisce quanto abbia realizzato in un tempo relativamente breve. I sistemi che costruii cambiarono radicalmente il modo in cui operava la piattaforma Triton, e molti di quei miglioramenti sono ancora in uso oggi. Il repository di documentazione che creai divenne la base di conoscenza per l’intero progetto. Le relazioni di mentorship che instaurai ebbero un impatto duraturo sulle persone con cui lavorai.

Ma forse, cosa ancora più significativa, l’esperienza mi mostrò di cosa sono capace quando lavoro su problemi che mi appassionano davvero. In quegli otto mesi, io:

• Ho migliorato il sistema di controllo del movimento del robot che stava limitando la piattaforma
• Ho costruito da zero un sistema di coordinamento multi-robot
• Ho integrato capacità di visione artificiale e fusione dei 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

Tuttavia, non si trattava solo dei risultati tecnici, anche se per me erano significativi. Si trattava di imparare che, con perseveranza e pensiero sistematico, si possono dare contributi utili anche da studenti universitari.

Il Futuro e la Robotica

Anche se la mia carriera mi ha portato in altre direzioni, la mia passione per la robotica non è diminuita. Continuo a seguire gli sviluppi del settore, sono entusiasta dei progressi nell’apprendimento dei robot e nei sistemi autonomi, e occasionalmente lavoro a progetti personali di robotica nel mio tempo libero.

Chi sa cosa riserva il futuro? Le competenze che sto sviluppando nell’IA e nel machine learning sono sempre più rilevanti per la robotica. L’esperienza nel settore che ho acquisito mi ha insegnato come costruire sistemi robusti e scalabili. Forse ci sarà un futuro in cui questi diversi filoni 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 offerto. È stato un periodo formativo che ha plasmato sia le mie competenze tecniche sia la mia comprensione di quali tipi di lavoro 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ì, ancora al servizio dei ricercatori, ancora a rendere possibile un lavoro importante. E questo è davvero meraviglioso.