[ros-users] [Discourse.ros.org] [Next Generation ROS] Actions in ROS 2

[Andreas Köpf]

Actions are one of the most important parts of ROS1 but they always felt a bit like an afterthought since they were implemented on top of topics and created a kind of namespace polution, e.g. visualization tools like rqt_graph optionally group the goal/feedback/status/cancel topics to hide this mess. On the other hand for debugging purposes it is very handy to be able to inspect the action communication between action clients and servers.


Here is my design feedback:

- It should be clearly detectable by clients that an action server node crashed and was restarted. I implemented a work-around for this for our own action client libs (see in .net [[1]](https://github.com/Xamla/ROS.NET/blob/01459b53d9b86944fa269fc0de034b505b2f5e73/Uml.Robotics.Ros/ActionLib/ActionClient.cs#L555) and lua [[2]](https://github.com/Xamla/torch-ros/blob/3b5f95985542299dbab7bf01865e40788d6878f1/lua/actionlib/ActionClient.lua#L333)) by detecting non-monotonously increasing sequence numbers of messages received on the status topic. Topic disconnect callbacks could unfortunately not be used in ROS1 for quick detection of disconnects since they were executed only after a pretty long timeout period. Maybe in ROS2 this can be done in a clean way.

- During load tests of a action client implementation I observed a rare situation in which a goal was submitted but never actually reflected by the server. It is a bit artificially created but it can happen that a new action server crashes directly after a goal is submitted and then restarts but the non-monotonously seq check of the client (as described above) does not trigger since the async status topic subscription misses one of the first status messages, e.g. the client sees only increasing status messages while the newly created action server never mentions the goal. In my .net impl I added a check for this situation by counting status messages that are missing a goal waiting for ack, see [[3]](https://github.com/Xamla/ROS.NET/blob/01459b53d9b86944fa269fc0de034b505b2f5e73/Uml.Robotics.Ros/ActionLib/ActionClient.cs#L655). If I remember correctly the caller_id of the status connect callback could not be used to detect the action server restart. Maybe also a problem of weak
  server-process-identity.

- In general the initial handshake of ROS1 actionlib and the client/server identity handling is too brittle, e.g. very strange  situations can be created if two or more action servers are started under the same name (topics).

- It would be great if a new connection to an action server could be established within milliseconds. In ROS1 due to the async pub/sub mechanism and the dependency on the first status-message (server identity) the maximum connection frequency is pretty low, e.g. this is even noted in comments in the actionlib impl see for example [wait_for_server()](https://github.com/ros/actionlib/blob/d317e63ebabc6c437f8b9f73ece06acf348700ea/src/actionlib/action_client.py#L579-L581).

- From the server implementation perspective I remember that I made the mistake to call setAborted on a goal-handle before accepting it which did not work because setAborted must only be called in PREEMPTING or ACTIVE state. I am not sure if this complexity is really necessarly and to create an error when setAborted is called in PENDING state, e.g. setCanceled seems to be valid for most states.





---
[Visit Topic](https://discourse.ros.org/t/actions-in-ros-2/6254/4) or reply to this email to respond.