Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support passing parameters as command line arguments #460

Closed
hidmic opened this issue Jun 13, 2019 · 4 comments
Closed

Support passing parameters as command line arguments #460

hidmic opened this issue Jun 13, 2019 · 4 comments
Labels
enhancement New feature or request

Comments

@hidmic
Copy link
Contributor

hidmic commented Jun 13, 2019

Feature request

Feature description

Currently, the only way to pass node parameters over the command line is via a YAML file. To improve usability, we'd like to be be able to pass key value pairs directly, as ROS1 rosrun does. Grounds for this have to be established here and then leveraged in downstream client libraries (e.g. rclpy and rclcpp).

As a proposal for a syntax and since ROS1 syntax e.g. _name:=value would be parsed as a ROS2 remapping rule, we could make use of a dotted '.' equivalent .name:=value (credits to @sloretz for it). For a usage example, consider:

ros2 run demo_nodes_cpp talker \
  .bool_param:=true \
  .int_param:=1 \
  .float_param:=1.2 \
  .str_param:='...' \
  .bool_array_param:="[true, false, true]" \
  .int_array_param:="[1, 2, 3]" \
  .float_array_param:="[1.0, 2.0, 3.0]" \
  .str_array_param:="['a', 'b', 'c']" \
  .nested.int_param:=0 \
  .nested:="{str_param: '...'}"

which would roughly equate to the following YAML file:

bool_param: true
int_param: 1
float_param: 1.2
str_param: '...'
bool_array_param: [true, false, true]
int_array_param: [1, 2, 3]
float_array_param: [1.0, 2.0, 3.0]
str_array_param: ['a', 'b', 'c']
nested:
  int_param: 0
  str_param: '...'

Implementation considerations

As a likely prerequisite, #246 has to be implemented first.

@hidmic hidmic added the enhancement New feature or request label Jun 13, 2019
@jhdcs
Copy link
Contributor

jhdcs commented Jun 17, 2019

Is this the same thing as #370?

@wjwwood
Copy link
Member

wjwwood commented Jun 24, 2019

I would prefer to see a more explicit parameter marker than .. I understand that it neatly disambiguates _foo:=bar (hidden topic _foo remaps to bar) from _foo:=bar (override parameter foo to have a value of bar), but if we're going to diverge from ROS 1 anyways, I'd like to see a more explicit flag, as I said before. Maybe something like -p<key>:=<value>, at the risk of overlapping with user arguments in someway.

I also do not care for using . as I would still like to see parameters go back to using / as their separator at some pointer (necessitating node namespaces change to . instead of / too). I know we already rely on the . in existing examples and stuff like that, but I can't help but hesitate before making further dependence on it if it can be avoided.

@hidmic
Copy link
Contributor Author

hidmic commented Jul 4, 2019

Is this the same thing as #370?

Yes, it is a duplicate. Thanks for pointing it out @jhdcs. @dirk-thomas I'd be inclined to close #370 as it's somewhat bare compared to this ticket in terms of description and discussion. Do you agree?

I also do not care for using . as I would still like to see parameters go back to using / as their separator at some pointer (necessitating node namespaces change to . instead of / too).

I understand. Over the course of last week, @wjwwood and I have been discussing about ROS 2 resource addressing in general (be them topics, services, actions, parameters, nodes). As a result of that, I've opened ros2/design#241 which I think reflects what the ideal state would look like.

Maybe something like -p:=, at the risk of overlapping with user arguments in someway.

Hmm, I'm not a big fan of the -p prefix but I'm not really into the operator modification I propose on ros2/design#242 either. Ideas and alternatives are more than welcome.

@mjcarroll mjcarroll added backlog and removed backlog labels Feb 5, 2020
@hidmic
Copy link
Contributor Author

hidmic commented Mar 19, 2020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants