The GripperDB module (gripper database module) is an optional on-board module of the rc_visard and is licensed with any of the modules ItemPick and BoxPick or SilhouetteMatch. Otherwise it requires a separate CollisionCheck license to be purchased.
The module provides services to set, retrieve and delete grippers which can then be used for checking collisions with a load carrier or other detected objects (only in combination with SilhouetteMatch). The specified grippers are available for all modules supporting collision checking on the rc_visard.
|Max. number of grippers||50|
|Supported gripper element geometries||Box, Cylinder|
|Max. number of elements per gripper||15|
|Collision checking available in||ItemPick and BoxPick, SilhouetteMatch|
Setting a gripper¶
The gripper is a collision geometry used to determine whether the grasp is in collision with the load carrier. The gripper consists of up to 15 elements connected to each other.
At this point, the gripper can be built of elements of the following types:
BOX, with dimensions
CYLINDER, with radius
Additionally, for each gripper the flange radius, and information about the Tool Center Point (TCP) have to be defined.
Robot flange radius¶
Collisions are checked only with the gripper, the robot body is not considered.
As a safety feature, to prevent collisions between the load carrier and the robot, all grasps having any part of the
robot’s flange inside the load carrier can be designated as colliding (see Fig. 62).
This check is based on the defined gripper geometry and the flange radius value. It is optional to use
this functionality, and it can be turned on and off with the CollisionCheck module’s run-time parameter
check_flange as described
in Parameter overview.
Creating a gripper via the REST-API or the Web GUI¶
When creating a gripper via the REST-API interface or the Web GUI, each element of the gripper has a parent element, which defines how they are connected. The gripper is always built in the direction from the robot flange to the TCP, and at least one element must have ‘flange’ as parent. The elements’ IDs must be unique and must not be ‘tcp’ or ‘flange’. The pose of the child element has to be given in the coordinate frame of the parent element. The coordinate frame of an element is always in its geometric center. Accordingly, for a child element to be exactly below the parent element, the position of the child element must be computed from the heights of both parent and child element (see Fig. 63).
It is recommended to create a gripper via the Web GUI, because it provides a 3D visualization of the gripper geometry and also allows to automatically attach the child element to the bottom of its parent element, when the corresponding option for this element is activated. In this case, the elements also stay attached when any of their sizes change. Automatic attachment is only possible when the child element is not rotated with respect to its parent.
The reference frame for the first element for the gripper creation is always the center of the robot’s flange with the z axis pointing outwards. It is possible to create a gripper with a tree structure, corresponding to multiple elements having the same parent element, as long as they are all connected.
Calculated TCP position¶
After gripper creation via the
set_gripper service call, the TCP position in the flange coordinate
system is calculated and returned as
It is important to check if this value is the same as the robot’s true TCP position. When creating a
gripper in the Web GUI the current TCP position is always displayed in the 3D gripper visualization.
Creating rotationally asymmetric grippers¶
For grippers which are not rotationally symmetric around the z axis, it is crucial to ensure that the gripper is properly mounted, so that the representation stored in the GripperDB module corresponds to reality.
The GripperDB module is called
rc_gripper_db in the REST-API and is represented in the
Web GUI under
The user can explore and call the GripperDB module’s services,
e.g. for development and testing, using the
REST-API interface or
the Web GUI.
The GripperDB module offers the following services.
Persistently stores a gripper on the rc_visard. All configured grippers are persistent over firmware updates and rollbacks.
This service can be called as follows.PUT http://<host>/api/v2/nodes/rc_gripper_db/services/set_gripper
Returns the configured grippers with the requested
This service can be called as follows.PUT http://<host>/api/v2/nodes/rc_gripper_db/services/get_grippers
Deletes the configured grippers with the requested
This service can be called as follows.PUT http://<host>/api/v2/nodes/rc_gripper_db/services/delete_grippers
Each service response contains a
which consists of a
value plus an optional
A successful service returns with a
return_code value of
return_code values indicate that the service failed.
return_code values indicate that the service succeeded with additional information.
The smaller value is selected in case a service has multiple
but all messages are appended in the
The following table contains a list of common codes:
|-1||An invalid argument was provided|
|-7||Data could not be read or written to persistent storage|
|-9||No valid license for the module|
|-10||New gripper could not be added as the maximum storage capacity of grippers has been exceeded|
|10||The maximum storage capacity of grippers has been reached|
|11||Existing gripper was overwritten|