Feature request: Sending an Action goal can be complexed, require difficult steps

[130s]

This is about ROS2 Action's potential new feature. According to ros2/ros2#583 (comment) this repo is the right place, although it's more about user (developer) interface so I'm not entirely sure if this repo is appropriate. Please let me know if there's a better place, or feel free to transfer if possible.

---

Problem scope

Sending an Action goal involves a bit demanding process. This makes experimenting or debugging a process that entails Action difficult, probably far more challenging than ROS Topic and Service related processes.

Related concern is found in ros/actionlib#44 (comment), which I agree from my experience in (fast-paced) a startup where Action was eliminated by Service even for the cases Action was more semantically suitable. Though the referenced post and my anecdote are from ROS1, having seen Action's user interface up until Humble, my view remains the same in ROS2 so far.

Personal review of existing options:

• It's great that we have a CLI ros2 action send_goal, it's useful for simpler Goal structure. But as seen in answers.ros.org#416441, it is difficult to use for a goal with complexed structure.
• Both rclcpp and rclpy:
  • require a single line to instantiate an Action api object, which is awesome.
  • do require (? sorry I haven't verified it these are mandatory or not) 3 callbacks (goal_response, feedback, result) to be written. While this granurality gives applications a great flexibility, IMHO it understandably raises hurdle not just for quick experimenting, proto-typing, but also non-expriment coding (just my impression).

Problem breakdown

• Inputting the concrete values to a (complexed) goal definition is not easy. It's inherently a demanding task, so it's not a fault of ROS2 designers IMO.
• Callbacks: In some/many prototyping usecases, no special handling for any of Action's callbacks might be needed.

Feature description

Suggested approaches

(Just initial, rough suggestions. Open for discussion)

• Make typing goal easier. No special grammar like CLI does (that use both square and curly brackets).
• Have default callbacks behavior (as bash CLI already does), if it's not done yet (sorry I haven't verified this yet).

Implementation considerations

• axclient for ROS1 was a kind of popular tool (e.g. [noetic] Where is axclient.py ? ros/actionlib#167, answers.ros.org#399476) that provided GUI and made prototyping in sending Action goals much easier, but I can't find an equivalent in ROS2.
• Improve CLI to get rid of the need to use multiple brackets?

[fujitatomoya]

Make typing goal easier. No special grammar like CLI does (that use both square and curly brackets).

IMO, output is not really nice but auto-completion helps and not so hard to type in. some GUI or tools for typing aid, that would be nice to have.

Have default callbacks behavior (as bash CLI already does), if it's not done yet (sorry I haven't verified this yet).

So the question is what could be default behavior? in case of using CLI, we convert the message into yaml format to print if the option is specified by user, that is because that is what user likely check via ros2 action CLI. (i think that is the expectation here)

but if we add that default printing behavior to rclcpp or rclpy, it could bother many user application since that is not really what they want to do? instead, i think it would make sense to keep it NULL unless user application specifies?

[130s]

IMO, output is not really nice but auto-completion helps and not so hard to type in.

I agree CLI auto-complete is not so hard, for relatively simpler structure. I wouldn't say so though for the case of FollowJointTrajectory (ref. answers.ros.org#416441).

some GUI or tools for typing aid, that would be nice to have.

Thank you.

I'm getting more inclined to see how GUI will turn out useful (or not) and I'll see if I can do that as that'll be helpful for my immediate project where Action is involved a lot. I might open a separate ticket? For now I'm describing the direction I have in mind for the quick GUI dev project. Thoughts welcomed:

• Porting axclient to ros2 is a good starting point IMO.
• I'd likely port it to rqt (current one is wx, which I think may be problematic with Python3).

instead, i think it would make sense to keep it NULL unless user application specifies?

I think so too. Reason I brought up callbacks is because of my hypothesis that I'm afraid having to write callbacks has likely been raising developers mental hurdle. If default implementation is provided that don't break existing usecases that's great, and making such default as null sounds fine to me.