gazebo calibration package

Este é o relato da experiência de utilização do pacote calibration_gazebo que está disponível no seguinte repositório:

https://github.com/oKermorgant/calibration_gazebo

Na primeira execução reparei que este pacote depende do pacote slide_publisher. Esta dependência pode ser satisfeita com o seguinte comando

sudo apt install ros-noetic-slider-publisher

Também está disponível no seguinte repositório

https://github.com/oKermorgant/slider_publisher

O erro que denuncia a dependência é o seguinte

Resource not found: slider_publisher

O comando que faz o spawn do quadro de xadrez para a calibração da camera é o seguinte:

roslaunch calibration_gazebo landmark.launch

Este comando pressupõe que o ambiente simulado já esteja em execução, pelo que no caso do projecto do automec será necessário executar por exemplo o seguinte comando:

roslaunch simulation_bringup traxxas_free_drive.launch

No entanto na experiência efectuada o quadro de xadrez não apareceu.

Segundo a descrição do pacote o programa tentará identificar o link da camera (o primeiro a ter a palavra camera) e a fazer o spawn do quadro de xadrez á sua frente, caso não encontre o quadro aparece numa posição fixa.

O pacote contem os launch files que permite lançar dois ambientes simulados para testar o seu funcionamento.

  • roslaunch calibration_gazebo perspective.launch
  • roslaunch calibration_gazebo fisheye.launch

A execução do primeiro, seguido do comando para lançar o quadro, permitiu verificar que o quadro aparece em frente da camera.

Numa tentativa de identificar o que estava a acontecer, foi efectuada uma correcção do launch file de modo a poder observar as mensagens geradas pelo node.

No caso do do ambiente exemplo pré configurado no pacote 0 resultado na consola foi  o seguinte:

process[calibration_gazebo/landmark_bridge-2]: started with pid [404599]
False
False
Found camera link at camera::camera_link
[INFO] [1632494079.717182, 0.000000]: Loading model XML from file /home/inaciose/catkin_ws/src/calibration_gazebo/sdf/landmark.sdf
[INFO] [1632494079.735229, 0.000000]: Waiting for service /gazebo/spawn_sdf_model
[INFO] [1632494079.743581, 16.158000]: Calling service /gazebo/spawn_sdf_model
[INFO] [1632494080.021423, 16.313000]: Spawn status: SpawnModel: Successfully spawned entity

Ficando o processo de calibração disponível conforme a imagem acima

No caso do ambiente simulado do projecto do automec o quadro de xadrez nunca aparece no ecrã e surgem as seguintes mensagens de erro.

process[calibration_gazebo/landmark_bridge-2]: started with pid [415518]
False
(...)
False
Could not find camera link, spawning landmark at (0,0,0.5)
[INFO] [1632494966.819862, 0.000000]: Loading model XML from file /home/inaciose/catkin_ws/src/calibration_gazebo/sdf/landmark.sdf
[INFO] [1632494966.824028, 24.350000]: Waiting for service /gazebo/spawn_sdf_model

Como após algumas pesquisas e verificações não consegui colocar o paccote a funcionar no ambiente de simulação usado no projecto do automec, passei para outra abordagem.

A nova abordagem foi usar apenas ficheiro sdf que define o quadro de xadrez, integrando-no pacote que define o ambiente de simulação.

 

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