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
- 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?
- 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:
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 intervalI'm also playing around with stuff like:
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.
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
- How does communication occur? - What types are supported? - How to make the GUI more pleasant?
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.