Realsense-ros: DDynamic Reconfigure - Default Values

[RhysMcK]

Is there simple way to set the default values for the dynamic reconfigurable variables?

[stwirth]

I'm running into the same problem. The "traditional" ROS dynamic reconfigure server reads all parameter values form the ROS parameter server on startup and sets the parameters to those values. When a dynamic reconfigure call is made, it also updates the values on the parameter server. This way, running a rosparam get / always gets the current configuration of the system, including dynamically configurable parameters. It would be nice if the camera driver behaved the same to be able to save and restore the parameter configuration state.

[stwirth]

A workaround for this problem is to include a dynamic reconfigure call in the launch file:

  <node name="$(anon param_setter)" pkg="dynamic_reconfigure" type="dynparam"
        args="set /camera/Stereo_Module 'Visual Preset' 3" />

[stwirth]

Another option is probably to use the JSON config file.

[stwirth]

One problem with communicating the realsense ROS node parameters with the ROS parameter server is that in the current implementation some parameters have spaces in them (e.g. "Emitter Enabled") which is not a valid ROS parameter name (see http://wiki.ros.org/Names).

[doronhi]

I'm running into the same problem. The "traditional" ROS dynamic reconfigure server reads all parameter values form the ROS parameter server on startup and sets the parameters to those values. When a dynamic reconfigure call is made, it also updates the values on the parameter server. This way, running a rosparam get / always gets the current configuration of the system, including dynamically configurable parameters. It would be nice if the camera driver behaved the same to be able to save and restore the parameter configuration state.

@stwirth
I don't really understand what is it that you suggest the driver (realsense2_wrapper ) should do?
Can you walk me through your case?

[stwirth]

@doronhi this is actually a problem of ddynamic_reconfigure.
In dynamic_reconfigure, the initialization sequence is as follows:

• On construction, init() is called which pulls values for all parameters from the ROS parameter server (if they are set): https://github.com/ros/dynamic_reconfigure/blob/4f320fcdc3d6cd6fbf7a7f9a969af81ca521b761/include/dynamic_reconfigure/server.h#L190-L192
• On registering the callback, the callback is immediately called with the current configuration (which contains the defaults or the values that have been read from the parameter server in init()): https://github.com/ros/dynamic_reconfigure/blob/4f320fcdc3d6cd6fbf7a7f9a969af81ca521b761/include/dynamic_reconfigure/server.h#L89-L90
• When responding to the set_parameters service, all parameters are also written to the ROS parameter server: https://github.com/ros/dynamic_reconfigure/blob/4f320fcdc3d6cd6fbf7a7f9a969af81ca521b761/include/dynamic_reconfigure/server.h#L225-L239

Unfortunately ddynamic_reconfigure does not implement the same behavior, especially the read operation from the ROS parameter server is not done on startup (which this ticket is about).
The use case is simple: I start up the camera driver, fiddle with the parameters until I get the image as I want it and use rosparam dump to save the current parameter set. Then, before I launch the camera again, I use rosparam load to load the parameter set or use <rosparam> or <param> tags in a launch file together with the camera driver to restore the state I want.

[stwirth]

Another thing that ddynamic_reconfigure does not support (and therefore the driver cannot support) is to give feedback about which parameter values have been accepted by the callback. The caller of the reconfigure service just has to believe that the requested parameters are applied.

[doronhi]

@stwirth
Both issues sounds very valid to me. The ddynamic_reconfigure library gives the befit of revealing all the underlying options but its obviously not mature enough.
I will try to add the features you described in the future or merge a PR if one is available.

[stwirth]

As a workaround to this problem we currently use the JSON format, we simply took the presets from here and adapted the values to match the ones we found by playing with dynamic reconfigure.

[RealSenseCustomerSupport]

[Please Ignore - RealSense system comment]