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.

---