<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Gonzalo,<br>
<br>
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.<br>
This would also mean easy adoption for non-C++ languages which
already deal with ROS messages.<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
Right now I am not sure whether it is useful to mention ROS2.0 at
all.<br>
<br>
regards,<br>
Thibault<br>
<br>
<br>
<br>
On 17.04.2013 03:07, Gonzalo Abella wrote:<br>
</div>
<blockquote
cite="mid:CACuzp6gs0ne0OtBNZ9E=64U=XVqgQqiSf8Eu-ubWGS34Y_cuFw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Dear community</div>
<div><br>
</div>
<div>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: </div>
<div><br>
</div>
<div>"Develop new Parameter API for C++ ROS client"</div>
<div>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.</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div style="">I would appreciate any
opinion/suggestion/advice/commentary. Thank you very much.</div>
<div style=""><br>
</div>
<div>Best regards,</div>
<div> Gonzalo</div>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
ros-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a>
<a class="moz-txt-link-freetext" href="https://code.ros.org/mailman/listinfo/ros-users">https://code.ros.org/mailman/listinfo/ros-users</a>
</pre>
</blockquote>
<br>
</body>
</html>