--ros-args --help

[emersonknapp]

Description

Add an option to the argument parsing --help that at least prints out a usage string with the available arguments. Something automatic would be better, but being in pure C really limits our options... something manually written would be a fine start.

Motivation

Even for an experienced ROS 2 user, it's not easy to always remember what the commandline arguments are supposed to be to nodes. However, there's no usage text like in most CLI parsers. Let's add one to describe the args that are available.

Design / Implementation Considerations

No response

Additional Information

No response

[BlaineKTMO]

Hi @emersonknapp

Thanks for bringing this up! I've definitely struggled with the same in the past. If you're not working on this I'd like to tackle it as a new contributor.

I propose a small, query-only API addition to rcl arguments:

RCL_PUBLIC
bool
rcl_arguments_help_requested(const rcl_arguments_t * arguments);

This stores the fact that the help flag was added without changing control flow or initialization semantics. It is then up to higher level APIs (rclcpp, rclpy) to check for this flag during their init and terminate afterwards if appropriate.

An alternative solution is to handle it exclusively in rclpp/rclpy when they call rcl_arguments_get_unparsed() but that API seems to be for propagating unknown ros arguments . It also forces the wrapper libraries to re-interpret the arguments instead of relying on rcl as the source of truth.

I'd love to hear outside opinions on this - I thought this would be fairly straightforward but I ended up puzzling over this quite a bit.

[ros-discourse]

This issue has been mentioned on Open Robotics Discourse. There might be relevant details there:

https://discourse.openrobotics.org/t/ros-args-help-text/52198/1

[emersonknapp]

@BlaineKTMO Yeah, it's not necessarily trivial. I don't have a plan to work on this anytime soon, so contributions very welcome.

As far as I can tell rcl_arguments_get_unparsed is used just for raising an error in the language-appropriate way, not for re-parsing extra things at that client library level.

Maybe as a simpler first implementation than your proposal, in rcl_parse_args you could just do something like:

RCL_SET_ERROR_MSG_WITH_FORMAT_STRING("USAGE STRING");
ret = RCL_RET_INVALID_ARGUMENT;
goto fail;

And that would show as an error but at least abort and show the usage printout?