Regresso aos braços robóticos

O problema encontrado nas experiências de pick & place com o braço robótico eezyBotArm mk2 (ebamk2), associado à falta de motivação para encontrar uma alternativa a esse braço, a que se juntou ainda o tempo ocupado a estudar matemática, coincidiu com o abandono dos meus projectos na área da robótica.

Além do ebamk2, também fiz uma versão nele baseada mas com motores de passo em vez de servo motores, o RobotArm mk2 plus (ramk2p), que nunca explorei tanto quanto o anterior.

Quer um braço quer outro, são de 3dof, e com o desaire das experiências pick & place com o ebamk2, deixei de lado a exploração do ramk2p.

Comecei então a germinar a ideia de fazer um braço robótico de 6dof e a direcção inicial foi começar por usar de novo servo motores. Mas desisti em grande medida pela observação de alguns vídeos de projectos deste tipo nos quais os braços exibiam um comportamento instável e que se afastam da precisão que queria.


Roboticarm V1

O braço robótico no video acima, tem apenas 5 DOF e como ainda imprimi a maior parte das peças também verifiquei que algumas das peças não permitem um bom funcionamento sem modificações. Face a mais este desaire (em particular a falta de estabilidade) passei para outra ideia.

Nesta fase a minha ideia passou a ser um braço robótico de 6DOF impresso em 3D e baseado em motores de passo, cujo projecto estivesse disponível na web, fosse relativamente preciso. fácil de fazer, e económico.

Ao longo do tempo elaborei uma lista de braços robóticos que é possível montar com recurso a peças de feitas em impressora 3D e outros componentes que tem de ser necessariamente comprados. Por exemplo rolamentos e motores. Mas essa lista revela que os meus critérios não são satisfeitos por nenhum dos projectos. Todos os que tem um bom grau de precisão são complicados e caros.

Por outro lado também reparei que não existe nenhum braço robótico baseado em motores de passo fácil de construir e que não custe umas centenas de euros.

Provavelmente o braço robótico que se pode construir num projecto caseiro que mais se aproxima da simplicidade e custo relativamente reduzido (menos de 350 euro) é o thor.

A informação mais actualizada do projecto do braço robótico thor está disponível no seguinte endereço:

https://github.com/AngelLM/Thor

Para além do repositório no github o thor tem também informação disponível no thingiverse e no hackaday.

Ainda assim, sendo simples, este braço tem na sua lista de materiais uma serie de componentes que não tenho disponíveis, alguns deles caros, como os motores de passo com caixas redutoras.

Também considerei desenhar um braço robótico por mim próprio, e cheguei a comprar algumas correias e rolamentos para os usar num projecto desses.

Neste momento, diria que cheguei a um impasse. Se bem que queira desenhar, eu próprio, um braço robótico simples e económico, creio que me faltam algumas competências para o fazer.

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.