search

ros / actionlib

Provides a standardized interface for interfacing with preemptable tasks. Examples of this include moving the base to a target location, performing a laser scan and returning the resulting point cloud, detecting the handle of a door, etc.
http://www.ros.org/wiki/actionlib
96 stars 155 forks source link

ActionClient send_goal and cancel retries #52

Open sjfwilson opened 8 years ago

sjfwilson commented 8 years ago

I am investigating the work require to implement support for retrying send_goal and cancel requests within ActionClient. This effort is driven by the fact that the ActionServers are on separate machines using a WiFi network. The separate machines may be turned off, or the network may be interrupted and be down for a while. In both cases, when a goal or cancel request is sent from the Client to a previously-connected Server, the message is effectively "lost", but ActionClient is not aware of the loss.

At present I have a couple of options I am considering:

  1. Implement an ActionClient wrapper in which the resend logic will be implemented. The wrapper will be used by the application instead of ActionClient directly. The primary intention of the wrapper is to minimize changes to ActionLib itself.
  2. Implement the resend logic within the ActionClient itself, primarily the CommStateMachine. This path minimizes changes to the application.

In either case, the resend logic would effectively be the same, implementing a timer or event-scheduler for all ActionClients within the node to use.

I found that the C++ ActionClient offers a ClientGoalHandle resend() method, which is not offered in the Python implementation. What was this to push logic for goal resends to the application?

Any thoughts in implementing retry logic for ActionClients?

sjfwilson commented 8 years ago

We have been working on the ActionClient robustness/resend design. During the most recent review of the design, and while discussing strategy for resending goals on a timer, the following question was asked:

"Does anyone use ActionClient/ActionServer with the expectation that goals are processed on the Server in the order that they are sent by the Client?"

We know that using TCP for topic transport in ROS implicitly provides in-order delivery of messages, including the goals. Does this extend into any implicit guarantee provided by the ActionClient interface? Is this something you have any insight into?

Is this something that people would explicitly implement in their application, for example using Are there any guarantees like this that we need to continue to provide with any changes we would put up for review?