[ros-users] New Parameter Server

William Woodall william at osrfoundation.org
Wed Apr 17 18:38:05 UTC 2013

On Wed, Apr 17, 2013 at 11:25 AM, Austin Hendrix <legotown at aol.com> wrote:

> I think the most important thing to consider with respect to the parameter
> server is the API;


All of this is good input, but the (proposed) goal of the GSoC is to come
up with a better way to declare, initialize, and interact with parameters
which lands squarely on configuration and API, but not necessarily
implementation details. The GSoC calls specifically for C++ API to be
redesigned, but something to consider is the Python API which would be an
obvious extension to the work proposed.

Implementation details will obviously drive or constrain the API in subtle
ways, but are less important at this stage. If the result of the project is
a standalone solution then it can be rolled out along side the existing ROS
parameters with an implementation based on the current ROS ecosystem. If
the design calls for more extensive changes to existing ROS constructs
(like changes to the master, replacing the parameter server, or extensive
changes to roscpp) then we will have to make decisions based on backwards
compatibility. Either way we will use this design in the ROS2.0 effort
where we can make a cleaner API without as many problems with API

> in particular, the python API is very good, and you can easily retrieve
> and work with any subtree of the parameter server namespace, and easily
> store lists within a parameter. Doing similar operations from C++, by
> comparison, is very cumbersome, requiring manual manipulation of the XMLRPC
> data structures and manual casting or conversion operations.
> It would also be nice to see an API where dynamic parameter updates can
> replace dynamic reconfigure. Ideally, it would be cool to have proxy
> objects for parameters, and have the API deal with updating the proxies
> whenever the underlying parameters change. The API will probably need to
> provide a few locking/snapshot functions around parameters to make this
> work properly.
> +1 to being able to capture parameter state with rosbag; parameters are an
> important part of a ROS system. For my use-case (calibration), being able
> to capture parameters such as the active URDF is important.
> A few more responses inline:
> On 04/17/2013 07:22 AM, Jack O'Quin wrote:
>> On Wed, Apr 17, 2013 at 8:06 AM, Gonzalo Abella <abellagonzalo at gmail.com>
>> wrote:
>>> Thank you very much for your answers. They are all pretty helpful. A
>>> brief summarize:
>>> - But (a possibility), rely on a simple key-value DB as Redis to
>>> minimize development/maintenance.
>> +1 to redis
>>  - Priorities to initialize parameters: (0) default values, (1) launch
>>> files, (2) parameter server, (3) command line. +number -> +priority
>> Not sure why the server needs to worry about this. Parameters get set
>> whenever someone sets them. Not your responsibility, its under user
>> control.
> Agreed. As I see it, this priority hierarchy is already part of the system.
>>  The params lifecycle is a tricky problem. I think the best solution
>>> would be a combination of both live/die with paramserver and live/die
>>> with parent. It is reasonable to have global parameters which do not
>>> depend on any node (or depend on the ROS Master). But other
>>> parameters, such as private params, are meaningless and they should be
>>> removed from the param server.
>> Beware: in the existing implementation, parameters live and die with
>> the parameter server (currently roscore). That is often useful.
>>   * I often find myself starting roscore first just so I don't have to
>> reload parameters every time I test some node.
>>   * Sometimes parameters may be adjusted during node execution. If they
>> are destroyed when the node terminates, we lose the opportunity to
>> save them somewhere for the next session.
>>   * For general compatibility, interface issues like this should not be
>> changed without a compelling reason.
> Agreed on all counts.
> -Austin
>  --
>>   joq
>> ______________________________**_________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/**listinfo/ros-users<https://code.ros.org/mailman/listinfo/ros-users>
> ______________________________**_________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/**listinfo/ros-users<https://code.ros.org/mailman/listinfo/ros-users>

William Woodall
ROS Development Team
william at osrfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130417/77d9b0bc/attachment-0004.html>

More information about the ros-users mailing list