# PAPRAS: Plug-And-Play Robotic Arm System

Joohyung Kim, Dhruv C Mathur, Kazuki Shin, Sean Taylor  Joohyung Kim, Dhruv C
Mathur, Kazuki Shin, and Sean Taylor are with the KIMLAB (Kinetic Intelligent
Machine LAB) at the University of Illinois Urbana-Champaign {joohyung,
dmathur2, kazukis2<EMAIL_ADDRESS>All authors contributed equally to
this work (alphabetical order).

###### Abstract

This paper presents a novel robotic arm system, named PAPRAS (Plug-And-Play
Robotic Arm System). PAPRAS consists of a portable robotic arm(s), docking
mount(s), and software architecture including a control system. By analyzing
the target task spaces at home, the dimensions and configuration of PAPRAS are
determined. PAPRAS’s arm is light (less than 6kg) with an optimized 3D-printed
structure, and it has a high payload (3kg) as a human-arm-sized manipulator. A
locking mechanism is embedded in the structure for better portability and the
3D-printed docking mount can be installed easily. PAPRAS’s software
architecture is developed on an open-source framework and optimized for low-
latency multiagent-based distributed manipulator control. A process to create
new demonstrations is presented to show PAPRAS’s ease of use and efficiency.
In the paper, simulations and hardware experiments are presented in various
demonstrations, including sink-to-dishwasher manipulation, coffee making,
mobile manipulation on a quadruped, and suit-up demo to validate the hardware
and software design.

##  I Introduction

Robotic manipulation has been explored since the start of robotics research.
Industrial robotic arms have been developed and used for decades for fast and
precise manufacturing and heavy-loaded tasks. From car assembly to
semiconductor fabrication, robotic arms and manipulation have made a
significant contribution to the manufacturing industry.

Recently, robotic manipulation has broadened its boundaries for various
manipulation tasks, including cooperative manipulation tasks between humans
and robots. Many robotic arms for pHRI (physical Human-Robot Interaction) were
commercialized, such as the LBR iiwa from Kuka [1], the robotic arms from
Kinova [2], and Franka robot arms from Franka Emika [3]. These robotic arms
have force and/or torque sensors to consider safe interaction when there are
contacts or collisions with humans in the workspace. In addition to the
force/torque sensors, mechanically compliant joints and lightweight mechanisms
with high back-drivability have been investigated to ensure safe interaction.
One of the most popular approaches for the compliant joint design is having an
elastic component in the mechanism [4]. The lightweight mechanism can be
achieved by locating the heavy actuators near the robot base and utilizing a
transmission mechanism (e.g. cable-driven mechanism) for joint actuation [5,
6].

Figure 1: PAPRAS mounted in various environments using the plug-and-play
feature and executing manipulation tasks.

Despite continued achievements and efforts, robotic manipulators are not ready
for home use yet. Most existing robotic arms are not affordable (higher than
$20,000 USD) and not lightweight (more than 10kg). Additionally, they must be
bolted down to a fixed structure or need mechanical clamps to hold the base of
the robot, and it is hard to move once installed. Although the home
environment is well-segmented depending on the purposes, such as a kitchen for
cooking and a utility room for laundry, it is cumbersome and time-consuming if
the arm needs assembly and disassembly every time when moving from one place
to another. Some researchers are trying to utilize mobile manipulators [7, 8],
but these are ongoing efforts to make them compact, dexterous, and safe.

In this paper, we introduce a new robotic manipulator, PAPRAS (Plug-And-Play
Robotic Arm System), to tackle this challenge by designing a docking system
with a modular, plug-and-play robotic arm and optimizing its design. Our
primary objective was to create a pluggable, portable, and lightweight
manipulator capable of performing a variety of tasks as shown in Fig. 1. There
are several research works related to pluggable robotic limbs. Topping [9]
introduced an interesting concept of Flexibot which has the pluggable feature
to a wheelchair or a wall mount, but it has not been implemented. In modular
robot research, researchers have been working on modular, reconfigurable
limbed robots [10, 11, 12, 13]. Also, a company named GITAI recently released
large-scale pluggable robotic arms for space [14]. The proposed PAPRAS is
designed for home and human collaboration. Within this paper, we present the
design of PAPRAS and provide empirical evidence for its efficacy by showing
its applications.

The paper is organized as follows. In Sections II and III, we introduce the
hardware design of the proposed robotic arm. Section IV explains PAPRAS’s
software architecture. Validations and applications of PAPRAS are presented in
Section V. Lastly, the conclusion and future work are discussed in Section VI.

##  II Mechanical Hardware Design

(a) Table (top)

(b) Kitchen (top)

(c) Kitchen (front)

Figure 2: Visualization of workspaces. Most rectangular dinner tables are
914.4mm (36”) wide. The standard dishwasher and sink dimensions (LxWxH) are
typically 609.6x609.6x889 mm and 762x558.8x254 mm, respectively.

###  II-A Design Considerations

From the task-level point of view, the location of the robotic arm’s base in
the target task space is essential to determine the robot’s workspace. In a
manipulation task with one robotic arm, controlling the robot means moving the
relative position and orientation of its end-effector frame $\\{e\\}$, based
on the robot’s base frame $\\{b\\}$ in a world frame $\\{w\\}$. When there are
$n$ objects in the world, we can represent a set of $n$ frames as
$O=\\{\\{o_{1}\\},\\{o_{2}\\},...,\\{o_{n}\\}\\}$, where $\\{o_{k}\\}$ is the
local frame attached the $n_{th}$ object $(1\leq k\leq n)$. In most cases, the
relation between $\\{w\\}$ and $\\{b\\}$, $T_{wb}$, is fixed and given, and
the information related to $\\{o_{k}\\}$, $T_{wo_{k}}$, can be estimated
through the perception. From this information, we can get the transformation
$T_{bo_{k}}={T_{wb}}^{-1}T_{wo_{k}}$ and use it for control and planning,
considering environments and human collaborators. If the set of target objects
$O$ is bounded within a specific area, the optimal location of the robot’s
base $\\{b\\}$ to handle all the objects can be found for the target task. For
example, while manually washing dishes in a kitchen, the dishes would stay in
the kitchen sink. Or, when using a dishwasher, the positions of the kitchen
items would be bounded within a certain area including a sink and a
dishwasher. Given a robotic manipulator and kitchen information, one can find
the proper position and orientation of the robot’s base $\\{b\\}$ for this
task.

Figure 3: PAPRAS long version (top) and short version (middle) in front view, and joint configuration (bottom). Items | Specifications
---|---
Mass | Short Version: $4.771$ kg
| Long Version: $4.894$ kg
Payload | Short Version: $3$ kg
| Long Version: $2.5$ kg
Range of Motion | Joint 1: $-180^{\circ}\sim 180^{\circ}$
((): Long version) | Joint 2: $-115^{\circ}\sim 115^{\circ}$
| Joint 3: $-135^{\circ}(-45^{\circ})\sim 135^{\circ}$
| Joint 4: $-158^{\circ}\sim 158^{\circ}$
| Joint 5: $-90^{\circ}\sim 90^{\circ}$
| Joint 6: $-180^{\circ}\sim 180^{\circ}$
Max speed | Joint 1, Joint 2: $174^{\circ}/$s
(continuous) | Joint 3, Joint 4: $175.2^{\circ}/$s
| Joint 5, Joint 6: $175.2^{\circ}/$s
Max Torque | Joint 1, Joint 2: $44.7$ Nm
(continuous) | Joint 3, Joint 4: $25.3$ Nm
| Joint 5, Joint 6: $5.1$ Nm
TABLE I: Specifications

The dimensions of PAPRAS were determined considering the target task spaces,
which are the tabletop and dishwashing areas. As shown in Fig. 2, the length
of the arm’s moving part needs to be around 800-900 mm long for these tasks,
and its DoF (degree of freedom) needs to be at least 6. To meet these
requirements, PAPRAS was developed based on a 6-DoF open-source robotic arm,
OpenMANIPULATOR-P [15]. We modified its design and developed two variants of
PAPRAS in Fig. 3, one version being 100 mm longer than the other.

We define the link between Joint $n$ and Joint $(n+1)$ as Link $n$, and the
arm can be broken down into five links and six joints. The placement and
orientation of each joint are shown in Fig. 3. Joints 2, 3, and 5 are pitch
joints and their rotation axes are parallel. However, they are not in the same
plane because the position and orientation of Joint 3 have offsets. The
offsets make PAPRAS fully foldable around Joint 3. Since the shorter arm has
the same configuration of the OpenMANIPULATOR-P, detailed information can be
found in [15]. For all the joints, Dynamixel-P series motors are used. Table I
shows the specs of all the joints including the range of motion, max speed,
and torque information. An arm has a gripper with a camera at the output of
Joint 6. The gripper and camera are commercialized products, RH-P12-RN from
ROBOTIS and RealSense D435 from Intel, respectively.

###  II-B Linkage Design

For the linkage design, we aimed to reduce the overall weight of the links.
This was done to reduce the moments of inertia about the joints and thus
decrease the torques required to perform motions. As shown in Fig. 4(a), Links
1 and 4 are commercialized parts, and Links 2, 3, and 5 are 3D-printed parts.
All 3D-printed components in PAPRAS were made using two FDM printers
(Flashforge Creator 3, Raise 3D E2), and were printed using standard PLA
filament. The use of 3D-printed PLA not only reduced the weight of the
components but also allowed other features to be incorporated into the design.

(a) PAPRAS colored by parts. Motors in black, 3D-printed parts in orange,
connectors (commercialized parts) in blue, a gripper in red, and a camera in
green.

(b) An example (Link 5) of the linkage weight reduction by structure
optimization. A) initial design, B) applied constraints, C) topology
optimization, D) the resulting part.

Figure 4: PAPRAS parts break down and linkage weight reduction process.

In order to reduce the weight of the new 3D-printed links, we used the
topology optimization tool in Solidworks. This feature allowed us to
selectively remove sections from each link while simultaneously maximizing the
stiffness-to-weight ratio. To use this feature, the implementation of some
constraints was needed to get the desired output. These constraints ensured
that the parts had the desired symmetry and did not remove desired geometric
features such as faces/holes which connected with the motors. Fig. 4(b) shows
the process to get the optimized design for Link 5. We used the same process
for Link 2 and Link 3 to reduce the weight while keeping the target stiffness
we set. After each design, loads were simulated using the FEA tool in
Solidworks to test the design.

Component | MANIPULATOR-P | Short Version | Long Version
---|---|---|---
Link 2 | 644.0 g | 231.9 g | 277.4 g
Link 3 | 496.0 g | 211.6 g | 289.1 g
Link 5 | 114.0 g | 35.7 g | 35.7 g
TABLE II:  Link weight comparison

In the long version of PAPRAS, Links 2 and 3 are both $50$ mm longer than
those in a short version. In Fig. 3, the long version (top) has a more
complicated structure than the short version (middle). Link 3 of the long
version has a reinforced structure near Joint 3 to meet the stiffness
constraints. This makes Link 3 slightly heavier, and Joint 3 has a smaller
range of motion than Joint 3 in a long version.

(a) Mount with Joint 1.

(b) Mount dimensions.

(c) Male section, exploded view. A) Joint 1, B) 3D-printed wire cover, D) two
sets of 10-pin Molex connectors (male), C, E). 3D-printed parts.

(d) Female section, exploded view. A, B) rotating locking mechanism, C) body
of the socket, D) 2 sets of 10-pin Molex connectors (female), E) 3D-printed
back plate, F) custom-made PCB.

Figure 5: Docking mount.

###  II-C Docking mount

The docking mount of PAPRAS is composed of male and female sections. The male
section in Fig. 5(c) is composed of Joint 1 (a motor), along with two sets of
10-pin Molex connectors and three 3D-printed components. The female section in
Fig. 5(d) is composed of four 3D-printed components which allow for a locking
mechanism to keep the motor in place when in use. The mechanism works by
having a threaded component on the female section; when this section is
screwed in it presses itself onto the motor, securing it in place as shown in
Fig. 5(a). When it is unlocked as shown in Fig. 5(b), the arm can be unplugged
easily by pulling it out.

Four different types of these female sections were used in this paper: one for
the table demo that is made to be orientated vertically, one for the dual-arm
and cage demos that is made to orientated horizontally, with a modified
horizontal version used for the kitchen demo, and one for the quadruped demo
that is made to be orientated at an angle ($45^{\circ}$). The horizontally
orientated one is shown in Fig. 5, and all the mounts have the exact locking
mechanism.

(a) Joint 3 in unlocked position (left) and locked position (right).

(b) PAPRAS with covers attached.

Figure 6: Portability features of PAPRAS.

###  II-D Features for portability

One design goal of PAPRAS is portability. To achieve this, the weight
reduction in the previous section is important. At the same time, an easy-to-
carry design should be considered. There are two key features for this in
PAPRAS.

####  II-D1 Locking mechanism

PAPRAS is designed with a locking mechanism, which holds the arm in a closed
position when it is not in use. The mechanism is based on a rotating cam in
Link 2 which hooks onto a protrusion from Link 3. When the mechanism is in the
unlocked position it is held in place with magnets. The arm can be seen in
both locked and unlocked positions in Fig. 6(a).

####  II-D2 Covers for both ends

The gripper/camera module and Joint 1 with the connectors are located at each
end of PAPRAS. When PAPRAS is fully folded around Joint 3 and locked with the
locking mechanism, these parts lie one upon another as shown in Fig. 6(a).
Both parts are relatively feeble to impact and need to be fixed in order to
not move around Joints 2 and 5. To prevent damage and lock their positions, a
cover system was created. Two parts of the cover system were 3D-printed and a
cloth strap was used to connect the two parts. Fig. 6(b) shows a folded PAPRAS
(short version) with the camera and socket covers attached.

##  III Electrical Hardware

The electrical hardware for PAPRAS consists of three parts: the wiring harness
on each arm, the connection on each mount, and the control box for each
application.

###  III-A Arm Wiring Harness

The motors are all connected to an RS-485 serial communication bus, which is
daisy chained up the arm to each motor and the gripper. The Joint 1-4 motors
each require external power, while the Joint 5-6 motors and the gripper are
powered by the RS-485 voltage. There is also a USB-C cable that runs the
length of a PAPRAS arm to connect to a USB camera mounted on the gripper. All
these wires are routed to two 10-pin male connectors located at the base of
the arm, which mate with connectors in the mounts.

###  III-B Mount Connection

Each mount has a custom PCB (F in Fig. 5(d)) which consists of the connections
responsible for distributing power to the arm and transferring data to and
from the arm. The PCB has two 10-pin female connectors that mate with the
matching set on each arm. Of the twenty pins, four are used for the RS-485
serial communication with the motors. Eight more pins are used for the
external power connections required by the Joint 1-4 motors. The final eight
pins are used for the USB 3.1 connection between the computer in the control
box and the USB camera on the gripper. The PCB also contains connectors that
lead back to the control box – an XT connector for power, a 4-pin Molex
connector for serial communication, and a USB 3.1 Type A receptacle.

(a) Control box.

(b) Spot application.

Figure 7: Control box for a fixed PAPRAS application (a) and setup for an
untethered mobile application (b). The power source (blue), controlling
computer (green), and custom PCB (red) are highlighted.

###  III-C Control Box

Each application has a single control box regardless of how many mounts and
arms are involved. The control box contains a power supply, a controlling
computer, an RS-485 adapter (U2D2), an emergency stop, and another custom PCB.
The power supply connects to AC mains and outputs 24V DC power, which is
routed through the emergency stop switch before running to the mount(s) to
power the arm motors. The power supply also feeds a buck regulator on the PCB
(independent from the emergency stop) which outputs 19V to power the computer.
This setup allows for the e-stop to safely cut power to the arms without
dropping power to the controlling computer. The computer connects to the U2D2
over USB, which converts the USB signal into the RS-485 signal required to
interface with the motors. The serial nature of the communication protocol
allows multiple mounts to connect in parallel with a single U2D2. The computer
also can connect directly to the USB receptacle on the mount(s) to communicate
with the camera on the gripper.

For mobile applications, the power supply is replaced with a 6S LiPo battery.
The battery power is used for both the arm motors and the controlling
computer. The emergency stop switch and the communication setup are identical
to fixed applications. This change keeps the mobile platform untethered and
free to move to any location. Fig. 7 shows a control box for a fixed
application as well as the setup for a mobile application using Boston
Dynamic’s Spot.

##  IV Software Architecture

PAPRAS’s software architecture is built on an open-source framework and
optimized for low-latency multiagent-based distributed manipulator control.
Developed in C++, the architecture runs on ROS Noetic with the Ubuntu 20.04
Linux distribution. Low-level programming for motor sub-routine calls employs
the Dynamixel SDK. High-level programming of the robot, such as the planning
and perception pipelines, is accomplished through the incorporation of various
ROS packages. A breakdown of the complete flow of the software pipeline is
shown in Fig. 8, including user operation, perception, planning, control,
simulation, and hardware.

Figure 8: Overview of software architecture.

###  IV-A Global ROS Parameter Server

The Global ROS Parameter Server, shown in ⑤ of Fig. 8, is a core component of
the software architecture that stores data and settings that are shared across
all active nodes. It includes the URDF and SRDF files, a list of controllers,
hardware configurations, and joint limits. This data is used to initialize
PAPRAS demo applications and is critical for the proper functioning of the
robot. The URDF defines the environment, components and geometric structure of
the robot arms, while the SRDF assigns planning groups, poses and collision
checking information. Joint groups consist of the chain of links from the
first link to the end-effector link, and can also be broken into sub-groups.
Default poses like ‘init’, ‘rest’, ‘open’ and ‘close’ are assigned for testing
and safe positioning, and the SRDF can tweak the collision checking
information to reduce trajectory validation time.

###  IV-B User-based Operation and Monitoring

As shown in ① of Fig. 8, users can operate the system in three ways: using a
3D marker in Rviz, with joystick or keyboard inputs, or by running a command
script which contains joint angles or cartesian-based end-effector poses for
each step of a given task. The user can command robots to reach desired
configurations either by sending a command to the planning pipeline (IV-D) to
generate a valid trajectory, or alternatively by sending the command directly
to the controller manager (IV-E) to move directly to the goal position. The
process is monitored with the help of RQT and Rviz plugins which provide
debugging tools during development and validation testing.

###  IV-C Perception Pipeline

Figure 9: Visual of planned robot motion (top left), RGB (top right), point
cloud (mid left), and depth data (mid right), motion retargeting (bot left),
object pose estimation (bot right).

The perception pipeline, shown in ② of Fig. 8, is responsible for obtaining
data from the camera on the gripper of each arm, with a sampling rate of 15Hz.
Fig. 9 demonstrates the RGBD image and point cloud data of a table
environment. This data is used in various perception algorithms to give the
robot increased autonomy and decision-making capabilities. For example, the
DOPE (Deep Object Pose Estimation) algorithm can recognize objects and
estimate their 6 DoF pose [16]. This pose is recorded as a transformation from
the camera frame to the object frame, $T_{co}$. This data is used by the
pipeline to create an occupancy map, which helps the robot to build a semantic
belief state of its surroundings. Additionally, OpenPose human skeleton
tracking can be used to extract corresponding joints from the 2D image [17].
This information can then be retargeted to the robot arm. This technology is
demonstrated as a demo application in Section V-B. All of these perception
algorithms provide the robot with increased control over its environment.

###  IV-D Planning Pipeline

The planning pipeline, shown in ③ of Fig. 8, uses MoveIt to manage the
planning scene and trajectory generation. The planning scene is used to
represent the environment around the robot arms and their current state by
processing the joint states of each motor in the arm. Objects of interest can
be added to the planning scene manually or by using a 2D or 3D camera to
detect them. By using the move group interface, requests can be made to the
planning scene to move to a certain pose defined in either joint space,
cartesian space, or by an object to interact with. Goal poses must be defined
in the base frame of the arm. To calculate the goal pose for interacting with
an object, the transform $T_{co}$ found by the perception pipeline must be
transformed into the correct frame with the equation $T_{bo}=T_{bc}T_{co}$,
where $T_{bo}$ is the goal pose for the arm to interact with the object, and
$T_{bc}$ is the pose of the camera in the base frame of the arm, calculated
through the forward kinematics defined by the URDF and current joint angles.
In order to determine the correct joint angles from a given cartesian space
goal, the TRAC-IK numerical inverse kinematics solver [18] is then invoked.
The goal state is then defined in joint space and a trajectory to reach it
from the current state is found by running OMPL’s RRT-Connect planner [19,
20], taking into account any constraints that have been specified. Collision
checking is performed using FCL [21] at each time step of the trajectory to
ensure that the returned trajectory is safe. Once the trajectory has been
generated, it is sent to the controller manager (IV-E).

###  IV-E Controller Manager

The controller manager, shown in ④ of Fig. 8, provides a real-time compatible
control loop that runs a rate of 8 ms, and the infrastructure to load, unload,
start, and stop controllers. It enables controllers to access joint state
information and execute commands from a single interface. The manager is able
to read joint states from the hardware and send commands to it. The joint
position controller is utilized to send position commands to the arm’s six
joints. The joint trajectory controller is used for planned trajectory
messages, which is done with the help of its follow joint trajectory action
server. This action server allows for tracking of trajectory execution,
passing goals to the controller, and reporting success when done. The
trajectory may also be constrained or aborted if the constraints are broken.
Lastly, an effort controller is used for the grippers because current-based
position control is needed at the embedded level control.

###  IV-F Hardware and Simulation Interfaces

The hardware interface, shown in ⑥ of Fig. 8, uses the Dynamixel SDK to
communicate with the motor controllers through U2D2. Before communication is
established, the hardware configuration file is used to relate the motor IDs
to the arm configuration. This enables the hardware interface to send commands
to the correct actuators and access their parameters. During the execution of
a task, the controller manager sends velocity, position, and torque commands
to the motors. The Dynamixel SDK then applies these commands to the motors to
move them to the desired setpoints and enforce joint limits. To ensure joint
limits are not exceeded, the controller manager continuously monitors the
encoder positions of the motors, and if the setpoint is outside the joint
limits, the motor is commanded to stop.

The simulation environment Gazebo 11 is used to simulate multiple manipulators
in complex scenarios. It is loaded using environment-specific URDF files,
which contain mass, inertia, and joint configuration information. Gazebo is
bridged with ROS using the gazebo_ros_lib plugin, allowing the controller
manager to interface with the motor input and sensor output. The simulator’s
physics engine is used to validate the goal action by evaluating the plan. The
state of the virtual environment can be synchronized with the real world by
updating the simulation through the perception pipeline. As shown in the data
flow of ⑦ in Fig. 8, the robot can use the updated belief state to spawn 3D
models in simulation and planning scenes.

(a) Demo system configurations.

(b) Process to create a new demonstration.

Figure 10: PAPRAS applications.

###  IV-G Communication between Distributed Computing Units

As demonstrated in Fig. 10(a), PAPRAS uses distributed computing capabilities
to allow communication between distributed computing units. Using the master
ROS node on the main operating computer as the host machine, all other running
processes can be configured with their IP and master URI addresses for the
connection. The host machine runs the high-level and computationally heavy
nodes such as the user or AI-based task commands as well as the perception and
planning algorithms. Furthermore, multiple PAPRAS arms can be controlled from
each client machine and its movements can be synchronized with other client
machines. The main host machine used is the Lambda Dual GPU Workstation, while
the client machines are Intel NUCs composed of an Intel Core i3-10110U
processor, 16GB DDR4 RAM, and a 256GB SSD.

##  V Hardware experiments

###  V-A Validations

Hardware experiments were performed in a kitchen environment to validate the
functions and performance of PAPRAS. In Fig. 11, a docking mount (Fig. 5) and
a control box (Fig. 7(a)) were installed between the dishwasher and the
kitchen sink. The mount is located right below the kitchen top facing
perpendicular to the surface of the dishwasher door and the cabinet door, as
planned in Fig. 2. With this mount location, PAPRAS is able to reach the
objects in the sink and the bottom drawer of the dishwasher. We used a 2.27 kg
(5 lbs) dumbbell for the payload test. First, 300 hundred random poses near
the boundary of the PAPRAS workspace were selected in simulation (Fig. 11(a)).
From the 300 poses, we selected 10 poses in which the motor torques were close
to the maximum torques. A motion was planned between the 10 poses while
avoiding collisions. PAPRAS was able to track the planned motion in both
simulation and hardware experiments. Please refer to the supplementary video
to see the hardware experiment.

(a) 300 poses

(b) PAPRAS moving 5lbs payload

Figure 11: Payload check in simulation and experiments.

###  V-B Applications

PAPRAS offers a modular framework for quick and efficient implementation of
the system in various environments. Fig. 10(b) shows how to create a new
demonstration. First, a URDF file needs to be created that details the model
of the environment and the location(s) and orientation(s) of the PAPRAS
mount(s). A MoveIt package needs to be generated with appropriate inter-link
collisions disabled and planning groups set up. ROS launch and YAML
configuration files need to be created along with a YAML file outlining
desired poses and actions. Lastly, a C++ script uses the Mission Plan to
control the arms and gripper. In general, all steps are relatively
straightforward and require minimal effort. As a result, PAPRAS allows for the
rapid deployment of new demonstrations. Our system demonstrated scenarios such
as dishwashing, coffee making, dressing, and dual-arm motions in Fig. 12.

####  V-B1 Sink to Dishwasher

In the kitchen environment, the goal was to move a set of dirty dishes from
the sink to the dishwasher. To do this, we used the same setting as in the
payload test. A command script was used to perform the task of localizing and
mapping the sink, detecting objects, estimating each item’s pose, choosing the
most cost-efficient object to pick, picking an object from the sink, moving
the object to the dishwasher, and placing the object in the dishwasher.

Figure 12: Execution of coffee making, quadruped, cage, and dual arm demos.
Figure 13: Visualization of cage with collision box.

####  V-B2 Coffee Making

For our coffee-making demonstration, we made a dinner table with three arm
mounts in Fig. 2(a) and used a cup, an electric kettle, a pour-over coffee
cone, and ground coffee. Our command script runs the two stages of the demo
task which consists of pouring periodically from the kettle into the pour-over
coffee cone, then serving the coffee into a cup without spilling.

####  V-B3 Quadruped

PAPRAS can also be extended to mobile robots, such as Spot. In this
application, two arm mounts were attached to the front end of Spot to pick and
place objects between the table and sink, where mobility is needed. A command
script coordinates arm control operations with mobile navigation while
communicating with the Spot SDK.

####  V-B4 Cage

In the cage demo, four arm mounts were placed on the four vertical beams of
the suit-up environment. Here, all four arms were simultaneously controlled by
a single client computer to assist the subject with putting on a jacket. The
task planning pipeline starts with the back arms holding the end sleeves,
bringing the jacket forward for the two front arms, helping the subject step
in, and finally bringing down the jacket as the back arms go back to the rest
position. This setup enables automated dressing while ensuring safety with
real-time multi-agent motion planning. The estimated collision box of the
subject seen in Fig. 13 was used to ensure that the arms always avoid contact
with the user.

####  V-B5 Dual Arm

The dual arm demo showcases the potential of human-robot interaction and
collaboration in real-world scenarios. The platform is built with a single
stand, two arm mounts, and a client computer. A camera records the motion of a
lead demonstrator, and OpenPose human skeleton tracking is used to directly
map the joint angle values from the human to the robot. The mapping is sent as
raw action commands to the joint trajectory controller. In addition to the HRI
aspect, the dual arm highlights the group communication capabilities between
distributed systems. We enable synchronized control of multiple dual arm
stands by connecting each client machine to the host machine, as described in
IV-G. This communication allows the movements of each robotic arm to be
synchronized with other client machines, creating a highly coordinated
display.

##  VI Conclusion and Future Work

This paper presented PAPRAS, a pluggable robotic arm system for home and
human-robot collaboration. By analyzing the target task spaces and utilizing
3D printing and structure optimization, we were able to accomplish the
lightweight and high-payload arm design. A locking mechanism was embedded in
PAPRAS for better portability and a docking mount was implemented for the
plug-and-play function. We built the PAPRAS software architecture based on an
open-source framework and optimized for low-latency multiagent-based
distributed manipulator control. To show PAPRAS’s ease of use and efficiency,
we developed a process to create new demonstrations. Simulations and hardware
experiments were conducted in various demonstrations to validate the hardware
and software design. PAPRAS successfully performed sink-to-dishwasher
manipulation, coffee making, mobile manipulation on Spot, and suit-up demo.

For future work, we will keep creating more applications in human
environments. Furniture, home appliances, and other types of mobile base
robots are potential applications of PAPRAS. Furthermore, we are planning to
optimize the workspace of PAPRAS based on the 3D data from the target task. As
stated in Section II-A, collecting spatial data, such as trajectories of the
objects in 3D space, is important for the robot to do the task. For this, we
will collect the trajectories of the objects and human motions using a motion
capture system. From this data, we can get the possible end-effector
trajectories for the sequential movements. It will be an interesting design
optimization problem to solve various target tasks by optimizing the number of
arms, the locations of the mounts, as well as the trajectories of the objects.
Computational co-optimization methods, such as [22], can be used to find
design parameters and motion trajectories for the robotic system at the same
time.

## References

  * [1] R. Bischoff, J. Kurth, G. Schreiber, R. Koeppe, A. Albu-Schaeffer, A. Beyer, O. Eiberger, S. Haddadin, A. Stemmer, G. Grunwald, and G. Hirzinger, “The kuka-dlr lightweight robot arm - a new reference platform for robotics research and manufacturing,” in _ISR 2010 (41st International Symposium on Robotics) and ROBOTIK 2010 (6th German Conference on Robotics)_ , 2010, pp. 1–8.
  * [2] “Kinova,” https://www.kinovarobotics.com/, accessed: 2023-01-15.
  * [3] S. Haddadin, S. Parusel, L. Johannsmeier, S. Golz, S. Gabl, F. Walch, M. Sabaghian, C. Jähne, L. Hausperger, and S. Haddadin, “The franka emika robot: A reference platform for robotics research and education,” _IEEE Robotics & Automation Magazine_, vol. 29, no. 2, pp. 46–64, 2022.
  * [4] G. Pratt and M. Williamson, “Series elastic actuators,” in _Proceedings 1995 IEEE/RSJ International Conference on Intelligent Robots and Systems. Human Robot Interaction and Cooperative Robots_ , vol. 1, 1995, pp. 399–406 vol.1.
  * [5] K. Salisbury, W. Townsend, B. Ebrman, and D. DiPietro, “Preliminary design of a whole-arm manipulation system (wams),” in _Proceedings. 1988 IEEE International Conference on Robotics and Automation_ , 1988, pp. 254–260 vol.1.
  * [6] Y.-J. Kim, “Anthropomorphic low-inertia high-stiffness manipulator for high-speed safe interaction,” _IEEE Transactions on Robotics_ , vol. 33, no. 6, pp. 1358–1374, 2017.
  * [7] T. Yamamoto, K. Terada, A. Ochiai, F. Saito, Y. Asahara, and K. Murase, “Development of human support robot as the research platform of a domestic mobile manipulator,” _ROBOMECH Journal_ , 2019.
  * [8] C. C. Kemp, A. Edsinger, H. M. Clever, and B. Matulevich, “The design of stretch: A compact, lightweight mobile manipulator for indoor human environments,” in _2022 International Conference on Robotics and Automation (ICRA)_ , 2022, pp. 3150–3157.
  * [9] M. Topping, “Flexibot – a multi‐functional general purpose service robot,” _Industrial Robot-an International Journal_ , vol. 28, pp. 395–401, 2001.
  * [10] J. Kim, A. Alspach, and K. Yamane, “Snapbot: A reconfigurable legged robot,” in _2017 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS)_ , 2017, pp. 5861–5867.
  * [11] K. G. Gim and J. Kim, “Snapbot v2: a reconfigurable legged robot with a camera for self configuration recognition,” in _2020 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS)_ , 2020, pp. 4026–4031.
  * [12] J. Hu, J. Whitman, M. Travers, and H. Choset, “Modular robot design optimization with generative adversarial networks,” in _2022 International Conference on Robotics and Automation (ICRA)_ , 2022, pp. 4282–4288.
  * [13] T. Zhu, G. I. Fernandez, C. Togashi, Y. Liu, and D. Hong, “Feasibility study of limms, a multi-agent modular robotic delivery system with various locomotion and manipulation modes,” in _2022 19th International Conference on Ubiquitous Robots (UR)_ , 2022, pp. 30–37.
  * [14] “Gitai,” https://gitai.tech/, accessed: 2023-01-15.
  * [15] ROBOTIS, “Robotis openmanipulator-p.” [Online]. Available: https://emanual.robotis.com/docs/en/platform/openmanipulator_p/overview/
  * [16] J. Tremblay, T. To, B. Sundaralingam, Y. Xiang, D. Fox, and S. Birchfield, “Deep object pose estimation for semantic robotic grasping of household objects,” in _Conference on Robot Learning (CoRL)_ , 2018. [Online]. Available: https://arxiv.org/abs/1809.10790
  * [17] Z. Cao, G. Hidalgo Martinez, T. Simon, S. Wei, and Y. A. Sheikh, “Openpose: Realtime multi-person 2d pose estimation using part affinity fields,” _IEEE Transactions on Pattern Analysis and Machine Intelligence_ , 2019.
  * [18] P. Beeson and B. Ames, “Trac-ik: An open-source library for improved solving of generic inverse kinematics,” in _2015 IEEE-RAS 15th International Conference on Humanoid Robots (Humanoids)_ , 2015, pp. 928–935.
  * [19] I. A. Şucan, M. Moll, and L. E. Kavraki, “The Open Motion Planning Library,” _IEEE Robotics & Automation Magazine_, vol. 19, no. 4, pp. 72–82, December 2012, https://ompl.kavrakilab.org.
  * [20] J. Kuffner and S. LaValle, “Rrt-connect: An efficient approach to single-query path planning,” in _Proceedings 2000 ICRA. Millennium Conference. IEEE International Conference on Robotics and Automation. Symposia Proceedings (Cat. No.00CH37065)_ , vol. 2, 2000, pp. 995–1001 vol.2.
  * [21] J. Pan, S. Chitta, and D. Manocha, “Fcl: A general purpose library for collision and proximity queries,” in _2012 IEEE International Conference on Robotics and Automation_ , 2012, pp. 3859–3866.
  * [22] S. Ha, S. Coros, A. Alspach, J. Kim, and K. Yamane, “Computational co-optimization of design parameters and motion trajectories for robotic systems,” _The International Journal of Robotics Research_ , vol. 37, no. 13-14, pp. 1521–1536, 2018. [Online]. Available: https://doi.org/10.1177/0278364918771172