Does the ROS driver expose the safety planes?

[mzucker]

Summary

Was hoping to get some information about safety setup of the robot including safety planes on the ROS side.

Versions

• ROS Driver version: Both ROS Melodic and ROS Noetic, driver commit 54e24c0; universal_robot calibration_devel commit 1ffd6918
• Affected Robot Software Version(s): URSoftware 3.15.1.106171 (Mar 29 2021)
• Affected Robot Hardware Version(s): UR10
• Robot Serial Number: 2018300027
• UR+ product(s) installed:
• URCaps Software version(s): external control

Impact

It would be great if it was possible to read safety planes defined in the robot installation so they could be used for planning (e.g. in MoveIt, etc).

Use Case and Setup

The use case would be a ROS topic related to the safety parameters of the robot installation, including a list of up to the maximum number of defined safety planes (8 I believe). Then the safety planes could be defined as primitives in MoveIt and added to the planning scene, perhaps with some additional safety margin to avoid tripping a protective stop on the robot side.

Is this possible? If not, please consider this a feature request!

[fmauch]

I cannot think of an "easy" implementation of this and we currently do not have the plan or resources for this. So, I'll mark it as "help wanted".

[mzucker]

I also asked on the UR forums: https://forum.universal-robots.com/t/are-safety-planes-exposed-to-ros/16546

Maybe someone at UR will get excited about making this possible?

[urrsk]

@mzucker I like the idea, it could be the next step of making integration easier.
See my reply on the forum https://forum.universal-robots.com/t/are-safety-planes-exposed-to-ros/16546

How do you in vision the use. An export of safety boundaries to an URDF file or?

[gavanderhoorn]

Could publish them as shape_msgs/Plane. That would also make it easy to keep them in-sync with whatever happens on the controller.

For MoveIt specifically you'd need something which takes those Planes and converts them into moveit_msgs/CollisionObject, but I would not suggest having the driver publish those directly. That is rather specific to MoveIt.

---

Or a custom message. I don't really like the fact shape_msgs/Plane does not have a Header.

geometry_msgs/PolygonStamped does have one, but a polygon is not a plane of course. Perhaps with the assumption it models an infinite square?

[mzucker]

I like the idea of publishing on a topic and letting users integrate with it how they want. I also agree that a header would be important to establish which frame the plane is expressed relative to (presumably 'base'). Rather than geometry_msgs/PolygonStamped, how about geometry_msgs/PoseArray? I'm thinking PoseArray vs single PoseStamped because there could be multiple safety planes defined.

There is 2 extra DOF in pose vs plane but could adapt some convention to figure out a canonical pose given a plane. For example:

• pose origin = point on plane closest to origin of frame
• pose z-axis aligned with plane normal
• pose x-axis or y-axis chosen to maximize projection onto world x or y

Or just make a ur_msgs/SafetyPlanes message that has a header, and an array of planes?

However the message is delivered, I would almost certainly turn around and create CollisionObjects in MoveIt, but I think it would be good to allow users to do whatever they want with them.