Pure Coordination Using the Coordinator-Configurator Pattern

Pure Coordination using theCoordinator–Configurator Pattern

3rd International Workshop on Domain-Specific Languages and modelsfor ROBotic systems

M. Klotzbuecher1 Geoffrey Biggs2 Herman Bruyninckx1

1Department of Mechanical EngineeringKatholieke Universiteit Leuven

Belgium

2Intelligent Systems Research InstituteAIST, Japan.

November 5, 2012

Pure Coordination using the Coordinator–Configurator Pattern

National Institute ofAdvanced Industrial Science

and Technology

AIST

Introduction

Context: coordination in component based systems.

Coordination supervises and monitors functional computations.

Commonly used coordination models: FSM, Petri-nets, Statecharts,SFCs.

Common practice: in a Coordination FSM:

Call methods/operations (move to)Change parameters (e.g. set a gain)Start and stop components. . .



and Technology

AIST

Problem Statement

The common practice of tightly integrating the action execution within theCoordinator has three disadvantages:

1 Reduced resuability of Coordinator due to pollution with platformdependent information.

2 Reduced determinism of Coordinator

Logical (no separation between logical and platform specific error).Temporal (due to blocking calls).. . .

3 Reduced robustness of Coordinator: crashing or indefinite blockingof calls will render Coordinator inoperative.



and Technology

AIST

Approach: Coordinator-Configurator Pattern

Split “rich” coordinator intoPure Coordinator andConfigurator.

Coordinator commands andmonitors via events only.

Configurator is configured witha set of Configurations that itapplies upon receiving therespective event.

Success or failure is likewisereported via events.

computation

computation

computation

Configurator

Coordinator

command events status events

start/stop

configure

call



and Technology

AIST

The Role of the DSL

Formalization: A language to express theConfigurator–Configuration; Shields Coordinator from:

Software platform specific details (e.g. how to change a property)Hardware platform specific details (e.g. how a specific gripper isopened)

Encourages construction of reusable Coordinators by introducing:

A dedicated language to model changeThe Configurator as a dedicated entity to apply change

The approach is independent of the specific coordination model used.



and Technology

AIST

Case study: dual youbot coupling

Two KuKA YouBots coupledusing impedance control.

Safe behavior: switch to gravitycompensation upon exceeding aforce threshold orcommunication breakdown.



and Technology

AIST

Component structure

youbot_driver

Coordinator

computation

Cart_Impedance

Dynamics

youbot_coupling

e_force_thres_exceeded/below

CartForceDes CartPosMsr

CartPosDsr

commlat

eQoS_change

heartbeat_in

heartbeat_out

command events status events

Configurator

connected to CartPosMsr of peer Youbot

Connected to CartPosDsrof peer Youbot



and Technology

AIST

Coordination Statechart (subset)

unsynchronized andsynchronized modelwhether the communicationquality is sufficient or not.

Switch betweengravity comp and copyingdepending on the current forces.

Impedance control and gravitycompensation are enabled uponentering and exiting copyingrespectively.

coupling coordination

unsynchronized

synchronized

e_QoS_OK e_QoS_NOTOK

gravity_comp

copying

[ above_force_thres() ]

[ ! above_force_thres() ]

entry: enable_copying(true)exit: disable_copying(false)



and Technology

AIST

The DSL implementation: Configurator–Configuration

Configuration {disable_copying = Configuration{

port_write("Cart_Impedance.ext_ref_mode", false)},

enable_copying = Configuration {port_write("Cart_Impedance.ext_ref_mode", true)

},

eight_DOF = Configuration {property_set("Dynamics.force_gain", {0.1, 0.1,

0.1})},

five_DOF = Configuration {property_set("Dynamics.force_gain", {0, 0, 0})

},}



and Technology

AIST

Side node: Unifying Deployment and Coordination

Observation:

By extending the Configurator withprimitives for instantiating components,deployment and startup can be naturallyexpressed as just another case of runtimeCoordination.

create_components

configure_components

start_components

e_create_components_OK

e_configure_components_OK



and Technology

AIST

Conclusions

The coordinator-configurator pattern enables:

Reusability, by encapsulating software and hardware platformspecifics in the Configurator–Configuration.

Increased determinism, by separating commanding and execution.

Higher robustness of the Coordinator, by shielding it from theexecution of actions.

Deployment is reduced to just an other case of run-time coordination.



and Technology

AIST

Thanks

Questions?

Acknowledgements This research was funded by the European Community

under grant agreements FP7-ICT-231940 (Best Practice in Robotics), and

FP7-ICT-230902(ROSETTA), and by K.U.Leuven’s Concerted Research Action

Global real-time optimal control of autonomous robots and mechatronic systems.



and Technology

AIST

Documents

Pure Coordination Using the Coordinator-Configurator Pattern