ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
2

Bi-directional dynamic_reconfigure

asked 2015-09-09 12:51:48 -0500

peci1 gravatar image

I have a few parameters that can be controlled either via dynamic_reconfigure, or via a subscriber, or by updating their value to the state of the hardware they act with.

One direction works well - when I set a value using dynparam or rqt_reconfigure, an action is commanded to the hardware and a parameter update is published automatically.

I want to know if there is a tutorial or at least guideline on how to deal with the other direction - something else (hw event, subscribed message) changes the state and I need the parameters to reflect it.

Obviously, using dynamic_reconfigure.client is not the right way to do it, because it would issue commands instead of just changing parameter values.

So I try publishing directly on ~/parameter_updates and manually setting the parameter value on the parameter server, which somehow works, but still it seems quite unreliable and cumbersome.

Is there a better way to do it?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2015-09-09 15:29:55 -0500

ahendrix gravatar image

The dynamic reconfigure server has an undocumented updateConfig method, which appears to do what you're looking for: https://github.com/ros/dynamic_reconf...

To use it, it looks like you also need to have an external mutex for controlling access to the dynamic_reconfigure config.

Not tested, but this _might_ work:

boost::recursive_mutex config_mutex;
dynamic_reconfigure::Server<dynamic_tutorials::TutorialsConfig> server;
dynamic_reconfigure::Server<dynamic_tutorials::TutorialsConfig>::CallbackType f;

f = boost::bind(&callback, _1, _2);
server.setCallback(f);

dynamic_tutorials::TutorialsConfig new_config;
server.updateConfig(new_config);

Note that the dynamic_recofigure::Server API doesn't require that the mutex be locked before calling updateConfig; it does the appropriate locking internally.

edit flag offensive delete link more

Comments

Great! I haven't mentioned it, but I looked for a solution in Python. Fortunately, there seems to be a similar method in server.py called _change_config. Though it is protected, thanks to Python's liberal object model I think I can call it without hesitation :)

peci1 gravatar image peci1  ( 2015-09-10 06:35:30 -0500 )edit
1

There is one catch, though. You need to make sure (using e.g. a class-wide flag) that you don't call your API setting stuff again after calling _change_config. This way, you'd get into an infinite loop (or a deadlock because of the mutexes). You can also use update_configuration, which is public

peci1 gravatar image peci1  ( 2015-09-10 09:12:49 -0500 )edit

Question Tools

3 followers

Stats

Asked: 2015-09-09 12:51:48 -0500

Seen: 1,696 times

Last updated: Sep 09 '15