[ros-users] New Parameter Server

[Ken Conley]

Back in the day, I did some experiments on replacing the Parameter Server
with Redis.  If the Redis-based system was detected, the clients could
switch to the Redis protocol, which has much less overhead.

I'm more dubious in switching the Parameter Server to a full-blown
database, or, at least, I think you will have something very different by
the end of it.  To me, the Parameter Server is just a config server, and
making it better means putting more config there, and making things like
Dynamic Reconfigure work better.  One thing that would make it a better
config server is to make it possible to shuttle ROS messages back and forth
between it, while trying to find the happy balance between namespaces and
hierarchical config messages.  ROS is currently sparse on config-oriented
messages, and they are one mechanism that could lead to less
parameter-related errors, such as misspellings.

If clients need an actual database, they should use a database.  There's
many different requirements in choosing a database and it seems a non-goal
to have the Parameter Server serve all those possible needs.

HTH,
Ken



On Tue, Apr 16, 2013 at 6:17 PM, Ryan Gariepy <
rgariepy at clearpathrobotics.com> wrote:

> Personally, I would like the API and launchfile syntax to be kept as
> simple as possible. Adding a static parameter isn't much extra typing over
> and above defining a constant, but promotes much more reusable prototype
> code. I've never personally said "There is too many parameters in this
> node", but have often said "why is <CONSTANT> not a parameter". Ideally,
> the dynamic reconfiguration could be taken right from the code, no manual
> building of a .cfg required.
>
> -Ryan
>
>
> On Tue, Apr 16, 2013 at 9:07 PM, Gonzalo Abella <abellagonzalo at gmail.com>wrote:
>
>> Dear community
>>
>> My name is Gonzalo Abella. I am going to apply for the Google Summer of
>> Code program. For those who does not know about what I am talking about,
>> GSoC is a program where Google awards stipends to students who successfully
>> complete a requested free and open-source software coding project during
>> the summer. Here you can find more info [1]. There is a project which I
>> find very interesting:
>>
>> "Develop new Parameter API for C++ ROS client"
>> Description: ROS has a concept called parameters, which are settings for
>> individual computational “nodes”. Currently the built-in parameter system
>> in ROS statically sets the parameters at launch time and cannot be changed
>> during runtime. There is an additional system called Dynamic Reconfigure
>> which allows ROS nodes to define dynamic parameters, but this system
>> requires that the parameters be defined outside of the normal ROS parameter
>> API and is not integrated into the ROS C++ client API. This task would be
>> to redesign the built-in ROS parameter system for C++ into a functional
>> prototype which combines the normal static parameters with the Dynamic
>> Parameter’s feature set. There are several features that need to be tackled
>> for this project, for example: having callbacks for when parameters change,
>> lock on access for the parameters (thread safety), grouping of parameters,
>> and how to define the valid ranges for parameter values. The goal is a
>> working prototype which can be used for ROS 2.0 work, but which could be
>> back ported into ROS 1.0 if the new system can be implemented alongside the
>> existing one or the changes to the existing system are minimal.
>>
>> With this description I have a pretty good idea of the goal of the
>> project. I also have an initial idea of how I would do it. But because this
>> is a community and it is you who are going to use the new Parameter Server
>> at the end of the project, I would like to know your opinions in order to
>> propose a better project (and do it if finally I get selected). Do you miss
>> any feature? How would you improve the Parameter Server?
>>
>> For example, I think it could be interesting to decouple the Parameter
>> Server from the ROS Master. The reason to do so is to increase its
>> functionality. We could have two implementations and use the one that
>> better suit for you. There is a simple by default implementation. Useful
>> when you don't have many parameters. The other implementation could use a
>> distributed key/value DB. It is useful when you have many parameters and to
>> use the Parameter Server as a database. If the underlying DB is
>> distributed, the DB would be highly scalable. What do you think? Does it
>> fit in the project scope?
>>
>> I would appreciate any opinion/suggestion/advice/commentary. Thank you
>> very much.
>>
>> Best regards,
>>       Gonzalo
>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130416/0766e3e1/attachment-0004.html>