[ros-users] New Parameter Server

[Jack O'Quin]

+1

On Tue, Apr 16, 2013 at 8:59 PM, Ken Conley <kwc at kwc.org> wrote:
> 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
>>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>



-- 
 joq