Meetings 2012-03-01¶

Announcements¶

• Documentation at http://docs.cor-lab.org
• Release of RSB 0.6 within the next few days

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

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?

Currently blocked by¶

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

Implementation¶

• 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