ROS - actionlib library (a) understand

Outline

In any large ROS-based system, there is such a situation: someone wants to send a request to a node to perform certain tasks, and receive a response to the request. This can be achieved by ROS service.

However, in some cases, if the service takes a long time to perform, the user may want to cancel the request during the execution, or get regular feedback on the progress of the request. actionlib package provides the tools to create server, server to perform these long-term goals can be preempted. It also provides a client interface to send requests to the server.

A detailed description

About how actionlib "in the background" complete discussion of operations, please refer to the detailed description .

The client - server interaction

ActionClient ActionServer and communicate through "ROS behavior agreement", the protocol is built on top of ROS message. Then, the client and server to the API provides a simple user, for requesting a target (client) or the execution target (the server) by function calls and callbacks.

Code of Conduct: Goal, Feedback, & Result

In order for the client and server communicate, we need to define some of the messages they communicate. This is a normative behavior. This defines the target client and server communication, feedback and result messages:

Goal

In order to use behavior to complete the task, we introduced the concept of a target, it can be sent to a ActionServer through a ActionClient. In the case of a mobile chassis, the objectives will contain information about a robot should move to a world where, with fixed-function information. In order to control the tilt of the laser scanner, the scan parameters including the target (minimum angle, the maximum angle, speed, etc.).

Feedback

Feedback provides a way for the server to tell who achieve a ActionClient gradual progress on a goal. For mobile chassis, which may be the current posture of the robot on the path. In order to control the tilt of the laser scanner, which may be completed before the scan time.

Result

After completion of the target, the result is transmitted from ActionServer to ActionClient. This feedback is different because it only sent once. When the purpose of the action is to provide some information, which is very useful. For mobile chassis, the result is not very important, but it may contain the final posture of the robot. In order to control the tilt of the laser scanner, the result may be generated from the point cloud comprising a scan request.

action file

Code of Conduct use .action file. .action defined target file, then the result is defined, then the feedback is defined, each with three portions of a hyphen (-) separated.

These files are placed in the directory ./action package, looks very similar service .srv file. An action plan might look like this place:
./action/DoDishes.action

# 定义目标goal
uint32 dishwasher_id  # Specify which dishwasher we want to use
---
# Define the result
uint32 total_dishes_cleaned
---
# Define a feedback message
float32 percent_complete

.Action on the basis of this, it is necessary to generate six messages to the client and server communicate. This generation can be triggered automatically in the production process:

Create a package using Catkin

Create a file package contains .action

find_package(catkin REQUIRED genmsg actionlib_msgs)
add_action_files(DIRECTORY action FILES DoDishes.action)
generate_messages(DEPENDENCIES actionlib_msgs)

Additional, package.xml package containing the file must contain at .action since:

<build_depend>actionlib_msgs</build_depend>
<exec_depend>actionlib_msgs</exec_depend>

Also in front of the package.xml 2 format is that you can use depend mark:

<depend>actionlib</depend>
<depend>actionlib_msgs</depend>

Creating dependencies actionlib API's

Package relies actionlib API to implement a server behavior, or behavior since actionlib to use the client.
CMakeLists.txt

find_package(catkin REQUIRED genmsg actionlib_msgs actionlib)
add_action_files(DIRECTORY action FILES DoDishes.action)
generate_messages(DEPENDENCIES actionlib_msgs)

package.xml

<build_depend>actionlib</build_depend>
<build_depend>actionlib_msgs</build_depend>
<exec_depend>actionlib</exec_depend>
<exec_depend>actionlib_msgs</exec_depend>

result

For DoDishes.action, the message generated by genaction.py:

DoDishesAction.msg
DoDishesActionGoal.msg
DoDishesActionResult.msg
DoDishesActionFeedback.msg
DoDishesGoal.msg
DoDishesResult.msg
DoDishesFeedback.msg

The message is then used by the internal actionlib, for communication between ActionClient and ActionServer.

Use ActionClient

C ++ SimpleActionClient

Complete API Reference C ++ SimpleActionClient

Quick Guide:
Suppose you have defined DoDishes.action chores in the bag. The following code fragment shows how to make a goal to DoDishes ActionServer, referred to as "do_dishes".

   1 #include <chores/DoDishesAction.h> // Note: "Action" is appended
   2 #include <actionlib/client/simple_action_client.h>
   3 
   4 typedef actionlib::SimpleActionClient<chores::DoDishesAction> Client;
   5 
   6 int main(int argc, char** argv)
   7 {
   8   ros::init(argc, argv, "do_dishes_client");
   9   Client client("do_dishes", true); // true -> don't need ros::spin()
  10   client.waitForServer();
  11   chores::DoDishesGoal goal;
  12   // Fill in goal here
  13   client.sendGoal(goal);
  14   client.waitForResult(ros::Duration(5.0));
  15   if (client.getState() == actionlib::SimpleClientGoalState::SUCCEEDED)
  16     printf("Yay! The dishes are now clean");
  17   printf("Current State: %s\n", client.getState().toString().c_str());
  18   return 0;
  19 }

Note: For C ++ SimpleActionClient, if a single thread is for the client callback queue service, waitForServer method will work. Use spinner running multithreaded, or use your own threads to service ROS callback queue, which need to pass true in the constructor options spin_thread client machine.

Achieve ActionServer

C++ SimpleActionServer

Complete API Reference C ++ SimpleActionServer

Quick Guide:
Suppose you have defined DoDishes.action in chores. The following code fragment shows how to write a DoDishes ActionServer, referred to as "do_dishes".

   1 #include <chores/DoDishesAction.h>  // Note: "Action" is appended
   2 #include <actionlib/server/simple_action_server.h>
   3 
   4 typedef actionlib::SimpleActionServer<chores::DoDishesAction> Server;
   5 
   6 void execute(const chores::DoDishesGoalConstPtr& goal, Server* as)  // Note: "Action" is not appended to DoDishes here
   7 {
   8   // Do lots of awesome groundbreaking robot stuff here
   9   as->setSucceeded();
  10 }
  11 
  12 int main(int argc, char** argv)
  13 {
  14   ros::init(argc, argv, "do_dishes_server");
  15   ros::NodeHandle n;
  16   Server server(n, "do_dishes", boost::bind(&execute, _1, &server), false);
  17   server.start();
  18   ros::spin();
  19   return 0;
  20 }

SimpleActionServer target policy

In the above ActionServer class, SimpleActionServer achieve a single goal strategy. Description of the policy are as follows:

1. Only one target can have an active state at the same time.
2. (Later goal to seize the early goal) based on previous mark, in their GoalID field, you can seize the new target goal
3. A certain explicit preemption preempts all timestamps, the timestamp is less than or equal to those markers associated with preemption.
4. To accept a new target means that successfully seize any old target, the state of the old target will automatically change to reflect this.

Call acceptNewGoal to accept a new target when available. The state target is set to be activated in an interview, and the status of any previous activity goals will be set to seize. Received at check isNewGoalAvailable or call the target callback and call acceptNewGoal will not trigger a new target between preempt callback preemption. This means that, isPreemptRequested should target after receiving calls even realize callback-based, in order to ensure that the new target will not have to seize the pending request.