ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

but I can't find the steps for creating a service where I issue a request consisting of Cartesian Coordinates as an input and getting joint angles as an output.

Are you trying to implement your own service, or do you want to use an existing service, which does this for your robot?

If the latter, would the GetPositionIK service from the move_group MoveIt capability work for your use case? Afaik, for the service to work, you should just launch a MoveIt configuration for your arm, populate a moveit_msgs/GetPositionIK with the appropriate info, and invoke the service.

Note that invoking services incurs quite some overhead, so depending on your use case, you might want to look into the MoveIt Kinematics/C++ API. The tutorial should give you enough information on how to use it with your particular robot/urdf.

There is some stuff about the PR2 arm, but I can't work out how to adapt this for my arm.

That tutorial seems to have been written when arm_navigation was still used. I think (but am not sure) you'll have to adapt that quite a bit to get it working with MoveIt.

but I can't find the steps for creating a service where I issue a request consisting of Cartesian Coordinates as an input and getting joint angles as an output.

Are you trying to implement your own service, or do you want to use an existing service, which does this for your robot?

If the latter, would the GetPositionIK service from the move_group MoveIt capability work for your use case? Afaik, for the service to work, you should just launch a MoveIt configuration for your arm, populate a moveit_msgs/GetPositionIK with the appropriate info, and invoke the service.

Note that invoking services incurs quite some overhead, so depending on your use case, you might want to look into the MoveIt Kinematics/C++ API. The tutorial should give you enough information on how to use it with your particular robot/urdf.

There is some stuff about the PR2 arm, but I can't work out how to adapt this for my arm.

That tutorial seems to have been written when arm_navigation was still used. I think (but am not sure) you'll have to adapt that quite a bit to get it working with MoveIt.


Edit: with a normal MoveIt configuration for your robot, you should see:

[..]
Loading 'move_group/MoveGroupKinematicsService'...
[..]

in your console, which should give you access to the /compute_fk and /compute_ik services (as I wrote in my original answer). Does this not cover your use case?

but I can't find the steps for creating a service where I issue a request consisting of Cartesian Coordinates as an input and getting joint angles as an output.

Are you trying to implement your own service, or do you want to use an existing service, which does this for your robot?

If the latter, would the GetPositionIK service from the move_group MoveIt capability work for your use case? Afaik, for the service to work, you should just launch a MoveIt configuration for your arm, populate a moveit_msgs/GetPositionIK with the appropriate info, and invoke the service.

Note that invoking services incurs quite some overhead, so depending on your use case, you might want to look into the MoveIt Kinematics/C++ API. The tutorial should give you enough information on how to use it with your particular robot/urdf.

There is some stuff about the PR2 arm, but I can't work out how to adapt this for my arm.

That tutorial seems to have been written when arm_navigation was still used. I think (but am not sure) you'll have to adapt that quite a bit to get it working with MoveIt.


Edit: with a normal MoveIt configuration for your robot, you should see:

[..]
Loading 'move_group/MoveGroupKinematicsService'...
[..]

in your console, which should give you access to the /compute_fk and /compute_ik services (as I wrote in my original answer). Does this not cover your use case?

I merely mentioned the C++ interface so you'd know about it: it has much less overhead than a ROS service, and with about 4 to 5 lines of initialisation (see the tutorial I linked), I'm guessing it will be around the same programming effort as setting up and working with a ros::ServiceClient.