<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#006600;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#006600">Before I continue, is there a discussion forum (google whatever)? Or is this the place for it?
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#006600"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#006600">The backend is just looking up the full string, regardless of what the node name or namespace may be. As such there is no loss of namespace hierarchy in the config store. So
the question is how to handle remapping. In my case each module has a “name()” method which holds the assigned/remapped name. Looking up the config value is then config.get(name()+”height”,height,42,”costmap height in cells”);<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#006600"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#006600">Everything in the architecture has a name and unique id to aid with debugging and diagnostics. Looking at doxygen pretty much all my code inherits from rframe::NameId class.
As a result, N instances of an algorithm can be instantiated separately from the messaging system, access their subset of the global configuration, and uniquely log output (to a log file, not over the network, that’s another discussion).
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#006600"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#006600">Alternatively, a local configuration instance could be allocated with the namespace prefix, and prepend it to queries which are then forwarded to the singleton (or server).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#006600">Configuration config(“/move_base/local_costmap”): // config knows it is not the singleon due to how it is constructed<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#006600">config.get(“height”,height);<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#006600"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#006600">Essentially what node param does, but as a separate functional component. As such, the overall interface is more modular, and is therefore more interoperable due to separation
of concerns.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#006600"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#006600">-Bob<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri","sans-serif";color:#006600"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> ros-users-bounces@code.ros.org [mailto:ros-users-bounces@code.ros.org]
<b>On Behalf Of </b>Dave Hershberger<br>
<b>Sent:</b> Monday, April 22, 2013 4:32 PM<br>
<b>To:</b> User discussions<br>
<b>Subject:</b> Re: [ros-users] New Parameter Server<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">rdean's system sounds pretty convenient, but I wanted to point something out about these two aspects:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">First, separate it from the node and nodelet API.<br>
...<br>
The singleton is nice as it allows threadsafe access to the configuration from anywhere in the code.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">With the existing rosparam system, parameters live in a tree of namespaces. ROS code can load parameters using a nodehandle which was named, which name can have been remapped from the command line or from a launch file, and both of these
can change the prefix of the parameter names. This is powerful and desirable, as it reduces name conflicts and allows code to be reused in new ways.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">For example, there is a parameter who's full name is "/move_base/local_costmap/height". In the costmap code, the parameter-reading function only needs to specify "height". The code is used two times in the same executable - there is also
a "/move_base/global_costmap/height" parameter, and they don't interfere with each other because of the namespaces.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It seems to me that if you separate rosparams from the Node/Nodelet API, you'll need a separate way to manage namespaces. If you use a singleton, you remove the capability for having config objects which represent different parts of the
tree, and thus each piece of code will need to know the full path of its parameter names.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Of course you could have a config singleton which is just the root of the tree, but then you lose a lot of the convenience of having a singleton, since you need to carry around a pointer to your current location in the tree.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Anyway, I don't want to say I know what the API should be, but I wanted to point out this very useful feature of the existing API.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Dave<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Mon, Apr 22, 2013 at 12:32 PM, <<a href="mailto:rdean@gdrs.com" target="_blank">rdean@gdrs.com</a>> wrote:<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#006600">First, separate it from the node and nodelet API. (not sure if this is in the gsoc description on not)</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#006600">Second, api should include a mechanism to manually check for a parameter change i.e. not use callbacks. We write a
large amount of real-time capable code, where callbacks are bad. ROS is not used for this code, our main interest in the matter is to increase interoperability/quality of code. A manual check simplifies thread safety and algorithm design.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#006600"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#006600">The api should be as simple as possible. I have a configuration system which is similar in capability as what the
GSoC is asking for (but I cannot share code but am allowed to discuss interfaces). It is a singleton, where get() and set() are implemented as templates, and use polymorphism to handle either single or arrays of parameter values. Get also has a specialized
“startup” version which allows setting of default values for metadata if the parameter does not exist. Error codes are returned for all possible cases, no exceptions are thrown.
</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#006600"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#006600">At startup:</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#006600"> Configuration & config = Configuration::instance();</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#006600"> double width;</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#006600"> // either get the value, or add it to the store with value of 3.5 & the given description. As get is a template,
internally it sets the type as double</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#006600"> config.get(“param name”,width_,3.5,”width between points A and B”);</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#006600"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#006600">At runtime:</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#006600"> If (Configuration::instance().get(“param name”,width_) == rframe::Error::CHANGED)</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#006600"> cout << “width changed to “ << width << endl;</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#006600"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#006600">The values for each parameter are currently: key, value, comment, dirty, and type. Type is a enum mapping to int,
bool, string, double, etc.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:#006600">As the get<>() and set<>() calls are templates, there is no need for separate getTYPENAME calls to do the type conversion.
This is an aesthetic choice which simplifies the interface for us.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:green"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:green">The singleton is nice as it allows threadsafe access to the configuration from anywhere in the code. I do not currently
support ranges for values.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:green"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri","sans-serif";color:green"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a href="mailto:ros-users-bounces@code.ros.org" target="_blank">ros-users-bounces@code.ros.org</a> [mailto:<a href="mailto:ros-users-bounces@code.ros.org" target="_blank">ros-users-bounces@code.ros.org</a>]
<b>On Behalf Of </b>Dave Hershberger<br>
<b>Sent:</b> Wednesday, April 17, 2013 5:09 PM<br>
<b>To:</b> User discussions<br>
<b>Subject:</b> Re: [ros-users] New Parameter Server</span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">+1 on the project, I'm glad to see this getting attention!<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">For the Qt version of rviz, I wrote a property hierarchy system in C++ which I have been fairly happy with.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">For example usage, see map_display.cpp: <a href="https://github.com/ros-visualization/rviz/blob/groovy-devel/src/rviz/default_plugin/map_display.cpp" target="_blank">https://github.com/ros-visualization/rviz/blob/groovy-devel/src/rviz/default_plugin/map_display.cpp</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">That system uses Qt slots to receive notice of property changes when needed. (If Qt is undesirable you could probably go with Boost slots or even just member function pointers.)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The bit about rviz's property API that is perhaps unique is that the Property object actually owns the data. That means any time you want one of the property values you say something
like "width_property_->getInt()" or "name_property_->getString()". What is returned by the Property object is always the latest value. If you need to learn about updates, you don't need any parameters coming through the update function, because you can just
ask the parameter object for the latest value from inside the update function. This felt simpler to me than requiring API users to implement get/set functions for every parameter, which is how it had been implemented before.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Dave<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Wed, Apr 17, 2013 at 12:43 PM, Thibault Kruse <<a href="mailto:kruset@in.tum.de" target="_blank">kruset@in.tum.de</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I found my draft rep, and now put it on github:<br>
<a href="https://github.com/tkruse/rep/blob/nodeparam/nodeparam-REP.rst" target="_blank">https://github.com/tkruse/rep/blob/nodeparam/nodeparam-REP.rst</a><br>
<br>
Note this was work in progress when I stopped working on it.<br>
<br>
Other things I considered back then:<br>
- whether to support complex parameter types like poses (rather than just primitive values)<br>
- how to organize parameter naming (I think there were some inconsistencies between rospy and roscpp around the '~')<br>
- using the same system for logger levels<br>
- grouping of parameters instead of having flat lists<br>
- whether to support batch updates of multiple parameters as one operation (e.g. when parameter validation would else deadlock changing two interdependent parameters)<br>
<br>
cheers,<br>
Thibault<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
</div>
<p><b><span style="color:red">------------------------------------------------------</span></b><o:p></o:p></p>
<p><span style="color:darkblue">This is an e-mail from General Dynamics Robotic Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it
or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.</span><o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p><b><font color="red">------------------------------------------------------</font></b></p>
<p><font color="darkblue">This is an e-mail from General Dynamics Robotic Systems. It is for the intended recipient only and may contain confidential and privileged information. No one else may read, print, store, copy, forward or act in reliance on it or its attachments. If you are not the intended recipient, please return this message to the sender and delete the message and any attachments from your computer. Your cooperation is appreciated.</font><br /></p>
</body>
</html>