Tool frame transform needed as parameter

[JeroenDM]

Currently, the plugin assumes that the convention for the tool0 frame is the same as defined in the opw_kinematics plugin. This is not the case for the Fanuc robot used in the tests.

As this is difficult to derive from an urdf in general, this should be passed in some way to the plugin by the user.

[simonschmeisser]

Now I finally understand your problem! Looks like I was using ikfast for fanucs so far ... I think @gavanderhoorn is trying to establish a convention where flange is what we used as a vendor neutral sane coordinate system while tool0 (now?) corresponds to the coordinate system with the same name on the robot controller. (read http://gavanderhoorn.github.io/rep/rep-0199.html#flange to see if I mixed that up ...)

So I guess changing the srdf to use flange as tip_frame and using flange everywhere in custom code would "fix" the problem.

@gavanderhoorn do you have a more general/robust idea? Transform solutions from flange to tip_frame (eg tool0)? Provide an option (string) to set "the endpoint of ik-calculation" which defaults to flange?

[simonschmeisser]

Hmm, no, that (flange) doesn't work. opw expects a coordinate system where the z-axis coincides with the rotational axis of j6 or in terms of rep-0199: z points away from the last link.

What actually does work in this case is a joint offset of pi /3.141 on j6!

[gavanderhoorn]

So I guess changing the srdf to use flange as tip_frame and using flange everywhere in custom code would "fix" the problem.

at least in the REP you reference, flange is not supposed to be the end of a kinematic chain. That would be tool0's job. flange is really just for attaching EEF geometry.

As to how to plan with toolframes: MoveIt should be capable of transforming target poses back to the tip of the chain. And in fact, MoveIt's default IK solvers have 'gained' the capability to do this themselves. Personally I don't believe that should be the responsibility of the solver, but of the caller though.

As to usage without MoveIt: I'd suggest to present the IK solver with queries it can actually solve. So if you have a TCP that is not coincident with tool0, you'll have to transform target poses such that they are.

[simonschmeisser]

As it was early in the morning I was under the impression that this particular tool0 cannot in fact be represented by the current parameter set. And mixed up flange and tool0.

Some coffees later I found that setting the joint offset as

kinematics_solver_joint_offsets: [0.0, 0.0, -1.57079632679, 0.0, 0.0, 3.141592653589793]

works for Fanuc. So @JeroenDM does that solve your issue as well?

[gavanderhoorn]

I haven't checked, but does this offset interact with the joint limits in any way?

Adding an offset to a joint to compensate for a frame orientation doesn't seem like the way to approach this.

[simonschmeisser]

Well, this offset is in fact some sort of frame orientation as it describes the zero position of the joint. Joint limits are "shifted" so j6 in this case will still have +-360°, just tested that.

[JeroenDM]

Thank you for explaining this :) The offset on j6 does solve my issue. I agree, opw_kinematics has no concept of joint limits, and since the joint offset parameter is only used by opw_kinematics, it should not influence what happens in MoveIt. (Since we do opw_kinematics::harmonizeTowardZero(sol); before doing something with the joint values in MoveIt.)

In conclusion, as long as the z-axis points out of the flange, the difference can be encoded in the opw_parameters. I will close the issue for now, as I never came accros a z-axis not pointing out of the flange.

Feel free to comment if such robot comes up, and then we need to think about it again.