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

Esta publicación narra mi viaje 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 Laboratorio de Robótica Centrada en el Humano (HCR) de la Escuela de Minas de Colorado desde febrero de 2021 hasta septiembre de 2021. Tenga en cuenta que desde finales de 2022, el Laboratorio HCR se ha trasladado de la Escuela de Minas de Colorado a la Universidad de Massachusetts Amherst, junto con su sitio de hcr.mines.edu a hcr.cs.umass.edu.

Antecedentes

Comencé mis estudios de pregrado en la Escuela de Minas de Colorado 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, pasé una buena cantidad de tiempo tratando de averiguar qué me gustaba y en qué podría ser bueno. Después de algunos intentos y errores, pude descubrir que mi pasión era la informática. Pero también fue durante este tiempo que descubrí que tenía un amor abrumador por construir a través del código.

En Mines, tuve la oportunidad de trabajar en el Laboratorio de Robótica Centrada en el Humano (HCR) de Mines bajo la dirección del Dr. Hao Zhang. Conocí al Dr. Zhang por primera vez en la primavera de 2020 a través de su clase “Robótica Centrada en el Humano” (CSCI473), y después del caos de 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 total para la clase se compuso de solo tres proyectos, cada uno de los cuales presentó un problema desafiante que introdujo conceptos fundamentales de robótica. Estos proyectos consistieron en:

1. Aprender el Sistema Operativo de Robots (ROS)
2. Aprendizaje por Refuerzo para el Seguimiento de Paredes por Robots
3. Comprensión de Comportamientos Humanos por Robots Usando Representaciones Basadas en Esqueletos

Aprender el Sistema Operativo de Robots (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 “Hola Mundo” en 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ó:

• Configurar ROS Melodic, que hice en mi laptop HP de 2011 que era lo suficientemente buena
• Instalar y configurar ROS y Gazebo
• Pasar por 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 sonaba simple, fue más difícil de lo que parecía. Este proyecto eventualmente me introdujo al concepto de sistemas de Bucle Abierto y Bucle Cerrado. Para la descripción completa del proyecto, consulte csci473-p1.pdf o puede 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 Robots

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 fue 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 de 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 utilizarán un escáner láser en el robot para realizar la detección y el aprendizaje, donde el robot se controla mediante comandos de dirección y velocidad. Se requiere que los estudiantes programen este proyecto utilizando C++ o Python en ROS Melodic ejecutándose en 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 de robótica estándar de IEEE utilizando LATEX.

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

Nunca publiqué mi solución en GitHub o en la web porque no era muy buena y estaba muy defectuosa. Además, hacer que el código funcionara en el entorno correcto es bastante difícil y molesto. Sin embargo, tengo un video de demostración que envié a la clase, mostrando mi solución. Puedes verlo aquí:

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

Comprensión de Comportamientos Humanos por Robots Usando Representaciones Basadas en Esqueletos

Para el tercer proyecto, la descripción del proyecto fue 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 utilizando 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 de robótica estándar de IEEE utilizando LATEX en el Entregable 3.

Este proyecto fue desafiante pero no tan difícil como el segundo proyecto. El objetivo principal era utilizar datos del sensor Kinect V1, del Conjunto de Datos de Actividad Diaria 3D de MSR, y Máquinas de Vectores de Soporte para clasificar ciertas acciones/comportamientos humanos. Para la descripción completa del proyecto, consulte csci473-p3.pdf o puede 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, 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 interesante de proyectos en los que reflexionar y referirme en mi currículum. También fue la primera clase donde sentí que estaba en mi elemento, ya que nunca fui un buen examinado pero sobresalía en completar proyectos. También fue a través de esta clase que conocí al Dr. Hao Zhang, quien eventualmente me ayudó a conseguir un puesto 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 CS en la Escuela de Minas de Colorado. 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 su conocimiento de los cursos a problemas del mundo real en 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 una empresa llamada Lunar Outpost llamado “Detección de Deslizamiento de Ruedas en Tiempo Real y Correcciones de Errores para una Navegación Lunar Mejorada”. Dado que el nombre es largo, llamemos 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 el rastro de su ubicación en el mundo real. En la Tierra, esto se resuelve utilizando datos de 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 que orbitan constantemente la Tierra y transmiten señales únicas que permiten a las computadoras calcular su posición. Pero en la luna, actualmente no existe tal cosa como un GPS. Sabiendo esto, se debe utilizar otro método que no sea GPS para detectar el deslizamiento de ruedas. Un informe más detallado sobre el problema del proyecto se puede ver aquí.

El Equipo

Este proyecto no fue un proyecto simple, por lo que tuvo que hacerse en equipo. El equipo estaba compuesto por cinco compañeros estudiantes de la Escuela de Minas de Colorado:

Este proyecto no fue un proyecto 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 que supiéramos algo 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 usé ROS en mi clase de Robótica Centrada en el Humano (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 ello.

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 las pruebas. Esto se debió a que COVID hizo que todo fuera remoto y nos impidió trabajar en el laboratorio/edificios del Puesto Lunar. Debido a esto, tuvimos que usar simulaciones.

Además, revisamos algunas investigaciones académicas del Laboratorio de Navegación de WVU para tener una idea de cómo se podría resolver el problema del deslizamiento de las 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 tratando de resolver/perfeccionar durante décadas. Así que un mes está 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 desarrollo, determinamos que es casi imposible simular adecuadamente la física lunar digitalmente, así que realmente probar este algoritmo en una simulación no es útil y no va a generar ninguna investigación significativa en la detección de deslizamiento de ruedas en el espacio y en la luna. Concluimos que establecer un entorno de prueba adecuado utilizando 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 funcionara como un nodo ROS y funcionó correctamente y podría ser fácilmente importado a hardware real para pruebas. Este proyecto me permitió asumir un papel de liderazgo, educar a mis compañeros sobre el desarrollo de ROS y ganar experiencia con Python, ROS y Gazebo mientras abordaba un problema complejo que nunca había encontrado antes. Lo más importante es que esta experiencia solidificó 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 a continuación en mi viaje 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 2020, decidí seguir investigando 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 HCR. Como conocí al Dr. Zhang el año anterior, decidí enviarle un correo electrónico y preguntar sobre cualquier oportunidad que el laboratorio pudiera tener en enero de 2021. Dentro de unas 2 semanas, el Dr. Zhang expresó interés, me presentó opciones de investigación y me ofreció un papel en el laboratorio. Luego comencé 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 mi tiempo en el Laboratorio HCR. Fue grabado en mayo de 2021 y cubre la investigación en la que me enfocarí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 Humano en la Escuela de Minas de Colorado. Es un robot terrestre de ruedas omnidireccionales triangulares alimentado por el Jetson Nano de NVIDIA.

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

• NVIDIA Jetson Nano
• Placa de soporte A205 de Seed Studio de NVIDIA
• 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 Realsense D435 de Intel
• Algunas luces LED

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

Para comenzar a abordar esto, el laboratorio estableció un área donde podíamos hacer un seguimiento del Triton. Para hacer esto, crearon un área de 2 metros por 2 metros con 8 cámaras Optitrack Flex (Infrarrojo Rojo) en una forma cuadrada a unos 6-7 pies sobre el suelo.

Junto con la construcción de esta área, cada Triton tenía tres bolas esféricas grises unidas 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 Optitrack en una forma triangular, pudimos localizar las coordenadas exactas de un Triton en nuestra área. Esto nos permitió aplicar un sistema de bucle cerrado para una mejor precisión en el movimiento.

El sistema Optitrack proporcionó datos de posición y orientación a aproximadamente 120Hz con una 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) estaba 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 aún tenía dificultades con el movimiento.

Con esta configuración, una característica clave que queríamos proporcionar al Triton era la capacidad de moverse a una coordenada específica. El usuario, o su software, podrí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, preciso y sin problemas posible. Cuando me uní, esta función existía pero no estaba funcionando muy bien. Aquí hay una simple animación 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 te muestra la antigua lógica de movimiento en acción. Sabiendo 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 alrededor.

Entonces, ¿por qué estaba ocurriendo este comportamiento? El problema era que el Triton primero giraba, cambiando su alfa, hasta que apuntaba hacia el punto objetivo dentro de un margen de error específico. Luego, se lanzaba hacia adelante, y después de que su theta se desviaba del objetivo por una cantidad específica, se detenía y comenzaba a girar nuevamente hasta que el alfa estaba dentro de ese rango aceptable para el objetivo. Luego se lanzaba nuevamente y seguía 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 carrera se volvía mucho más lenta para asegurarse de que no se pasara. Esto resultó en que el Triton tuviera un movimiento antinatural, tardando una eternidad en llegar a un punto objetivo y requiriendo tanto espacio solo para llegar a un punto objetivo específico. Así que con todos estos problemas, y dado lo esencial que era esta función para el desarrollo del proyecto Triton, cuando comencé a trabajar en el Laboratorio HCR, mi primera tarea fue desarrollar soluciones más efectivas 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 Retroalimentación (EENG307) en Mines. Al principio de esa clase, aprendimos sobre el concepto de Controladores de bucle abierto y Controladores de bucle cerrado. Sabiendo esto, y después de algunas discusiones que tuve con el profesor de esa clase y mi inteligente compañero de cuarto, quedó claro que este objetivo de llevar al Triton a un punto objetivo era un problema de sistema de bucle cerrado.

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

Método 1: Controlador Distancia-Theta

Este enfoque utilizó 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/atrás
• Controlador de Theta: Calculaba el error angular entre la dirección actual del robot y la dirección deseada hacia el objetivo, aplicando una ganancia proporcional separada para la velocidad de rotación

El algoritmo calculaba continuamente la distancia euclidiana al objetivo y el error angular entre la dirección actual del robot y la dirección deseada. Se aplicaron 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 hacia adelante, creando caminos curvos 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 trató al robot como un plotter 2D, con control independiente del movimiento en X e Y:

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

La implementación calculó los errores de las 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, di detalles completos sobre este método en mi blog de Mover Tortuga (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 basado en el 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 posicionamiento preciso.

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 conseguir 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 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 del Mundo 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 hasta 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 tambaleaban 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, opté 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é consistió en varios componentes clave:

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

Procesos Individuales de Robots: 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 en 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 de 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 cada robot siguiera, 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 para 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 Tritones utilizando su distintiva forma triangular y marcadores esféricos reflectantes
• Calcular posiciones y orientaciones relativas utilizando datos de profundidad
• Comparar estas mediciones con 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é un tiempo considerable experimentando con un pipeline 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. 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 en múltiples etapas. Tuve cierto éxito segmentando la imagen de profundidad para identificar objetos a nivel del suelo (filtrando paredes, techos, etc.) y buscando objetos con las características de tamaño adecuadas, aproximadamente 0.3x0.3 metros de huella. 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. Tuve algunos resultados prometedores en condiciones de iluminación controladas, aunque no fue consistentemente fiable.

Investigación sobre 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 estaban 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: Hacer que todo este procesamiento funcionara en tiempo real junto con los bucles de control del robot resultó ser un desafío. Experimenté con enfoques de optimización para ejecutar los algoritmos a alrededor de 10-15Hz sin abrumar las capacidades de procesamiento del Jetson Nano.

Desafortunadamente, tuve que dejar el laboratorio antes de poder completar completamente 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 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í es como se veía la vista del sensor de profundidad durante mis experimentos:

Aunque no completé el trabajo de integración del sensor de profundidad, el concepto mostró promesa para aplicaciones como la simulación de escenarios de automóviles autónomos, donde los vehículos necesitan ser conscientes unos de otros sin depender únicamente de la infraestructura externa. La dirección de investigación que comencé a explorar podría contribuir potencialmente al trabajo futuro 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 Tritón estaba disperso en múltiples plataformas y formatos. La información crítica estaba esparcida en:

• Varios 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 escritas a mano que solo ciertas personas podían interpretar

Esta documentación fragmentada era un gran problema. Los nuevos estudiantes pasaban semanas solo tratando de averiguar cómo comenzar, y el conocimiento valioso se perdía constantemente cuando las personas se graduaban o dejaban el laboratorio.

Me propuse resolver este problema de manera sistemática. Pasé incontables horas rastreando cada pieza de documentación, código, video y nota relacionada con el proyecto Tritón. 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 Tritones desde cero
• Configuración de Software: Guías completas para configurar el entorno de desarrollo
• Documentación de 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, incluyendo tutoriales detallados de calibración de Optitrack:

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

Más allá de solo organizar la documentación existente, creé varias guías y tutoriales originales que llenaron vacíos críticos en la base de conocimiento. Estos incluyeron instrucciones de configuración detalladas para nuevos miembros del laboratorio, guías de solución de problemas completas 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 utilizado por 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 Tritón y ahorró incontables 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 mentorear 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 Tritón, asumí una responsabilidad creciente en la capacitación de nuevos miembros del equipo.

Mentoría de 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 se harían cargo del proyecto Tritón después de mi partida. No se trataba solo de mostrarles cómo funcionaban las cosas, sino de asegurarme 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 falla comunes

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

Programa de Mentoría de Secundaria

Quizás aún más gratificante fue mi experiencia mentoreando a un 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 currículo integral que cubría:

Fundamentos de Ciencias de la Computación:

• Conceptos de programación utilizando Python como el 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 interaccionar con ellos
• Control de actuadores y sistemas de motores
• Los fundamentos de los sistemas autónomos y el control de retroalimentación

ROS (Sistema Operativo de Robots):

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

Trabajo Práctico en Proyectos:

• Colaboramos en la creación de 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 de la base de código del Tritón

Lo que hizo que esta mentoría fuera particularmente especial fue observar su progreso desde no saber prácticamente nada sobre 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 de 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 LED de la cabeza del Tritón a través de simples comandos de ROS. Esto puede sonar simple, pero requirió entender la arquitectura de ROS, la interconexión de hardware y los patrones de diseño de software adecuados. Su contribución sigue siendo utilizada en el laboratorio hoy en día.

La mentoría fue tan educativa para mí como lo fue para ella. Me obligó a descomponer conceptos complejos en piezas digeribles y a pensar realmente en los fundamentos de lo que estábamos haciendo. Enseñar 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 estrechamente con Peng, un estudiante de doctorado cuya investigación se centraba en algoritmos para coches autónomos. Las mejoras de software que había realizado en el sistema Triton ayudaron a respaldar su investigación doctoral.

La investigación de Peng requería una coordinación multi-robot precisa y confiable para simular escenarios de coches autónomos. Antes de mis mejoras en el control de movimiento y 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 de manera tan efectiva.

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” (Tritones) 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 multi-procesamiento que desarrollé permitió a Peng implementar y probar protocolos de comunicación entre vehículos simulados. Cada Triton podía tomar decisiones mientras aún coordinaba con otros, 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 solo era yo ayudando a su investigación, era una verdadera asociación. La comprensión de Peng sobre los aspectos teóricos de los vehículos autónomos ayudó a informar mis implementaciones prácticas. Su retroalimentación y requisitos me empujaron a hacer que los sistemas fueran 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 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 disertación de Peng. Ver mis contribuciones prácticas de ingeniería respaldar 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 mantuvimos el contacto. Saber que mi trabajo continuó contribuyendo a una investigación importante incluso 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 llevó a cabo durante la era pre-LLM del desarrollo de software. Todo esto tuvo lugar entre 2020 y 2021 (principalmente en 2021), antes de que existieran ChatGPT, Claude, Perplexity o herramientas de desarrollo impulsadas por IA como Cursor IDE.

Cada línea de código fue escrita desde cero, cada algoritmo fue investigado a través de 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 metódicas. Cuando me quedaba atascado en un problema de transformación de coordenadas o ajuste de PID, no podía simplemente pedirle 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 de control PID significaba leer libros de texto y artículos académicos. Resolver transformaciones de coordenadas requería trabajar a través de las matemáticas a mano. Cada concepto tenía que ser completamente entendido antes de la implementación.

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

Aprender desde los Principios Fundamentales: Sin la capacidad de preguntar rápidamente “¿cómo implemento multi-procesamiento en Python para robótica?”, tuve que entender 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: Dado que no podía confiar en que la IA explicara el código más tarde, tuve que escribir documentación y comentarios extremadamente claros. Esta disciplina resultó invaluable al transferir conocimientos 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 de resolución de problemas más profundas y una comprensión más completa de los sistemas subyacentes. Es fascinante pensar en lo diferente que podría haber sido este proyecto con las herramientas de desarrollo de hoy disponibles.

La Difícil Decisión de Irse

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

La oportunidad en eBay era significativa; era mi primer gran rol en ingeniería de software, proporcionaba una experiencia invaluable en la industria y me ofrecía un ingreso sólido. 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 hablé con el Dr. Zhang sobre la posibilidad de reducir mi carga de cursos para centrarme más en el trabajo del laboratorio, me aconsejó firmemente en contra. Su razonamiento era sólido: completar mi carrera debería ser la prioridad, y la experiencia en la industria en eBay sería valiosa para mi desarrollo profesional. Sentía que dejar clases para enfocarme 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 aproximadamente 8 meses de trabajo intensivo en el laboratorio, tomé la difícil decisión de dar un paso atrás de mi rol de asistente de investigación para centrarme en completar mi carrera 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 hecho y la inversión que tenía en el éxito del proyecto no desaparecieron simplemente porque ya no era parte oficial 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 la ingeniería de IA/ML, áreas que han sido increíblemente gratificantes y han proporcionado enormes oportunidades de crecimiento e impacto.

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

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

Pero también reconozco que cada camino tiene sus compensaciones. 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 gran escala, diseño de experiencia de usuario y los desafíos prácticos de construir productos que millones de personas utilizan. Estas experiencias me han convertido en un mejor ingeniero en general.

El trabajo que hice en el Laboratorio HCR continúa 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 el equipo.

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

El Impacto Duradero

Mirando hacia atrás en la experiencia del Laboratorio HCR, 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 todavía se utilizan 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 formé tuvieron un impacto duradero en las personas con las que trabajé.

Pero quizás lo más significativo, la experiencia me mostró de lo que soy capaz cuando trabajo en problemas que realmente me apasionan. 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 de múltiples robots desde cero
• Integré capacidades de visión por computadora y fusión de sensores
• Creé una documentación integral y un sistema de gestión del conocimiento
• Mentoricé a varias personas y ayudé con la transferencia de conocimiento
• Apoyé la investigación a nivel de doctorado en vehículos autónomos

Sin embargo, 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 los desarrollos en el campo, estoy emocionado por los avances en el aprendizaje de robots y sistemas autónomos, y ocasionalmente trabajo en proyectos de robótica personal 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 en la industria que he adquirido me ha enseñado cómo construir sistemas robustos y escalables. Quizás 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 me brindó. Fue un período formativo que moldeó tanto mis habilidades técnicas como mi comprensión de qué tipo de trabajo encuentro más gratificante. 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 Triton todavía están allí, todavía sirviendo a los investigadores, todavía habilitando trabajos importantes. Y eso es bastante maravilloso.