[ros-users] New Parameter Server

Dave Hershberger hersh at willowgarage.com
Mon Apr 22 20:31:34 UTC 2013


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> 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] *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> 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
> 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
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130422/d5acf6e7/attachment-0004.html>


More information about the ros-users mailing list