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