-
Notifications
You must be signed in to change notification settings - Fork 119
It is suggested to add auxiliary methods about forward kinematics and inverse kinematics of the robot arm to the ur client library #312
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
Comments
Could you please elaborate on that? If you explain, what you are trying to achieve, it is much easier to understand what kind of feature your are missing. |
I'd like to convert Cartesian points and joint angles to and from each other, but I've just seen you implement this in your script and in your client library as a pose enumeration |
g_my_robot->getUrDriver()->writeJointCommand(tcp_target, comm::ControlMode::MODE_POSE, |
For example, when my robot arm moves with the car, I use some methods to find the gripping coordinates of the robot arm in the new position (Cartesian coordinates), and then I need to use movej to move directly above the new gripping coordinates, at this time I need to convert the Cartesian coordinates to the joint angle (because this saves time and the robot arm has to move significantly),Regardless of whether you can add an auxiliary method, please reply to me (I'm in a hurry to use it here), thank you very much |
Such things currently don't exist, no. If I understand you correctly, having the possibility to send Cartesian coordinates to moveJ would fit your usecase. While this is possible on a urscript level, this is currently not possible with the C++ API. As a workaround, you can also send URScript functions directly using the |
The corresponding function in urscript is get_inverse_kin(x, qnear, maxPositionError=1e-10, |
The technical difficulty would be to send the response back to the client_library application. As a standalone feature you could add a function calling that to the ScriptCommandInterface. You would have to extend the callback to handle a different message that could contain the result from the inverse kinematic calculation. At this point it would make sense to put a bit more thoughts into the communication protocol there, however. For a works-for-you implementation you could make that a bit simpler and just take the number of bytes as a decision. I'm not saying it is impossible or very difficult to implement, but it's a bit more work than just adding a single function somewhere. |
Maybe i can add one more motiontype in writemotionprimitive, do movej by cartesian coordinates, and then make corresponding changes in external_control.urscript |
If you would like to do that, feel free to create a PR. We will potentially provide this feature later this year. |
Feature summary
Short introduction to the feature and why it should be implemented
Followed by a longer description
Related issues
Links to related issues internal or external to this repo
Tasks
To complete this issue involves
The text was updated successfully, but these errors were encountered: