rclcpp_action Namespace Reference

Classes
class	Client
struct	GoalUUID
class	Server

Enumerations
enum class	CancelResponse : int8_t { REJECT = 1 , ACCEPT = 2 }
enum class	CancelReturnCode : int8_t { Ok = 0 , Rejected = 1 , UnknownGoal = 2 , GoalTerminated = 3 }
enum class	GoalResponse : int8_t { REJECT = 1 , ACCEPT_AND_EXECUTE = 2 , ACCEPT_AND_DEFER = 3 }
enum class	GoalStatus : int8_t {   Unknown = 0 , Accepted = 1 , Executing = 2 , Canceling = 3 ,   Succeeded = 4 , Canceled = 5 , Aborted = 6 }

Functions
constexpr int32_t	to_ffi (CancelResponse r)
constexpr int32_t	to_ffi (GoalResponse r)

Variables
static const size_t	ACTION_NAME_MAX = 256

Enumeration Type Documentation

CancelResponse

enum class rclcpp_action::CancelResponse : int8_t

strong

Per-goal cancel decision returned from the user's cancel callback.

Issue 0796 — this is NOT the action_msgs/srv/CancelGoal RPC status; that is CancelReturnCode below. The two carry different meanings on overlapping FFI values (reject and Ok are both 0 there), so never cast between them. C names them apart too (rclc_cancel_response_t vs rclc_cancel_return_code_t), and Rust now does (nros_core::CancelResponse vs nros_core::CancelReturnCode).

Upstream's enum, value for value: rclcpp_action::CancelResponse is int8_t with REJECT = 1, ACCEPT = 2, and so is this one (0-based and CamelCase until issue 1637). The FFI is 0-based (RCLC_C_CANCEL_REJECT = 0): convert with rclcpp_action::to_ffi(CancelResponse), never with a static_cast<int32_t>.

Enumerator
REJECT
ACCEPT

CancelReturnCode

enum class rclcpp_action::CancelReturnCode : int8_t

strong

action_msgs/srv/CancelGoal RPC return code — the WHOLE-REQUEST outcome (issue 0796).

Written by a polling-tier server into send_cancel_reply, and read by a client from ActionClient::try_recv_cancel_response. Distinct from the per-goal CancelResponse above; these four discriminants are the wire contract, fixed by action_msgs.

Enumerator
Ok
Rejected
UnknownGoal
GoalTerminated

GoalResponse

enum class rclcpp_action::GoalResponse : int8_t

strong

Goal acceptance response returned from the user's goal callback.

Upstream's enum, value for value: rclcpp_action::GoalResponse is int8_t with REJECT = 1, ACCEPT_AND_EXECUTE = 2, ACCEPT_AND_DEFER = 3, and so is this one, enumerator for enumerator, so a ported switch or a stored integer means the same thing on both. (Until issue 1637 these were 0-based and CamelCase: Reject = 0, AcceptAndExecute = 1, ...)

The FFI below is 0-based (RCLC_C_GOAL_REJECT = 0 in component.h), because a zero-initialised decision slot must mean reject. That integer is not this enum: convert with rclcpp_action::to_ffi(GoalResponse), NEVER with a static_cast<int32_t> — the cast yields upstream's value, and the FFI reads REJECT (1) as accept-and-execute.

Enumerator
REJECT
ACCEPT_AND_EXECUTE
ACCEPT_AND_DEFER

GoalStatus

enum class rclcpp_action::GoalStatus : int8_t

strong

Mirror of action_msgs/msg/GoalStatus — lifecycle state reported by for_each_active_goal.

Enumerator
Unknown
Accepted
Executing
Canceling
Succeeded
Canceled
Aborted

Function Documentation

to_ffi() [1/2]

constexpr int32_t rclcpp_action::to_ffi ( CancelResponse  r )

constexpr

The FFI discriminant of a cancel decision — RCLC_C_CANCEL_REJECT (0), RCLC_C_CANCEL_ACCEPT (1). Anything but ACCEPT maps to reject.

to_ffi() [2/2]

constexpr int32_t rclcpp_action::to_ffi ( GoalResponse  r )

constexpr

The FFI discriminant of a goal decision — RCLC_C_GOAL_REJECT (0), RCLC_C_GOAL_ACCEPT_AND_EXECUTE (1), RCLC_C_GOAL_ACCEPT_AND_DEFER (2). This is the value a raw component callback (create_action_server_raw) returns. Anything outside upstream's three values maps to reject, the FFI's own answer for "nobody decided".

Variable Documentation

ACTION_NAME_MAX

const size_t rclcpp_action::ACTION_NAME_MAX = 256

static

Bound on the action name an action entity remembers for get_action_name() — phase-417 W4.b.

ONE spelling for all four action classes. PollingActionServer and PollingActionClient each defined their own ACTION_NAME_MAX = 256 and the two callback tiers had neither, which is how the accessor came to exist on half the C++ action surface (ledger rows c:action_{client,server}_get_action_name, "four surfaces, one accessor"). Sized to match rclcpp::SUBSCRIPTION_TOPIC_NAME_MAX and the C surface's MAX_ACTION_NAME_LEN, so a name that fits one entity fits all of them and a truncation is not a per-class surprise.