-
Notifications
You must be signed in to change notification settings - Fork 147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proper 4DoF kinematics solver for MoveIt #192
Comments
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:
|
Closing this issue as there isn't any recent activity. Please feel free to reopen when necessary. |
This issue is still valid and has to be re-opened. |
I guess it simply means that it won't be fixed. |
Moveit probably don't have interest in developing 4DOF IK solver. |
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 =) |
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: From 0:28 you can see OpenMANIPULATOR-X in MoveIt using (most probably) your custom IK solver. |
Oh, I see. |
@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. So my question is also, if there is a way to control a robot arm with 4DoF in moveit without a custom IK solver? |
@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. |
@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. |
Nice!! and thanks for your quick reply @dudasdavid |
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. |
Hi @mayank0621! Sure thing, I just uploaded a simple example to GitHub. You have to make changes in 2 repositories: You can see the commit history of what have I changed compared to the master. 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. |
Thank you so much @dudasdavid. |
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? |
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!!! |
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. Also, you can see here how it works in my case with TRAC_IKKinematicsPlugin. |
@fenixkz , when I add your changes and try to do catkin_make . I get errors. |
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.
The text was updated successfully, but these errors were encountered: