dynamic_reconfigure provides convenient features to set parameter values after the initialization of the node, but also to have parameter changes mirrored with the parameter server. This last feature has contributed to the widespread use of dynamic_reconfigure in replacement of many .yaml config files and getParam(...) calls in various projects I have worked on. Of course only one default value can be specified for each parameter in the .cfg, so if you have different values for different configurations, the .yaml files are still essential.
Now the problem comes when you want to enforce that a specific value is read from the parameter server during node initialization and if no values can be retrieved, trigger an error-handling behavior (return error code, throw exception, log error message...). With parameter server + getParam(...) I can easily enforce it, but with parameters specified in a .cfg, it seems that I can't. If I specify no default value for a parameter in the .cfg, I observe that my parameter is given a default value based on its primitive type. Where not having the getParam() can really bite you is if your node parameters are specified in a .yaml and you accidentally make a mistake in the namespace/naming of that parameter. Having gladly removed all my getParam() calls previously knowing that dynamic_reconfigure would do the work for me of fetching them from the parameter server, I find myself with an incorrect parameter value that goes unnoticed until it creates a failure.
I understand one solution might be to add a getParam(..) for those specific parameters and/or have my parameter initialization covered through unit tests, but it would be a lot more convenient for me to manage all my parameters from inside the .cfg file, adding a 'required' argument to the add(...) function for the parameters that need it. If the dynamic_reconfigure::Server cannot find these required parameters in its provided namespace, it could for instance throw an exception.
I tried to dig for similar issues but couldn't find anything related. Maybe there is something obvious that I missed? Is this a ROS 'anti-pattern'? If the feature makes sense, I'll be glad to help with the implementation.
dynamic_reconfigureprovides convenient features to set parameter values after the initialization of the node, but also to have parameter changes mirrored with the parameter server. This last feature has contributed to the widespread use ofdynamic_reconfigurein replacement of many .yaml config files andgetParam(...)calls in various projects I have worked on. Of course only one default value can be specified for each parameter in the .cfg, so if you have different values for different configurations, the .yaml files are still essential.Now the problem comes when you want to enforce that a specific value is read from the parameter server during node initialization and if no values can be retrieved, trigger an error-handling behavior (return error code, throw exception, log error message...). With parameter server +
getParam(...)I can easily enforce it, but with parameters specified in a .cfg, it seems that I can't. If I specify no default value for a parameter in the .cfg, I observe that my parameter is given a default value based on its primitive type. Where not having thegetParam()can really bite you is if your node parameters are specified in a .yaml and you accidentally make a mistake in the namespace/naming of that parameter. Having gladly removed all mygetParam()calls previously knowing thatdynamic_reconfigurewould do the work for me of fetching them from the parameter server, I find myself with an incorrect parameter value that goes unnoticed until it creates a failure.I understand one solution might be to add a
getParam(..)for those specific parameters and/or have my parameter initialization covered through unit tests, but it would be a lot more convenient for me to manage all my parameters from inside the .cfg file, adding a 'required' argument to theadd(...)function for the parameters that need it. If thedynamic_reconfigure::Servercannot find these required parameters in its provided namespace, it could for instance throw an exception.I tried to dig for similar issues but couldn't find anything related. Maybe there is something obvious that I missed? Is this a ROS 'anti-pattern'? If the feature makes sense, I'll be glad to help with the implementation.