From e0e90d8f8cd2954d427fb9f6d1c9b81e04a5e87e Mon Sep 17 00:00:00 2001 From: Pablo Garrido Date: Wed, 16 Dec 2020 07:51:09 +0100 Subject: [PATCH 1/5] Update index.md --- _docs/concepts/client_library/real-time_executor/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/_docs/concepts/client_library/real-time_executor/index.md b/_docs/concepts/client_library/real-time_executor/index.md index 0d2d1fd6..8d5c7137 100644 --- a/_docs/concepts/client_library/real-time_executor/index.md +++ b/_docs/concepts/client_library/real-time_executor/index.md @@ -181,12 +181,12 @@ 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. 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. - +- Aus dem Bild die Beschreibung löschen --> + 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. Sychronization with sequence From c58412d5bb00019be5aaab8edf21fbce4e141ef9 Mon Sep 17 00:00:00 2001 From: Ralph Lange Date: Wed, 16 Dec 2020 08:04:04 +0100 Subject: [PATCH 2/5] Remove ToDo list completely. --- _docs/concepts/client_library/real-time_executor/index.md | 1 - 1 file changed, 1 deletion(-) diff --git a/_docs/concepts/client_library/real-time_executor/index.md b/_docs/concepts/client_library/real-time_executor/index.md index 8d5c7137..a9f0376b 100644 --- a/_docs/concepts/client_library/real-time_executor/index.md +++ b/_docs/concepts/client_library/real-time_executor/index.md @@ -183,7 +183,6 @@ Figure 6: Synchronization of multiple input data with a trigger. 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. From 99fdf19a4b67287aa4ee09fe08b5137fb2e5deb7 Mon Sep 17 00:00:00 2001 From: Ralph Lange Date: Wed, 16 Dec 2020 08:04:11 +0100 Subject: [PATCH 3/5] Remove ToDo list completely. --- _docs/concepts/client_library/real-time_executor/index.md | 1 - 1 file changed, 1 deletion(-) diff --git a/_docs/concepts/client_library/real-time_executor/index.md b/_docs/concepts/client_library/real-time_executor/index.md index a9f0376b..6cdf0f8f 100644 --- a/_docs/concepts/client_library/real-time_executor/index.md +++ b/_docs/concepts/client_library/real-time_executor/index.md @@ -183,7 +183,6 @@ Figure 6: Synchronization of multiple input data with a trigger. 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. 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. From 99d7c04c7eea0c4387ac75061708b7d6c8cc1291 Mon Sep 17 00:00:00 2001 From: Ralph Lange Date: Wed, 16 Dec 2020 08:05:10 +0100 Subject: [PATCH 4/5] Remove ToDo list completely. --- _docs/concepts/client_library/real-time_executor/index.md | 1 - 1 file changed, 1 deletion(-) diff --git a/_docs/concepts/client_library/real-time_executor/index.md b/_docs/concepts/client_library/real-time_executor/index.md index 6cdf0f8f..bef1eb65 100644 --- a/_docs/concepts/client_library/real-time_executor/index.md +++ b/_docs/concepts/client_library/real-time_executor/index.md @@ -182,7 +182,6 @@ Figure 6: Synchronization of multiple input data with a trigger. 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. - 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. From 287106fdaeeea701dfb4a6cb7f909bfb0a52193e Mon Sep 17 00:00:00 2001 From: Ralph Lange Date: Wed, 16 Dec 2020 08:05:17 +0100 Subject: [PATCH 5/5] Remove ToDo list completely. --- _docs/concepts/client_library/real-time_executor/index.md | 1 - 1 file changed, 1 deletion(-) diff --git a/_docs/concepts/client_library/real-time_executor/index.md b/_docs/concepts/client_library/real-time_executor/index.md index bef1eb65..97055b01 100644 --- a/_docs/concepts/client_library/real-time_executor/index.md +++ b/_docs/concepts/client_library/real-time_executor/index.md @@ -182,7 +182,6 @@ Figure 6: Synchronization of multiple input data with a trigger. 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. -- Aus dem Bild die Beschreibung löschen --> 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.