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@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@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
(text/plain)