rclc Executor API Sample Clauses

rclc Executor API. The API of the rclc Executor can be divided in configuration and running phase. • the total number of callbacks, • the processing sequence of the callbacks, • trigger condition (optional, default: ANY), and • data communication semantics (optional, default ROS2). As the Executor is intended for embedded controllers, resource-efficient 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. Second, the user registers ROS 2 communication objects, like subscriptions and timers, to the Executor. This order defines the sequential processing order at the Running phase. Third, 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. Forth, 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. Finally, the data communication semantics can be • ROS2 (default) • LET To be compatible with ROS 2 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 (Logical Execution Time) 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 operating on the buffered copy. This semantics is useful for exchanging data between multiple threads safe...