[ros-users] New Parameter Server

[Austin Hendrix]

I think the most important thing to consider with respect to the 
parameter server is the 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