J Intell Robot SystDOI 10.1007/s10846-011-9626-9

TORP: The Open Robot ProjectA 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 shownitself as a very complex interdisciplinary researchfield. The predominant procedure for these de-velopments in the last decades is based on theassumption that each robot is a fully personalizedproject, with the direct embedding of hardwareand software technologies in robot parts with nolevel of abstraction. Although this methodologyhas brought countless benefits to the robotics re-search, on the other hand, it has imposed majordrawbacks: (i) the difficulty to reuse hardwareand 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, Brazile-mail: assimoes@sorocaba.unesp.br

M. N. FranchinDepartment of Electrical Engineering,UNESP - Univ Estadual Paulista,Campus of Bauru, Bauru, Brazile-mail: franchin@feb.unesp.br

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

E. L. Colombinie-mail: esther@ita.br

J. P. Matsuurae-mail: jackson@ita.br

(ii) the difficulty to compare performance of dif-ferent robots parts; and (iii) the difficulty toadapt development needsin hardware and soft-ware levelsto local groups expertise. Large ad-vances might be reached, for example, if physicalparts of a robot could be reused in a differentrobot constructed with other technologies byother researcher or group. This paper proposes aframework for robots, TORP (The Open RobotProject), that aims to put forward a standardiza-tion in all dimensions (electrical, mechanical andcomputational) of a robot shared developmentmodel. This architecture is based on the dissocia-tion between the robot and its parts, and betweenthe robot parts and their technologies. In this pa-per, the first specification for a TORP family andthe first humanoid robot constructed following theTORP specification set are presented, as well asthe advances proposed for their improvement.

Keywords Module-based robots Robotics design framework Collaborative robots Open Robot Project Standardization in robotics

1 Introduction

In the last decades, there has been some impor-tant standardization in several areas of computa-tion 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 thelate 70s. As it happened to the PCs, the roboticslabs and researchers around the world are facingexactly the same challenges: high fragmentation,lack of standardization, complex projects withoutestablished methodologies, lack of practical appli-cations and slow development. Indeed, it is almostunthinkable nowadays that some part of a robotcan be plugged and work properly in another one,and this scenario is even worse when consideringhuman-size robots.

There are some different reasons for this poorstandardization level. First of all, robots are builtwith extremely different purposes, that have deepimpact in their architecture. It is unlikely, forexample, that a robot designed to load weight canhave the same physical architecture of a robotfor playing music, even if both are humanoids.Other contributing factor is that some of the mostimportant robotics developments are fomentedby private institutions, that are usually restricton sharing technical information and acceptingstandardization from external institutions. Yet,robotics operating systems are recently new andhave a low number of users. In some cases theseframeworks also impose some technology con-straints to the developers. In fact, the expertise ofdifferent groups in using some kind of hardware orsoftware technology guides their technical choicesin new projects. Standardization that cannot prop-erly handle with this diversity is doomed tofailure.

As a consequence of this scenario, most of thenew projects must restart almost from scratch,what limits the knowledge sharing between re-search centers. However, a change is expected inthe next years. The rush for better robots andfor a speed up in robotics developments is turn-ing mandatory the sharing of expertise amongdifferent groups in the fields necessary to developa full robot. A new kind of collaborative researchand development could make possible to use thisexpertise diversity, necessary in this interdiscipli-nary task.

In this way, a framework for this kind of devel-opment would require: (i) standardization in elec-trical and mechanical dimensions that allow theinterchangeability of robot parts with flexibility in

technologies; and (ii) availability of software tools,like graphical interfaces, robotics optimized rou-tines, network communication framework, sensordata transfer, and so on.

This paper presents the TORP (The OpenRobot Project) framework, an open standardmethodology for modular robots design that aimsto fulfill some of the gaps earlier presented. Thispaper is organized as follows: Section 2 providesan overview of the available robotics frameworksin several aspects, presenting a general schemeof these methodologies in order to establish fu-ture directions of these technologies. Section 3presents an overview of the TORP specificationset. Section 4.2 shows examples of TORP appli-cations, detailing the main features of CP01, thefirst robot built using TORP methodology whileSection 5 presents some results achieved. Finally,Section 6 concludes with an assessment of theresults and proposes directions for further inves-tigation and improvements in the framework.

2 Robotics Frameworks: Overviewand Future Directions

Different methodologies have been proposed forrobotic developments in the last decades. Themost common methodology, adopted since theearly days of robotics, tends to focus on sensorsand actuators assembly directly linked with a con-troller device. In the electrical dimension, powersource is regulated and appropriate voltages aretransferred to sensors, actuators and controllerthrough a set of cables. Mechanically, devices tendto be all connected to a robot chassis. Compu-tationally, the main control is located in a per-sonal computer or an embedded device, and thereis usually a low level of separation in softwarelayers [18]. A schematic diagram of this projectmethodology is shown in Fig. 1a. Although manyadvances have been possible with this method-ology, it has well known limitations in terms ofhardware and software reuse, collaborative devel-opment and excessive technology-dependence.

Specially focusing on software reuse, severalframeworks have arisen in the past years. In gen-eral lines, these frameworks are cross-platform

J Intell Robot Syst

Fig. 1 Roboticsframeworks generalscheme. a The mostcommon roboticsframework: low level ofseparation betweensoftware layers, electricaland mechanical devices.b General scheme of therobotics operationalsystems approach thatarose in the last decade: asoftware abstraction levelaims to assure someindependence degreebetween code anddevices. Electrical andmechanical devicesremain with a lowindependence level

(a) (b)

open-source environments that operate over someoperational system layer. Most of them, likePLAYER [7, 23], OROCOS [6], YARP [14] andCLARATY [20, 30] focus in architectures ableto provide modularity and separation between ro-botics application code and low level code (mem-ory allocation, threads, communication, etc.).ORCA [5] proposes a component-based softwareapproach. Although device drivers for these plat-forms are not yet available for manufacturers, itis a growing trend. In communication level, sev-eral frameworks also assume a network structurewith central servers, like CARMEN [17], or het-erogeneous networks, like ROS [21], Tekkotsu[29] and Urbi [3, 4]. Some frameworks also pro-pose valuable application level tools and librariesfor robotics domains, like kinematics calculationtools [6], centralized parameter server [21], imagelibraries [14], localization and mapping [21] and soon. Figure 1b presents a general scheme of theseframeworks.

Although these computational frameworksrepresent a complete rupture with previous robotprojects methodologies much more appropriatefor complex developments than the traditionalapproach, some important questions remain still

open. In general lines robot technologies con-tinue to be chosen based on a specific projectphilosophy and needs. The excessive intertwineand mutual dependence between a robot and itstechnologies leads to some particular problems:(i) hardware reuse in different robots or in dif-ferent versions of the same robot is unthinkablefor fully assembled parts, and is limited to changesin components level; (ii) technological sharing be-tween different research groups is difficult, sinceeach group tends to work based on differenttechnologies; and (iii) performance comparisonbetween analogue high level parts of differentrobots is almost impossible since the parts per-formance are completely dependent on the wholerobot set. In fact, it is important to remark thatcomputationmajor concern of today roboticsframeworksrepresents only one of the three ro-botics dimensions, and quicker developments inthe robotics field could be reached if a frameworkwould also consider some electrical and mechani-cal standardization, as technology independent aspossible.

As a next step on the robotics frameworksdiscussion, one can hypothesize that a moreuseful framework for robotics development and

J Intell Robot Syst

research could be reached based on the followingprinciples:

1. Project paradigm is shifted from componentslevel to functional self-contained moduleslevel;

2. Modules are externally standardized in threedimensions: electrical, mechanical and com-putational, but are internally technology-independent;

3. Main controller may operate remotely accord-ing to previous robotics operating systemsprinciples.

It is important to remark that this set of prin-ciples keeps strong relation with those adoptedin PCs, since technologies changes in componentslevel no longer affect computers functionalitiesdue to electrical and mechanical standardizationin data buses, plugs and power sources.

Two other concepts are important to overcomethe compatibility issues in the design of the robots.

First, collaborative development is usually as-sociated to the open-source development, thatis, developments where knowledge is publiclyshared as open-software and/or open-hardware.E-puck robot [16] is a desktop-size open-softwareand open-hardware differential wheeled mobilerobot designed for micro-engineering education.Molecube [34] are modular-based open-softwareand open-hardware low-cost cube robots envi-sioned as a universal element in order to buildmore complex structures, as an alternative to avariety of specialized machines.1 One of the mostrecent robots in this line is the PR2 [32], a general-purpose wheeled robot platform with two arms,head and gripers that can serve as a base forfurther development in robotics. This project in-corporates 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 ahardware system and then re-implement code,the PR2 allows software experts to immediately

1In the context of projects hereby presented, open-hardware refers to a basic hardware electromechanicalpublishing, and not a collaboratively constructed hardware.

create new functionality on the robot. It also stim-ulates groups to build new parts of the robot, likegrippers, and to develop open-source software.Although it is an extremely flexible and an upto date platform, it does not allow some studies,like for legged systems, since the pre-designedplatform naturally imposes several constraints inthe robot physical structure.

Another important growing tendency is re-configurable robotics [33], term usually relatedto the possibility of multiple mechanical config-urations of robot modules through mechanicalconnections. It is usually based on the existenceof some kind of mechanical standard plug. In [8]modules can be connected or disconnected man-ually, and by adding and removing the modulesone can build a robotic fish with different mor-phologies. In [26, 27] reconfiguration is carried outthrough dynamic connection and disconnection ofmodules and rotation of their DOF, which areapplied over adaptive furniture. For [12], flexibletiles are interconnected by magnets and commu-nicate using infra-red. It is used to engage andmotivate user to perform physical activities inhospitals, whereas [2] uses passive lockable cylin-drical joints to permit changing kinematic para-meters in robotic manipulators. An interestingcombination of electrical and mechanical plug wasproposed in Molecube [35]. Due to a unified inter-face, since a robot cube is mechanically connectedto a next cube, they are also electrically plugged.Although universal mechanical plugs have notbeen proposed for high-size humanoid robotics,this idea must be taken into consideration.

2.1 Humanoid Robot Projectsand Related Approaches

As an example to expose the problems concernedwith a robot design, an analysis of humanoid robotprojects will be presented.

Some important projects of humanoid robotshave been highlighted in recent robotics history,many of them correlated with the present workin several aspects. Some well known humanoidprojects are ASIMO [24], HRP-2 [10, 11], HUBO[9] and REEM-B [25]. In order to perform humanlike actions, it is natural to expect that humanoid

J Intell Robot Syst

robots approximate humans in several aspects likesize, mass, torque, velocity and so on. Consideringconstructive aspects, these robots vary from 30[24] to 66 [9] DOF, are from 1.2 to 1.5 m tall andcapable to walk up to 6 km/h. As shown in Table 1,one can say that todays robots power is the sameorder of magnitude as human muscle power [19,25], although these robots are smaller and slowerthan humans, and have a worst power/weight rela-tion in actuators (150 W/kg of todays motors [13]against 500 W/kg of human muscles [31]).

Considering the increasing complexity of hu-manoid robotics developments, it is more andmore unlikely that a single research center can becapable of developing the whole chain of needsrequired by such a complex project. In fact, ro-bots development paradigm seems evolving fromcentralized developments to a collaborative ap-proach. One of the most important platforms inthis paradigm is iCub [15], project funded by theEuropean Commission that aims to study cogni-tion through the implementation of a humanoidrobot the size of a 3.5 year old child, through theRobotCub framework. Some of the RoboCubspartners adopt the YARP open-source library[14]. Although it is a collaborative robotics proj-ect, collaboration in RobotCub is mainly fo-cused on computational developments for robotcognition based on a predefined hardware.

Regarding the mechanical aspects of a roboticsproject, one of the trends is the research of univer-sal and flexible connectors. Some of the desiredcharacteristics 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 humandegrees of freedom, excluding head, hands and feet, versushumanoid robot actuators power

Joint Human Hubo

Peak power Velocity Torque Robot(W) (rpm) (N.m) (W)

Shoulder 110 350 70 270Elbow 110 150 40 90Wrist 30 150 20 22Hip 600 300 140 330Knee 600 150 160 300Ankle 50 150 110 180Estimated 3.000 2.384

tools; (ii) it must be unique or keep compatibilitywith all similar connections in robot, independenton its size or mechanical requirements; and (iii)it must be robust in terms of mechanical efforts(looseness, torque, rotation, etc.). These are ab-solutely nontrivial goals considering humanoid ro-bots mechanical characteristics.

It can be observed that there must be a stan-dardization in all three dimensions (electrical,mechanical and computational) to enable coop-erative and collaborative design and implemen-tation of complex humanoid robot projects. TheTORP specification set could be a solution.

3 The Open Robot Project Framework

TORP is a framework, ruled by GNU GeneralPublic License (GPL), to build robots that followa common philosophy in their design: the TORPSpecification Set.

Shifting from the components level, usuallyproposed by traditional robotics frameworks(Fig. 1a and b), to the functional level, a TORProbot is a collection of independent, replaceableand specialized parts (modules) that are as self-contained as possible and that jointly producean artificial creature. For example, consider anarm of a humanoid robot. In a TORP robot, allthe mechanics, electrical devices and processingunits necessary to assure that this robot arm canexecute its functions must be fully contained inthe very robot arm. Furthermore, the robot canbe seen as a communication network that hostsa society of mechanically-electrically independentparts. All these parts are responsible for collect-ing information (internal and external) that canbe important to perform its own tasks and foroffering all its services to the robot network. Inorder to assure that these parts can be capable tosuitably and harmonically cooperate to produce amore complex entity, some electrical, mechanical,computational and communication requirements(the TORP Specification Set) must be simultane-ously respected by all families of TORP robots. ATORP family is defined as a set of modules thatshare the same values for all dimensions in theTORP specification set.

J Intell Robot Syst

3.1 TORP Specifications Set

The framework proposed in this paper followsthe schematics of Fig. 2. In this model, three di-mensions are considered to fully describe a ro-bot project: the mechanical, the electrical and thecomputational dimension. In the computationaldimension (Fig. 2a) it is stated that all modulesare responsible for containing the knowledge onhow to control its parts according to the chosencomponents. The only restriction in this modelrefers to the fact that all modules have to speaka common protocol, defined in Section 3.4.1, andthat they have to communicate through a net-work. There is no restriction whether the maincontroller should be embedded or not. Hence,a Robotics Operating System could be used toproperly deal with the modules coordination, aswell as a Graphics User Interface. The electrical

specification seen in Fig. 2b determines that thereis a common power source for the modules andthat each one is responsible for regulating thepower to meet the modules components needs. Astandard electrical plug is used for all modules. Fi-nally, the mechanical dimension (Fig. 2c) presentsthe modules connected to the main chassis orto each other through a standard plug. The nextsubsections describe details on each dimension.

3.2 Mechanical Dimension

The main concept in the mechanical dimensionis the module. Each module must be chosen ac-cording to its typical function and it must becompletely independent on the other modules.In a humanoid robot, for example, the follow-ing modules would be recommended: head, chest,legs, arms, hands. However, a robot designer is

(a) (b) (c)

Fig. 2 TORP framework general scheme, with focus onfully self-contained modules. a Computational architec-ture. Modules interact in a network with a high level maincontrol. Drivers and low level processing are fully em-bedded in module. b Electrical architecture. Each module

is responsible for internal voltage regulation for its ownneeds and it can provide electrical connection to othermodules. c Mechanical architecture. Modules can be con-nected to main chassis or other modules using a quickconnect standard mechanical plug

J Intell Robot Syst

free to use any number or type of modules andthese modules can change over time. For instance,a project of a humanoid robot that has a singlemodule arm that contemplates the hand can bereplaced, in a new version, by two separate mod-ules: arm and hand. The modules are encouragedto keep all its elements (mechanical, electrical,computational and communication) inside of itsown mechanical structure, allowing a quick andeasy handle of the module. In the same direction,modules must have a structural rigid material ableto properly attach all its internal units, except inthe case of the internal module, which is allowedto plug its sensors, actuators and/or wires in theexternal module.

To allow connections between modules, aTORP mechanical plug (TMP) must be defined.In this way, modules cannot be connected toother modules except by using standard mechan-ical plugs. This practice assures that any modulewill be able to physically connect into any TORProbot, part or version of that specific family. TheTMP should meet the family project needs. Fur-thermore, since modules can be plugged in com-plex ways, there must be a classification of theseconnections types.

In this framework, a module must be classifiedaccording to the following:

1. Connection with previous module: Defineshow the current module connects to previousmodules. There are two possibilities:

(a) External: the module (A) is physicallyconnected to a previous module (B) us-ing the TMP, and A is physically exter-nal to B;

(b) Internal: the module (A) is fully inter-nal to the previous module (B). Internalmodules do not need to be connectedusing the TMP. This is allowed only toextremely simple and light modules (typ-ically those that have only an electricalboard connected to some special sensorwithout any mechanics and so on). In thiscase, the connection between modulescan be made through screws.

2. Connection with next modules: Defines thenumber of modules that can be connected to

the current module and how this connectionoccurs. Following this specification, the currentmodule can be classified in two different ways:

(a) Expansible of order N: this module of-fers N TMPs that can be used by othermodules;

(b) Terminal: this module does not provideTMP connections to other modules.

The modules and TMPs must carry preciseinformation regarding some special features thatshould physically be written in their structure:

1. TMP label: any material can be used to con-struct the TMP. However, different materialsimply in different mechanical properties, and,hence, the maximum number of allowed con-nected modules depends on the mechanicalplug material. In this way, TMPs must carrythe maximum load (N) and torque (N.m) thatcan be supported by this mechanical plug.

2. Module label: every single module must carryprecise information (physically written in themodule) regarding its own load (in N), length(in m) and degrees of freedom. This informa-tion can be used to control the module.

3.3 Electrical Dimension

Although standardization is proposed in the elec-trical dimension, there are no constraints for theelectronic boards or on-board software used bythe modules. Instead, only a common protocol isestablished, and the implementation technology iscompletely free. There is a main power source,used by all modules and each module is respon-sible both for re-configuring the power to meet itsown needs as well as for by-passing the originalpower to the next module connected to it, if thereis such module.

In this way, each single module is electricallyindependent on the others and they should beclassified according to:

Module type: according to the electrical rolethat it plays in the system, a module mustbelong to one of these electrical patterns:

Expansible of order N: this module re-ceives electrical energy from other modules,

J Intell Robot Syst

and will provide electrical connection withthe original power to N other modules(that must be mechanically connectedto it)

Terminal: this module receives electri-cal energy from other modules, but doesnot provide electrical connection to othermodules

Initial: this module will transfer electricalenergy from the power source to othermodules. In this case, it will also be expan-sible of order N.

In order to respect the independence of eachmodule, some other important characteristicsmust be considered:

Standard electrical plug: there should be astandard plug as the only allowed electricalconnection for modules.

Allowed electrical connections: each moduleis allowed to connect only to the plug providedby the immediately previous module, and itmust provide a fully functional electric plugto the next module(s), except in the case of aterminal type module;

Power: the maximum power available to therobot has to be specified in the family projectand cannot be exceeded;

Voltage: all robot modules will receive thesame standard voltage, determined accordingto the family robot design. The module mustinternally transform this voltage according toits own needs;

Current: the maximum allowed current forthe whole robot is set in the family project.Since an expansible type module can be con-nected to an unknown number of other mod-ules, all expansible module wires must bedimensioned to attend the whole robot electri-cal requirement. Terminal type modules wirescan be dimensioned according to their ownneeds.

Visual identification: The module current con-sumption must be clearly identified (physi-cally written) in the module in order to allowpeople to visually inspect and evaluate thepossible insertion of this module in the mainrobot (composed by other modules) while re-placing robot parts;

Wires and cables position: the allowed posi-tions of modules wires and cables will dependon the type of the physical position of themodule in the robot (see Section 3.2). Forconnected modules all wires and cables (andalso modules sensors and actuators) must me-chanically fit the robot module. As for inter-nal modules, if a module A is internal to amodule B, some of the A modules sensors,actuators and wires are allowed to be externalto the module A. In this case, all wires (andalso sensors and actuators) of module A mustmechanically fit module B.

3.4 Computational Dimension

In the TORP structure, a robot is a set of nodesin a network. Hence, each single robot modulecarries its own computational unit that has nolimitation on the technology besides the fact thatit has to connect to other modules through acommon network protocol, defined for the projectfamily. Although all kinds of computer boards ormicroprocessors boards can be used, the followingrequirements must be respected:

1. Position: the computational unit must physi-cally fit the module. There is an exception forthe main controller, that can be embedded inthe robot or not;

2. Functionality: the computational unit must beable to fully control all module sensors andactuators;

3. Communication capability: the computationalunit must be able to communicate with othermodules according to the TORP communica-tion protocol;

4. Alone/network use: the module must be ableto work in the robot network as well asin a stand-alone mode (without the othermodules);

5. Services: the computational unit must provideservices to the robot network, that can beused by other instances and unities. Theseservices are regulated by the communicationprotocol;

6. Internal states and monitoring: the computa-tional 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 andexteroceptive information. In other words, themodule must keep up to date internal stateswith information continuously obtained fromits sensors and actuators, as well as monitoringstatus information (board temperature, mod-ule inclination, etc.).

The coordination of the set of modules, herebycalled the main controller, can be represented asa device embedded in the robot in one of itsmodules or as a device remotely linked to therobot through the network. It is important toremark that the communication protocol is tech-nology independent and it is implemented overa network protocol defined for a specific TORPfamily.

3.4.1 Communication Protocol

In order to allow the communication among themodules, a communication protocol was estab-lished. This protocol considers that the TORPmodules communicate among them according tothe network structure presented in Fig. 3. In thisstructure, each module with its native processorunit is linked to the others through a networksuch as Ethernet, CAN, etc. The controller pre-sented can be a module in the robot or an external

computer that will run as the main coordinatorof the system. In the protocol, every time a newmodule is plugged into the system it has to beregistered in the network. Then, a connection tothe main controller is established and data can besent following the TORP protocol.

There are seven types of messages that can becommunicated: CHECKIN, ACTION, GETSTA-TUS, STATUS, SETCONF, CONF and CHECK-OUT. Each one of these messages exchangeinformation between the modules and the maincontroller. A set of messages sent to/from a mod-ule should be enough to return all informationrequired and to perform all actions for that mod-ule. Every message should end with a ENTERcharacter.

1. CHECKIN message: this message is sent bythe module when it is plugged in the network.Its structure is: CHECKIN [MODULE name][IP value PORT n] [TYPE type(EXPANSI-BLE/TERMINAL)] [SONS n(used only forexpansible)] [FATHER moduleName] [TMPid POS x,y,z] [TMP idn POS x,y,z] [MOUNTn] [MAXCURRENT value(float)] [VOL-UME v] [MASS m] [CG cg] [IX ix] [KX kx][SENSOR type NAME n POS x,y,z] ... [SEN-SOR typen NAME n POS x,y,z] [ACTUA-TOR type NAME n POS x,y,z DIR x,y,z] ...

Fig. 3 Different networkconfigurations for aTORP family.Left Architecture with anexternal non-embeddedcontroller running overEthernet. (Center)Architecture with anexternal non-embeddedcontroller running overCAN. Right Architecturewith internal embeddedcontroller running overEthernet

J Intell Robot Syst

[ACTUATOR typen NAME n POS x,y,zDIR x,y,z] where:

MODULEthe module name TYPEthe module type: expansible or

terminal SONSthe module maximum number

of sons FATHERthe module in which the cur-

rent module is mounted TMPnthe id and position of the stan-

dard 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 themodule and their relative position tothe standard plug of the module

ACTUATORthe list of actuators withthe quantity of each one present in themodule and their relative position to thestandard plug of the module

2. ACTION message: this message is sent bythe main controller to the module any timeit needs an action to be performed by theexisting actuators. Every action message re-turns an OK message (zero) or an ERRORmessage (non-zero). There are many actionmessages possible, according to the actuatorsregistered in the system, and others can beadded without any loss in the protocol. Thefollowing ACTION messages were designedby abstracting the most important features ofthe common actuators used in robotics.

ACTION [MOVE MOTORTYPE] [NAMEid] [DEGREES n]... [NAME id] [DE-GREES n]

ACTION [MOVE MOTORTYPE] [NAMEid] [DEGREES n] [SPEED s] ... [NAMEidn] [DEGREES nn] [SPEED sn]

ACTION [MOVE MOTORTYPE] [NAMEid] [DEGREES n] [TIME t] ... [NAMEidn] [DEGREES nn] [TIME tn]

ACTION [STOP MOTORTYPE] [NAMEid] ... [NAME idn]

ACTION [TORQUE MOTORTYPE][NAME id] [VALUE ON/OFF] ... [NAMEidn] [VALUE ON/OFF]

ACTION [LED MOTORTYPE] [NAMEid] [VALUE ON/OFF] ... [NAME id][VALUE ON/OFF]

ACTION [DISPLAY IMAGEDEVICE][NAME id] [IMAGE name] ... [NAMEidn] [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] [VALUER,G,B]

ACTION [CLEAR LEDRGB] [NAMEid] ... [NAME idn]

ACTION [SOUNDON/OFF SPEAKER][NAME id] ... [SOUNDON/OFF SPEAK-ER] [NAME id]

ACTION [PLAY SPEAKER] [NAME id][VALUE ...] ... [NAME id] [VALUE ...]

ACTION [PLAYFILE SPEAKER] [NAMEid] [VALUE FILENAME] ... [NAME id][VALUE FILENAME]

3. GETSTATUS message: this message is sentby the main controller to a sensor in orderto acquire information regarding its readings.The GETSTATUS message is followed by anSTATUS message from the module contain-ing the required information.

GETSTATUS [SENSOR type] [NAMEid] ... [SENSOR typen] [NAME idn]

4. STATUS message: this message is sent by asensor or actuator that contains sensors tothe controller any time a GETSTATUS mes-sage is received. The current list of sensorsregistered is formed by: gps, sonar, infra-red,touch, compass, accelerometer, force, temper-ature, camera, microphone. There is also the

J Intell Robot Syst

possibility of having the sensors from the mo-tors sending their status. Additional sensorscan be included in the list.

GpsSTATUS [SENSOR GPS] [NAMEid] [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 COM-PASS] [NAME id] [DATA]

AccelerometerSTATUS [SENSOR AC-CELEROMETER] [NAME id] [AXES n][Data x,y,z]

ForceSTATUS [SENSOR FORCE][NAME id] [DATA value]

TemperatureSTATUS [SENSOR TEM-PERATURE] [NAME id] [DATA temp]

CameraSTATUS [SENSOR CAMERA][NAME id] [FORMAT type] [RESOLU-TION value] [DIMENSION x,y][BYTES n][DATA ...]

MicrophoneSTATUS [SENSOR Micro-phone] [NAME id] [FORMAT type][RESOLUTION value][DIMENSION x,y][BYTES n] [DATA ...]

5. SETCONF message: this message is sent bythe controller to a sensor or actuator in orderto change its operating mode, return type, etc.It is followed by a confirmation sent by thesensor or actuator.

SETCONF [SENSOR name][NAME id][PARAMETER x][TYPE value]...[SEN-SOR namen] [NAME idn] [PARAME-TER xn][TYPE valuen] [ACTUATORname] [NAME idn] [PARAMETER x][TYPE value]...[ACTUATOR namen][NAME idn] [PARAMETER xn][TYPEvaluen]

6. CONF message: this message is sent by thesensor or actuator to the controller in orderto respond to a SETCONF message.

CONF [SENSOR name] [NAME id][STATUS OK/ERROR]

7. CHECKOUT message: this message is sent bythe module when it is plugged off.

CHECKOUT [MODULE name]

The process of packing data into the protocolformat and parsing the data received is carried outboth in the main controller and inside the modulesby their processing unit.

4 Examples of TORP Applications

It is important to state that a new TORP familycan be defined for any class of robots. This sectionpresents a hypothetical TORP family for wheeledrobots and a more detailed case study for a TORPfamily of humanoid robots, with the implementa-tion of CP01.

4.1 A TORP Family for Wheeled Robots

For this family, consider that the following mod-ules were defined: body, vision and laser. Thebody module could be represented by a commer-cially available robot like a P2DX [1] that has anembedded CPU running a unix-based operatingsystem. In this way, this body model would com-prise sonars, IR, bump sensors, odometers and 2wheels. The vision module could be representedby a camera mounted in a platform with 2 DOF.Finally, the laser module could contain a laserscanner. Mechanically, the base module offers me-chanical plugs to other modules connect to. Thevision and laser modules are both terminal mod-ules since they do not provide mechanical con-nections to other modules. In this configurationboth modules, vision and laser, are external oncethey are mounted outside the structure of the basemodule. Considering the electrical dimension, thebase module is initial since it contains the systempower source and it is expansible of order 2, onceit provides electrical energy to vision and lasermodules, that are electrically classified as termi-nal. If this project follows a TORP module-basedapproach, all modules should have their process-ing units, acting according to their needs, com-municating through the system network. In thisexample, the vision module would be responsiblefor having all knowledge regarding how to drive

J Intell Robot Syst

its motors to position the camera according tothe commands sent by the main controller. In thesame way, the body module would be responsiblefor acquiring information from all its sensors aswell as for driving the robot.

Consider now that the differential wheels in thebody module will be replaced by omnidirectionalones. In this case the body module would be theonly one to suffer with these modifications. Inthe same way, if an extra DOF is added to thevision module, this module would be responsiblefor controlling this new DOF. The generalizationachieved by the application of the framework overa traditional robotics model is the major benefit ofTORP. The application of the electrical, mechan-ical and computational standards proposed allowthis new system to become reconfigurable, modu-lar and interchangeable, at the cost of additionalhardware and software layers.

A TORP specification set for this family isdetailed in Table 2. Additionally, the specificationfor the mechanical and electrical plugs would berequired. As for the power limitations, as thebase module was defined electrically as initial, thevoltage/current specifications for the family couldbe defined by it: 12V@7.2A. The network protocolwould be Ethernet.

The following subsection presents another ap-plication of TORP for a different class of robots.

4.2 Case Study: CP01 Humanoid Robot

TORP is a generic framework for a large rangeof robots. Although it is a feasible framework, itsapplication is difficult on small-size robots due tolimitations in current technology, like electronicboard sizes, that imply constraints to the self-contained modules. Its immediate applications to

large robots, like humanoid robots, however, is fareasier.

In order to perform a concept proof of TORPthis section describes the implementation ofa humanoid robot, named CP01. The TORPfamily for this robot was idealized as follows:(i) standard mechanical plug designed to sup-port efforts related to humanoid robot motions(Table 1); (ii) electrical specification (Table 1),and (iii) Computational Dimension based onTCP/IP communication.

Figure 4 presents the CAD design of CP01 ro-bot, first robot implemented based on the TORPspecification set. In its current version, it is a23 DOF robot with head, two arms and chest,envisioning future leg expansion, although dueto the use of the TORP framework, a wheeled,a caterpillar, a n-footed or any other low bodyassembly could also be used. CP01 was designedfor human-robot interaction research. Its bodydimensions, particularly its long neck, were pur-posely designed to permit robots face approxima-tion to human interactor, allowing diverse novelsocial behaviors. The full project was designedaccording to open-hardware and open-softwareconcepts, 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 mechanicalconnection classification are shown in Table 3.Figure 5 presents a connection diagram, in theelectrical and mechanical dimensions, betweenmodules.

4.2.1 CP01 Electrical Dimension

One of the most important implications of usingTORP 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 DOF: 2Electrical: initial, expansible of order 2 Sensors: sonar, ir, odometer, bumpers

Vision Mechanical: external, terminal DOF: 2Electrical: terminal Sensors: camera

Laser Mechanical: external, terminal DOF: 0Electrical: terminal Sensors: laser

J Intell Robot Syst

Fig. 4 CP01 mechanicalCAD drawing.a Assemblythree-dimensional view;front-view. b Side-view

(a) (b) (c)

sizing and distribution along the robot. As dis-cussed in Section 2, the average power expectedfrom a humanoid robot is lower than 3 kW.In order to attend usual motors and regulatorsspecifications, a 48 V power source was adoptedfor the TORP family of CP01 robot. This voltagelevel in mentioned in humanoid robots domainand expected currents for its usual power wouldbe about 60 A considering all actuators simul-

taneously activated. To fit these requirements, a8 AWG 3.3 mm diameter cable was used in allmodules and a Molex mini-fit 8 AWG plug familywas adopted as the standard electrical plug forthe whole robot. Once powered, each module wasresponsible for regulating voltage for its internalneeds. Regarding electrical specifications, thereare 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 DOF: 2Electrical: expansible of order 1 Sensors: none

Chest Mechanical: external, expansible of order 4 DOF: 0Electrical: initial, expansible or order 4 Sensors: accelerometer, sonar

Arms Mechanical: external, terminal DOF: 6Electrical: terminal Sensors: accelerometer

Head Mechanical: external, terminal DOF: 3Electrical: expansible or order 3 Sensors: accelerometer

Image Mechanical: internal, terminal DOF: 0Electrical: terminal Sensors: camera

Sound Mechanical: internal, terminal DOF: 0Electrical: terminal Sensor: none

Facial Mechanical: internal, terminal DOF: 3Electrical: terminal None

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 expansi-ble of order 3 (head). Gumstixs Verdex PROwere adopted as embedded devices in all modulesdue to their small size (2 cm 8 cm) and highcomputational power (Marvell PXA270 400 MHzXScale processor). There was an exception forGumstix RoboAudio, that was adopted in thesound module. Regulators and sensor/actuatorcontrollers SMD boards were specially designedto fit these project requirements.

4.2.2 CP01 Mechanical Dimension

In order to conduct a proof of concept with re-spect to the possibility of building a common me-chanical plug to a humanoid robot, a very simpleconnectorshown in Fig. 6was proposed andmachined for the TORP family of CP01 robot.This plug is basically composed by two aluminumtubes with a mechanical interlocking. Aiming aquick 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 com-pressed into the tube, allowing disengagement.Once released, both are expelled by the spring totheir original places. Since buttons tend to be thepoint of maximum mechanical stress, they weremanufactured in steel instead of aluminum dueto its well known high shear strength. The oppo-site end of tubes were strongly fixed in moduleschassis. Dynamixel AX-12, RX-64 and EX-106servomotors and as general purpose micro servo-motors were adopted as the motors of CP01.

4.2.3 CP01 Communication and ComputationalDimension

CP01 robot modules were modeled as nodes ina Ethernet-TCP/IP network and a router was in-serted in the chest module. CP01 software wasdivided into two parts: (i) inside modules and (ii)controller software. Inside each module, to allowfuture changes of hardware without significantchanges, CP01 follows the multilayer softwaredevelopment. Each module contains a Gumstixwith Linux Open Embedded OS running, and aNet Pro VX with wi-fi for communication. Foreach module, three levels of code were designed:(i) The low level: refers to direct access to pins,ports and hardware elements (serial, timer, re-set, etc.); (ii) The medium level: refers to macrocommands that can be sent to the peripheralsconnected to the control board. For example, theset of low levels commands that are sent to thehardware to perform a move in a servo withspecific speed, and (iii) The high level: refers tothe packing/unpacking commands that parser the

messages sent/received through the network interms of medium level commands. For all levels,the code was written in C++. The basic classstructure of the system is represented in Fig. 7.In the following code example, Module is theclass that contains all sensors and actuators im-plementation. This class is responsible for receiv-ing/sending the information from/to the networkconnection, calling the appropriate commands.

Sample code for CP01 software embedded inmodules.

/******* High level function *******/void Module::checkData() {string lastDataFromServer;

this->serverSocket->receive(lastDataFromServer,500);

string str = lastDataFromServer;// Checks for messagesif (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);

}}

}

Fig. 7 Basic class-diagram for module internal code

J Intell Robot Syst

(a) (b)

Fig. 8 CP01 Control software. a Interface control withno module connected. In this representation, the color ofthe modules sketch and the absence of visual informationindicate that no module has been plugged in the system.

b As modules are plugged, the color of the sketch changesand the information received trough the check-in messageregarding 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 servochar *parameter;parameter = new char[2];parameter[0] = P_RETURN_DELAY_TIME;

//adress to writeparameter[1] = rdt;

//new adress to be setupsendGeneralCmd

(INST_WRITE,parameter,2);//send the command

}/******* Low level function *******/int Tserial::getArray

(char *buffer, int len) {unsigned long read_nbr;

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 com-puter external to the robot. The controller wasbuilt in Java with the Java 2D API for the graphi-

cal interface. The software is responsible for keep-ing track of each module connected. In Fig. 8athere is a monitoring window where no module isconnected. As the modules open their connectionwith the controller and send a CHECKIN mes-sage, the data is interpreted by the control systemand the characteristics of the module (sensors,

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 orderto evaluate the additional vibration induced in the arm by the addition of the standard plug

actuators, etc.) are presented. Figure 8b showsmodules plugged into the system. Once a modulehas checked in into the system, the main controlleris responsible for requesting up to date infor-mation of the modules through GETSTATUSmessage. The module answers to the controllerwith a STATUS message. Then, the informationreceived is parsed in the controller so that itsgraphical interface shows the current status of themodule. In this way, the controller software is ableto visualize and control each module individuallyor 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 whenestablishing a standard mechanical plug instead

of perfectly clumping parts, an experiment wasconducted. The movement sequence for this ex-periment can be seen in Fig. 10. In this experi-ment, a 3-axis accelerometer was inserted in theshoulder-arm link, just after the TORP Mechani-cal Plug, in such a way that vibration effects couldbe observed. Figure 11 presents the voltage versustime graphs returned by the accelerometer in its3-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 indicatethat a low vibration was inserted by the plug in thesystem. However, its amplitude cannot be under-stood as significant for robots that do not requirea very precise positioning system, as that requiredfor industrial or domestic general purpose robots.Considering the scenario where the robot armstructure weights approximately 2 kg and mea-sures 0.7 m, moving at low speed with a small

(a) (b) (c)Fig. 11 Accelerometer measurements in all three axis for slow (a), medium (b) and high (c) shoulders motors movementvelocities. 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 steelYield strength are about 97 and 294.8 MPa, respectively

load, it is reasonable to expect that the mechanicalplug will not be subject to a force greater than1,000 N. Following this assumption, experimentaldata obtained with computer simulations for ten-sile, compressive and flexion analysis for a 1,000 Nload on the aluminum-steel connector shown inFig. 12, did not present significant mechanicaldeformation, showing that this first version of amechanical plug attends the project mechanicalrequirements.

5 Results and Discussion

The feasibility of the proposed methodologyfor real world robots was demonstrated throughthe building of CP01. Experimental results havedemonstrate that robot mechanical abilities arenot significantly affected by the TORP architec-ture, and that there is at least one set of me-chanical plug, electronics and communication ap-paratus able to satisfy specification requirements.Besides the functional modification that can becarried in the TORP robots through the replace-ment of modules, the aesthetics of the robot canalso be fully modified by the exchange of modules.For CP01, a new and smaller head will be usedso the robot can have more stability once legs areadded.

Taking into consideration that TORP frame-work does not limit mechanical nor electrical con-nectors, as well as network technologies, it is rea-sonable to expect that new families of robots withbetter implementations can arise in the future andthat some of them can become new standards forcertain robot classes.

One of the most serious difficulties faced in theproject was on the design of the power regula-tion boards, far more complex than usual and inthe limit of the available technologies consideringsize/power relation.

Although the work to setup a robot project tothe TORP specification set is hard, the advantagesthat overcome this initial trouble are tremendous.First of all, the re-use of hardware and softwareparts in new robots or versions is an easy taskif the robots belong to the same TORP family.Moreover, the modular architecture provides aneasy way to compare parts of robots. For instance,distinct models of arms, legs, grippers and others,can be evaluated regarding their speed, responsetime, energy consumption or even control aspectsin the same platform. Yet, groups with differentexpertise and using different technologies can ap-ply their developments in the same robot. Thebefore mentioned advantages of the proposedframework present possible ways to overcome thehistorical drawbacks in robot design and still have

J Intell Robot Syst

full compatibility with previously proposed robot-ics operating systems and frameworks.

One can argue that the connection of moduleswith distinct mechanical properties might be im-practical for control purposes of the whole assem-bly. In fact, this would be a serious constraint ifthe information regarding the mechanical aspectsof the module was not informed to the main con-troller by the module itself. With this information,special control techniques can be future investi-gated to assign robustness to the system.

Finally, it is fair to observe that this module-based framework is better suitable for medium/high size robots due to constraints regarding cur-rent mechanical and electrical technologies.

6 Conclusions and Future Work

This paper summarizes the specification of a newframework, TORP, proposed for modular collab-orative robot projects. The focus in TORP robotsis shifted from components to functional level,creating an abstraction between high and low levelcontrol, not only in the computational dimensionbut also in the mechanical and electrical. It doesnot contradict previous standardization, but ex-tends them to new dimensions. At the best of ourknowledge, this work represents the first proposi-tion of standardization at all these dimensions inrobotics.

It is also important to mention that the cost ofthe application of this protocol in a robot projectis the insertion of redundancies in all dimensions,that have impact in robot budget. In fact, onecan argue that it would be cheaper and quickerto connect sensors and actuators directly to thecontroller. In fact, this reasoning was valid also forPCs in the early 70s. The advantages of such stan-dardization work in long term. It is also importantto keep in mind that TORP direct applicationsare for robots build in collaborative situations, i.e.,where multiple institutions with different interestsand skills want to build a unique robot. However,any project can adopt this methodology.

In order to upgrade the framework, some im-provements are in progress: (i) a new version ofthe mechanical plug that incorporates the electri-cal cables, (ii) simpler self-designed boards for the

modules to reduce the overall project budget, and(iii) development of control strategies suitable forapplication in TORP robots domain.

Finally, we do not claim that TORP is a finalmethodology. Although we believe such standard-ization could have a deep impact on the way webuild robots, we are sure that it represents justa first step on the direction of the discussion ofnecessary standardization in the robotics field.

Acknowledgements Authors gratefully acknowledgethe contribution of Rafael Ribeiro, Victor Nalin, AlanMorgensztern, Kaue Cruz, Daniel Baggio, WilsonCanazart, Rafael Chiafarelli and Raphael Bartholo Costa.Authors would also like to thanks Mauricio Leal, SilveiraNeto and Bruno Souza for developing the remoteinterface. CP01 robot was named after Campus Party,event supported by Futura Networks, that welcomedthe project and made this research possible. CP01 wassponsored by Micropress.

References

1. Active Media Robotics: P2dx robot. http://www.mobilerobots.com/ (2010)

2. Aghili, F., Parsa, K.: A reconfigurable robot withlockable cylindrical joints. IEEE Trans. Robot. 25(4),785797 (2009)

3. Baillie, J.C.: Urbi: towards a universal robotic low-level programming language. In: IEEE/RSJ Interna-tional 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 Program-ming 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 Experi-mental Robotics. Springer Tracts in Advanced Robot-ics, vol. 30, pp 231251. Springer Berlin, Heidelberg(2007)

6. Bruyninckx, H., Soetens, P., Koninckx, B.: The real-time motion control core of the Orocos project.In: IEEE International Conference on Robotics andAutomation, pp. 27662771 (2003)

7. Gerkey, B., Vaughan, R., Howard, A.: The player/stageproject: tools for multi-robot and distributed sensorsystems. In: Proceedings of the 11th International Con-ference on Advanced Robotics, pp. 317323 (2003)

8. Hu, Y., Wang, L., Zhao, W., Wang, Q., Zhang, L.:Modular design and motion control of reconfigurablerobotic fish. In: IEEE Conference on Decision andControl, 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

humanoid robot Albert HUBO. In: International Con-ference on Intelligent Robots and Systems, pp. 14281433 (2006)

10. Kaneko, K., Kanehiro, F., Kajita, S., Hirukawa, H.:Humanoid robot HRP-2. In: Proceedings of the IEEEInternational Conference on Robotics and Automation(2004)

11. Kim, J.Y., Park, I.W., Oh, J.H.: Realization of dy-namic stair climbing for biped humanoid robot usingforce/torque sensors. J. Intell. Robot. Syst. 56(4), 389423 (2009)

12. Lund, H., Henningsen, A., Nielsen, R.: Modular ro-botic system as multisensory room in childrens hospi-tal. In: Proceedings of 14th International Symposiumon Artificial Life and Robotics (ISAROB) (2009)

13. Madden, J.D.: Mobile robots: motor challenges andmaterials solutions. Science 318(5853), 10941097(2007)

14. Metta, G., Fitzpatrick, P., Natale, L.: Yarp: yet anotherrobot platform. Int. J. Adv. Robot. Syst. 3(1), 4348(2006)

15. Metta, G., Sandini, G., Vernon, D., Natale, L., Nori,F.: The iCub humanoid robot: an open platform forresearch in embodied cognition. In: PerMIS: Per-formance Metrics for Intelligent Systems Workshop,pp. 1921 (2008)

16. 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 foreducation in engineering. In: Proc. of the 9th Conf. onMobile Robots and Competitions (ROBOTICA 2009),pp. 5965. IPCB: Instituto Politcnico de CasteloBranco, Castelo Branco, Portugal (2009)

17. Montemerlo, M., Roy, N., Thrun, S.: Perspectiveson Standardization in Mobile Robot Programming:The Carnegie Mellon Navigation (CARMEN) Toolkit,pp. 24362441 (2004)

18. Nof, S., Chen, J.: Assembly and disassembly: anoverview and framework for cooperation requirementplanning with conflict resolution. J. Intell. Robot. Syst.37(3), 307320 (2003)

19. Park, I.W., Kim, J.Y., Lee, J., Oh, J.H.: Mechanicaldesign of the humanoid robot platform, HUBO. Adv.Robot. 21(11), 10351322 (2007)

20. Pivtoraiko, M., Nesnas, I., Nayar, H.: A reusable soft-ware framework for rover motion control. In: Interna-tional Symposium on Artificial Intelligence, Roboticsand Automation in Space. Los Angeles, CA (2008)

21. Quigley, M., Gerkey, B., Conley, K., Faust, J., Foote,T., Leibs, J., Berger, E., Wheeler, R., Ng, A.: Ros: anopen-source robot operating system. In: InternationalConference 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.: Ex-tending player/stage/gazebo towards cognitive robotsacting 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: systemoverview and integration. In: Proceedings of Interna-tional Conference on Intelligent Robots and Systems,pp. 24782483 (2002)

25. Seward, D., Bradshaw, A., Margrave, F.: The anatomyof a humanoid robot. Robotica 14(4), 437443 (2009)

26. Sproewitz, A., Asadpour, M., Billard, A., Dillenbourg,P., Ijspeert, A.: Roombotsmodular robots for adap-tive furniture. In: Proceedings of the IEEE/RASInternational Conference on Intelligent Robots andSystems (IROS). Workshop on Self-ReconfigurableRobots, Systems and Applications (2008)

27. Sproewitz, A., Billard, A., Dillenbourg, P., Ijspeert,A.: Roombots-mechanical design of self-reconfiguringmodular robots for adaptive furniture. In: IEEE In-ternational 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 TekkotsuCrew: teaching robot programming at a higher level. In:Proceedings of the Twenty-Fourth AAAI Conferenceon 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 self-reconfigurable robot systemschallenges and oppor-tunities for the future. IEEE Robot. Autom. Mag.,14(1), 4352 (2007)

34. Zykov, V., Chan, A., Lipson, H.: Molecubes: an open-source modular robotics kit. In: Proceedings of theIEEE International Conference on Intelligent Robotsand Systems (IROS) (2007)

35. Zykov, V., William, P., Lassabe, N., Lipson, H.:Molecubes extended: diversifying capabilities of open-source modular robotics. In: Proceedings of theIEEE Intelligent Robots and Systems 2008, Self-Reconfigurable Robotics Workshop (2008)

TORP: The Open Robot ProjectQ1Please check article title if captured correctly.AbstractIntroductionRobotics Frameworks: Overview and Future DirectionsHumanoid Robot Projects and Related Approaches

The Open Robot Project FrameworkTORP Specifications SetMechanical DimensionElectrical DimensionComputational DimensionCommunication Protocol

Examples of TORP ApplicationsA TORP Family for Wheeled RobotsCase Study: CP01 Humanoid RobotCP01 Electrical DimensionCP01 Mechanical DimensionCP01 Communication and Computational DimensionController SoftwareFinal Assembly Evaluation

Results and DiscussionConclusions and Future WorkReferences

/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 150 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages true /GrayImageDownsampleType /Bicubic /GrayImageResolution 150 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 1200 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages true /MonoImageDownsampleType /Bicubic /MonoImageResolution 600 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile (None) /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False

/CreateJDFFile false /Description >>> setdistillerparams> setpagedevice