Ask Your Question
2

Best practice for online re-configuration between nodes [closed]

asked 2013-04-03 07:08:07 -0600

Philip gravatar image

updated 2013-04-09 04:19:57 -0600

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?

edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by Philip
close date 2013-04-11 11:40:31

Comments

2

You might want to see this question that I asked. There are some good tips in there, and I had a very similar situation.

jarvisschultz gravatar imagejarvisschultz ( 2013-04-03 08:05:47 -0600 )edit

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.

Philip gravatar imagePhilip ( 2013-04-03 09:14:20 -0600 )edit

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?

joq gravatar imagejoq ( 2013-04-03 11:18:04 -0600 )edit

Sorry for the confusion! Of course something accessible from everywhere is global :-) I updated the question to clarify.

Philip gravatar imagePhilip ( 2013-04-03 11:55:55 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
2

answered 2013-04-03 12:15:54 -0600

joq gravatar image

updated 2013-04-09 04:47:11 -0600

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.

edit flag offensive delete link more

Comments

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.

Philip gravatar imagePhilip ( 2013-04-05 01:47:06 -0600 )edit
1

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

joq gravatar imagejoq ( 2013-04-05 02:16:19 -0600 )edit

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 :-)

Philip gravatar imagePhilip ( 2013-04-07 23:53:30 -0600 )edit

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.

joq gravatar imagejoq ( 2013-04-09 06:07:26 -0600 )edit

Good point, thanks!

Philip gravatar imagePhilip ( 2013-04-09 06:23:35 -0600 )edit

Question Tools

2 followers

Stats

Asked: 2013-04-03 07:08:07 -0600

Seen: 907 times

Last updated: Apr 09 '13