On Wed, Apr 17, 2013 at 11:25 AM, Austin Hendrix <span dir="ltr"><<a href="mailto:legotown@aol.com" target="_blank">legotown@aol.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the most important thing to consider with respect to the parameter server is the API;</blockquote><div><br></div><div>+1</div><div><br></div><div>All of this is good input, but the (proposed) goal of the GSoC is to come up with a better way to declare, initialize, and interact with parameters which lands squarely on configuration and API, but not necessarily implementation details. The GSoC calls specifically for C++ API to be redesigned, but something to consider is the Python API which would be an obvious extension to the work proposed.</div>
<div><br></div><div>Implementation details will obviously drive or constrain the API in subtle ways, but are less important at this stage. If the result of the project is a standalone solution then it can be rolled out along side the existing ROS parameters with an implementation based on the current ROS ecosystem. If the design calls for more extensive changes to existing ROS constructs (like changes to the master, replacing the parameter server, or extensive changes to roscpp) then we will have to make decisions based on backwards compatibility. Either way we will use this design in the ROS2.0 effort where we can make a cleaner API without as many problems with API collisions.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">in particular, the python API is very good, and you can easily retrieve and work with any subtree of the parameter server namespace, and easily store lists within a parameter. Doing similar operations from C++, by comparison, is very cumbersome, requiring manual manipulation of the XMLRPC data structures and manual casting or conversion operations.<br>
<br>
It would also be nice to see an API where dynamic parameter updates can replace dynamic reconfigure. Ideally, it would be cool to have proxy objects for parameters, and have the API deal with updating the proxies whenever the underlying parameters change. The API will probably need to provide a few locking/snapshot functions around parameters to make this work properly.<br>
<br>
+1 to being able to capture parameter state with rosbag; parameters are an important part of a ROS system. For my use-case (calibration), being able to capture parameters such as the active URDF is important.<br>
<br>
A few more responses inline:<div class="im"><br>
<br>
On 04/17/2013 07:22 AM, Jack O'Quin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Apr 17, 2013 at 8:06 AM, Gonzalo Abella <<a href="mailto:abellagonzalo@gmail.com" target="_blank">abellagonzalo@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thank you very much for your answers. They are all pretty helpful. A<br>
brief summarize:<br>
- But (a possibility), rely on a simple key-value DB as Redis to<br>
minimize development/maintenance.<br>
</blockquote>
+1 to redis<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Priorities to initialize parameters: (0) default values, (1) launch<br>
files, (2) parameter server, (3) command line. +number -> +priority<br>
</blockquote>
Not sure why the server needs to worry about this. Parameters get set<br>
whenever someone sets them. Not your responsibility, its under user<br>
control.<br>
</blockquote></div>
Agreed. As I see it, this priority hierarchy is already part of the system.<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The params lifecycle is a tricky problem. I think the best solution<br>
would be a combination of both live/die with paramserver and live/die<br>
with parent. It is reasonable to have global parameters which do not<br>
depend on any node (or depend on the ROS Master). But other<br>
parameters, such as private params, are meaningless and they should be<br>
removed from the param server.<br>
</blockquote>
Beware: in the existing implementation, parameters live and die with<br>
the parameter server (currently roscore). That is often useful.<br>
<br>
* I often find myself starting roscore first just so I don't have to<br>
reload parameters every time I test some node.<br>
<br>
* Sometimes parameters may be adjusted during node execution. If they<br>
are destroyed when the node terminates, we lose the opportunity to<br>
save them somewhere for the next session.<br>
<br>
* For general compatibility, interface issues like this should not be<br>
changed without a compelling reason.<br>
</blockquote></div>
Agreed on all counts.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Austin</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
--<br>
joq<br>
______________________________<u></u>_________________<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/<u></u>listinfo/ros-users</a><br>
</blockquote>
<br>
______________________________<u></u>_________________<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/<u></u>listinfo/ros-users</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>William Woodall<div>ROS Development Team</div><div><a href="mailto:william@osrfoundation.org" target="_blank">william@osrfoundation.org</a></div><div>
<a href="http://williamjwoodall.com/" target="_blank">http://williamjwoodall.com/</a></div>