0
$\begingroup$

Rosanswers logo

I've got a simulation setup of the Kuka KR6 Agilus running in Gazebo using MoveIt for movement.

In order to move the robot I'm calling MoveGroupInterface::setPoseTarget and MoveGroupInterface::asyncMove(), and to get the current pose I'm calling MoveGroupInterface::getCurrentPose.

There is an inconsistency between the pose that is set and the pose that is reported from MoveIt. The image below shows the pose I'm requesting and the pose I'm getting after the robot has reached its pose.

Pose

I guess the pose is correct, but why the difference in the quaternions representing orientation? I don't specify the end_effector_link in any calls to setPoseTarget() or getCurrentPose().


Originally posted by Borkr on ROS Answers with karma: 16 on 2019-01-23

Post score: 0


Original comments

Comment by Borkr on 2019-01-23:
Without any changes it now reports the following orientation (0.0, 0.7071, 0.0, 0.7071) with the same desired position and desired orientation. Reported position is still correct.

Comment by Borkr on 2019-01-23:
The problem is with the last joint. When joint values are calculated it is set to arbitrary positions as it doesn't influence the actual pose of the robot per se, as it has no attachments to it, but is somehow included in the calculation when asking for current pose. Should this be reported?

Comment by fvd on 2019-02-19:
Did you manage to fix this?

Comment by Borkr on 2019-10-21:
Not really a fix, but orientations became accurate when a tool was included in the kinematic chain. From what I can recall about the problem, it would seem that the joint position of the last joint didn't matter as the end-point was located in the center of that joint. However, from what I can understand, it should matter. Seemingly it did for FK but not IK. This problem no longer occurred when I added a tool to the kinematic chain.

Comment by fvd on 2020-02-29:
If you can make an answer of this and mark it solved, that would be great.

Comment by gvdhoorn on 2020-02-29:
Should this not be reported on the MoveIt issue tracker? I agree with @Borkr: whether or not a chain ends with the last joint (or link, really) should not matter for correct FK/IK.

Comment by fvd on 2020-02-29:
If it's a reproducible bug then yes, if it's a vague memory of what might solved a problem related to this issue and robot, then it seems better stored as an answer here.

Comment by Borkr on 2020-03-26:
Sorry for the late reply, added the answer but I'm unable to accept my own answer due to limited points.

Comment by blue_barracuda on 2020-05-07:
I'm experiencing a similar issue. Would you mind providing a little more detail on your solution?

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Not really a fix, but orientations became accurate when a tool was included in the kinematic chain.

From what I can recall about the problem, it would seem that the joint position of the last joint didn't matter as the end-point was located in the center of that joint. However, from what I can understand, it should matter. Seemingly it did for FK but not IK. This problem no longer occurred when I added a tool to the kinematic chain.


Originally posted by Borkr with karma: 16 on 2020-03-26

This answer was ACCEPTED on the original site

Post score: 0

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.