PilzDE / pilz_industrial_motion

Industrial trajectory generation for MoveIt!.
https://wiki.ros.org/pilz_industrial_motion
119 stars 37 forks source link

Support for Joint Coupled Robots #334

Closed srujan-aris closed 3 years ago

srujan-aris commented 3 years ago

Is your feature request related to a problem? Please describe. Trajectory Generation for Kinematic Coupled Robots. For example the Fanuc Collaborative Robot series come with their Joint2 and Joint3 coupled together. If I use this pilz_command_planner to generate robot trajectories for such robots, the resultant trajectories are not correct I think there should be a way to generate robot trajectories for such robots

Describe the solution you'd like For my application what I temporarily did was, I changed the code below this line. I applied the folmula to ge the actual joint values are pushed back into the point.positions. That worked for me.

But I feel there should be some procedure to deal with joint coupled robots. Any thoughts?

gavanderhoorn commented 3 years ago

I'm not a maintainer here, but you mention a Fanuc, and that got my attention.

In ROS, joint angles are always 'decoupled' and with respect to the origin of the joint (ie: the 'previous joint').

Robot drivers are (implicitly) expected to take this into account, and if a robot reports (and takes) its joint angles in a different way, it's the driver's job to compensate -- in both directions.

In fanuc_driver and fanuc_driver_exp, this (de)coupling is done transparently.

From your request, I have the impression you are either not using either of those, or have not configured them correctly.

Could you provide some more information about your setup? Are you perhaps generating TP programs off-line and then uploading them?

again, not a maintainer here, but ideally we would not add support for the kind of corner case(s) you describe, but if possible, let drivers take care of that. If you have something custom, it would perhaps be better (and more compatible) to (de)couple joint angles for J2 and J3 in the component which is responsible for interfacing with your Fanuc (whether a real-time connection or a convert-ROS-trajectories-to-LS component). That way, you'll never have to adapt motion planning software ever again, as the coupling employed by Fanuc is hidden from the rest of your ROS application.

srujan-aris commented 3 years ago

@gavanderhoorn , thanks for your answer and suggestions. Yes, I am not using either fanuc_driver / fanuc_driver_exp, we have our own fanuc driver. In my setup my ROS system is not connected to the Fanuc directly. Hence, there is also no two-way communication between ROS and Fanuc driver. I have an middleware system which communicates between our fanuc driver and ROS. I am using ROS only to simulate the motions and expecting the real robot to mimic the same. Hence I rely only on the type of motions (Linear motion, Point to Point/free-space) I can generate using TP programs (my driver generates TP programs).

I didn't quite understand this well,

it would perhaps be better (and more compatible) to (de)couple joint angles for J2 and J3 in the component which is responsible for interfacing with your Fanuc (whether a real-time connection or a convert-ROS-trajectories-to-LS component)

from my limited understanding, I thought I will have to tweak my trajectories to compensate for J2-J3. I'm open to take your suggestions if there's a better way to do this.

gavanderhoorn commented 3 years ago

Yes, I am not using either fanuc_driver / fanuc_driver_exp, we have our own fanuc driver.

would be interesting to compare notes. Only by collaborating can we make progress.

my driver generates TP programs [..] I thought I will have to tweak my trajectories to compensate for J2-J3

You only have to couple the joints in the step ros-trajectory-to-tp-program. No where else.

So I'd suggest to add the coupling there, as that would immediately make any trajectory coming out of ROS 'compatible' with your setup without having to change each-and-every motion planning system you (may) use (in the future).

Why change N systems to deal with an idiosyncrasy which exists in 1 target, if there is only 1 piece of data communicated to that system (ie: a JointTrajectory or whatever trajectory representation you use)?

Change the consumer, not all producers.

jschleicher commented 3 years ago

Thank you @gavanderhoorn for sharing your experiences with fanuc robots. Closing here for inactivity - please re-open in moveit upstream if you still have any issues. The planner was integrated into moveit, so this repo is finally abandoned.