[ros-users] New Parameter Server

Gonzalo Abella abellagonzalo at gmail.com
Wed Apr 17 01:07:37 UTC 2013

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

Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/ros-users/attachments/20130417/9358208b/attachment-0003.html>

More information about the ros-users mailing list