[ros-users] New Parameter Server

Wed Apr 17 13:06:43 UTC 2013

Thank you very much for your answers. They are all pretty helpful. A
brief summarize:

- API and launch files, KISS
- Dismiss the idea of  a full-blown DB.
- But (a possibility), rely on a simple key-value DB as Redis to
minimize development/maintenance.
- Check GSettings and QSettings to get ideas.
- Use services (as main communication channel) and topics (to notify
nodes when a parameter changes) so as to reuse existing tools (rosbag,
rviz).
- Priorities to initialize parameters: (0) default values, (1) launch
files, (2) parameter server, (3) command line. +number -> +priority
- Parameters lifecycle: live/die with paramserver, live/die with
parent, combination ?? This one is difficult.

Thibault, It would be great if you can find and send me that draft. I
am sure I am missing a lot of things and your experience can help me a
lot.

The params lifecycle is a tricky problem. I think the best solution
would be a combination of both live/die with paramserver and live/die
with parent. It is reasonable to have global parameters which do not
depend on any node (or depend on the ROS Master). But other
parameters, such as private params, are meaningless and they should be
removed from the param server.

With all this new features I can start writting my application. If you
have more comments or you feel that I am missing something important,
just please let me know.

Thank you again for your answers.

Best regards,
  Gonzalo

2013/4/17 Thibault Kruse <kruset at in.tum.de>:
> Hi Gonzalo,
>
> about a year ago I had similar ideas. I thought about having a separate
> Param server ROS node which would receive and serve params as ROS messages.
> This would allow easily using the same toolset for params as for other
> messages. E.g. recording param changes with rosbag, or setting a param using
> interactive markers in rviz.
> This would also mean easy adoption for non-C++ languages which already deal
> with ROS messages.
> The API should allow to create a UI similar to the one for
> dynamic_reconfigure, meaning nodes should advertise the parameters they
> dynamically consume, with type and range information.
>
> The main technical problem I had with that approach was creating a ROS
> message in C++ based on command-line parameters, as I had no way to figure
> out the required datatype of single parameters of ROS messages. I think I
> had a draft REP ready, I'll send it to you if I can still find it.
>
> There were other subtle problems to consider, such as the lifecycle of
> params. E.g. does a parameter live and die with the paramserver node, or
> does it live and die with its "parent" node, or are combinations of both
> possible? Similarly how to have protected namespaces for the dynamic params
> of each node on the paramserver node, and whether to allow nodes to set
> (each other's) params on the parameter server.
>
> When I talked to Ken about the larger concept, he said pretty much what he
> says now, and that a Redis based solution would offer more features with
> less development/maintenance effort. And maintenance effort is IMO the
> largest challenge currently to the ROS ecosystem.
>
> Also at the time I was under the (false) impression that ROS2.0 was
> something to happen soon and would change everything, so I did not continue
> to work on that.
> Right now I am not sure whether it is useful to mention ROS2.0 at all.
>
> regards,
>   Thibault
>
>
>
>
> On 17.04.2013 03:07, 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 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
>