0
$\begingroup$

Rosanswers logo

Dear all,

I'm looking for the best way to achieve the following (in cpp on Fuerte).

At the moment, I have one node which should be dynamically reconfigurable (i.e.: start, stop, set camera frame rate). In the long run, there will be many nodes that should be configurable by other nodes, often by one node switching the system into different states. The current state of each node should be accessible by all other nodes. What's the best design to achieve this?

My ideas so far:

  1. Use dynamic_reconfigure in each node.
  2. Provide services for all configurations in each node.
  3. Use the parameter_server for exchange of parameters and offer an updateFromServer()-service in each node. Other nodes set the new parameters on the server and then trigger the service to reconfigure accordingly. Probably not very clever as there can be inconsistencies / false assumptions about the current configurations.
  4. Use the parameter server with different parameters for the desired (new) configuration and the actual one, again coupled with a updateFromServer()-service. Other nodes set the desired parameter and call the service for starting the reconfiguration. After reconfiguring, the node updates the actual values on the parameter server (where the caller can check, if needed).

In case of three and four, I could probably use a regular getParamCached() call instead of the service (?).

Do any of these seem reasonable? Do you have comments on possible benefits/downsides of using on or another, e.g. in terms of performance, manageability of code (including n services of different other nodes), best practices? Or is there some other method that I didn't discover yet?

I'd appreciate your comments or recommendations!

Regards,

Philip

P.S.: If there's any changes between Fuerte and Groovy that may benefit my use-case, I'd probably consider upgrading.


EDIT (in reply to comments): I am not looking for setting and reading a configuration state for the whole system, for which a nice solution was already given here. I'm rather looking for a way to be able to access and configure each node's parameters on their own during runtime. Thanks for all your input!


EDIT (out of curiosity): In this tutorial, turtlesim is re-configured at runtime via something like method 3 as described above (this is probably where I got that idea in the first place). Does anybody know a specific reason why it is done this way?


Originally posted by Philip on ROS Answers with karma: 990 on 2013-04-03

Post score: 2


Original comments

Comment by jarvisschultz on 2013-04-03:
You might want to see this question that I asked. There are some good tips in there, and I had a very similar situation.

Comment by Philip on 2013-04-03:
Thanks for your comment! I've actually browsed through quite a lot of answers in order to get a rough idea for what I'm looking for, and your question was one that helped me quite a bit. However, I'm more looking for configuration per node instead of a "global" configuration state.

Comment by joq on 2013-04-03:
Since you want nodes to be configurable from other nodes, with the other nodes monitoring their state, you really are asking for global configuration state, aren't you?

Comment by Philip on 2013-04-03:
Sorry for the confusion! Of course something accessible from everywhere is global :-) I updated the question to clarify.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

If each node will be accessed and configured separately at runtime, I recommend option 1: dynamic_reconfigure.

Advantages:

  • reasonably nice GUI with minimal implementation effort
  • efficient updates
  • clean separation between nodes, making them easy to reuse

Disadvantage:

  • not easy to access another node's current configuration

EDIT: I did some experiments. Dynamic reconfigure does update the parameter server whenever changes are made. So, reading the current settings is simple: just get them from the parameter server using the usual ROS parameter APIs.


Originally posted by joq with karma: 25443 on 2013-04-03

This answer was ACCEPTED on the original site

Post score: 2


Original comments

Comment by Philip on 2013-04-05:
Thanks for your answer and listing the (dis)advantages! I'm worried a little about the last point. http://answers.ros.org/question/12276/is-there-a-c-api-for-a-dynamic-reconfigure-client indicates that there are topics I can use to access the configuration of a node, but I haven't found more info.

Comment by joq on 2013-04-05:
C++ should use system("rosrun dynamic_reconfigure dynparam ..."). In Python there is a decent API: http://www.ros.org/wiki/hokuyo_node/Tutorials/UsingDynparamToChangeHokuyoLaserParameters#PythonAPI

Comment by Philip on 2013-04-07:
EDIT: Perfect, nice find! So I'll use the system-call for setting parameters (I'm using c++) and query the parameter-server to access them. To be on the safe side, I'm clearing the according parameters on the server at the startup of each node to avoid ghosts from the last run :-)

Comment by joq on 2013-04-09:
Clearing the parameters on node start-up will likely cause strange behavior for common ROS practices, such as loading a batch of parameters in a launch script. To clear the parameters: shut down roscore and restart it.

Comment by Philip on 2013-04-09:
Good point, thanks!

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.