Cool.  Some more things to throw out there:

 * One thing that let me to Redis was I was also experimenting with TTL.  This seemed to be an interesting concept (e.g., expiring an 'initialized' parameter/calibration/pose).  Wasn't sure if it would be useful, but it was at least interesting.
 * Another thing that led me to Redis was its support for Sets.  These Sets are very powerful; e.g. Instagram uses Redis Sets to represent the photos you see in your stream.

And finally:

 * Right now you're motivated to extract the Parameter Server from the Master. I agree that it's useful to decouple them.  But, to warp things a bit, a Redis-backed, TTL supporting Key/Value store would make a great backend for a master.  i.e., the Master is little more than a special set of Parameter APIs using Sets, TTLs, and PubSub.

cheers,
Ken



On Wed, Apr 17, 2013 at 7:22 AM, Jack O'Quin <jack.oquin@gmail.com> 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.

> 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
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users