Depois de conseguir por a funcionar soluções menos apropriadas para movimentar o eezybotarm mk2 no ros moveit!, como, por exemplo, conduzir o robot em espelho com a apresentação do rviz, por subscrição do tópico fake_controller_joint_states, quando se corre o demo.launch, consegui implementar uma forma mais adequada de exploração do eezybotarm mk2 com o moveit!. com base nas mensagens follow joint trajectory.
Passo 1 – Criar ou adaptar de alguma fonte o firmware para o microcontrolador que é o responsavel directo pelos actuadores. Neste caso do eezybotarm mk2 os servo motores.
Passo 2 – Criar ou adaptar de alguma fonte o node ros com o actionlib server que recebe as mensagens joint_trajectory_action, processa as e publica ao longo do tempo a sequência dos ângulos a aplicar a cada actuador em cada passo.
Passo 3 – Criar a descrição do braço robotico num ficheiro com o formato urdf.
Passo 4 – Criar o pacote de configuração do braço robótico para o moveit! com o moveit_setup_assistant.
Passo 5 – Alterar o pacote de configuração do braço robótico para o moveit! pois é necessário criar e alterar ficheiros de configuração (yaml) e de lançamento (launch). Ver alterações ao moveit config de um braço para ligação eficaz ao nosso hardware.
Passo 6 – executar o comando de lançamento de nodes:
roslaunch ebamk2_moveit_config ebamk2_planning_execution.launch
Deverá aparecer o rviz com a representação do braço e o interface de controlo que permite a selecção da nova posição do braço robotico.
Para aceder ao controlo sobre o braço é necessário ter o Display: MotionPlaning. Para adicionar, caso necessário, clicar no botão Add na área de Displays e seleciona-lo.
Nesta solução não se usa um hardware interface em conformidade com as especificações e interface do ros control. O termo controllers que é usado nas vaŕias informações disponiveis sobre o assunto deixa-me um bocado confundido, até por que encontrei informação nesse sentido (ver link abaixo). Mas tanto quanto percebi, o controller não necessita de ter uma hardware interface que siga o padrão do ros control.
https://answers.ros.org/question/331384/building-a-custom-hardware-interface-for-moveit/
O que indicamos como controller determina o namespace de um conjunto de tópicos, com os nomes tipicos dos actionlib servers e com tipos de mensagens apropriados, como por exemplo, no caso das indicações da trajectoria do braço, o control_msgs/FollowJointTrajectoryActionGoal.
O nosso node, e que é indicado como controller, tem de ter um action server que cuide do processamento dessas mensagens, enviando os dados necessários para o controlo de posição dos diversos servo motores a partir das informaçoes de posição (e …velocidade e esforço), existentes nas mensagens recebidas.
Nesta minha primeira implementação do node com um action server para mensagens da familia FollowJointTrajectory adoptei o script meArm.py em python que descobri no pacote typetyp.
Sobre este node em c++ ver o seguinte link.
https://answers.ros.org/question/192739/implement-moveit-on-real-robot/
Outra nota importante é que não existe qualquer feedback do hardware, pelo que a posição das articulações que compõem as joint_states publicadas são todas meras copias das posições desejadas. Para podermos ter publicadas as posições reais, teremos, caso do ebamk2, de usar servos com feedback e escrever o codigo adequado para usar esse feedback no nosso node.
O proximo passo é o controlo da pinça, já que este tipo de mensagens apenas trata do posicionamento do end effector, e não diz nada sobre como este se comporta.