Lições Aprendidas em Experimentação Robótica

Neste artigo, a gente dá uma olhada em alguns métodos e experiências que não deram certo no nosso projeto. Queremos compartilhar nossas vivências pra que outros possam aprender com nossos erros. Ao entender o que não funcionou, a gente pode ter um conhecimento melhor pra melhorias futuras.

#Destilação de Política Privilegiada e História de Observação

A gente tentou usar informações especiais, como parâmetros chave e posições reais, pra treinar uma política que pudesse funcionar melhor. Essa abordagem envolveu aprendizado supervisionado e verificações regulares enquanto o modelo estava rodando. No entanto, não melhorou o Desempenho. Na verdade, causou problemas quando a gente incluiu um histórico mais longo de observações. Um motivo pode ser que o sistema de temporização que usamos em Python não era exato, dificultando a confiança na história. Esse problema era menos sério no Unitree A1, que tem um sistema de temporização melhor.

#Agarrando com Precisão para Lançamentos

Pra melhorar nossas técnicas de pegar e lançar, a gente coletou muitos dados de demonstrações humanas. Infelizmente, mesmo com 500 exemplos, os pequenos movimentos do controlador causaram problemas na manipulação dos objetos pelo Robô. Acreditamos que ter mais dados poderia ajudar a criar um processo de pega e lançamento mais confiável.

#Confiabilidade do Sistema para Implementação Totalmente Desconectada

Nosso sistema pode realizar tarefas sem precisar estar conectado a cabos. No entanto, não era confiável o suficiente no geral. Enfrentamos alguns desafios de hardware e de sistema. Como o peso do robô não estava bem equilibrado, as articulações provavelmente superaqueceriam depois de um tempo curto. Isso fez com que o sistema entrasse em estado de erro, levando a gente a esfriar os motores frequentemente e ajustar a política pra economizar energia.

Outro problema foi com a fonte de energia. A bateria fornece diferentes voltagens dependendo do nível de carga. Quando estava completamente carregada, a voltagem era muito alta pra certos componentes. À medida que descarregava, as ações do robô ficavam mais lentas e menos eficazes.

#Integração de Velocidade

Usamos o ARKit da iOS pra ajudar a rastrear a posição do robô usando um iPhone. Infelizmente, a posição da câmera frequentemente se tornava pouco confiável durante movimentos rápidos, como lançar. Mesmo que o tempo de comunicação entre o iPhone e o sistema embarcado fosse rápido, ainda enfrentávamos um atraso de cerca de 140ms antes de atualizações serem feitas na posição do robô.

Esse atraso criou uma lacuna entre o que foi simulado e o que aconteceu na realidade. O resultado foi que o robô experimentou oscilações lentas que pioraram com o tempo. A gente poderia estimar a velocidade do robô usando várias leituras, mas a tremedeira dos atrasos continuava sendo um problema. Pra melhorar as coisas, pensamos em usar uma taxa de ação mais rápida e ajustar o sistema de forma mais eficiente.

#Posicionamento do iPhone

Escolhemos um lugar estratégico pra montar o iPhone no robô. Principalmente, queríamos que a câmera visse melhor o ambiente enquanto evitava qualquer visão do braço do robô durante as tarefas. O ângulo foi ajustado pra apontar pra cima, ajudando a capturar mais detalhes ao redor. Isso ajudou no processo de rastreamento. Além disso, garantimos que o braço do robô não conseguisse alcançar o celular, reduzindo o risco de dano.

#URDF do Robô

Para nossas tarefas que exigiam movimentos rápidos, percebemos que alguns métodos não fechavam a lacuna entre nosso modelo falho e o robô real. Nos demos conta de que precisávamos desmontar partes do robô, medi-las e atualizar nossos modelos pra fazer as coisas funcionarem melhor tanto nas simulações quanto no mundo real.

Enquanto tudo é perfeitamente cronometrado nas simulações, no mundo real, há muito atraso. O maior atraso vem da observação das articulações do robô e do envio de comandos pra elas. Não conseguimos medir todas as fontes desse atraso com precisão, mas descobrimos que ajustar o tempo total de 0ms pra 30ms ajudou no desempenho. Se não estiver alinhado corretamente, o robô tremia.

Outras fontes de atraso vieram dos sistemas de rastreamento de posição que usamos. O sistema de captura de movimento adicionou um atraso de 8ms, enquanto o iPhone tinha um atraso de 140ms. Tentamos fazer as simulações levarem em conta esses atrasos da melhor forma possível. Pra melhorias adicionais, até tentamos atualizar estimativas de posição usando métodos adicionais, mas esses esforços não deram melhorias significativas.

Também enfrentamos atrasos no nosso programa em Python. Por causa de certas restrições técnicas, todas as tarefas tinham que ser executadas uma após a outra, causando lentidão. Ao otimizar nosso código e separar tarefas que demoravam muito em partes diferentes, aumentamos a velocidade de observação e de comandos.

#Abordando Questões de Segurança

Quando tentamos implementar nossas Políticas diretamente da simulação pro mundo real, percebemos algumas preocupações de segurança. Pra resolver problemas como a tremedeira, aumentamos a regularização das ações. O robô ganharia menos recompensa se seus movimentos previstos estivessem muito distantes dos anteriores. Também desativamos alguns sensores que contribuíam pra tremedeira.

Enfrentamos problemas de superaquecimento com algumas articulações do robô devido ao design delas, que as fazia trabalhar mais do que o necessário. Ajustando nossos métodos de treinamento, conseguimos estender o tempo de operação pra cerca de 30 minutos antes de qualquer desligamento.

Além disso, nossas simulações mostraram alguns movimentos inseguros que poderiam causar problemas no mundo real. Pra promover uma postura equilibrada e ajudar na estabilidade, adicionamos novas recompensas pra desencorajar configurações arriscadas.

#Política de Manipulação

A gente também analisou os hiperparâmetros usados em nossas políticas de manipulação. A observação visual e o horizonte de propriocepção referem-se a quantas imagens e estados anteriores foram usados ao guiar o robô. Também monitoramos os passos e a frequência das ações realizadas no mundo real.

Pra manter o caminho do efetor final suave durante as operações, introduzimos um método pra misturar o caminho que o robô estava executando com atualizações na sua trajetória.

#Lançamento Dinâmico de Corpo Inteiro

Para tarefas de lançamento, precisávamos aumentar os passos pra manejar as ações e torná-las mais suaves. Descobrimos que, fazendo isso, poderíamos lançar itens mais longe. Também rastreamos parâmetros de perto pra garantir resultados mais suaves.

#Atingir o Efetor Final Leva a um Empurrão Robusto do Corpo Inteiro

Pra movimentos mais simples como empurrar, coletamos menos exemplos de demonstração. No entanto, colocamos uma ênfase extra em manter o caminho do robô estável suavizando as atualizações da trajetória.

#Políticas de Manipulação Plug-and-Play de Corpo Cruzado

Pra tarefas que requeriam alta precisão, tivemos que diminuir a frequência das ações pra manter a estabilidade. Usamos recursos pré-existentes sem precisar de dados adicionais pra essas tarefas.

#Avaliação de Reorganização de Copos no Mundo Real

A gente testou o sistema inteiro reorganizando copos sob várias condições desafiadoras. Questões como superfícies instáveis e iluminação severa fizeram parte do teste pra ver como o robô conseguiria se adaptar.

#Termos de Recompensa

Enquanto treinávamos nosso robô, consideramos vários fatores de recompensa que ajudaram a melhorar o desempenho. Esses fatores incluíam limites no alcance das articulações, aceleração e posição. Também focamos em manter o robô equilibrado e alinhado durante as ações.

#Lançamento no Mundo Real

Para tarefas de lançamento, entregamos objetos pro robô pra melhorar seu desempenho. Contamos falhas com base em se o robô caiu ou não durante as operações. Era considerado bem-sucedido se o objeto lançado aterrissasse dentro de uma certa distância do alvo.

#Ablations de Simulação

Durante os testes, criamos ensaios com uma variedade de condições iniciais pra ver como o robô conseguiria lidar com diferentes cenários. Medimos o desempenho observando como o robô mantinha o equilíbrio sem colidir com obstáculos.

#Custo do Sistema

Por fim, resumimos as despesas necessárias pra montar nosso sistema robótico. Essa divisão mostrou que nosso sistema completo custou cerca de um quarto do custo de outros sistemas robóticos similares disponíveis no mercado.

Ao compartilhar nossas descobertas e detalhar nossa jornada, esperamos inspirar outros que estão trabalhando em tecnologias similares. Entender o que funcionou e o que não funcionou nos permite refinar nossos métodos e avançar no desenvolvimento da robótica.