1.Overview
通常情况下使用topic和service即可满足系统的通讯需求
In any large ROS based system, there are cases when someone would like to send a request to a node to perform some task, and also receive a reply to the request. This can currently be achieved via ROS services.
某些情况下需要请求能够中断或者能够给予反馈
In some cases, however, if the service takes a long time to execute, the user might want the ability to cancel the request during execution or get periodic feedback about how the request is progressing. The actionlib package provides tools to create servers that execute long-running goals that can be preempted. It also provides a client interface in order to send requests to the server.
2.Detailed Description
2.1.Server Description
Server State Machine
Goals are initiated by an ActionClient. Once a goal is received by an ActionServer, the ActionServer creates a state machine to track the status of the goal:
Server Transitions
The majority of these state transitions are triggered by the server implementer, using a small set of possible commands:
setAccepted - After inspecting a goal, decide to start processing it
setRejected - After inspecting a goal, decide to never process it because it is an invalid request (out of bounds, resources not available, invalid, etc)
setSucceeded - Notify that goal has been successfully processed
setAborted - Notify that goal encountered an error during processsing, and had to be aborted
setCanceled - Notify that goal is no longer being processed, due to a cancel request
The action client can also asynchronously trigger state transitions:
CancelRequest: The client notifies the action server that it wants the server to stop processing the goal.
Server States
Intermediate States
Pending - The goal has yet to be processed by the action server
Active - The goal is currently being processed by the action server
Recalling - The goal hasnot been processed and a cancel request has been received from the action client, but the action server has not confirmed the goal is canceled
Preempting - The goal is being processed, and a cancel request has been received from the action client, but the action server has not confirmed the goal is canceled
Terminal States
Rejected - The goal was rejected by the action server without being processed and without a request from the action client to cancel
Succeeded - The goal was achieved successfully by the action server
Aborted - The goal was terminated by the action server without an external request from the action client to cancel
Recalled - The goal was canceled by either another goal, or a cancel request, before the action server began processing the goal
Preempted - Processing of the goal was canceled by either another goal, or a cancel request sent to the action server
Simple Action Server
Many action servers follow a similar pattern where only one goal can be active at a time and each new goal preempts the previous one. The simple action server is a wrapper around the action server designed to enforce this simple policy for processing goals.
Upon reception of a new goal from an action client, the simple action server moves that goal into its pending slot. If a goal already occupies the pending slot, the simple action server sets that goal to canceled and replaces it with the goal that came in over the wire.
Once a new goal is received by the simple action server and is moved into the pending slot, the user of the simple action server is notified that a new goal is available. This notification occurs in one of two ways as described in the Notificaton of Goals section below. Upon receiving notification, the user can accept the goal which causes the goal in the pending slot to move to the current goal slot, and allows the user to modify the state machine associated with the newly accepted goal.
2.2.Client Description
Client State Machine
In actionlib, we treat the server state machine as the primary machine, and then treat the client state machine as a secondary/coupled state machine that tries to track the server's state:
Client Transitions
Server triggered Transitions
Reported [State]: Since the client is trying to track the server's state, most transitions are triggered by the server reporting its state to the ActionClient.
Receive Result Message: In this case, the server sends a result message to the client. Receiving a result will always signal the end of tracking a goal.
Client Triggered Transitions
Cancel Goal: Request the server to stop processing this goal
Simple Action Client
In general, high level applications and executives only care whether a goal is being processed, or if it's complete. They very rarely care about all the intermediate states. The Simple Action Client factors the original client state machine into three states: Pending, Active, & Done
template
void SimpleActionClient::sendGoal(const Goal & goal,
SimpleDoneCallback done_cb,
SimpleActiveCallback active_cb,
SimpleFeedbackCallback feedback_cb)
{
// Reset the old GoalHandle, so that our callbacks won't get called anymore
gh_.reset();
// Store all the callbacks
done_cb_ = done_cb;
active_cb_ = active_cb;
feedback_cb_ = feedback_cb;
cur_simple_state_ = SimpleGoalState::PENDING;
// Send the goal to the ActionServer
gh_ = ac_->sendGoal(goal, boost::bind(&SimpleActionClientT::handleTransition, this, _1),
boost::bind(&SimpleActionClientT::handleFeedback, this, _1, _2));
}
2.3.Action Interface & Transport Layer
The action client and server communicate with each other using a predefined action protocol. This action protocol relies on ROS topics in a specified ROS namespace in order to transport messages.
ROS Messages
goal - Used to send new goals to servers
cancel - Used to send cancel requests to servers
status - Used to notify clients on the current state of every goal in the system.
feedback - Used to send clients periodic auxiliary information for a goal.
result - Used to send clients one-time auxiliary information upon completion of a goal
3.Client-Server Interaction
从图中可以看到Action Clinet和Action Server之间的交互是双向
4.Action Specification: Goal, Feedback, & Result
为了实现客户端和服务器的通信,需要定义一些消息包括Goal,Feedback,Result
In order for the client and server to communicate, we need to define a few messages on which they communicate. This is with an action specification. This defines the Goal, Feedback, and Result messages with which clients and servers communicate:
ActionClient发送Goal给ActionServer
Goal
To accomplish tasks using actions, we introduce the notion of a goal that can be sent to an ActionServer by an ActionClient. In the case of moving the base, the goal would be a PoseStamped message that contains information about where the robot should move to in the world. For controlling the tilting laser scanner, the goal would contain the scan parameters (min angle, max angle, speed, etc).
ActionServer发送给ActionClinet的反馈,周期反馈任务运行状态数据
Feedback
Feedback provides server implementers a way to tell an ActionClient about the incremental progress of a goal. For moving the base, this might be the robot's current pose along the path. For controlling the tilting laser scanner, this might be the time left until the scan completes.
ActionServer发给ActionClient的任务运行结果,只发送一次
Result
A result is sent from the ActionServer to the ActionClient upon completion of the goal. This is different than feedback, since it is sent exactly once. This is extremely useful when the purpose of the action is to provide some sort of information. For move base, the result isn't very important, but it might contain the final pose of the robot. For controlling the tilting laser scanner, the result might contain a point cloud generated from the requested scan.