Update _docs/concepts/client_library/execution_management/index.md

Co-authored-by: Ralph Lange <ralph-lange@users.noreply.github.com>

Author: JanStaschulat

_docs/concepts/client_library/execution_management/index.md

@@ -164,7 +164,7 @@ An Alternative would be to evalute the IMU sample and the laser scan by synchron
 Figure 6: Synchronization of multiple input data with a trigger.
 </center>
 
-In ROS 2, this is currently not possible to be modeled because of the lack of a trigger concept in the ROS2 Executor. Message filters could be used to synchronize input data based on the timestamp in the header, but this is only available in rclcpp (and not in rcl). Further more, it would be more efficient to have such a trigger concept directly in the Executor.
+In ROS 2, this is currently not possible to be modeled because of the lack of a trigger concept in the Executors of rclcpp and rclpy. Message filters could be used to synchronize input data based on the timestamp in the header, but this is only available in rclcpp (and not in rcl). Further more, it would be more efficient to have such a trigger concept directly in the Executor.
 
 Another idea would be to activly request for IMU data only when a laser scan is received. This concept is shown in Figure 7. Upon arrival of a laser scan mesage, first, a message with aggregated IMU samples is requested. Then, the laser scan is processed and later the sensor fusion algorithm. An Executor, which would support sequential execution of callbacks, could realize this idea.