No dia 1 de Agosto de 2021 foram feitos os primeiros testes de condução autónoma do robot com direcção ackermann.
Os resultados foram promissores. Apesar do despiste inicial, a segunda tentativa foi bem sucedida.
A pista onde foram realizados os testes foi feita com cartolina preta. e fita cola amarela fina.
Os primeiros testes foram efectuados sem a linha central. A faixa de rodagem tem 40 cm. O circuito está compreendido num espaço rectangular de 1.90M por 2.40M,
O resultado do primeiro teste pode ser observado no seguinte video.
O resultado da condução autónoma não foi propriamente bom mas foi promissor. Existiram despistes. Mas também sessões em que o robot conduziu várias voltas sem qualquer problema.
Na fase de recolha. o problema detectado foi a dificuldade de controlar o veiculo com precisão e suavidade.
O método de conversão da mensagem twist na velocidade aplicada ao motor e o angulo aplicado na direcção, extrai a velocidade linear, e computa o angulo com base na relação entre a velocidade angular, a velocidade linear e distancia entre eixos.
Este método faz com que a capacidade de virar o carro diminui com o aumento da velocidade, e que apenas a velocidades baixas se consegue virar de forma notável.
Estes teste foram realizados com o mcu ESP8266 e o usado nele subscrevia e descodificava a mensagem twist.
A mensagem twist era produzida por um joystick virtual na app ROS-Mobile.
Depois de acertar com as modificações para o mcu passar a subscrever apenas o pub_dir e pub_vel, e com o circuito ainda com a linha ao centro foram efectuadas 9 sessões de condução com recolha de dados (write). Posteriormente foi treinado o modelo rrm01.h5 com uma selecção das sessões.
Os resultados da condução autónoma foram muito desanimadores.
Retirei a fita cola que fazia de linha central e fiz mais uma serie de sessões de condução para recolha de dados,
Posteriormente com base nos dados de condução recolhidos foi treinados os modelos:
rrm02.h5 (set 12)
rrm02a.h5 (set 14)
rrm02b.h5 (set 11)
rrm02c.h5 (set 13)
A inexperiência de condução autonoma inicial com o modelo rrm02.h5, no mesmo sentido que foi efectuado o treino, também foi desanimadora.
No entanto, quando experimentei colocar o robot no sentido contrário os resultados melhoraram muito. O robot deu muitas voltas sem se despistar.
Com o modelo rrm02a.h5, o comportamento em sentido contrario foi bom, e no mesmo sentido foi ligeiramente melhor.
Os melhores resultados no mesmo sentido foram obtidos com o modelo rrm02c.h5, e não foram satisfatórios mas o desempenho no sentido contrário não foi o melhor.
A melhor situação será provavelmente a que foi obtida com o modelo rrm02a.h5.
Condições gerais dos testes
A camera estava inclinada o mais possível para baixo, a apontar para o mais perto do robot.
Quando o node rosserial estabelece ligação tcp com a o microcontrolador a correr um programa preparado para o rosserial é exibida a seguinte mensagem informativa do ip do microcontrolador.
[INFO] [1629761354.148552]: Established a socket connection from 192.168.1.136 on port 53589
Este ip pode ser usado para fazer o upload de um novo programa para o mcu por OTA.
I followed the document available on address above, to successfully install the cuda and libfreenect2 with cuda.
As is, the procedure described failed. I need to add some more steps. The steps are found after hours of trial and error.
This process install the cuda 10.1 from the ubuntu 20.04 repos. Before this procedure I tried the installation form nvidia repos, but i never had success.
Install and test nvidia cuda from ubuntu repos
apt-get install cuda-toolkit -y
After install you may check the installed cuda compiler version with
nvcc –version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2019 NVIDIA Corporation
Built on Sun_Jul_28_19:07:16_PDT_2019
Cuda compilation tools, release 10.1, V10.1.243
Then to check if the cuda is working, you need to compile the hello.cu code available in the following address:
If the serial monitor of platformio in vscode doesnt output anything, maybe its because some ESP32 boards have a mechanism that connects RTS/DTR to the EN/GPIO0 lines, and if the RTS/DTR are driven the wrong way when the serial monitor opens, it might shut down the ESP32.
We can try adding each of follow blocks to the platformio.ini and retry opening the serial monitor, until it works.
If one doesn’t make a difference, delete it and try again withthe next one.
Antes de volta a trabalhar no ficheiro urdf com o modelo do robot de lagartas, fui, mais uma vez, ver se conseguia colocar o plugin phobos para o blender de modo a passar a usar a funcionalidade de import/export de urdfs no blender e desse modo usar o blender para desennhar os modelos urdf dos robots.
Mais uma vez não tive sucesso nessa instalação.
Entretanto consegui acabar o urdf do robot com lagartas á mão e ficou com o seguinte aspecto no rviz e no gazebo:
Existe uma pequena diferença relação ao modelo definido no sdf original, o angulo dos flippers face ao solo é menor (os flippers são as extremidades que existem anexas a cada lagarta)
Passado o problema da conversão do sdf para urdf, passei ao problema do controlo do movimento do robot, que gostava que fosse efectuado com base no seguinte plugin do gazebo (e a respectiva evocação no urdf):
Mas o problema, á primeira vista é que este plugin não tem interface para topicos do ROS e aparenta ter como input o teclado via o seguinte plugin do gazebo (e a respectiva evocação no urdf):
O modelo de robot de lagartas definido no mundo acima usa o seguinte plugin especifico para robots de lagartas (tracked robot):
libSimpleTrackedVehiclePlugin.so
Primeiro passei por um processo de conversão manual do sdf para urdf, no entanto o resultado não foi satisfatório. Todos os componentes do modelo ficaram colocados no eixo dos y, e as extremidades das lagartas também não ficaram bem posicionadas.
O modelo tal como está no mundo do gazebo em sdf tem o seguinte aspecto:
O aspecto original no rviz e no gazebo do modelo após o primeiro processo manual de conversão do sdf para urdf era o seguinte:
2021-04-22
sibotdiff_description & sibotdiff_bringup
Actualizei o sibotdiff_description da seguinte forma:
Removi os models antigos (robot01 e robot02) e respectivas pastas de includes, e copiei o model robot01 do multibot_description (e respectiva pasta de includes) para a para a pasta urdf do sibotdiff_description.
Na pasta launch do sibotdiff_bringup actualizei os ficheiros spawn_* e world_* para ficarem em linha com o existente no multibot_description.
Os modelos e ficheiros relacionados do sibotdiff_description vão ficar a ser desenvolvidos no multibot_description até ficarem estáveis e serem copiados para o sibotdiff_description.
multibot_description
Passando para o desenvolvimento no multibot_description o proximo passo é passar a usar macros e fazer com que a robot seja mais estavel (eventualmente pesado)
Sobre as propriedades fisicas seguem dois links importantes
Pacote ROS para controlar base de robot móvel de propulsão diferencial com um RaspberryPi e um STM32F.
https://github.com/inaciose/rospibot6
O pacote do ROS inclui o seguinte software:
O node base que comunica por I2C com o microcontrolador STM32F
Vários nodes em Python que implementam isoladamente algumas das funções incluídas no node base.
Conjuntos de launch files e yaml com parâmetros de exemplo para a exploração da base em tarefas de navegação autónoma.
O node base depende do software para o microcontrolador STM32F.
O node base foi pensado para ser monolítico e incluir nele várias funções que podem estar dispersas por vários módulos.
twist_diff
pid controler
IMU MPU6050
odometria
interface de LCD e botões
interface MCU ROS
No entanto, apesar de todos estas funções estarem implementadas, até este momento momento as tarefas de navegação bem sucedidas fizeram uso dos node externo para a odometria e do controlo pid existente no microcontrolador,
Enumerando as funcionalidades no node base e o seu estado
O componente twist_diff que faz a conversão das velocidades expressas nas mensagens twist para as velocidades que cada um das duas rodas deve ter está a funcionar e a ser usado (se bem que foi desenhado de forma diferente da implementação do chefbot)
O pid controler tanto quanto me lembro está a funcionar, mas não está a ser usado.
O IMU está funcional e foi objeto de testes bem sucedidos com o pacote robot_pose_ekf.
A odometria, está implementada mas tanto quanto me lembro tem problemas e não está a ser usada, pois os robots estão a usar um node externo.
O interface de LCD e botões está funcional mas não está a ser usado, porque nenhum dos robots atuais tem o hardware necessário.
O interface MCU ROS está a funcionar.
O software para o microcontrolador STM32F será uma das versões disponíveis no seguinte repositório.
https://github.com/inaciose/rospibot6mcu
Sem uma averiguação mais detalhada o programa adequado deve ser um destes dois:
rospibot6_stm32d_v4
rospibot6_stm32d_v4d
A principal diferença entre estes dois programas é que o v4d faz uso de dois interrupts, um por cada canal do encoder , o que me faz apostar que este seja o programa adequado pois os pulsos por rotação que estão definidos nos parâmetros do node base são bastante elevados.