O projecto inicial de fazer um robot simples e económico, capaz de executar programas de localização e navegação para o ROS, com um Raspberry Pi ou um Banana Pi, desdobrou se em vários projectos, com sucessivas experiências.
Robot chefbot
A série de projectos desenvolveu-se com base na implementação de uma versão mutilada (sem kinetic ) do chefbot.
As minhas impressões fundamentais dos resultados foram as seguintes:
- sem uma alta densidade de pontos (depth câmera ou um lidar) é difícil aceder ao conjunto de pacotes de navegação do ROS;
- não consegui por o MPU6050 (GY-521) com DMP a funcionar de forma continuada e estável;
- o movimento do robot controlado por teleop era desajeitado, com solavancos, provavelmente porquê não configurei bem o pid, já que o sistema de controlo da locomoção do chefbot é diferente do que estava habituado. Ver mais em: motores e encoders no chefbot;
- a percentagem de ocupação da CPU do pi era muito elevada
Para além da observação dos resultados práticos do projecto, existiu uma aprendizagem sobre o funcionamento básico do ROS, nomeadamente, sobre: nodes, tópicos, tipos de mensagens, launch files, modelos de robots (urdf files), transformações (tf) e a comunicação serial com microcontroladores.
O conhecimento adquirido resultou não só da leitura do livro do lentin, e a implementação parcial do chefbot, mas também da leitura dos tutoriais do ROS.
As primeiras tentativas de estabelecer uma plataforma base para um robot de propulsão diferencial foram modeladas com o conhecimento adquirido com a implementação rudimentar e parcial do chefbot.
Robot rospibot1
O primeiro projecto foi orientado para experimentar um modelo diferente de controlo de locomoção mais eficiente em termos de carga na CPU do pi, e que resultasse num movimento mais suave.
O robot foi construído com:
- Banana Pi M1
- Arduino Mega 2560
- MPU6050 (GY-271)
- Logic Level Converter
Na implementação deste robot, face ao leque de possibilidades decidi usar a biblioteca rosserial como protocolo de comunicação, por me parecer ser a biblioteca padrão para as comunicações serial no ROS.
Os resultados da implementação do projecto foram animadores. Para além de atingir os objectivos resultou em conhecimento adquirido do qual destaco:
- no ROS não existe garantia da entrega das mensagens publicaras nos tópicos;
- o mecanismo de sincronia no rosserial é muito sensível; não pode existir atrasos nas respostas do microcontrolador ao cpu (nh.spin());
Neste robot também não consegui um uso contínuo e estável do mpu6050.
Apesar de neste projecto o robot apenas evitar obstáculos, desenvolvi o software necessário ao uso do arduino no ROS em tarefas fundamentais na locomoção e leitura de sensores.
Robot rospibot2
No segundo projecto, tentei desenvolver um robot que:
- não tivesse microcontrolador só o pi (raspberry pi3)
- fizesse uso de um LIDAR rudimentar (VL53L0x + SG90)
O uso Raspberry Pi para substituir tarefas do microcontrolador é possível, mas problemático para algumas tarefas. As problemáticas não se compadecem com atrasos no processamento, como por exemplo na leitura de
Para comunicar com os sensores e actuadores via GPIO fiz uso do wiringPi.
A escolha do wiringPi talvez não tenha sido a mais adequada, mas foi a única biblioteca que consegui a por a funcionar sem sudo e sem nenhum hack.
O lidar feito com um servo e um sensor de distância laser VL53L0X, foi pensado para poder aceder ao stack de navegação do ROS.
Apesar da baixa frequência de actualização e densidade de pontos o lidar permitiu a construção de mensagens do tipo laserscan, que são correctamente visualizaras no rviz.
Quando usados em separado, o controlo dos motores (encoders) e o lidar, ambos funcionam bem. Quando usados em conjunto, existe um problema de interferência do VL53L0X na contagem dos encoders.
Devido ao problema no uso do lidar, não dediquei qualquer atenção ao MPU6050.
Como entretanto recebi um LIDAR neato xv11 que comprei em segunda mão no ebay, o desenvolvimento deste projecto foi suspenso.
Se voltar a retomar o projecto vou tentar usar um microcontrolador para fazer o controlo dos motores e encoders, ficando o pi apenas responsável pelo lidar.
Robot rospibot3
O terceiro projecto consiste na construção de um robot com recursos ao ros_controllers.
Este projecto foi suspenso na sua fase inicial. Ainda iniciei a programação do node, mas ficou inacabado.
Robot rospibot4
No quarto projecto, tentei desenvolver um robot com o seguintes componentes:
- Banana Pi M1
- Microcontrolador (arduino) para a gestão dos motores e encoders
- MPU5060 (GY-271)
- Logic Level Converter
- LIDAR Neato xv11
Neste robot a comunicação entre o Pi e o Arduino é efectuada via bus I2C.
Este projecto foi suspenso após imensas horas a tentar estabilizar o funcionamento das comunicações i2c sem sucesso.
O problema principal é a estabilidade do MPU6050 que bloqueia e impede o funcionamento do bus I2C quando os motores são activados.
Robot rospibot5
No quinto projecto procura resolver o problema do rospibot4. Um MPU6050 que funcione sem parar. A ideia a testar é usar um microcontrolador com lógica de 3.3V. Acabei por usar o e STM32F (bluepill), mas existiam mais candidatos. Por exemplo: arduino 3.3V, ESP8266, ESP32, etc.
Este robot tem os seguintes componentes:
- Raspberry Pi 2
- Microcontrolador (stm32f) para a gestão dos motores encoders, e LIDAR
- MPU5060 (GY-271)
- LIDAR rudimentar (VL53L0x + SG90)
O microcontrolador, para além do controlo dos motores e leitura dos encoders também opera o lidar. As comunicações entre o microcontrolador e o pi são efectuadas via serial e não é usado o rosserial, mas sim um protocolo simples para comunicar dados entre o microcontrolador e o node que se encarrega de publicar e subscrever mensagens nos tópicos correspondentes aos encoders e o pwm a aplicar nos motores.
Todas as mensagens são constituídas por:
- header 4 bytes: 13,13,0,cmd
- payload n bytes
- tail 4 bytes: 0,0,0,10
Para o microcontrolador existem 3 comandos (cmd)
1 – reset encoders
2 – pwm (left, right) 4 bytes para cada variável.
3 – lidar on
4 – lidar off
Para o computador existem 2 comandos (cmd)
1 – encoders data
2 – lidar data
O node responsável pela leitura do IMU (MPU6050) foi escolhido entre os nodes existentes na web e tem dmp.
Robot rospibot6
O robot deste projecto é o primeiro a ter um lidar com uma resolução e frequência aceitável. Um neato xv11.
Relativamente ao projecto anterior as alterações de relevo foram:
- o lidar rudimentar substituído pelo xv11
- a comunicação entre o microcontrolador e computador passou a ser efectuada por i2c
A alteração do canal de comunicação implicou escrever um node que comunique com o microcontrolador para controlar os motores e ao mesmo tempo também efectue a leitura e publicação dos dados do imu.
Neste projecto o programa a correr no microcontrolador e o pacote ros passaram por diversas fases.
programa para o stm32.
na primeira fase limitava-se as seguintes funções:
l