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 rdiankov/openrave#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 [email protected]
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
#67 (comment),
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 [email protected] 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 [email protected]
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
#67 (comment),
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 rdiankov/openrave#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 :)