Implement SimpleActionServer and SimpleAction Client

[orduno]

Feature request

Feature description

ROS2 is missing an rclcpp_action::SimpleActionServer that is equivalent to ROS1 actionlib::SimpleActionServer, same for the action client.

ROS2 does come with some basic examples for implementing action clients and servers, but these don't fully implement the ROS1 SimpleActionServer policy.

[orduno]

We've created a simple action server for nav2.

[jacobperron]

@orduno The link appears to be broken.

I'm happy to iterate with you if you would like to work on getting this into rclcpp_action.

[orduno]

@jacobperron Ups should work now.

Yes, let's work together to get something into rclcpp_action.

Here's the PR with some additional details.

[mkhansenbot]

I think this is needed. @jacobperron - have you looked at what we have in nav2? We could submit this here instead.

As a side note, I think this would be useful for projects like MoveIt2, I know MoveIt uses SimpleActionClient & Server. @davetcoleman, care to comment on that?

[jacobperron]

I'm not convinced that we need a separate entity like "SimpleActionServer" to achieve what we want. IIUC, what we want is a single goal policy (described here). For better semantics, I would use the name single-goal action server.

Depending on ones use-case, achieving this policy is fairly straight-forward (without much boilerplate). For example, I've recently added what is effectively a single-goal action server to turtlesim. When the action server is created we make it so all goal requests and cancel requests are accepted:

https://github.com/ros/ros_tutorials/blob/cd34759c848955c0d4e3a2e500481d86f1affc62/turtlesim/src/turtle.cpp#L68-L81

And in the accepted callback, we add two lines (plus a log statement) to abort any current goal:

https://github.com/ros/ros_tutorials/blob/cd34759c848955c0d4e3a2e500481d86f1affc62/turtlesim/src/turtle.cpp#L138-L142

This is similar to what is done in nav2's SimpleActionServer, except in the turtlesim scenario we don't need to worry about locks since it uses a single threaded executor.

I can think of some improvements we could make to the existing action server API related to a single-goal policy:

• We could default the goal request and cancel request callbacks to always accept (which seems like it may be common enough). This can be done by adding a callback struct as an argument to the constructor, similar to the SendGoalOptions struct for the action client.
• Expose an API for the server to preempt itself (ie. transition to canceling state). This is more like the SimpleActionServer in ROS 1. Besides, calling goal_handle->abort() with an empty result is limiting. It's better to have the option to transition to canceling in the accept callback so that an active goal can wrap up before terminating with a more meaningful result.
• Following the previous point, if it's possible that a previous goal will take time to wrap up after transitioning to canceling, then we need a mechanism for queuing goals. E.g. when a new goal request is accepted, we should wait to start executing until the previous goal execution thread stops. I believe this is the scenario in nav2, right? It's possible we might leverage some upcoming work to executors/callback groups to help streamline this use-case, but I have to think about it some more.

I think the first two improvements are easy wins. The third points deserves a little more thought, and is probably worth waiting to see what changes happen to executors (@wjwwood let me know if you agree). Depending on the complexity, it may make sense to add a concept of a single-goal (or N-goal) action server.

Let me know if I'm missing other features from ROS 1's SimpleActionServer that should be considered.

Also, correct me if I'm wrong, but it doesn't seem like we need to worry about adding an equivalent for "SimpleActionClient".

[jacobperron]

Expose an API for the server to preempt itself (ie. transition to canceling state).

See proposed API in https://github.com/ros2/rclcpp/pull/884

[wjwwood]

The third points deserves a little more thought, and is probably worth waiting to see what changes happen to executors (@wjwwood let me know if you agree).

I think that's right, changing the executors to not require a single executor per node would allow the action server to create it's own executor by default and spin it in a thread (giving you nice behavior out of the box) without fear of interfering with other stuff in the node. Advanced users could still control which executor is used in the action server/client with an option.

[DLu]

As @awesomebytes points out, I made C++/Python Simple Action interfaces here: https://github.com/DLu/simple_actions

Announcement

[mjcarroll]

I think that @DLu's contribution fulfills this request, so I'm going to close this out, with https://github.com/DLu/simple_actions being a good path forward for people looking for SimpleActionServer or SimpleActionClient capabilities.

Thanks for the contribution!