Meu Capítulo de Pesquisa em Robótica

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 tempo 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. Note que desde final de 2022, o Laboratório HCR se mudou da Colorado School of Mines para a Universidade de 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 encontrar minha paixão cedo na vida. Durante o ensino médio, passei um bom tempo tentando descobrir o que eu gostava e no que eu poderia ser bom. Após algumas tentativas e erros, consegui descobrir que minha paixão era a ciência da computação. Mas foi também durante esse tempo que descobri que tinha um amor avassalador por construir através do código.

Na Mines, tive a oportunidade de trabalhar no Laboratório de Robótica Centrada no Humano (HCR) sob a supervisão do Dr. Hao Zhang. Conheci o Dr. Zhang pela primeira vez na primavera de 2020 através de sua aula “Robótica Centrada no Humano” (CSCI473), e após o caos da COVID e do trabalho escolar, consegui trabalhar em seu laboratório no início da primavera de 2021.

Aula de Robótica Centrada no Humano (CSCI473)

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

1. Aprendizado do Sistema Operacional de Robôs (ROS)
2. Aprendizado por Reforço para Seguir Paredes com Robôs
3. Compreensão de Comportamentos Humanos por Robôs Usando Representações Baseadas em Esqueleto

Aprendizado do Sistema Operacional de Robôs (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, apenas tivemos que configurar nosso ambiente de desenvolvimento e seguir um tutorial introdutório sobre o Gazebo. Isso incluiu:

• Configurar o ROS Melodic, que fiz no meu laptop HP de 2011 que era bom o suficiente
• Instalar e configurar o ROS e o Gazebo
• Passar pelo tutorial do gazebosim e pelo 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 logo “M” da Mines:

Essa tarefa, embora parecesse simples, era mais difícil do que parecia. Este projeto eventualmente me apresentou ao conceito de sistemas de Laço Aberto e Laço Fechado. Para a descrição completa do projeto, confira csci473-p1.pdf ou você pode aprender mais sobre este projeto e minha solução na página do projeto ROS Move Turtle.

Aprendizado por Reforço para Seguir Paredes com Robôs

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 alunos irão projetar e implementar algoritmos de aprendizado 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, e usarão um mapa do ambiente que é fornecido a você. Os alunos usarão um scanner a laser no robô para realizar a detecção e aprendizado, onde o robô é controlado usando comandos de direção e velocidade. Os alunos 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 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 aprendizado por reforço, fomos instruídos a usar Q-Learning. Também usamos o ambiente de simulação Gazebo Stingray fornecido pela aula. 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:

Nunca publiquei minha solução no GitHub ou na web porque não era muito boa e estava cheia de falhas. Além disso, fazer o código funcionar no ambiente certo é bastante difícil e irritante. No entanto, eu tenho um vídeo de demonstração que enviei para a aula, 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ôs 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 de dados de atividades públicas coletadas 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 Conjunto de Dados de Atividades Diárias 3D da MSR, 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 aprender mais sobre este projeto e minha solução no post do blog Prever Ações Humanas Usando LIBSVM.

Conclusão do CSCI473

CSCI473 é uma das, se não a melhor aula 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 em meu currículo. Também foi a primeira aula onde senti que estava no meu elemento, já que nunca fui um bom aluno em provas, mas me destaquei em completar projetos. Foi também através desta aula 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 Humano (HCR) da Mines.

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

Durante o verão de 2020, entre a conclusão do CSCI473 e a entrada 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 alunos projetarem, implementarem e documentarem soluções relacionadas a software para uma empresa. Ele permite que os alunos apliquem o conhecimento adquirido nas aulas a problemas reais de ciência da computação. Você pode aprender mais sobre o curso aqui.

No curso, você decide em qual projeto/empresa irá trabalhar. O curso forneceu PDFs detalhando cada projeto e empresa. No final, decidi trabalhar em um projeto postado por uma empresa chamada Lunar Outpost chamado “Detecção de Deslizamento de Rodas em Tempo Real e Correções de Erros para Navegação Lunar Aprimorada”. Como o nome é longo, vamos dar ao projeto um apelido de “Detecção de Deslizamento de Rodas”.

O Problema

A Lunar Outpost é uma startup que tenta criar rovers lunares autônomos. Na lua, há muita poeira lunar que é conhecida por causar muito deslizamento de rodas. Isso não é ideal porque o deslizamento de 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 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 que os computadores calculem sua posição. Mas na lua, atualmente não existe nada parecido com um GPS. Sabendo disso, outro método além do GPS deve ser usado para detectar o deslizamento de rodas. Um relatório mais detalhado sobre o problema do projeto pode ser visualizado aqui.

A Equipe

Este projeto não era um projeto simples, então teve 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 teve que 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 aula de Robótica Centrada no Humano (CSCI473) durante o semestre da primavera de 2020. Devido a isso, logo no início, ajudei a colocar todos a par sobre o ROS e 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 se deveu ao COVID que tornou tudo remoto e nos impediu de trabalhar no laboratório/edifícios do Lunar Outpost. Devido a isso, tivemos que usar simulações.

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

Outro desafio que enfrentamos foi a quantidade de tempo que tivemos para trabalhar neste projeto. O CSCI370 é uma disciplina de um mês. Mas o problema em si é um problema massivo que muitas empresas e acadêmicos têm tentado resolver/aprimorar por décadas. Portanto, um mês está longe de ser tempo suficiente para resolver essa questão. Mas, apesar de todos esses desafios, perseveramos e nos certificamos de entregar.

Conclusão

Após trabalhar em toda a pesquisa e desenvolvimento, determinamos que é quase impossível simular a física lunar adequadamente de forma digital, então realmente tentar este algoritmo em uma simulação não é bom e não vai gerar nenhuma pesquisa significativa na detecção de deslizamento de rodas no espaço e na lua. Concluímos que configurar um ambiente de teste adequado usando algo como areia e hardware real, como um robô Husky, é muito mais importante para esse tipo de pesquisa. Atualizamos o código de detecção de deslizamento de rodas para funcionar como um nó ROS e ele funcionou corretamente e poderia ser facilmente importado para hardware real para testes. Este projeto me permitiu assumir um papel de liderança, educar meus colegas sobre desenvolvimento ROS e ganhar experiência com Python, ROS e Gazebo enquanto enfrentava um problema complexo que nunca havia encontrado antes. O mais importante, 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 em minha jornada na robótica.

Começando no Laboratório HCR

Após completar o 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 com o CSCI473 e a Sessão de Campo de CS que decidi que queria fazer pesquisa para o Laboratório HCR. Como conheci 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. Dentro de cerca de 2 semanas, o Dr. Zhang expressou interesse, me apresentou opções de pesquisa e me ofereceu um papel no laboratório. 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 após meu tempo no Laboratório HCR. Foi gravado em maio de 2021 e cobre a pesquisa na qual eu me concentraria no Laboratório HCR durante o verão de 2021:

Meu Projeto

Durante meu tempo no Laboratório HCR, concentrei-me principalmente no projeto Triton. O projeto Triton é um robô móvel desenvolvido pelo Laboratório de Robótica Centrada no Humano da Colorado School of Mines. É um robô terrestre de rodas omni-triangulares alimentado pelo NVIDIA Jetson Nano.

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

• NVIDIA Jetson Nano
• Placa de Carregamento A205 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 fiação
• Câmera Realsense D435 da Intel
• Algumas LEDs

Foi projetado, construído e fabricado entre 2018-2020 como um robô para fins educacionais. Quando me juntei, o Triton já estava bastante estabelecido, e o laboratório estava considerando fazer uma nova versão dele. No entanto, o principal problema com o Triton era seu software. O Triton podia se mover, carregar e funcionar de forma básica, mas não fazia nada inteligente. Ele até carecia da capacidade de fazer movimentos mais avançados.

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

Além de ter essa área construída, cada Triton tinha três bolas esféricas cinzas anexadas ao topo de seus corpos.

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

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

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

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

1. É realmente lento
2. Faz com que o robô ocupe 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.

Então, por que esse comportamento estava acontecendo? O problema era que o Triton primeiro girava, mudando seu alfa, até apontar para o ponto alvo dentro de uma margem de erro específica. Então, ele corria para frente, e depois que seu theta estava desviado do alvo por uma quantidade específica, ele parava e começava a girar novamente até que o alfa estivesse dentro daquela faixa aceitável para o objetivo. Então, ele corria novamente e continuava fazendo isso até chegar ao ponto. Além disso, à medida que se aproximava do ponto alvo, a velocidade de giro e corrida diminuía muito para garantir que não ultrapassasse. Isso resultou em um movimento não natural do Triton, levando uma eternidade para chegar a um ponto alvo e exigindo tanto espaço apenas para chegar a um ponto alvo específico. Portanto, com todos esses problemas, e dado quão essencial essa funcionalidade 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 alvo.

Sabendo disso, passei muito tempo pesquisando a melhor maneira possível de abordar esse problema. Ironicamente, estava fazendo uma disciplina chamada Introdução a Sistemas de Controle por Feedback (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 após algumas discussões que tive com o professor dessa disciplina e meu colega de quarto inteligente, ficou claro que esse objetivo de levar o Triton a um ponto alvo era um problema de sistema em malha fechada.

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

Método 1: Controlador Distância-Theta

Essa abordagem usou dois controladores proporcionais separados funcionando simultaneamente:

• Controlador de Distância: Calculou a distância euclidiana até o alvo e aplicou um ganho proporcional para determinar a velocidade para frente/para trás
• Controlador de Theta: Calculou o erro angular entre a direção atual do robô e a direção desejada para 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 foram aplicados para gerar velocidades lineares e angulares, respectivamente.

Isso resultou no Triton se virando naturalmente em direção ao objetivo enquanto se movia para frente, criando caminhos curvos suaves. A principal vantagem era que o robô sempre mantinha sua frente orientada em direção ao destino, o que era crucial para aplicações baseadas em câmera.

Método 2: Controlador de Coordenadas X-Y

Esta abordagem tratou o robô como um plotter 2D, com controle independente do movimento 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 calculou os erros das coordenadas X e Y de forma independente, aplicou ganhos proporcionais separados e, em seguida, transformou esses componentes de velocidade globais no quadro de coordenadas local do robô usando matrizes de rotação. Essa transformação foi necessária porque o sistema de tração de rodas omnidirecionais do robô exigia velocidades em seu próprio quadro de referência, e não em coordenadas globais. Este método produziu os caminhos mais diretos para os alvos e foi significativamente mais rápido, mas a direção do robô poderia desviar, uma vez que não havia controle de orientação explícito.

Para o método #1, eu entrei em detalhes completos sobre este método no meu blog Move Turtle (TurtleSim). Eu 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. Eu desenvolvi o método #1 usando o TurtleSim do ROS, e 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 sobre a orientação do robô e a distância até o objetivo, este 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ô 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 funcionaram simultaneamente: um ajustou a velocidade do robô na direção X com base no erro X, enquanto o outro lidou com o movimento na direção Y com base no erro Y. Isso criou um caminho mais direto para o objetivo, semelhante a como a cabeça de uma impressora 3D se move, e permitiu movimentos diagonais suaves. O robô não precisava se virar explicitamente para enfrentar seu alvo, tornando este método particularmente eficaz em espaços apertados ou quando um posicionamento preciso é necessário.

Ambos os métodos provaram ser significativamente mais rápidos e mais confiáveis do 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 de 30 a 45 segundos para um simples movimento ponto a ponto agora levava cerca de 8 a 12 segundos. Mais importante, o Triton agora podia 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 forneceu 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. As implementações iniciais tinham robôs se movendo nas direções erradas porque eu havia confundido os cálculos da matriz de rotação.

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

Oscilações 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 de ganho. Acabei optando por controle predominantemente proporcional com ganhos cuidadosamente ajustados em vez de PID completo, já que a 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 de interferência inesperados. Os robôs às vezes “lutavam” pelo mesmo espaço ou criavam situações de deadlock onde 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

Uma vez que resolvi o problema de movimento de um único Triton, o próximo desafio do laboratório foi fazer com que vários Tritons trabalhassem 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 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 SLAM (Localização e Mapeamento Simultâneos).

Para resolver isso, implementei uma abordagem de multiprocessamento usando a biblioteca de multiprocessamento do Python. Cada Triton recebeu seu próprio processo dedicado que poderia ser executado de forma independente, enquanto ainda era 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-chave:

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

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

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

Comunicação de 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 a sobrecarga da comunicação de rede.

Mecanismos de Sincronização: Para evitar conflitos quando vários robôs precisavam coordenar (como evitar colisões), implementei semáforos e bloqueios 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 loops de controle de forma independente, enquanto ainda mantinham a coordenação global. Cada processo de robô executava seus próprios cálculos PID e enviava comandos de motor diretamente para o hardware, enquanto o processo principal lidava com coordenação de alto nível, como prevenção de colisões e planejamento de caminhos.

O sistema multi-Triton abriu novas possibilidades de pesquisa. Agora podíamos simular:

• Cenários de comunicação veículo a veículo
• Planejamento de caminhos coordenados com prevençã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 funcionando simultaneamente:

Eu também desenvolvi uma interface amigável que permitia aos pesquisadores definir visualmente caminhos para cada Triton. Você poderia literalmente desenhar o caminho que queria que cada robô seguisse, e eles executariam esses caminhos com perfeita coordenação. Isso foi incrivelmente útil para configurar experimentos complexos sem ter que codificar manualmente cada movimento.

O sistema poderia lidar com até 5 Tritons simultaneamente, cada um executando seus próprios controladores PID enquanto era coordenado através do 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, desde o controle de robô único até a coordenação de múltiplos robôs: Playlist Tritons in Action

Integração do 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 a bordo 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 em sua proximidade e cruzar suas posições. Isso serviria a múltiplos propósitos:

1. Correção de Erros: Se o sistema Optitrack tivesse qualquer 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.

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: 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 com algoritmos que permitiriam que os Tritons:

• Detectassem outros Tritons usando sua forma triangular distinta e marcadores esféricos reflexivos
• Calculassem posições e orientações relativas usando dados de profundidade
• Comparassem essas medições com dados do Optitrack para identificar discrepâncias
• Potencialmente ajustassem seu sistema de coordenadas em tempo real para manter a precisão

Experimentos de Visão Computacional

Passei um tempo considerável experimentando com um pipeline de visão computacional que funcionava em várias etapas:

Processamento de Dados de Profundidade: O Intel RealSense D435 forneceu tanto streams de dados RGB quanto de profundidade. Trabalhei principalmente com os dados de profundidade, que vinham como uma matriz de 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 no nível do chão (filtrando paredes, teto, etc.) e procurando objetos com as características de tamanho corretas, aproximadamente 0,3x0,3 metros de área. Tentei usar detecção de bordas e análise geométrica para identificar o perfil distinto do Triton, com resultados mistos.

Experimentos de Reconhecimento de Marcadores: As três esferas reflexivas em cada Triton pareciam ser a característica de detecção mais promissora. 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 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 não tenha conseguido fazer isso funcionar completamente antes do término do meu tempo no laboratório.

Desafios de Desempenho: Fazer todo esse processamento funcionar em tempo real junto com os loops de controle do robô provou ser desafiador. Experimentei abordagens de otimização para executar os algoritmos a 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 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. Permaneceu 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 visão do sensor de profundidade parecia durante meus experimentos:

Embora eu não tenha completado 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 espalhadas por:

• Vários contas do Google Drive pertencentes a diferentes alunos que se formaram
• E-mails antigos enterrados em 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 alunos passavam semanas apenas tentando descobrir como começar, e conhecimentos valiosos estavam constantemente sendo perdidos quando as pessoas se formavam ou deixavam o laboratório.

Assumi a responsabilidade de resolver esse problema de forma sistemática. Passei incontáveis horas rastreando cada peça de documentação, código, vídeo e nota relacionada ao projeto Triton. Depois, 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 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 designs 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 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 explicativos de procedimentos complexos.

O impacto foi imediato e duradouro. Novos alunos podiam se atualizar em dias em vez de semanas. O repositório de documentação que criei ainda está sendo usado pelo laboratório hoje, anos depois que saí. Ele se tornou a única fonte de verdade para o projeto Triton e economizou incontáveis 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 mentorar outros e compartilhar o conhecimento que adquiri. À medida que meu trabalho progredia e eu me tornava mais experiente com os sistemas Triton, assumi uma responsabilidade crescente pelo treinamento de novos membros da equipe.

Mentoria de Sucessores do Laboratório

Enquanto me preparava para eventualmente deixar o laboratório para me concentrar em terminar meu diploma e meu trabalho na eBay, certifiquei-me de treinar minuciosamente duas pessoas que assumiriam o projeto Triton após minha partida. Isso não se tratava apenas de mostrar como as coisas funcionavam, mas de garantir que eles realmente entendessem os princípios subjacentes para que pudessem continuar inovando.

Passei semanas trabalhando de perto com eles, passando por:

• As bases matemáticas dos sistemas de controle PID
• A arquitetura de multiprocessamento para coordenar múltiplos robôs
• A integração do sensor de profundidade e 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, fiz com que eles modificassem e estendessem o código existente, e garanti que pudessem configurar novos Tritons de forma independente desde o início.

Programa de Mentoria para o Ensino Médio

Talvez ainda mais gratificante foi minha experiência como mentor de um estudante do ensino médio através do programa de extensão do laboratório. Esta foi uma ótima oportunidade para apresentar alguém à robótica, ciência da computação e pesquisa em um estágio formativo 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 a 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 de feedback

ROS (Sistema Operacional de Robôs):

• Compreensão do sistema de mensagens publish/subscribe
• Criação de nós e serviços
• Trabalhando com arquivos de lançamento e servidores de parâmetros

Trabalho Prático em Projetos:

• Colaboramos na criação de um serviço ROS que controlava o sistema de LED na cabeça do Triton
• Ela aprendeu a escrever código limpo e documentado que se integrava com nossos sistemas existentes
• O serviço de controle de LED que ela criou se tornou uma parte permanente da base de código do Triton

O que tornou essa mentoria particularmente especial foi observar seu progresso de não 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?” para depurar de forma independente problemas de comunicação do ROS e escrever suas próprias implementações de serviços.

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 comandos ROS simples. Isso pode parecer simples, mas exigiu compreensão da arquitetura do ROS, interface de hardware e padrões adequados de design de software. A contribuição dela ainda está sendo usada no laboratório hoje.

A mentoria foi tão educativa para mim quanto foi 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 mais gratificantes profissionalmente 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 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 Gestão de Interseções: Com os controladores PID melhorados 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 tempo e posicionamento ajudaram a tornar esses estudos mais viáveis.

Comunicação Veículo-a-Veículo: A estrutura de multi-processamento que desenvolvi permitiu que Peng implementasse e testasse protocolos de comunicação entre veículos simulados. Cada Triton poderia tomar decisões enquanto ainda coordenava com os outros, semelhante a como os carros autônomos poderiam 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. Ter múltiplos 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 sua pesquisa, era 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 juntos no laboratório, depurando cenários, discutindo diferentes estratégias de controle e explorando o que a plataforma Triton poderia realizar. 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 uma engenharia sólida e pesquisa podem trabalhar juntas para criar resultados úteis.

Mesmo depois de deixar o laboratório, Peng e eu mantivemos contato. Saber que meu trabalho continuou a contribuir para pesquisas importantes mesmo após minha saída foi extremamente gratificante.

Perspectiva: A Era Pré-LLM de Desenvolvimento

Vale a pena notar que todo esse trabalho foi realizado durante a era pré-LLM de desenvolvimento de software. Tudo isso ocorreu entre 2020 e 2021 (principalmente em 2021), antes que ChatGPT, Claude, Perplexity ou ferramentas de desenvolvimento impulsionadas por IA como Cursor IDE existissem.

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 envolveu métodos tradicionais como declaraçõ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 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: Compreender a teoria de controle PID significava ler livros didáticos e artigos acadêmicos. Descobrir transformações de coordenadas exigia trabalhar com a matemática à mão. Cada conceito tinha que 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 em torno de alvos, eu tinha que rastrear metódicamente a lógica, adicionar saídas de depuração e testar hipóteses uma a uma. Não havia IA para sugerir problemas potenciais ou ajudar a interpretar padrões de erro.

Aprender a Partir de Princípios Fundamentais: Sem a capacidade de perguntar rapidamente “como implemento multi-processamento em Python para robótica?”, eu tinha 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 não podia contar com IA para explicar o código mais tarde, eu tinha que escrever documentação e comentários extremamente claros. Essa disciplina se mostrou inestimável ao transferir conhecimento para outros.

Olhando para trás, enquanto ferramentas modernas de IA teriam 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 em como este projeto poderia ter sido diferente com as ferramentas de desenvolvimento de hoje disponíveis.

A Difícil Decisão de Sair

Por mais que eu amasse trabalhar no Laboratório HCR, no final de 2021 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, terminando meu diploma em ciência da computação na Mines e contribuindo para a pesquisa no Laboratório HCR.

A oportunidade na eBay era significativa; era meu primeiro grande papel em engenharia de software, fornecia uma experiência valiosa na indústria e me proporcionava uma renda sólida. No entanto, tentar manter um trabalho em tempo integral, completar meu diploma e contribuir de forma significativa para a pesquisa era simplesmente insustentável. Algo tinha que ceder.

Quando abordei o Dr. Zhang sobre a possibilidade de reduzir minha carga de cursos para me concentrar mais no trabalho do laboratório, ele me aconselhou fortemente contra isso. Seu raciocínio era sólido: completar meu diploma deveria ser a prioridade, e a experiência na indústria na eBay seria valiosa para meu desenvolvimento profissional. Ele sentiu que abandonar aulas para se concentrar 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 intenso no laboratório, tomei a difícil decisão de me afastar do meu papel de assistente de pesquisa para me concentrar em completar meu diploma 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 fornecer 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 fiz e o investimento que tinha no sucesso do projeto não desapareceram apenas porque eu não fazia mais parte oficialmente da equipe.

Reflexões e Olhando Para Trás

Agora, em 2025, quatro anos depois, me vejo refletindo sobre aquele tempo com emoções complexas. Meu caminho 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.

Ainda assim, há uma parte de mim que se pergunta “e se.” A robótica foi, e honestamente ainda é, minha verdadeira paixão. Há algo sobre trabalhar com sistemas físicos, ver seu código se traduzir em movimento e comportamento no mundo real, que o desenvolvimento web e até mesmo o trabalho em IA não conseguem replicar.

Às vezes me pergunto o que poderia ter acontecido se eu tivesse seguido um caminho diferente. E se eu tivesse encontrado uma maneira de permanecer na pesquisa em robótica? E se eu tivesse buscado a pós-graduação imediatamente após terminar meu diploma de 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 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 usam. Essas experiências me tornaram um engenheiro melhor no geral.

O trabalho que fiz no Laboratório HCR continua a influenciar como abordo problemas hoje. O pensamento sistemático exigido para sistemas de controle PID aparece em como projeto laços de feedback em sistemas de software. As habilidades de documentação e preservação do conhecimento que desenvolvi foram inestimáveis em todos os papéis desde então. A experiência de mentoria e ensino moldou como trabalho com desenvolvedores juniores e contribuo para o compartilhamento de conhecimento na equipe.

Mais importante ainda, a experiência me ensinou que eu 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 Laboratório HCR, fico impressionado com o quanto consegui realizar em um período relativamente curto. Os sistemas que construí mudaram fundamentalmente 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 para todo o projeto. As relações de mentoria que formei tiveram um impacto duradouro nas pessoas com quem trabalhei.

Mas talvez, mais significativamente, a experiência me mostrou do que sou capaz ao trabalhar em problemas pelos quais sou verdadeiramente apaixonado. Naqueles oito meses, eu:

• Melhorou o sistema de controle de movimento do robô que estava limitando a plataforma
• Construiu um sistema de coordenação de múltiplos robôs do zero
• Integrou capacidades de visão computacional e fusão de sensores
• Criou uma documentação abrangente e um sistema de gestão do conhecimento
• Orientou várias pessoas e ajudou na transferência de conhecimento
• Apoio à pesquisa em nível de doutorado em veículos autônomos

Isso não se tratava apenas das conquistas técnicas, embora essas tenham sido 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. Eu 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 na indústria que adquiri me ensinou como construir sistemas robustos e escaláveis. Talvez haja um futuro onde esses diferentes aspectos da minha experiência se unam de maneiras inesperadas.

Por enquanto, sou grato pelo tempo que passei no Laboratório HCR 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. Embora às vezes 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.