Robotics Service Bus

h1. Meetings 2012-03-01

h2. Scope of the Configuration Service

* Supply parameter values for components running in a system

* Components expose parameters

** Parameters consist of

*** Name

*** Type

**** Complex values have to be possible: e.g. arbitratry Protocol buffer types, array of joint velocities)

*** Current value

*** Default value (supplied by component?)

** Provided functionality

*** Parameter values and default values can be queried

*** Parameter values can be reset to default values

*** Parameters can be updated from outside

h2. Requirements

* Has to be suitable for component layer (e.g. CCA)

* Component developers should not have to handle parameter updates explicitly

** However, parameter updates should be interceptable via callbacks

* Distributed implementation

** No central "Parameter Server"

** Tools monitor, update parameters

*** Tool may need internal model/cache of the whole configuration system

* Hierarchical organization of parameters

** Groups? Trees?

** Integrated with naming service?

** Structured values should support partial and full updates/notifications

   (e.g. only transfer, notify sub-elements of composite values in case of partial change)

* Complexity of asynchronous updates should be hidden from component developer, if possible

** Components need local copies of parameter values despite async parameter updates

** How does ROS solve this?

h2. Currently blocked by

* Lack of naming service

* Lack of support for hierarchical data

h2. Implementation