[ros-users] Best way to set the parameters for the controllers (param or message?)

[Blaise Gassend]

Hi Jack,

> Most of my guesses were close enough. I was mainly worried about the
> threading model. I wanted to know for sure that no locking was needed,
> even though it appeared to work without locks I hate depending on
> testing to find concurrency problems. The interface for simple
> single-threaded drivers is quite clean.

The server class actually supports locking (though not sure how good the
model is). It will take a recursive lock each time its code is entered
(service call or set_parameter), which should avoid problems if a
callback is racing with another thread is setting a parameter. You can
actually provided it with your own lock, which driver_base uses to have
a single big lock on the driver and server.

> I did encounter one awkward design issue. My code uses a couple of
> subordinate classes for speed control and PID. I could not figure out
> a clean way to pass the parameters to the PID class (which is shared
> by other drivers), so it still reads its parameters using
> getParamCached() on every cycle. That works, after I renamed the
> parameters from brake/kp, brake/ki, etc. to brake_kp, brake_ki, etc.
> (because dynamic_reconfigure requires valid C++ identifiers for all
> parameter names). But, I would prefer to use dynamic reconfigure for
> everything.

I would love to support hierarchical parameters, but so far I'm not sure
how it should be done and don't have the bandwidth. For now your
simplest bet might be to run a dynamic reconfigure server for each
subordinate class, in its own namespace. The main problem I see is that
this approach will cause a lot of clutter in the GUI. Stu is starting to
do this for controllers, so I expect that enhancements to the GUI to
manage the clutter will be appearing.

> Is there some way to build a separate parameter server for each
> instance of the PID class? I have not tried that yet. It would be
> nice, if workable. All those parameters can be updated at any time, so
> they would not need to interact with the main driver state. There are
> other ways to solve that problem using explicit calls from the
> reconfigure callback to subordinate controller methods, but in this
> case it's two layers deep, making for messy code. I like using
> subordinate parameter names (like brake/kp) for subordinate classes,
> it tends to avoid name collisions.

That should work. I have heard reports of problems when running multiple
servers in a node, but so far have not been given the code that causes
the problem. Multiple servers in a node is something that I intend to
support aggressively, so if you encounter that problem, let me know.

Blaise