nros C++ API
Lightweight ROS 2 client for embedded real-time systems (C++ headers)
Loading...
Searching...
No Matches
rclcpp_action::ServerGoalHandle< A > Class Template Reference

#include <server.hpp>

Public Types

using ConstSharedPtr = detail::Refused<ServerGoalHandle>
using Feedback = typename A::Feedback
using Goal = typename A::Goal
using Result = typename A::Result
using SharedPtr = detail::Refused<ServerGoalHandle>

Public Member Functions

void execute ()
const GoalUUID & get_goal_id () const
 The goal's id.
bool is_active () const
 The goal has not reached a terminal state.
bool is_canceling () const
 The goal is CANCELING: a cancel request for it was accepted.
bool is_executing () const
 The goal is EXECUTING.
 ServerGoalHandle (Server< A > *server, const GoalUUID &uuid)

Friends

struct detail::ServerUpstream< A >

Detailed Description

template<typename A>
class rclcpp_action::ServerGoalHandle< A >

rclcpp_action::ServerGoalHandle<A> — issue 2015, upstream's per-goal handle on a HOSTED build.

A token over (server, goal id), plus the goal message the goal callback was handed: every call forwards to the server keyed by the id, and the goal's state stays in the server's static arena (RFC-0019). Obtained only as the std::shared_ptr upstream's handle_cancel / handle_accepted receive; a freestanding build has no allocator for it, so SharedPtr is refused there and the goal-id-keyed Server<A> calls are the form.

Envelope: the handle names its server by address, so the server must not move while a handle is in use (it lives in a SharedPtr, which does not move it). Called from the executor's own task only — a goal handle used from a thread the application started races the executor (RFC-0002: no hidden threads, and no lock on a one-level image); run the goal from the accepted callback, or from a timer.

Member Typedef Documentation

◆ ConstSharedPtr

template<typename A>
using rclcpp_action::ServerGoalHandle< A >::ConstSharedPtr = detail::Refused<ServerGoalHandle>

◆ Feedback

template<typename A>
using rclcpp_action::ServerGoalHandle< A >::Feedback = typename A::Feedback

◆ Goal

template<typename A>
using rclcpp_action::ServerGoalHandle< A >::Goal = typename A::Goal

◆ Result

template<typename A>
using rclcpp_action::ServerGoalHandle< A >::Result = typename A::Result

◆ SharedPtr

template<typename A>
using rclcpp_action::ServerGoalHandle< A >::SharedPtr = detail::Refused<ServerGoalHandle>

Constructor & Destructor Documentation

◆ ServerGoalHandle()

template<typename A>
rclcpp_action::ServerGoalHandle< A >::ServerGoalHandle ( Server< A > * server,
const GoalUUID & uuid )
inline

Member Function Documentation

◆ execute()

template<typename A>
void rclcpp_action::ServerGoalHandle< A >::execute ( )
inline

Start EXECUTING this goal — issue 2027, upstream's execute(): ACCEPTED -> EXECUTING, publishing the status array. How a goal accepted with GoalResponse::ACCEPT_AND_DEFER starts (create_server already does it for ACCEPT_AND_EXECUTE, before handle_accepted). Upstream raises for a goal that is not ACCEPTED; this changes nothing then. Server<A>::execute(goal_id) reports which case it was.

◆ get_goal_id()

template<typename A>
const GoalUUID & rclcpp_action::ServerGoalHandle< A >::get_goal_id ( ) const
inline

The goal's id.

◆ is_active()

template<typename A>
bool rclcpp_action::ServerGoalHandle< A >::is_active ( ) const
inline

The goal has not reached a terminal state.

◆ is_canceling()

template<typename A>
bool rclcpp_action::ServerGoalHandle< A >::is_canceling ( ) const
inline

The goal is CANCELING: a cancel request for it was accepted.

◆ is_executing()

template<typename A>
bool rclcpp_action::ServerGoalHandle< A >::is_executing ( ) const
inline

The goal is EXECUTING.

◆ detail::ServerUpstream< A >

template<typename A>
friend struct detail::ServerUpstream< A >
friend
The documentation for this class was generated from the following file: