Pesquisa de Robótica do Laboratório HCR
Table of Contents
Este post relata minha jornada na robótica, começando com a descoberta da minha paixão por robótica na FRC durante o ensino médio em 2015 até meu período como assistente de pesquisa no Laboratório de Robótica Centrada no Humano (HCR) da Colorado School of Mines de fevereiro de 2021 a setembro de 2021. Observe que desde final de 2022, o Laboratório HCR mudou da Colorado School of Mines para a Universidade de Massachusetts Amherst, juntamente com seu site de hcr.mines.edu para hcr.cs.umass.edu.
Histórico
Comecei meus estudos de graduação na Colorado School of Mines no semestre de outono de 2018. Meu curso era Ciência da Computação com foco em Robótica e Sistemas Inteligentes. E me formei na primavera de 2022.
Tive sorte de encontrar minha paixão cedo na vida. Durante o ensino médio, passei bastante tempo tentando descobrir o que eu gostava e no que poderia ser bom. Após alguns testes e erros, consegui perceber que minha paixão era ciência da computação. Mas também foi nessa época que descobri que tinha um amor avassalador por construir através de código.
Na Mines, tive a oportunidade de trabalhar no Laboratório de Robótica Centrada no Humano (HCR) da Mines sob a orientação do Dr. Hao Zhang. Conheci o Dr. Zhang pela primeira vez na primavera de 2020 através da sua disciplina “Robótica Centrada no Humano” (CSCI473) e, após o caos da COVID e das tarefas da disciplina, passei a trabalhar em seu laboratório no início da primavera de 2021.
Disciplina de Robótica Centrada no Humano (CSCI473)
Mines’ Human Centered Robotics (CSCI473) foi uma das poucas disciplinas da minha experiência universitária que teve um impacto profundo em mim. A disciplina foi ministrada pelo Dr. Hao Zhang. Nossa nota final na disciplina era composta por apenas três projetos, cada um apresentando um problema desafiador que introduzia conceitos centrais de robótica. Esses projetos consistiam em:
- Aprendendo o Robot Operating System (ROS)
- Aprendizado por Reforço para Seguimento de Parede por Robô
- Compreensão Robótica de Comportamentos Humanos Usando Representações Baseadas em Esqueleto
🧩 Aprendendo o Robot Operating System (ROS)
Este foi o primeiro projeto que nos foi atribuído. O projeto consistia em três tarefas:
- Configurar o Ambiente de Desenvolvimento
- Entender o Simulador Gazebo
- Escrever um ROS “Hello World”
Para as tarefas 1 e 2, só precisávamos configurar nosso ambiente de desenvolvimento e seguir um tutorial de introdução ao Gazebo. Isso incluía:
- Configurar o ROS Melodic, que eu fiz no meu laptop HP de 2011, que foi suficiente
- Instalar e configurar o ROS e o Gazebo
- Seguir o tutorial do gazebosim e o tutorial do e-manual.
A tarefa 3, por outro lado, foi um verdadeiro desafio. A tarefa era usar o turtlesim e fazer a tartaruga desenhar o logotipo “M” da Mines:
![]() |
![]() |
Esta tarefa, embora parecesse simples, foi mais difícil do que parecia. Este projeto acabou me apresentando ao conceito de sistemas de Malha Aberta e Malha Fechada. Você pode saber mais sobre este projeto e minha solução na página do projeto ROS Move Turtle.
🧩 Aprendizado por Reforço para Seguimento de Parede por Robô
Este foi o segundo projeto que nos foi atribuído, e foi um dos projetos mais difíceis que já trabalhei na faculdade. A descrição do projeto era a seguinte:
Neste projeto, os estudantes projetarão e implementarão algoritmos de aprendizado por reforço para ensinar a um robô móvel autônomo a seguir uma parede e evitar colidir com obstáculos. Os estudantes usarão a simulação Gazebo no ROS Melodic para simular um robô móvel omnidirecional chamado Triton, e usarão um mapa de ambiente fornecido. Os estudantes usarão um scanner a laser no robô para realizar a detecção e o aprendizado, onde o robô é controlado por comandos de direção e velocidade. Os estudantes são obrigados a programar este projeto usando C++ ou Python no ROS Melodic rodando no Ubuntu 18.04 LTS (ou seja, o mesmo ambiente de desenvolvimento usado no Projeto 1). Além disso, os estudantes devem escrever um relatório seguindo o formato de conferências padrão de robótica IEEE usando LATEX.
Para o algoritmo de aprendizado por reforço, fomos instruídos a usar o Q-Learning. Também usamos o ambiente de simulação Gazebo Stingray fornecido pela disciplina. Stingray consistia no modelo Triton e na lógica física. Também nos foi fornecido um labirinto para o robô seguir. No geral, o ambiente parecia assim:
Para a descrição completa do projeto, confira csci473-p2.pdf. Nunca publiquei minha solução no GitHub ou na web porque não era muito boa e tinha falhas graves. Além disso, fazer o código rodar no ambiente correto é bastante difícil e irritante. No entanto, tenho um vídeo de demonstração que enviei para a disciplina, mostrando minha solução. Você pode visualizá‑lo aqui:
🧩 Compreensão Robótica de Comportamentos Humanos Usando Representações Baseadas em Esqueleto
Para o terceiro projeto, a descrição do projeto era a seguinte:
Neste projeto, os estudantes implementarão várias representações baseadas em esqueleto (Entregável 1) e usarão Máquinas de Vetor de Suporte (SVMs) (Entregável 2) para classificar comportamentos humanos usando um conjunto de dados de atividades públicas coletado de um sensor Kinect V1. Além disso, os estudantes são obrigados a escrever um relatório seguindo o formato de conferências padrão de robótica IEEE usando LATEX no Entregável 3.
Este projeto foi desafiador, mas não tão difícil quanto o segundo projeto. O objetivo principal era usar os dados do sensor Kinect V1, do MSR Daily Activity 3D Dataset, e Máquinas de Vetor de Suporte para classificar certas ações/comportamentos humanos. Você pode saber mais sobre este projeto e minha solução na página do projeto Predict Human Actions Using LIBSVM.
Conclusão do CSCI473
CSCI473 é uma das, senão a melhor, disciplina que fiz durante meus estudos de graduação na Mines. Todos esses projetos me ensinaram muito e me permitiram ter um catálogo legal de projetos para refletir e referenciar no meu currículo. Foi também a primeira disciplina em que me senti no meu elemento, já que nunca fui bom em provas, mas me destaquei na conclusão de projetos. Foi também através desta disciplina que conheci o Dr. Hao Zhang, que eventualmente me ajudou a garantir uma posição como assistente de pesquisa no Laboratório de Robótica Centrada no Humano (HCR) da Mines.
Sessão de Campo de CS (Verão 2020)
Durante o verão de 2020, entre concluir o CSCI473 e ingressar no Laboratório HCR, fiz CSCI370 ou “Engenharia de Software Avançada” como parte do meu programa de graduação em CS na Colorado School of Mines. O CSCI370 é um curso que faz os estudantes projetarem, implementarem e documentarem soluções de software para uma empresa. Ele permite que os estudantes apliquem o conhecimento adquirido nas disciplinas a problemas reais de ciência da computação. Você pode saber mais sobre o curso aqui.
No curso, você decide em qual projeto/empresa trabalhará. O curso forneceu PDFs detalhando cada projeto e empresa. No final, decidi trabalhar em um projeto publicado por uma empresa chamada Lunar Outpost chamado “Detecção em Tempo Real de Deslizamento de Rodas e Correções de Erro para Navegação Lunar Aprimorada”. Como o nome é longo, vamos dar ao projeto o apelido de “Detecção de Deslizamento de Rodas”.
O Problema
Lunar Outpost é uma startup que tenta criar rovers lunares autônomos. Na lua, há muita poeira lunar conhecida por causar muito deslizamento de rodas. Isso não é ideal porque o deslizamento de rodas pode fazer com que sistemas autônomos percam a localização no mundo real. Na Terra, isso é resolvido usando dados de GPS para corrigir qualquer deslocamento causado pelo deslizamento de rodas. Mas o problema com o GPS é que ele só funciona tendo 30+ satélites de navegação constantemente orbitando a Terra e transmitindo sinais únicos que permitem aos computadores calcular sua posição. Mas na lua, atualmente não existe GPS. Sabendo disso, outro método além do GPS precisa ser usado para detectar o deslizamento de rodas. Um relatório mais detalhado do problema do projeto pode ser visualizado aqui.
A Equipe
Este projeto não foi um projeto simples, então precisou ser feito em equipe. A equipe era composta por cinco colegas estudantes da Colorado School of Mines:
Este projeto não foi um projeto simples, então precisou ser feito em equipe. Esta equipe era composta por Mehmet Yilmaz (eu), Kane Bruce, Braedon O’Callaghan, Liam Williams e Kevin Grant.
O projeto exigiu que soubéssemos um pouco de ROS, C++, Python, Linux, Raspberry Pi e Arduino. A maioria de nós tinha experiência em uma ou mais dessas tecnologias, mas eu era o único com experiência em ROS, já que usei ROS na minha disciplina Human Centered Robotics (CSCI473) durante o semestre da primavera de 2020. Por isso, logo no início, ajudei todos a se atualizarem sobre ROS e como desenvolver para ele.
Desafios
In this project there were a lot of challenges. But the biggest challenge we faced was not having access to a real world robot for testing. This was due to COVID making everything remote and preventing us from working in the Lunar Outpost’s lab/buildings. Due to this, we had to use simulations.
Also, we went through some academic research from the WVU Navigation Lab to get an idea of how the Wheel Slippage problem could get solved for Lunar Outpost’s use case. Which, for us, as undergraduate sophomores and juniors, was more difficult than we expected.
Another challenge we faced was the amount of time we had to work on this project. CSCI370 is a one month class. But the problem itself is a massive problem that many companies and academics have been trying to solve/perfect for decades. So one month is far from enough time to solve this issue. But, despite all these challenges we pushed through and made sure to deliver.
Conclusão
After working through all the research and development, we determined that it is almost impossible to simulate proper moon physics digitally, so really trying this algorithm in a simulation is no good and not going to yield any meaningful research in wheel slippage detection in space and on the moon. We concluded that setting up a proper test environment using something like sand and real hardware, like a Husky robot, is far more important for this type of research. We did update the wheel slippage detection code to work as a ROS node and it functioned properly and could easily be imported into real hardware for testing. This project allowed me to take a leadership role, educate my peers on ROS development, and gain experience with Python, ROS, and Gazebo while tackling a complex problem I had never encountered before. Most importantly, this experience further solidified my passion for robotics and reinforced my desire to pursue research in the field, setting the stage for what would come next in my robotics journey.
Começando no HCR Lab
After completing CSCI473, my CS Field Session in the summer of 2020, and my Fall 2020 semester, I decided to pursue research in robotics. I had such great experiences with both CSCI473 and the CS Field Session that I decided I wanted to do research for the HCR Lab. Since I had met Dr. Zhang the year prior, I decided to email him and ask about any opportunities the lab might have in January 2021. Within about 2 weeks, Dr. Zhang expressed interest, presented me with research options, and offered me a role in the lab. I then started working for the lab in February 2021.
Vídeo de Introdução
Here’s my introduction video that I recorded a few months into my time in the HCR Lab. It was recorded in May 2021 and covers the research I would focus on in the HCR Lab during the summer of 2021:
Meu Projeto
Throughout my time in the HCR Lab, I mainly focused on the Triton project. The Triton project is a mobile robot developed by the Human Centered Robotics Lab at the Colorado School of Mines. It’s a triangular omni-wheel ground robot powered by NVIDIA’s Jetson Nano.
The Triton, in a simple overview, consisted of the following parts:
- NVIDIA Jetson Nano
- Placa Carrier A205 da Seed Studio da NVIDIA
- Arduino Mega
- Cartão Micro SD de 64 GB
- Corpo impresso em 3D personalizado
- 3 rodas mecanum
- 1 Bateria AR
- Circuitos personalizados para distribuição de energia otimizada e cabeamento
- Câmera Realsense D435 da Intel
- Alguns LEDs
It was designed, built, and manufactured around 2018-2020 as a robot for educational purposes. By the time I joined, the Triton was pretty established, and the lab was considering making a new version of it. However, the main issue with the Triton was its software. The Triton could move, charge, and function in a basic sense but did not really do anything intelligent. It even lacked the ability to make more advanced movements.
![]() |
![]() |
![]() |
![]() |
To start addressing this, the lab set up an area where we could keep track of the Triton. To do this, they created a 2-meter by 2-meter area with 8 Optitrack Flex (Infrared Red) Cameras in a square-like shape about 6-7 feet above the floor.
![]() |
![]() |
Along with having this area built, each Triton had three gray sphere balls attached at the top of their bodies.
With this setup, we had effectively built our own small-scale GPS system that allowed us to get the exact coordinates in meters of a Triton in our area of interest. By using the Optitrack infrared cameras and the Optitrack gray spheres in a triangular shape, we could pinpoint the exact coordinates of a Triton in our area. This allowed us to apply a closed-loop system for better accuracy in movement.
The Optitrack system provided position and orientation data at about 120Hz with sub-millimeter accuracy when properly calibrated. Each Triton’s three reflective markers formed a unique triangular pattern that the system could track as a rigid body. The coordinate system was calibrated so that (0,0) was at the center of the tracking area, with X and Y axes aligned to the room’s geometry. But despite this precise positioning data, the Triton still struggled with movement.
With this setup, one core feature we wanted to provide the Triton was the ability to move to a specific coordinate. The user, or their software, could provide a (x, y) coordinate within their area of interest. Then the robot would move to that coordinate as fast, accurately, and seamlessly as possible. When I joined, this feature existed but it wasn’t working very well. Here is a simple animation showing how the original moving logic worked:
I did not record the original solution in action, so I created this simple animation showing you the old moving logic in action. Knowing this, what are the issues with this method?
- É realmente lento
- Faz o robô ocupar muito espaço apenas para ir a um ponto específico. Isso dificultou o uso dessa solução quando vários Tritons estavam se movendo ao redor.
So why was this behavior happening? The issue was that the Triton first turned, changing its alpha, until it pointed toward the target point within a specific margin of error. Then it would sprint forward, and after its theta was off from the target by a specific amount, it would stop and start turning again until the alpha was within that acceptable range for the target goal. Then it sprints again and keeps doing this until it gets to the point. Also, as it got closer and closer to the goal point, the turning and sprinting speed would get much slower to make sure it didn’t overshoot. This resulted in the Triton having unnatural movement, taking forever to get to a target point, and requiring so much area just to get to a specific target point. So with all of these issues, and given how essential this feature was for the development of the Triton project, when I started working at the HCR Lab, my first task was to develop more effective solutions that would allow the Triton to better navigate to a goal point.
Knowing this, I spent a lot of time doing research on the best possible way of addressing this problem. Ironically, I was taking a class called Introduction to Feedback Control Systems (EENG307) at Mines. Early in that class, we learned about the concept of Open-loop controllers and Closed-loop controllers. Knowing this, and after some discussion I had with the professor of that class and my smart roommate, it became clear that this goal of getting the Triton to a goal point was a closed-loop system problem.
Now, after extensive testing and research, I developed two distinct controller approaches for the Tritons:
Método 1: Controlador Distância‑Theta
This approach used two separate proportional controllers running simultaneously:
- Controlador de Distância: Calculou a distância euclidiana até o alvo e aplicou um ganho proporcional para determinar a velocidade de avanço/recuo
- Controlador de Theta: Calculou o erro angular entre a orientação atual do robô e a orientação desejada para o alvo, aplicando um ganho proporcional separado para a velocidade rotacional
The algorithm continuously calculated the Euclidean distance to the target and the angular error between the robot’s current heading and the desired direction. Two separate proportional gains were applied to generate linear and angular velocities respectively.
This resulted in the Triton naturally turning toward the goal while simultaneously moving forward, creating smooth curved paths. The key advantage was that the robot always kept its front face oriented toward the destination, which was crucial for camera-based applications.
Método 2: Controlador de Coordenadas X‑Y
Esta abordagem tratava o robô como um plotter 2D, com controle independente dos movimentos X e Y:
- X Controller: Controlava diretamente o movimento leste‑oeste com base no erro da coordenada X
- Y Controller: Controlava diretamente o movimento norte‑sul com base no erro da coordenada Y
A implementação calculava os erros das coordenadas X e Y de forma independente, aplicava ganhos proporcionais separados e então transformava esses componentes de velocidade globais para o quadro de coordenadas local do robô usando matrizes de rotação. Essa transformação era necessária porque o sistema de tração omni‑wheel do robô exigia velocidades em seu próprio referencial, não em coordenadas globais. Esse método produzia os caminhos mais diretos até os alvos e era significativamente mais rápido, mas a orientação do robô desviava, já que não havia controle explícito de orientação.
Para o método #1, eu entrei em detalhes completos sobre esse método no meu blog Move Turtle (TurtleSim). Recomendo fortemente que você leia este blog para obter todos os detalhes sobre como os controladores PID funcionam em geral, bem como como o método #1 funciona. Desenvolvi o método #1 usando o TurtleSim do ROS, depois transferi esse código para o Triton e o atualizei para levar em conta um ambiente mais realista.
O método #2 usou uma abordagem bastante diferente, mas igualmente eficaz. Em vez de pensar na orientação do robô e na distância até o objetivo, esse método trata o movimento como um problema de plano de coordenadas. O controlador calcula continuamente o erro em ambas as direções X e Y separadamente. Por exemplo, se o robô precisar mover de (0,0) para (2,3), ele vê isso como a necessidade de corrigir um erro de 2 metros em X e um erro de 3 metros em Y. Dois controladores proporcionais trabalharam simultaneamente: um ajustava a velocidade do robô na direção X com base no erro X, enquanto o outro controlava o movimento na direção Y com base no erro Y. Isso criou um caminho mais direto até o objetivo, semelhante ao movimento da cabeça de uma impressora 3D, e permitiu movimentos diagonais suaves. O robô não precisava girar explicitamente para enfrentar seu alvo, tornando esse método particularmente eficaz em espaços apertados ou quando é necessário posicionamento preciso.
Ambos os métodos provaram ser significativamente mais rápidos e mais confiáveis que a abordagem original. Para ver esses novos métodos em ação, confira a Playlist Tritons in Action, que mostra todos os Tritons em ação com os novos métodos.
O que antes levava 30‑45 segundos para um simples movimento ponto a ponto agora leva cerca de 8‑12 segundos. Mais importante, o Triton agora pode navegar de forma mais eficiente em espaços apertados, o que se tornou útil para nossos cenários de múltiplos robôs.
Desafios de Desenvolvimento e Depuração
Implementar esses controladores não foi simples e envolveu vários desafios significativos de depuração:
Transformações de Sistema de Coordenadas: Um dos aspectos mais complicados foi acertar as transformações de coordenadas. O sistema Optitrack fornecia dados em seu próprio quadro de coordenadas, o robô tinha seu quadro de coordenadas local, e eu precisava converter entre eles com precisão. Implementações iniciais fizeram os robôs se moverem nas direções erradas porque eu confundi os cálculos das matrizes de rotação.
Mundo Real vs. Comportamento Ideal: O maior desafio foi levar em conta fatores do mundo real que não aparecem na teoria de controle dos livros. As rodas do robô tinham características de fricção diferentes, os motores não respondiam de forma idêntica, e sempre havia alguma latência na cadeia de comunicação do Optitrack ao software de controle e ao Arduino do robô. Passei semanas ajustando ganhos proporcionais e adicionando filtros de zona morta para considerar essas realidades físicas.
Oscilação e Problemas de Estabilidade: Minhas primeiras implementações sofreram de problemas de oscilação onde os robôs ultrapassavam seus alvos e balançavam para frente e para trás. Isso me ensinou sobre a importância dos termos derivativos em controladores PID e a necessidade de um ajuste adequado dos ganhos. Acabei optando por controle predominantemente proporcional com ganhos cuidadosamente ajustados em vez de PID completo, já que o amortecimento inerente do sistema era suficiente para a maioria das aplicações.
Interferência de Múltiplos Robôs: Quando vários robôs operavam simultaneamente, descobri padrões de interferência inesperados. Os robôs às vezes “lutavam” pelo mesmo espaço ou criavam situações de impasse onde bloqueavam uns aos outros indefinidamente. Isso me levou a implementar mecanismos de coordenação e algoritmos de prevenção de colisões.
Sistema de Controle Multi‑Triton
Depois que resolvi o problema de movimento de um único Triton, o próximo desafio do laboratório foi fazer vários Tritons trabalharem juntos simultaneamente. Isso se tornou uma das minhas principais áreas de foco e acabou sendo uma contribuição significativa para o projeto.
O sistema original só podia controlar um Triton de cada vez, o que limitava severamente as possibilidades de pesquisa. O laboratório queria simular cenários onde múltiplos veículos autônomos precisavam coordenar seus movimentos, como carros autônomos se comunicando entre si para otimizar o fluxo de tráfego e criar mapas SLAM (Localização e Mapeamento Simultâneos) melhores.
Para resolver isso, implementei uma abordagem de multiprocessamento usando a biblioteca multiprocessing do Python. Cada Triton recebeu seu próprio processo dedicado que podia rodar independentemente, ainda sendo coordenado por um sistema de controle central. Isso permitiu que vários Tritons se movessem simultaneamente sem interferir nos loops de controle uns dos outros.
Design da Arquitetura Multi‑Robô
A arquitetura do sistema que desenvolvi consistia em vários componentes principais:
- Processo do Controlador Principal: Servia como o coordenador central, lidando com interações da interface do usuário, planejamento de trajetórias e coordenação de alto nível entre os robôs. Mantinha o estado global e distribuía comandos para os processos individuais dos robôs.
- Processos de Robô Individuais: Cada Triton tinha seu próprio processo Python dedicado que lidava com:
- Cálculos de controle PID em tempo real a ~50 Hz
- Comunicação com o hardware do robô (Arduino/Jetson)
- Execução de caminho local e evasão de obstáculos
- Relato de status de volta ao controlador principal
- Comunicação por Memória Compartilhada: Usei multiprocessing.shared_memory e objetos Queue do Python para permitir comunicação eficiente entre processos. Isso permitiu coordenação em tempo real sem a sobrecarga da comunicação de rede.
- Mecanismos de Sincronização: Para prevenir conflitos quando múltiplos robôs precisavam coordenar (como evitar colisões), implementei semáforos e locks que permitiam aos robôs solicitar acesso exclusivo a certas áreas do espaço de trabalho.
O desafio era garantir que todos os robôs pudessem operar seus loops de controle independentemente, ainda mantendo a coordenação global. Cada processo de robô executava seus próprios cálculos PID e enviava comandos de motor diretamente ao hardware, enquanto o processo principal lidava com a coordenação de alto nível, como prevenção de colisões e planejamento de trajetórias.
![]() |
![]() |
O sistema multi‑Triton abriu possibilidades de pesquisa totalmente novas. Agora podíamos simular:
- Cenários de comunicação veículo‑a‑veículo
- Planejamento de trajetórias coordenado com evasão de obstáculos
- Comportamentos de robótica em enxame
- Mapeamento SLAM multi‑agente
- Controle de formação e comportamentos de seguimento
Aqui está como a configuração do laboratório parecia com vários Tritons rodando simultaneamente:
![]() |
![]() |
Também desenvolvi uma interface amigável que permitia aos pesquisadores definir visualmente caminhos para cada Triton. Você podia literalmente desenhar o caminho que queria que cada robô seguisse, e eles executariam esses caminhos com coordenação perfeita. Isso foi incrivelmente útil para montar experimentos complexos sem precisar codificar manualmente cada movimento.
O sistema podia lidar com até 5 Tritons simultaneamente, cada um executando seus próprios controladores PID enquanto era coordenado pelo sistema de controle central. O desempenho foi impressionante, com todos os robôs mantendo sua precisão individual enquanto trabalhavam juntos como uma equipe.
Aqui está uma playlist mostrando os Tritons em ação, do controle de um único robô à coordenação multi‑robô: Playlist Tritons in Action
Integração de Sensor de Profundidade e Correção de Coordenadas
Outro grande avanço em que trabalhei envolveu a utilização das câmeras de profundidade Intel RealSense D435 montadas em cada Triton. Enquanto o sistema Optitrack nos fornecia dados de posicionamento incrivelmente precisos, eu queria explorar como os robôs poderiam usar seus sensores embarcados para melhorar sua percepção espacial e corrigir erros de coordenadas.
A ideia era que os Tritons pudessem usar seus sensores de profundidade para detectar outros Tritons nas proximidades e cruzar as referências de suas posições. Isso serviria a múltiplos propósitos:
-
Correção de Erro: Se o sistema Optitrack apresentasse algum desvio de calibração ou oclusão temporária, os robôs poderiam usar a confirmação visual das posições uns dos outros para manter sistemas de coordenadas precisos.
-
SLAM Aprimorado: Ao ter múltiplos robôs com sensores de profundidade trabalhando juntos, poderíamos criar mapas muito mais ricos do ambiente com pontos de dados redundantes.
-
Evitação de Colisão: A detecção de profundidade em tempo real permitiria que os robôs detectassem e evitassem uns aos outros mesmo que o sistema de controle central tivesse atrasos de comunicação.
Comecei a experimentar algoritmos que permitiriam aos Tritons:
- Detectar outros Tritons usando sua forma triangular distintiva e marcadores de esferas refletoras
- Calcular posições e orientações relativas usando dados de profundidade
- Comparar essas medições com os dados do Optitrack para identificar discrepâncias
- Potencialmente ajustar seu sistema de coordenadas em tempo real para manter a precisão
Experimentos de Visão Computacional
Passei um tempo considerável experimentando um pipeline de visão computacional que funcionava em várias etapas:
![]() |
![]() |
![]() |
![]() |
![]() |
Processamento de Dados de Profundidade: O Intel RealSense D435 fornecia fluxos de dados RGB e de profundidade. Eu trabalhei principalmente com os dados de profundidade, que vinham como uma matriz 640x480 de medições de distância a 30Hz. O primeiro desafio foi filtrar esses dados de profundidade ruidosos para extrair informações geométricas significativas.
Tentativas de Detecção de Objetos: Experimentei algoritmos de detecção em múltiplas etapas. Tive algum sucesso segmentando a imagem de profundidade para identificar objetos ao nível do chão (filtrando paredes, teto, etc.) e procurando objetos com as características de tamanho corretas, aproximadamente uma pegada de 0,3x0,3 metros. Tentei usar detecção de bordas e análise geométrica para identificar o perfil distintivo do Triton, com resultados mistos.
Experimentos de Reconhecimento de Marcadores: As três esferas refletoras em cada Triton pareciam ser o recurso de detecção mais promissor. Experimentei algoritmos de detecção de blobs para identificar o padrão triangular característico de três pontos brilhantes na imagem de profundidade. Obtive alguns resultados promissores em condições de iluminação controlada, embora não fosse consistentemente confiável.
Pesquisa de Fusão de Coordenadas: Pesquisei abordagens para fundir estimativas de posição baseadas em visão com os dados do Optitrack, incluindo implementações básicas de filtro de Kalman. O conceito era dar mais peso aos dados do Optitrack quando disponíveis, mas recorrer à visão quando necessário, embora eu não tenha conseguido fazer isso funcionar completamente antes do meu tempo no laboratório terminar.
Desafios de Performance: Fazer todo esse processamento rodar em tempo real junto com os loops de controle do robô provou ser desafiador. Experimentei abordagens de otimização para executar os algoritmos em torno de 10-15Hz sem sobrecarregar as capacidades de processamento do Jetson Nano.
Infelizmente, tive que deixar o laboratório antes de poder concluir totalmente este trabalho de visão computacional. Embora eu tenha obtido alguns resultados iniciais promissores e aprendido muito sobre o processamento de sensores de profundidade, não consegui levar o sistema a um estado totalmente confiável. Continuou sendo uma direção de pesquisa interessante que outros poderiam potencialmente desenvolver.
Aqui está um vídeo de mim testando os algoritmos de visão computacional:
Aqui está como a visualização do sensor de profundidade parecia durante meus experimentos:
Embora eu não tenha concluído o trabalho de integração do sensor de profundidade, o conceito mostrou potencial para aplicações como simular cenários de carros autônomos, onde os veículos precisam estar cientes uns dos outros sem depender exclusivamente de infraestrutura externa. A direção de pesquisa que comecei a explorar poderia potencialmente contribuir para trabalhos futuros no laboratório.
Documentação e Preservação do Conhecimento
Uma das minhas contribuições mais importantes para o HCR Lab, e talvez a que mais me orgulho, foi organizar e preservar toda a documentação do projeto. Quando entrei no laboratório, o conhecimento do projeto Triton estava espalhado por várias plataformas e formatos. Informações críticas estavam distribuídas entre:
- Várias contas do Google Drive pertencentes a diferentes estudantes que se formaram
- E‑mails antigos enterrados nas caixas de entrada
- Pastas aleatórias do Dropbox
- Múltiplos repositórios do GitHub
- Repositórios do GitLab com organização inconsistente
- Notas manuscritas que apenas pessoas específicas podiam interpretar
Essa documentação fragmentada era um grande problema. Novos estudantes passavam semanas apenas tentando descobrir como começar, e o conhecimento valioso era constantemente perdido quando as pessoas se formavam ou deixavam o laboratório.
Assumi a responsabilidade de resolver esse problema de forma sistemática. Passei inúmeras horas rastreando cada pedaço de documentação, código, vídeo e nota relacionados ao projeto Triton. Em seguida, organizei tudo em um repositório GitLab centralizado com uma estrutura clara e lógica.
![]() |
![]() |
A documentação centralizada incluía:
- Guias de Montagem: Instruções passo a passo para montar Tritons do zero
- Configuração de Software: Guias completos para configurar o ambiente de desenvolvimento
- Documentação de Código: Código bem comentado com explicações claras
- Especificações de Hardware: Listas detalhadas de peças, diagramas de fiação e projetos de PCB
- Guias de Solução de Problemas: Problemas comuns e suas soluções
- Tutoriais em Vídeo: Criei e carreguei vídeos instrucionais no YouTube, incluindo tutoriais detalhados de calibração do Optitrack:
Também estabeleci padrões de documentação para garantir que contribuições futuras fossem organizadas e acessíveis. A estrutura do repositório que criei se tornou a base para todo o trabalho subsequente no laboratório.
Além de apenas organizar a documentação existente, criei vários guias e tutoriais originais que preencheram lacunas críticas na base de conhecimento. Estes incluíram instruções detalhadas de configuração para novos membros do laboratório, guias abrangentes de solução de problemas e vídeos passo a passo de procedimentos complexos.
O impacto foi imediato e duradouro. Novos estudantes podiam se atualizar em dias ao invés de semanas. O repositório de documentação que criei ainda está sendo usado pelo laboratório hoje, anos depois que eu saí. Ele se tornou a única fonte de verdade para o projeto Triton e economizou inúmeras horas/dias para futuros pesquisadores.
Mentoria e Transferência de Conhecimento
Um dos aspectos mais gratificantes do meu tempo no HCR Lab foi a oportunidade de orientar outros e compartilhar o conhecimento que adquiri. Conforme meu trabalho avançava e eu me tornava mais experiente com os sistemas Triton, assumi responsabilidade crescente no treinamento de novos membros da equipe.
Orientando Sucessores do Laboratório
Enquanto me preparava para eventualmente deixar o laboratório para focar em terminar meu diploma e meu trabalho na eBay, certifiquei-me de treinar minuciosamente duas pessoas que assumiriam o projeto Triton após minha saída. Isso não se tratava apenas de mostrar a eles como as coisas funcionavam, mas de garantir que realmente compreendessem os princípios subjacentes para que pudessem continuar inovando.
Passei semanas trabalhando de perto com eles, abordando:
- Os fundamentos matemáticos dos sistemas de controle PID
- A arquitetura de multiprocessamento para coordenar múltiplos robôs
- A integração do sensor de profundidade e os algoritmos de visão computacional
- O sistema de documentação e como mantê-lo
- Técnicas de depuração e modos de falha comuns
A transferência de conhecimento foi incrivelmente completa. Passamos por sessões reais de depuração juntos, eu os fiz modificar e estender o código existente, e garanti que eles pudessem configurar novos Tritons de forma independente a partir do zero.
Programa de Mentoria de Ensino Médio
Talvez ainda mais gratificante tenha sido minha experiência orientando um estudante do ensino médio através do programa de extensão do laboratório. Foi uma ótima oportunidade para apresentar alguém à robótica, ciência da computação e pesquisa em uma fase formativa de sua educação.
Desenhei um currículo abrangente que cobria:
Fundamentos de Ciência da Computação:
- Conceitos de programação usando Python como linguagem principal
- Introdução à programação orientada a objetos
- Compreensão de algoritmos e estruturas de dados
Conceitos de Robótica:
- Como os sensores funcionam e como interagir com eles
- Controle de atuadores e sistemas de motores
- O básico de sistemas autônomos e controle de feedback
ROS (Robot Operating System):
- Compreensão do sistema de mensagens publish/subscribe
- Criação de nós e serviços
- Trabalho com arquivos de lançamento e servidores de parâmetros
Trabalho Prático de Projeto:
- Colaboramos na criação de um serviço ROS que controlava o sistema de LEDs na cabeça do Triton
- Ela aprendeu a escrever código limpo e documentado que se integrava aos nossos sistemas existentes
- O serviço de controle de LED que ela criou tornou-se uma parte permanente da base de código do Triton
O que tornou essa mentoria particularmente especial foi observar sua progressão de saber praticamente nada sobre programação a contribuir com código significativo para um projeto de pesquisa ativo. Ela passou de perguntar “O que é uma variável?” a depurar independentemente problemas de comunicação ROS e escrever suas próprias implementações de serviço.
O sistema de controle de LED que ela desenvolveu permitiu que os pesquisadores mudassem facilmente as cores e padrões dos LEDs da cabeça do Triton através de simples comandos ROS. Isso pode parecer simples, mas exigiu compreensão da arquitetura ROS, interface de hardware e padrões adequados de design de software. Sua contribuição ainda está sendo usada no laboratório hoje.
A mentoria foi tão educativa para mim quanto foi para ela. Ela me forçou a dividir conceitos complexos em partes digestíveis e realmente pensar nos fundamentos do que estávamos fazendo. Ensinar outra pessoa me tornou um engenheiro e pesquisador melhor.
Colaboração com Pesquisa de PhD
Um dos aspectos mais gratificantes profissionalmente do meu tempo no laboratório foi trabalhar de perto com Peng, um estudante de PhD cuja pesquisa se concentrava em algoritmos de carros autônomos. As melhorias de software que fiz no sistema Triton ajudaram a apoiar sua pesquisa de doutorado.
A pesquisa de Peng exigia coordenação multi-robô precisa e confiável para simular cenários de carros autônomos. Antes das minhas melhorias no controle de movimento e nos sistemas multi-robô, esses experimentos eram muito mais difíceis de conduzir. Os robôs eram mais lentos, menos precisos e não conseguiam trabalhar juntos de forma tão eficaz.
Minhas contribuições ajudaram a pesquisa de Peng em várias áreas:
Estudos de Gerenciamento de Interseções: Com os controladores PID aprimorados e a coordenação multi-robô, Peng pôde simular cenários de interseção onde múltiplos “veículos” (Tritons) precisavam coordenar seus movimentos. O melhor timing e posicionamento ajudaram a tornar esses estudos mais viáveis.
Comunicação Veículo-a-Veículo: A estrutura de multiprocessamento que desenvolvi permitiu que Peng implementasse e testasse protocolos de comunicação entre veículos simulados. Cada Triton podia tomar decisões enquanto ainda se coordenava com os demais, similar ao modo como carros autônomos podem precisar operar.
Pesquisa de SLAM e Mapeamento: O trabalho de integração do sensor de profundidade forneceu a Peng dados adicionais para sua pesquisa de localização e mapeamento simultâneos (SLAM). Ter múltiplos robôs com capacidades de sensoriamento coordenado permitiu experimentos de mapeamento mais abrangentes.
O que tornou nossa colaboração particularmente valiosa foi o fato de que não se tratava apenas de eu ajudar a pesquisa dele, mas de uma parceria genuína. A compreensão de Peng sobre os aspectos teóricos dos veículos autônomos ajudou a informar minhas implementações práticas. Seu feedback e requisitos me impulsionaram a tornar os sistemas mais robustos e capazes.
Passamos muitas horas no laboratório juntos, depurando cenários, discutindo diferentes estratégias de controle e explorando o que a plataforma Triton poderia alcançar. Peng se tornou tanto um colega quanto um amigo, e trabalhar com ele me ensinou muito sobre como a pesquisa acadêmica realmente funciona.
Os sistemas que construí se tornaram uma parte útil do trabalho de dissertação de Peng. Ver minhas contribuições práticas de engenharia apoiar a pesquisa em tecnologia de veículos autônomos foi realmente gratificante. Isso reforçou meu interesse em como engenharia sólida e pesquisa podem trabalhar juntas para criar resultados úteis.
Mesmo depois que deixei o laboratório, Peng e eu mantivemos contato. Saber que meu trabalho continuou a contribuir para pesquisas importantes mesmo após minha partida foi extremamente gratificante.
Perspectiva: A Era Pré-LLM do Desenvolvimento
Vale a pena notar que todo esse trabalho foi realizado durante a era pré-LLM do desenvolvimento de software. Tudo isso ocorreu entre 2020 e 2021 (principalmente 2021), antes de ChatGPT, Claude, Perplexity ou ferramentas de desenvolvimento impulsionadas por IA como Cursor IDE existirem.
Cada linha de código foi escrita do zero, cada algoritmo foi pesquisado através de artigos acadêmicos e livros didáticos, e cada sessão de depuração envolvia métodos tradicionais como instruções de impressão, depuradores e testes metódicos. Quando eu ficava preso em uma transformação de coordenadas ou em um problema de ajuste de PID, não podia simplesmente pedir a um assistente de IA para explicar o conceito ou ajudar a depurar o problema.
Isso tornou o processo de desenvolvimento significativamente mais desafiador, mas também mais educativo. Eu tive que:
Pesquisar Tudo Manualmente: Entender a teoria de controle PID significava ler livros didáticos e artigos acadêmicos. Descobrir transformações de coordenadas exigia trabalhar a matemática à mão. Cada conceito precisava ser totalmente compreendido antes da implementação.
Depurar Sem Assistência de IA: Quando os robôs se moviam em direções inesperadas ou oscilavam ao redor de alvos, eu precisava rastrear metodicamente a lógica, adicionar saídas de depuração e testar hipóteses uma a uma. Não havia IA para sugerir possíveis problemas ou ajudar a interpretar padrões de erro.
Aprender a Partir dos Princípios Fundamentais: Sem a capacidade de perguntar rapidamente “como implemento multiprocessamento em Python para robótica?”, eu tive que entender profundamente os conceitos subjacentes. Isso me forçou a construir uma base sólida em programação concorrente, sistemas de controle e visão computacional.
Documentação Era Crítica: Como eu não podia contar com IA para explicar o código posteriormente, tive que escrever documentação e comentários extremamente claros. Essa disciplina se mostrou inestimável ao transferir conhecimento para outras pessoas.
Olhando para trás, embora as ferramentas modernas de IA tivessem acelerado muitos aspectos do desenvolvimento, trabalhar sem elas me forçou a desenvolver habilidades de resolução de problemas mais profundas e uma compreensão mais completa dos sistemas subjacentes. É fascinante pensar como este projeto poderia ter sido diferente com as ferramentas de desenvolvimento atuais disponíveis.
A Difícil Decisão de Sair
Por mais que eu adorasse trabalhar no HCR Lab, no final de 2021 eu enfrentei uma decisão difícil que muitos estudantes encontram: equilibrar múltiplas oportunidades e responsabilidades. Eu estava simultaneamente trabalhando em tempo integral como engenheiro de software na eBay, concluindo meu grau em ciência da computação na Mines, e contribuindo para a pesquisa no HCR Lab.
A oportunidade na eBay foi significativa; foi meu primeiro grande cargo de engenharia de software, proporcionou experiência de indústria inestimável e me deu uma renda sólida. No entanto, tentar manter o trabalho em tempo integral, concluir meu grau e contribuir de forma significativa para a pesquisa era simplesmente insustentável. Algo precisava ceder.
Quando procurei o Dr. Zhang sobre a possibilidade de reduzir minha carga de cursos para focar mais no trabalho de laboratório, ele aconselhou fortemente contra isso. Seu raciocínio era sólido: concluir meu grau deveria ser a prioridade, e a experiência na indústria na eBay seria valiosa para o desenvolvimento da minha carreira. Ele achava que abandonar disciplinas para focar na pesquisa, embora tentador, poderia não ser a melhor decisão a longo prazo.
Então, em setembro de 2021, após cerca de 8 meses de trabalho intensivo no laboratório, tomei a difícil decisão de recuar do meu papel de assistente de pesquisa para focar em concluir meu grau e meu trabalho na eBay. Foi uma das decisões profissionais mais difíceis que tive que tomar na época.
Mesmo depois de deixar oficialmente o laboratório, continuei a oferecer suporte sempre que alguém precisava de ajuda com os sistemas que eu havia construído. Atualizei a documentação conforme necessário, respondi a perguntas sobre depuração e ajudei a solucionar problemas remotamente. As conexões que eu havia feito e o investimento que eu tinha no sucesso do projeto não desapareceram simplesmente porque eu não fazia mais parte oficialmente da equipe.
Reflexões e Relembrando
Agora, em 2025, quatro anos depois, encontro-me refletindo sobre aquele período com emoções complexas. Minha trajetória profissional me levou profundamente ao desenvolvimento web e à engenharia de IA/ML, áreas que têm sido incrivelmente gratificantes e proporcionaram enormes oportunidades de crescimento e impacto.
No entanto, há uma parte de mim que se pergunta “e se”. A robótica foi, e honestamente ainda é, minha verdadeira paixão. Há algo em trabalhar com sistemas físicos, ver seu código se traduzir em movimento e comportamento no mundo real, que o desenvolvimento web e até o trabalho com IA não conseguem replicar completamente.
Às vezes me pergunto o que poderia ter acontecido se eu tivesse tomado um caminho diferente. E se eu tivesse encontrado uma maneira de permanecer na pesquisa em robótica? E se eu tivesse seguido para a pós-graduação imediatamente após terminar meu bacharelado? E se eu tivesse escolhido priorizar o trabalho de laboratório em vez da experiência na indústria?
Mas também reconheço que cada caminho tem suas compensações. As habilidades que desenvolvi em desenvolvimento web e IA foram incrivelmente valiosas. A experiência na indústria me ensinou sobre engenharia de software em escala, design de experiência do usuário e os desafios práticos de construir produtos que milhões de pessoas utilizam. Essas experiências me tornaram um engenheiro melhor como um todo.
O trabalho que fiz no HCR Lab continua a influenciar como abordo os problemas hoje. O pensamento sistemático exigido pelos sistemas de controle PID aparece em como eu projeto loops de feedback em sistemas de software. As habilidades de documentação e preservação de conhecimento que desenvolvi têm sido inestimáveis em todas as funções desde então. A experiência de mentorar e ensinar moldou como eu trabalho com desenvolvedores juniores e contribuo para o compartilhamento de conhecimento na equipe.
Mais importante, a experiência me ensinou que prospero ao trabalhar em problemas técnicos desafiadores que têm impacto no mundo real. Seja otimizando algoritmos de movimento de robôs ou construindo sistemas de IA que ajudam os usuários a alcançar seus objetivos, a satisfação vem de resolver problemas difíceis que importam.
O Impacto Duradouro
Olhando para trás na experiência do HCR Lab, fico impressionado com o quanto consegui em um período relativamente curto. Os sistemas que construí mudaram fundamentalmente a forma como a plataforma Triton operava, e muitas dessas melhorias ainda são usadas hoje. O repositório de documentação que criei se tornou a base de conhecimento para todo o projeto. Os relacionamentos de mentoria que formei tiveram impacto duradouro nas pessoas com quem trabalhei.
Mas talvez o mais significativo, a experiência me mostrou do que sou capaz quando trabalho em problemas pelos quais sou verdadeiramente apaixonado. Nesses oito meses, eu:
- Melhorou o sistema de controle de movimento do robô que estava limitando a plataforma
- Construiu um sistema de coordenação multi‑robô do zero
- Integro capacidades de visão computacional e fusão de sensores
- Criou um sistema abrangente de documentação e gerenciamento de conhecimento
- Mentorou várias pessoas e ajudou na transferência de conhecimento
- Apoiei pesquisas de nível de doutorado em veículos autônomos
Isso não se tratava apenas das conquistas técnicas, embora elas fossem significativas para mim. Tratava‑se de aprender que, com persistência e pensamento sistemático, você pode fazer contribuições úteis mesmo como estudante de graduação.
O Futuro e a Robótica
Embora minha carreira tenha me levado a outras direções, minha paixão por robótica não diminuiu. Ainda acompanho os desenvolvimentos na área, estou empolgado com os avanços em aprendizado de robôs e sistemas autônomos, e ocasionalmente trabalho em projetos pessoais de robótica no meu tempo livre.
Quem sabe o que o futuro reserva? As habilidades que estou desenvolvendo em IA e aprendizado de máquina são cada vez mais relevantes para a robótica. A experiência industrial que adquiri me ensinou a construir sistemas robustos e escaláveis. Talvez haja um futuro onde esses diferentes fios da minha experiência se unam de maneiras inesperadas.
Por enquanto, sou grato pelo tempo que passei no HCR Lab e pelas experiências que ele proporcionou. Foi um período formativo que moldou tanto minhas habilidades técnicas quanto minha compreensão dos tipos de trabalho que mais me realizam. Embora às vezes sinta falta dele, sei que as lições que aprendi e as abordagens que desenvolvi continuam a influenciar tudo o que faço.
Os robôs ainda estão lá, ainda servindo os pesquisadores, ainda possibilitando trabalhos importantes. E isso é bastante maravilhoso.