support for flipping j1 as required for kuka

[simonschmeisser]

Kuka has weired ideas about axis of rotation, with j1, j4, and j6 being left-handed while j2, j3 and j5 are normal right handed. ikfast fails to generate a solution for j1 being left-handed (ie axis of rotation is negative). See https://github.com/rdiankov/openrave/issues/385 for a upstream bug report. I worked around this by creating a ikfast solution with a right handed j1 and flipping values in IKFastKinematicsPlugin::getPositionIK.

Do you think I should generalize my hack and open a pull request? Read in a value from parameter server and flip j1 according to this? (it does not seem necessary to flip other axis)

see my kuka_experimental fork for the current hack https://github.com/simonschmeisser/kuka_experimental/blob/hydro-devel/kuka_kr60ha_moveit_plugins/src/kuka_kr60ha_manipulator_ikfast_moveit_plugin.cpp

[gavanderhoorn]

I'm not sure I understand you completely: are you saying that your IKFast generator couldn't generate a solver when you had an axis element with a negative direction of rotation (ie: xyz="0 -1 0")?

I've successfully generated plugins for URDFs with that (for fanuc_lrmate200ic_support/urdf/lrmate200ic5f_macro.xacro fi) in the past, so I'm wondering if this is something that has changed (in IKFast) or you're running into some other problem.

[simonschmeisser]

the issues seems limited to joint_1/j1/a1/joints[0], ie the first joint in the chain. In your case Joint_3 is negative, that does not seem to cause any harm. It is sufficient to flip Joint_1 in my case while Joint_4 and Joint_6 can stay negative.

[gavanderhoorn]

Interesting.

As to your suggestion: ideally this is something that is fixed upstream. But we could consider integrating a (temporary) work-around in moveit_ikfast. @davetcoleman what do you think?

[simonschmeisser]

There was not even a comment since January when I filed the upstream bug report and generally response to tickets on openrave seems slowish ...

[shaun-edwards]

I'm late to the conversation, and I'm sure this is a dumb question, but isn't the axis direction defined by which directions are reported as + and -? If I am correct, then the root of the problem is when A1 points in the negative Z? direction, as defined by +/-. Is it that IKFast just can't handle this axis direction relative to the others?

[BrettHemes]

I agree the Kuka z-axis conventions are a bit strange but we had no problem getting an IKFast solution to work using the KR6 R700 with the axes as defined by Kuka (no modification). In fact this is the exact setup we are using for our Descartes development.

On Wed, Jun 29, 2016 at 10:24 AM, Shaun Edwards notifications@github.com wrote:

I'm late to the conversation, and I'm sure this is a dumb question, but isn't the axis direction defined by which directions are reported as + and -? If I am correct, then the root of the problem is when A1 points in the negative Z? direction, as defined by +/-. Is it that IKFast just can't handle this axis direction relative to the others?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ros-planning/moveit_ikfast/issues/67#issuecomment-229391607, or mute the thread https://github.com/notifications/unsubscribe/AJaIqXyk2M3ed4MDTMMaP_GI2TVs2yT3ks5qQo4ogaJpZM4JBMYr .

[BrettHemes]

Additionally, I don't think left/right handedness is the correct term here as the manual figures don't depict any axes other than Z. I have to believe that everything is actually "right-handed" internally, just that the picture was drawn using some negative z-axes (probably for readability of the figure). That said, their choice of frames doesn't follow the modified DH conventions but is in no way incorrect.

On Wed, Jun 29, 2016 at 10:42 AM, Brett Hemes brett.hemes@gmail.com wrote:

I agree the Kuka z-axis conventions are a bit strange but we had no problem getting an IKFast solution to work using the KR6 R700 with the axes as defined by Kuka (no modification). In fact this is the exact setup we are using for our Descartes development.

On Wed, Jun 29, 2016 at 10:24 AM, Shaun Edwards notifications@github.com wrote:

I'm late to the conversation, and I'm sure this is a dumb question, but isn't the axis direction defined by which directions are reported as + and -? If I am correct, then the root of the problem is when A1 points in the negative Z? direction, as defined by +/-. Is it that IKFast just can't handle this axis direction relative to the others?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ros-planning/moveit_ikfast/issues/67#issuecomment-229391607, or mute the thread https://github.com/notifications/unsubscribe/AJaIqXyk2M3ed4MDTMMaP_GI2TVs2yT3ks5qQo4ogaJpZM4JBMYr .

[shaun-edwards]

Based on my understanding and @BrettHemes's comments, I'm not sure this is an issue. @simonschmeisser, care to weigh in?

[simonschmeisser]

I noticed that even though no response to the upstream bug report happened, there have been two commits that might affect this. However I haven't succeeded yet to build recent openRAVE (it is assuming a c++11 version of fcl). I will soon try that once more and then get back to you. Sorry for potentially wasting your time.

ps: +1 on docker builds @gavanderhoorn https://github.com/rdiankov/openrave/issues/394

[gavanderhoorn]

@simonschmeisser: I think I've used personalrobotics/ros-openrave on dockerhub in the past. It's a relatively recent build. Probably doesn't include the commits you mention though.

[gavanderhoorn]

Sorry for potentially wasting your time.

And should obviously never be a reason to not ask questions :)