IEEE Robotics & Automation Magazine - June 2021 - 96

development tool used for several elements of the system,
such as the KUKA iiwa arm drivers and the grasping and
placement planning components. Therefore, both the highand
low-level integration efforts for including ROS-based
third-party components natively and directly were low.
ARMAR-6 Hand ROS Driver
The ARMAR-6 hand used by the dual-arm system is actuated
by a real-time controller developed using the ArmarX robotics
framework (https://armarx.humanoids.kit.edu/index.html)
developed by the Karlsruhe Institute of Technology. The version
of ArmarX required relies on Ubuntu 14 and cannot be
run directly on the robot's computer, which uses Ubuntu 18.
As such, a native inclusion approach requires high effort and
has a significant impact on the system. On the other hand, a
container blueprint that interfaces ArmarX to ROS needs to be
created; this also involves high effort, but the impact of this
approach on the system is low. Therefore, the high-level integration
approach we pursued was containerization.
Regarding low-level integration, we identified that there is
a medium amount of effort required to create a bridge with
ROS for the existing ArmarX interface [C1 (interface)]. Also,
C5 (support) is unmet because this specific component version
was deprecated, and the support community of ArmarX
is still in its early stage. Therefore, according to (1), there is a
moderate amount of effort (. )
f =
integration of this component. However, developing an alternative
controller from scratch would require much more
effort, so we decided to use the existing component but augment
it so that it can be interfaced with ROS.
Mask R-CNN
Mask R-CNN is a neural network used for object segmentation
[21]. The dual-arm system uses a customized version of Mask
R-CNN written in Tensorflow (https://www.tensorflow
.org/). The version of Tensorflow used requires older GPU drivers
not supported officially by Ubuntu 18. Adopting such drivers
would limit the rest of the system in using GPU computation.
On the other hand, container blueprints of Mask R-CNN were
already available in the SecondHands project's repositories and
ready to be used. As such, minimal effort was required to adapt
its blueprint to our system. Therefore, the high-level approach
pursued for Mask R-CNN was containerization.
The custom version of Mask R-CNN is a SecondHands
project output that was not maintained after the end of the
project [C5 (support)]. Also, Mask R-CNN does not have documentation
and tests [C4 (code quality)]. Despite those shortcomings,
it requires less effort to adapt the Mask R-CNN
interface [C1 (interface)] than to reimplement the component;
therefore, augmentation was chosen as the low-level integration
approach.
Online Motion Planning
The dual-arm system uses MoveIt [22] to perform online
motion planning. MoveIt is part of the ROS ecosystem; since
the dual-arm system is developed using ROS, there are no
conflicts to resolve, as already explained in the " ROS Ecosystem "
section. As such, the high-level integration approach
pursued was native integration.
The ROS drivers of the robot arms are not implemented
e 0333 associated with the
using the ROS control framework, but this is the only way
MoveIt interfaces with robot hardware [C1 (interface)]. Additionally,
MoveIt's online motion-planning functionality is not
satisfactory for the given system, as the replanning is performed
only if the current plan becomes infeasible, e.g., due to
collision with a moving obstacle [C3 (performance)]. Finally,
MoveIt's online planning features are not extensively documented,
and MoveIt does not offer official support to users
[C4 (code quality) and C5 (support)]. Based on these considerations,
(1) provided a high score (. ),
e 0571
f =
and the lowlevel
integration approach chosen was the reimplementation
of MoveIt's online motion planning functionality and ROS
control's joint trajectory-following capabilities.
Based on considering the integration level required for each
component, we have assigned the estimated integration effort
and impact on the system, as explained in Table 4. The effort
coefficient ef
was calculated for each low-level integration concoefficients
increase. The choice between
dition (Table 5), and low-level integration becomes increasingly
complex as the ef
containerization and native integration/high-level integration
approaches is guided by the estimated efforts and impact. The
approach chosen aims to minimize the effort and impact of
integration on the system. By employing our methodology, we
managed to choose the integration technique that was most
appropriate for every component of the system without committing
to large, unneeded integration works.
Table 5. The low-level integration effort per component of the
dual-arm system.
ROS ecosystem
C1 C2 C3 C4 C5
0.0
ARMAR-6 hand ROS driver 2.0
Mask R-CNN
MoveIt (online motion
planning and control)
3.0
3.0
0.0
0.0
0.0
0.0
ef
0.0 0.5 0.5
Low-Level
Integration
Approach
0.095 Direct integration
0.0 0.0 1.5 0.333 Augmentation
0.0 1.0 1.5 0.524 Augmentation
1.5 1.0 0.5 0.571 Reimplementation
Experimental Validation
Integration quality is inherently difficult
to measure for three main reasons.
1) Integration is often considered as a
binary concept, i.e., it is either successful
or not; 2) it is difficult to quantify
which aspects of system performance
are affected by system integration; and
3) integration methodologies affect not
only the system performance but also
the amount of time required to build
a system. In this section, we address
96 * IEEE ROBOTICS & AUTOMATION MAGAZINE * JUNE 2021
https://armarx.humanoids.kit.edu/index.html https://www.tensorflow.org
IEEE Robotics & Automation Magazine - June 2021

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