Preparar um sdcard com o rospibot6

webid#sdcard0703

Download da imagem em:

https://downloads.ubiquityrobotics.com/pi.html

Gravar num sdcard

Fazer o login (password: ubuntu), ssh ubuntu@10.42.0.1

Trocar a password

locale-gen pt_PT.UTF-8

locale-gen en_US.UTF-8

sudo apt update (optional: sudo apt upgrade)

sudo systemctl disable magni-base (o serviço roscore continua a funcionar)

trocar o hostname, https://www.cyberciti.biz/faq/ubuntu-change-hostname-command/

pifi add sid password

reboot

Bibliotecas Instaladas

INSTALL I2Cdevlib:

sudo mkdir -p /usr/share/arduino/libraries cd /usr/share/arduino/libraries
sudo git clone https://github.com/chrisspen/i2cdevlib.git

 

INSTALL Bcm2835:

cd /tmp
wget http://www.airspayce.com/mikem/bcm2835/bcm2835-1.50.tar.gz 
tar zxvf bcm2835-1.50.tar.gz 
cd bcm2835-1.50 
./configure 
make 
sudo make check 
sudo make install

 

Pacotes ros instalados

sudo apt-get install ros-kinetic-xv-11-laser-driver

sudo apt-get install ros-kinetic-gmapping

sudo apt-get install ros-kinetic-amcl

sudo apt-get install ros-kinetic-dwa-local-planner

sudo apt install ros-kinetic-robot-pose-ekf

 

Instalar o pacote do rospibot6

catkin_make (compilar)

 

sudo bash -c “source /opt/ros/kinetic/setup.bash; source /home/ubuntu/catkin_ws/devel/setup.bash; roslaunch rospibot6 robot6.launch”

rostopic pub –once cmd std_msgs/Int16 “data: 3”

roslaunch rospibot6 teleop.launch

 

Nema 17 planetary gearbox diy list

Nema 17 Stepper 5:1 Planetary Reducer

Robot Actuators by LoboCNC

 

Compact planetary gearbox

https://www.thingiverse.com/thing:2114390

https://www.thingiverse.com/thing:2436716

4:1

 

NEMA 17 Precision Gearbox with Position Feedback

https://www.thingiverse.com/thing:4440480

6:1

NEMA 17 Robot Actuator by mattiasZ

https://www.thingiverse.com/thing:4428749

 

Modular planetary gearbox 1024:1

https://www.thingiverse.com/thing:2586962

Nema 17 Stepper 5:1 Planetary Reducer

O Nema 17 Stepper 5:1 Planetary Reducer tem as instruções e stls disponíveis no seguinte endereço.

https://www.thingiverse.com/thing:8460

Rolamentos

6 x 683ZZ 3x7x3mm

1 x 606-2RS 6x17x6mm

1 parafuso M6 como veio de saída

Tem algumas remixes, incluindo uma para um veio de saida com 5mm.

Dificuldades no posicionamento do end effector link on eezybotarm

Recentemente passei à fase do pick and place no eezybot arm2, mas pelos vistos vou encalhar nesta fase.

O problema que encontrei é a dificuldade no posicionamento do end effector link on eezybotarm mk2 quando a mesma é efectuada por um script em python.

Não consegui efectuar um único movimento baseado na indicação da pose de destino com a interface do moveit move group em python. O que me deixa desconcertado face ao sucesso em resolver a cinemática inversa e planear trajectorias usando o rviz. Especialmente quando se usa Allow Aproximate IK Solutions activo.

A mensagem habitual é a seguinte:

[ INFO] [1590451846.572774885]: ABORTED: No motion plan found. No execution attempted.

Tentei várias soluções sem qualquer sucesso. Primeiro tentei alterar a tolerancia relativamente ao objectivo com o uso dos seguintes métodos:

move_group.set_goal_tolerance(0.1)
move_group.set_goal_position_tolerance(0.01)
move_group.set_goal_orientation_tolerance(0.1)

Nestas experiências o que consegui foi explicitar uma tolerancia tão grande que a decisão era nao se mexer porque já estava no sitio.

Como não tive sucesso, numa segunda fase tentei usar outro IK solver. Encontrei boas referencias relativamente ao bio_ik disponivel no seguinte endereço, mas também não tive sucesso.

  • https://github.com/TAMS-Group/bio_ik

Nota: O bio_ik solver á semelhança do LMAK também permite a especificação da rotação sobre o eixo z (joint_1) no eezybotarm mk2.

Por último descobri indicações que o seguinte método tinha o mesmo efeito que o Allow Aproximate IK Solutions, activo.

move_group.set_joint_value_target(pose_goal, "eef_link", True)

Mais uma vez não tive qualquer sucesso ao efectuar o posicionamento do braço no script de python.

Neste caso acresce a seguinte mensagem de aviso

[ WARN] [1590451841.449395412]: Returning dirty link transforms

Links

https://answers.ros.org/question/329107/moveit-approximate-ik-solutions/

 

Alterações ao pacote ebamk2_moveit_config

Daquilo que aprendi, das descrições e exemplos que encontrei na web sobre a exploração de um braço robótico real, e de baixo custo, com o ros moveit! é que existem quatro ficheiros importantes, que tem de ser criados ou alterados no pacote que resulta da execução do moveit_setup_assistent.

Este é um exemplo das alterações aplicadas ao pacote ebamk2_moveit_config. Pacote de configuração do moveit para braço robotico eezybotarm mk2.

Algumas notas sobre o hardware real. Os actuadores em cada articulação são servo motores, sem qualquer feedback.

Existem 4 joints, correspondentes a 4 servo motores. Incluindo o da pinça.

Provavelmente deveria estar apenas a enumerar 3, decidi colocar o joint6 que é o da articulação da pinça (o que abre e fecha a pinça). Irei saber depois. Quando abordar o controlo da pinça com o moveit.

Cada um dos motores é referido como um joint_n, pelo que os termos joint_1, joint_2, joint_3, e joint_6, referem os motores. Os nomes usados são importantes e devem ser os nomes das joints existentes no ficheiro urdf usado como base para o pacote de configuração do moveit para o eezybotarm mk2

controllers.yaml

O primeiro passo é criar o ficheiro (ebamk2_moveit_config/config/controllers.yaml) com o seguinte conteúdo:

controller_manager_ns: /
controller_list:
  - name: arm_controller
    action_ns: follow_joint_trajectory
    type: FollowJointTrajectory
    joints: [joint_1, joint_2, joint_3, joint_6]

Este ficheiro vai origem ao tópicos

/arm_controller/follow_joint_trajectory/cancel
/arm_controller/follow_joint_trajectory/feedback
/arm_controller/follow_joint_trajectory/goal
/arm_controller/follow_joint_trajectory/result
/arm_controller/follow_joint_trajectory/status

joint_names.yaml

O segundo passo é criar o ficheiro (ebamk2_moveit_config/config/joint_names.yaml) com o seguinte conteúdo:

controller_joint_names: [joint_1, joint_2, joint_3, joint_6]

ebamk2_moveit_controller_manager.launch.xml

O terceiro passo é substituir ros_controllers.yaml por controllers.yaml no ficheiro abaixo.

(ebamk2_moveit_config/launch/ebamk2_moveit_controller_manager.launch.xml)

O conteúdo será o seguinte:

<launch>

<!-- loads moveit_controller_manager on the parameter server which is taken as argument 
if no argument is passed, moveit_simple_controller_manager will be set -->
<arg name="moveit_controller_manager" default="moveit_simple_controller_manager/MoveItSimpleControllerManager" />
<param name="moveit_controller_manager" value="$(arg moveit_controller_manager)"/>

<!-- loads ros_controllers to the param server -->
<rosparam file="$(find ebamk2_moveit_config)/config/controllers.yaml"/>
</launch>

robot_planning_execution.launch

O ultimo passo é criar o ficheiro: (ebamk2_moveit_config/launch/robot_planning_execution.launch)

Este launch file é o usado para iniciar os nodes necessários para o braço robótico  executar os movimentos planeados no ros moveit.

<!-- connect to micro controller -->
<arg name="baud" default="57600"/>
<arg name="port" default="/dev/ttyUSB0"/>

<node pkg="rosserial_python" type="serial_node.py" name="init_serial_node">
<param name="baud" value="$(arg baud)"/>
<param name="port" value="$(arg port)"/>
</node>

<!-- load the joint names configuration file manualy created -->
<rosparam command="load" file="$(find ebamk2_moveit_config)/config/joint_names.yaml"/>

<!-- load the robot_description parameter before launching ROS-I nodes -->
<include file="$(find ebamk2_moveit_config)/launch/planning_context.launch" >
<arg name="load_robot_description" value="true" />
</include>

<!-- run the actionlib moveit messages to robot hardware interface node -->
<node pkg="rosarm_control" type="eba_arm_control.py" name="arm_controller" output="screen"/>

<!-- publish the robot state (tf transforms) -->
<node name="robot_state_publisher" pkg="robot_state_publisher" type="robot_state_publisher" />

<!-- include automatic generated launch files -->
<include file="$(find ebamk2_moveit_config)/launch/move_group.launch">
<arg name="publish_monitored_planning_scene" value="true" />
</include>

<include file="$(find ebamk2_moveit_config)/launch/moveit_rviz.launch">
<arg name="rviz_config" value="true"/>
</include>

</launch>

Partes relevantes deste artigo provêm das instruções descritas no documento no seguinte endereço:

https://industrial-training-master.readthedocs.io/en/melodic/_source/session3/Build-a-Moveit!-Package.html

 

diff_drive_controller

O pacote diff_drive_controller faz parte dos ros_controllers e aplica-se ao controlo a uma base de robot com propulsão diferencial.

O diff_drive_controller necessita de um node que implemente a interface com o hardware de acordo com o estabelecido para o ros control. Ou seja um programa baseado numa classe que herde a hardware_interface::RobotHW, e implemente os métodos que façam a ligação com o controller_manager, o diff_drive_controller e o hardware, via firmware.

O controlo é efectuado por comandos de velocidade, ou seja mensagens do tipo geometry_msgs/Twist). Destas mensagens o controlador extrai o componente x da velocidade linear e o componente z da velocidade angular (os outros componentes são ignorados), que utiliza para calcular a velocidade de cada uma das rodas. Estas velociades são então enviadas através do node com o hardware interface para cada uma das duas rodas existentes num robot 2WD. A odometria é calculada e publicada pelo controlador com base no feedback que provem do hardware através do mesmo interface.

O diff_drive_controller necessita de um conjunto de configurações que devem obedecer a critérios especificos e estarem adequadas ao hardware.

O ficheiro robot.urdf que descreve o robot deve conter as articulações (joints), neste caso das rodas, com os nomes adequados, ou em consonancia com os nomes usados no programa e no ficheiro de configuração (controllers.yaml).

Exemplo de joints relevantes num robot.urdf
<joint name="front_right_wheel_joint" type="continuous">
(...)
</joint>

<joint name="front_left_wheel_joint" type="continuous">
(..)
</joint>

O ficheiro controllers.yaml que contém a configuração dos controllers, entre os quais a do diff_drive_controller, tendo cada um deles os seus parametros de configuração. No minimo tem de conter a identificação do controller com o respectivo tipo e as articulações (joints) neste caso as rodas com o mesmo nome que está no urdf e no programa.

O conteúdo minimo para o diff_drive_controller  no controllers.yaml é o seguinte:

robot_velocity_controller:
    type: "diff_drive_controller/DiffDriveController"
    left_wheel: 'front_left_wheel_joint'
    right_wheel: 'front_right_wheel_joint'
    pose_covariance_diagonal: [0.001, 0.001, 1000000.0, 1000000.0, 1000000.0, 1000.0]
    twist_covariance_diagonal: [0.001, 0.001, 1000000.0, 1000000.0, 1000000.0, 1000.0]

Note que o nome indicado para o left_wheel e right_wheel é o mesmo que o indicado no urdf.

Outra coisa importante é que a indentação é importante para a atribuição dos parâmetros ao controlador respectivo.

A descrição do robot incluida no ficheiro robot.urdf e a configuração dos controllers no ficheiro controllers.yaml são carregadas no servidor de paramentros rod ROS (parameter server) por intermédio de um launch file com os seguintes elementos:

<param name="robot_description" command="$(find xacro)/xacro '$(find diff_drive_base1)/urdf/robot.urdf.xacro'
--inorder"/>
<rosparam command="load" file="$(find diff_drive_base1)/config/controllers.yaml"/>

No que se refere a forma como os ros controllers são executados ter em atenção que eles são executados indirectamente por referência aos parametros carregados pelo ficheiro yaml, como por exemplo no caso abaixo em que o diff_drive_controller é carregado pela evocação do robot_velocity_controller.

<node name="base_controller_spawner" pkg="controller_manager" type="spawner"
args="robot_joint_publisher robot_velocity_controller"/>

Apesar de não esta referido aqui, o robot_joint_publisher refere-se ao  joint_state_controller, que é também um ros controller e na mesma por referência á sua inclusão no ficheiro de configuração controllers.yaml.

A identificação usada no controllers.yaml para o diff_drive_controller é usada também no nome dos topicos que são publicados e subscritos pelo node que usa o controller conforme exemplo abaixo:

/robot_velocity_controller/cmd_vel
/robot_velocity_controller/odom
/robot_velocity_controller/parameter_descriptions
/robot_velocity_controller/parameter_updates

 

Fontes

http://wiki.ros.org/diff_drive_controller

ntbd_base

O ntbd_base é um conjunto de pacotes com uma interface genérica para exploração de braços robóticos.

É composto pelos seguintes pacotes:

  • ntbd_core
  • ntbd_msgs

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

Install openrave ubuntu 18.04 bionic

Required instalation to use IK-Fast on ROS moveit

Install OpenRAVE  from source on Ubuntu 18.04 bionic No official PPA.

sudo apt install git
sudo apt install libboost-filesystem-dev libboost-system-dev libboost-python-dev libboost-thread-dev libboost-iostreams-dev libboost-numpy-dev
sudo apt install libqt4-dev qt4-dev-tools libxml2-dev libode-dev
sudo apt install libsoqt4-dev libcoin80-dev
sudo apt install rapidjson-dev liblapack-dev

# For openravepy. Note that Xenial sympy is 0.7.6, see next line
sudo apt install python-scipy

# OpenRAVE ikfast needs sympy 0.7.1, https://github.com/rdiankov/openrave/p ull/407
pip install --upgrade --user sympy==0.7.1

# Open .zae files, only Ubuntu 16.04
sudo apt install libcollada-dom2.4-dp-dev

cd # go home

mkdir -p repos; cd repos # create $HOME/repos if it doesn't exist; then, enter it 
git clone --branch boost-1.6x-forcompile https://github.com/roboticslab-uc3m/openrave.git # git clone --branch master https://github.com/rdiankov/openrave.git 
cd openrave; mkdir build; cd build 
cmake .. -DOPT_VIDEORECORDING=OFF # Avoids AV errors 
make -j$(nproc) 

sudo make install; cd # install and go home

Note that you may end up requiring over 2 GB of free space during the installation of apt dependencies. To avoid that, use the –noinstall-recommends option as in:

sudo apt install –no-install-recommends package

Thus, apt would not try to install non-critical packages marked as recommended by the dependencies of OpenRAVE.

Known Issues (Ubuntu 18.04) In case you run into non-constant-expression cannot be narrowed from type ‘double’ to ‘float’ in initializer list [- Wc++11-narrowing] errors (happened on OpenRAVE 0.15 and a Clang 6.0.0/7.0.0 compiler), reconfigure CMake with the following option: cmake .. -DOPT_IKFAST_FLOAT32=OFF Install Openrave 4

 

Source of instructions

http://robots.uc3m.es/gitbook-installation-guides/installation-guides.pdf