I think it would be best if we move this to a SIG for discussion, as not to
flood the ros-users mailing list.

I have setup one here:

http://www.ros.org/wiki/sig/Parameters

You'll find the mailing list and other links on that page, I would
encourage any stakeholders to join that mailing list and follow
the discussion there.

Thanks!


On Tue, Apr 23, 2013 at 6:29 AM, <rdean@gdrs.com> wrote:

>  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@code.ros.org [mailto:
> ros-users-bounces@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@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@code.ros.org [mailto:
> ros-users-bounces@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@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@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@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@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>


-- 
William Woodall
ROS Development Team
william@osrfoundation.org
http://williamjwoodall.com/