[ros-users] New Parameter Server

[rdean at gdrs.com]

First, separate it from the node and nodelet API. (not sure if this is in the gsoc description on not)
Second, api should include a mechanism to manually check for a parameter change i.e. not use callbacks. We write a large amount of real-time capable code, where callbacks are bad. ROS is not used for this code, our main interest in the matter is to increase interoperability/quality of code. A manual check simplifies thread safety and algorithm design.

The api should be as simple as possible. I have a configuration system which is similar in capability as what the GSoC is asking for (but I cannot share code but am allowed to discuss interfaces).  It is a singleton, where get() and set() are implemented as templates, and use polymorphism to handle either single or arrays of parameter values. Get also has a specialized "startup" version which allows setting of default values for metadata if the parameter does not exist.  Error codes are returned for all possible cases, no exceptions are thrown.

At startup:
   Configuration & config = Configuration::instance();
   double width;
   // either get the value, or add it to the store with value of 3.5 & the given description. As get is a template, internally it sets the type as double
   config.get("param name",width_,3.5,"width between points A and B");

At runtime:
   If (Configuration::instance().get("param name",width_) == rframe::Error::CHANGED)
            cout << "width changed to " << width << endl;

The values for each parameter are currently: key, value, comment, dirty, and type. Type is a enum mapping to int, bool, string, double, etc.
As the get<>() and set<>() calls are templates, there is no need for separate getTYPENAME calls to do the type conversion.  This is an aesthetic choice which simplifies the interface for us.

The singleton is nice as it allows threadsafe access to the configuration from anywhere in the code.  I do not currently support ranges for values.


From: ros-users-bounces at code.ros.org [mailto:ros-users-bounces at code.ros.org] On Behalf Of Dave Hershberger
Sent: Wednesday, April 17, 2013 5:09 PM
To: User discussions
Subject: Re: [ros-users] New Parameter Server

+1 on the project, I'm glad to see this getting attention!

For the Qt version of rviz, I wrote a property hierarchy system in C++ which I have been fairly happy with.

For example usage, see map_display.cpp: https://github.com/ros-visualization/rviz/blob/groovy-devel/src/rviz/default_plugin/map_display.cpp

That system uses Qt slots to receive notice of property changes when needed. (If Qt is undesirable you could probably go with Boost slots or even just member function pointers.)

The bit about rviz's property API that is perhaps unique is that the Property object actually owns the data.  That means any time you want one of the property values you say something like "width_property_->getInt()" or "name_property_->getString()".  What is returned by the Property object is always the latest value.  If you need to learn about updates, you don't need any parameters coming through the update function, because you can just ask the parameter object for the latest value from inside the update function.  This felt simpler to me than requiring API users to implement get/set functions for every parameter, which is how it had been implemented before.

Dave

On Wed, Apr 17, 2013 at 12:43 PM, Thibault Kruse <kruset at in.tum.de<mailto:kruset at in.tum.de>> wrote:
I found my draft rep, and now put it on github:
https://github.com/tkruse/rep/blob/nodeparam/nodeparam-REP.rst

Note this was work in progress when I stopped working on it.

Other things I considered back then:
- whether to support complex parameter types like poses (rather than just primitive values)
- how to organize parameter naming (I think there were some inconsistencies between rospy and roscpp around the '~')
- using the same system for logger levels
- grouping of parameters instead of having flat lists
- whether to support batch updates of multiple parameters as one operation (e.g. when parameter validation would else deadlock changing two interdependent parameters)

cheers,
  Thibault

_______________________________________________
ros-users mailing list
ros-users at code.ros.org<mailto:ros-users at code.ros.org>
https://code.ros.org/mailman/listinfo/ros-users


-------------------------------------------------------
This is an e-mail from General Dynamics Robotic Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130422/70c4d96f/attachment-0004.html>