Feature request
This is a request for a feature to allow waiting on action servers and action clients. Action servers and Action clients are to be implemented in libraries on top of the core rcl and rclcpp features in rcl_action and rclcpp_action. Adding them to the wait set in rcl is covered by ros2/rcl#335.
Feature description
This feature would allow an executor to wait on action servers and action clients which have servers/timers/clients/subscribers created in C. Since the individual entities don't have rclcpp::<Entity>Base types they can't be used by the existing callback group and executor APIs.
With #519 in mind it could make sense to change callback groups to be the class that adds things to the wait set, but I don't think there is time before the Crystal release. Instead this feature is proposing to add a new class to be used along with callback groups.
Implementation considerations
Assuming class called Waitable with virtual APIs
virtual get_number_of_entities(size_t * num_subscriptions, ...)
- Called by executor when determining how big to allocate the wait set
virtual void add_to_wait_set(rcl_wait_set_t *)
- Called by executor when populating the wait set
- Because
get_number_of_entities() and add_to_wait_set() are separate calls, it must be assumed that the number of entities in a Waitable are constant between the two calls. For actions this assumption holds because the number of waitable entities is constant for the life of the server and client.
virtual bool can_execute(rcl_wait_set_t *)
- Return true if there is something that can be executed in the waitset.
virtual void execute();
- It's assumed the waitable will set some state within itself during
can_execute() so that it does the right thing here.
Using Waitable requires:
Requires ros2/rcl#335 so Executor and Waitable can know which entities belong to which.
Feature request
This is a request for a feature to allow waiting on action servers and action clients. Action servers and Action clients are to be implemented in libraries on top of the core
rclandrclcppfeatures inrcl_actionandrclcpp_action. Adding them to the wait set inrclis covered by ros2/rcl#335.Feature description
This feature would allow an executor to wait on action servers and action clients which have servers/timers/clients/subscribers created in C. Since the individual entities don't have
rclcpp::<Entity>Basetypes they can't be used by the existing callback group and executor APIs.With #519 in mind it could make sense to change callback groups to be the class that adds things to the wait set, but I don't think there is time before the Crystal release. Instead this feature is proposing to add a new class to be used along with callback groups.
Implementation considerations
Assuming class called
Waitablewith virtual APIsvirtual get_number_of_entities(size_t * num_subscriptions, ...)virtual void add_to_wait_set(rcl_wait_set_t *)get_number_of_entities()andadd_to_wait_set()are separate calls, it must be assumed that the number of entities in aWaitableare constant between the two calls. For actions this assumption holds because the number of waitable entities is constant for the life of the server and client.virtual bool can_execute(rcl_wait_set_t *)virtual void execute();can_execute()so that it does the right thing here.Using
Waitablerequires:Waitable::SharedPtrfield toAnyExecutableExecutor::execute_any_executable()needs to callWaitable::execute()add_waitable(Waitable::SharedPtr)toNode, possibly viaNodeWaitableInterface(and an API to remove them)MemoryStrategyneeds apinumber_of_ready_waitables()AllocatorMemoryStrategy::add_handles_to_wait_set()needs to giveWaitablea chance to add thingsMemoryStrategyneeds apiget_next_waitable()to be used byExecutor::get_next_executableRequires ros2/rcl#335 so
ExecutorandWaitablecan know which entities belong to which.