API review

Proposer: Blaise Gassend

Present at review:

  • Brian Gerkey
  • Eric Berger
  • Vijay Pradeep
  • Stu Glasser
  • Blaise Gassend
  • Jeremy Leibs
  • Ken Conley
  • Josh Faust (Add yourself if I forgot you.)

Question / concerns / comments

Stu

  • Feel free to move these notes once a review page is created.
  • One of your requirements is: "The server code can adjust the parameter values it is given if they are illegal." Does this include parameters that were on the parameter server when the node is started?
  • What if only certain parameters are reconfigurable? Is there any way to tell beyond noticing if setting them fails?

Vijay

  • Comment: We need to think past 'drivers'. We have a huge number of processing pipelines that could use reconfiguration.
  • Can we use this to tune gains in PID controllers
  • Does Reconfiguration level make sense when not talking about hardware?
    • I'd guess that with processing nodes, there might not be a linear scale of levels, but rather, different actions need to be taken, based on what set of params is reconfigured. This could maybe be solved by a node simple having multiple sets of reconfigurable params.
  • Param server feels slow. Impossible to drag the slider around in reconfigure_gui
  • Messages would give way more expressiveness. I'm currently using this message to reconfigure:

    SettlerConfig.msg

    string[] joint_names   # Names of the joints we're waiting to settle
    float64[] tolerances   # Tolerance on each of the specified joints
    duration max_step      # The maximum timestep between two elements in an interval
    uint32 cache_size      # The size of our cache when searching for an interval
    I'm also playing around with stuff like:

    CheckerboardPipelineConfig.msg

     CbDetectorConfig detector_config
     SettlerConfig settler_config
  • Could we somehow skip all the C++ code gen, even if that means stripping out some functionality?
  • Is doing a ready-modify-write really that bad? This would remove the need for key-value pairs in the reconfigure message.

Melonee

I spent some time using the reconfigure_gui yesterday with the hokuyo and I basically have requests for features for the reconfigure_gui.

  • anytime a device is selected in the gui the hardware configuration should be given to the gui so that illegal/irrelevant operations can't be made. For example currently when using the hokuyo 04LX the intensity is still selectable even though the laser can't return intensity. I would expect that this option would be grayed out for this laser and not selectable.
  • a help panel that displays what each parameter does or something similar to rviz that links to the ROS API documentation with the param list.
  • Notification on failing requests

Meeting agenda

- How does communication occur? - What types are supported? - How to make the GUI more pleasant?

Conclusion

No real concensus was reached on what the real right way of doing things is. We are going to add a few features to the existing system, and use it for a while to see what people think.

  • /!\ Change "level" to "changemask".

  • /!\ Support setting parameters via a topic or a service call depending on whether the client wants blocking or not.

  • /!\ Add support for list of basic types and for a yaml type.

  • /!\ Some kind of support for limiting what the GUI will allow would be useful but not clear what the right general system is yet.


Wiki: dynamic_reconfigure/Reviews/10-29-09 Proposal Review API Review (last edited 2009-10-29 23:13:24 by BlaiseGassend)