Skip to content

Fix typo in executor #264

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ralph-lange merged 5 commits into from
Dec 16, 2020
Merged

Fix typo in executor #264

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
e0e90d8
Update index.md
pablogs9 Dec 16, 2020
c58412d
Remove ToDo list completely.
ralph-lange Dec 16, 2020
99fdf19
Remove ToDo list completely.
ralph-lange Dec 16, 2020
99d7c04
Remove ToDo list completely.
ralph-lange Dec 16, 2020
287106f
Remove ToDo list completely.
ralph-lange Dec 16, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 2 additions & 6 deletions _docs/concepts/client_library/real-time_executor/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -181,12 +181,8 @@ 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.
<!--
TODO
- Bilder erweitern mit drei boxen: request IMU, process laser, fusion
dann wird klarer was mit den Daten wird
- 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.

<img src="png/sensorFusion_03.png" alt="Sychronization with sequence" width="350" />
Expand Down