# How can I figure out the parameters a ROS2 executable accepts?

Given just the installed executables: How can I figure out if and in case which parameters a ROS2 executable (e.g. for one of the executables one gets with ros2 pkg executables) accepts?

edit retag close merge delete

Sort by » oldest newest most voted

In ROS 1 this was always covered in documentation, either on the wiki (e.g. https://wiki.ros.org/amcl#Parameters ) or as @Dirk Thomas suggested in the -h of the node itself.

There is not currently a way to pass parameter values to a node via the command line (but we're currently work on that, see: https://github.com/ros2/rclcpp/pull/477 ), but even if you could do so in a standard way already, you would not be able to know, without running the node, whether or not it uses parameters and if so which ones.

The problem is that the nodes express how they use parameters programmatically and it occurs in the same places that things like creating topics and services occur (usually the main function or the constructor of the derived Node class). So you can't get this information without also getting the side-effect of running the node.

We've discussed in the past that we could separate the logic where users declare an intention have certain parameters, either to a standalone free-function or static method (so it could be called without creating the node) or to a DSL file outside of the C++/Python code (similar to the .cfg files for dynamic reconfigure in ROS 1). That would let you describe the parameters that would be used in a way that it could be used in the code of the node and to generate documentation automatically.

However neither of these can capture parameters which aren't know ahead of time. By this I mean parameters whose name and/or type would be determined at runtime based on something like the values of other parameters or the state of the ROS graph, etc... An example of this is move_base , where you list the names of some "observation sources" in one parameter, and the names in that list become part of new parameter names for each observation source ( https://wiki.ros.org/costmap_2d/hydro... ). It would be an incremental improvement to be able to say "this node has at least these parameters, but possibly more..." but to be a replacement for hand written documentation it would need to be more complete I think.

Hopefully this is something we can address as the parameters in ROS 2 get more mature.

more

This is no major issue. I was just thinking about if I could implement a fuzzer which gets the executable interface without running it. But it would bei possible to get it done by running the executable before fuzzying once as well.

( 2018-05-25 12:33:32 -0600 )edit

The executable hopefully provides usage information when you pass -h / --help when you run it.

more