Mi Capítulo de Investigación en Robótica

Esta publicación relata mi trayectoria en robótica, comenzando con el descubrimiento de mi pasión por la robótica en FRC durante la escuela secundaria en 2015 hasta mi tiempo como asistente de investigación en el Human Centered Robotics (HCR) Lab de la Colorado School of Mines desde febrero de 2021 hasta septiembre de 2021. Ten en cuenta que desde finales de 2022, el HCR Lab se trasladó de la Colorado School of Mines a la University of Massachusetts Amherst, junto con su sitio de hcr.mines.edu a hcr.cs.umass.edu.

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 un enfoque en Robótica y Sistemas Inteligentes. Y me gradué en la primavera de 2022.

Tuve la suerte de encontrar mi pasión temprano en mi vida. Durante la escuela secundaria, dediqué bastante tiempo a averiguar qué me gustaba y en qué podía ser bueno. Después de prueba y error, pude darme cuenta de que mi pasión era la informática. Pero también fue durante este tiempo cuando descubrí que tenía este abrumador amor por construir a través del código.

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

Clase de Human Centered Robotics (CSCI473)

Human Centered Robotics (CSCI473) de Mines fue una de las pocas clases de mi experiencia universitaria que tuvo un profundo impacto en mí. La clase fue impartida por el Dr. Hao Zhang. Toda nuestra calificación para la clase estaba compuesta por solo tres proyectos, cada uno de los cuales presentaba un problema desafiante que introducía conceptos fundamentales de la robótica. Estos proyectos consistían en:

1. Aprender Robot Operating System (ROS)
2. Aprendizaje por Refuerzo para el Seguimiento de Paredes por un Robot
3. Comprensión por Parte del Robot de los Comportamientos Humanos Usando Representaciones Basadas en el Esqueleto

Aprender Robot Operating System (ROS)

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

1. Configurar el Entorno de Desarrollo
2. Entender el Simulador Gazebo
3. Escribir un “Hola Mundo” en ROS

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

• Configurar ROS Melodic, que hice en mi portátil HP de 2011, que era suficiente
• Instalar y configurar ROS y Gazebo
• Seguir el tutorial de gazebosim y el tutorial de 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 logotipo “M” de Mines:

Esta tarea, aunque sonaba simple, fue más difícil de lo que parecía. Este proyecto eventualmente me introdujo al concepto de sistemas de lazo abierto y de lazo cerrado. Para la descripción completa del proyecto, consulta csci473-p1.pdf o puedes aprender más sobre este proyecto y mi solución en la página del proyecto ROS Move Turtle.

Aprendizaje por Refuerzo para el Seguimiento de Paredes por un Robot

Este fue el segundo proyecto que se nos asignó, y fue uno de los proyectos más difíciles en los que trabajé 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 utilizarán la simulación Gazebo en ROS Melodic para simular un robot móvil omnidireccional llamado Triton, y utilizarán un mapa del entorno que se les proporciona. Los estudiantes utilizarán un escáner láser de alcance 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 sobre Ubuntu 18.04 LTS (es decir, el mismo entorno de desarrollo utilizado en el Proyecto 1). Además, se requiere que los estudiantes escriban un informe siguiendo el formato de las conferencias estándar de robótica de IEEE 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 consistía en el modelo Triton y la lógica de física. También se nos proporcionó un laberinto para que el robot lo siguiera. En conjunto, el entorno se veía así:

Nunca publiqué mi solución en GitHub ni en la web porque no era muy buena y tenía muchos fallos. Además, hacer que el código funcione en el entorno correcto es bastante difícil y molesto. Sin embargo, sí tengo un video demo que entregué a la clase, mostrando mi solución. Puedes verlo aquí:

Para la descripción completa del proyecto, consulta csci473-p2.pdf

Comprensión por Parte del Robot de los Comportamientos Humanos Usando Representaciones Basadas en el Esqueleto

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

En este proyecto, los estudiantes implementarán varias representaciones basadas en esqueleto (Entregable 1) y usarán Máquinas de Vectores de Soporte (SVMs) (Entregable 2) para clasificar comportamientos humanos usando un conjunto de datos de actividad pública recopilado de un sensor Kinect V1. Además, se requiere que los estudiantes escriban un informe siguiendo el formato de las conferencias estándar de robótica de IEEE 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. Para la descripción completa del proyecto, consulta csci473-p3.pdf o puedes aprender más sobre este proyecto y mi solución en la publicación del blog Predecir Acciones Humanas Usando LIBSVM.

Conclusión de CSCI473

CSCI473 es una de las mejores, 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 genial de proyectos para reflexionar y consultar en mi currículum. También fue la primera clase en la que sentí que estaba en mi elemento, ya que nunca fui bueno para los exámenes pero destaqué al completar proyectos. También fue a través de esta clase que conocí al Dr. Hao Zhang, quien eventualmente me ayudó a asegurar un puesto como asistente de investigación en el HCR Lab centrado en el ser humano de Mines.

Sesión de Campo de CS (Verano de 2020)

Durante el verano de 2020, entre completar CSCI473 y unirme al HCR Lab, 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 relacionadas con software para una empresa. Permite a los estudiantes aplicar los conocimientos de sus cursos 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 vas a trabajar. El curso proporcionaba PDFs que detallaban cada proyecto y empresa. Finalmente decidí trabajar en un proyecto publicado por una empresa llamada 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, demos al proyecto un alias de “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 se sabe que causa mucho deslizamiento de ruedas. Esto no es ideal porque el deslizamiento de ruedas puede hacer que los sistemas autónomos pierdan el seguimiento de su ubicación en el mundo real. En la Tierra, esto se resuelve usando datos GPS para corregir cualquier desplazamiento causado por el deslizamiento de ruedas. Pero el problema con el GPS es que solo funciona teniendo 30+ satélites de navegación orbitando constantemente la Tierra y transmitiendo señales únicas que permiten a las computadoras calcular su posición. Pero en la luna, actualmente no existe algo como un GPS. Sabiendo esto, hay que usar otro método además del GPS para detectar el deslizamiento de ruedas. Puede consultarse un informe más detallado del problema del proyecto aquí.

El Equipo

Este proyecto no era un proyecto simple, así que tenía que hacerse en equipo. El equipo estaba formado por cinco compañeros estudiantes de la Colorado School of Mines:

Este proyecto no era un proyecto simple, así que tenía que hacerse en equipo. Este equipo estaba formado por Mehmet Yilmaz (yo), Kane Bruce, Braedon O’Callaghan, Liam Williams y Kevin Grant.

El proyecto requería que conociéramos algo de ROS, C++, Python, Linux, Raspberry Pi y Arduino. La mayoría de nosotros tenía experiencia en una o más de estas tecnologías, pero yo era el único con experiencia en ROS, ya que usé ROS en mi clase de Human Centered Robotics (CSCI473) durante el semestre de primavera de 2020. Debido a esto, al principio, ayudé a poner a todos al día sobre ROS y cómo desarrollar para él.

Desafíos

En este proyecto hubo muchos desafíos. Pero el mayor desafío que enfrentamos fue no tener acceso a un robot del mundo real para hacer pruebas. Esto se debió a que COVID hizo que todo fuera remoto e impidió que trabajáramos en el laboratorio/los edificios de Lunar Outpost. Debido a esto, tuvimos que usar simulaciones.

Además, revisamos algunas investigaciones académicas del WVU Navigation Lab para obtener una idea de cómo podría resolverse el problema del deslizamiento de las ruedas para el caso de uso de Lunar Outpost, lo cual, para nosotros, como estudiantes de segundo y tercer año de licenciatura, 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 enorme que muchas empresas y académicos han intentado resolver/perfeccionar durante décadas. Así que un mes está muy lejos de ser suficiente tiempo para resolver este problema. Pero, a pesar de todos estos desafíos, seguimos adelante y nos aseguramos de entregar.

Conclusión

Después de trabajar en toda la investigación y el desarrollo, determinamos que es casi imposible simular correctamente la física lunar de forma digital, así que realmente intentar este algoritmo en una simulación no sirve y no va a producir ninguna investigación significativa en la detección del deslizamiento de ruedas en el espacio y en la luna. Concluimos que configurar 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. Sí actualizamos el código de detección de deslizamiento de ruedas para que funcionara como un nodo de ROS y funcionó correctamente y pudo importarse fácilmente en hardware real para hacer pruebas. Este proyecto me permitió asumir un rol de liderazgo, educar a mis compañeros sobre el desarrollo con ROS y ganar experiencia con Python, ROS y Gazebo mientras abordaba un problema complejo que nunca antes había encontrado. Lo más importante es que esta experiencia consolidó aún más mi pasión por la robótica y reforzó mi deseo de dedicarme a la investigación en el campo, preparando el escenario para lo que vendría después en mi trayectoria en robótica.

Comenzando en el laboratorio HCR

Después de completar CSCI473, mi sesión de campo de CS en el verano de 2020, y mi semestre de otoño de 2020, decidí dedicarme a la investigación en robótica. Tuve experiencias tan excelentes tanto con CSCI473 como con la sesión de campo de CS que decidí que quería hacer investigación para el laboratorio HCR. Como había conocido al Dr. Zhang el año anterior, decidí escribirle por correo electrónico y preguntarle sobre cualquier oportunidad que el laboratorio pudiera tener en enero de 2021. En unas 2 semanas, el Dr. Zhang mostró interés, me presentó opciones de investigación y me ofreció un puesto en el laboratorio. Luego empecé a trabajar para el laboratorio en febrero de 2021.

Video de introducción

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

Mi proyecto

A lo largo de mi tiempo en el laboratorio HCR, 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, impulsado por la Jetson Nano de NVIDIA.

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

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

Fue diseñado, construido y fabricado aproximadamente entre 2018 y 2020 como un robot con fines educativos. Para cuando me uní, el Triton ya estaba bastante consolidado, y el laboratorio estaba considerando hacer una nueva versión de él. Sin embargo, el principal problema del Triton era su software. El Triton podía moverse, cargarse y funcionar en un sentido básico, pero realmente no hacía nada inteligente. Incluso carecía de la capacidad de realizar movimientos más avanzados.

Para empezar a abordar esto, el laboratorio preparó un área donde pudiéramos hacer seguimiento del Triton. Para ello, crearon un área de 2 metros por 2 metros con 8 cámaras Optitrack Flex (infrarrojas) en una forma similar a un cuadrado a unos 6-7 pies por encima del suelo.

Además de construir esta área, a cada Triton se le colocaron tres esferas grises 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 área de interés. Al usar las cámaras infrarrojas Optitrack y las esferas grises de Optitrack en forma triangular, podíamos localizar con precisión las coordenadas exactas de un Triton en nuestra área. Esto nos permitió aplicar un sistema de lazo cerrado para una mejor precisión en el movimiento.

El sistema Optitrack proporcionaba datos de posición y orientación a unos 120 Hz con precisión submilimétrica cuando estaba correctamente calibrado. 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 estaba calibrado 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 sala. Pero, a pesar de estos datos de posicionamiento precisos, el Triton seguía teniendo dificultades con el movimiento.

Con esta configuración, una característica fundamental 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. Luego, el robot se movería a esa coordenada lo más rápido, con la mayor precisión y de la manera más fluida posible. Cuando me uní, esta función existía pero no funcionaba muy bien. Aquí hay una animación sencilla que muestra cómo funcionaba la lógica de movimiento original:

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

1. Es realmente lento
2. Hace que el robot ocupe mucho espacio solo para ir a un punto específico. Esto nos dificultaba usar esta solución cuando varios Tritons se movían al mismo tiempo.

Entonces, ¿por qué ocurría este comportamiento? El problema era que el Triton primero giraba, cambiando su alpha, hasta que apuntaba hacia el punto objetivo dentro de un margen de error específico. Luego aceleraba hacia adelante, y después de que su theta se desviaba del objetivo por una cantidad determinada, se detenía y comenzaba a girar de nuevo hasta que el alpha estuviera dentro de ese rango aceptable para el objetivo. Luego vuelve a acelerar y sigue haciendo esto hasta llegar al punto. Además, a medida que se acercaba más y más al punto objetivo, la velocidad de giro y de aceleración se volvía mucho más lenta para asegurarse de que no se pasara de largo. Esto hacía que el Triton tuviera un movimiento antinatural, tardara una eternidad en llegar a un punto objetivo y requiriera una cantidad de espacio enorme solo para llegar a un punto objetivo específico. Así que, con todos estos problemas, y dado lo esencial que era esta característica para el desarrollo del proyecto Triton, cuando empecé a trabajar en el laboratorio HCR, mi primera tarea fue desarrollar soluciones más eficaces que permitieran al Triton navegar mejor hacia un punto objetivo.

Sabiendo esto, pasé mucho tiempo investigando la mejor manera posible de abordar este problema. Irónicamente, estaba tomando una clase llamada Introducción a los Sistemas de Control por Realimentación (EENG307) en Mines. Al principio de esa clase, aprendimos sobre el concepto de controladores de lazo abierto y controladores de lazo cerrado. Sabiendo esto, y después de algunas conversaciones que tuve con el profesor de esa clase y con mi compañero de cuarto, que es muy inteligente, quedó claro que este objetivo de llevar al Triton a un punto objetivo era un problema de sistema de lazo cerrado.

Ahora, después de pruebas e investigaciones extensas, desarrollé dos enfoques de controlador distintos para los Tritons:

Método 1: Controlador Distancia-Theta

Este enfoque utilizaba dos controladores proporcionales separados que funcionaban simultáneamente:

• Controlador de distancia: Calculaba la distancia euclidiana al objetivo y aplicaba una ganancia proporcional para determinar la velocidad hacia adelante/hacia atrás
• Controlador de theta: Calculaba el error angular entre la orientación actual del robot y la orientación deseada hacia el objetivo, aplicando una ganancia proporcional separada para la velocidad rotacional

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

Esto hizo que el Triton girara de forma natural hacia el objetivo mientras avanzaba simultáneamente, creando trayectorias curvas suaves. La ventaja clave era que el robot siempre mantenía su cara frontal orientada hacia el destino, lo cual era crucial para aplicaciones basadas en cámara.

Método 2: Controlador de Coordenadas X-Y

Este enfoque trataba al robot como un trazador 2D, con control independiente del movimiento en X e Y:

• Controlador X: Controlaba directamente el movimiento este-oeste según el error de la coordenada X
• Controlador Y: Controlaba directamente el movimiento norte-sur según el error de la coordenada Y

La implementación calculaba los errores de las coordenadas X e Y de forma independiente, aplicaba ganancias proporcionales separadas y luego transformaba estos componentes globales de velocidad al marco de coordenadas local del robot utilizando matrices de rotación. Esta transformación era necesaria porque el tren de transmisión de ruedas omnidireccionales del robot requería velocidades en su propio marco de referencia, no en coordenadas globales. Este método producía las trayectorias más directas hacia los objetivos y era significativamente más rápido, pero la orientación del robot se desviaba, ya que no había un control explícito de la orientación.

Para el método #1, expliqué en detalle este método en mi blog de 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 usando TurtleSim de ROS, y luego transferí ese código al Triton y lo actualicé para adaptarlo a un entorno más real.

El método #2 utilizó un enfoque bastante diferente pero igualmente eficaz. 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 las direcciones X e Y por separado. Por ejemplo, si el robot necesita moverse de (0,0) a (2,3), esto se interpreta como la necesidad de corregir un error de 2 metros en X y un error de 3 metros en Y. Dos controladores proporcionales funcionaban simultáneamente: uno ajustaba la velocidad del robot en la dirección X según el error en X, mientras que el otro manejaba el movimiento en la dirección Y según el error en Y. Esto creó una ruta más directa hacia el objetivo, similar a cómo se mueve el cabezal de una impresora 3D, y permitió movimientos diagonales suaves. El robot no necesitaba girar explícitamente para mirar hacia su objetivo, lo que hacía que este método fuera particularmente eficaz en espacios reducidos o cuando se requiere un posicionamiento preciso.

Ambos métodos demostraron ser significativamente más rápidos y más fiables que el enfoque original. Para ver estos nuevos métodos en acción, consulta la lista de reproducción Tritons in Action, que muestra a todos los Tritons en acción con los nuevos métodos.

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

Desafíos de desarrollo y depuración

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

Transformaciones del sistema de coordenadas: Uno de los aspectos más complicados fue lograr que las transformaciones de coordenadas fueran correctas. El sistema Optitrack proporcionaba datos en su propio marco de coordenadas, el robot tenía su marco de coordenadas local, y yo necesitaba convertir entre ellos con precisión. Las primeras implementaciones hacían que los robots se movieran en las direcciones equivocadas porque había confundido los cálculos de las matrices de rotación.

Comportamiento del mundo real frente al 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 forma idéntica y siempre había cierta latencia en la cadena de comunicación desde Optitrack hasta el software de control y luego hasta el Arduino del robot. Pasé semanas ajustando las ganancias proporcionales y añadiendo filtros de banda muerta para tener en cuenta estas realidades físicas.

Problemas de oscilación y estabilidad: Mis primeras implementaciones sufrían problemas de oscilación en los que los robots sobrepasaban sus objetivos y se balanceaban de un lado a otro. Esto me enseñó la importancia de los términos derivativos en los controladores PID y la necesidad de ajustar adecuadamente las ganancias. Finalmente me decanté por un control predominantemente proporcional con ganancias cuidadosamente ajustadas en lugar de 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 mutuo en las que se impedían el paso indefinidamente. Esto me llevó a implementar mecanismos de coordinación y algoritmos de evitación de colisiones.

Sistema de control multi-Triton

Una vez que resolví el problema del movimiento de un solo Triton, el siguiente desafío del laboratorio fue lograr que varios Tritons 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 Triton a la vez, lo que limitaba enormemente las posibilidades de investigación. El laboratorio quería simular escenarios en los que múltiples vehículos autónomos necesitaran coordinar sus movimientos, como coches autónomos que se comunican entre sí para optimizar el flujo de tráfico y crear mapas SLAM (Localización y Mapeo Simultáneos) mejores.

Para resolver esto, implementé un enfoque de multiprocesamiento usando la biblioteca multiprocessing de Python. Cada Triton obtenía su propio proceso dedicado que podía ejecutarse de forma independiente mientras seguía siendo coordinado por un sistema de control central. Esto permitía que varios Tritons se movieran simultáneamente sin interferir con los bucles de control de los demás.

Diseño de la arquitectura multi-robot

La arquitectura del sistema que desarrollé constaba de varios componentes clave:

Proceso controlador principal: Este servía como coordinador central, encargándose de las interacciones de la interfaz de usuario, la planificación de rutas y la coordinación de alto nivel entre robots. Mantenía el estado global y distribuía comandos a los procesos de robots individuales.

Procesos de robots individuales: Cada Triton tenía su propio proceso de Python dedicado que se encargaba de:

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

Comunicación en memoria compartida: Usé multiprocessing.shared_memory y objetos Queue de Python para permitir una comunicación eficiente entre procesos. Esto permitió una coordinación en tiempo real sin la sobrecarga de la comunicación por red.

Mecanismos de sincronización: Para evitar conflictos cuando varios 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 consistía en garantizar que todos los robots pudieran operar sus bucles de control de forma independiente mientras seguían manteniendo 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 nivel superior, como la evitación de colisiones y la planificación de rutas.

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

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

Así es como se veía la configuración del laboratorio con varios Tritons funcionando simultáneamente:

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

El sistema podía manejar hasta 5 Tritons simultáneamente, cada uno ejecutando sus propios controladores PID mientras estaba coordinado 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 Tritons en acción, desde el control de un solo robot hasta la coordinación de múltiples robots: Lista de reproducción Tritons in Action

Integración de sensores de profundidad y corrección de coordenadas

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

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

1. Corrección de errores: Si el sistema Optitrack tuviera algún desvío de calibración o una 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 varios robots con sensores de profundidad trabajando juntos, podríamos crear mapas mucho más ricos del entorno con puntos de datos redundantes.

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

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

• Detectar otros Tritons usando su distintiva forma triangular y marcadores esféricos reflectantes
• 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é una cantidad considerable de tiempo experimentando con una canalización de visión por computadora que funcionaba en varias etapas:

Procesamiento de Datos de Profundidad: El Intel RealSense D435 proporcionaba flujos de datos tanto RGB como de profundidad. Trabajé principalmente con los datos de profundidad, que venían como una matriz de 640x480 de mediciones de distancia a 30Hz. 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. Tuve 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.3x0.3 metros. Probé usar detección de bordes y análisis geométrico para identificar el perfil distintivo de Triton, con resultados mixtos.

Experimentos de Reconocimiento de Marcadores: Las tres esferas reflectantes de cada Triton 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. Obtuve algunos resultados prometedores en condiciones de iluminación controladas, aunque no era consistentemente confiable.

Investigación de Fusión de Coordenadas: Investigué enfoques para fusionar estimaciones de posición basadas en visión con los datos de Optitrack, incluidas 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 llegué a hacer que esto funcionara por completo antes de que terminara mi tiempo en el laboratorio.

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

Desafortunadamente, tuve que dejar el laboratorio antes de poder completar por completo este trabajo de visión por computadora. Si bien tuve algunos resultados iniciales prometedores y aprendí mucho sobre el procesamiento de sensores de profundidad, no logré llevar el sistema a un estado completamente confiable. Seguía siendo una dirección de investigación interesante sobre la que otros podrían potencialmente construir.

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

Así era la vista del sensor de profundidad durante mis experimentos:

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

Documentación y Preservación del Conocimiento

Una de mis contribuciones más importantes al HCR Lab, y quizá 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:

• Varias cuentas de Google Drive pertenecientes a distintos estudiantes que ya 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 ciertas personas podían interpretar

Esta documentación fragmentada era un problema enorme. Los nuevos estudiantes pasaban semanas solo tratando de averiguar cómo empezar, y el conocimiento valioso se perdía constantemente cuando la gente se graduaba o dejaba el laboratorio.

Decidí encargarme de resolver este problema de forma sistemática. Pasé incontables horas rastreando cada pieza de documentación, código, video y nota relacionados 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 detalladas de piezas, 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, incluidos tutoriales detallados de calibración de Optitrack:

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

Más allá de simplemente organizar la documentación existente, creé varias guías y tutoriales originales que llenaron vacíos críticos en la base de conocimiento. Estos incluían instrucciones detalladas de configuración para nuevos miembros del laboratorio, guías completas de solución de problemas 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é todavía lo usa el laboratorio hoy en día, años después de que me fui. Se convirtió en la única fuente de verdad para el proyecto Triton y ahorró incontables horas/días a futuros investigadores.

Mentoría y Transferencia de Conocimiento

Uno de los aspectos más gratificantes de mi tiempo en el HCR Lab 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í una responsabilidad cada vez mayor en la formación de nuevos miembros del equipo.

Mentoría a los Sucesores del Laboratorio

Mientras me preparaba para eventualmente dejar el laboratorio para concentrarme en terminar mi carrera y mi trabajo en eBay, me aseguré de capacitar a fondo a dos personas que tomarían el relevo del proyecto Triton después de mi partida. No se trataba solo de mostrarles cómo funcionaban las cosas, sino de asegurarse de que realmente entendieran los principios subyacentes para que pudieran seguir innovando.

Pasé semanas trabajando estrechamente con ellos, revisando:

• Los fundamentos matemáticos de los sistemas de control PID
• La arquitectura de multiprocesamiento 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 fallo comunes

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

Programa de Mentoría para Estudiantes de Secundaria

Quizá incluso más gratificante fue mi experiencia mentorando a una estudiante de secundaria a través del programa de divulgación del laboratorio. Esta 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 plan de estudios 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 motores
• Los fundamentos de los sistemas autónomos y el control por retroalimentación

ROS (Robot Operating System):

• Comprensión del sistema de mensajería publicar/suscribir
• Creación de nodos y servicios
• Trabajo con archivos de lanzamiento y servidores de parámetros

Trabajo de Proyecto Práctico:

• Colaboramos en la creación de un servicio de ROS que controlaba el sistema de LED en la cabeza de Triton
• 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 de la base de código de Triton

Lo que hizo que esta mentoría fuera particularmente especial fue ver su progreso desde no saber prácticamente nada de programación hasta contribuir 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 de ROS y escribir sus propias implementaciones de servicios.

El sistema de control de LED que desarrolló permitía a los investigadores cambiar fácilmente los colores y patrones de los LED de la cabeza de Triton mediante simples comandos de ROS. Esto puede sonar sencillo, pero requería entender la arquitectura de ROS, la interfaz con el hardware y patrones adecuados de diseño de software. Su contribución todavía se usa en el laboratorio hoy en día.

La mentoría fue tan educativa para mí como lo fue para ella. Me obligó a desglosar conceptos complejos en partes digeribles y a pensar realmente en los fundamentos de lo que estábamos haciendo. Enseñarle a otra persona me convirtió en un mejor ingeniero e investigador.

Colaboración con la Investigación de Doctorado

Uno de los aspectos más gratificantes profesionalmente de mi tiempo en el laboratorio fue trabajar de cerca con Peng, un estudiante de doctorado cuya investigación se centraba en algoritmos para coches autónomos. Las mejoras de software que había hecho al sistema Triton ayudaron a respaldar su investigación doctoral.

La investigación de Peng requería una coordinación precisa y fiable de múltiples robots para simular escenarios de coches autónomos. Antes de mis mejoras al control de movimiento y a los sistemas multi-robot, estos experimentos eran mucho más difíciles de llevar a cabo. Los robots eran más lentos, menos precisos y no podían trabajar juntos con tanta eficacia.

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 en los que varios “vehículos” (Tritons) necesitaban coordinar sus movimientos. El mejor tiempo y posicionamiento ayudaron a que estos estudios fueran más factibles.

Comunicación Vehículo a Vehículo: El marco de multiprocesamiento 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, de manera similar a cómo los coches autónomos podrían necesitar operar.

Investigación de SLAM y Mapeo: 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 múltiples robots con capacidades de detección coordinadas permitió experimentos de mapeo más completos.

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

Pasamos muchas horas juntos en el laboratorio, depurando escenarios, discutiendo diferentes estrategias de control y explorando lo que la plataforma Triton podía lograr. Peng se convirtió tanto en un colega como en un 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 mis contribuciones de ingeniería práctica apoyar la investigación en tecnología de vehículos autónomos fue realmente satisfactorio. 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 mantuvimos el contacto. Saber que mi trabajo siguió contribuyendo a una investigación importante incluso después de mi partida fue extremadamente gratificante.

Perspectiva: La era previa a los LLM del desarrollo

Vale la pena señalar que todo este trabajo se llevó a cabo durante la era previa a los 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 implicó métodos tradicionales como instrucciones de impresión, depuradores y pruebas metódicas. Cuando me quedaba atascado en un problema de transformación de coordenadas o de ajuste de PID, no podía simplemente pedirle a un asistente de IA que me explicara el concepto o me 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 significaba leer libros de texto y artículos académicos. Resolver transformaciones de coordenadas requería trabajar las matemáticas a mano. Cada concepto tenía que 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 Primeros Principios: Sin la capacidad de preguntar rápidamente “¿cómo implemento multiprocesamiento en Python para robótica?” tenía 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 Fundamental: Como no podía confiar en la IA para explicar el código más adelante, tenía que escribir documentación y comentarios extremadamente claros. Esta disciplina resultó invaluable al transferir conocimiento a otros.

Mirando hacia atrás, aunque las herramientas modernas de IA habrían acelerado muchos aspectos del desarrollo, trabajar sin ellas me obligó a desarrollar habilidades más profundas para resolver problemas y una comprensión más completa de los sistemas subyacentes. Es fascinante pensar en lo diferente que habría sido este proyecto con las herramientas de desarrollo de hoy disponibles.

La Difícil Decisión de Irme

Por mucho que amara trabajar en el Laboratorio HCR, para finales de 2021 me enfrenté a una decisión difícil que muchos estudiantes encuentran: equilibrar múltiples oportunidades y responsabilidades. Estaba trabajando simultáneamente a tiempo completo como ingeniero de software en eBay, terminando mi carrera de informática en Mines y contribuyendo a la investigación en el Laboratorio HCR.

La oportunidad en eBay era significativa; fue mi primer gran puesto de ingeniería de software, me proporcionó una experiencia invaluable en la industria y me brindó unos ingresos sólidos. Sin embargo, intentar mantener un trabajo a tiempo completo, completar mi carrera y contribuir de manera significativa a la investigación era simplemente insostenible. Algo tenía que ceder.

Cuando me acerqué al Dr. Zhang para plantearle la posibilidad de reducir mi carga de cursos para centrarme más en el trabajo del laboratorio, me aconsejó firmemente que no lo hiciera. Su razonamiento era sólido: completar mi título debía ser la prioridad, y la experiencia en la industria en eBay sería valiosa para mi desarrollo profesional. Sentía que dejar las clases para centrarme en la investigación, aunque tentador, quizá no sería 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 apartarme de mi puesto de asistente de investigación para centrarme en completar mi título y mi trabajo en eBay. Fue una de las decisiones profesionales más difíciles que tuve que tomar en ese momento.

Incluso después de dejar oficialmente el laboratorio, seguí brindando apoyo siempre que alguien necesitaba ayuda con los sistemas que había construido. Actualizaba la documentación según era necesario, respondía preguntas sobre depuración y ayudaba a resolver problemas a distancia. Las conexiones que había establecido y el compromiso que tenía con el éxito del proyecto no desaparecieron solo porque ya no formara oficialmente parte del equipo.

Reflexiones y Mirando Hacia Atrás

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 me han brindado enormes oportunidades de crecimiento e impacto.

Sin embargo, hay una parte de mí que se pregunta “qué habría pasado si”. La robótica era, y honestamente sigue siendo, mi verdadera pasión. Hay algo en trabajar con sistemas físicos, ver cómo tu código se traduce en movimiento y comportamiento del mundo real, que el desarrollo web e incluso el trabajo en IA no pueden replicar del todo.

A veces me pregunto qué habría pasado si hubiera tomado un camino diferente. ¿Qué habría pasado si hubiera encontrado una manera de seguir en la investigación robótica? ¿Qué habría pasado si hubiera cursado estudios de posgrado inmediatamente después de terminar mi licenciatura? ¿Qué habría pasado si hubiera elegido priorizar el trabajo del laboratorio sobre la experiencia en la industria?

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

El trabajo que hice en el Laboratorio HCR sigue influyendo en cómo abordo los problemas hoy. El pensamiento sistemático requerido para los sistemas de control PID aparece en cómo diseño bucles de retroalimentación en los sistemas de software. Las habilidades de documentación y preservación del conocimiento que desarrollé han sido invaluables en cada puesto desde entonces. La experiencia de mentorizar y enseñar ha moldeado la forma en que trabajo con desarrolladores junior y contribuyo al intercambio de conocimiento en el equipo.

Lo más importante es que la experiencia me enseñó que prospero cuando trabajo en problemas técnicos desafiantes que tienen impacto en el mundo real. Ya sea optimizar algoritmos de movimiento de robots o construir 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 a la experiencia en el Laboratorio HCR, me impresiona cuánto logré en un tiempo relativamente corto. Los sistemas que construí cambiaron fundamentalmente cómo funcionaba la plataforma Triton, y muchas de esas mejoras todavía se utilizan hoy. El repositorio de documentación que creé se convirtió en la base de conocimiento de todo el proyecto. Las relaciones de mentoría que formé tuvieron un impacto duradero en las personas con las que trabajé.

Pero quizá lo más significativo es que la experiencia me mostró de lo que soy capaz cuando trabajo en problemas por los que siento verdadera pasión. En esos ocho meses, yo:

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

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

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. Todavía sigo los avances en el campo, me entusiasman los progresos en el aprendizaje de robots y los sistemas autónomos, y ocasionalmente trabajo en proyectos personales de robótica en mi tiempo libre.

¿Quién sabe lo que 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 en el que estos diferentes hilos de mi experiencia se unan de maneras inesperadas.

Por ahora, estoy agradecido por el tiempo que pasé en el HCR Lab y las experiencias que me brindó. Fue un período formativo que moldeó tanto mis habilidades técnicas como mi comprensión de qué tipo de trabajo me resulta más satisfactorio. Aunque a veces lo echo de menos, sé que las lecciones que aprendí y los enfoques que desarrollé siguen influyendo en todo lo que hago.

Los robots Triton todavía están allí, siguen sirviendo a los investigadores y siguen posibilitando trabajos importantes. Y eso es maravilloso.