IEEE Robotics & Automation Magazine - June 2021 - 95

Grasp Control
After the system reaches a pregrasp state [Figure 5(f) and (g)],
the corresponding end effector moves toward the object until
a predefined force threshold is exceeded. This signals contact
with either the object or the supporting surface.
We adopt distinct grasp control strategies for both robotic
hands. The qb SoftHand is fully closed, while the arm motion
is regulated by a joint impedance controller. This prevents the
table surface from blocking the hand fingers when they are
closing [Figure 5(l)]. The ARMAR-6 hand is closed in two
phases. Initially, the fingers are closed to around one-half of
their full range to constrain the object between the thumb and
the fingers, and, after a small delay, the hand is closed fully
[Figure 5(h)]. During these movements, we support the grasp
control strategy by controlling the wrenches exerted by the
robot hand on the bench surface. This guarantees that the
hand does not lose contact with the supporting surface and
that there is not an excessive build-up of forces during closure.
The arms lift the grasped object for a predefined amount
of time, which guarantees that the tool loses contact with the
supporting surface. Grasp success is validated using a combination
of two methods: 1) reading the hand encoders and 2)
using force measurements.
Placement Planning
Our placement planning pipeline consists of the following
steps:
●
Approximate the combined hand-object volume with an
MVBB [Figure 5(j) and (k)].
●
Search for a candidate placement affordance, and validate
whether this affordance and the corresponding placement
motion are feasible [Figure 5(l) and (m)].
Given the hand-object MVBB and the status of the current
toolbox occupancy, the placement affordance that leads
toward a more uniform toolbox occupancy is identified. Since
top-down placements are feasible only in the toolbox, the
placement affordances narrow down to 6D poses for the end
effector above the toolbox. The hand-object MVBB is used
by the motion planner to validate whether a certain placement
pose and the corresponding
placement motion are kinematically
reachable and collision free (i.e., there
are no hand-object-toolbox collisions).
If this is not possible, the system
attempts to find the closest feasible
placement pose by sampling a predefined
2D grid above the toolbox.
ROS
ecosystem
Placement Execution
The two arms are prevented from
simultaneously placing tools in the toolbox
due to the space constraints of the
toolbox. Therefore, an arm must
acquire exclusive access to the area
above the toolbox and prevent the other
arm from accessing it simultaneously.
ARMAR-6
hand ROS
driver
Mask
R-CNN
MoveIt
(online motion
planning and
control)
JUNE 2021 * IEEE ROBOTICS & AUTOMATION MAGAZINE *
95
High
Medium
Low
High
High
Medium Low
Low
Low
Low
Medium Low
Containerization
Containerization
Native inclusion
Once a feasible placement affordance is found and access
to the placement area is acquired, the corresponding arm
moves above the toolbox and lowers its end effector until contact
with the bottom of the toolbox is detected and the object
is released. The FT measurements of the wrist-mounted FT
sensor are used to distinguish between contact of the end
effector with the bottom of the toolbox and contact with the
toolbox sides. This can occur because of partial knowledge of
the combined hand-object volume through point cloud data.
In case the end effector collides with the sides of the toolbox,
we use the FT feedback to repulse the arm toward the center
of the toolbox and out of collision [Figure 5(n) and (o)].
Systems Integration Case Study
In this section, we showcase how the methodology proposed
in the " Systems Integration and Methodology " section is
employed to achieve a smooth integration for the system presented
in the " Dual-Arm Tool-Packing System " section.
As the system is still in the R&D stage, we consider the
low-level integration conditions C1 (interface) and C2 (syntax)
as more important since those enable the quick development
of a baseline system on which to iterate. Therefore, the
priority factors pC1
(interface) and pC2
(syntax) have been set
to 1.0 to give more impact to the corresponding conditions, as
illustrated in Table 3. Summaries of the high- and low-level
integration decisions made for the dual-arm system components
are presented in Tables 4 and 5, respectively.
ROS Ecosystem
As the dual-arm system is developed using ROS, several ROS
components were included natively. It was not required to
containerize any ROS-based component as ROS was the
Table 3. The priority factor per low-level
integration condition for the dual-arm system.
C1
Priority factor
1.0
C2
1.0
C3
0.5
C4
0.5
C5
0.5
Table 4. The high-level integration effort per component of the dualarm
system.
Conflict
Resolution
Effort
Low
Native
Inclusion
Impact
Low
Blueprint
Creation
Effort
Containerization
Impact
Medium Low
High-Level
Integration
Approach
Native inclusion
IEEE Robotics & Automation Magazine - June 2021

Table of Contents for the Digital Edition of IEEE Robotics & Automation Magazine - June 2021
