Categoria: ROS packages

rospibot6

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.

 

Pacote do ROS para calibrar o MPU6050

O pacote de calibração do MPU6050 está disponivel no seguinte endereço:

https://github.com/inaciose/ros_mpu6050_calibration

As instruções para instalar e usar estão no github.

Descrição do contexto que deu origem ao desenvolvimento do pacoteros_mpu6050_calibration.

Tenho estado a tentar fazer a fusão dos dados do IMU com a odometria usando o pacote robot_pose_ekf.

http://wiki.ros.org/robot_pose_ekf

O teste que efectuei não deu bons resultados, pois o resultado da fusão dos dados do IMU com a odometria, é uma pose completamente diferente daquela que é dada pela odometria e indubitavelmente de muito má qualidade.
Direi mesmo que o resultado no teste efectuado foi uma evolução da pose completamente divergente.

A represestação no rviz é feita com o visualização da: PoseWithCovariance tendo como fonte o topico: /robot_pose_ekf/odom_combined

O resultado deste teste pode ser obervado no seguinte video.

Após ter usado o programa para calibrar o mpu6050, e ter incluido na configuração do node adequado os offsets indicados nos parametros de configuração do mpu6050, efectuei outro teste e o resultado foi mais animador. Conforme se pode observar no seguinte video, a seta vermelha já não aponta para cima, nem diverge com o movimento do robot.

Outra coisa reparei foi que a visualização no topico imu/data, que antes da calibração dava uma seta enorme a apontar para a frente direita do robot e inclinada para cima, agora aparece uma seta ao principio que rapidamente desaparece.

https://github.com/inaciose/ros_mpu6050_calibration

typepyt

O pacote typepyt explora o pequeno braço robótico meArm no ROS. Tendo em consideração que eezyBotArm partilha o mesmo tipo de cadeia cinemática com o meArm decidi explorar este pacote de software disponível no seguinte endereço:

https://github.com/inaciosef/TyPEpyt

Nota: o fork explorado foi:

https://github.com/matrhint/TyPEpyt

Logo ao inicio chamou-me a atenção a forma como os ficheiros estavam dispostos no pacote. Normalmente não existem ficheiros urdf e launch na raiz.

Uma das coisas que me chamou a atenção é que o urdf que descreve o braço robótico aparenta representar melhor a cadeia cinemática que existe num robot manipulador deste tipo, do que aquela que descobri no repositório do ntbd.

No urdf do ntdb o que acontece é que quando a haste principal se desloca, a haste horizontal que se articula no seu topo mantém o seu ângulo com a haste principal (ver video abaixo) .

No entanto na descrição do meArm as duas haste relacionam-se de forma diferente (ver video abaixo)

Como se pode observar segundo este urdf, a haste horizontal tem um ângulo relativamente a haste principal que vai variando com a posição desta. Este comportamento está mais próximo do real.

A visualização do modelo no rviz é efectuada com o seguinte comando:

roslaunch typepyt urdf_visualize.launch model:='$(find typepyt)/typepyt.urdf'

 

De seguida instalei os seguintes pacotes por serem requisitos para continuar a explorar o typepyt. O primeiro dos quais está disponível para ser instalado por clonagem e compilação

https://github.com/mintar/mimic_joint_gazebo_tutorial

O segundo é uma ferramenta de teleop para trajectórias de braços e é instalado via apt

sudo apt install ros-melodic-rqt-joint-trajectory-controller

A experiência seguinte foi lançar o lançar unico launch file que está na respectiva pasta.

roslaunch typepyt gazebo.launch

O terminal exibiu um numero considerável de erros que reproduzo parcialmente abaixo e no final a simulação no gazebo não estava funcional.

[WARN] [1589846396.527857, 0.000000]: wait_for_service(/controller_manager/load_controller): failed to contact, will keep trying
(...)
[ERROR] [1589846397.308676399, 0.120000000]: No p gain specified for pid. Namespace: /gazebo_ros_control/pid_gains/hip
[ERROR] [1589846397.309328809, 0.120000000]: No p gain specified for pid. Namespace: /gazebo_ros_control/pid_gains/shoulder
[ERROR] [1589846397.309993934, 0.120000000]: No p gain specified for pid. Namespace: /gazebo_ros_control/pid_gains/elbow1
[ERROR] [1589846397.310607059, 0.120000000]: No p gain specified for pid. Namespace: /gazebo_ros_control/pid_gains/wrist

 

De seguida experimentei lançar launch file typepyt.launch disponível na raiz do pacote.

roslaunch typepyt typepyt.launch

Também lançou uma serie de erros relacionados com o ganho do parametro p do pid.

[ WARN] [1589847824.627491156, 0.129000000]: Deprecated syntax, please prepend 'hardware_interface/' to 'PositionJointInterface' within the <hardwareInterface> tag in joint 'hip'.
[ERROR] [1589847824.628310336, 0.129000000]: No p gain specified for pid. Namespace: /gazebo_ros_control/pid_gains/hip

Os problemas foram corrigidos pela inclusão do seguinte ficheiro de configuração no launch file.

<rosparam file="$(find typepyt)/config/gazebo/gazebo_controller.yaml" command="load" />
Posteriormente consegui controlar as hastes do braço com a inclusão do trajectory teleop no ficheiro launch.
 <!-- Load teleop -->
<node name="rqt_joint_trajectory_controller" pkg="rqt_joint_trajectory_controller" type="rqt_joint_trajectory_controller" />
O repositório também contem um pacote de configuração do braço para o moveit feito com o moveit_setup_assistant.

coffee-bot

O coffee bot é o nome de um pacote do ROS (coffee_bot), e também de um repositório do github que contem quer o pacote para o ROS quer o firmware para o Arduino, necessário para explorar o braço robótico eezyBotArm MK2 com o Robotic Operating System.

O repositório original está disponivel a partir do meu fork no seguinte endereço: https://github.com/inaciosef/coffee-bot.

Este conjunto de software para o braço robótico eezyBotArm MK2 permite:

  • Comandar o braço robotico com o teclado
  • Gravar os movimentos executados
  • Reproduzir os movimentos gravados de forma automática
  • Visualizar o movimento do braço no rviz (o firmware publica mensagens sensor_msgs/JointState)

Conheci este pacote por ter visto o video abaixo no youtube.

A interação entre o node ROS e o firmware do Arduino (que é feito com base no rosserial) é efectuada com base nos tópicos x, y, z e g, que correspondem aos vários servos do braço e aceitam mensagens do tipo std_msgs/UInt16. Existe também um tópico com mensagens do tipo sensor_msgs/JointState que é publicado pelo firmware e informa a posição das várias articulações do braço robótico.

Este pacote foi importante na elaboração da parte do pacote rosarm_control que diz respeito ao eezyBotArm.

 

 

3-DOF_Manipulator

O conjunto de pacotes 3-DOF_Manipulator é usado para explorar um robot planar com 3DOF.

É composto pelos seguintes pacotes do ROS

  • three_dof_planar_manipulator
  • three_dof_planar_manipulator_ikfast_arm_plugin
  • three_dof_planar_manipulator_moveit_config

Este conjunto de pacotes tem um repositório com o mesmo nome (3-DOF_Manipulator)

https://github.com/bandasaikrishna/3-DOF_Manipulator

ros_hardware_interfaces

O ros_hardware_interfaces é um conjunto de pacotes com hardware_interfaces para serem usadas com o ros control e  vários ros controllers.

Este conjunto de pacotes é elaborado no ambito da minha aprendizagem do ROS.

É composto pelos seguintes pacotes:

  • arm3dof_all_nofb (não está completamente funcional)
  • arm3dof_jpc_nofb (funcional)
  • arm3dof_jpc_nolim_nofb (funcional)
  • dcmotor_one (completo)
  • diff_drive_base1 (completo)
  • ebamk2_hardware_interface (abandonado a refazer)
  • robotpos1 (investigar o estado do pacote)

Este conjunto de pacotes tem um repositório com o mesmo nome (ros_hardware_interfaces)

gc_bridge

O gc_bridge é um conjunto de pacotes destinados a explorar os recursos do google cloud.

É composto pelos seguintes pacotes:

  • gc_dialogflow bridge
  • gc_msgs
  • gc_speech_bridge
  • gc_vision_bridge

Este conjunto de pacotes tem um repositório com o mesmo nome (gc_bridge)

eezybotarm

O pacote do ROS eezybotarm para o braço robotico eezybotarm mk1 é um projecto abandonado. O pacote foi substituido pelos seguintes pacotes:

  • ebamk1_description;
  • ebamk2_description;
  • rosarm_control;

O firmware está incluido no pacote rosarm_firmware.