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.
> 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.
--
joq
(text/plain)