On Mon, Apr 19, 2010 at 1:57 PM, Blaise Gassend <blaise@willowgarage.com> wrote:
> Ugo,
>
> Dynamic_reconfigure can probably help you. Have a look at
> dynamic_reconfigure/test/testserver.cpp, which is the only real
> documentation so far. It is not stable, but given that it has more and more
> users, I will be careful about not breaking things if/when it gets improved.
>
> Stu is just starting to think about using it in controllers, I do not
> anticipate any major hurdles there.
>
> I can help with point questions if you have any.

I've been looking at this recently, too. I've been able to figure out
enough from reading code to get some simple but useful features
working. It seems quite nice, providing significant benefit with very
little coding.

Many things are not yet clear to me, however.

What thread does the server callback run in?

I suppose it must be invoked in the main thread at the point where it
calls ros::spinOnce(). But, I have not been able to find any
definitive answer on my own. If my code all runs in the same thread, I
should not need any locking for updating internal parameter variables.
Otherwise, I should worry.

Is this just a regular ROS service call?

I see my node advertising a set_parameters service. It's also
advertising parameter_descriptions and parameter_updates topics.

What is the recommended way to update internal parameter variables?

I find that calling node.getParamCached() in the main loop actually
works, because the reconfigure_gui script is updating the parameter
server to keep things in sync. That allows other updating methods,
such as "rosparam set" to work. But, it's probably not the best way to
operate.

My callback always seems to get invoked at startup with level set to
0xffffffff. Is that guaranteed? Does it happen immediately? Can I use
that to save an initial config structure? Is there a way to make sure
those fields get set before my main loop starts executing? Do those
values come directly from the parameter server, so I don't need to
read them separately?

When reconfigure_gui selects my node, it seems to generate a
set_parameters call with level 0x0. What does that signify?

How should the reconfigure callback detect which parameters have
changed? The obvious solution is to compare the new config structure
with one saved on the initial or previous call. Is there a better
solution? Most changes don't need to be detected, but some do.

The level parameter seems to interact with the states of the
driver_base package. That goes somewhat deeper than I am ready to
venture at the moment. I'm just using dynamic_reconfigure to update
values that can easily change during execution of the node, because my
code is currently not structured to handle
SensorLevels::RECONFIGURE_CLOSE updates. That seems to require a whole
different node structure which continues to run after the device is
closed.

Thanks for any help you can provide,
-- 
 joq