ros / dynamic_reconfigure Goto Github PK
View Code? Open in Web Editor NEWLicense: BSD 3-Clause "New" or "Revised" License
License: BSD 3-Clause "New" or "Revised" License
Robot Operating System (ROS) =============================================================================== ROS is a meta-operating system for your robot. It provides language-independent and network-transparent communication for a distributed robot control system. Installation Notes ------------------ For full installation instructions, including system prerequisites and platform-specific help, see: http://wiki.ros.org/ROS/Installation
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.
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.
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.
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.
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.
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
[ 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
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.
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.
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.
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
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?
As per the tutorial, using dynparam from C++ code is not implemented.
Currently when dynamic reconfigure generates .h files from cfg files, they are created with:
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.
Let me first describe the current group state behaviour:
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.~/parameter_descriptions
to start with, and then applies the difference. There are two problems here:
~/parameter_descriptions
(should) hold the default state values, which may have changed since startup.~/parameter_descriptions
currently populates the default group states all with True
instead of the default state specified in the .cfg
file.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
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/
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
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/
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
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!
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]
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.
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()
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 inf
in the generated TestConfig.py, it works.
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/)
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.
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 :)
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
(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:
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:
add_group
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?
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?
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.
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?
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.
Does this master branch work with all ROS distros?
If you write an enum description with a single quote and use it in C++, you will get some weird errors.
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")
gen.const("B", int_t, 0, "I can't do it"),
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]...
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().
http://wiki.ros.org/dynamic_reconfigure
The link to the API documentation is broken and I'm not sure where to point it to.
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.
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
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:
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?
Moving issue from answers to github:
The name string cannot be the value "i", "state", or "name" as discussed in this issue:
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
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.
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
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
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
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.