Um problema de orientação

O problema com o pick and place com o moveit, e da execução do posicionamento do end effector conforme o tutorial do moveit foi no minimo mitigado, quando não resolvido.

Quando descobri o uArm (swift e pro), mais um braço do tipo do eezybotarm, e o software que estes braços têm para o ros moveit disponivel no github, e verifiquei que com este software o moveit conseguia efectuar o planeamento. Após rápida reflexão a razão do sucesso parecia evidente. O urdf destes braços não incluia em nenhuma joint mimic.

A descrição que efectuei do ebamk2 incluia duas mimic joints. Uma entre o link_2 e um link virtual que acrescentei entre este e o link_3, para descrever a relação que existe entre o movimento destes links, pois não são complementamente independentes. Outra entre o link_3 e o link_4, que é o link final onde se connecta o end effector. Estes dois links relacionam-se atravez de duas articulações, a que estabelecem entre si, e a que o link 4 estabelece com uma articulação passiva no corpo do braço, cujo objectivo é manter o end effector sempre horizontal.

Portanto, rescrevi o urdf do eezybotarm mk2 de duas formas, uma sem nenhuma joint mimic, e outra em que conservei a joint mimic e o link virtual entre o link_2 e o link_3, e quando experimentei acabei por ter sucesso no passo em que estava encalhado no tutorial do moveit (mover o braço robótico para um pose).

Ou seja, a orientação do end effector na versão com o mimic entre a joint_3 e joint_4 era impossivel de atingir, pois era incompativel com o quaternion (x,y,z,w) com os valores (0,0,0,1).

eezybotarm mk2 pick and place problem

The eezybotarm mk2 pick and place problem is about the lack of DOF

As minhas experiências falhadas com o pick and place no eezybotarm mk2 derivaram da incapacidade de fazer o planner do moveit fazer a cinemática inversa do braço robótico, pois o braço tem apenas 3DOF e parece que é necessário 6DOF.

Ainda não digeri completamente esta incapacidade, pois no rviz com o Allow Aproximate IK Solutions activo, é possivel movimentar e calcular a trajectória para a pose, mas no script de pick and place é impossivel, mesmo que a posse seja muito aproximada a pose actual e portanto possivel.

Procurei encontrar uma forma de activar o Allow Aproximate IK Solutions no programa de pick and place em python e fui conduzido para o seguinte método, mas sem sucesso.

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

Também descobri dois novos ik solvers:

  • track_ik – http://wiki.ros.org/trac_ik
  • bio_ik – https://github.com/TAMS-Group/bio_ik

Dos dois apenas experimentei e passei a usar o bio_ik, que foi facil de instalar.

É muito provavel que desista de explorar o eezybotarm mk2 no ros moveit, pelo menos temporariamente, e tentar fazer um braço com os 6DOF para voltar a este assunto do pick and place.

Ros moveit GripperCommand

Mais um problema resolvido. Como descobri que não tenho nenhuma interface visual para interagir com o gripper no moveit rviz, não está completamente conforme com a minha ideia inicial. Mas é o melhor que consegui descobrir por enquanto.

Mais tarde acho que irei dedicar um bocado de atenção ao moveit_grasps, mas por enquanto o proximo passo é descobrir como funciona o pick and place.

The quest for a robot with moveit follow joint trajectory

Após conseguir fazer a cinemática inversa para o eezybotarm mk2 no moveit, e conduzir o robot em espelho com a apresentação do rviz, por subscrição do fake_controller_joint_states, quando se corre o demo.launch, andei em busca da integração com o moveit! com base nas mensagens follow joint trajectory.

Na minha humilde perspectiva, de quem não teve qualquer formação de relevo para o assunto, devo dizer que provavelmente para quem não sabe, há assuntos que parece muito difícil encontrar informação sobre o eles.

O controlo de movimentos de um braço robótico físico com o ros moveit parece uma delas. O que eu diria é que não existe nenhum exemplo para a exploração de um braço físico de baixo custo com o moveit!

Existe informação, ambiguidades, questões sobre a implementação que por vezes não sabemos como colocar, e portanto até pesquisar, e algumas questões respondidas. Regra geral a solução está numa dessas respostas. Até mesmo quando por vezes temos alguma ideia conceptual de como a coisa funciona, ficamos imenso tempo a procura de alguns detalhes que são fundamentais.

Entretanto parece que consegui encontrar todos os pequenos detalhes para colocar a funcionar a integração do braço eezybotarm mk2 com o ros moveit, sem recorrer a soluções menos apropriadas como as que tinha ensaiado anteriormente. Ainda assim acho que não estou a usar ainda um hardware interface ao estilo do ros control.

eezybotarm mk2 no ros moveit

Tenho andado de volta do controlo do braço robótico eezybotarm mk2 com o ros moveit, e até agora não tinha tido muito sucesso em controlar a rotação do braço sobre o eixo z (posição no eixo y). Apenas conseguia posicionar a ponta do braço robótico mais perto ou mais longe da base (posição no eixo x) ou mais alto ou mais baixo face á superfície (posição no eixo x).

Finalmente consegui. A diferença fundamental foi a escolha do LMA kinematics plugin como kinematic solver, para o arm planing group durante a configuração do braço efectuada no Moveit Setup Assistant.

ROS Moveit não gosta de mimic joints

Depois de ter tido o trabalho de rescrever dois dos urdf do eezybotarm mk2 para incluir mimic joints de forma a melhor reproduzir os movimentos do braço descobri que o ROS moveit não faz o planeamento de trajectorias de robots com cadeias cinemáticas que contenham mimic joints.

Actualização: ainda ontem apercebi-me que apesar de o launch file demo.launch exibir o seguinte erro na consola:

[ERROR] [1590019577.283880216]: Group ‘Arm’ has a mimic joint. Will not initialize dynamics solver

O moveit consegue fazer o planeamento de robots com mimic joints na cadeia cinemática

Exploração do projecto typepyt para o meArm

Ontem estive a explorar o pacote typepyt para o meArm disponivel num repositório do github com o mesmo nome.

Nessa exploração conheci um ficheiro urdf que procura descrever a cinemática do meArm com recurso à tag mimic. Esta tag é aplicada a uma articulação virtual existente entre a haste principal e a haste horizontal, e permite assim efectuar uma melhor descrição do movimento do braço robótico.

Como a cinemática do meArm é semelhante à do eezyBotArm vou melhorar a descrição que tenho do eezyBotArm MK2, no pacote ebamk2_description.

Hardware Interface para diff_drive_controller

Adicionei uma versão mais simples de um Hardware Interface para diff_drive_controller.

O diff_drive_base2 está disponivel no seguinte repositório do github: https://github.com/inaciose/ros_hardware_interfaces

Também existem repositórios para os firmware correspondentes aos diversos nodes de hardware interface disponiveis no repositório acima.

Existem os seguintes repositórios:

https://github.com/inaciose/rosmotor_firmware

https://github.com/inaciose/rosarm_firmware

https://github.com/inaciose/rosstepper_firmware

É provavel que no futuro estes repositórios sejam revistos.

Excluído do Mestrado de Automação Industrial

Apesar de no edital indicar que o Mestrado de Automação Industrial na Universidade de Aveiro era destinado a licenciados em engenharia electrónica, mecânica e afins, decidi candidatar-me. Quanto muito perdia os 20 euros. Pois bem. Os resultados saíram e não fui colocado.

Nova placa controladora para o braço robótico RAMK2P

Hoje estive a fazer as ligações e a testar a nova placa para o braço robótico RAMK2P. Usei uma placa perfurada de lado duplo e como não estou habituada a elas acho que fiz um mau trabalho. Tive que ir duas vezes ao ferro de soldar corrigir problemas. No final o braço robótico ficou a trabalhar conforme estava anteriormente.

Vista superior do braço robótico RAMK2P com a placa controladora
Vista superior do braço robótico RAMK2P com a placa controladora

A placa está ainda incompleta pois não tem a ligação para o servo motor da garra nem a sua alimentação independente. Só estou a prever completar a placa mais tarde. Antes de a completar estou a pensar dedicar um tempo a desenvolver o software para usar este braço com o ROS, entre o qual um node com o hardware interface usável com o ros control.