Meetings 2012-03-01


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


  • 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?

Currently blocked by

  • Lack of naming service
  • Lack of support for hierarchical data


  • We probably need (at least) three protocols
    • Discovery of configurable components and configuration parameters
    • Monitoring of parameter changes
    • Modification of parameter values
  • These protocols should be implemented on top of the usual RSB mechanisms