An Open Source Extensible Software Package to CreateWhole-Body Compliant Skills in Personal Mobile Manipulators

Roland Philippsen∗, Luis Sentis†, and Oussama Khatib∗∗Stanford University, †University of Texas at Austin

Abstract— Whole-body operational space control is a pow-erful compliant control approach for robots that physicallyinteract with their environment. The underlying mathematicaland algorithmic principles have been laid in a large bodyof published work, and novel research keeps advancing itsformulation and variations. However the lack of a reusableand robust shared implementation has hindered its widespreadadoption.

To fill this gap, we present an open-source implementationof whole-body operational space control that provides runtimeconfigurability, ease of reuse and extension, and independencefrom specific middlewares or operating systems. Our librariesare highly portable, and the application code contains athin adaptation layer for specific development and runtimeenvironments such as ROS.

In this paper, we briefly survey the foundations of whole-bodycontrol for mobile manipulation and describe the structure ofour software. We performed experiments on two quite differentrobots to demonstrate that the software is mature enough forbuilding a community of users and developers who can workon extensions and applications.

I. INTRODUCTION

The foundations for controlling robots that physicallyinteract with objects and persons in environments madefor humans have been investigated for approximately threedecades. In addition to recognizing and developing therequired mechatronic capabilities, such as backdriveable ac-tuation and effective control of output torques, this large bodyof work provides mathematical and algorithmic foundationsfor creating robotic skills similar to those of humans in termsof movement coordination, stiffness regulation, and contactwith the environment. However, despite the availability ofmechatronically advanced manipulators such as the KUKALWR, Barrett WAM, and Meka arm, this knowledge is onlyslowly making its way into applications. These machines in-dicate a definite trend toward robots better suited for physicalinteraction with everyday environments, and we believe thatthe remaining hurdle in producing agile interactive robot ap-plications now lies in the complexity of the required modelsand the difficulty of producing reusable extensible softwareframeworks that provide advanced control methodologies.

To address this hurdle, we launched the stanford-wbcopen-source project in 2009, with the aim of making thewhole-body operational-space formulation developed at theStanford Robotics and AI Lab [17], [12] readily availablefor widespread reuse. In this paper, we present the firstfruits of our effort to design, implement and test a softwarepackage for compliant whole-body control, complete withresources to create complex mobile manipulation behaviors

Fig. 1. To date, the stanford-wbc software has been integrated onUT Austin’s Dreamer and Willow Garage’s PR2, which are quite distinctin their mechatronics as well as their development and runtime systemenvironments.

by composition and extension. Having worked with open-source robotics software and frameworks such as ROS,Player/Stage, XCF, GenoM, and Orocos, we understand theneed for robust, flexible, and documented foundations thatcan be re-composed in application-specific ways, and ourobjectives explicitly include these non-technical challenges.

The project homepage is http://stanford-wbc.sourceforge.net which contains announcements, doc-umentation, mailing list archives, and links to downloadsource code releases and clone the git repository. Themajority of the source code is released under the LGPLv3license [3], with some third-party code under other licenses.

To date, we have integrated the project on two robots(Fig. 1): within the ROS-based control architecture on PR2 atWillow Garage and Stanford; and on Dreamer at Universityof Texas at Austin within the RTAI shared-memory interfaceprovided by Meka Robotics. The approach underlying oursoftware has been applied to other robots, such as PUMA andASIMO, and back-porting stanford-wbc to these systemswould be easy.

II. RELATED WORK

There is a large body of work that focuses on modelsand control structures. Torque control strategies include thework of Khatib [11] and the German aerospace center,DLR [6], [14], the latter focusing on impedance control ofsemi-flexible robot arms. At the whole-body level, torquecontrol has been applied by Mizuuchi et al. for complianttendon contraction [13], by Whitman and Atkeson [20] tocoordinate multiple optimal controllers for achieving com-plex behaviors, by Hyon [8] for compliant multi-contact, andourselves [16] for the execution of whole-body skills. Posi-tion control strategies still dominate the field; at the whole-body level, they include work at AIST (e.g. momentum-

based models by Kajita et al. [9]), on the Honda Asimo (e.g.inverse kinematic position control coupled with an invertedpendulum model by Hirai et al. [5]), and on Reem-B ( inversekinematics approach by Tellez et al. [19]).

The research underlying stanford-wbc focuses onmodels of whole-body compliant skills and on hierarchicalcontrol structures that resolve task conflicts during execu-tion [16], [18]. These rely on contact interactions for manip-ulators, especially results on dynamics and force control byKhatib [10] and Raibert and Craig [15], as well as our workon mobile and multi-grasp manipulation [7], [21], [1].

III. WHOLE-BODY CONTROL FOUNDATIONS

This section summarizes algorithmic foundations and in-troduces the main concepts of: (i) operational space tasks,(ii) their adaptive hierarchical arrangement into sensorimotorwhole-body skills, and (iii) the prioritized control structurewhich dynamically decouples tasks. Algorithm 1 in Sec. IV-B provides a dense summary in pseudo-code with simplifiednotation.

A task is defined via a mapping between the robot’s N -dimensional joint configuration and some M -dimensionalspace which describes an objective that the controller shouldachieve. For any joint configuration, the robot is considereda point in the M -dimensional operational space, and thetask controls the motion of this point. At this stage, a taskis a kinematic entity with an associated tangent space thatcan be represented by a Jacobian, which maps velocities andforces between joint and operational spaces.

For the (usual) case of N > M , a task-point definesa manifold in joint-space. This manifold represents theredundancy of the robot with respect to the task. We canexplore tangents to the current configuration to determinejoint-space motions which keep the task-point constant. Thisis referred to as the null space of the task, and it providesthe basis for task decoupling via projection.

In order to facilitate the management of tasks and hierar-chies, we introduce sensorimotor skills to translate betweenhigher-level goals (such as provided by planning algorithms)and the operational-space tasks. A skill is responsible forconfiguring the tasks such that an overall motion objective isachieved. Skills can be considered containers and managersof tasks, and the active skill provides the current taskhierarchy to the control structure.

The intuition behind the hierarchical control structureis is to instantiate several tasks, each of which tries todrive the robot toward some state. The task contributionsare accumulated using null space projections to ensure thatlower-priority tasks do not interfere with higher levels. Themotion is thus determined by each task in combination withtheir priorities. This structuring provides two orthogonalways of changing robot behavior, either by influencing thetasks (e.g. changing their gains or goals) or by rearrangingthe hierarchy (e.g. inserting tasks or locally inverting theirordering).

The model of the robot under prioritized control wasdeveloped in [16] which provides the generalized Jacobian

Fig. 2. Architectural overview of the Whole-Body Control software.SV stands for singular values, Tdes is the desired joint-torque vector, and{qact, qact, Tact} are the actual joint positions, velocities, and torques. Therest of the notation is the same as in Algorithm 1.

of an operational task for a given priority, written

J∗k|Pk, Jtaskk

NPk, (1)

where Jtaskkis the Jacobian of the k-th level task manifold

with respect to an inertial frame,

NPk, I −

k−1∑i=1

J∗i|Pi

J ∗i|Pi(2)

is the recursive dynamically-consistent null space describingthe task’s k-th priority state, k|Pk is used to express that thek-th task operates in the null space of all higher priority tasks,and J

∗i|Pk

is the dynamically consistent generalized inverseof the i-th prioritized Jacobian. The Principle of VirtualWork allows us to determine the torques that accomplishan operational force:

Γk = J ∗Tk|PkFk (3)

where Fk is the force or impedance command to controland interact with the task point, J∗k|Pk

is the whole-bodytask Jacobian including the priority, and Γk is the task’scontribution to the whole-body command of torques sent tothe actuators. For command summation, we use the controlstructure

Γ =∑k

Γk =∑k

(J ∗Tk|Pk

Fk

). (4)

This structure is a variant of our previous work on whole-body compliant control [18].

IV. IMPLEMENTATION

We adhere to three main objectives during the design andimplementation of stanford-wbc: (i) separate concernsinto mathematical foundations, runtime configurability, andindependence from specific implementation environments;(ii) support two types of end-users, namely control integra-tors (library support for creating interesting applications) andresearchers (investigate and modify models and control struc-tures); (iii) ease experimentation and system integration by

ReflectionController

init(model)computeCommand(model,*skill)

Skill

init(model)update(model)getTaskTable()lookupSlot(name)declareSlot(name,**slot)

Task

init(model)update(model)getCommand()getJacobian()

Fig. 3. Controllers, skills, and tasks follow a similar layoutby providing init() and update() methods (the latter is calledcomputeCommand() in the controller to make its role more explicit).

providing reusable mechanisms for data logging, parameterreflection, and interactive online configuration.

We follow the tried and trusted separation into layeredlibraries that are then pulled into OS- and application-specificexecutables. We rely on object-oriented programming (C++)to allow extension by inheritance and composition. Whilerelying on some widespread open-source libraries, we care-fully avoid dependencies on any particular middleware oroperating system. We strive to avoid feature bloat and keepall interfaces clear and minimal.

This section begins with a high-level architecturaloverview, then presents the code structure from the bottomup, and finally describes the patterns and utilities for objectcreation during startup and on-line reconfiguration of therunning tasks and skills.

A. System Architecture

Fig. 2 depicts the main components of our framework andthe information that flows during operation. The Controllerimplements Eq. (4) to compute the torque commands Γdesthat are sent to the robot, based on the Jacobians Ji andthe desired accelerations xdes,i or forces Fdes,i that areprovided by the Task objects in the currently active taskhierarchy. The Model estimates the joint-space kinematicsand dynamics, used by tasks for internal updates and by thecontroller for gravity compensation and dynamic decoupling.The Skill is responsible for determining the currently activetask hierarchy. The latter is denoted current state in the figurebecause hierarchy switching is typically implemented usinga finite-state machine that processes external sensorimotorfeedback as well as internal task feasibility information.

The system architecture diagram hints at the runtimeconfigurability and reflection capabilities by indicating pa-rameter lists associated with the skill, tasks, and the con-troller. These parameters are declared with type and namein the source code, and at runtime they can be enumerated,inspected, and changed by outside processes.

B. Implementation Structure

Fig. 3 shows the main aspects of the controller, skill, andtask base classes. The common Reflection base classprovides uniform parameter introspection capabilities whichare described in Sec. IV-C.

Algorithm 1 Hierarchical Task Decomposition (simplified).Input: joint-space inverse mass-inertia A−1

joint-space gravity torque vector gdesired task accelerations xdes,itask Jacobians Ji

Output: joint-space torque vector ΓΓ← 0N∗

0 ← In×n

for all 0 ≤ i < Ntasks doJ∗i ← JiN

∗i

Λ∗i ←

(J∗i A−1J∗T )+++

p∗i ← Λ∗i J

∗i A−1g

Fcomp,i ← Λ∗i J

∗i A−1Γ

Γ← Γ + J∗iT (Λ∗

i xdes,i + p∗i − Fcomp,i)if i < Ntasks − 1 then

N∗i+1 ←

(In×n −A−1J∗

iT Λ∗

i J∗i

)N∗

i

end ifend forreturn Γ

Algorithm 1 gives simplified pseudo-code for the mainmethod (called computeCommand) of the default Con-troller subclass. Here, the “(·)+++” denotes a pseudo-inversecomputed by singular-value decomposition and thresholdingat a task-dependent and configurable value. Several havebeen omitted from the pseudo-code: task feasibility feedbackto the skill, switching to a safe fallback controller in case ofemergency, and skipping of inactive tasks.

The Model is a facade [4] that hides the specifics of thekinematic and dynamic model behind a clear interface. Someof its methods involve pointers that can be treated as opaquehandles but provide direct access to the dynamics engine forexperts.

The Task class is the extension point for programmingoperational-space controllers independently of the specificrobot. Each task takes care of controlling a point in a virtualtask space that is mapped to and from the robot’s joint spaceusing the model.

The Skill base class is the starting point for composingspecific tasks into sensorimotor skills that result in compliantwhole-body behavior of the robot. A skill instance is respon-sible for updating its tasks and providing a valid fully definedtask hierarchy at each control cycle. One intuitive way ofimplementing skills is to define a finite set of states, eachwith an associated task hierarchy, and have the skill performstate transitions based on sensor readings or other feedbackmethods, but the software framework does not enforce anyparticular task management approach.

Although a skill defines what needs to be coordinatedby the tasks and the hierarchy, it (usually) does not definespecific goals. Instead, a skill definition file is parsed tocreate and configure the required tasks, and their goals andparameters get influenced at runtime using the reflectionapproach described in Sec. IV-C.

Besides providing tasks to the controller, skill classes cansignal emergency situations by inspecting the singular valuesof J ∗i J ∗Ti computed by the controller. When an essentialtask becomes infeasible, the controller can be asked to switch

Reflection

check(*parameter,value)lookupParameter(name)getParameterTable()declareParameter(name,*instance)

Parameter

get()set(value)

ConcreteParameterParameterLogger

update(timestamp)writeFiles(prefix)

Fig. 4. Parameter reflection infrastructure. There are five types ofConcreteParameter: string, integer, floating point, vector, and matrix.

Task SkillSlot

assign(*instance)getInstance()

ConcreteTask

SpecialTask

ConcreteSkill SpecialSlotT

Fig. 5. Task slots allow skill subclasses to declare a placeholder for atask, and then rely on the parser and factory (not shown) to assign a taskinstance at runtime when the controller starts up.

to a configurable safe fallback control law.

C. Configurability and Reflection

One of the most important features to make a softwareframework reusable by others is runtime configurability. Forreal-time capabilities, however, computational overhead isalso important. We have thus traded-off generality, amountof code, and computational resources. Two features makestanford-wbc configurable: parameter reflection and taskslots.

Parameter reflection (see Fig. 4) connects the imple-mentation to the parser and runtime configuration engine.The provided infrastructure maintains named parameters andalso provides generic logging capabilities. A subclass ofReflection exposes its fields as parameters simply bycalling the declareParameter() method of its baseclass. Optionally, parameters can be flagged read-only orexcluded from automatic logging, and reflection subclassescan intercept write requests to enforce arbitrary constraints.

Task slots (see Fig. 5) allow skills to be written indepen-dently of specific task subclasses or instances, a separationof concerns important for extensibility and reusability. Forinstance, if a skill requires a certain task to control the end-effector position, it should not be concerned how exactlya task achieves this. So, instead of hard-coding task types,skill subclasses call the declareSlot() method in theirconstructor, passing a name and a pointer to one of theirtask fields. The rest is handled by the parser and factory: theconfiguration file first defines tasks and their parameters, andthen instantiates skills fills their slots with the appropriatetask instances. In case of type mismatch, human readableerror messages are generated.

-1

0

1

2

3

4

5

6

7

8

9

0 5000 10000 15000 20000 25000 30000 35000joint angle [rad] / cond. numbers

time [ms]

task feasability monitoring on Dreamer

elbow angleeepos log(s3/s1)

posture s2

Fig. 6. Task-singularity monitoring on Dreamer. When the elbow isstretched out, the end-effector position task becomes infeasible (its conditionnumber becomes infinite) and the joint posture task gains an extra dimension(its second eigenvalue becomes non-zero).

V. EXPERIMENTS

In order to demonstrate the portability ofstanford-wbc and its basic operation, we have performedexperiments on two robots which differ significantly fromeach other, in terms of their mechatronics as well asconcerning their development and runtime environments.

Dreamer is a humanoid upper body made by MekaRobotics for the Human-Centered Robotics Lab at the Uni-versity of Texas at Austin. Its joints contain series-elasticactuators that provide high-fidelity torque control. Here,stanford-wbc is integrated with an RTAI applicationthat has one real-time whole-body control thread whichcommunicates via shared memory with the hardware driver,and one non-real-time thread for runtime configuration anddebug output.

The second robot we used is PR2 at the Stanford Roboticsand AI Lab, a dual-arm mobile manipulator made by Wil-low Garage. PR2 ships with ROS [2] and we integratedstanford-wbc along with related packages into a ROSstack called whole body control. We implemented aROS controller plugin that uses POSIX message queuesas communication mechanism between real-time driver andnon-real-time whole-body control application.

A. Studying Task Feasibility on Dreamer

As explained earlier, if parts of a task become infeasible,its dynamically consistent Jacobian drops rank. This is notalways a problem: in fact, many if not most of the tasks willbe partially infeasible, and this is naturally handled by thecontrol structure. It is up to the skill to ensure that the oneswhich are critical to the behavior remain at full rank.

Fig. 7. Demonstration of the interactive HelloByebyeSkill onDreamer, the Meka robot of the University of Texas at Austin, during ashow and tell at Willow Garage on March 4, 2011.

In order to illustrate how readily available the requiredinformation is, Fig. 6 shows a skill with three tasks: an end-effector orientation task at the top, an end-effector positiontask in the middle, and a joint posture control at the bottomof the hierarchy. The orientation task is always feasible(this is a property of Dreamer’s kinematic structure). The3-dimensional position task thus has 4 dimensions to workin. It might be expected that it is always full rank, butdue to kinematic singularities, some directions of the end-effector position can become uncontrollable. This is shownby the plots of the condition number, which shoots up aswe manually push the arm toward specific configurations.The joint posture controller, which gets projected into thenullspaces of both the orientation and position tasks, thushas between 1 and 2 dimensions to work with. This can beseen by looking at its 2nd singular value, which is non-zeroonly when the end-effector position task drops rank.

B. Interactive Skill Demo on Dreamer

Fig. 7 shows some video stills from demonstrating aninteractive skill. The HelloByebyeSkill contains fourtasks subdivided among two states: the SHAKE HANDS

and WAVE states each have a Cartesian end-effector posi-tion tasks and a joint-posture task. The skill starts in theSHAKE HANDS state which holds the robot’s hand out infront of the torso, waiting for a human to shake it to “sayhello.” Once that ends (detected by looking at the end-effector position error), the skill switches to the WAVE statewhich “waves goodbye” by alternating between two end-effector position goals above the robot’s head.

This behavior was written in an afternoon and is fullyintegrated into the parameter reflection and task slot mech-anisms. It thus illustrates how easy it is to extend theexisting framework with novel behaviors while leveragingthe existing tasks and infrastructure for wider system in-tegration: we also implemented a thin bridge between theparameter reflection of stanford-wbc and ROS messagesand services, thus allowing direct interaction with the runningwhole-body controller via the ROS command line tools orother ROS nodes.

C. Compensating for Motor Saturation on PR2

One of the main objectives for the mechatronic designof PR2 was to make the arms extremely safe. This wasachieved by relying on a mechanical counter-balance forgravity compensation, which in turn allows the arm motors

-2

-1.5

-1

-0.5

0

0.5

1

1.5

2

0 500 1000 1500 2000

join

t an

gle

[rad

]

time [ms]

all joint positions, shoulder-pan setpointmaxacc = 10000

-2

-1.5

-1

-0.5

0

0.5

1

1.5

2

0 500 1000 1500 2000

join

t an

gle

[rad

]

time [ms]

all joint positions, shoulder-pan setpointmaxacc = 10

Fig. 8. In this experiment we send a step in the setpoint to the shoulder-pan joint of the left arm of PR2. All other joint setpoints remain constant.The setpoint and trajectory is shown with a thick line, and all the otherjoint trajectories overlaid with thin lines in order to show the coupling(before) and its absence (after). Top: without acceleration limit. Bottom:with xmax = 10rad/s

to be very low-powered. While this is great for safety, itseverely limits the control torques, especially in the first4 degrees of freedom. This motor torque saturation, alongwith running-belt stretch in some of the transmissions, arethe main reasons for the difficulties in using whole-bodyoperational space control on PR2. A naive application ofstanford-wbc leads to arm motions that are reminiscentof excessive dynamic coupling and severely under-dampedPD controllers.

The experiments shown in Fig. 8 demonstrate that thesemechatronic limitations can be partially overcome: therunning-belt stretch can be compensated with experimentalPR2 controller packages provided by Willow Garage, andmotor torque saturation can be avoided by limiting theacceleration of task points. Moving just the first joint with asimple PD controller creates large coupling in all the otherjoints, but if we generate acceleration- and velocity-boundedtrajectories, the coupling disappears almost entirely.

More work remains to be done to make the accelerationlimitation adaptive during task execution. Also, the implica-tions of the nullspace projections on acceleration-boundedtask-points are not yet fully understood. But we have shownthat it is possible to employ whole-body control on PR2 aslong as the required fidelity is not very high.

D. Demonstrating Base-Velocity Integration on PR2

An important aspect of mobile manipulators is of coursethat they are not bolted to a fixed base. Fig. 9 shows video

Fig. 9. Translating errors in the end-effector position and orientation intovirtual torques at the base, and then translating these torques into basevelocity commands using a viscosity approximation, allows to easily controlthe robot by pushing and twisting its hand.

stills taken during a demonstration of our integration ofPR2’s base velocity controller into the whole-body controlframework. We use 3 virtual joints to represent the base mo-tion to stanford-wbc via a simple yet effective dynamicmodel that treats the base as a large mass in a purely viscousmedium. This maps desired torques into velocities which wesend to PR2’s base velocity controller.

VI. CONCLUSION

The much-touted advent of personal robots that willphysically and safely interact with people and objects ineveryday environments is not likely to come about unless westart employing mechatronics and control approaches that aredesigned from the ground up to properly deal with forces anddynamics. Many (if not most) of the required principles arenow sufficiently understood, and recent commercial hardwaredevelopments for mobile manipulation indicate that the re-quired technology is within our grasp. The whole-body con-trol software presented in this paper leverages an advancedcontrol approach that inherently supports physical interactionand can handle multiple competing control objectives in avery flexible manner. With the release as an open-sourceproject, we are fostering its widespread adoption for upcom-ing developments, for research as well as for applications. Inparticular, the ROS stack which integrates our core librarieswith an executable that uses the controller plugin architecturedeveloped for PR2, significantly lowers the entrance barrier.Our experimental results show once again that whole-bodycontrol works, but this time the implementation is availableto a large community of roboticists for testing, use, andmodification.

ACKNOWLEDGEMENTJosh Petersen implemented PR2 code for handling motor torque satura-

tions and base velocity integration. Samir Menon, Francois Conti, TorstenKroger, and Ellen Klingbeil contributed to design discussions and earlyrefactoring attempts. Kurt Konolige, Gunter Niemeyer, Eric Berger, StuGlaser, Sachin Chitta, John Hsu, Aaron Edsinger, and Robby Kelbs providedvaluable support, technically as well as for the project in general.

REFERENCES

[1] K.C. Chang and O. Khatib. Operational space dynamics: Efficientalgorithms for modeling and control of branching mechanisms. InProceedings of the IEEE International Conference on Robotics andAutomation, April 2000.

[2] S. Cousins, B. Gerkey, K. Conley, and W. Garage. Sharing softwarewith ros [ros topics]. Robotics Automation Magazine, IEEE, 17(2):12–14, june 2010.

[3] Free Software Foundation. LGPLv3 (GNU Lesser General PublicLicense version 3). http://www.gnu.org/licenses/lgpl.html.

[4] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.Design Patterns: Elements of Reusable Object-Oriented Software.Addison-Wesley, 1995.

[5] K. Hirai, M. Hirose, Y. Haikawa, and T. Takenaka. The developmentof Honda humanoid robot. In Proceedings of the IEEE InternationalConference on Robotics and Automation, volume 2, pages 1321–1326,Leuven, Belgium, 1998.

[6] G. Hirzinger, J. Bals, M. Otter, and J. Stelter. The dlr-kuka successstory: robotics research improves industrial robots. Robotics Automa-tion Magazine, IEEE, 12(3):16 – 23, sept. 2005.

[7] R. Holmberg and O. Khatib. Development and control of a holonomicmobile robot for mobile manipulation tasks. International Journal ofRobotics Research, 19(11):1066–1074, 2000.

[8] Sang-Ho Hyon. A motor control strategy with virtual musculoskele-tal systems for compliant anthropomorphic robots. Mechatronics,IEEE/ASME Transactions on, 14(6):677 –688, dec. 2009.

[9] S. Kajita, F. Kanehiro, K. Kaneko, K. Fujiwara, K. Harada, K. Yokoi,and H. Hirukawa. Resolved momentum control: Humanoid motionplanning based on the linear and angular momentum. In Proceedingsof the IEEE/RSJ International Conference on Intelligent Robots andSystems, pages 1644–1650, Las Vegas, USA, October 2003.

[10] O. Khatib. Commande Dynamique dans l’Espace Operationnel desRobots Manipulateurs en Presence d’Obstacles. PhD thesis, l’EcoleNationale Superieure de l’Aeronautique et de l’Espace, Toulouse,France, 1980.

[11] O. Khatib. A unified approach for motion and force control ofrobot manipulators: The operational space formulation. InternationalJournal of Robotics Research, 3(1):43–53, 1987.

[12] O. Khatib, L. Sentis, and J. Park. A unified framework for whole-body humanoid robot control with multiple constraints and contacts.In Springer Tracts in Advanced Robotics - STAR Series, Prague, CzechRepublic, March 2008.

[13] I. Mizuuchi, Y. Nakanishi, Y. Sodeyama, Y. Namiki, T. Nishino,N. Muramatsu, J. Urata, K. Hongo, T. Yoshikai, and M. Inaba. Anadvanced musculoskeletal humanoid Kojiro. In Humanoid Robots,2007 7th IEEE-RAS International Conference on, pages 294 –299,dec. 2007.

[14] Christian Ott. Cartesian impedance control of redundant flexible-jointrobots. Springer, 2008.

[15] M.H. Raibert and J.J. Craig. Hybrid position force control ofmanipulators. ASME J. Dyn. Sys. Measurement Contr., 103(2):126–133, 1981.

[16] L. Sentis and O. Khatib. Synthesis of whole-body behaviors throughhierarchical control of behavioral primitives. International Journal ofHumanoid Robotics, 2(4):505–518, December 2005.

[17] L. Sentis and O. Khatib. A whole-body control framework forhumanoids operating in human environments. In Proceedings of theIEEE International Conference on Robotics and Automation, Orlando,USA, May 2006.

[18] L. Sentis, J. Park, and O. Khatib. Compliant control of multi-contactand center of mass behaviors in humanoid robots. IEEE Transactionson Robotics, 26(3):483–501, June 2010.

[19] R. Tellez, F. Ferro, S. Garcia, E. Gomez, E. Jorge, D. Mora, D. Pinyol,J. Oliver, O. Torres, J. Velazquez, and D. Faconti. Reem-B: Anautonomous lightweight human-size humanoid robot. In HumanoidRobots, 2008. Humanoids 2008. 8th IEEE-RAS International Confer-ence on, pages 462 –468, dec. 2008.

[20] E.C. Whitman and C.G. Atkeson. Control of instantaneously coupledsystems applied to humanoid walking. In Humanoid Robots (Hu-manoids), 2010 10th IEEE-RAS International Conference on, pages210 –217, dec. 2010.

[21] D. Williams and O. Khatib. The virtual linkage: A model for internalforces in multi-grasp manipulation. In Proceedings of the IEEEInternational Conference on Robotics and Automation, pages 1025–1030, Atlanta, USA, October 1993.