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