The mystery of Actionlib's life

I don't know why I put such a serious piece of technology in a sort of a story that would have a similar style of name, that's it: ^) Shenmegui

Someone in the garden has tidied up the Actionlib beginner's tutorial, I'll sort out the details of the actionlib. The first edition favors verbatim translation + small personal understanding. When I grow up some more understanding of the time to revise and update my more. My boss said it would be messy to start learning about Ros. I am an odd woman who likes to divide the secant ~\ (≧▽≦)/~

First, the service side description

1) goal is started on the actionclient side (client will send Sendgoal), once Actionserver received the goal request, it will create a state machine for this goal to track goal state transitions, repeat three times, A state machine is a tracking goal that is not a tracking actionserver:

Zou is the state transition diagram, which follows these states:

2) service-side status

• setaccepted -After checking to have goal, decide to start processing it

• setrejected -after prosecuting to goal, decide not to handle it because it is an invalid request (overflow, resource unavailable, invalid, etc.)

• setsucceeded - Tell goal to be properly executed

• setaborted -informs goal that a problem has been encountered while processing has to be terminated

• Setcanceled -informs the Cancle request that goal is no longer executed

action Client can also trigger state transitions asynchronously:

• cancelrequest : Clients notify action Server it wants the server to stop processing this goal service-side status

Service-side status Intermediate State

(as stated earlier, there are three simple states, that is, waiting for execution to hang)

• Pending -goal has not been processed by Actionserver.

• Active -goal is being processed by as

• Recalling -goal is not processed and the command to cancel it has been sent from the client, but as is not sure that the goal has been canceled (the time difference is caused?). ）

• preempting -goal is being processed and received a cancellation request from the AC, but as is not sure goal has been canceled.

End State

• rejected -AC did not send Cancle request, goal was rejected directly by as not processed by the goal is rejected by the action server without being processed and WI Thout a request from the action client to cancel

• succeeded -goal was successfully implemented as achieved successfully by the action server

• aborted -goal is terminated by as Cancle request without AC

• recalled -this goal was canceled by another goal or Cancle request before as start execution

• preempted -The goal in process is canceled by another goal or AC cancellation request

Concurrency issues

setaccepted-cancelrequest vs cancelrequest-setaccepted:

The direct saying is that as can still give goal to SA after receiving the CR. This is because the asynchronous competition mechanism for the CR is executed because the server cannot determine whether it is now in [PENDING] or [recalling] state because other code other than server has triggered the state transition.

Ii. Description of the client

1) Client state machine

Actionlib, the state machine of the server is the host, the state machine of the client is slave/coupler, it is in the state of following the host.

2) client-side conversion

Server-side Trigger conversions

• reported [State]: Because the client is following the host state, many transitions are the state transitions that trigger the client after the state transitions are notified

• Receive Result message: This state, the server sends a result message to the client. The receipt of result means that tracing the goal is over.

Client-triggered conversions

• Cancel Goal: Request Server to stop processing this Goal

"Skip" status

• Given that Ros is based on the Transport Layer protocol, it is very likely that the client does not receive updates for all server states. Therefore, we allow the client state machine to "skip" the trigger state of the server

  • Example: The client receives the update status of the [ preempted]server in the [waiting for GOAL ACK] state , and the client state can skip the [ACTIVE] state and transfer directly to the /c11> [Waiting for RESULT] status

• Because multi-AC can connect to a single as, one client is allowed to cancel the goal of another client. Therefore, when the [recalling] state of the server is received, the client is allowed to move from [PENDING] to the [recalling] state

Iii. Action interface and transport protocol

The day of the regular meeting, I first finishing four, and so finish finishing and then put three complete. It's going to be a third and a bust.

Iv. Agreement

1) Simple Action Client

Generally, high-level applications and executables do not care whether or not goal is handled or complete. They only care about the middle state. Simple Action client has only three state machines in its original state: Pending, Active, & Done

1.1) Client State Blur

We're going to have a meeting, and I'll write ...

The mystery of Actionlib's life