Anteriormente

É importante que você tenha visto o post anterior Desenho mecânico do Bbot, para um completo entendimento do desenvolvimento do projeto.

Introdução

Na etapa quatro do processo de construção do Bbot, podemos analisar o desenvolvimento de sua simulação feita no Gazebo, utilizando o ROS Noetic.

Caso você não saiba, o Robot Operating System (ROS) é um framework de robótica OpenSource com diversas ferramentas implementadas para facilitar o desenvolvimento de aplicações em robótica. Você pode consultar este link para mais informações sobre o ROS. Para o desenvolvimento do Bbot, estamos usando a versão do ROS Noetic.


Representação e controle do sistema

O Bbot, assim como vários outros robôs de alto-balanceamento, pode ser tratado como um pêndulo invertido. Diferente de um pêndulo convencional, esse sistema visa equilibrar a sua haste na posição vertical para cima, como mostrado na figura abaixo.

Pêndulo invertido

Ao deixá-lo oscilar livremente, o pêndulo irá cair até tocar o chão. Contudo, caso uma força seja exercida na base do robô, de forma a deslocá-lo para frente ou para trás, uma pseudo-força (que é a inércia) agirá sobre a haste no sentido contrário ao torque aplicado pelo seu próprio peso. Com a força adequada, podemos fazer o pêndulo voltar à posição vertical. Como esta posição é instável, a haste voltará a cair e, portando, outra força deve ser aplicada.

Caso possamos monitorar a inclinação instantânea do pêndulo e, a partir dela, calcular e exercer a força adequada para que ele volte à posição vertical, conseguiremos mantê-lo em equilíbrio. A seguir está o diagrama de blocos do sistema.

Diagrama de blocos

Este é um sistema realimentado, onde estaremos a todo tempo enviando a inclinação de equilíbrio do robô como entrada (~ 0°) e mandando para o controlador a diferença entre esta e a inclinação atual do robô. Este sinal, chamado de “erro”, é a entrada do controlador, o qual este usará para calcular a força necessária para manter o Bbot em equilíbrio.

O controlador será do tipo PID (Proportional-Integral-Derivative). Este tipo de controlador é um dos mais utilizados em sistemas de controle. Ele pode ser descrito pela seguinte equação:

Equação do PID

Como podemos ver, ele possui 3 parâmetros de configuração: Kp, Ki e Kd. Cada um desses influencia na velocidade de recuperação da posição de equilíbrio, no tempo necessário para que ele se estabilize nessa posição e no tipo de resposta transitória que o sistema terá para alcançar o equilíbrio. Caso você queira saber mais sobre o controlador PID, pode acessar este link.

Configurando a simulação no ROS

Para poder simular o Bbot no ROS, criamos um arquivo URDF (Unified Robot Description Format), que contêm todas as informações necessárias para simular o robô no Gazebo. Neste arquivo estão definidas todas as partes móveis do robô, assim como tipo de juntas, parâmetros inerciais e de colisão, além dos aspectos visuais, baseados no desenho mecânico que fizemos e mostramos no post anterior (clique aqui para saber mais).

Para poder enviar comandos de velocidade para o robô e conseguir movê-lo para frente e para trás, assim como girar em torno do próprio eixo, utilizamos um controlador de direção diferencial implementado no pacote ros_control.

Como o Bbot possui pernas articuladas, também configuramos controladores de posição para cada uma das suas juntas. Contudo, para esta simulação, não utilizaremos o controle das pernas.

Até então, seria possível mover o robô, mas para que ele seja autônomo, são necessários alguns sensores para que este consiga sentir o ambiente ao seu redor, ter noção de sua posição e orientação no espaço, além de ver o que está a sua frente. Portando, também no URDF, configuramos os plugins do Gazebo que simulam um sensor IMU (Inertial Mesurement Unit), para monitorar a inclinação do robô assim como sua velocidade e aceleração angular em 3 dimensões; um Lidar (Light Detection and Ranging), para identificar possíveis obstáculos e uma câmera, que nos permite usar a visão computacional para dar mais inteligência ao robô.

Criamos, então, três pacotes para guardar todas essas informações:

  • bbot_description: contém o arquivo URDF e os arquivos de renderização do Bbot.
  • bbot_gazebo: contém a arquivo do mundo virtual e arquivos .launch para iniciar a simulação.
  • bbot_control: contém os arquivos de configuração dos controladores das juntas além do algoritmo de controle que mantêm o robô equilibrado.

Com tudo isso configurado, já podemos visualizar o robô no Gazebo e também no Rviz.

Visualização do Bbot no Gazebo

Algoritmo de Controle

Para criar o algoritmo de controle do robô, utilizamos um pacote do ROS pid, que implementa um controlador do tipo PID que já utiliza toda a interface do ROS como tópicos e parâmetros. Este pacote contém um nó que, após receber uma mensagem pelo tópico /setpoint, é habilitado e, sempre que recebe uma mensagem pelo tópico /state, calcula o erro entre ambas, aplica a fórmula do PID e publica outra mensagem no tópico /control_effort. O processo acontece de forma assíncrona, portando, cabe ao usuário manter as publicações em /state o mais constante possível na frequência que desejar. Manter o loop de controle em uma frequência única eleva a precisão do controlador e melhora os resultados. No caso do Bbot, o loop de controle roda a 100 Hz, que é a frequência de aquisição das informações de inclinação, fornecida pelo IMU.

Como o algorítmo do controlador já está pronto, criamos um nó que apenas redireciona as informações necessárias compartilhadas pela interface do ROS para os tópicos certos com o formato de mensagem adequado. Caso você esteja ouvindo esses termos referentes ao ROS pela primeira vez, vale a pena dar uma olhada nesse tutorial: link.

Uma representação gráfica dos processos que ocorrem no ROS pode ser visto na figura abaixo.

Diagrama de processos no ROS

Nesta imagem, há dois controladores PID. O controlador /balancing_pid calcula o esforço de controle para manter o robô equilibrado em uma angulação específica, enquanto o controlador /velocity_pid qual é este ângulo, com base nos comandos de velocidade que o robô recebe do usuário ou, eventualmente, de um planejador de trajetórias.

O nó /freq_pub tem a função de diminuir a frequência de publicações no tópico /setpoint do /balancing_pid, para diminuir ruído no controle. Como estas mensagens alteram o ângulo de equilíbrio e o robô precisa de tempo para se estabilizar, notamos pela simulação que gerar mudanças nesse a cada 0,01 segundos gerava muito ruído no controlador.

Uma representação do mesmo sistema em formato de diagrama de blocos pode ser visto abaixo.

Diagrama de blocos do sistema

Pode-se notar que os dados que são realimentados no controlador /velocity_pid não é o comando de velocidade mais atual do robô, mas a média dos últimos N comandos. Utilizamos N = 100. Essa medida também é uma forma de diminuir ruídos no controlador, pois os comandos de velocidade podem variar rapidamente, porém sua média é uma informação mais estável e fácil de controlar.

Resultados da simulação

Após alguns dias ajustando os parâmetros dos controladores e aperfeiçoando o sistema, conseguimos fazer o Bbot se equilibrar e teleoperá-lo.

Teleoperação do Bbot

Testamos também a reação dele a esforços externos:

Teste de resistência do Bbot

Na quarta etapa do projeto, nós apresentamos o desenvolvimento do sistema de controle e teleoperação do Bbot. Bbot 🔧 Bbot

Para as próximas etapas, serão apresentados a impressão e montagem do robô, assim como os testes do sistema com o robô real.



Autor


Not found

Lucas Lins
Estagiário no laboratório de Robótica e Sistemas Autônomos (RoSA), SENAI CIMATEC, graduando em Engenharia Elétrica no SENAI CIMATEC.