I second this. The experience with rosbag also shows that such a second serialization format is hard to get rid of (rosbag has a different format in the header than in the messages...). cheers, On Sat, Nov 12, 2011 at 7:40 PM, Thibault Kruse wrote: > Hi, > > a bit late maybe to mention this, but I find it strange that > dynamic_reconfigure > would invent its own type system. Why not build on the > ROS msg type system and work it from there? That would reduce > the duplicate code (binding generation) and allow for easier integration > with other > programming languages. It does not even need to support the whole > range of ros msg possibilities for that to start with. > > "Grouping parameters" sounds very much like building a ROS message structure > to me. > > I understand that you cannot define variable domains in ros msg definitions, > but why should a dynamic reconfigure file not start by loading a message > struct from a ros msg definition, and extend this to a configuration? > > If you look at the example on using dynamic reconfigure merged with a > service: > http://ibotics.ucsd.edu/trac/stingray/wiki/ROSNodeTutorialC%2B%2B >  this bit seems like redundant code: > > void  NodeExample::messageCallback(const >  node_example::node_example_data::ConstPtr&msg) > { >  message_=  msg->message; >  a_=  msg->a; >  b_=  msg->b; > ... > }  // end publishCallback() > void >  NodeExample::configCallback(node_example::node_example_paramsConfig&config, >  uint32_t level) > { >  // Set class variables to new values. They should match what is input at > the dynamic reconfigure GUI. >  message_=  config.message.c_str(); >  a_=  config.a; >  b_=  config.b; > }  // end configCallback() > > If dynamic reconfigure was based on ros msg, one callback would do for both. > That in itself is not a huge benefit to anyone maybe, it just would seem > more > reasonable to me than to have two parallel type systems. > > > In the same way, i would have been happy to see dynamic_reconfigure cfg > files being yaml files rather than python, declaring structures only. > That could one day even lead to ROS msg definitions which include more > semantics like minimum, maximum, default, docstring. Is there a good > reason why this cannot or should not be done? > > cheers, >  Thibault > > > > On 01/-10/-28163 08:59 PM, Ken Conley wrote: >> >> Forwarding to ros-developers as well >> >> >> ---------- Forwarded message ---------- >> From: Eitan Marder-Eppstein >> Date: Thu, Jul 7, 2011 at 8:09 AM >> Subject: Review for Dynamic Reconfigure Groups >> To: ros-review@lists.willowgarage.com >> Cc: Ze'ev Klapow, Ken >> Conley >> >> >> Hey all, >> Ze'ev Klapow spent some time last week implementing a groups feature >> for dynamic reconfigure. The feature enables you to do things like >> show and hide groups of parameters based on what other parameters have >> been set, view parameters for a node by group and expand or collapse >> them in the client, and access parameters in both C++ and Python in a >> consistent manner using '.' syntax. The feature is, I think, super >> useful, but to land in E-Turtle it needs a review. We'd love feedback >> from anyone using dynamic_reconfigure who wants to try out this >> feature. >> The list of changes lives here, along with a section for feedback: >> http://www.ros.org/wiki/dynamic_reconfigure/Reviews/7-1-11_groups >> And updated tutorials live here: >> http://www.ros.org/wiki/Ze%27ev%20Klapow/dynamic >> And the code can be found here: >> https://kforge.ros.org/project/common/services/dynamicreconfig/ >> Thanks much, and hope all is well, >> Eitan >> _______________________________________________ >> ros-developers mailing list >> ros-developers@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-developers >> > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > -- Ingo Lütkebohle Bielefeld University http://www.techfak.uni-bielefeld.de/~iluetkeb/ PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B