Executor API. The API of the RCLC-Executor can be divided in two phases: Configuration and Running. #### Configuration phase During the configuration phase, the user shall define: - the total number of callbacks - the sequence of the callbacks - trigger condition (optional, default: ANY) - data com- muncation semantics (optional, default ROS2) As the Executor is intended for embedded controllers, dynamic memory management is crucial. Therefore at initialization of the RCLC-Executor, the user defines the total number of callbacks. The necessary dynamic memory will be allocated only in this phase and no more memory in the running phase. This makes this Executor static in the sense, that during runtime no additional callbacks can be added. Then, the user adds handles and the corresponding callbacks (e.g. for subscriptions and timers) to the Executor. The order in which this takes place, defines later the sequential processing order during runtime. For each handle the user can specify, if the callback shall be executed only if new data is available (ON_NEW_DATA) or if the callback shall always be executed (ALWAYS). The second option is useful when the callback is expected to be called at a fixed rate. The trigger condition defines when the processing of these callbacks shall start. For convenience some default conditions have been defined: - trigger_any(default) : start executing if any callback has new data - trigger_all : start executing if all callbacks have new data - trigger_one(&data) : start executing if data has been received - user_defined_function: the user can also define its own function with more complex logic With ‘trigger_any’ being the default, the current semantics of the rclcpp Executor is selected. The data communication semantics can be - ROS2 (default) - LET To be compatible with ROS2 rclcpp Executor, the existing rclcpp semantics is implemented as ‘ROS2’. That is, with the spin-function the DDS-queue is constantly monitored for new data (rcl_wait). If new data becomes available, then is fetched from DDS (rcl_take) immediately before the callback is executed. All callbacks are processed in the user-defined order, this is the only difference to the rclcpp Executor, in which no order can be specified. Secondly, the LET semantics is implemented such that at the beginning of processing all available data is fetched (rcl_take) and buffered and then the callbacks are processed in the pre-defined oper- ating on the buffered copy.
