ros/dynamic_reconfigure

dynamic_reconfigure's Issues

debbuild of camera1394 seems to be calling rosdep at build time and failng

http://jenkins.willowgarage.com:8080/job/ros-hydro-camera1394_binarydeb_precise_amd64/2/console

-- catkin 0.5.65
-- Boost version: 1.46.1
-- Found the following Boost libraries:
--   thread
-- checking for module 'libdc1394-2'
--   found libdc1394-2, version 2.2.0
CMake Error at /opt/ros/hydro/share/dynamic_reconfigure/cmake/extras.cmake:47 (message):
  Could not run dynamic reconfigure file 'cfg/Camera1394.cfg': the rosdep
  view is empty: call 'sudo rosdep init' and 'rosdep update'
Call Stack (most recent call first):
  CMakeLists.txt:35 (generate_dynamic_reconfigure_options)


-- Configuring incomplete, errors occurred!
dh_auto_configure: cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCATKIN_BUILD_BINARY_PACKAGE=1 -DCMAKE_INSTALL_PREFIX=/opt/ros/hydro -DCMAKE_PREFIX_PATH=/opt/ros/hydro returned exit code 1

No content on the Indigo wiki page

http://wiki.ros.org/dynamic_reconfigure

Link to python code api is 404 not found

From here
to here

I've not been able to see this page for a few days. Last time I could see them was probably in early January.

generate_dynamic_reconfigure_options() generates files in the source tree

Currently, dynamic_reconfigure generates config files in the source tree, but shouldn't it do so in the devel tree?

https://github.com/ros/dynamic_reconfigure/blob/master/cmake/cfgbuild.cmake#L56

dynamic_reconfigure failing build on jenkins.ros.org

http://jenkins.ros.org/view/GbinP32/job/ros-groovy-dynamic-reconfigure_binarydeb_precise_i386/ keep failing, I think
https://github.com/ros/dynamic_reconfigure/blob/master/package.xml#L18 is not good
since ros-groovy-catkin is 0.5.86 (http://jenkins.ros.org/job/ros-groovy-catkin_sourcedeb/)

Many compile warnings due to unused parameters.

The config_tools.h header has many used variables, resulting in a lot of compile warnings (on 14.04 with gcc 4.8.2) when we build our own code that includes these headers. This is not production-friendly :(

Lines:
15, 20, 25, 30, 35, 40, 45, 50

Not sure if there's a preferred style in the ROS code base, but I'd recommend commenting out the variable name, e.g.

static std::vector<dynamic_reconfigure::DoubleParameter>& getVectorForType(dynamic_reconfigure::Config &set, const double /*val*/)

Thanks!

Dynamic dynamic reconfigure for python

I implemented a tiny layer to be able to do a "dynamic dynamic reconfigure" server at https://github.com/pal-robotics/ddynamic_reconfigure_python

It allows to add some dynamic reconfigure variables and then just call a start method with a callback to have a dynamic reconfigure server running (instead of using a .cfg file and all the stuff necessary currently for having the server). Give a look to the README with an example.
Maybe we want this to be added to the dynamic_reconfigure package itself?

If you give a look at the code I needed to write to achieve this, it's very short: https://github.com/pal-robotics/ddynamic_reconfigure_python/blob/master/src/ddynamic_reconfigure_python/ddynamic_reconfigure.py

@ibaranov-cp I think you already tried it and liked it too :)

Array parameter for each type (int, double, string, bool)

I'd like to use array for parameter, and currently it seems not possible.
Anyone who tried this, or are there any ways to achieve this?

getCurrentConfiguration() sometimes fails in new cpp client

In client.h: getCurrentConfiguration() sometimes fails to get the current configuration from the dynamic reconfigure server if the server has been recently updated with a new configuration.

A call to getCurrentConfiguration() will return when the "received_configuration_" boolean flag is true.
However, this flag is only set to false in the constructor, so getCurrentConfiguration() will only work correctly the first time. Thereafter it will always return immediately, and not wait for the callback from the server update.

Possible workaround: Set "received_configuration_" to false in the method setConfiguration().

Sphinx generator for param documentation

Inspired by sphinx-argparse, it would be really neat to have dynamic_reconfigure supply a Sphinx plugin to allow automatically generating a documentation page based on inspecting the object defined in a .cfg file.

Unable to reload parameters from a file generated by dumping

I am using ubuntu 14.04/Indigo from debs.

I am not using grouping. The generated yaml file contains all parameters twice as follows:

!!python/object/new:dynamic_reconfigure.encoding.Config
dictitems:
  parameter1: false
...
  groups: !!python/object/new:dynamic_reconfigure.encoding.Config
    dictitems:
      parameter1: false
...
      groups: !!python/object/new:dynamic_reconfigure.encoding.Config
        state: []
      id: 0
      parameters: !!python/object/new:dynamic_reconfigure.encoding.Config
        state: []
      parent: 0
      state: true
      type: ''
    state: []
state: []

The exact same issue has been posted on the ROS.answers too:
http://answers.ros.org/question/181915/dynamic_reconfigure-unable-to-reload-dumped-parameters/

Special characters in group name break build

Special characters like "(" in the parameter group name break the build, but might be desirable to put a short description in brackets.

Example:

fov_sub = gen.add_group("Field of view (relative to vehicle frame)")

generates C++ classes named FIELD_OF_VIEW_(RELATIVE_TO_VEHICLE_FRAME), which are obviously bad syntax.

To serve the need for group descriptions (that show up in rqt_reconfigure for example), I see two possiblities:

1. Support special characters in the group name
2. Add a description argument to add_group

auto-generated dynamic_reconfigure headers fail to compile depending on field names

Moving issue from answers to github:

The name string cannot be the value "i", "state", or "name" as discussed in this issue:

http://answers.ros.org/question/46724/auto-generated-dynamic_reconfigure-headers-fail-to-compile-depending-on-field-names/

Infinity not handled correctly in python

It seems that python dynamic_reconfigure does not handle double parameters properly if the min/max values are not specified. In this case, the values are set to the default std::numeric_limits<double>::infinity() which is not understood by python. In the callback, the values are aways set to std::numeric_limits<double>::infinity() instead of the actual parameter. This even causes the rqt_reconfigure gui to crash with the following error:

 ValueError: could not convert string to float: -std::numeric_limits<double>::infinity()

Reproduce

The error can be easily reproduced even with the test.cfg in this repository with the following code:

#!/usr/bin/env python
import sys
import rospy
from dynamic_reconfigure.cfg import TestConfig
from dynamic_reconfigure.server import Server

def reconfigure_callback(config, level):
    rospy.loginfo("Group2_double value: {}".format(config['group2_double']))
    return config

def main(args):
    rospy.init_node('issue_node')
    reconfigure = Server(TestConfig, reconfigure_callback)
    rospy.spin()

if __name__ == '__main__':
    main(sys.argv)

rosrunning this code should output Group2_double value: -std::numeric_limits::infinity() instead of 0, the default parameter. If you start an rqt_reconfigure window and try to configure this node, it will crash.

If I manually replace std::numeric_limits<double>::infinity() by infin the generated TestConfig.py, it works.

Allow dynamic_reconfigure to fail/reject a change

Hi all,

I want to suggest a minor improvment: currently, the callback's return type which updates the parameter is void. Thus, if the provided (new) parameters are invalid and nothing will change, there is no possibility to indicate this. I would therefore suggest to change the return type of the callback to bool and pass that information to the underlying set_parameters service, see https://github.com/ros/dynamic_reconfigure/blob/master/include/dynamic_reconfigure/server.h#L223 (and L227). If changing parameters in the callback fails, the service caller would get to know that as well.

As a quick fix (because I need this feature urgently), would it be possible to add a boolean parameter to the .cfg file so that that callback modifiers this boolean to indicate success/failure? What I've understood from the code (see https://github.com/ros/dynamic_reconfigure/blob/master/include/dynamic_reconfigure/server.h#L226 ), the new_config (passed to the callback) is stored in the service response. Do you think that this workaround would do the trick? Or is there even a simpler solution that I overlooked completely?
UPDATE: The quick fix is possible as described.

What do you think about that? Glad to hear your comments.

Parameter with slash isn't supported

Cfg generator doesn't support below scenario.For example, there are ros parameter as below
/node/camera/xxx
/node/lidar/xxx
Current generator try to generate c++ variable named as camera/xxx, it definitely failed.

Generated code has BSD boilerplate and Willow copyright

Currently when dynamic reconfigure generates .h files from cfg files, they are created with:

• BSD Boiler plate
• a 2008 Willow Garage copyright notice
• Blaise Gassend as the author

This is not a big issue, but I think that that text should not be added, or even better make it configurable. The later seems more complex (both in the code and when using dynamic reconfigure), and probably not worth it.

setCallback() should not trigger the callback

In my use case I have already set up all parameters from a config file. But they get overwritten with the defaults in the dynamic reconfigure config, when it is set up.

Is it possible to do setCallback without triggering it?

Allow using dyn. reconfig. with -Werror=float-equal

Hi all,

I am using dynamic_reconfigure with much stricter compiler settings, namely -Werror=float-equal (among others). Unfortunately, this results in errors like:

.../MyPackageConfig.h: In instantiation of ‘void my_namespace::MyPackageConfig::ParamDescription<T>::calcLevel(uint32_t&, const my_namespace::MyPackageConfig&, const my_namespace::MyPackageConfig&) const [with T = double; uint32_t = unsigned int]’:
.../my_package.cpp:371:1:   required from here
.../MyPackageConfig.h:77:28: error: comparing floating point with == or != is unsafe [-Werror=float-equal]
         if (config1.*field != config2.*field)
                            ^
cc1plus: all warnings being treated as errors

One can get rid of these problems in 2 ways:

1. move all *.cfg files to separate packages and
2. "patch" the include directory to generated headers in CMake.

Both solutions are somewhat "hacks". (a) requires to create a new ROS package just for the .cfg file (overhead, file bloat). (b) is hackish in a sense that additional CMake code is required which may also hide other issues.

Therefore I would suggest patching the template to allow such flags. (My first idea would be a specialized version of the template for floats and doubles but there's probably also a smarter / shorter way.)

Any comments on this?

Groups not working properly

Setting up dynamic_reconfigure with groups results in error from rqt_reconfigure:

Here is the error message:

Traceback (most recent call last):
File "/opt/ros/groovy/lib/python2.7/dist-packages/rqt_reconfigure/node_selector_widget.py", line 250, in _selection_changed_slot
self._selection_selected(index_current, rosnode_name_selected)
File "/opt/ros/groovy/lib/python2.7/dist-packages/rqt_reconfigure/node_selector_widget.py", line 200, in _selection_selected
item_widget = item_child.get_dynreconf_widget()
File "/opt/ros/groovy/lib/python2.7/dist-packages/rqt_reconfigure/treenode_qstditem.py", line 148, in get_dynreconf_widget
self._param_name_raw)
File "/opt/ros/groovy/lib/python2.7/dist-packages/rqt_reconfigure/dynreconf_client_widget.py", line 57, in init
group_desc, node_name)
File "/opt/ros/groovy/lib/python2.7/dist-packages/rqt_reconfigure/param_groups.py", line 153, in init
self._create_node_widgets(config)
File "/opt/ros/groovy/lib/python2.7/dist-packages/rqt_reconfigure/param_groups.py", line 199, in _create_node_widgets
widget = eval(_GROUP_TYPES[group['type']])(self.updater, group)
File "/opt/ros/groovy/lib/python2.7/dist-packages/rqt_reconfigure/param_groups.py", line 259, in init
super(CollapseGroup, self).init(updater, config)
File "/opt/ros/groovy/lib/python2.7/dist-packages/rqt_reconfigure/param_groups.py", line 248, in init
super(BoxGroup, self).init(updater, config)
TypeError: init() takes exactly 4 arguments (3 given)

It doesn't matter, if I only specify the groups name or additional the type (collapse, hide) or the state (true, false).

I tested on groovy and hydro with the same result. I'm using the c++ API and Ubuntu x64.

C++ dynamic reconfigure server with str_t param ignores numerical strings

https://github.com/lucasw/dynamic_reconfigure_tools/tree/master/dynamic_reconfigure_example is an example C++ server with a str_t param that it prints out when reconfigured:

...
gen.add("str_param", str_t, 1, "string", "")
...

Alphanumeric strings work as expected:

$ rosrun dynamic_reconfigure_example example_server_node _str_param:=5a
[ INFO] [/example_server] :[233] [Initializing nodelet with 8 worker threads.]
[ INFO] [/example_server] :[56] [5a]

But an int or float string gets dropped entirely in favor of the default "" value:

$ rosrun dynamic_reconfigure_example example_server_node _str_param:=55
[ INFO] [/example_server] [233] [Initializing nodelet with 8 worker threads.]
[ INFO] [/example_server] [56] []

The server also happens to be a nodelet, I don't think that is related but I'll create a non-nodelet example server later.

The same thing works fine with a python server (the server prints out the entire config on reconfigure):

$ rosrun rqt_dr_single example_server.py _str_param:="12345"
[INFO] [/rqt_dr_single_13663_1520016082376] :[15] [Reconfigure Request: 50, 0.5,\ 
          12345, True, 1]

Using dynparam from C++ code

As per the tutorial, using dynparam from C++ code is not implemented.

New check of description is causing other ros package to fail

We are seeing errors running with the latest version of dynamic_reconfigure as the new check is causing failures. The latest version of ros image_transport_plugins (1.9.5) fails with the following error:

File "/tmp/buildd/workspace/dynamic_reconfigure/parameter_generator_catkin.py", line 70, in check_description
raise Exception(r"""quotes not allowed in description string `%s`""" % description)
Exception: quotes not allowed in description string `Try to achieve either 'target_bitrate' or 'quality'`
make[4]: *** [/tmp/buildd/workspace/theora_image_transport/include/theora_image_transport/TheoraPublisherConfig.h] Error 1

Is there a way to allow for backward compatibility or before turning the check on ensure that all other packages are compliant?

Any help with this would be appreciated.

@mikepurvis

Install uses different name than auto gen header

The cfg file (e.g. my_parameter.cfg) allows you to specify the name of generated header (e.g. MyParameter) in generate macro, and generates MyParameterConfig, but install looks for name based off of configuration file name.

Thus, when installing I get a build error that system can't find my_parameterConfig.h

Work around by naming file the same as macro for now.

When using groups, parameters are still in the same scope

Consider this cfg file:

#! /usr/bin/env python

PACKAGE='package'

from dynamic_reconfigure.parameter_generator_catkin import *

gen = ParameterGenerator()

group = gen.add_group("group1")
group.add("enable", bool_t, 0, "Enable", True)

group = gen.add_group("group2")
group.add("enable", bool_t, 0, "Enable", True)

exit(gen.generate(PACKAGE, "package", "Groups"))

The two enable parameters will end up here:

}groups;

//#line ...
    bool enable;
//#line ...
    bool enable;

I'm using dynamic reconfigure 1.5.36.
Does the latest (1.5.37) fixes this issue?

Should I simply get rid of those attributes, or are the needed changes more complex than that? I mean, will it be difficult to fix this? or are groups well supported?

update_configuration needs timeout

If a dynamic reconfigure server locks up update_configuration never returns.

My client ( https://github.com/lucasw/dynamic_reconfigure_tools/blob/master/rqt_dr_single ) runs update_configuration out of a rospy Timer update callback, this locks up the whole rqt window and turns it gray when the dynamic reconfigure server locks up (does that mean Timer is running in the Qt thread and if so why?).

rqt_reconfigure doesn't have the same locking up problem but it is creating a thread to run update_configuration within- I can copy that but maybe solving the timeout here would be better.

I'll make https://github.com/lucasw/dynamic_reconfigure_tools/blob/master/rqt_dr_single/scripts/example_server.py demonstrate the problem (e.g. first reconfigure callback works, second waits forever) and post the code here.

rostest times out on Debian Stretch and recent ubuntus

This seem to be Ubuntu Distro related and not ROS Distro related, consistently fails on Debian Stretch, Ubuntu Artful and Bionic.
Example jobs with hanging test: http://build.ros.org/view/Mdev/job/Mdev__dynamic_reconfigure__ubuntu_bionic_amd64/1/
http://build.ros.org/view/Mdev_ds/job/Mdev_ds__dynamic_reconfigure__debian_stretch_amd64/1/

Build error with ueye package

Trying to build package ueye, throw error in trying to import SensorLevels from dynamic_reconfigure

pi@raspberrypi:~/devel/james_ws $ catkin_make
Base path: /home/pi/devel/james_ws
Source space: /home/pi/devel/james_ws/src
Build space: /home/pi/devel/james_ws/build
Devel space: /home/pi/devel/james_ws/devel
Install space: /home/pi/devel/james_ws/install

Running command: "make cmake_check_build_system" in "/home/pi/devel/james_ws/build"

Running command: "make -j4 -l4" in "/home/pi/devel/james_ws/build"

[ 0%] Built target std_msgs_generate_messages_lisp
[ 0%] Built target std_msgs_generate_messages_cpp
[ 0%] Built target std_msgs_generate_messages_py
[ 3%] Built target class_loader
[ 3%] Built target geometry_msgs_generate_messages_py
[ 3%] Built target rosgraph_msgs_generate_messages_lisp
[ 3%] Built target roscpp_generate_messages_lisp
[ 3%] Built target sensor_msgs_generate_messages_py
[ 3%] Built target sensor_msgs_generate_messages_cpp
[ 3%] Built target sensor_msgs_generate_messages_lisp
[ 3%] Built target geometry_msgs_generate_messages_lisp
[ 3%] Built target geometry_msgs_generate_messages_cpp
[ 3%] Built target roscpp_generate_messages_cpp
[ 3%] Built target rosgraph_msgs_generate_messages_py
[ 3%] Built target rosgraph_msgs_generate_messages_cpp
[ 3%] Built target roscpp_generate_messages_py
[ 3%] Built target _nodelet_generate_messages_check_deps_NodeletUnload
[ 3%] Built target _nodelet_generate_messages_check_deps_NodeletLoad
[ 3%] Built target _nodelet_generate_messages_check_deps_NodeletList
[ 3%] Built target _dynamic_reconfigure_generate_messages_check_deps_ConfigDescription
[ 3%] Built target _dynamic_reconfigure_generate_messages_check_deps_Reconfigure
[ 3%] Built target _dynamic_reconfigure_generate_messages_check_deps_DoubleParameter
[ 3%] Built target _dynamic_reconfigure_generate_messages_check_deps_GroupState
[ 3%] Built target _dynamic_reconfigure_generate_messages_check_deps_ParamDescription
[ 3%] Built target _dynamic_reconfigure_generate_messages_check_deps_BoolParameter
[ 3%] Built target _dynamic_reconfigure_generate_messages_check_deps_IntParameter
[ 3%] Built target _dynamic_reconfigure_generate_messages_check_deps_SensorLevels
[ 3%] Built target _dynamic_reconfigure_generate_messages_check_deps_Config
[ 3%] Built target dynamic_reconfigure_gencfg
[ 6%] Built target dynamic_reconfigure_config_init_mutex
[ 6%] Built target _dynamic_reconfigure_generate_messages_check_deps_Group
[ 6%] Built target _dynamic_reconfigure_generate_messages_check_deps_StrParameter
[ 7%] Built target gtest
[ 13%] Built target image_transport
[ 14%] Built target nodelet_topic_tools_gencfg
[ 14%] Built target bond_generate_messages_cpp
[ 14%] Built target bond_generate_messages_lisp
[ 14%] Built target bond_generate_messages_py
[ 14%] Built target _polled_camera_generate_messages_check_deps_GetPolledImage
[ 16%] Generating dynamic reconfigure files from cfg/mono.cfg: /home/pi/devel/james_ws/devel/include/ueye/monoConfig.h /home/pi/devel/james_ws/devel/lib/python2.7/dist-packages/ueye/cfg/monoConfig.py
[ 16%] Generating dynamic reconfigure files from cfg/stereo.cfg: /home/pi/devel/james_ws/devel/include/ueye/stereoConfig.h /home/pi/devel/james_ws/devel/lib/python2.7/dist-packages/ueye/cfg/stereoConfig.py
[ 17%] Built target plugin_tool
[ 20%] Built target camera_calibration_parsers
[ 23%] Built target nodelet_generate_messages_cpp
Traceback (most recent call last):
File "/home/pi/devel/james_ws/src/ueye/cfg/stereo.cfg", line 6, in
from dynamic_reconfigure.msg import SensorLevels
ImportError: No module named msg
Traceback (most recent call last):
File "/home/pi/devel/james_ws/src/ueye/cfg/mono.cfg", line 6, in
from dynamic_reconfigure.msg import SensorLevels
ImportError: No module named msg
ueye/CMakeFiles/ueye_gencfg.dir/build.make:83: recipe for target '/home/pi/devel/james_ws/devel/include/ueye/stereoConfig.h' failed
make[2]: *** [/home/pi/devel/james_ws/devel/include/ueye/stereoConfig.h] Error 1
make[2]: *** Waiting for unfinished jobs....
ueye/CMakeFiles/ueye_gencfg.dir/build.make:65: recipe for target '/home/pi/devel/james_ws/devel/include/ueye/monoConfig.h' failed
make[2]: *** [/home/pi/devel/james_ws/devel/include/ueye/monoConfig.h] Error 1
CMakeFiles/Makefile2:6580: recipe for target 'ueye/CMakeFiles/ueye_gencfg.dir/all' failed
make[1]: *** [ueye/CMakeFiles/ueye_gencfg.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 25%] Built target nodelet_generate_messages_py
[ 28%] Built target nodelet_generate_messages_lisp
[ 37%] Built target dynamic_reconfigure_generate_messages_lisp
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2
Invoking "make -j4 -l4" failed

Shebang in setup_custom_pythonpath.sh.in

I've run into some issues while building an arm Docker image to run my ROS application. I think the issue has to do with missing shebang (#!/usr/bin/env bash) in the cmake/setup_custom_pythonpath.sh.in file.

I think it's related to how Docker executes RUN statements - see http://kimh.github.io/blog/en/docker/gotchas-in-writing-dockerfile-en/ and paragraph on exec format error.

I only run into the issue in my arm images, as they are build using the technique described here: https://resin.io/blog/building-arm-containers-on-any-x86-machine-even-dockerhub/ (using qemu).

My project has been building fine until I introduced dynamic_reconfigure - and after trying to isolate the problem, I have been able to build in my docker container if I add the shebang to the generated setup_custom_pythonpath.sh file.

Forgive me if my understanding of the problem is incorrect, but would it make sense to include the shebang in the template file used to generate the setup_custom_pythonpath.sh file?

set queue_size=1 on publishers

hey,

In hydro, queue size is an optional parameter, but is suggested to be used.
I suggest size of 1, but anything would do.

Specifically, lines:
self.descr_topic = rospy.Publisher('~parameter_descriptions', ConfigDescrMsg, latch=True, queue_size=1)

and

self.update_topic = rospy.Publisher('~parameter_updates', ConfigMsg, latch=True, queue_size=1 )

in

/opt/ros/indigo/lib/python2.7/dist-packages/dynamic_reconfigure/server.py

header file generated everytime generate_dynamic_reconfigure_options() is exectuted

Hi,
I have the tutorial package from http://wiki.ros.org/dynamic_reconfigure/Tutorials/HowToWriteYourFirstCfgFile . Every time I do catkin_make even though the cfg files are not edited the header files are generated. This causes any executables that depend on the header to be rebuilt. I am using ros-hydro on ubuntu 12.04.

bpwiselybabu@bpwiselybabu-Lenovo-IdeaPad-Y580:~/drc_workspace$ catkin_make --pkg dynamic_tutorials
Base path: /home/bpwiselybabu/drc_workspace
Source space: /home/bpwiselybabu/drc_workspace/src
Build space: /home/bpwiselybabu/drc_workspace/build
Devel space: /home/bpwiselybabu/drc_workspace/devel
Install space: /home/bpwiselybabu/drc_workspace/install

Running command: "make cmake_check_build_system" in "/home/bpwiselybabu/drc_workspace/build"

Running command: "make -j8 -l8" in "/home/bpwiselybabu/drc_workspace/build/drc/dynamic_tutorials"

Generating dynamic reconfigure files from cfg/Tutorial.cfg: /home/bpwiselybabu/drc_workspace/devel/include/dynamic_tutorials/TutorialConfig.h /home/bpwiselybabu/drc_workspace/devel/lib/python2.7/dist-packages/dynamic_tutorials/cfg/TutorialConfig.py
Generating reconfiguration files for Tutorials in dynamic_tutorials
Wrote header file in /home/bpwiselybabu/drc_workspace/devel/include/dynamic_tutorials/TutorialsConfig.h
Built target dynamic_tutorials_gencfg
bpwiselybabu@bpwiselybabu-Lenovo-IdeaPad-Y580:~/drc_workspace$ catkin_make --pkg dynamic_tutorials
Base path: /home/bpwiselybabu/drc_workspace
Source space: /home/bpwiselybabu/drc_workspace/src
Build space: /home/bpwiselybabu/drc_workspace/build
Devel space: /home/bpwiselybabu/drc_workspace/devel
Install space: /home/bpwiselybabu/drc_workspace/install

Running command: "make cmake_check_build_system" in "/home/bpwiselybabu/drc_workspace/build"

Running command: "make -j8 -l8" in "/home/bpwiselybabu/drc_workspace/build/drc/dynamic_tutorials"

Generating dynamic reconfigure files from cfg/Tutorial.cfg: /home/bpwiselybabu/drc_workspace/devel/include/dynamic_tutorials/TutorialConfig.h /home/bpwiselybabu/drc_workspace/devel/lib/python2.7/dist-packages/dynamic_tutorials/cfg/TutorialConfig.py
Generating reconfiguration files for Tutorials in dynamic_tutorials
Wrote header file in /home/bpwiselybabu/drc_workspace/devel/include/dynamic_tutorials/TutorialsConfig.h
Built target dynamic_tutorials_gencfg

Thanking you,
Benzun

parameter name 'i' results in compiler error

see this link

http://answers.ros.org/question/46724/auto-generated-dynamic_reconfigure-headers-fail-to-compile-depending-on-field-names/

Group configuration is not consistent

Let me first describe the current group state behaviour:

1. When the dynamic_reconfigure client starts, states are initialized to the latest published states from ~/parameter_updates. The states included in the published states are initialized to those described in the .cfg file, so this behaviour is correct.
2. When the consumer of the client attempts to update the state, it sends a configuration to update only the group(s) it intends to change the state on. The client internally grabs all of the states from the ~/parameter_descriptions to start with, and then applies the difference. There are two problems here:
   • The ~/parameter_descriptions (should) hold the default state values, which may have changed since startup.
   • The ~/parameter_descriptions currently populates the default group states all with True instead of the default state specified in the .cfg file.
3. This results in all states being set to True, except the states which the consumer intended to change, which are set appropriately.

My question is this: Should the states behave the same as the other parameters, in that they start with their default and any time a client changes a state, the change is propagated to the other clients?

This could be a little awkward for a collapse group, which collapses and is hidden when the state changes to False. One client collapsing the group would automatically collapse it on another. It would be possible to not propagate the collapse group state changes to the parameter server, meaning that this behaviour would not emerge. Is this a good move?

I am perfectly happy writing and fixing code, I just want to know how which way to head...

Thanks,

--scott

Unexpected installation dependency on source location

While debugging the issue discussed here http://answers.ros.org/question/105771/rqt_reconfigure-runtime-error-osx/ with @MrTatsch we discovered that the installed package has an unexpected dependency on the source directory. It seems that during the python package installation, $INSTALL_DIR/dynamic_reconfigure/__init__.py gets generated with a reference to the current source directory, so that when the installed package is used, the source directory is read.

This is very counter intuitive behaviour. If the source directory is deleted or renamed after installation, as was the case in the ROS Answers problem, then the installed versions of dynamic reconfigure ceases to function.

Enum descriptions with single quotes

If you write an enum description with a single quote and use it in C++, you will get some weird errors.

example package

dyn_param_error.zip

this works

combo_enum = gen.enum([
        gen.const("A", int_t, 0, "I can do it"),
        gen.const("B", int_t, 0, "I cant do it"),
       ],
  "x")

This doesn't

        gen.const("B", int_t, 0, "I can't do it"),

Errors

In file included from /home/dlu/bnr_software/src/bnr_autonomy/bnr_navigation/dyn_param_error/src/x.cpp:1:0:
/home/dlu/bnr_software/devel/include/dyn_param_error/DynParamConfig.h:387:475: warning: character constant too long for its type [enabled by default]
       Default.abstract_parameters.push_back(DynParamConfig::AbstractParamDescriptionConstPtr(new DynParamConfig::ParamDescription<int>("combination_method", "int", 0, "", "{'enum_description': 'x', 'enum': [{'srcline': 8, 'description': 'I can do it', 'srcfile': '/home/dlu/bnr_software/src/bnr_autonomy/bnr_navigation/dyn_param_error/cfg/DynParam.cfg', 'cconsttype': 'const int', 'value': 0, 'ctype': 'int', 'type': 'int', 'name': 'A'}, {'srcline': 9, 'description': "I can't do it", 'srcfile': '/home/dlu/bnr_software/src/bnr_autonomy/bnr_navigation/dyn_param_error/cfg/DynParam.cfg', 'cconsttype': 'const int', 'value': 0, 'ctype': 'int', 'type': 'int', 'name': 'B'}]}", &DynParamConfig::combination_method)));
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           ^
/home/dlu/bnr_software/devel/include/dyn_param_error/DynParamConfig.h:387:494: warning: multi-character character constant [-Wmultichar]
       Default.abstract_parameters.push_back(DynParamConfig::AbstractParamDescriptionConstPtr(new DynParamConfig::ParamDescription<int>("combination_method", "int", 0, "", "{'enum_description': 'x', 'enum': [{'srcline': 8, 'description': 'I can do it', 'srcfile': '/home/dlu/bnr_software/src/bnr_autonomy/bnr_navigation/dyn_param_error/cfg/DynParam.cfg', 'cconsttype': 'const int', 'value': 0, 'ctype': 'int', 'type': 'int', 'name': 'A'}, {'srcline': 9, 'description': "I can't do it", 'srcfile': '/home/dlu/bnr_software/src/bnr_autonomy/bnr_navigation/dyn_param_error/cfg/DynParam.cfg', 'cconsttype': 'const int', 'value': 0, 'ctype': 'int', 'type': 'int', 'name': 'B'}]}", &DynParamConfig::combination_method)));
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              ^
...[and many more]...

branches for ROS distros

Does this master branch work with all ROS distros?

Compiler Error on Gentoo

Remember when I said that dynamic_reconfigure emerged on Gentoo? Well, it did, but... Not so much anymore (the new ebuild format is pure CMake and doesn't call catkin).

Scanning dependencies of target dynamic_reconfigure_gencfg
make[2]: Leaving directory '/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build'
make -f CMakeFiles/dynamic_reconfigure_gencfg.dir/build.make CMakeFiles/dynamic_reconfigure_gencfg.dir/build
[  0%] Built target _dynamic_reconfigure_generate_messages_check_deps_SensorLevels
make[2]: Entering directory '/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build'
make[2]: Nothing to be done for 'CMakeFiles/std_msgs_generate_messages_nodejs.dir/build'.
make[2]: Leaving directory '/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build'
make[2]: Entering directory '/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build'
Dependee "/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/CMakeFiles/dynamic_reconfigure_config_init_mutex.dir/DependInfo.cmake" is newer than depender "/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/CMakeFiles/dynamic_reconfigure_config_init_mutex.dir/depend.internal".
Dependee "/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/CMakeFiles/dynamic_reconfigure_config_init_mutex.dir/depend.internal".
Scanning dependencies of target dynamic_reconfigure_config_init_mutex
make[2]: Leaving directory '/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build'
make -f CMakeFiles/dynamic_reconfigure_config_init_mutex.dir/build.make CMakeFiles/dynamic_reconfigure_config_init_mutex.dir/build
[  0%] Built target std_msgs_generate_messages_nodejs
[  1%] Generating dynamic reconfigure files from cfg/Test.cfg: /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/devel/include/dynamic_reconfigure/TestConfig.h /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/devel/lib64/python3.5/site-packages/dynamic_reconfigure/cfg/TestConfig.py
make[2]: Entering directory '/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build'
catkin_generated/env_cached.sh /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/setup_custom_pythonpath.sh /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48/cfg/Test.cfg /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48 /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/devel/share/dynamic_reconfigure /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/devel/include/dynamic_reconfigure /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/devel/lib64/python3.5/site-packages/dynamic_reconfigure
[  3%] Building CXX object CMakeFiles/dynamic_reconfigure_config_init_mutex.dir/src/dynamic_reconfigure_config_init_mutex.cpp.o
/usr/bin/x86_64-pc-linux-gnu-g++  -DROSCONSOLE_BACKEND_LOG4CXX -DROS_PACKAGE_NAME=\"dynamic_reconfigure\" -Ddynamic_reconfigure_config_init_mutex_EXPORTS -I/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/devel/include -I/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48/include -I/opt/ros/lunar/include -I/opt/ros/lunar/share/xmlrpcpp/cmake/../../../include/xmlrpcpp   -march=core-avx2 -O3 -pipe -std=c++11 -fPIC   -o CMakeFiles/dynamic_reconfigure_config_init_mutex.dir/src/dynamic_reconfigure_config_init_mutex.cpp.o -c /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48/src/dynamic_reconfigure_config_init_mutex.cpp
Traceback (most recent call last):
  File "/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48/cfg/Test.cfg", line 37, in <module>
    from dynamic_reconfigure.parameter_generator_catkin import *
ImportError: No module named 'dynamic_reconfigure'
make[2]: Leaving directory '/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build'
make[2]: *** [CMakeFiles/dynamic_reconfigure_gencfg.dir/build.make:64: devel/include/dynamic_reconfigure/TestConfig.h] Error 1
make[2]: Leaving directory '/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build'
make[1]: *** [CMakeFiles/Makefile2:1477: CMakeFiles/dynamic_reconfigure_gencfg.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[  3%] Built target _dynamic_reconfigure_generate_messages_check_deps_Reconfigure
make[2]: Leaving directory '/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build'
[  3%] Built target _dynamic_reconfigure_generate_messages_check_deps_Config
[  4%] Linking CXX shared library devel/lib/libdynamic_reconfigure_config_init_mutex.so
/usr/bin/cmake -E cmake_link_script CMakeFiles/dynamic_reconfigure_config_init_mutex.dir/link.txt --verbose=1
/usr/bin/x86_64-pc-linux-gnu-g++  -fPIC -march=core-avx2 -O3 -pipe -std=c++11 -Wl,-O1 -Wl,--as-needed -shared -Wl,-soname,libdynamic_reconfigure_config_init_mutex.so -o devel/lib/libdynamic_reconfigure_config_init_mutex.so CMakeFiles/dynamic_reconfigure_config_init_mutex.dir/src/dynamic_reconfigure_config_init_mutex.cpp.o -lboost_system-mt -lboost_thread-mt -lboost_chrono-mt -lboost_date_time-mt -lboost_atomic-mt 
make[2]: Leaving directory '/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build'
[  4%] Built target dynamic_reconfigure_config_init_mutex
make[1]: Leaving directory '/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build'
make: *** [Makefile:128: all] Error 2

It goes without saying that this is should only be seen as low priority, but, should you have any ideas, please let me know!

Oh, this might be useful.

>>> Emerging (1 of 161) ros-lunar/dynamic_reconfigure-1.5.48::ros-overlay
 * dynamic_reconfigure-1.5.48-1.5.48.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ...                  [ ok ]
>>> Unpacking source...
>>> Unpacking dynamic_reconfigure-1.5.48-1.5.48.tar.gz to /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work
>>> Source unpacked in /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work
>>> Preparing source in /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48 ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48 ...
>>> Working in BUILD_DIR: "/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build"
cmake -C /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/gentoo_common_config.cmake -G Unix Makefiles -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_INSTALL_PREFIX=/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/image/opt/ros/lunar -DCMAKE_PREFIX_PATH=/opt/ros/lunar -DPYTHON_INSTALL_DIR=lib64/python3.5/site-packages -DPYTHON_EXECUTABLE=/usr/bin/ros-python-lunar -DCATKIN_BUILD_BINARY_PACKAGE=1 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_USER_MAKE_RULES_OVERRIDE=/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/gentoo_rules.cmake -DCMAKE_TOOLCHAIN_FILE=/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/gentoo_toolchain.cmake  /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48
loading initial cache file /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/gentoo_common_config.cmake
-- The C compiler identification is GNU 4.9.4
-- The CXX compiler identification is GNU 4.9.4
-- Check for working C compiler: /usr/bin/x86_64-pc-linux-gnu-gcc
-- Check for working C compiler: /usr/bin/x86_64-pc-linux-gnu-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/x86_64-pc-linux-gnu-g++
-- Check for working CXX compiler: /usr/bin/x86_64-pc-linux-gnu-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Using CATKIN_DEVEL_PREFIX: /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/devel
-- Using CMAKE_PREFIX_PATH: /opt/ros/lunar
-- This workspace overlays: /opt/ros/lunar
-- Found PythonInterp: /usr/bin/ros-python-lunar (found version "3.5.3") 
-- Using PYTHON_EXECUTABLE: /usr/bin/ros-python-lunar
-- Using default Python package layout
-- Using empy: /usr/bin/empy
-- Using CATKIN_ENABLE_TESTING: ON
-- Skip enable_testing() when building binary package
-- Using CATKIN_TEST_RESULTS_DIR: /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/test_results
-- Found gtest: gtests will be built
-- Using Python nosetests: /usr/bin/nosetests-3.5
-- catkin 0.7.6
-- Using these message generators: gencpp;geneus;genlisp;gennodejs;genpy
-- Boost version: 1.62.0
-- Found the following Boost libraries:
--   system
--   thread
--   chrono
--   date_time
--   atomic
-- dynamic_reconfigure: 10 messages, 1 services
CMake Warning at /opt/ros/lunar/share/catkin/cmake/catkin_package.cmake:416 (message):
  catkin_package() include dir
  '/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/devel/include'
  should be placed in the devel space instead of the build space
Call Stack (most recent call first):
  /opt/ros/lunar/share/catkin/cmake/catkin_package.cmake:102 (_catkin_package)
  CMakeLists.txt:31 (catkin_package)


CMake Warning at /opt/ros/lunar/share/catkin/cmake/catkin_package.cmake:416 (message):
  catkin_package() include dir
  '/var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/work/dynamic_reconfigure-1.5.48_build/devel/include'
  should be placed in the devel space instead of the build space
Call Stack (most recent call first):
  /opt/ros/lunar/share/catkin/cmake/catkin_package.cmake:102 (_catkin_package)
  CMakeLists.txt:31 (catkin_package)


-- <<< Gentoo configuration >>>
Build type      RelWithDebInfo
Install path    /var/tmp/portage/ros-lunar/dynamic_reconfigure-1.5.48/image/opt/ros/lunar
Compiler flags:
C               -march=core-avx2 -O3 -pipe
C++             -march=core-avx2 -O3 -pipe -std=c++11
Linker flags:
Executable      -Wl,-O1 -Wl,--as-needed
Module          -Wl,-O1 -Wl,--as-needed
Shared          -Wl,-O1 -Wl,--as-needed

Test fails on Arch Linux

While compiling dynamic_reconfigure on Arch Linux (e.g. with indigo), we get:

[  5%] Generating dynamic reconfigure files from cfg/Test.cfg: /home/user/dev/dynamic_reconfigure/build/devel/include/dynamic_reconfigure/TestConfig.h /home/user/dev/dynamic_reconfigure/build/devel/lib
/python2.7/site-packages/dynamic_reconfigure/cfg/TestConfig.py
[  5%] Built target _dynamic_reconfigure_generate_messages_check_deps_ParamDescription
Traceback (most recent call last):
  File "/home/user/dev/dynamic_reconfigure/cfg/Test.cfg", line 37, in <module>
    from dynamic_reconfigure.parameter_generator_catkin import *
ImportError: No module named 'dynamic_reconfigure'
CMakeFiles/dynamic_reconfigure_gencfg.dir/build.make:63: recipe for target 'devel/include/dynamic_reconfigure/TestConfig.h' failed
make[2]: *** [devel/include/dynamic_reconfigure/TestConfig.h] Error 1
make[2]: Target 'CMakeFiles/dynamic_reconfigure_gencfg.dir/build' not remade because of errors.
CMakeFiles/Makefile2:584: recipe for target 'CMakeFiles/dynamic_reconfigure_gencfg.dir/all' failed

We currently add -DCATKIN_ENABLE_TESTING=OFF to avoid the issue. See the original discussion in the AUR.

Feature Request: Reconfigure the white balance the same way it is possible in the wxPropView GUI

Commandline dynparam takes a few second to do "get"

Example

$ time rosrun dynamic_reconfigure dynparam get /wide_stereo_right
:
real    0m3.799s
user    0m2.084s
sys 0m0.308s

As far as experienced, this isn't the case with its python API dynamic_reconfigure.client.Client that can get node of 150+ in about 30 secs for rqt_reconfigure, which means 0.2 sec per each node (including other GUI tasks). If the same level of speed is realized that would be great.

amd64 Version: 1.5.31-0quantal-20130126-0941-+0000

Parameter oscillation when using rqt_reconfigure

I have observed this when using dynamic_reconfigure multiple times on completely unrelated robot systems, so I´m pretty sure it´s not just related to a specific setup: Sometimes when changing parameters, they will start oscillating between two different settings, with the slider in the user interface happily alternating between two settings at high frequency. By typing something into the SpinBox in the UI and pressing "Enter" multiple times, the issue can be "fixed" most of the time. There appears to be some kind of race condition happening between UI and target node, so it´s a bit hard to say which component is at fault.

This bug makes it very risky to use dynamic reconfiguration in many cases (say, controller parameter settings). Tested on 12.04/hydro/AMD64 from .debs with different nodes using dynamic_reconfigure.

-Wshadow warnings on generated dynamic reconfigure options files.

I'm on Ubuntu 16.04, ROS kinetic, but this issue also affects my 14.04/indigo machine.

I'm generating config options using generate_dynamic_reconfigure_options and it's making a header file with shadow variables, which is important because my nightly build machine uses -Wshadow and -Werror flags to build my code.

warning: declaration of ‘edit_method’ shadows a member of ‘code_package::adaptive_estimationConfig::ParamDescription<T>’ [-Wshadow]

warning: declaration of ‘description’ shadows a member of ‘code_package::adaptive_estimationConfig::ParamDescription<T>’ [-Wshadow]
...

Also errors for level, type, name, id, parent

Should be an easy fix.

Enums with string constants not working anymore

rqt_reconfigure does not accept enums with string constants:

The combo box is displayed corrctly, but if a selection is done I get the error:

Traceback (most recent call last):
File "/opt/ros/groovy/lib/python2.7/dist-packages/rqt_reconfigure/param_editors.py", line 288, in selected
self._combobox.setCurrentIndex(self.values[index])
TypeError: QComboBox.setCurrentIndex(int): argument 1 has unexpected type 'str'

This one is straight from amcl node choosing odom_model_type.

Changing enum implementation to integer constants does work as expected.

catkin version of ParameterGenerator should output a more helpful message when invoked incorrectly

As seen in http://answers.ros.org/question/55647/dynamic_reconfigure-and-catkin-is-tutorial-correct/, ParameterGenerator should inform users to add their generator scripts to CMakeLists.txt and use the generate_dynamic_reconfigure_options() macro, instead of aborting abruptly.

API Docs link broken

http://wiki.ros.org/dynamic_reconfigure

The link to the API documentation is broken and I'm not sure where to point it to.

Bool_t param issue

I'm using ROS Electric version. Now I have an issue about the bool_t param.
When I use the GUI, bool_t can be changed from 0 to 1 or the other way around.
However, when I use command-line, I can only change it from 0 to 1 (when default is 0), but not from 1 to 0.

I have an alternative solution for this. I changed bool_t to int_t and set the min_value and max_value to 0 and 1, respectively. But somehow this is not very......satisfying. Would u please try to locate the problem? Otherwise bool_t will become meaningless.

Groups do not maintain order like parameters

All parameters are enumerated in the order in which they were added during generation. This allows developers to organize their rqt_reconfigure layouts. Unfortunately, the parameter group code employs a dict to store the groups at one point, so the order is lost.

Location: https://github.com/ros/dynamic_reconfigure/blob/master/src/dynamic_reconfigure/encoding.py#L47-L81

Related: ros-visualization/rqt_common_plugins#287

Default constructed *Config instances should carry default values for all parameters

When I default construct a (generated) *Config instance in C++ the parameters are not initialized. It would be nice if all the parameters carried the values that are specified as defaults in the *.cfg file.
Right now I call params_ = MyConfig::__getDefault__() which does not seem very clean.

Bad output marked as error

The following line https://github.com/ros/dynamic_reconfigure/blob/master/cmake/gendeps#L62 outputs a message to stderr which is not an error. Than https://github.com/ros/dynamic_reconfigure/blob/master/cmake/cfgbuild.cmake#L71 will prepend "ERROR" to that output which is bad ouput for the user as it is not really a problem.

[feature] New feature to change dynamic parameter with timestamp

(this issue came from jsk-ros-pkg/jsk_recognition#1444)

I'd like to use dynamic_reconfigure for recognition with timestamp.
Currently, in most cases the config callback does not see the timestamp http://wiki.ros.org/dynamic_reconfigure/Tutorials/SettingUpDynamicReconfigureForANode%28python%29
and dynamic_reconfigure seems to be not designed to do so.

Any idea to fix this issue? Or dynamic_reconfigure already has this feature?
I think a solutioin is:

1. Change dynamic_reconfigure to serve another topic with timstamp (like dynamic_reconfigure/ReconfigureStamped). (currently, dynamic_reconfigure serves set_parameters service not topic)