J Intell Robot Syst

DOI 10.1007/s10846-011-9626-9

TORP: The Open Robot Project

A Framework for Module-Based Robots
Alexandre da Silva Simes Esther Luna Colombini
Jackson Paul Matsuura Marcelo Nicoletti Franchin

Received: 17 December 2010 / Accepted: 25 July 2011

Springer Science+Business Media B.V. 2011

Abstract The development of robots has shown

itself as a very complex interdisciplinary research
field. The predominant procedure for these developments in the last decades is based on the
assumption that each robot is a fully personalized
project, with the direct embedding of hardware
and software technologies in robot parts with no
level of abstraction. Although this methodology
has brought countless benefits to the robotics research, on the other hand, it has imposed major
drawbacks: (i) the difficulty to reuse hardware
and software parts in new robots or new versions;

A. S. Simes (B)
Department of Control and Automation Engineering,
UNESP - Univ Estadual Paulista,
Campus of Sorocaba, Sorocaba, Brazil
e-mail: assimoes@sorocaba.unesp.br

(ii) the difficulty to compare performance of different robots parts; and (iii) the difficulty to
adapt development needsin hardware and software levelsto local groups expertise. Large advances might be reached, for example, if physical
parts of a robot could be reused in a different
robot constructed with other technologies by
other researcher or group. This paper proposes a
framework for robots, TORP (The Open Robot
Project), that aims to put forward a standardization in all dimensions (electrical, mechanical and
computational) of a robot shared development
model. This architecture is based on the dissociation between the robot and its parts, and between
the robot parts and their technologies. In this paper, the first specification for a TORP family and
the first humanoid robot constructed following the
TORP specification set are presented, as well as
the advances proposed for their improvement.

M. N. Franchin
Department of Electrical Engineering,
UNESP - Univ Estadual Paulista,
Campus of Bauru, Bauru, Brazil
e-mail: franchin@feb.unesp.br

Keywords Module-based robots

Robotics design framework
Collaborative robots Open Robot Project
Standardization in robotics

E. L. Colombini J. P. Matsuura
ITA - Technological Institute of Aeronautics,
Sao Jose dos Campos, Brazil

1 Introduction

E. L. Colombini
e-mail: esther@ita.br
J. P. Matsuura
e-mail: jackson@ita.br

In the last decades, there has been some important standardization in several areas of computation and automation. However, we are far from

J Intell Robot Syst

this level of standardization in the robotics field.

Robotics today is close to what were PCs in the
late 70s. As it happened to the PCs, the robotics
labs and researchers around the world are facing
exactly the same challenges: high fragmentation,
lack of standardization, complex projects without
established methodologies, lack of practical applications and slow development. Indeed, it is almost
unthinkable nowadays that some part of a robot
can be plugged and work properly in another one,
and this scenario is even worse when considering
human-size robots.
There are some different reasons for this poor
standardization level. First of all, robots are built
with extremely different purposes, that have deep
impact in their architecture. It is unlikely, for
example, that a robot designed to load weight can
have the same physical architecture of a robot
for playing music, even if both are humanoids.
Other contributing factor is that some of the most
important robotics developments are fomented
by private institutions, that are usually restrict
on sharing technical information and accepting
standardization from external institutions. Yet,
robotics operating systems are recently new and
have a low number of users. In some cases these
frameworks also impose some technology constraints to the developers. In fact, the expertise of
different groups in using some kind of hardware or
software technology guides their technical choices
in new projects. Standardization that cannot properly handle with this diversity is doomed to
failure.
As a consequence of this scenario, most of the
new projects must restart almost from scratch,
what limits the knowledge sharing between research centers. However, a change is expected in
the next years. The rush for better robots and
for a speed up in robotics developments is turning mandatory the sharing of expertise among
different groups in the fields necessary to develop
a full robot. A new kind of collaborative research
and development could make possible to use this
expertise diversity, necessary in this interdisciplinary task.
In this way, a framework for this kind of development would require: (i) standardization in electrical and mechanical dimensions that allow the
interchangeability of robot parts with flexibility in

technologies; and (ii) availability of software tools,

like graphical interfaces, robotics optimized routines, network communication framework, sensor
data transfer, and so on.
This paper presents the TORP (The Open
Robot Project) framework, an open standard
methodology for modular robots design that aims
to fulfill some of the gaps earlier presented. This
paper is organized as follows: Section 2 provides
an overview of the available robotics frameworks
in several aspects, presenting a general scheme
of these methodologies in order to establish future directions of these technologies. Section 3
presents an overview of the TORP specification
set. Section 4.2 shows examples of TORP applications, detailing the main features of CP01, the
first robot built using TORP methodology while
Section 5 presents some results achieved. Finally,
Section 6 concludes with an assessment of the
results and proposes directions for further investigation and improvements in the framework.

2 Robotics Frameworks: Overview

and Future Directions
Different methodologies have been proposed for
robotic developments in the last decades. The
most common methodology, adopted since the
early days of robotics, tends to focus on sensors
and actuators assembly directly linked with a controller device. In the electrical dimension, power
source is regulated and appropriate voltages are
transferred to sensors, actuators and controller
through a set of cables. Mechanically, devices tend
to be all connected to a robot chassis. Computationally, the main control is located in a personal computer or an embedded device, and there
is usually a low level of separation in software
layers [18]. A schematic diagram of this project
methodology is shown in Fig. 1a. Although many
advances have been possible with this methodology, it has well known limitations in terms of
hardware and software reuse, collaborative development and excessive technology-dependence.
Specially focusing on software reuse, several
frameworks have arisen in the past years. In general lines, these frameworks are cross-platform

J Intell Robot Syst

Fig. 1 Robotics
frameworks general
scheme. a The most
common robotics
framework: low level of
separation between
software layers, electrical
and mechanical devices.
b General scheme of the
robotics operational
systems approach that
arose in the last decade: a
software abstraction level
aims to assure some
independence degree
between code and
devices. Electrical and
mechanical devices
remain with a low
independence level

(a)

open-source environments that operate over some

operational system layer. Most of them, like
PLAYER [7, 23], OROCOS [6], YARP [14] and
CLARATY [20, 30] focus in architectures able
to provide modularity and separation between robotics application code and low level code (memory allocation, threads, communication, etc.).
ORCA [5] proposes a component-based software
approach. Although device drivers for these platforms are not yet available for manufacturers, it
is a growing trend. In communication level, several frameworks also assume a network structure
with central servers, like CARMEN [17], or heterogeneous networks, like ROS [21], Tekkotsu
[29] and Urbi [3, 4]. Some frameworks also propose valuable application level tools and libraries
for robotics domains, like kinematics calculation
tools [6], centralized parameter server [21], image
libraries [14], localization and mapping [21] and so
on. Figure 1b presents a general scheme of these
frameworks.
Although these computational frameworks
represent a complete rupture with previous robot
projects methodologies much more appropriate
for complex developments than the traditional
approach, some important questions remain still

(b)

open. In general lines robot technologies continue to be chosen based on a specific project
philosophy and needs. The excessive intertwine
and mutual dependence between a robot and its
technologies leads to some particular problems:
(i) hardware reuse in different robots or in different versions of the same robot is unthinkable
for fully assembled parts, and is limited to changes
in components level; (ii) technological sharing between different research groups is difficult, since
each group tends to work based on different
technologies; and (iii) performance comparison
between analogue high level parts of different
robots is almost impossible since the parts performance are completely dependent on the whole
robot set. In fact, it is important to remark that
computationmajor concern of today robotics
frameworksrepresents only one of the three robotics dimensions, and quicker developments in
the robotics field could be reached if a framework
would also consider some electrical and mechanical standardization, as technology independent as
possible.
As a next step on the robotics frameworks
discussion, one can hypothesize that a more
useful framework for robotics development and

J Intell Robot Syst

research could be reached based on the following

principles:
1. Project paradigm is shifted from components
level to functional self-contained modules
level;
2. Modules are externally standardized in three
dimensions: electrical, mechanical and computational, but are internally technologyindependent;
3. Main controller may operate remotely according to previous robotics operating systems
principles.
It is important to remark that this set of principles keeps strong relation with those adopted
in PCs, since technologies changes in components
level no longer affect computers functionalities
due to electrical and mechanical standardization
in data buses, plugs and power sources.
Two other concepts are important to overcome
the compatibility issues in the design of the robots.
First, collaborative development is usually associated to the open-source development, that
is, developments where knowledge is publicly
shared as open-software and/or open-hardware.
E-puck robot [16] is a desktop-size open-software
and open-hardware differential wheeled mobile
robot designed for micro-engineering education.
Molecube [34] are modular-based open-software
and open-hardware low-cost cube robots envisioned as a universal element in order to build
more complex structures, as an alternative to a
variety of specialized machines.1 One of the most
recent robots in this line is the PR2 [32], a generalpurpose wheeled robot platform with two arms,
head and gripers that can serve as a base for
further development in robotics. This project incorporates some of the new strategies of robotics,
like the open-source in hardware and software,
and is fully-integrated with ROS software libraries
[22]. By eliminating the need to first build a
hardware system and then re-implement code,
the PR2 allows software experts to immediately

1 In

the context of projects hereby presented, openhardware refers to a basic hardware electromechanical
publishing, and not a collaboratively constructed hardware.

create new functionality on the robot. It also stimulates groups to build new parts of the robot, like
grippers, and to develop open-source software.
Although it is an extremely flexible and an up
to date platform, it does not allow some studies,
like for legged systems, since the pre-designed
platform naturally imposes several constraints in
the robot physical structure.
Another important growing tendency is reconfigurable robotics [33], term usually related
to the possibility of multiple mechanical configurations of robot modules through mechanical
connections. It is usually based on the existence
of some kind of mechanical standard plug. In [8]
modules can be connected or disconnected manually, and by adding and removing the modules
one can build a robotic fish with different morphologies. In [26, 27] reconfiguration is carried out
through dynamic connection and disconnection of
modules and rotation of their DOF, which are
applied over adaptive furniture. For [12], flexible
tiles are interconnected by magnets and communicate using infra-red. It is used to engage and
motivate user to perform physical activities in
hospitals, whereas [2] uses passive lockable cylindrical joints to permit changing kinematic parameters in robotic manipulators. An interesting
combination of electrical and mechanical plug was
proposed in Molecube [35]. Due to a unified interface, since a robot cube is mechanically connected
to a next cube, they are also electrically plugged.
Although universal mechanical plugs have not
been proposed for high-size humanoid robotics,
this idea must be taken into consideration.
2.1 Humanoid Robot Projects
and Related Approaches
As an example to expose the problems concerned
with a robot design, an analysis of humanoid robot
projects will be presented.
Some important projects of humanoid robots
have been highlighted in recent robotics history,
many of them correlated with the present work
in several aspects. Some well known humanoid
projects are ASIMO [24], HRP-2 [10, 11], HUBO
[9] and REEM-B [25]. In order to perform human
like actions, it is natural to expect that humanoid

J Intell Robot Syst

robots approximate humans in several aspects like

size, mass, torque, velocity and so on. Considering
constructive aspects, these robots vary from 30
[24] to 66 [9] DOF, are from 1.2 to 1.5 m tall and
capable to walk up to 6 km/h. As shown in Table 1,
one can say that todays robots power is the same
order of magnitude as human muscle power [19,
25], although these robots are smaller and slower
than humans, and have a worst power/weight relation in actuators (150 W/kg of todays motors [13]
against 500 W/kg of human muscles [31]).
Considering the increasing complexity of humanoid robotics developments, it is more and
more unlikely that a single research center can be
capable of developing the whole chain of needs
required by such a complex project. In fact, robots development paradigm seems evolving from
centralized developments to a collaborative approach. One of the most important platforms in
this paradigm is iCub [15], project funded by the
European Commission that aims to study cognition through the implementation of a humanoid
robot the size of a 3.5 year old child, through the
RobotCub framework. Some of the RoboCubs
partners adopt the YARP open-source library
[14]. Although it is a collaborative robotics project, collaboration in RobotCub is mainly focused on computational developments for robot
cognition based on a predefined hardware.
Regarding the mechanical aspects of a robotics
project, one of the trends is the research of universal and flexible connectors. Some of the desired
characteristics of a standard mechanical plug are:
(i) the ability to quick plug with no need of extra

Table 1 Power, speed and torque requirements in human

degrees of freedom, excluding head, hands and feet, versus
humanoid robot actuators power
Joint

Shoulder
Elbow
Wrist
Hip
Knee
Ankle
Estimated

Human

Hubo

Peak power
(W)

Velocity
(rpm)

Torque
(N.m)

Robot
(W)

110
110
30
600
600
50
3.000

350
150
150
300
150
150

70
40
20
140
160
110

270
90
22
330
300
180
2.384

tools; (ii) it must be unique or keep compatibility

with all similar connections in robot, independent
on its size or mechanical requirements; and (iii)
it must be robust in terms of mechanical efforts
(looseness, torque, rotation, etc.). These are absolutely nontrivial goals considering humanoid robots mechanical characteristics.
It can be observed that there must be a standardization in all three dimensions (electrical,
mechanical and computational) to enable cooperative and collaborative design and implementation of complex humanoid robot projects. The
TORP specification set could be a solution.

3 The Open Robot Project Framework

TORP is a framework, ruled by GNU General
Public License (GPL), to build robots that follow
a common philosophy in their design: the TORP
Specification Set.
Shifting from the components level, usually
proposed by traditional robotics frameworks
(Fig. 1a and b), to the functional level, a TORP
robot is a collection of independent, replaceable
and specialized parts (modules) that are as selfcontained as possible and that jointly produce
an artificial creature. For example, consider an
arm of a humanoid robot. In a TORP robot, all
the mechanics, electrical devices and processing
units necessary to assure that this robot arm can
execute its functions must be fully contained in
the very robot arm. Furthermore, the robot can
be seen as a communication network that hosts
a society of mechanically-electrically independent
parts. All these parts are responsible for collecting information (internal and external) that can
be important to perform its own tasks and for
offering all its services to the robot network. In
order to assure that these parts can be capable to
suitably and harmonically cooperate to produce a
more complex entity, some electrical, mechanical,
computational and communication requirements
(the TORP Specification Set) must be simultaneously respected by all families of TORP robots. A
TORP family is defined as a set of modules that
share the same values for all dimensions in the
TORP specification set.

J Intell Robot Syst

3.1 TORP Specifications Set

specification seen in Fig. 2b determines that there

is a common power source for the modules and
that each one is responsible for regulating the
power to meet the modules components needs. A
standard electrical plug is used for all modules. Finally, the mechanical dimension (Fig. 2c) presents
the modules connected to the main chassis or
to each other through a standard plug. The next
subsections describe details on each dimension.

The framework proposed in this paper follows

the schematics of Fig. 2. In this model, three dimensions are considered to fully describe a robot project: the mechanical, the electrical and the
computational dimension. In the computational
dimension (Fig. 2a) it is stated that all modules
are responsible for containing the knowledge on
how to control its parts according to the chosen
components. The only restriction in this model
refers to the fact that all modules have to speak
a common protocol, defined in Section 3.4.1, and
that they have to communicate through a network. There is no restriction whether the main
controller should be embedded or not. Hence,
a Robotics Operating System could be used to
properly deal with the modules coordination, as
well as a Graphics User Interface. The electrical

(a)
Fig. 2 TORP framework general scheme, with focus on
fully self-contained modules. a Computational architecture. Modules interact in a network with a high level main
control. Drivers and low level processing are fully embedded in module. b Electrical architecture. Each module

3.2 Mechanical Dimension

The main concept in the mechanical dimension
is the module. Each module must be chosen according to its typical function and it must be
completely independent on the other modules.
In a humanoid robot, for example, the following modules would be recommended: head, chest,
legs, arms, hands. However, a robot designer is

(b)

(c)
is responsible for internal voltage regulation for its own
needs and it can provide electrical connection to other
modules. c Mechanical architecture. Modules can be connected to main chassis or other modules using a quick
connect standard mechanical plug

J Intell Robot Syst

free to use any number or type of modules and

these modules can change over time. For instance,
a project of a humanoid robot that has a single
module arm that contemplates the hand can be
replaced, in a new version, by two separate modules: arm and hand. The modules are encouraged
to keep all its elements (mechanical, electrical,
computational and communication) inside of its
own mechanical structure, allowing a quick and
easy handle of the module. In the same direction,
modules must have a structural rigid material able
to properly attach all its internal units, except in
the case of the internal module, which is allowed
to plug its sensors, actuators and/or wires in the
external module.
To allow connections between modules, a
TORP mechanical plug (TMP) must be defined.
In this way, modules cannot be connected to
other modules except by using standard mechanical plugs. This practice assures that any module
will be able to physically connect into any TORP
robot, part or version of that specific family. The
TMP should meet the family project needs. Furthermore, since modules can be plugged in complex ways, there must be a classification of these
connections types.
In this framework, a module must be classified
according to the following:
1. Connection with previous module: Defines
how the current module connects to previous
modules. There are two possibilities:
(a) External: the module (A) is physically
connected to a previous module (B) using the TMP, and A is physically external to B;
(b) Internal: the module (A) is fully internal to the previous module (B). Internal
modules do not need to be connected
using the TMP. This is allowed only to
extremely simple and light modules (typically those that have only an electrical
board connected to some special sensor
without any mechanics and so on). In this
case, the connection between modules
can be made through screws.
2. Connection with next modules: Defines the
number of modules that can be connected to

the current module and how this connection

occurs. Following this specification, the current
module can be classified in two different ways:
(a) Expansible of order N: this module offers N TMPs that can be used by other
modules;
(b) Terminal: this module does not provide
TMP connections to other modules.
The modules and TMPs must carry precise
information regarding some special features that
should physically be written in their structure:
1. TMP label: any material can be used to construct the TMP. However, different materials
imply in different mechanical properties, and,
hence, the maximum number of allowed connected modules depends on the mechanical
plug material. In this way, TMPs must carry
the maximum load (N) and torque (N.m) that
can be supported by this mechanical plug.
2. Module label: every single module must carry
precise information (physically written in the
module) regarding its own load (in N), length
(in m) and degrees of freedom. This information can be used to control the module.
3.3 Electrical Dimension
Although standardization is proposed in the electrical dimension, there are no constraints for the
electronic boards or on-board software used by
the modules. Instead, only a common protocol is
established, and the implementation technology is
completely free. There is a main power source,
used by all modules and each module is responsible both for re-configuring the power to meet its
own needs as well as for by-passing the original
power to the next module connected to it, if there
is such module.
In this way, each single module is electrically
independent on the others and they should be
classified according to:

Module type: according to the electrical role

that it plays in the system, a module must
belong to one of these electrical patterns:

Expansible of order N: this module receives electrical energy from other modules,

J Intell Robot Syst

and will provide electrical connection with

the original power to N other modules
(that must be mechanically connected
to it)
Terminal: this module receives electrical energy from other modules, but does
not provide electrical connection to other
modules
Initial: this module will transfer electrical
energy from the power source to other
modules. In this case, it will also be expansible of order N.

In order to respect the independence of each

module, some other important characteristics
must be considered:

Standard electrical plug: there should be a

standard plug as the only allowed electrical
connection for modules.
Allowed electrical connections: each module
is allowed to connect only to the plug provided
by the immediately previous module, and it
must provide a fully functional electric plug
to the next module(s), except in the case of a
terminal type module;
Power: the maximum power available to the
robot has to be specified in the family project
and cannot be exceeded;
Voltage: all robot modules will receive the
same standard voltage, determined according
to the family robot design. The module must
internally transform this voltage according to
its own needs;
Current: the maximum allowed current for
the whole robot is set in the family project.
Since an expansible type module can be connected to an unknown number of other modules, all expansible module wires must be
dimensioned to attend the whole robot electrical requirement. Terminal type modules wires
can be dimensioned according to their own
needs.
Visual identification: The module current consumption must be clearly identified (physically written) in the module in order to allow
people to visually inspect and evaluate the
possible insertion of this module in the main
robot (composed by other modules) while replacing robot parts;

Wires and cables position: the allowed positions of modules wires and cables will depend
on the type of the physical position of the
module in the robot (see Section 3.2). For
connected modules all wires and cables (and
also modules sensors and actuators) must mechanically fit the robot module. As for internal modules, if a module A is internal to a
module B, some of the A modules sensors,
actuators and wires are allowed to be external
to the module A. In this case, all wires (and
also sensors and actuators) of module A must
mechanically fit module B.

3.4 Computational Dimension

In the TORP structure, a robot is a set of nodes
in a network. Hence, each single robot module
carries its own computational unit that has no
limitation on the technology besides the fact that
it has to connect to other modules through a
common network protocol, defined for the project
family. Although all kinds of computer boards or
microprocessors boards can be used, the following
requirements must be respected:
1. Position: the computational unit must physically fit the module. There is an exception for
the main controller, that can be embedded in
the robot or not;
2. Functionality: the computational unit must be
able to fully control all module sensors and
actuators;
3. Communication capability: the computational
unit must be able to communicate with other
modules according to the TORP communication protocol;
4. Alone/network use: the module must be able
to work in the robot network as well as
in a stand-alone mode (without the other
modules);
5. Services: the computational unit must provide
services to the robot network, that can be
used by other instances and unities. These
services are regulated by the communication
protocol;
6. Internal states and monitoring: the computational unit must be able to provide, at all time,
full information regarding the module, that is,

J Intell Robot Syst

an up to date table of its proprioceptive and

exteroceptive information. In other words, the
module must keep up to date internal states
with information continuously obtained from
its sensors and actuators, as well as monitoring
status information (board temperature, module inclination, etc.).
The coordination of the set of modules, hereby
called the main controller, can be represented as
a device embedded in the robot in one of its
modules or as a device remotely linked to the
robot through the network. It is important to
remark that the communication protocol is technology independent and it is implemented over
a network protocol defined for a specific TORP
family.
3.4.1 Communication Protocol
In order to allow the communication among the
modules, a communication protocol was established. This protocol considers that the TORP
modules communicate among them according to
the network structure presented in Fig. 3. In this
structure, each module with its native processor
unit is linked to the others through a network
such as Ethernet, CAN, etc. The controller presented can be a module in the robot or an external

Fig. 3 Different network

configurations for a
TORP family.
Left Architecture with an
external non-embedded
controller running over
Ethernet. (Center)
Architecture with an
external non-embedded
controller running over
CAN. Right Architecture
with internal embedded
controller running over
Ethernet

computer that will run as the main coordinator

of the system. In the protocol, every time a new
module is plugged into the system it has to be
registered in the network. Then, a connection to
the main controller is established and data can be
sent following the TORP protocol.
There are seven types of messages that can be
communicated: CHECKIN, ACTION, GETSTATUS, STATUS, SETCONF, CONF and CHECKOUT. Each one of these messages exchange
information between the modules and the main
controller. A set of messages sent to/from a module should be enough to return all information
required and to perform all actions for that module. Every message should end with a ENTER
character.
1. CHECKIN message: this message is sent by
the module when it is plugged in the network.
Its structure is: CHECKIN [MODULE name]
[IP value PORT n] [TYPE type(EXPANSIBLE/TERMINAL)] [SONS n(used only for
expansible)] [FATHER moduleName] [TMP
id POS x,y,z] [TMP idn POS x,y,z] [MOUNT
n] [MAXCURRENT value(float)] [VOLUME v] [MASS m] [CG cg] [IX ix] [KX kx]
[SENSOR type NAME n POS x,y,z] ... [SENSOR typen NAME n POS x,y,z] [ACTUATOR type NAME n POS x,y,z DIR x,y,z] ...

J Intell Robot Syst

[ACTUATOR typen NAME n POS x,y,z

DIR x,y,z] where:

MODULEthe module name

TYPEthe module type: expansible or
terminal
SONSthe module maximum number
of sons
FATHERthe module in which the current module is mounted
TMPnthe id and position of the standard mechanical plug in the module
MOUNTid of the fathers standard plug
where the module is connected
MAXCURRENTthe maximum current
required by the module in A
VOLUMEthe volume of the module
(mm3)
MASSthe mass of the module (kg)
CGthe gravity center of the module
IXthe moment of inertia of the module
KXspin radius
SENSORthe list of sensors with the
quantity of each sensor present in the
module and their relative position to
the standard plug of the module
ACTUATORthe list of actuators with
the quantity of each one present in the
module and their relative position to the
standard plug of the module

2. ACTION message: this message is sent by

the main controller to the module any time
it needs an action to be performed by the
existing actuators. Every action message returns an OK message (zero) or an ERROR
message (non-zero). There are many action
messages possible, according to the actuators
registered in the system, and others can be
added without any loss in the protocol. The
following ACTION messages were designed
by abstracting the most important features of
the common actuators used in robotics.

ACTION [MOVE MOTORTYPE] [NAME

id] [DEGREES n]... [NAME id] [DEGREES n]
ACTION [MOVE MOTORTYPE] [NAME
id] [DEGREES n] [SPEED s] ... [NAME
idn] [DEGREES nn] [SPEED sn]

ACTION [MOVE MOTORTYPE] [NAME

id] [DEGREES n] [TIME t] ... [NAME
idn] [DEGREES nn] [TIME tn]
ACTION [STOP MOTORTYPE] [NAME
id] ... [NAME idn]
ACTION [TORQUE MOTORTYPE]
[NAME id] [VALUE ON/OFF] ... [NAME
idn] [VALUE ON/OFF]
ACTION [LED MOTORTYPE] [NAME
id] [VALUE ON/OFF] ... [NAME id]
[VALUE ON/OFF]
ACTION [DISPLAY IMAGEDEVICE]
[NAME id] [IMAGE name] ... [NAME
idn] [IMAGE namen]
ACTION [CLEAR IMAGEDEVICE]
[NAME id] ... [NAME idn]
ACTION [PLAY IMAGEDEVICE]
[NAME id] [Video name] ... [NAME idn]
[Video namen
ACTION [PAINT LEDRGB] [NAME id]
[VALUE R,G,B]... [NAME idn] [VALUE
R,G,B]
ACTION [CLEAR LEDRGB] [NAME
id] ... [NAME idn]
ACTION [SOUNDON/OFF SPEAKER]
[NAME id] ... [SOUNDON/OFF SPEAKER] [NAME id]
ACTION [PLAY SPEAKER] [NAME id]
[VALUE ...] ... [NAME id] [VALUE ...]
ACTION [PLAYFILE SPEAKER] [NAME
id] [VALUE FILENAME] ... [NAME id]
[VALUE FILENAME]

3. GETSTATUS message: this message is sent

by the main controller to a sensor in order
to acquire information regarding its readings.
The GETSTATUS message is followed by an
STATUS message from the module containing the required information.

GETSTATUS [SENSOR type] [NAME

id] ... [SENSOR typen] [NAME idn]

4. STATUS message: this message is sent by a

sensor or actuator that contains sensors to
the controller any time a GETSTATUS message is received. The current list of sensors
registered is formed by: gps, sonar, infra-red,
touch, compass, accelerometer, force, temperature, camera, microphone. There is also the

J Intell Robot Syst

possibility of having the sensors from the motors sending their status. Additional sensors
can be included in the list.

GpsSTATUS [SENSOR GPS] [NAME

id] [DATA n,n]
SonarSTATUS [SENSOR SONAR]
[NAME id] [DATA distance]
IRSTATUS [SENSOR IR] [NAME id]
[DATA distance]
TouchSTATUS [SENSOR TOUCH]
[NAME id] [DATA status(PRESSED/
FREE)]
CompassSTATUS [SENSOR COMPASS] [NAME id] [DATA]
AccelerometerSTATUS [SENSOR ACCELEROMETER] [NAME id] [AXES n]
[Data x,y,z]
ForceSTATUS [SENSOR FORCE]
[NAME id] [DATA value]
TemperatureSTATUS [SENSOR TEMPERATURE] [NAME id] [DATA temp]
CameraSTATUS [SENSOR CAMERA]
[NAME id] [FORMAT type] [RESOLUTION value] [DIMENSION x,y][BYTES n]
[DATA ...]
MicrophoneSTATUS [SENSOR Microphone] [NAME id] [FORMAT type]
[RESOLUTION value][DIMENSION x,y]
[BYTES n] [DATA ...]

5. SETCONF message: this message is sent by

the controller to a sensor or actuator in order
to change its operating mode, return type, etc.
It is followed by a confirmation sent by the
sensor or actuator.

SETCONF [SENSOR name][NAME id]

[PARAMETER x][TYPE value]...[SENSOR namen] [NAME idn] [PARAMETER xn][TYPE valuen] [ACTUATOR
name] [NAME idn] [PARAMETER x]
[TYPE value]...[ACTUATOR namen]
[NAME idn] [PARAMETER xn][TYPE
valuen]

6. CONF message: this message is sent by the

sensor or actuator to the controller in order
to respond to a SETCONF message.

CONF [SENSOR name] [NAME id]

[STATUS OK/ERROR]

7. CHECKOUT message: this message is sent by

the module when it is plugged off.

CHECKOUT [MODULE name]

The process of packing data into the protocol

format and parsing the data received is carried out
both in the main controller and inside the modules
by their processing unit.

4 Examples of TORP Applications

It is important to state that a new TORP family
can be defined for any class of robots. This section
presents a hypothetical TORP family for wheeled
robots and a more detailed case study for a TORP
family of humanoid robots, with the implementation of CP01.
4.1 A TORP Family for Wheeled Robots
For this family, consider that the following modules were defined: body, vision and laser. The
body module could be represented by a commercially available robot like a P2DX [1] that has an
embedded CPU running a unix-based operating
system. In this way, this body model would comprise sonars, IR, bump sensors, odometers and 2
wheels. The vision module could be represented
by a camera mounted in a platform with 2 DOF.
Finally, the laser module could contain a laser
scanner. Mechanically, the base module offers mechanical plugs to other modules connect to. The
vision and laser modules are both terminal modules since they do not provide mechanical connections to other modules. In this configuration
both modules, vision and laser, are external once
they are mounted outside the structure of the base
module. Considering the electrical dimension, the
base module is initial since it contains the system
power source and it is expansible of order 2, once
it provides electrical energy to vision and laser
modules, that are electrically classified as terminal. If this project follows a TORP module-based
approach, all modules should have their processing units, acting according to their needs, communicating through the system network. In this
example, the vision module would be responsible
for having all knowledge regarding how to drive

J Intell Robot Syst

its motors to position the camera according to

the commands sent by the main controller. In the
same way, the body module would be responsible
for acquiring information from all its sensors as
well as for driving the robot.
Consider now that the differential wheels in the
body module will be replaced by omnidirectional
ones. In this case the body module would be the
only one to suffer with these modifications. In
the same way, if an extra DOF is added to the
vision module, this module would be responsible
for controlling this new DOF. The generalization
achieved by the application of the framework over
a traditional robotics model is the major benefit of
TORP. The application of the electrical, mechanical and computational standards proposed allow
this new system to become reconfigurable, modular and interchangeable, at the cost of additional
hardware and software layers.
A TORP specification set for this family is
detailed in Table 2. Additionally, the specification
for the mechanical and electrical plugs would be
required. As for the power limitations, as the
base module was defined electrically as initial, the
voltage/current specifications for the family could
be defined by it: 12V@7.2A. The network protocol
would be Ethernet.
The following subsection presents another application of TORP for a different class of robots.
4.2 Case Study: CP01 Humanoid Robot
TORP is a generic framework for a large range
of robots. Although it is a feasible framework, its
application is difficult on small-size robots due to
limitations in current technology, like electronic
board sizes, that imply constraints to the selfcontained modules. Its immediate applications to

large robots, like humanoid robots, however, is far

easier.
In order to perform a concept proof of TORP
this section describes the implementation of
a humanoid robot, named CP01. The TORP
family for this robot was idealized as follows:
(i) standard mechanical plug designed to support efforts related to humanoid robot motions
(Table 1); (ii) electrical specification (Table 1),
and (iii) Computational Dimension based on
TCP/IP communication.
Figure 4 presents the CAD design of CP01 robot, first robot implemented based on the TORP
specification set. In its current version, it is a
23 DOF robot with head, two arms and chest,
envisioning future leg expansion, although due
to the use of the TORP framework, a wheeled,
a caterpillar, a n-footed or any other low body
assembly could also be used. CP01 was designed
for human-robot interaction research. Its body
dimensions, particularly its long neck, were purposely designed to permit robots face approximation to human interactor, allowing diverse novel
social behaviors. The full project was designed
according to open-hardware and open-software
concepts, and files are publicly available at [28].
CP01 is composed by eight modules: base,
arms (2), chest, head, image, sound and facial.
Electrical module types and module mechanical
connection classification are shown in Table 3.
Figure 5 presents a connection diagram, in the
electrical and mechanical dimensions, between
modules.
4.2.1 CP01 Electrical Dimension
One of the most important implications of using
TORP protocol lies with respect to power cables

Table 2 TORP specification set for a wheeled robot family

Module

Electrical and mechanical connections

Components

Base

Mechanical: external, expansible of order 2

Electrical: initial, expansible of order 2
Mechanical: external, terminal
Electrical: terminal
Mechanical: external, terminal
Electrical: terminal

DOF: 2
Sensors: sonar, ir, odometer, bumpers
DOF: 2
Sensors: camera
DOF: 0
Sensors: laser

Vision
Laser

J Intell Robot Syst

Fig. 4 CP01 mechanical
CAD drawing.
a Assembly
three-dimensional view;
front-view. b Side-view

(a)

sizing and distribution along the robot. As discussed in Section 2, the average power expected
from a humanoid robot is lower than 3 kW.
In order to attend usual motors and regulators
specifications, a 48 V power source was adopted
for the TORP family of CP01 robot. This voltage
level in mentioned in humanoid robots domain
and expected currents for its usual power would
be about 60 A considering all actuators simul-

(b)

(c)

taneously activated. To fit these requirements, a

8 AWG 3.3 mm diameter cable was used in all
modules and a Molex mini-fit 8 AWG plug family
was adopted as the standard electrical plug for
the whole robot. Once powered, each module was
responsible for regulating voltage for its internal
needs. Regarding electrical specifications, there
are five terminal modules (arms, image, sound,
facial), one expansible of order 1 (base), one

Table 3 CP01 modules

Module

Electrical and mechanical connections

Components

Base

Mechanical: external, expansible of order 1

Electrical: expansible of order 1
Mechanical: external, expansible of order 4
Electrical: initial, expansible or order 4
Mechanical: external, terminal
Electrical: terminal
Mechanical: external, terminal
Electrical: expansible or order 3
Mechanical: internal, terminal
Electrical: terminal
Mechanical: internal, terminal
Electrical: terminal
Mechanical: internal, terminal
Electrical: terminal

DOF: 2
Sensors: none
DOF: 0
Sensors: accelerometer, sonar
DOF: 6
Sensors: accelerometer
DOF: 3
Sensors: accelerometer
DOF: 0
Sensors: camera
DOF: 0
Sensor: none
DOF: 3
None

Chest
Arms
Head
Image
Sound
Facial

J Intell Robot Syst

(a)

(b)

Fig. 5 CP01 modules connection schema. a Electrical schema. b Mechanical schema

expanisble of order 4 (chest) and one expansible of order 3 (head). Gumstixs Verdex PRO
were adopted as embedded devices in all modules
due to their small size (2 cm 8 cm) and high
computational power (Marvell PXA270 400 MHz
XScale processor). There was an exception for
Gumstix RoboAudio, that was adopted in the
sound module. Regulators and sensor/actuator
controllers SMD boards were specially designed
to fit these project requirements.

4.2.2 CP01 Mechanical Dimension

In order to conduct a proof of concept with respect to the possibility of building a common mechanical plug to a humanoid robot, a very simple
connectorshown in Fig. 6was proposed and
machined for the TORP family of CP01 robot.
This plug is basically composed by two aluminum
tubes with a mechanical interlocking. Aiming a
quick plug, two side buttons were designed in the

J Intell Robot Syst

Fig. 6 Exploded version of CP01 mechanical plug

main tube. When both are pressed, they are compressed into the tube, allowing disengagement.
Once released, both are expelled by the spring to
their original places. Since buttons tend to be the
point of maximum mechanical stress, they were
manufactured in steel instead of aluminum due
to its well known high shear strength. The opposite end of tubes were strongly fixed in modules
chassis. Dynamixel AX-12, RX-64 and EX-106
servomotors and as general purpose micro servomotors were adopted as the motors of CP01.

messages sent/received through the network in

terms of medium level commands. For all levels,
the code was written in C++. The basic class
structure of the system is represented in Fig. 7.
In the following code example, Module is the
class that contains all sensors and actuators implementation. This class is responsible for receiving/sending the information from/to the network
connection, calling the appropriate commands.
Sample code for CP01 software embedded in
modules.
/******* High level function *******/
void Module::checkData() {
string lastDataFromServer;
this->serverSocket
->receive(lastDataFromServer,500);
string str = lastDataFromServer;
// Checks for messages
if (str.find("ACTION",0)
!= string::npos ) {
if (str.find("{MOVE RX64}")
!= string::npos ) {
this->rx64->move(str);
}
if (str.find("{MOVE AX12}")
!= string::npos ) {
this->ax12->move(str);
}
if (str.find("{PLAY SPEAKER}")
!= string::npos ) {
this-speaker->play(str);
}
}

4.2.3 CP01 Communication and Computational

Dimension
CP01 robot modules were modeled as nodes in
a Ethernet-TCP/IP network and a router was inserted in the chest module. CP01 software was
divided into two parts: (i) inside modules and (ii)
controller software. Inside each module, to allow
future changes of hardware without significant
changes, CP01 follows the multilayer software
development. Each module contains a Gumstix
with Linux Open Embedded OS running, and a
Net Pro VX with wi-fi for communication. For
each module, three levels of code were designed:
(i) The low level: refers to direct access to pins,
ports and hardware elements (serial, timer, reset, etc.); (ii) The medium level: refers to macro
commands that can be sent to the peripherals
connected to the control board. For example, the
set of low levels commands that are sent to the
hardware to perform a move in a servo with
specific speed, and (iii) The high level: refers to
the packing/unpacking commands that parser the

Fig. 7 Basic class-diagram for module internal code

J Intell Robot Syst

(a)

(b)

Fig. 8 CP01 Control software. a Interface control with

no module connected. In this representation, the color of
the modules sketch and the absence of visual information
indicate that no module has been plugged in the system.

b As modules are plugged, the color of the sketch changes

and the information received trough the check-in message
regarding the module (number of sensors, sensor data,
position, etc.) are presented in the interface

/*******Medium level function*******/

void MotorRx64::setReturnDelayTime
(char rdt) {
//construct the message to the servo
char *parameter;
parameter = new char[2];
parameter[0] = P_RETURN_DELAY_TIME;
//adress to write
parameter[1] = rdt;
//new adress to be setup
sendGeneralCmd
(INST_WRITE,parameter,2);
//send the command
}
/******* Low level function *******/
int Tserial::getArray
(char *buffer, int len) {
unsigned long read_nbr;

cal interface. The software is responsible for keeping track of each module connected. In Fig. 8a
there is a monitoring window where no module is
connected. As the modules open their connection
with the controller and send a CHECKIN message, the data is interpreted by the control system
and the characteristics of the module (sensors,

read_nbr = 0;
if (serial_handle
!=INVALID_HANDLE_VALUE) {
ReadFile(serial_handle, buffer, len,
&read_nbr, NULL);
}
return((int) read_nbr);
}

4.2.4 Controller Software

The Controller Software in CP01 runs in a computer external to the robot. The controller was
built in Java with the Java 2D API for the graphi-

Fig. 9 CP01 robot assembled

J Intell Robot Syst

Fig. 10 Sequence of movements of CP01 arm with embedded accelerometer placed next to the shoulder link TMP in order
to evaluate the additional vibration induced in the arm by the addition of the standard plug

actuators, etc.) are presented. Figure 8b shows

modules plugged into the system. Once a module
has checked in into the system, the main controller
is responsible for requesting up to date information of the modules through GETSTATUS
message. The module answers to the controller
with a STATUS message. Then, the information
received is parsed in the controller so that its
graphical interface shows the current status of the
module. In this way, the controller software is able
to visualize and control each module individually
or the whole robot. The TORP architecture is,
therefore, invisible to a human operator.
4.2.5 Final Assembly Evaluation
CP01 robot final assembly is shown in Fig. 9.
In order to evaluate the issues that arise when
establishing a standard mechanical plug instead

(a)

of perfectly clumping parts, an experiment was

conducted. The movement sequence for this experiment can be seen in Fig. 10. In this experiment, a 3-axis accelerometer was inserted in the
shoulder-arm link, just after the TORP Mechanical Plug, in such a way that vibration effects could
be observed. Figure 11 presents the voltage versus
time graphs returned by the accelerometer in its
3-axis. One can verify that spikes in the Z axis
(the plan where there is no ongoing movement)
after movements in the other axis may indicate
that a low vibration was inserted by the plug in the
system. However, its amplitude cannot be understood as significant for robots that do not require
a very precise positioning system, as that required
for industrial or domestic general purpose robots.
Considering the scenario where the robot arm
structure weights approximately 2 kg and measures 0.7 m, moving at low speed with a small

(b)

(c)

Fig. 11 Accelerometer measurements in all three axis for slow (a), medium (b) and high (c) shoulders motors movement
velocities. Axis not rotating in all situations does not present significant vibration

J Intell Robot Syst

Fig. 12 Tensile, compressive and flexion analysis for a 1,000 N load on the aluminum-steel connector. Aluminum and steel
Yield strength are about 97 and 294.8 MPa, respectively

load, it is reasonable to expect that the mechanical

plug will not be subject to a force greater than
1,000 N. Following this assumption, experimental
data obtained with computer simulations for tensile, compressive and flexion analysis for a 1,000 N
load on the aluminum-steel connector shown in
Fig. 12, did not present significant mechanical
deformation, showing that this first version of a
mechanical plug attends the project mechanical
requirements.

5 Results and Discussion

The feasibility of the proposed methodology
for real world robots was demonstrated through
the building of CP01. Experimental results have
demonstrate that robot mechanical abilities are
not significantly affected by the TORP architecture, and that there is at least one set of mechanical plug, electronics and communication apparatus able to satisfy specification requirements.
Besides the functional modification that can be
carried in the TORP robots through the replacement of modules, the aesthetics of the robot can
also be fully modified by the exchange of modules.
For CP01, a new and smaller head will be used
so the robot can have more stability once legs are
added.

Taking into consideration that TORP framework does not limit mechanical nor electrical connectors, as well as network technologies, it is reasonable to expect that new families of robots with
better implementations can arise in the future and
that some of them can become new standards for
certain robot classes.
One of the most serious difficulties faced in the
project was on the design of the power regulation boards, far more complex than usual and in
the limit of the available technologies considering
size/power relation.
Although the work to setup a robot project to
the TORP specification set is hard, the advantages
that overcome this initial trouble are tremendous.
First of all, the re-use of hardware and software
parts in new robots or versions is an easy task
if the robots belong to the same TORP family.
Moreover, the modular architecture provides an
easy way to compare parts of robots. For instance,
distinct models of arms, legs, grippers and others,
can be evaluated regarding their speed, response
time, energy consumption or even control aspects
in the same platform. Yet, groups with different
expertise and using different technologies can apply their developments in the same robot. The
before mentioned advantages of the proposed
framework present possible ways to overcome the
historical drawbacks in robot design and still have

J Intell Robot Syst

full compatibility with previously proposed robotics operating systems and frameworks.
One can argue that the connection of modules
with distinct mechanical properties might be impractical for control purposes of the whole assembly. In fact, this would be a serious constraint if
the information regarding the mechanical aspects
of the module was not informed to the main controller by the module itself. With this information,
special control techniques can be future investigated to assign robustness to the system.
Finally, it is fair to observe that this modulebased framework is better suitable for medium/
high size robots due to constraints regarding current mechanical and electrical technologies.

6 Conclusions and Future Work

This paper summarizes the specification of a new
framework, TORP, proposed for modular collaborative robot projects. The focus in TORP robots
is shifted from components to functional level,
creating an abstraction between high and low level
control, not only in the computational dimension
but also in the mechanical and electrical. It does
not contradict previous standardization, but extends them to new dimensions. At the best of our
knowledge, this work represents the first proposition of standardization at all these dimensions in
robotics.
It is also important to mention that the cost of
the application of this protocol in a robot project
is the insertion of redundancies in all dimensions,
that have impact in robot budget. In fact, one
can argue that it would be cheaper and quicker
to connect sensors and actuators directly to the
controller. In fact, this reasoning was valid also for
PCs in the early 70s. The advantages of such standardization work in long term. It is also important
to keep in mind that TORP direct applications
are for robots build in collaborative situations, i.e.,
where multiple institutions with different interests
and skills want to build a unique robot. However,
any project can adopt this methodology.
In order to upgrade the framework, some improvements are in progress: (i) a new version of
the mechanical plug that incorporates the electrical cables, (ii) simpler self-designed boards for the

modules to reduce the overall project budget, and

(iii) development of control strategies suitable for
application in TORP robots domain.
Finally, we do not claim that TORP is a final
methodology. Although we believe such standardization could have a deep impact on the way we
build robots, we are sure that it represents just
a first step on the direction of the discussion of
necessary standardization in the robotics field.
Acknowledgements Authors gratefully acknowledge
the contribution of Rafael Ribeiro, Victor Nalin, Alan
Morgensztern, Kaue Cruz, Daniel Baggio, Wilson
Canazart, Rafael Chiafarelli and Raphael Bartholo Costa.
Authors would also like to thanks Mauricio Leal, Silveira
Neto and Bruno Souza for developing the remote
interface. CP01 robot was named after Campus Party,
event supported by Futura Networks, that welcomed
the project and made this research possible. CP01 was
sponsored by Micropress.

References
1. Active Media Robotics: P2dx robot. http://www.
mobilerobots.com/ (2010)
2. Aghili, F., Parsa, K.: A reconfigurable robot with
lockable cylindrical joints. IEEE Trans. Robot. 25(4),
785797 (2009)
3. Baillie, J.C.: Urbi: towards a universal robotic lowlevel programming language. In: IEEE/RSJ International Conference on Intelligent Robots and Systems,
pp. 820825 (2005)
4. Baillie, J.C., Demaille, A., Hocquet, Q., Nottale, M.,
Tardieu, S.: The Urbi universal platform for robotics.
In: Intl. Conf. on Simulation, Modeling and Programming for Autonomous Robots, pp. 580591 (2008)
5. Brooks, A., Kaupp, T., Makarenko, A., Williams, S.,
Orebck, A.: Orca: a component model and repository.
In: Brugali, D. (ed.) Software Engineering for Experimental Robotics. Springer Tracts in Advanced Robotics, vol. 30, pp 231251. Springer Berlin, Heidelberg
(2007)
6. Bruyninckx, H., Soetens, P., Koninckx, B.: The realtime motion control core of the Orocos project.
In: IEEE International Conference on Robotics and
Automation, pp. 27662771 (2003)
7. Gerkey, B., Vaughan, R., Howard, A.: The player/stage
project: tools for multi-robot and distributed sensor
systems. In: Proceedings of the 11th International Conference on Advanced Robotics, pp. 317323 (2003)
8. Hu, Y., Wang, L., Zhao, W., Wang, Q., Zhang, L.:
Modular design and motion control of reconfigurable
robotic fish. In: IEEE Conference on Decision and
Control, pp. 51565161 (2007)
9. Jun-Ho, O., David, H., Won-Sup, K., Young, H.,
Jung-Yup, K., Woo, P.: Design of android type

J Intell Robot Syst

10.

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

21.

humanoid robot Albert HUBO. In: International Conference on Intelligent Robots and Systems, pp. 1428
1433 (2006)
Kaneko, K., Kanehiro, F., Kajita, S., Hirukawa, H.:
Humanoid robot HRP-2. In: Proceedings of the IEEE
International Conference on Robotics and Automation
(2004)
Kim, J.Y., Park, I.W., Oh, J.H.: Realization of dynamic stair climbing for biped humanoid robot using
force/torque sensors. J. Intell. Robot. Syst. 56(4), 389
423 (2009)
Lund, H., Henningsen, A., Nielsen, R.: Modular robotic system as multisensory room in childrens hospital. In: Proceedings of 14th International Symposium
on Artificial Life and Robotics (ISAROB) (2009)
Madden, J.D.: Mobile robots: motor challenges and
materials solutions. Science 318(5853), 10941097
(2007)
Metta, G., Fitzpatrick, P., Natale, L.: Yarp: yet another
robot platform. Int. J. Adv. Robot. Syst. 3(1), 4348
(2006)
Metta, G., Sandini, G., Vernon, D., Natale, L., Nori,
F.: The iCub humanoid robot: an open platform for
research in embodied cognition. In: PerMIS: Performance Metrics for Intelligent Systems Workshop,
pp. 1921 (2008)
Mondada, F., Bonani, M., Raemy, X., Pugh, J., Cianci,
C., Klaptocz, A., Magnenat, S., Zufferey, J., Floreano,
D., Martinoli, A.: The e-puck, a robot designed for
education in engineering. In: Proc. of the 9th Conf. on
Mobile Robots and Competitions (ROBOTICA 2009),
pp. 5965. IPCB: Instituto Politcnico de Castelo
Branco, Castelo Branco, Portugal (2009)
Montemerlo, M., Roy, N., Thrun, S.: Perspectives
on Standardization in Mobile Robot Programming:
The Carnegie Mellon Navigation (CARMEN) Toolkit,
pp. 24362441 (2004)
Nof, S., Chen, J.: Assembly and disassembly: an
overview and framework for cooperation requirement
planning with conflict resolution. J. Intell. Robot. Syst.
37(3), 307320 (2003)
Park, I.W., Kim, J.Y., Lee, J., Oh, J.H.: Mechanical
design of the humanoid robot platform, HUBO. Adv.
Robot. 21(11), 10351322 (2007)
Pivtoraiko, M., Nesnas, I., Nayar, H.: A reusable software framework for rover motion control. In: International Symposium on Artificial Intelligence, Robotics
and Automation in Space. Los Angeles, CA (2008)
Quigley, M., Gerkey, B., Conley, K., Faust, J., Foote,
T., Leibs, J., Berger, E., Wheeler, R., Ng, A.: Ros: an
open-source robot operating system. In: International
Conference on Robotics and Automation (2009)

22. ROS.org: Ros Software Libraries. http://www.ros.

org/wiki/ (2010)
23. Rusu, R., Maldonado, A., Beetz, M., Gerkey, B.: Extending player/stage/gazebo towards cognitive robots
acting in ubiquitous sensorequipped environments. In:
ICRA Workshop for Networked Robot Systems, 2007.
Rome, Italy (2007)
24. Sakagami, Y., Watanabe, R., Aoyama, C., Matsunaga,
S., Higaki, N., Fujita, M.: The intelligent asimo: system
overview and integration. In: Proceedings of International Conference on Intelligent Robots and Systems,
pp. 24782483 (2002)
25. Seward, D., Bradshaw, A., Margrave, F.: The anatomy
of a humanoid robot. Robotica 14(4), 437443 (2009)
26. Sproewitz, A., Asadpour, M., Billard, A., Dillenbourg,
P., Ijspeert, A.: Roombotsmodular robots for adaptive furniture. In: Proceedings of the IEEE/RAS
International Conference on Intelligent Robots and
Systems (IROS). Workshop on Self-Reconfigurable
Robots, Systems and Applications (2008)
27. Sproewitz, A., Billard, A., Dillenbourg, P., Ijspeert,
A.: Roombots-mechanical design of self-reconfiguring
modular robots for adaptive furniture. In: IEEE International Conference on Robotics and Automation,
pp. 42594264 (2009)
28. TORP: The Open Robot Project Repository. https://
torp.svn.sourceforge.net/svnroot/torp/ (2010)
29. Touretzky, D.S., Tira-Thompson, E.J.: The Tekkotsu
Crew: teaching robot programming at a higher level. In:
Proceedings of the Twenty-Fourth AAAI Conference
on Artificial Intelligence (AAAI-10) (2010)
30. Volpe, R., Nesnas, I., Estlin, T., Mutz, D., Petras, R.,
Das, H.: The claraty architecture for robotic autonomy.
In: Aerospace Conference, 2001, IEEE Proceedings,
vol. 1, p. 1 (2002)
31. Wilkier, D.R.: Muscle. Edward Arnold, London (1976)
32. Willow Garage: PR2 Robot. http://www.willowgarage.
com/ (2010)
33. Yim, M., Shen, W.M., Salemi, B., Rus, D., Moll, M.,
Lipson, H., Klavins, E., Chirikjian, G.S.: Modular selfreconfigurable robot systemschallenges and opportunities for the future. IEEE Robot. Autom. Mag.,
14(1), 4352 (2007)
34. Zykov, V., Chan, A., Lipson, H.: Molecubes: an opensource modular robotics kit. In: Proceedings of the
IEEE International Conference on Intelligent Robots
and Systems (IROS) (2007)
35. Zykov, V., William, P., Lassabe, N., Lipson, H.:
Molecubes extended: diversifying capabilities of opensource modular robotics. In: Proceedings of the
IEEE Intelligent Robots and Systems 2008, SelfReconfigurable Robotics Workshop (2008)