ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
1 | initial version |
I think I am just launching the camera (raspicam_node) and suddenly out of nowhere comes a dynamic reconfigure.
I'm almost certain this is the default behaviour for dynamic_reconfigure
servers.
See #q28327 fi (the answer by @joq), #q250134 and finally the source of dynamic_configure
's Server::setCallback(..)
itself (from here):
void setCallback(const CallbackType &callback) { boost::recursive_mutex::scoped_lock lock(mutex_); callback_ = callback; callCallback(config_, ~0); // At startup we need to load the configuration with all level bits set. (Everything has changed.) updateConfigInternal(config_); }
Notice how it calls callCallback(..)
right after storing the callback
is assigned to callback_
(ie: the member variable).
This lets the server load the default values for all parameters using the same callback that is used to handle any incoming reconfigure requests from actual clients.
2 | No.2 Revision |
I think I am just launching the camera (raspicam_node) and suddenly out of nowhere comes a dynamic reconfigure.
I'm almost certain this is the default behaviour for dynamic_reconfigure
servers.
See #q28327 fi (the answer by @joq), @joq ), #q250134 and finally the source of dynamic_configure
's Server::setCallback(..)
itself (from here):
void setCallback(const CallbackType &callback) { boost::recursive_mutex::scoped_lock lock(mutex_); callback_ = callback; callCallback(config_, ~0); // At startup we need to load the configuration with all level bits set. (Everything has changed.) updateConfigInternal(config_); }
Notice how it calls callCallback(..)
right after storing the callback
is assigned to callback_
(ie: the member variable).
This lets the server load the default values for all parameters using the same callback that is used to handle any incoming reconfigure requests from actual clients.
3 | No.3 Revision |
I think I am just launching the camera (raspicam_node) and suddenly out of nowhere comes a dynamic reconfigure.
I'm almost certain this is the default behaviour for dynamic_reconfigure
servers.
See #q28327 fi (the (also the answer by @joq ), #q250134 and finally the source of dynamic_configure
's Server::setCallback(..)
itself (from here):
void setCallback(const CallbackType &callback) { boost::recursive_mutex::scoped_lock lock(mutex_); callback_ = callback; callCallback(config_, ~0); // At startup we need to load the configuration with all level bits set. (Everything has changed.) updateConfigInternal(config_); }
Notice how it calls callCallback(..)
right after storing the callback
is assigned to callback_
(ie: the member variable).
This lets the server load the default values for all parameters using the same callback that is used to handle any incoming reconfigure requests from actual clients.