Investigación de Robótica del Laboratorio HCR

Esta publicación del blog narra mi trayectoria en robótica durante mis estudios de pregrado en la Colorado School of Mines, desde descubrir mi pasión en CSCI473, pasando por mi proyecto CS Field Session en el verano de 2020, hasta mi trabajo de investigación en el Laboratorio de Robótica Centrada en el Humano (HCR) de febrero de 2021 a septiembre de 2021.

Antecedentes

Comencé mis estudios de pregrado en la Colorado School of Mines en el semestre de otoño de 2018. Mi especialidad era Ciencias de la Computación con enfoque en Robótica y Sistemas Inteligentes. Y me gradué en la primavera de 2022.

Tuve suerte de encontrar mi pasión temprano en mi vida. Durante la escuela secundaria, dediqué bastante tiempo a descubrir qué me gustaba y en qué podía ser bueno. Después de varios intentos y errores, pude descubrir que mi pasión era la informática. Pero también fue durante ese tiempo que descubrí mi gran amor por construir mediante código.

En Mines, tuve la oportunidad de trabajar en el Laboratorio de Robótica Centrada en el Humano (HCR) de Mines bajo la supervisión del Dr Hao Zhang. Conocí al Dr. Zhang por primera vez en la primavera de 2020 a través de su clase “Human Centered Robotics” (CSCI473), y después del caos del COVID y el trabajo de clase, pude trabajar en su laboratorio a principios de la primavera de 2021.

Clase de Robótica Centrada en el Humano (CSCI473)

La Robótica Centrada en el Humano (CSCI473) de Mines fue una de las pocas clases de mi experiencia universitaria que tuvo un impacto profundo en mí. La clase fue impartida por el Dr. Hao Zhang. Nuestra calificación completa para la clase consistió en solo tres proyectos, cada uno de los cuales presentó un problema desafiante que introdujo conceptos básicos de robótica. Estos proyectos consistieron en:

1. Aprender Robot Operating System (ROS)
2. Aprendizaje por Refuerzo para Seguimiento de Pared por Robot
3. Comprensión de los Comportamientos Humanos por Robot usando Representaciones Basadas en Esqueleto

🧩 Aprender Robot Operating System (ROS)

Este fue el primer proyecto que se nos asignó. El proyecto consistió en tres tareas:

1. Configurar el Entorno de Desarrollo
2. Entender el Simulador Gazebo
3. Escribir un “Hello World” de ROS

Para las tareas 1 y 2, solo tuvimos que configurar nuestro entorno de desarrollo y seguir un tutorial de introducción a Gazebo. Esto incluyó:

• Instalar ROS Melodic, lo cual hice en mi laptop HP de 2011 que fue suficiente
• Instalar y configurar ROS y Gazebo
• Seguir el tutorial de gazebosim y el tutorial del e-manual.

La tarea 3, por otro lado, fue un verdadero desafío. La tarea consistía en usar turtlesim y hacer que la tortuga dibujara el logo “M” de Mines:

Esta tarea, aunque parecía simple, fue más difícil de lo que parecía. Este proyecto finalmente me introdujo al concepto de sistemas de bucle abierto y bucle cerrado. Puedes aprender más sobre este proyecto y mi solución en la página del proyecto ROS Move Turtle.

🧩 Aprendizaje por Refuerzo para Seguimiento de Pared por Robot

Este fue el segundo proyecto que se nos asignó, y fue uno de los proyectos más difíciles en los que he trabajado en la universidad. La descripción del proyecto era la siguiente:

En este proyecto, los estudiantes diseñarán e implementarán algoritmos de aprendizaje por refuerzo para enseñar a un robot móvil autónomo a seguir una pared y evitar chocar con obstáculos. Los estudiantes usarán la simulación Gazebo en ROS Melodic para simular un robot móvil omnidireccional llamado Triton, y usarán un mapa del entorno que se les proporciona. Los estudiantes usarán un escáner láser en el robot para realizar detección y aprendizaje, donde el robot se controla mediante comandos de dirección y velocidad. Se requiere que los estudiantes programen este proyecto usando C++ o Python en ROS Melodic ejecutándose en Ubuntu 18.04 LTS (es decir, el mismo entorno de desarrollo usado en el Proyecto 1). Además, los estudiantes deben redactar un informe siguiendo el formato de conferencias estándar de IEEE en robótica usando LATEX.

Para el algoritmo de aprendizaje por refuerzo, se nos indicó usar Q-Learning. También usamos el entorno de simulación Gazebo Stingray proporcionado por la clase. Stingray incluía el modelo Triton y la lógica física. También se nos proporcionó un laberinto para que el robot lo siguiera. En conjunto, el entorno se veía así:

Para la descripción completa del proyecto, consulta csci473-p2.pdf. Nunca publiqué mi solución en GitHub o la web porque no era muy buena y tenía muchos errores. Además, hacer que el código funcione en el entorno correcto es bastante difícil y molesto. Sin embargo, tengo un video de demostración que presenté a la clase, mostrando mi solución. Puedes verlo aquí:

🧩 Comprensión de los Comportamientos Humanos usando Representaciones Basadas en Esqueleto

Para el tercer proyecto, la descripción del proyecto era la siguiente:

En este proyecto, los estudiantes implementarán varias representaciones basadas en esqueletos (Entregable 1) y usarán Máquinas de Vectores de Soporte (SVM) (Entregable 2) para clasificar comportamientos humanos usando un conjunto de datos de actividades públicas recopilado con un sensor Kinect V1. Además, los estudiantes deben redactar un informe siguiendo el formato de conferencias estándar de IEEE en robótica usando LATEX en el Entregable 3.

Este proyecto fue desafiante pero no tan difícil como el segundo proyecto. El objetivo principal era usar datos del sensor Kinect V1 del MSR Daily Activity 3D Dataset y Máquinas de Vectores de Soporte para clasificar ciertas acciones/comportamientos humanos. Puedes aprender más sobre este proyecto y mi solución en la página del proyecto Predict Human Actions Using LIBSVM.

Conclusión de CSCI473

CSCI473 es una de, si no la mejor clase que tomé durante mis estudios de pregrado en Mines. Todos estos proyectos me enseñaron mucho y me permitieron tener un catálogo de proyectos para reflejar y referir en mi currículum. También fue la primera clase donde sentí que estaba en mi elemento, ya que nunca fui buen estudiante de exámenes pero sobresalí en la realización de proyectos. También fue a través de esta clase que conocí al Dr. Hao Zhang, quien finalmente me ayudó a conseguir una posición como asistente de investigación en el Laboratorio de Robótica Centrada en el Humano (HCR) de Mines.

Sesión de Campo de CS (Verano 2020)

Durante el verano de 2020, entre completar CSCI473 y unirme al Laboratorio HCR, tomé CSCI370 o “Ingeniería de Software Avanzada” como parte de mi programa de pregrado en Ciencias de la Computación en la Colorado School of Mines. CSCI370 es un curso que hace que los estudiantes diseñen, implementen y documenten soluciones de software para una empresa. Permite a los estudiantes aplicar sus conocimientos académicos a problemas reales de ciencias de la computación. Puedes aprender más sobre el curso aquí.

En el curso, puedes decidir en qué proyecto/empresa trabajarás. El curso proporcionó PDFs detallando cada proyecto y empresa. Finalmente decidí trabajar en un proyecto publicado por la empresa Lunar Outpost llamado “Detección de Deslizamiento de Ruedas en Tiempo Real y Correcciones de Error para una Navegación Lunar Mejorada”. Como el nombre es largo, llamaremos al proyecto “Detección de Deslizamiento de Ruedas”.

El Problema

Lunar Outpost es una startup que intenta crear rovers lunares autónomos. En la luna, hay mucho polvo lunar que es conocido por causar mucho deslizamiento de ruedas. Esto no es ideal porque el deslizamiento de ruedas puede hacer que los sistemas autónomos pierdan la ubicación real. En la Tierra, esto se soluciona usando datos GPS para corregir cualquier desplazamiento causado por el deslizamiento de ruedas. Pero el problema con GPS es que solo funciona con 30+ satélites de navegación. Pero en la luna no hay GPS. Por lo tanto, se debe usar otro método para detectar el deslizamiento de ruedas. Un informe más detallado del problema del proyecto se puede ver aquí.

El Equipo

Este proyecto no fue simple, por lo que tuvo que hacerse en equipo. El equipo estaba compuesto por cinco estudiantes de la Colorado School of Mines:

Este proyecto no fue simple, por lo que tuvo que hacerse en equipo. Este equipo estaba compuesto por Mehmet Yilmaz (yo), Kane Bruce, Braedon O’Callaghan, Liam Williams y Kevin Grant.

El proyecto requería conocimientos de ROS, C++, Python, Linux, Raspberry Pi y Arduino. La mayoría de nosotros teníamos experiencia en una o más de estas tecnologías, pero yo era el único con experiencia en ROS ya que lo usé en mi clase de Robótica Centrada en el Humano (CSCI473) en la primavera de 2020. Por ello, al principio ayudé a que todos se pusieran al día con ROS y cómo desarrollarlo.

Desafíos

En este proyecto hubo muchos desafíos. Pero el mayor desafío fue no tener acceso a un robot real para pruebas. Esto se debió al COVID y nos impidió trabajar en el laboratorio/edificios de Lunar Outpost. Por lo tanto, tuvimos que usar simulaciones.

También, revisamos alguna investigación académica del Laboratorio de Navegación WVU para obtener una idea de cómo se podría resolver el problema de deslizamiento de ruedas para el caso de uso del puesto lunar. Lo cual, para nosotros, como estudiantes de segundo y tercer año de pregrado, fue más difícil de lo que esperábamos.

Otro desafío que enfrentamos fue la cantidad de tiempo que teníamos para trabajar en este proyecto. CSCI370 es una clase de un mes. Pero el problema en sí es un problema masivo que muchas empresas y académicos han estado intentando resolver/perfeccionar durante décadas. Así que un mes está lejos de ser suficiente para resolver este problema. Sin embargo, a pesar de todos estos desafíos, seguimos adelante y nos aseguramos de entregar.

Conclusion

Después de trabajar a través de toda la investigación y desarrollo, determinamos que es casi imposible simular la física lunar adecuada de forma digital, por lo que intentar este algoritmo en una simulación no sirve y no producirá ninguna investigación significativa en detección de deslizamiento de ruedas en el espacio y en la luna. Concluimos que establecer un entorno de prueba adecuado usando algo como arena y hardware real, como un robot Husky, es mucho más importante para este tipo de investigación. Actualizamos el código de detección de deslizamiento de ruedas para que funcione como un nodo ROS y funcionó correctamente y podría importarse fácilmente a hardware real para pruebas. Este proyecto me permitió asumir un rol de liderazgo, educar a mis compañeros en desarrollo ROS y adquirir experiencia con Python, ROS y Gazebo mientras abordaba un problema complejo que nunca había encontrado antes. Lo más importante, esta experiencia consolidó aún más mi pasión por la robótica y reforzó mi deseo de seguir investigando en el campo, preparando el escenario para lo que vendría después en mi trayectoria de robótica.

Starting At The HCR Lab

Después de completar CSCI473, mi Sesión de Campo de CS en el verano de 2020, y mi semestre de otoño 2020, decidí perseguir la investigación en robótica. Tuve experiencias tan buenas con CSCI473 y la Sesión de Campo de CS que decidí que quería hacer investigación para el Laboratorio de Robótica Centrada en el Ser Humano (HCR Lab). Como había conocido al Dr. Zhang el año anterior, le envié un correo electrónico preguntando sobre oportunidades que el laboratorio pudiera tener en enero de 2021. En aproximadamente 2 semanas, el Dr. Zhang mostró interés, me presentó opciones de investigación y me ofreció un puesto en el laboratorio. Entonces comencé a trabajar para el laboratorio en febrero de 2021.

Introduction Video

Aquí está mi video de introducción que grabé unos meses después de comenzar en el HCR Lab. Fue grabado en mayo de 2021 y cubre la investigación en la que me enfocaría en el HCR Lab durante el verano de 2021:

My Project

Durante mi tiempo en el HCR Lab, me enfoqué principalmente en el proyecto Triton. El proyecto Triton es un robot móvil desarrollado por el Laboratorio de Robótica Centrada en el Ser Humano de la Colorado School of Mines. Es un robot terrestre triangular con ruedas omni, alimentado por el Jetson Nano de NVIDIA.

El Triton, en una visión simple, consistía en las siguientes partes:

• NVIDIA Jetson Nano
• NVIDIA’s Seed Studio A205 Carrier Board
• Arduino Mega
• Tarjeta Micro SD de 64 GB
• Cuerpo impreso en 3D personalizado
• 3 ruedas mecanum
• 1 batería AR
• Circuitos personalizados para distribución de energía y cableado optimizados
• Cámara Intel Realsense D435
• Algunos LEDs

Fue diseñado, construido y fabricado entre 2018-2020 como robot educativo. Cuando me uní, el Triton ya estaba bastante establecido, y el laboratorio estaba considerando crear una nueva versión. Sin embargo, el principal problema del Triton era su software. El Triton podía moverse, cargar y funcionar en un sentido básico, pero no hacía nada inteligente. Incluso le faltaba la capacidad de realizar movimientos más avanzados.

Para comenzar a abordar esto, el laboratorio configuró un área donde podíamos rastrear al Triton. Para ello, crearon un área de 2 metros por 2 metros con 8 cámaras Optitrack Flex (infrarrojas) en una forma cuadrada a unos 6-7 pies del suelo.

Además de tener esta área construida, cada Triton tenía tres esferas grises adheridas en la parte superior de sus cuerpos.

Con esta configuración, habíamos construido efectivamente nuestro propio sistema GPS a pequeña escala que nos permitía obtener las coordenadas exactas en metros de un Triton en nuestra zona de interés. Usando las cámaras infrarrojas Optitrack y las esferas grises de Optitrack en forma triangular, podíamos determinar las coordenadas exactas de un Triton en nuestra área. Esto nos permitió aplicar un sistema de bucle cerrado para mayor precisión en el movimiento.

El sistema Optitrack proporcionaba datos de posición y orientación a aproximadamente 120 Hz con precisión submilimétrica cuando estaba calibrado correctamente. Los tres marcadores reflectantes de cada Triton formaban un patrón triangular único que el sistema podía rastrear como un cuerpo rígido. El sistema de coordenadas se calibró de modo que (0,0) estuviera en el centro del área de seguimiento, con los ejes X e Y alineados con la geometría de la habitación. Pero a pesar de estos datos precisos, el Triton todavía tenía dificultades de movimiento.

Con esta configuración, una característica central que queríamos proporcionar al Triton era la capacidad de moverse a una coordenada específica. El usuario, o su software, podía proporcionar una coordenada (x, y) dentro de su área de interés. Entonces el robot se movería a esa coordenada lo más rápido, preciso y sin interrupciones posible. Cuando me uní, esta característica existía pero no funcionaba bien. Aquí hay una animación simple que muestra cómo funcionaba la lógica de movimiento original:

No grabé la solución original en acción, así que creé esta simple animación que muestra la lógica de movimiento anterior en acción. Conociendo esto, ¿cuáles son los problemas con este método?

1. Es realmente lento
2. Hace que el robot ocupe mucho espacio solo para ir a un punto específico. Esto dificultó el uso de esta solución cuando varios Tritons se movían simultáneamente.

¿Por qué ocurría este comportamiento? El problema era que el Triton primero giraba, cambiando su alfa, hasta que apuntaba al punto objetivo dentro de un margen de error específico. Luego avanzaba rápidamente, y después de que su theta se desviaba del objetivo por una cantidad específica, se detenía y volvía a girar hasta que el alfa estaba dentro del rango aceptable para el objetivo. Luego vuelve a avanzar y repite el proceso hasta llegar al punto. Además, a medida que se acercaba al objetivo, la velocidad de giro y de sprint se ralentizaba mucho para evitar sobrepasar el objetivo. Esto resultó en un movimiento poco natural del Triton, tardando mucho en llegar a un punto objetivo y requiriendo mucho espacio para llegar a un punto específico. Con todos estos problemas, y dado lo esencial que era esta característica para el desarrollo del proyecto Triton, cuando comencé a trabajar en el HCR Lab, mi primera tarea fue desarrollar soluciones más efectivas que permitieran al Triton navegar mejor hacia un punto objetivo.

Con esto en mente, dediqué mucho tiempo a investigar la mejor manera de abordar este problema. Irónicamente, estaba tomando una clase llamada Introducción a los Sistemas de Control de Retroalimentación (EENG307) en Mines. Al principio de esa clase, aprendimos sobre el concepto de controladores de bucle abierto y controladores de bucle cerrado. Con esto, y después de una discusión con el profesor de esa clase y mi compañero de cuarto inteligente, quedó claro que el objetivo de llevar al Triton a un punto objetivo era un problema de sistema de bucle cerrado.

Ahora, después de extensas pruebas e investigación, desarrollé dos enfoques de controladores distintos para los Tritons:

Method 1: Distance-Theta Controller

Este enfoque utilizó dos controladores proporcionales separados que se ejecutan simultáneamente:

• Controlador de distancia: Calcula la distancia euclidiana al objetivo y aplica una ganancia proporcional para determinar la velocidad de avance/retroceso
• Controlador de theta: Calcula el error angular entre la dirección actual del robot y la dirección deseada al objetivo, aplicando una ganancia proporcional separada para la velocidad de rotación

El algoritmo calcula continuamente la distancia euclidiana al objetivo y el error angular entre la dirección actual del robot y la dirección deseada. Se aplican dos ganancias proporcionales separadas para generar velocidades lineales y angulares respectivamente.

Esto resultó en que el Triton girara naturalmente hacia el objetivo mientras se movía simultáneamente hacia adelante, creando trayectorias curvas suaves. La ventaja clave era que el robot siempre mantenía su frente orientado hacia el destino, lo cual era crucial para aplicaciones basadas en cámara.

Method 2: X-Y Coordinate Controller

Este enfoque trató al robot como un plotter 2D, con control independiente de movimiento en X e Y:

• Controlador X: Controla directamente el movimiento este‑oeste basado en el error de la coordenada X
• Controlador Y: Controla directamente el movimiento norte‑sur basado en el error de la coordenada Y

La implementación calculó los errores de coordenadas X e Y de manera independiente, aplicó ganancias proporcionales separadas y luego transformó estos componentes de velocidad global en el marco de coordenadas local del robot utilizando matrices de rotación. Esta transformación era necesaria porque el sistema de tracción de ruedas omnidireccionales del robot requería velocidades en su propio marco de referencia, no en coordenadas globales. Este método produjo los caminos más directos hacia los objetivos y fue significativamente más rápido, pero la dirección del robot se desvió ya que no había un control de orientación explícito.

Para el método #1, entré en detalle sobre este método en mi blog Move Turtle (TurtleSim). Te recomiendo encarecidamente que leas este blog para obtener todos los detalles sobre cómo funcionan los controladores PID en general, así como cómo funciona el método #1. Desarrollé el método #1 utilizando TurtleSim de ROS, luego transferí ese código al Tritón y lo actualicé para tener en cuenta un entorno más realista.

El método #2 utilizó un enfoque bastante diferente pero igualmente efectivo. En lugar de pensar en la orientación del robot y la distancia al objetivo, este método trata el movimiento como un problema de plano de coordenadas. El controlador calcula continuamente el error en ambas direcciones X e Y por separado. Por ejemplo, si el robot necesita moverse de (0,0) a (2,3), lo ve como la necesidad de corregir un error de 2 metros en X y un error de 3 metros en Y. Dos controladores proporcionales trabajaron simultáneamente: uno ajustó la velocidad del robot en la dirección X en función del error en X, mientras que el otro manejó el movimiento en la dirección Y basado en el error en Y. Esto creó un camino más directo hacia el objetivo, similar a cómo se mueve la cabeza de una impresora 3D, y permitió movimientos diagonales suaves. El robot no necesitaba girar explícitamente para enfrentar su objetivo, lo que hacía que este método fuera particularmente efectivo en espacios reducidos o cuando se requería una colocación precisa.

Ambos métodos resultaron ser significativamente más rápidos y más confiables que el enfoque original. Para ver estos nuevos métodos en acción, consulta la Lista de Reproducción de Tritones en Acción, que muestra todos los Tritones en acción con los nuevos métodos.

Lo que antes tomaba de 30 a 45 segundos para un simple movimiento de punto a punto ahora tomaba alrededor de 8 a 12 segundos. Más importante aún, el Tritón ahora podía navegar de manera más eficiente en espacios reducidos, lo que se volvió útil para nuestros escenarios de múltiples robots.

Desafíos de Desarrollo y Depuración

Implementar estos controladores no fue sencillo e involucró varios desafíos significativos de depuración:

Transformaciones del Sistema de Coordenadas: Uno de los aspectos más complicados fue obtener correctamente las transformaciones de coordenadas. El sistema Optitrack proporcionaba datos en su propio marco de coordenadas, el robot tenía su marco de coordenadas local y necesitaba convertir entre ellos con precisión. Las primeras implementaciones hicieron que los robots se movieran en direcciones incorrectas porque había confundido los cálculos de la matriz de rotación.

Comportamiento Real vs. Ideal: El mayor desafío fue tener en cuenta factores del mundo real que no aparecen en la teoría de control de los libros de texto. Las ruedas del robot tenían diferentes características de fricción, los motores no respondían de manera idéntica y siempre había cierta latencia en la cadena de comunicación desde Optitrack hasta el software de control y el Arduino del robot. Pasé semanas ajustando las ganancias proporcionales y añadiendo filtros de zona muerta para tener en cuenta estas realidades físicas.

Problemas de Oscilación y Estabilidad: Mis primeras implementaciones sufrieron problemas de oscilación donde los robots sobrepasaban sus objetivos y se balanceaban de un lado a otro. Esto me enseñó sobre la importancia de los términos derivados en los controladores PID y la necesidad de un ajuste adecuado de las ganancias. Finalmente, me decidí por un control predominantemente proporcional con ganancias cuidadosamente ajustadas en lugar de un PID completo, ya que el amortiguamiento inherente del sistema era suficiente para la mayoría de las aplicaciones.

Interferencia entre Múltiples Robots: Cuando varios robots operaban simultáneamente, descubrí patrones de interferencia inesperados. A veces, los robots “luchaban” por el mismo espacio o creaban situaciones de bloqueo donde se bloqueaban entre sí indefinidamente. Esto me llevó a implementar mecanismos de coordinación y algoritmos de evitación de colisiones.

Sistema de Control Multi-Tritón

Una vez que resolví el problema del movimiento de un solo Tritón, el siguiente desafío del laboratorio fue hacer que múltiples Tritones trabajaran juntos simultáneamente. Esto se convirtió en una de mis principales áreas de enfoque y terminó siendo una contribución significativa al proyecto.

El sistema original solo podía controlar un Tritón a la vez, lo que limitaba severamente las posibilidades de investigación. El laboratorio quería simular escenarios donde múltiples vehículos autónomos necesitaban coordinar sus movimientos, como coches autónomos comunicándose entre sí para optimizar el flujo de tráfico y crear mejores mapas SLAM (Localización y Mapeo Simultáneos).

Para resolver esto, implementé un enfoque de multiprocesamiento utilizando la biblioteca de multiprocesamiento de Python. Cada Tritón obtuvo su propio proceso dedicado que podía ejecutarse de manera independiente mientras aún era coordinado por un sistema de control central. Esto permitió que múltiples Tritones se movieran simultáneamente sin interferir con los bucles de control de los demás.

Diseño de Arquitectura Multi-Robot

La arquitectura del sistema que desarrollé consistía en varios componentes clave:

Proceso del Controlador Principal: Este servía como el coordinador central, manejando interacciones de la interfaz de usuario, planificación de rutas y coordinación de alto nivel entre robots. Mantenía el estado global y distribuía comandos a los procesos individuales de los robots.

Procesos de Robot Individuales: Cada Tritón tenía su propio proceso de Python dedicado que manejaba:

• Cálculos de control PID en tiempo real a ~50Hz
• Comunicación con el hardware del robot (Arduino/Jetson)
• Ejecución de rutas locales y evitación de obstáculos
• Informes de estado de vuelta al controlador principal

Comunicación de Memoria Compartida: Utilicé los objetos multiprocessing.shared_memory y Queue de Python para habilitar una comunicación eficiente entre procesos. Esto permitió una coordinación en tiempo real sin la sobrecarga de la comunicación de red.

Mecanismos de Sincronización: Para prevenir conflictos cuando múltiples robots necesitaban coordinarse (como evitar colisiones), implementé semáforos y bloqueos que permitían a los robots solicitar acceso exclusivo a ciertas áreas del espacio de trabajo.

El desafío era asegurar que todos los robots pudieran operar sus bucles de control de manera independiente mientras mantenían la coordinación global. Cada proceso de robot ejecutaba sus propios cálculos PID y enviaba comandos de motor directamente al hardware, mientras que el proceso principal manejaba la coordinación de alto nivel como la evitación de colisiones y la planificación de rutas.

El sistema multi-Tritón abrió completamente nuevas posibilidades de investigación. Ahora podíamos simular:

• Escenarios de comunicación vehículo a vehículo
• Planificación de rutas coordinadas con evitación de obstáculos
• Comportamientos de robótica en enjambre
• Mapeo SLAM multi-agente
• Control de formación y comportamientos de seguimiento

Así es como se veía la configuración del laboratorio con múltiples Tritones funcionando simultáneamente:

También desarrollé una interfaz fácil de usar que permitía a los investigadores definir visualmente rutas para cada Tritón. Podías literalmente dibujar la ruta que querías que siguiera cada robot, y ellos ejecutarían estas rutas con perfecta coordinación. Esto fue increíblemente útil para configurar experimentos complejos sin tener que codificar manualmente cada movimiento.

El sistema podía manejar hasta 5 Tritones simultáneamente, cada uno ejecutando sus propios controladores PID mientras eran coordinados a través del sistema de control central. El rendimiento fue impresionante, con todos los robots manteniendo su precisión individual mientras trabajaban juntos como un equipo.

Aquí hay una lista de reproducción que muestra a los Tritones en acción, desde el control de un solo robot hasta la coordinación de múltiples robots: Lista de Reproducción de Tritones en Acción

Integración del Sensor de Profundidad y Corrección de Coordenadas

Otro avance importante en el que trabajé involucró la utilización de las cámaras de profundidad Intel RealSense D435 montadas en cada Tritón. Mientras que el sistema Optitrack nos proporcionaba datos de posicionamiento increíblemente precisos, quería explorar cómo los robots podían usar sus sensores a bordo para mejorar su conciencia espacial y corregir errores de coordenadas.

La idea era que los Tritones pudieran usar sus sensores de profundidad para detectar otros Tritones en su vecindad y cruzar referencias de sus posiciones. Esto serviría a múltiples propósitos:

1. Corrección de Errores: Si el sistema Optitrack tenía algún deslizamiento de calibración o oclusión temporal, los robots podrían usar la confirmación visual de las posiciones de los demás para mantener sistemas de coordenadas precisos.

2. SLAM Mejorado: Al tener múltiples robots con sensores de profundidad trabajando juntos, podríamos crear mapas del entorno mucho más ricos con puntos de datos redundantes.

3. Evitación de Colisiones: La detección de profundidad en tiempo real permitiría a los robots detectar y evitarse entre sí incluso si el sistema de control central tenía retrasos en la comunicación.

Comencé a experimentar con algoritmos que permitirían a los Tritones:

• Detectar otros Tritons usando su distintiva forma triangular y marcadores de esfera reflectante
• Calcular posiciones y orientaciones relativas usando datos de profundidad
• Comparar estas mediciones con los datos de Optitrack para identificar discrepancias
• Potencialmente ajustar su sistema de coordenadas en tiempo real para mantener la precisión

Experimentos de Visión por Computadora

Pasé mucho tiempo experimentando con una cadena de visión por computadora que funcionaba en varias etapas:

Procesamiento de Datos de Profundidad: El Intel RealSense D435 proporcionó tanto flujos de datos RGB como de profundidad. Principalmente trabajé con los datos de profundidad, que llegaban como una matriz de 640x480 de mediciones de distancia a 30 Hz. El primer desafío fue filtrar estos datos de profundidad ruidosos para extraer información geométrica significativa.

Intentos de Detección de Objetos: Experimenté con algoritmos de detección de múltiples etapas. Logré cierto éxito segmentando la imagen de profundidad para identificar objetos a nivel del suelo (filtrando paredes, techo, etc.) y buscando objetos con las características de tamaño adecuadas, aproximadamente una huella de 0.3 × 0.3 metros. Intenté usar detección de bordes y análisis geométrico para identificar el perfil distintivo del Tritón, con resultados mixtos.

Experimentos de Reconocimiento de Marcadores: Las tres esferas reflectantes en cada Tritón parecían ser la característica de detección más prometedora. Experimenté con algoritmos de detección de blobs para identificar el patrón triangular característico de tres puntos brillantes en la imagen de profundidad. Obtuvé algunos resultados prometedores en condiciones de iluminación controlada, aunque no fue consistentemente fiable.

Investigación de Fusión de Coordenadas: Investigé enfoques para fusionar estimaciones de posición basadas en visión con los datos de Optitrack, incluyendo implementaciones básicas de filtros de Kalman. El concepto era dar más peso a los datos de Optitrack cuando estuvieran disponibles, pero recurrir a la visión cuando fuera necesario, aunque no logré que esto funcionara completamente antes de que terminara mi tiempo en el laboratorio.

Desafíos de Rendimiento: Lograr que todo este procesamiento se ejecutara en tiempo real junto con los bucles de control del robot resultó desafiante. Experimenté con enfoques de optimización para ejecutar los algoritmos a alrededor de 10‑15 Hz sin sobrecargar las capacidades de procesamiento del Jetson Nano.

Desafortunadamente, tuve que dejar el laboratorio antes de poder completar totalmente este trabajo de visión por computadora. Aunque obtuve algunos resultados prometedores al principio y aprendí mucho sobre el procesamiento de sensores de profundidad, no logré que el sistema fuera completamente fiable. Siguió siendo una dirección de investigación interesante que otros podrían potencialmente desarrollar.

Aquí hay un video de mí probando los algoritmos de visión por computadora:

Así se veía la vista del sensor de profundidad durante mis experimentos:

Aunque no completé la integración del sensor de profundidad, el concepto mostró potencial para aplicaciones como la simulación de escenarios de vehículos autónomos, donde los vehículos deben ser conscientes de los demás sin depender únicamente de infraestructura externa. La dirección de investigación que comencé a explorar podría contribuir a futuros trabajos en el laboratorio.

Documentación y Preservación del Conocimiento

Una de mis contribuciones más importantes al Laboratorio HCR, y quizás la que más me enorgullece, fue organizar y preservar toda la documentación del proyecto. Cuando me uní al laboratorio, el conocimiento del proyecto Triton estaba disperso en múltiples plataformas y formatos. La información crítica estaba repartida entre:

• Diversas cuentas de Google Drive pertenecientes a diferentes estudiantes que se habían graduado
• Correos electrónicos antiguos enterrados en bandejas de entrada
• Carpetas aleatorias de Dropbox
• Múltiples repositorios de GitHub
• Repositorios de GitLab con organización inconsistente
• Notas manuscritas que solo personas específicas podían interpretar

Esta documentación fragmentada era un gran problema. Los nuevos estudiantes pasaban semanas intentando averiguar cómo comenzar, y el conocimiento valioso se perdía constantemente cuando la gente se graduaba o abandonaba el laboratorio.

Me encargué de resolver este problema de manera sistemática. Pasé innumerables horas rastreando cada pieza de documentación, código, video y nota relacionada con el proyecto Triton. Luego organicé todo en un repositorio centralizado de GitLab con una estructura clara y lógica.

La documentación centralizada incluía:

• Guías de Construcción: Instrucciones paso a paso para ensamblar Tritons desde cero
• Configuración del Software: Guías completas para configurar el entorno de desarrollo
• Documentación del Código: Código bien comentado con explicaciones claras
• Especificaciones de Hardware: Listas de piezas detalladas, diagramas de cableado y diseños de PCB
• Guías de Solución de Problemas: Problemas comunes y sus soluciones
• Tutoriales en Video: Creé y subí videos instructivos a YouTube, incluyendo tutoriales detallados de calibración de Optitrack:

También establecí estándares de documentación para asegurar que futuras contribuciones fueran organizadas y accesibles. La estructura del repositorio que creé se convirtió en la base para todo trabajo posterior en el laboratorio.

Más allá de organizar la documentación existente, creé varias guías y tutoriales originales que llenaron vacíos críticos en la base de conocimientos. Estos incluían instrucciones detalladas para nuevos miembros del laboratorio, guías de solución de problemas exhaustivas y recorridos en video de procedimientos complejos.

El impacto fue inmediato y duradero. Los nuevos estudiantes podían ponerse al día en días en lugar de semanas. El repositorio de documentación que creé sigue siendo usado por el laboratorio hoy, años después de mi partida. Se convirtió en la fuente única de verdad para el proyecto Triton y ahorró innumerables horas/días para futuros investigadores.

Mentoría y Transferencia de Conocimiento

Uno de los aspectos más gratificantes de mi tiempo en el Laboratorio HCR fue la oportunidad de mentorizar a otros y compartir el conocimiento que había adquirido. A medida que mi trabajo avanzaba y me volvía más experimentado con los sistemas Triton, asumí mayor responsabilidad en la capacitación de nuevos miembros del equipo.

Mentoría de Sucesores del Laboratorio

Al prepararme para eventualmente dejar el laboratorio y enfocarme en terminar mi grado y mi trabajo en eBay, me aseguré de entrenar a fondo a dos personas que asumirían el proyecto Triton después de mi partida. No se trataba solo de mostrarles cómo funcionaban las cosas, sino de asegurarse de que comprendieran los principios subyacentes para poder seguir innovando.

• Los fundamentos matemáticos de los sistemas de control PID
• La arquitectura de multiproceso para coordinar múltiples robots
• La integración del sensor de profundidad y los algoritmos de visión por computadora
• El sistema de documentación y cómo mantenerlo
• Técnicas de depuración y modos de falla comunes

La transferencia de conocimiento fue increíblemente exhaustiva. Realizamos sesiones de depuración reales juntos, les hice modificar y ampliar el código existente, y me aseguré de que pudieran configurar nuevos Tritones desde cero de forma independiente.

Programa de Mentoría en la Escuela Secundaria

Quizás aún más gratificante fue mi experiencia mentorando a una estudiante de secundaria a través del programa de divulgación del laboratorio. Fue una gran oportunidad para introducir a alguien en la robótica, la informática y la investigación en una etapa formativa de su educación.

Diseñé un currículo integral que cubría:

Fundamentos de Ciencias de la Computación:

• Conceptos de programación usando Python como lenguaje principal
• Introducción a la programación orientada a objetos
• Comprensión de algoritmos y estructuras de datos

Conceptos de Robótica:

• Cómo funcionan los sensores y cómo interactuar con ellos
• Control de actuadores y sistemas de motor
• Los fundamentos de los sistemas autónomos y control de retroalimentación

ROS (Robot Operating System):

• Comprender el sistema de mensajería publicar/suscribir
• Crear nodos y servicios
• Trabajar con archivos de lanzamiento y servidores de parámetros

Trabajo Práctico:

• Colaboramos en crear un servicio ROS que controlaba el sistema de LED en la cabeza del Tritón
• Aprendió a escribir código limpio y documentado que se integraba con nuestros sistemas existentes
• El servicio de control de LED que creó se convirtió en una parte permanente del código del Tritón

Lo que hizo especial esta mentoría fue observar su progreso desde no saber nada de programación hasta contribuir con código significativo a un proyecto de investigación activo. Pasó de preguntar “¿Qué es una variable?” a depurar de forma independiente problemas de comunicación ROS y escribir sus propias implementaciones de servicios.

El sistema de control de LED que desarrolló permitió a los investigadores cambiar fácilmente los colores y patrones de los LEDs de la cabeza del Tritón mediante simples comandos ROS. Puede parecer simple, pero requirió comprender la arquitectura de ROS, la interfaz de hardware y los patrones de diseño de software adecuados. Su contribución sigue utilizándose en el laboratorio hoy.

La mentoría fue tan educativa para mí como lo fue para ella. Me obligó a descomponer conceptos complejos en piezas digeribles y realmente pensar en los fundamentos de lo que hacíamos. Enseñar a otro me hizo un mejor ingeniero e investigador.

Colaboración con Investigación de Doctorado

Uno de los aspectos más gratificantes profesionalmente de mi tiempo en el laboratorio fue trabajar estrechamente con Peng, un estudiante de doctorado cuya investigación se centró en algoritmos de coches autónomos. Las mejoras de software que realicé al sistema Triton ayudaron a apoyar su investigación doctoral.

La investigación de Peng requería una coordinación multi‑robot precisa y fiable para simular escenarios de coches autónomos. Antes de mis mejoras al control de movimiento y los sistemas multi‑robot, estos experimentos eran mucho más difíciles de realizar. Los robots eran más lentos, menos precisos y no podían trabajar juntos de manera tan eficaz.

Mis contribuciones ayudaron a la investigación de Peng en varias áreas:

Estudios de Gestión de Intersecciones: Con los controladores PID mejorados y la coordinación multi‑robot, Peng pudo simular escenarios de intersección donde múltiples “vehículos” (Tritons) necesitaban coordinar sus movimientos. El mejor timing y posicionamiento ayudaron a que estos estudios fueran más factibles.

Comunicación Vehículo‑a‑Vehículo: El marco de multiproceso que desarrollé permitió a Peng implementar y probar protocolos de comunicación entre vehículos simulados. Cada Triton podía tomar decisiones mientras seguía coordinándose con los demás, similar a cómo los coches autónomos podrían necesitar operar.

Investigación de SLAM y Cartografía: El trabajo de integración del sensor de profundidad proporcionó a Peng datos adicionales para su investigación de localización y mapeo simultáneos. Tener varios robots con capacidades de sensor coordinado permitió experimentos de mapeo más completos.

Lo que hizo nuestra colaboración particularmente valiosa fue que no solo yo ayudaba a su investigación, sino que era una verdadera asociación. La comprensión de Peng de los aspectos teóricos de los vehículos autónomos ayudó a informar mis implementaciones prácticas. Sus comentarios y requisitos me impulsaron a hacer los sistemas más robustos y capaces.

Pasamos muchas horas en el laboratorio juntos, depurando escenarios, discutiendo diferentes estrategias de control y explorando lo que la plataforma Triton podía lograr. Peng se convirtió tanto en colega como en amigo, y trabajar con él me enseñó mucho sobre cómo funciona realmente la investigación académica.

Los sistemas que construí se convirtieron en una parte útil del trabajo de tesis de Peng. Ver que mis contribuciones de ingeniería práctica apoyaban la investigación en tecnología de vehículos autónomos fue realmente gratificante. Reforzó mi interés en cómo la ingeniería sólida y la investigación pueden trabajar juntas para crear resultados útiles.

Incluso después de dejar el laboratorio, Peng y yo seguimos en contacto. Saber que mi trabajo continuó contribuyendo a una investigación importante después de mi partida fue extremadamente gratificante.

Perspectiva: La Era Pre‑LLM del Desarrollo

Vale la pena señalar que todo este trabajo se realizó durante la era pre‑LLM del desarrollo de software. Todo esto tuvo lugar entre 2020 y 2021 (principalmente 2021), antes de que existieran ChatGPT, Claude, Perplexity o herramientas de desarrollo impulsadas por IA como Cursor IDE.

Cada línea de código se escribió desde cero, cada algoritmo se investigó mediante artículos académicos y libros de texto, y cada sesión de depuración involucró métodos tradicionales como declaraciones de impresión, depuradores y pruebas metodológicas. Cuando me quedaba atascado con una transformación de coordenadas o un problema de ajuste de PID, no podía simplemente preguntar a un asistente de IA que explicara el concepto o ayudara a depurar el problema.

Esto hizo que el proceso de desarrollo fuera significativamente más desafiante pero también más educativo. Tuve que:

Investigar Todo Manualmente: Entender la teoría del control PID implicaba leer libros de texto y artículos académicos. Descifrar transformaciones de coordenadas requería trabajar la matemática a mano. Cada concepto debía entenderse completamente antes de implementarlo.

Depurar Sin Asistencia de IA: Cuando los robots se movían en direcciones inesperadas o oscilaban alrededor de los objetivos, tenía que rastrear metódicamente la lógica, añadir salidas de depuración y probar hipótesis una por una. No había IA que sugiriera posibles problemas o ayudara a interpretar patrones de error.

Aprender Desde los Principios: Sin la capacidad de preguntar rápidamente “¿cómo implemento multiproceso en Python para robótica?” tuve que comprender profundamente los conceptos subyacentes. Esto me obligó a construir una base sólida en programación concurrente, sistemas de control y visión por computadora.

La Documentación Era Crítica: Como no podía confiar en una IA para explicar el código después, tuve que escribir documentación y comentarios extremadamente claros. Esta disciplina resultó invaluable al transferir conocimientos a otros.

Mirando atrás, aunque las herramientas modernas de IA habrían acelerado muchos aspectos del desarrollo, trabajar sin ellas me obligó a desarrollar habilidades de resolución de problemas más profundas y una comprensión más completa de los sistemas subyacentes. Es fascinante imaginar cómo habría sido este proyecto con las herramientas de desarrollo actuales.

La Decisión Difícil de Irse

Por mucho que amara trabajar en el HCR Lab, a finales de 2021 enfrenté una decisión difícil que muchos estudiantes encuentran: equilibrar múltiples oportunidades y responsabilidades. Simultáneamente trabajaba a tiempo completo como ingeniero de software en eBay, terminaba mi licenciatura en Ciencias de la Computación en Mines y contribuía a la investigación en el HCR Lab.

La oportunidad en eBay era significativa; era mi primer puesto importante de ingeniería de software, me brindó experiencia industrial invaluable y me proporcionó un ingreso sólido. Sin embargo, intentar mantener un trabajo a tiempo completo, terminar mi grado y contribuir significativamente a la investigación era simplemente insostenible. Algo tenía que ceder.

Cuando le planteé al Dr. Zhang la posibilidad de reducir mi carga de cursos para enfocarme más en el trabajo de laboratorio, él me aconsejó firmemente que no lo hiciera. Su razonamiento era sólido: completar mi grado debía ser la prioridad, y la experiencia industrial en eBay sería valiosa para mi desarrollo profesional. Creía que abandonar clases para enfocarse en la investigación, aunque tentador, podría no ser la mejor decisión a largo plazo.

Así que en septiembre de 2021, después de unos 8 meses de trabajo intensivo en el laboratorio, tomé la difícil decisión de retirarme de mi rol de asistente de investigación para enfocarme en terminar mi grado y mi trabajo en eBay. Fue una de las decisiones profesionales más difíciles que he tenido que tomar en ese momento.

Incluso después de dejar oficialmente el laboratorio, continué brindando apoyo siempre que alguien necesitaba ayuda con los sistemas que había construido. Actualicé la documentación según fuera necesario, respondí preguntas sobre depuración y ayudé a solucionar problemas de forma remota. Las conexiones que había creado y la inversión que había hecho en el éxito del proyecto no desaparecieron simplemente porque ya no formaba parte oficialmente del equipo.

Reflexiones y Mirada al Pasado

Ahora, en 2025, cuatro años después, me encuentro reflexionando sobre ese tiempo con emociones complejas. Mi trayectoria profesional me llevó profundamente al desarrollo web y a la ingeniería de IA/ML, áreas que han sido increíblemente gratificantes y han brindado oportunidades enormes de crecimiento e impacto.

Sin embargo, hay una parte de mí que se pregunta “¿qué pasaría si?”. La robótica fue, y honestamente sigue siendo, mi verdadera pasión. Hay algo en trabajar con sistemas físicos, ver tu código traducirse en movimiento y comportamiento reales, que el desarrollo web e incluso el trabajo de IA no pueden replicar completamente.

A veces me pregunto qué habría pasado si hubiera tomado un camino diferente. ¿Qué habría pasado si hubiera encontrado una manera de quedarme en la investigación de robótica? ¿Qué habría pasado si hubiera continuado directamente a la escuela de posgrado después de terminar mi licenciatura? ¿Qué habría pasado si hubiera priorizado el trabajo de laboratorio sobre la experiencia industrial?

Pero también reconozco que cada camino tiene sus compromisos. Las habilidades que desarrollé en desarrollo web e IA han sido increíblemente valiosas. La experiencia industrial me enseñó sobre ingeniería de software a gran escala, diseño de experiencia de usuario y los desafíos prácticos de construir productos que millones de personas usan. Estas experiencias me han convertido en un mejor ingeniero en general.

El trabajo que hice en el HCR Lab sigue influyendo en cómo abordo los problemas hoy. El pensamiento sistemático requerido para los sistemas de control PID se refleja en cómo diseño bucles de retroalimentación en sistemas de software. Las habilidades de documentación y preservación del conocimiento que desarrollé han sido invaluables en cada rol desde entonces. La experiencia de mentoría y enseñanza ha moldeado cómo trabajo con desarrolladores junior y contribuyo al intercambio de conocimientos en equipos.

Lo más importante es que la experiencia me enseñó que prospero cuando trabajo en problemas técnicos desafiantes que tienen impacto real. Ya sea optimizando algoritmos de movimiento de robots o construyendo sistemas de IA que ayudan a los usuarios a lograr sus objetivos, la satisfacción proviene de resolver problemas difíciles que importan.

El Impacto Duradero

Al mirar atrás la experiencia en el HCR Lab, me sorprende cuánto logré en un tiempo relativamente corto. Los sistemas que construí cambiaron fundamentalmente cómo operaba la plataforma Triton, y muchas de esas mejoras siguen utilizándose hoy. El repositorio de documentación que creé se convirtió en la base de conocimiento para todo el proyecto. Las relaciones de mentoría que establecí tuvieron un impacto duradero en las personas con las que trabajé.

Pero quizás lo más significativo es que la experiencia me mostró lo que soy capaz de lograr cuando trabajo en problemas que realmente me apasionan. En esos ocho meses, yo:

• Mejoré el sistema de control de movimiento del robot que limitaba la plataforma
• Construí un sistema de coordinación multi‑robot desde cero
• Integré visión por computadora y capacidades de fusión de sensores
• Creé un sistema integral de documentación y gestión del conocimiento
• Mentoricé a varias personas y ayudé con la transferencia de conocimientos
• Apoyé investigación de nivel doctoral en vehículos autónomos

Esto no se trataba solo de los logros técnicos, aunque esos fueron significativos para mí. Se trataba de aprender que con persistencia y pensamiento sistemático, puedes hacer contribuciones útiles incluso como estudiante de pregrado.

El Futuro y la Robótica

Aunque mi carrera me ha llevado en otras direcciones, mi pasión por la robótica no ha disminuido. Sigo siguiendo los desarrollos en el campo, estoy emocionado por los avances en el aprendizaje de robots y sistemas autónomos, y ocasionalmente trabajo en proyectos personales de robótica en mi tiempo libre.

¿Quién sabe qué depara el futuro? Las habilidades que estoy desarrollando en IA y aprendizaje automático son cada vez más relevantes para la robótica. La experiencia industrial que he adquirido me ha enseñado cómo construir sistemas robustos y escalables. Tal vez haya un futuro donde estos diferentes hilos de mi experiencia se unan de maneras inesperadas.

Por ahora, estoy agradecido por el tiempo que pasé en el Laboratorio HCR y las experiencias que proporcionó. Fue un período formativo que moldeó tanto mis habilidades técnicas como mi comprensión de los tipos de trabajo que encuentro más gratificantes. Aunque a veces lo extraño, sé que las lecciones que aprendí y los enfoques que desarrollé continúan influyendo en todo lo que hago.

Los robots todavía están allí, todavía sirven a los investigadores, siguen facilitando trabajos importantes. Y eso es bastante maravilloso.