Meu Capítulo de Pesquisa em Robótica

Esta publicação relata minha jornada em robótica, começando com a descoberta da minha paixão por robótica no FRC durante o ensino médio em 2015 até meu período como assistente de pesquisa no Laboratório de Robótica Centrada no Ser Humano (HCR) da Colorado School of Mines’s de fevereiro de 2021 a setembro de 2021. Observe que, desde o fim de 2022, o Laboratório HCR se mudou da Colorado School of Mines para a University of Massachusetts Amherst, junto com seu site de hcr.mines.edu para hcr.cs.umass.edu.

Contexto

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 a sorte de descobrir minha paixão cedo na vida. Durante o ensino médio, passei bastante tempo tentando descobrir o que eu gostava e no que eu poderia ser bom. Depois de alguma tentativa e erro, consegui perceber que minha paixão era a ciência da computação. Mas foi também nessa época que descobri que tinha esse amor avassalador por construir por meio do código.

Na Mines, tive a oportunidade de trabalhar no Laboratório de Robótica Centrada no Ser Humano (HCR) da Mines sob a orientação do Dr. Hao Zhang. Conheci o Dr. Zhang pela primeira vez na primavera de 2020 por meio da disciplina “Robótica Centrada no Ser Humano” (CSCI473), e depois do caos da COVID e das atividades das aulas, passei a trabalhar em seu laboratório no início da primavera de 2021.

Disciplina de Robótica Centrada no Ser Humano (CSCI473)

A disciplina de Robótica Centrada no Ser Humano (CSCI473) da Mines foi uma das poucas da minha experiência universitária que teve um impacto profundo em mim. A disciplina foi ministrada pelo Dr. Hao Zhang. Toda a nossa nota na disciplina era composta por apenas três projetos, cada um dos quais apresentava um problema desafiador que introduzia conceitos centrais da robótica. Esses projetos consistiam em:

1. Aprender Robot Operating System (ROS)
2. Aprendizagem por Reforço para Seguir Parede com Robô
3. Compreensão de Comportamentos Humanos por Robô 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:

1. Configurar o Ambiente de Desenvolvimento
2. Entender o Simulador Gazebo
3. Escrever um “Hello World” em ROS

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, o que fiz no meu laptop HP de 2011, que era bom o 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 turtlesim e fazer a tartaruga desenhar o logotipo “M” da Mines:

Essa tarefa, embora parecesse simples, foi mais difícil do que parecia. Esse projeto acabou me apresentando ao conceito de sistemas em Malha Aberta e Malha Fechada. Para a descrição completa do projeto, confira csci473-p1.pdf ou você pode saber mais sobre este projeto e minha solução na página do projeto ROS Move Turtle.

Aprendizagem por Reforço para Seguir Parede com Robô

Este foi o segundo projeto que nos foi atribuído, e foi um dos projetos mais difíceis em que já trabalhei na faculdade. A descrição do projeto era a seguinte:

Neste projeto, os alunos projetarão e implementarão algoritmos de aprendizagem por reforço para ensinar um robô móvel autônomo a seguir uma parede e evitar colidir com obstáculos. Os alunos usarão a simulação Gazebo no ROS Melodic para simular um robô móvel omnidirecional chamado Triton, usando um mapa de ambiente fornecido a vocês. Os alunos usarão um scanner a laser no robô para realizar sensoriamento e aprendizado, sendo o robô controlado por comandos de direção e velocidade. Os alunos são obrigados a programar este projeto usando C++ ou Python no ROS Melodic executando no Ubuntu 18.04 LTS (ou seja, o mesmo ambiente de desenvolvimento usado no Projeto 1). Além disso, os alunos são obrigados a escrever um relatório seguindo o formato das conferências padrão de robótica da IEEE usando LATEX.

Para o algoritmo de aprendizagem por reforço, fomos instruídos a usar Q-Learning. Também usamos o ambiente de simulação Gazebo Stingray fornecido pela disciplina. O Stingray consistia no modelo Triton e na lógica de física. Também nos foi fornecido um labirinto para o robô seguir. No fim das contas, o ambiente parecia assim:

Nunca publiquei minha solução no GitHub nem na web porque ela não era muito boa e tinha muitos defeitos. Além disso, fazer o código funcionar 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 vê-lo aqui:

Para a descrição completa do projeto, confira csci473-p2.pdf

Compreensão de Comportamentos Humanos por Robô Usando Representações Baseadas em Esqueleto

Para o terceiro projeto, a descrição do projeto era a seguinte:

Neste projeto, os alunos implementarão várias representações baseadas em esqueleto (Entregável 1) e usarão Máquinas de Vetores de Suporte (SVMs) (Entregável 2) para classificar comportamentos humanos usando um conjunto público de dados de atividades coletado de um sensor Kinect V1. Além disso, os alunos são obrigados a escrever um relatório seguindo o formato das conferências padrão de robótica da 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 dados do sensor Kinect V1, do MSR Daily Activity 3D Dataset, e Máquinas de Vetores de Suporte para classificar certas ações/comportamentos humanos. Para a descrição completa do projeto, confira csci473-p3.pdf ou você pode saber mais sobre este projeto e minha solução na publicação do blog Prever Ações Humanas Usando LIBSVM.

Conclusão de CSCI473

CSCI473 é uma das, se nã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 consultar no meu currículo. Também foi a primeira disciplina em que senti que estava no meu elemento, pois eu nunca fui bom em fazer provas, mas me destacava na conclusão de projetos. Foi também por meio dessa disciplina que conheci o Dr. Hao Zhang, que eventualmente me ajudou a conseguir uma posição como assistente de pesquisa no Laboratório de Robótica Centrada no Ser Humano (HCR) da Mines.

Sessão de Campo de CS (Verão de 2020)

Durante o verão de 2020, entre concluir a CSCI473 e entrar no Laboratório HCR, fiz CSCI370 ou “Engenharia de Software Avançada” como parte do meu curso de graduação em CS na Colorado School of Mines. CSCI370 é uma disciplina que faz os alunos projetarem, implementarem e documentarem soluções relacionadas a software para uma empresa. Ela permite que os alunos apliquem o conhecimento das disciplinas a problemas reais de ciência da computação. Você pode saber mais sobre a disciplina aqui.

Na disciplina, você pode decidir em qual projeto/empresa vai trabalhar. A disciplina fornecia PDFs detalhando cada projeto e empresa. No fim, decidi trabalhar em um projeto publicado por uma empresa chamada Lunar Outpost chamado “Detecção de Deslizamento de Rodas em Tempo Real e Correções de Erro para Navegação Lunar Aprimorada”. Como o nome é longo, vamos dar ao projeto o alias de “Detecção de Deslizamento das Rodas”.

O Problema

A Lunar Outpost é uma startup tentando criar rovers lunares autônomos. Na lua, há muito pó lunar, conhecido por causar bastante deslizamento das rodas. Isso não é ideal porque o deslizamento das rodas pode fazer com que sistemas autônomos percam o controle de sua localização no mundo real. Na Terra, isso é resolvido usando dados de GPS para corrigir qualquer desvio causado pelo deslizamento das rodas. Mas o problema do GPS é que ele só funciona tendo mais de 30 satélites de navegação orbitando constantemente a Terra e transmitindo sinais únicos que permitem aos computadores calcular sua posição. Mas na lua, atualmente não existe algo como GPS. Sabendo disso, outro método além do GPS precisa ser usado para detectar o deslizamento das rodas. Um relatório mais detalhado sobre o problema do projeto pode ser visto aqui.

A Equipe

Este projeto não era simples, então tinha que ser feito em equipe. A equipe consistia em cinco colegas estudantes da Colorado School of Mines:

Este projeto não era um projeto simples, então tinha que ser feito em equipe. Essa equipe consistia em Mehmet Yilmaz (eu), Kane Bruce, Braedon O’Callaghan, Liam Williams e Kevin Grant.

O projeto exigia 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 de Robótica Centrada no Ser Humano (CSCI473) durante o semestre da primavera de 2020. Por causa disso, no início, ajudei todos a se atualizarem sobre ROS e sobre como desenvolver para ele.

Desafios

Neste projeto, houve muitos desafios. Mas o maior desafio que enfrentamos foi não ter acesso a um robô do mundo real para testes. Isso aconteceu por causa da COVID, que tornou tudo remoto e nos impediu de trabalhar nos laboratórios/prédios da Lunar Outpost. Por causa disso, tivemos que usar simulações.

Além disso, analisamos algumas pesquisas acadêmicas do WVU Navigation Lab para ter uma ideia de como o problema de deslizamento das rodas poderia ser resolvido para o caso de uso da Lunar Outpost, o que, para nós, como calouros e alunos do segundo ano da graduação, foi mais difícil do que esperávamos.

Outro desafio que enfrentamos foi a quantidade de tempo que tínhamos para trabalhar neste projeto. CSCI370 é uma disciplina de um mês. Mas o problema em si é um problema enorme que muitas empresas e acadêmicos têm tentado resolver/aprimorar por décadas. Então, um mês está longe de ser tempo suficiente para resolver esse problema. Mas, apesar de todos esses desafios, seguimos em frente e garantimos a entrega.

Conclusão

Depois de trabalhar em toda a pesquisa e desenvolvimento, determinamos que é quase impossível simular adequadamente a física da Lua digitalmente, então realmente tentar esse algoritmo em uma simulação não é bom e não vai produzir nenhuma pesquisa significativa na detecção de deslizamento das rodas no espaço e na Lua. Concluímos que montar um ambiente de teste adequado usando algo como areia e hardware real, como um robô Husky, é muito mais importante para esse tipo de pesquisa. Também atualizamos o código de detecção de deslizamento das rodas para funcionar como um nó ROS e ele funcionou corretamente, podendo ser facilmente importado para hardware real para testes. Este projeto me permitiu assumir um papel de liderança, educar meus colegas sobre desenvolvimento em ROS e ganhar experiência com Python, ROS e Gazebo enquanto enfrentava um problema complexo que eu nunca tinha encontrado antes. Mais importante ainda, essa experiência solidificou ainda mais minha paixão por robótica e reforçou meu desejo de seguir pesquisa na área, preparando o terreno para o que viria a seguir na minha jornada em robótica.

Começando No Laboratório HCR

Depois de concluir CSCI473, minha Sessão de Campo de CS no verão de 2020 e meu semestre de outono de 2020, decidi seguir pesquisa em robótica. Tive experiências tão boas tanto com CSCI473 quanto com a Sessão de Campo de CS que decidi que queria fazer pesquisa para o Laboratório HCR. Como já tinha conhecido o Dr. Zhang no ano anterior, decidi enviar um e-mail para ele e perguntar sobre quaisquer oportunidades que o laboratório pudesse ter em janeiro de 2021. Em cerca de 2 semanas, o Dr. Zhang demonstrou interesse, me apresentou opções de pesquisa e me ofereceu uma vaga no laboratório. Então comecei a trabalhar para o laboratório em fevereiro de 2021.

Vídeo de Introdução

Aqui está meu vídeo de introdução que gravei alguns meses depois de começar no Laboratório HCR. Ele foi gravado em maio de 2021 e aborda a pesquisa na qual eu me concentraria no Laboratório HCR durante o verão de 2021:

Meu Projeto

Ao longo do meu tempo no Laboratório HCR, concentrei-me principalmente no projeto Triton. O projeto Triton é um robô móvel desenvolvido pelo Human Centered Robotics Lab na Colorado School of Mines. É um robô terrestre triangular com rodas omni movido pelo Jetson Nano da NVIDIA.

O Triton, em uma visão geral simples, consistia nas seguintes partes:

• NVIDIA Jetson Nano
• Placa controladora A205 Seed Studio da NVIDIA
• Arduino Mega
• Cartão Micro SD de 64 GB
• Corpo personalizado impresso em 3D
• 3 rodas mecanum
• 1 bateria AR
• Circuitos personalizados para distribuição de energia e fiação otimizadas
• Câmera Realsense D435 da Intel
• Alguns LEDs

Ele foi projetado, construído e fabricado por volta de 2018-2020 como um robô para fins educacionais. Quando entrei, o Triton já estava bem estabelecido, e o laboratório estava considerando fazer uma nova versão dele. No entanto, o principal problema do Triton era seu software. O Triton conseguia se mover, carregar e funcionar em um sentido básico, mas realmente não fazia nada inteligente. Ele até mesmo não tinha a capacidade de fazer movimentos mais avançados.

Para começar a resolver isso, o laboratório montou uma área onde pudéssemos acompanhar o Triton. Para isso, eles criaram uma área de 2 metros por 2 metros com 8 câmeras Optitrack Flex (Infravermelho) em uma formação parecida com um quadrado, cerca de 6 a 7 pés acima do chão.

Além de construir essa área, cada Triton tinha três esferas cinzas presas no topo de seus corpos.

Com essa configuração, essencialmente construímos nosso próprio sistema de GPS em pequena escala, que nos permitia obter as coordenadas exatas em metros de um Triton em nossa área de interesse. Usando as câmeras infravermelhas Optitrack e as esferas cinzas da Optitrack em uma forma triangular, podíamos تحديد as coordenadas exatas de um Triton em nossa área. Isso nos permitiu aplicar um sistema em malha fechada para melhor precisão no movimento.

O sistema Optitrack fornecia dados de posição e orientação a cerca de 120 Hz com precisão submilimétrica quando devidamente calibrado. Os três marcadores reflexivos de cada Triton formavam um padrão triangular único que o sistema podia rastrear como um corpo rígido. O sistema de coordenadas foi calibrado para que (0,0) ficasse no centro da área de rastreamento, com os eixos X e Y alinhados com a geometria da sala. Mas, apesar desses dados precisos de posicionamento, o Triton ainda tinha dificuldades com o movimento.

Com essa configuração, um recurso central que queríamos fornecer ao Triton era a capacidade de se mover até uma coordenada específica. O usuário, ou o software dele, poderia fornecer uma coordenada (x, y) dentro da sua área de interesse. Então o robô se moveria até essa coordenada o mais rápido, preciso e perfeitamente possível. Quando entrei, esse recurso existia, mas não estava funcionando muito bem. Aqui está uma animação simples mostrando como a lógica original de movimento funcionava:

Eu não gravei a solução original em ação, então criei esta animação simples mostrando a lógica antiga de movimento em ação. Sabendo disso, quais são os problemas com esse método?

1. É muito lento
2. Faz o robô ocupar muito espaço apenas para ir até um ponto específico. Isso tornou difícil para nós usar essa solução quando vários Tritons estavam se movendo ao redor.

Então por que esse comportamento estava acontecendo? O problema era que o Triton primeiro virava, alterando seu alfa, até apontar para o ponto-alvo dentro de uma margem de erro específica. Depois ele avançava em disparada e, depois que seu theta saía do alvo por uma quantidade específica, ele parava e começava a virar de novo até que o alfa estivesse dentro daquele intervalo aceitável para o objetivo. Então ele avançava de novo e continuava fazendo isso até chegar ao ponto. Além disso, à medida que se aproximava cada vez mais do ponto de destino, a velocidade de giro e de disparada ficava muito mais lenta para garantir que não ultrapassasse o alvo. Isso fazia com que o Triton tivesse um movimento antinatural, demorasse demais para chegar a um ponto-alvo e exigisse tanta área apenas para alcançar um ponto específico. Então, com todos esses problemas, e dado o quão essencial esse recurso era para o desenvolvimento do projeto Triton, quando comecei a trabalhar no Laboratório HCR, minha primeira tarefa foi desenvolver soluções mais eficazes que permitissem ao Triton navegar melhor até um ponto de destino.

Sabendo disso, passei muito tempo pesquisando a melhor maneira possível de abordar esse problema. Ironicamente, eu estava fazendo uma disciplina chamada Introduction to Feedback Control Systems (EENG307) na Mines. No início dessa disciplina, aprendemos sobre o conceito de controladores em malha aberta e controladores em malha fechada. Sabendo disso, e depois de algumas conversas que tive com o professor dessa disciplina e com meu colega de quarto inteligente, ficou claro que esse objetivo de levar o Triton até um ponto-alvo era um problema de sistema em malha fechada.

Agora, após testes e pesquisas extensivos, desenvolvi duas abordagens distintas de controlador para os Tritons:

Método 1: Controlador Distância-Theta

Essa abordagem usava dois controladores proporcionais separados operando simultaneamente:

• Controlador de Distância: Calculava a distância euclidiana até o alvo e aplicava um ganho proporcional para determinar a velocidade para frente/para trás
• Controlador de Theta: Calculava o erro angular entre a direção atual do robô e a direção desejada até o alvo, aplicando um ganho proporcional separado para a velocidade de rotação

O algoritmo calculava continuamente a distância euclidiana até o alvo e o erro angular entre a direção atual do robô e a direção desejada. Dois ganhos proporcionais separados eram aplicados para gerar, respectivamente, velocidades linear e angular.

Isso fazia com que o Triton naturalmente se virasse em direção ao objetivo enquanto simultaneamente avançava, criando trajetórias curvas suaves. A principal vantagem era que o robô mantinha sempre sua face frontal orientada para o destino, o que era crucial para aplicações baseadas em câmera.

Método 2: Controlador de Coordenadas X-Y

Essa abordagem tratava o robô como um plotter 2D, com controle independente do movimento em X e Y:

• Controlador X: Controlava diretamente o movimento leste-oeste com base no erro da coordenada X
• Controlador Y: 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 globais de velocidade para o referencial 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 as trajetórias mais diretas até os alvos e era significativamente mais rápido, mas o rumo do robô derivaria, já que não havia controle explícito de orientação.

No método #1, eu expliquei esse método em todos os detalhes no meu blog Move Turtle (TurtleSim). Eu recomendo fortemente que você leia esse blog para obter todos os detalhes sobre como os controladores PID funcionam em geral, bem como sobre como o método #1 funciona. Desenvolvi o método #1 usando o TurtleSim do ROS, depois transfiri esse código para o Triton e o atualizei para levar em conta um ambiente mais real.

O método #2 usava uma abordagem bastante diferente, mas igualmente eficaz. Em vez de pensar na orientação do robô e na distância até a meta, esse método trata o movimento como um problema de plano de coordenadas. O controlador calcula continuamente o erro nas direções X e Y separadamente. Por exemplo, se o robô precisa se 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 trabalhavam simultaneamente: um ajustava a velocidade do robô na direção X com base no erro em X, enquanto o outro tratava do movimento na direção Y com base no erro em Y. Isso criava uma trajetória mais direta até a meta, semelhante a como se move a cabeça de uma impressora 3D, e permitia movimentos diagonais suaves. O robô não precisava girar explicitamente para encarar o alvo, tornando esse método particularmente eficaz em espaços apertados ou quando é necessário um posicionamento preciso.

Ambos os métodos se mostraram significativamente mais rápidos e confiáveis do que a abordagem original. Para ver esses novos métodos em ação, confira a Playlist Tritons em Ação, que mostra todos os Tritons em ação com os novos métodos.

O que antes levava de 30 a 45 segundos para um movimento simples de ponto a ponto agora levava cerca de 8 a 12 segundos. Mais importante ainda, o Triton agora podia navegar com mais eficiência em espaços apertados, o que se tornou útil para nossos cenários com 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 do Sistema de Coordenadas: Um dos aspectos mais difíceis foi acertar as transformações de coordenadas. O sistema Optitrack fornecia dados em seu próprio referencial, o robô tinha seu referencial local, e eu precisava converter entre eles com precisão. As primeiras implementações faziam os robôs se moverem nas direções erradas porque eu havia confundido os cálculos da matriz de rotação.

Comportamento do Mundo Real vs. Ideal: O maior desafio foi considerar fatores do mundo real que não aparecem na teoria de controle dos livros. As rodas do robô tinham características diferentes de atrito, os motores não respondiam de forma idêntica e sempre havia alguma latência na cadeia de comunicação do Optitrack até o software de controle e o Arduino do robô. Passei semanas ajustando ganhos proporcionais e adicionando filtros de zona morta para levar em conta essas realidades físicas.

Problemas de Oscilação e Estabilidade: Minhas primeiras implementações sofreram com problemas de oscilação, nos quais 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 nos controladores PID e sobre a necessidade de um ajuste adequado dos ganhos. No fim, optei por um 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 entre Múltiplos Robôs: Quando vários robôs operavam simultaneamente, descobri padrões inesperados de interferência. Às vezes, os robôs “brigavam” pelo mesmo espaço ou criavam situações de impasse em que se bloqueavam 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 do movimento de um único Triton, o próximo desafio do laboratório foi fazer vários Tritons funcionarem 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ó conseguia controlar um Triton por vez, o que limitava severamente as possibilidades de pesquisa. O laboratório queria simular cenários em que vários 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 melhores mapas de SLAM (Localização e Mapeamento Simultâneos).

Para resolver isso, implementei uma abordagem de multiprocessamento usando a biblioteca multiprocessing do Python. Cada Triton recebeu seu próprio processo dedicado, que podia executar de forma independente enquanto ainda era coordenado por um sistema central de controle. Isso permitiu que vários Tritons se movessem simultaneamente sem interferir nos laços de controle uns dos outros.

Projeto da Arquitetura Multi-Robô

A arquitetura do sistema que desenvolvi consistia em vários componentes principais:

Processo Principal do Controlador: Este servia como coordenador central, lidando com interações da interface do usuário, planejamento de caminho e coordenação de alto nível entre os robôs. Ele mantinha o estado global e distribuía comandos para processos individuais dos robôs.

Processos Individuais dos Robôs: Cada Triton tinha seu próprio processo Python dedicado que tratava de:

• Cálculos de controle PID em tempo real a ~50 Hz
• Comunicação com o hardware do robô (Arduino/Jetson)
• Execução de trajetórias locais e desvio de obstáculos
• Relato de status de volta ao controlador principal

Comunicação em Memória Compartilhada: Usei os objetos multiprocessing.shared_memory e Queue do Python para permitir comunicação eficiente entre processos. Isso permitiu coordenação em tempo real sem o overhead da comunicação em rede.

Mecanismos de Sincronização: Para evitar conflitos quando vários robôs precisavam se coordenar (como evitar colisões), implementei semáforos e travas que permitiam que os robôs solicitassem acesso exclusivo a certas áreas do espaço de trabalho.

O desafio era garantir que todos os robôs pudessem operar seus laços de controle de forma independente, mantendo ao mesmo tempo 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 tratava de coordenação de nível superior, como prevenção de colisões e planejamento de caminho.

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 coordenado de caminho com desvio de obstáculos
• Comportamentos de robótica em enxame
• Mapeamento SLAM com múltiplos agentes
• Controle de formação e comportamentos de seguimento

Aqui está como era a configuração do laboratório com vários Tritons funcionando simultaneamente:

Também desenvolvi uma interface amigável que permitia aos pesquisadores definir visualmente as trajetórias de cada Triton. Você podia literalmente desenhar a trajetória que queria que cada robô seguisse, e eles executavam essas trajetórias com coordenação perfeita. Isso era incrivelmente útil para configurar experimentos complexos sem precisar programar manualmente cada movimento.

O sistema conseguia lidar com até 5 Tritons simultaneamente, cada um executando seus próprios controladores PID enquanto era coordenado pelo sistema central de controle. O desempenho era 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, desde o controle de um único robô até a coordenação de vários robôs: Playlist Tritons em Ação

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. Embora o sistema Optitrack nos desse dados de posicionamento incrivelmente precisos, eu queria explorar como os robôs poderiam usar seus sensores embarcados para melhorar sua consciência espacial e corrigir erros de coordenadas.

A ideia era que os Tritons pudessem usar seus sensores de profundidade para detectar outros Tritons em sua vizinhança e cruzar suas posições. Isso serviria a várias finalidades:

1. Correção de Erros: Se o sistema Optitrack tivesse qualquer deriva de calibração ou oclusão temporária, os robôs poderiam usar confirmação visual das posições uns dos outros para manter sistemas de coordenadas precisos.

2. SLAM Aprimorado: Ao ter vários robôs com sensores de profundidade trabalhando juntos, poderíamos criar mapas muito mais ricos do ambiente com pontos de dados redundantes.

3. Evitação de Colisões: O sensoriamento de profundidade em tempo real permitiria que os robôs detectassem e evitassem uns aos outros, mesmo se o sistema de controle central tivesse atrasos de comunicação.

Comecei a experimentar algoritmos que permitiriam aos Tritons:

• Detectar outros Tritons usando seu formato triangular distinto e marcadores esféricos refletivos
• 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 bastante tempo 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 adequadas, com uma área de base de aproximadamente 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 refletivas 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. Tive alguns resultados promissores em condições de iluminação controladas, embora isso 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 de meu tempo no laboratório terminar.

Desafios de Desempenho: Fazer todo esse processamento rodar em tempo real junto com os loops de controle do robô se mostrou desafiador. Experimentei abordagens de otimização para executar os algoritmos em cerca de 10-15Hz sem sobrecarregar as capacidades de processamento do Jetson Nano.

Infelizmente, tive que deixar o laboratório antes de conseguir concluir totalmente esse trabalho de visão computacional. Embora eu tenha tido alguns resultados iniciais promissores e aprendido muito sobre processamento de sensores de profundidade, não consegui levar o sistema a um estado totalmente confiável. Permaneceu uma direção de pesquisa interessante sobre a qual outros poderiam potencialmente construir.

Aqui está um vídeo meu testando os algoritmos de visão computacional:

Aqui estava a aparência da visão do sensor de profundidade 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 a simulação de cenários de carros autônomos, em que 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 por:

• Várias contas do Google Drive pertencentes a diferentes estudantes que já haviam se formado
• E-mails antigos enterrados em caixas de entrada
• Pastas aleatórias do Dropbox
• Vários repositórios do GitHub
• Repositórios do GitLab com organização inconsistente
• Anotações manuscritas que apenas pessoas específicas conseguiam interpretar

Essa documentação fragmentada era um grande problema. Novos estudantes passavam semanas apenas tentando descobrir como começar, e conhecimentos valiosos eram constantemente perdidos quando pessoas se formavam ou deixavam o laboratório.

Assumi para mim a tarefa de resolver esse problema de forma sistemática. Passei incontáveis horas rastreando cada peça de documentação, código, vídeo e anotação relacionada ao projeto Triton. Em seguida, organizei tudo em um repositório centralizado do GitLab 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 do 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 enviei vídeos instrucionais para o YouTube, incluindo tutoriais detalhados de calibração do Optitrack:

Também estabeleci padrões de documentação para garantir que futuras contribuições fossem organizadas e acessíveis. A estrutura de repositório que criei tornou-se 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. Isso incluiu instruções detalhadas de configuração para novos membros do laboratório, guias abrangentes de solução de problemas e demonstrações em vídeo de procedimentos complexos.

O impacto foi imediato e duradouro. Novos estudantes puderam se atualizar em dias, em vez de semanas. O repositório de documentação que criei ainda é usado pelo laboratório hoje, anos depois de eu ter saído. Ele se tornou a única fonte de verdade para o projeto Triton e economizou incontáveis horas/dias para pesquisadores futuros.

Mentoria e Transferência de Conhecimento

Um dos aspectos mais gratificantes do meu tempo no HCR Lab foi a oportunidade de orientar outras pessoas e compartilhar o conhecimento que adquiri. À medida que meu trabalho progredia e eu me tornava mais experiente com os sistemas Triton, assumi cada vez mais responsabilidade pelo treinamento de novos membros da equipe.

Mentoria de Sucessores do Laboratório

Enquanto eu me preparava para eventualmente deixar o laboratório para me concentrar em concluir meu curso e meu trabalho no eBay, certifiquei-me de treinar minuciosamente duas pessoas que assumiriam o projeto Triton após minha saída. Não se tratava apenas de mostrar como as चीज funcionavam, mas de garantir que elas realmente entendessem 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 vários 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 comuns de falha

A transferência de conhecimento foi incrivelmente completa. Passamos por sessões reais de depuração juntos, pedi que modificassem e ampliassem o código existente e garanti que pudessem configurar novos Tritons de forma independente a partir do zero.

Programa de Mentoria para Ensino Médio

Talvez ainda mais gratificante tenha sido minha experiência orientando uma estudante do ensino médio por meio do programa de extensão do laboratório. Essa foi uma ótima oportunidade para apresentar a alguém robótica, ciência da computação e pesquisa em uma fase formativa de sua educação.

Desenvolvi 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
• Os fundamentos de sistemas autônomos e controle por retroalimentação

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 em 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 LEDs que ela criou tornou-se uma parte permanente da base de código do Triton

O que tornou essa mentoria particularmente especial foi acompanhar sua evolução de praticamente não saber nada sobre programação até contribuir com código significativo para um projeto de pesquisa ativo. Ela passou de perguntar “O que é uma variável?” a depurar de forma independente problemas de comunicação do ROS e escrever suas próprias implementações de serviço.

O sistema de controle de LEDs que ela desenvolveu permitiu que pesquisadores alterassem facilmente as cores e os padrões dos LEDs da cabeça do Triton por meio de comandos simples do ROS. Isso pode parecer simples, mas exigiu compreensão da arquitetura do ROS, integração de hardware e padrões adequados de design de software. A contribuição dela ainda é usada no laboratório hoje.

A mentoria foi tão educativa para mim quanto para ela. Isso me forçou a decompor conceitos complexos em partes digeríveis e realmente pensar sobre os fundamentos do que estávamos fazendo. Ensinar outra pessoa me tornou um engenheiro e pesquisador melhor.

Colaboração com Pesquisa de Doutorado

Um dos aspectos profissionalmente mais gratificantes do meu tempo no laboratório foi trabalhar de perto com Peng, um estudante de doutorado cuja pesquisa se concentrava em algoritmos para carros autônomos. As melhorias de software que eu havia feito no sistema Triton ajudaram a dar suporte à sua pesquisa de doutorado.

A pesquisa de Peng exigia coordenação precisa e confiável entre múltiplos robôs 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 com tanta eficácia.

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 entre múltiplos robôs, Peng pôde simular cenários de interseção em que múltiplos “veículos” (Tritons) precisavam coordenar seus movimentos. O melhor tempo de resposta e posicionamento ajudou 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 coordenava com os outros, de forma semelhante ao que carros autônomos talvez precisem fazer.

Pesquisa em 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. Ter vários robôs com capacidades de sensoriamento coordenadas permitiu experimentos de mapeamento mais abrangentes.

O que tornou nossa colaboração particularmente valiosa foi que não era apenas eu ajudando a pesquisa dele; era uma parceria genuína. A compreensão que Peng tinha dos aspectos teóricos dos veículos autônomos ajudou a orientar minhas implementações práticas. O feedback e os requisitos dele me impulsionaram a tornar os sistemas mais robustos e capazes.

Passamos muitas horas juntos no laboratório, depurando cenários, discutindo diferentes estratégias de controle e explorando o que a plataforma Triton podia realizar. Peng se tornou ao mesmo tempo um colega e 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 saí do laboratório, Peng e eu continuamos em contato. Saber que meu trabalho continuou contribuindo para pesquisas importantes mesmo depois da minha saída foi extremamente recompensador.

Perspectiva: A Era Pré-LLM do Desenvolvimento

Vale notar que todo esse trabalho foi realizado durante a era pré-LLM do desenvolvimento de software. Tudo isso aconteceu entre 2020 e 2021 (principalmente 2021), antes de existirem ChatGPT, Claude, Perplexity ou ferramentas de desenvolvimento com IA como o Cursor IDE.

Cada linha de código foi escrita do zero, cada algoritmo foi pesquisado por meio de artigos acadêmicos e livros-texto, 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 um problema de transformação de coordenadas ou ajuste de PID, não podia simplesmente pedir a um assistente de IA que explicasse o conceito ou ajudasse a depurar o problema.

Isso tornou o processo de desenvolvimento significativamente mais desafiador, mas também mais educativo. Eu tinha que:

Pesquisar Tudo Manualmente: Entender a teoria de controle PID significava ler livros-texto e artigos acadêmicos. Descobrir transformações de coordenadas exigia trabalhar a matemática manualmente. 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 dos alvos, eu tinha que rastrear metodicamente a lógica, adicionar saídas de depuração e testar hipóteses uma por uma. Não havia IA para sugerir problemas potenciais ou ajudar a interpretar padrões de erro.

Aprender a Partir dos Primeiros Princípios: Sem a capacidade de perguntar rapidamente “como faço para implementar multiprocessamento em Python para robótica?” eu precisava 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.

A Documentação Era Crítica: Como eu não podia contar com IA para explicar o código depois, precisei escrever documentação e comentários extremamente claros. Essa disciplina provou ser 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 mais profundas de resolução de problemas e uma compreensão mais completa dos sistemas subjacentes. É fascinante pensar em como esse projeto poderia ter sido diferente com as ferramentas de desenvolvimento atuais disponíveis.

A Decisão Difícil de Sair

Por mais que eu amasse trabalhar no HCR Lab, no final de 2021 enfrentei uma decisão difícil que muitos estudantes encontram: equilibrar múltiplas oportunidades e responsabilidades. Eu estava, ao mesmo tempo, trabalhando em tempo integral como engenheiro de software na eBay, terminando meu curso de ciência da computação na Mines e contribuindo para a pesquisa no HCR Lab.

A oportunidade na eBay era significativa; foi meu primeiro grande cargo em engenharia de software, proporcionou uma experiência industrial inestimável e me deu uma renda sólida. No entanto, tentar manter trabalho em tempo integral, concluir meu curso e contribuir de maneira significativa para a pesquisa era simplesmente insustentável. Algo teria de ceder.

Quando abordei o Dr. Zhang sobre a possibilidade de reduzir minha carga de disciplinas para me concentrar mais no trabalho do laboratório, ele aconselhou fortemente contra isso. O raciocínio dele era sólido: concluir meu curso 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 matérias para focar em pesquisa, embora tentador, talvez não fosse a melhor decisão de longo prazo.

Então, em setembro de 2021, depois de cerca de 8 meses de trabalho intensivo no laboratório, tomei a difícil decisão de me afastar do meu papel de assistente de pesquisa para me concentrar na conclusão do meu curso e no meu trabalho na eBay. Foi uma das decisões profissionais mais difíceis que tive de tomar na época.

Mesmo depois de sair oficialmente do laboratório, continuei oferecendo suporte sempre que alguém precisava de ajuda com os sistemas que eu havia construído. Atualizava a documentação conforme necessário, respondia a perguntas sobre depuração e ajudava a solucionar problemas remotamente. As conexões que eu havia feito e o investimento que tinha no sucesso do projeto não simplesmente desapareceram porque eu já não fazia mais parte oficial da equipe.

Reflexões e Olhando para Trás

Agora, em 2025, quatro anos depois, me vejo refletindo sobre aquela época com emoções complexas. Meu caminho profissional me levou profundamente ao desenvolvimento web e à engenharia de IA/ML, áreas que foram incrivelmente gratificantes e proporcionaram enormes oportunidades de crescimento e impacto.

Ainda assim, há uma parte de mim que se pergunta “e se”. Robótica era, 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 do mundo real, que o desenvolvimento web e até mesmo o trabalho com IA não conseguem replicar completamente.

Às vezes me pergunto o que poderia ter acontecido se eu tivesse seguido um caminho diferente. E se eu tivesse encontrado uma forma de continuar na pesquisa em robótica? E se eu tivesse feito pós-graduação imediatamente depois de concluir minha graduação? E se eu tivesse escolhido priorizar o trabalho no laboratório em vez da experiência na indústria?

Mas também reconheço que todo caminho tem seus prós e contras. 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 usados por milhões de pessoas. Essas experiências me tornaram um engenheiro melhor no geral.

O trabalho que fiz no HCR Lab continua influenciando como abordo problemas hoje. O pensamento sistemático exigido pelos sistemas de controle PID aparece em como projeto ciclos de feedback em sistemas de software. As habilidades de documentação e preservação de conhecimento que desenvolvi foram inestimáveis em cada função desde então. A experiência de orientar e ensinar moldou a forma como trabalho com desenvolvedores juniores e contribuo para o compartilhamento de conhecimento da equipe.

Mais importante ainda, a experiência me ensinou que eu prospero quando trabalho 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 a experiência no HCR Lab, fico impressionado com o quanto conquistei em um período relativamente curto. Os sistemas que construí mudaram fundamentalmente a forma como a plataforma Triton operava, e muitas dessas melhorias ainda estão sendo usadas hoje. O repositório de documentação que criei se tornou a base de conhecimento de todo o projeto. Os relacionamentos de mentoria que formei tiveram impacto duradouro nas pessoas com quem trabalhei.

Mas talvez o mais significativo seja que a experiência me mostrou do que sou capaz quando trabalho em problemas pelos quais sou verdadeiramente apaixonado. Nesses oito meses, eu:

• Melhorei o sistema de controle de movimento do robô que estava limitando a plataforma
• Construi um sistema de coordenação de múltiplos robôs do zero
• Integrei capacidades de visão computacional e fusão de sensores
• Criei um sistema abrangente de documentação e gestão do conhecimento
• Orientei várias pessoas e ajudei 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 em outras direções, minha paixão pela robótica não diminuiu. Ainda acompanho os desenvolvimentos na área, fico animado 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 estão cada vez mais relevantes para a robótica. A experiência profissional que adquiri me ensinou como construir sistemas robustos e escaláveis. Talvez haja um futuro em que 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 sobre que tipos de trabalho considero mais gratificantes. Mesmo que às vezes eu sinta falta, sei que as lições que aprendi e as abordagens que desenvolvi continuam a influenciar tudo o que faço.

Os robôs Triton ainda estão lá, ainda servindo pesquisadores, ainda possibilitando trabalhos importantes. E isso é realmente maravilhoso.