open_manipulator
open_manipulator copied to clipboard
ROBOTIS-GIT
Proper 4DoF kinematics solver for MoveIt
The issue is connected to the previously closed 138.
As I can see on your Facebook page (https://www.facebook.com/robotis.company/videos/2198266990449746/), you have a working plugin for MoveIt. Could you please share your plugin with the community?
I created an IKFast plugin based on @nxdefiant's great work: https://github.com/dudasdavid/open_manipulator_ikfast_plugin
But I still have some difficulties with the gripper joint, see my video: https://youtu.be/zHTLPNMEGCs
It's a pain in the back to generate such a plugin with an - let's say - obsolete and under-documented toolchain, and I still have no clue what is the problem with my generated plugin.
OpenMANIPUATOR is advertised that it works with MoveIt, and on your Facebook page, you even show a "complete" MoveIt experience that is not accessible for the community, please share your existing IK plugin.
hi, I met problem when running moveit with open manipulator in rviz. It seems that the arm can not rotate in the yaw direction, which means it can't rotate from left to right? I wonder how can I solve this problem?
@ZhengQiushi, MoveIt's default IK is for 6DoF arms and it cannot resolve any pose where the end effector should be rotated around yaw or roll axis. Until ROBOTIS doesn't release a proper IK solver you have three options:
- Set the IK to position only in the kinematics.yaml, but then you won't be able to adjust the pitch of the end-effector from MoveIt
- You can use my modifications with an IKFast solver (kudos to @nxdefiant), you can just clone and build my melodic-fixes branch: https://github.com/dudasdavid/open_manipulator/tree/melodic-fixes. It mostly works, but there are some minor strange behaviors as you can see in my video above.
- You can try to create a better IKFast plugin by yourself and if it's better than what we have now, please share it with us! :)
Closing this issue as there isn't any recent activity. Please feel free to reopen when necessary.
Moveit probably don't have interest in developing 4DOF IK solver. I'll review this with my colleagues, but this will have lower priority than other ongoing projects.
Thank you @ROBOTIS-Will, I can understand that MoveIt doesn't want to develop IK solvers for every custom arm, but MoveIt makes it possible to USE a custom IK solver, so the OEM should supply the IK solver in my opinion.
And by the way, you have a proper IK solver because it's clearly visible in your official video, I'm just asking to open source your existing solver.
Thanks!
Thank you for your feedback =) We do have open source IK solver for OpenManipulator-X, which is also somewhat limited due to the nature of 4DOF. It is all opened and available for developers, but designed to be used with the GUI program that we provide https://github.com/ROBOTIS-GIT/open_manipulator/blob/master/open_manipulator_libs/src/kinematics.cpp
So all we have to do would be to create a class that inherits from kinematics::KinematicsBase and somehow combines it with kinematics.cpp
You might misunderstand me, I'm aware the custom GUI tools, but could you please check out your own ROBOTIS video on this link: https://www.facebook.com/watch/?v=2198266990449746
From 0:28 you can see OpenMANIPULATOR-X in MoveIt using (most probably) your custom IK solver.
Oh, I see. But this solver also had a limitation not being able to control the 4th pitch joint with the interactive marker.
@ROBOTIS-Will The MoveIt controller seems to incorporate the 4th joint as well (pitch), although the last commit was a year before this post was made. Does this mean the issue @dudasdavid raised is solved?
Though I can control the 4DoF arm now (through rviz's moveit plugin), the MoveIt controller is still a bit finicky; the planner does not always find a solution and sometimes sending the exact same goal (in task space) more than once works.
I think I am just confused on what is not working with the current MoveIt controller. Any help would be much appreciated! :)
Hey @all,
this discussion seemed really interesting to me so that I would like to participate my current status. I'm currently working on a stäubli ts2-40 (4DoF) with Moveit2 and Ros2. Therefore I was able to create an URDF file as well as other necessary config files. While using rviz, my motion planner (with kdl_kinematics_plugin/KDLKinematicsPlugin) worked properly and I wasn't facing problems at all (after some debugging time obviously.. :D) Another goal was, to control the Stäubli with MoveIt2 and its C++ interface. But here I do have some troubles. While my target poses are definitely in the working range of the robot and the config files should also set properly, the move_group_interface is always failing/aborting. It happened twice, that the defined pose could be planned.. But after another try (without any changes) it failed again.
So my question is also, if there is a way to control a robot arm with 4DoF in moveit without a custom IK solver? I am concerned, because it's already working by defining a goal position in Rviz. Am I understanding something wrong or what's the difference to the move_group_interface method? Help is much appreciated. Thanks in advance!
@PaulDebus99 I was wondering on a workaround without any custom solver, but I couldn't find any spare time to spend on it yet. I'm planning to modify the urdf to add 2 dummy joints with 0 or near 0 length that can fake the missing DoFs of the arm. I guess then it can easily work with the default solver, but I never tested this workaround idea :)
Hi @dudasdavid have you got any solution? I'm also working on open manipulator (4 DOF) arm and unable to locate it. I've seen your custom plugin, that you have created, but it was for ROS1, and I'm working on ROS2 humble. If you have plugin for ROS2 please share. Thanks in advance!!!
@mayank0621, unfortunately I still don't work with ROS2 so I don't have a plugin :( Altough, I tested my previous recommendation to add 2 dummy joints with 0 length links for roll and yaw of the gripper and it works very well with the default KDL solver. Until you don't have a plugin I can strongly recommend this workaround in the urdf.
Hi @dudasdavid As you have suggested I have created two dummy joint in my open manipulator urdf.xacro file, but it's still not working for me. Could you please share your open manipulator urdf.xacro file by added two dummy joint. It would be great help for me. Thanks in advance!!
Hi @mayank0621! Sure thing, I just uploaded a simple example to GitHub. You have to make changes in 2 repositories: https://github.com/dudasdavid/open_manipulator/tree/fake-6-DOF https://github.com/dudasdavid/open_manipulator_controls/tree/fake-6-DOF
You can see the commit history of what have I changed compared to the master. I also uploaded a video about it (using KDL): https://youtu.be/brmCIqGkUPc
In simulation, it works quite well (tbh it's better than my IKFast plugin), although if you want to implement it on the real robot then you have to extend the ROBOTIS HW interface code too.
Hi @dudasdavid, I am also getting same error with 4DoF open manipulator arm. After changing the URDF, I was able to move the arm to desired location. In last message you mentioned that if I want to work on real robot, I have to "extend the ROBOTIS HW interface code".
I just wanted to know what exactly do you mean by that? In which file do I have to make changes? Can you please help me a bit with that?
It has taken me a lot of try and error attempts to get turtlebo3_manipulaion adapted to moveit_task_constructor pick_place demo working before finding this conversation. Before applying the solution the only good result which I managed to get was for grasp and place postion defined exactly before the gripper. Trying to place the object so the arm needed to rotate in Z axis resulted in “no IK found”.
After reading this conversation I have applied the solution to change in the kinematics.yaml “position_only_ik: true” . And … It has turned out to be a .. success. What I observe is good enough solutions are found. I only need to chose the solution of the lowest cost so the object is placed in a way that it is not tilted vertically.
The result looks good to my opinion (see here). Now I will try to do it with real robot and … real object to be picked-placed.
Hi @dudasdavid I have added virtual joint in urdf and also extended hardware code. But in simulation Inverse kinematics in perfectly running. But in actual hardware I'm unable to run inverse kinematics. I've also modified firmware code (OPEN CR). But it also not works. I've stucked here. Could you please help me. Thanks in advance !!!!!
Hi @lmendyk have you added virtual joint in urdf to run moveit_task_constructor pick and place?
Hi @mayank0621, I never used this hack in the real robot so I cannot share any working code, but I can tell what I'd do, I hope it helps. I wouldn't change anything on the OpenCR firmware, only in the ROS driver I'd lie towards MoveIt that we have 2 more motors then just doing nothing with the commands of these 2 fake joints. I think based on the existing code you should be able to add a couple of fake motors towards ROS, most probably some yaml files too, but I wouldn't change anything in the communication towards the real arm, because you anyway don't have these fake joints. It's not a huge help but I hope you can find a way to implement what you want :)
Thanks @dudasdavid for your quick reply. Definitely I will try your suggestion.
@mayank0621 – no I have not added any fake joints instead I changed the value of position_only_ik from the default one (false) to true. And thanks to that it works “good enough” – by this I mean you can observe that solutions found by moveit_task_constructor varies in the gripper position (it is tilted which may effect especially the “place object” task but to my experiments the slight diversion from vertical placement of the object does not cause the object to fell.
But I did have problems with the ros2 turtlebot3_manipulations, I had to modify the ros2 control hardware driver (commenting out the IMU initializations which cause txrx status packets errors and some firmware slight changes – frankly speaking not sure which change exactly helped 😊 ) and finally managed to have the velocity profile applied (I changed it values to 50 instead of 500) and now the movements are much less violent.
I do observe sometimes a collision is detected during the trajectory execution, in rivz – a collision between joint 2 and joint 4 are depicted but it looks to me due to the urdf model still describes the old version of turtlebot and openManipulation hardware (they differ in shapes) . So it is rather not caused by 4DoF vs 6DoF
Hi @dudasdavid greetings!!! Virtual joint idea has not worked in hardware. So I converted your "4 DOF IK solver" from ROS1 to ROS2 and then tested it on hardware, and it works. But manipulator only reaches in (x,z) position with tolerance not in 'y'.
Greetings everybody!
So, I had also some problems regarding finding the planner for MoveIt for the 4DOF open manipulator arm and decided to work with the workaround mentioned by @dudasdavid. I have added to the urdf two virtual joints (exactly the same as @dudasdavid) and updated the hardware interface. Now it works much smoother, meaning that MoveIt can calculate the IK. Note that the roll and yaw angles of the end-effector are just dummy joints, so they cannot be controlled (simply because not enough dofs).
Here you can find two updated files hardware_interface.cpp and hardware_interface.h, where I added two new joints. In my case I update the state of each dummy joint by assigning the position of the joint to the last given command to that joint. Also, note that I added a destructor to turn off the motors once the process is finished. Do not forget to add two new joints to your controller and update the moveit package.
Also, you can see here how it works in my case with TRAC_IKKinematicsPlugin.
