On Wed, Apr 17, 2013 at 11:25 AM, Austin Hendrix <legotown@aol.com> wrote:
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:Agreed. As I see it, this priority hierarchy is already part of the system.
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+1 to redis
brief summarize:
- But (a possibility), rely on a simple key-value DB as Redis to
minimize development/maintenance.
- Priorities to initialize parameters: (0) default values, (1) launchNot sure why the server needs to worry about this. Parameters get set
files, (2) parameter server, (3) command line. +number -> +priority
whenever someone sets them. Not your responsibility, its under user
control.
Agreed on all counts.
The params lifecycle is a tricky problem. I think the best solutionBeware: in the existing implementation, parameters live and die with
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.
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.
-Austin
--
joq
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users