[ros-users] New Parameter Server

rdean at gdrs.com rdean at gdrs.com
Tue Apr 23 13:29:34 UTC 2013


Before I continue, is there a discussion forum (google whatever)? Or is this the place for it?

The backend is just looking up the full string, regardless of what the node name or namespace may be. As such there is no loss of namespace hierarchy in the config store.  So the question is how to handle remapping. In my case each module has a "name()" method which holds the assigned/remapped name.  Looking up the config value is then config.get(name()+"height",height,42,"costmap height in cells");

Everything in the architecture has a name and unique id to aid with debugging and diagnostics. Looking at doxygen pretty much all my code inherits from rframe::NameId class. As a result, N instances of an algorithm can be instantiated separately from the messaging system, access their subset of the global configuration, and uniquely log output (to a log file, not over the network, that's another discussion).

Alternatively, a local configuration instance could be allocated with the namespace prefix, and prepend it to queries which are then forwarded to the singleton (or server).
Configuration config("/move_base/local_costmap"):  // config knows it is not the singleon due to how it is constructed
config.get("height",height);

Essentially what node param does, but as a separate functional component. As such, the overall interface is more modular, and is therefore more interoperable due to separation of concerns.

-Bob

From: ros-users-bounces at code.ros.org [mailto:ros-users-bounces at code.ros.org] On Behalf Of Dave Hershberger
Sent: Monday, April 22, 2013 4:32 PM
To: User discussions
Subject: Re: [ros-users] New Parameter Server

rdean's system sounds pretty convenient, but I wanted to point something out about these two aspects:

First, separate it from the node and nodelet API.
...
The singleton is nice as it allows threadsafe access to the configuration from anywhere in the code.

With the existing rosparam system, parameters live in a tree of namespaces.  ROS code can load parameters using a nodehandle which was named, which name can have been remapped from the command line or from a launch file, and both of these can change the prefix of the parameter names.  This is powerful and desirable, as it reduces name conflicts and allows code to be reused in new ways.

For example, there is a parameter who's full name is "/move_base/local_costmap/height".  In the costmap code, the parameter-reading function only needs to specify "height".  The code is used two times in the same executable - there is also a "/move_base/global_costmap/height" parameter, and they don't interfere with each other because of the namespaces.

It seems to me that if you separate rosparams from the Node/Nodelet API, you'll need a separate way to manage namespaces.  If you use a singleton, you remove the capability for having config objects which represent different parts of the tree, and thus each piece of code will need to know the full path of its parameter names.

Of course you could have a config singleton which is just the root of the tree, but then you lose a lot of the convenience of having a singleton, since you need to carry around a pointer to your current location in the tree.

Anyway, I don't want to say I know what the API should be, but I wanted to point out this very useful feature of the existing API.

Dave

On Mon, Apr 22, 2013 at 12:32 PM, <rdean at gdrs.com<mailto:rdean at gdrs.com>> wrote:
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> [mailto: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.

_______________________________________________
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/20130423/ef87ca6f/attachment-0004.html>


More information about the ros-users mailing list