IEEE Robotics & Automation Magazine - December 2018 - 71

V-REP
Simulator or
Visualizer

Simulink

Motion Capture

Operator
Inputs

Haptic Device

Task Planner

OTHex Ctrl.

System State

Joypad

Schunk
Gripper

Sunrise
Cabinet

ESC +
Brushless Motors
LBR-iiwa Arm

OTHex AM

Grippers
LEDs

Figure 5. The software architecture used in the Tele-MAGMaS project, showing the MATLAB-Simulink links (green arrows), the C
S-function links (blue arrows), the GenoM3 links (orange arrows), and the low-level links (black arrows). ESCs: electronic speed
controllers; LEDs: light-emitting diodes.

where M x is the inertia of the system projected at the object
point considered for the teleoperation x; d min and d min
denote the shortest distance, component-wise, toward an
obstacle and its derivative; and K P and K D are two positive
definite matrices chosen to generate the viscoelastic force.
The total rendered force is saturated to satisfy the actuation
constraints of the haptic device.
Shared-Control MAGMaS
The third possible autonomy level for the system, shared
control, combines the two previous approaches. An automatic task planner determines the motion commands and
changes of logic states, and the human operator can modify
the planned trajectories. Human operators can locally
change the trajectories or change the trajectories' time law
for reacting to changes in the environment. This autonomy
level is well suited for a semistructured environment, i.e.,
partially mapped or fully mapped, but with the possible
occurrence of unpredictable events, e.g., at a construction
site or in an industrial environment where humans, robots,
and other machines work together.
Software Architecture
The Tele-MAGMaS is composed of three main robotic parts:
the 1) LBR-iiwa arm, 2) OTHex AM, and 3) Omega.6 haptic
interface (all commanded by a centralized controller and interfaced with a simulator/visualizer). To develop the experimental framework, we relied on the GenoM3 (https://git
.openrobots.org/projects/genom3/wiki) abstraction layer,
which allows middleware-independent software components
to be defined for robotics [the middleware, e.g., the Robot
Operating System (ROS), can then be chosen at compilation
time]. The GenoM3 components are written in C/C++ and can
be controlled via tcl-shell, multi-command line, MATLABSimulink, or middleware-specific means. This allows high flexibility in the development and use of the components.
The global software architecture is depicted in Figure 5.
The high-level control of the full system is realized in MATLABSimulink and linked to the hardware via GenoM3 com-

ponents (OTHex, joypad, motion capture, and LBR-iiwa) or
MATLAB S-function drivers (haptic device and V-REP simulation device), which are C++ functions natively interacting
with MATLAB. We chose this approach because we realized
that the development and test of the controller in MATLABSimulink are considerably faster than in pure C/C++. However,
because MATLAB-Simulink is not meant for real-time execution, the hardware is commanded via GenoM3 components.
These GenoM3 components are essentially drivers for the
hardware to satisfy real-time constraints, as we chose to keep
most of the algorithmic
part in MATLAB-Simulink.
In centralized cooperative
To satisfy the hard realtime constraints of commanipulation, both robots
munication with the
LBR-iiwa, inverse kinereceive commands based
matics and other related
utilities are performed in
on the position of the
the GenoM3 component.
In our architecture, MATmanipulated object.
LAB-Simulink runs at
500 Hz, and the task/path
planner (see the "System
Autonomy Framework" section), human input interpreter,
system-state estimator, and OTHex controller all run inside
MATLAB-Simulink.
This component-based architecture allows easy repartitioning of the load between processes and machines. In our
experiment, we chose to use the ROS as middleware, which
provides sufficient real-timeness for the intended purpose.
The component-based design also allows the seamless change
of operator inputs and perception components or of the
MAGMaS hardware, as each of those are separate from the
main algorithmic part and provide standard interfaces that
are not hardware specific.
Simulation Environment
The simulation must balance the accuracy of the simulated
behavior with the computational load, weighted by the
december 2018

IEEE ROBOTICS & AUTOMATION MAGAZINE

https://git.openrobots.org/projects/genom3/wiki https://git.openrobots.org/projects/genom3/wiki

IEEE Robotics & Automation Magazine - December 2018

Table of Contents for the Digital Edition of IEEE Robotics & Automation Magazine - December 2018