Added static single threaded executor functionality by ishugoel20 · Pull Request #873 · ros2/rclcpp

ishugoel20 · 2019-09-25T14:08:14Z

Signed-off-by: Ishu Goel ishu.goel@nobleo.nl

This pull request aims to provide a static alternative to the existing single-threaded executor. In response to a question posted on ROS answers, we did research on the high CPU overhead of the existing implementation. The results of the research are here. Based on the results we started a discussion on ROS discourse here and we posted an issue on the rclcpp GitHub.

We contribute this static executor as an intermediate solution until another alternative is present or the existing executor is optimized. Our executor can be used by ROS users that have a static system to reduce CPU overhead.

An explanation of our static single-threaded executor is not included in this pull request but can instead be found here. This is an older Dashing version we made for testing. The README provides an overview in the form of a flowchart with a short description of functionality.

ishugoel20 · 2019-09-25T14:38:43Z

@alsora @fujitatomoya @ivanpauno @gbiggs @Karsten1987 can you have a look at this?

tfoote · 2019-09-25T23:24:42Z

This current implementation seems like it would be great to operate in environments such as when using the lifecycle nodes: https://design.ros2.org/articles/node_lifecycle.html

Currently the implementation requires that the all the setup is done before starting the spin which is relatively limiting. Would it be possible to modify this to react to events such as new subscriptions at which time it will rebuild the index that it is then iterating over until there's a new event triggering a reevaluation of the list to iterate.

There could be flags to keep it in permissive mode versus enforcing mode that tools like the lifecycle management and realtime environments might like to setup. But it seems that this would allow us to use this as a replacement for the current executor and get the benefits of faster iteration without requiring the developer to switch to a different executor.

MartinCornelis2 · 2019-09-26T07:11:40Z

We did already think about this. When a trigger occurs we can simply collect the handles, resize the wait-set and add the handles again. The list of executables can probably just be appended and may not require rebuilding. The only thing to consider in this case is waitables. Waitables may interfere with the order of things since they are added in a slightly different way(no longer possible to simply use indices to figure out what to execute). We could look into making a separate waitable struct, or figure out a way to retain a mapping between the wait-set and the list of executables. I think right now waitables work because they are assessed last and are always added at the end of the lists(I may be wrong here).

fujitatomoya · 2019-09-30T12:22:15Z

@MartinCornelis2

The list of executables can probably just be appended and may not require rebuilding. The only thing to consider in this case is waitables. Waitables may interfere with the order of things since they are added in a slightly different way(no longer possible to simply use indices to figure out what to execute).

can we just recreate entities and executable list via user's request for reconstruction? i believe that it is easier to implement, and besides this user event or request for reconstruction would not be happening every single time just like SingleThreadExecutor does. so i think that it is reasonable.

fujitatomoya · 2019-09-30T12:25:30Z

rclcpp/src/rclcpp/executors/static_single_threaded_executor.cpp

+    refresh_wait_set(timeout);
+    //Execute all the ready subscriptions
+    for (size_t i = 0; i < wait_set_.size_of_subscriptions; ++i) {
+      if (wait_set_.size_of_subscriptions && i < exec_list.number_of_subscriptions) {


check exec_list.number_of_subscriptions at 1st, so we do not do that every single loop of wait_set_.size_of_subscriptions ? also this applies to time, service and clients.

check exec_list.number_of_subscriptions at 1st, so we do not do that every single loop of wait_set_.size_of_subscriptions ? also this applies to time, service and clients.

@fujitatomoya thanks for the suggestion, we would consider making this change.

ishugoel20 · 2019-09-30T15:32:04Z

@fujitatomoya

can we just recreate entities and executable list via user's request for reconstruction? i believe that it is easier to implement, and besides this user event or request for reconstruction would not be happening every single time just like SingleThreadExecutor does. so i think that it is reasonable.

We are working on this, would share when this is ready.

rclcpp/include/rclcpp/executor.hpp

ivanpauno

First pass, I left some minimal comments (I have to do a more detailed review of the implementation).
The idea looks great!

It would be good to add some testing.
I think that these are the current executor tests:

rclcpp/include/rclcpp/memory_strategy.hpp

rclcpp/src/rclcpp/executor.cpp

ivanpauno · 2019-10-14T19:33:21Z

rclcpp/include/rclcpp/executors.hpp


 #include "rclcpp/executors/multi_threaded_executor.hpp"
 #include "rclcpp/executors/single_threaded_executor.hpp"
+#include "rclcpp/executors/static_single_threaded_executor.hpp"


Maybe, also add an using statement similar to lines 54-55. It's not strictly needed though.

I do not use StaticSingleThreadedExecutor in any of the below spin functions, so it is better not to include it in my view.

The MultiThreadedExecutor is also not used, and there is an using statement for it in line 54.
I'm not sure, but probably the original idea was to re-declare all executors in rclcpp::executors namespace.

You can ignore this comment for the moment, as it's a really not important and I'm not sure what was the idea of the original author.

rclcpp/include/rclcpp/executable_list.hpp

rclcpp/include/rclcpp/executors/static_single_threaded_executor.hpp

rclcpp/src/rclcpp/executable_list.cpp

rclcpp/src/rclcpp/executors/static_single_threaded_executor.cpp

ivanpauno · 2019-10-14T19:59:04Z

rclcpp/src/rclcpp/executors/static_single_threaded_executor.cpp

+  for (size_t i = 0; i < wait_set_.size_of_guard_conditions; ++i) {
+    if (wait_set_.guard_conditions[i]) {
+      // rebuild the wait_set and ExecutableList struct
+      run_collect_entities();


Why collecting entities again? Isn't this an static executor where the entities are collected once and then you just refresh the wait set?

At first we implemented the executor to be fully static, but this was quite restrictive. Now we use the node guard_conditions to check if something was added to a node at runtime. If this happens then we rebuild. This means that if nothing is added at runtime (everything is in place before .spin() ), this executor still behaves as a fully static one. So this check and rebuilding step only adds functionality. This means the executor can now be used for a wider variety of source code and will most likely still perform better than the original executor, since only rebuilding when necessary to me seems better than always rebuilding.

@fujitatomoya

can we just recreate entities and executable list via user's request for reconstruction? i believe that it is easier to implement, and besides this user event or request for reconstruction would not be happening every single time just like SingleThreadExecutor does. so i think that it is reasonable.

Instead of rebuilding on request, we handled it like this (event trigger from node).

i think that your idea is better than giving the responsibility to user for reconstruction.

i believe that this reconstruction only needs to be done here once, so find out if anything is notified, and then reconstruct just once and exit from this loop. this is performance concern if some of entities are updated.

Yes this is true, I believe we did realize this, but apparently haven't updated it here. We can add a "break;" after get_executable_list, that should get the desired result right?

A guard condition is for "waking up" the executor, and I think that shouldn't be coupled to re-collecting entities (I'm not sure if you always want to re-collect entities when a guard condition is triggered).
IMO, it's better to provide a way of doing it under user request.

One of the problems that we found is that this condition causes run_collect_entities to be called every time a guard condition is triggered, even if no nodes/pubs/subs/etc are added

Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com> Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl>

* Fail on invalid and unknown ROS specific arguments. Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com> * Revert changes to utilities.hpp in rclcpp Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com> * Fully revert change to utilities.hpp Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com> Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl>

"it's" instead of its Signed-off-by: Luca Della Vedova <luca@openrobotics.org> Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl>

* added throwing parameter name if parameter is not set Signed-off-by: Alex <cvbn127@gmail.com> Signed-off-by: ivanpauno <ivanpauno@ekumenlabs.com> Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl>

…s2#841) Signed-off-by: Tomoya.Fujita <Tomoya.Fujita@sony.com> Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl>

Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl> executor enhanced to run clients and waitable Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl> tested executor Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl> added semi-dynamic feature to the executor Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl> Jenkins error fixes Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl> Added static single threaded executor functionality Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl>

Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl>

fujitatomoya · 2019-10-25T06:47:16Z

rclcpp/src/rclcpp/node_options.cpp

+      try {
+        std::vector<std::string> unparsed_ros_args;
+        for (int i = 0; i < unparsed_ros_args_count; ++i) {
+          unparsed_ros_args.push_back(c_argv[unparsed_ros_args_indices[i]]);
+        }
+        throw exceptions::UnknownROSArgsError(std::move(unparsed_ros_args));
+      } catch (...) {
+        this->allocator_.deallocate(unparsed_ros_args_indices, this->allocator_.state);
+        throw;
+      }


i am not sure this try & catch is required here, can we just do the following?

Suggested change

try {

std::vector<std::string> unparsed_ros_args;

for (int i = 0; i < unparsed_ros_args_count; ++i) {

unparsed_ros_args.push_back(c_argv[unparsed_ros_args_indices[i]]);

}

throw exceptions::UnknownROSArgsError(std::move(unparsed_ros_args));

} catch (...) {

this->allocator_.deallocate(unparsed_ros_args_indices, this->allocator_.state);

throw;

}

} else {

std::vector<std::string> unparsed_ros_args;

for (int i = 0; i < unparsed_ros_args_count; ++i) {

unparsed_ros_args.push_back(c_argv[unparsed_ros_args_indices[i]]);

}

this->allocator_.deallocate(unparsed_ros_args_indices, this->allocator_.state);

throw exceptions::UnknownROSArgsError(std::move(unparsed_ros_args));

}

fujitatomoya · 2019-10-25T06:53:15Z

rclcpp/include/rclcpp/executors/static_single_threaded_executor.hpp

+ * This executor is a static version of original single threaded executor.
+ * This executor makes the assumption that system does not change during runtime.
+ * This means all nodes, callbackgroups, timers, subscriptions etc. are created
+ * before .spin() is called.


this explanation is not consistent, compared to the current implementation. i believe that run_collect_entities will be called if anything added during runtime.

fujitatomoya · 2019-10-25T10:27:59Z

rclcpp/src/rclcpp/executors/static_single_threaded_executor.cpp

+
+void
+StaticSingleThreadedExecutor::get_executable_list(
+  ExecutableList & executable_list, std::chrono::nanoseconds timeout)


second argument std::chrono::nanoseconds timeout is not really needed. we can call refresh_wait_set() instead.

fujitatomoya · 2019-10-25T11:07:16Z

rclcpp/src/rclcpp/executors/static_single_threaded_executor.cpp

+  for (size_t i = 0; i < wait_set_.size_of_guard_conditions; ++i) {
+    if (wait_set_.guard_conditions[i]) {
+      // rebuild the wait_set and ExecutableList struct
+      run_collect_entities();


i believe that this reconstruction only needs to be done here once, so find out if anything is notified, and then reconstruct just once and exit from this loop. this is performance concern if some of entities are updated.

ivanpauno

Sorry for the delay, I did a more detailed review this time.

My main questions are:

Why is ExecutableList needed? (see my other comment below)
Why updating the wait_set when a guard condition is triggered? I don't think that both things should be coupled.
When should an user use the existing SingleThreadedExecutor instead of this one?
If this one provides a way of recollecting entities, I think that both of them could be used in the same use-cases. In that case, I will simple drop the old one and replace it with this one.
As a first step, we could merge this as a different option, which will also ease backporting without breaking API. But in the long term, I don't think we should keep both.

PS: Rebasing is needed.

ivanpauno · 2019-11-20T16:41:18Z

rclcpp/include/rclcpp/exceptions.hpp

 };

+/// Created when the ret is RCL_RET_INVALID_ROS_ARGS.
+class RCLInvalidROSArgsError : public RCLErrorBase, public std::runtime_error


The PR seems to not be correctly rebased with master.

ivanpauno · 2019-11-20T16:51:25Z

rclcpp/include/rclcpp/executors.hpp


 #include "rclcpp/executors/multi_threaded_executor.hpp"
 #include "rclcpp/executors/single_threaded_executor.hpp"
+#include "rclcpp/executors/static_single_threaded_executor.hpp"


The MultiThreadedExecutor is also not used, and there is an using statement for it in line 54.
I'm not sure, but probably the original idea was to re-declare all executors in rclcpp::executors namespace.

You can ignore this comment for the moment, as it's a really not important and I'm not sure what was the idea of the original author.

ivanpauno · 2019-11-20T17:23:54Z

rclcpp/include/rclcpp/executors/static_single_threaded_executor.hpp

+ * exec.spin();
+ * exec.remove_node(node);
+ */
+class StaticSingleThreadedExecutor : public executor::Executor


This is inheriting from executor::Executor, but it's not using some of the "protected" method it provides.
IMO, the code has to be reorganized a little bit (I don't have any suggestion yet, I will think a little bit more about it).

ivanpauno · 2019-11-20T17:48:35Z

rclcpp/src/rclcpp/executors/static_single_threaded_executor.cpp

+  prepare_wait_set();
+
+  // add handles to the wait_set and wait for work
+  refresh_wait_set(timeout);


refresh_wait_set is always called in execute_ready_executables, why it has to be called here too?

ivanpauno · 2019-11-20T18:48:22Z

rclcpp/src/rclcpp/executors/static_single_threaded_executor.cpp

+
+void
+StaticSingleThreadedExecutor::execute_ready_executables(
+  ExecutableList & exec_list, std::chrono::nanoseconds timeout)


Why do we need both the exec_list and the memory_strategy_?
I think there is some duplication there, as they are mostly collecting the same stuff.

Why not using directly get_next_ready_executable instead of re-implementing this?

My idea is that this should look quite similar to the current SingleThreadedExecutor, but avoiding calling clear_handles and collect_entities each time. I don't understand the need of another collection.

MartinCornelis2 · 2019-11-27T09:34:11Z

Hello Everyone,

Ishu and I are very happy to see that so many people have responded to this PR.
What we see right now is that there is not really a consensus on how the executor will be refactored for F-turtle. So we plan to wait on implementing more changes until a decision has been made.

The intention of this version was to show the inefficiencies of the original executor. With a few changes to the code, we managed to gain quite some performance. However, the executor is now sitting on top of old data-structures and functions that do not perfectly fit the implementation. A proper refactored executor would require a bigger rewrite and re-organization of rclcpp.

This is why we rather wait until we are close to the Foxy release and then rebase and help with the refactored executor.

dirk-thomas · 2019-11-27T18:19:28Z

This is why we rather wait until we are close to the Foxy release and then rebase and help with the refactored executor.

@MartinCornelis2 I would suggest to try to get your proposed changes reviewed and merged rather earlier than later in the release cycle. If you need certain changes or decisions to happen before that please push on those ones as well.

If you wait until close to the Foxy release it becomes likely that a significant PR like this won't be accepted in time and misses the freeze deadline and therefore can only be considered for the next ROS distro.

wjwwood · 2019-12-02T21:23:01Z

@dirk-thomas please read up on the discussion: https://discourse.ros.org/t/singlethreadedexecutor-creates-a-high-cpu-overhead-in-ros-2/10077/21

One option is to get this reviewed and merged first, but it's not clear to me that is the best way.

If @MartinCornelis2 wants to do it that way, then I'm happy to try and get it merged though. Also if, after discussing the roadmap for Foxy, we will not have time for the executor improvements (very bad idea, imo) then that might be another reason to resurrect this pr early, since the aforementioned improvements won't come anyways.

alsora · 2020-02-18T14:29:09Z

Any updates on this?
Is it going to be in the Foxy release?

wjwwood · 2020-02-20T00:38:01Z

Any updates on this?
Is it going to be in the Foxy release?

I don't have any updates right now, but that is still the plan.

…_executor

…hreaded_executor.cpp w.r.t. intra-process change since last commit Signed-off-by: MartinCornelis2 <martin.cornelis@nobleo.nl>

MartinCornelis2 · 2020-03-03T15:56:43Z

Hi Everyone,

I merged master with this PR (resolved conflicts) and made some small changes to get the executor to compile again. I haven't had time to thoroughly test the executor functionality, but some quick ros2 topic inspections appear to indicate it is in working condition again.

I am OK with reviewing further additions to this PR, but like stated before don't have time to commit fully to further development on this.

@alsora had some suggestions to improve the rebuilding of the wait-set and executable list further. Right now we consider too many guard-conditions instead of just the "add stuff to a node"-related ones so there is still some unnecessary rebuilding going on.

Changes and small fixes like the one alsora mentioned can still quite easily be added to the executor before the Foxy release (alsora offered to contribute, I offered to review). Additionally, the static executor in this PR is implemented in such a way that it is optional next to the original executor, so (aside from a slightly bigger install) there is no harm in including it. From @iluetkeb and @wjwwood s input it looks like tackling "proper" scheduling is (currently) out of scope.

In short:
In my opinion there is some value in polishing this PR a little bit and including it in Foxy.
A better executor that covers more issues should still be developed for future releases, or alternatively the pool of executors to choose from should be expanded to cover the more common use-cases. In future releases the "old" executor should probably be dropped in favor of executors that perform better or fulfill a specific task better.

Let me know what you guys think. If I am needed for anything please @ me or send me an e-mail.

Kind regards!

wait_set_.size_of_* is always different than '0' if we are inside the for loop Signed-off-by: Mauro <mpasserino@irobot.com>

iluetkeb · 2020-03-04T08:30:12Z

@MartinCornelis2 I support including your executor.

Regarding "proper" scheduling: IMHO this is an absolute MUST for Foxy. The current situation is very problematic in that it mostly works but breaks down in important edge cases. Everybody I talked to that uses ROS 2 for serious applications is using workarounds.

MartinCornelis2 · 2020-03-04T08:50:49Z

Of course scheduling is very important, but do you think it is realistic given the timescale to still get something in before Foxy? Is it possible to implement one of these workarounds you mention before April?

Additionally, the improved scheduling will cost "some" performance. I think the discussion on performance vs determinism (is determinism the correct term here?) is difficult and (for me) still full of question marks.

Of course if we only lose a small amount of performance and suddenly have (fully) predictable scheduling then by all means shoot in a PR!

@iluetkeb I think your experience can maybe give some clarity on this subject? Do you know of any fixes that are, like this executor, a good short-term improvement that can be implemented somewhat quickly? Or will this just lead to a half-solution that benefits nobody and will still require a huge rewrite?

iluetkeb · 2020-03-04T09:10:51Z

Of course scheduling is very important, but do you think it is realistic given the timescale to still get something in before Foxy?

Certainly. It's not that hard. So far, I had assumed OpenRobotics is already working on it, and since this goes across many layers, they are in the best position to do so.

I personally have some IP-related restrictions that would make it harder for me to do this, but having learned of the situation, I will certainly discuss internally how we could proceed here.

Now we check ONLY node guard_conditions_ Some possible guard conditions to be triggered HERE are: 1. Ctrl+C guard condition 2. Executor interrupt_guard_condition_ 3. Node guard_conditions_ 4. Waitables guard conditions 5. ..more The previous approach was only checking if NOT (1 & 2), so if a Waitable was triggered, it would re-collect all entities, even if no new node entity was added. This was the case of the intra process manager, who relies on waitables. Every time a subscriber got a message, all the entities were collected. Signed-off-by: Mauro <mpasserino@irobot.com>

mauropasse · 2020-03-10T17:53:55Z

Just opened a PR with some StaticSingleThreadedExecutor improvements: nobleo#5
Below are the benchmark performances [1] we got so far (measured in RPi 1 - Model A+ v1.1, single core @700Mhz)

Executor	CPU [%]	RAM [Mb]	Late [%]	Too late [%]	Lost [%]
SingleThreadedExecutor	72	14.12	0.64	0	0.03
StaticSingleThreadedExecutor	53.71	13.34	21.04	9.96	27.15
StaticSingleThreadedExecutor (improved in the PR)	40.32	13.88	0.05	0	0

The gain in CPU performance is about ~13% compared to the StaticSingleThreadedExecutor, and 32% compared to the SingleThreadedExecutor.
[1] https://github.com/irobot-ros/ros2-performance/tree/master/performances/benchmark

Collect entities when a new node entity is added/removed

alsora · 2020-03-11T17:55:00Z

I recently started looking into spurious awakes with the ROS 2 executor.
Apparently, both the standard and the static executors are affected, but for different reasons.
See #1021 and nobleo/static_executor#2

I want to move the discussion here to get some feedback from more people on the static executor issue.

Results from recent experiments:

kernel tracing tools show a lot of context switching
I ran the static executor with 1 node with 1 timer and nothing else. I commented out some lines in the executor to not invoke any callback (like here and the other "execute"). This means that this system is only waking up and not doing anything else.
Since there are no messages published/received the spurious awakes do not happen.
Using a frequency of 100Hz I get a CPU usage of ~5%. Doubling the frequency I get ~8.7%.
This roughly should be the overhead of the double awakes in a very small system.
Note that it will be much bigger in a real system.

I think that this is a relevant issue that must be addressed.
P.S. For comparison, I tried to disable IPC and use the "built-in IPC" of cycloneDDS, but the results were worst, even if double awakes were not present

Signed-off-by: Mauro <mpasserino@irobot.com>

alsora · 2020-03-24T15:26:34Z

@ivanpauno @wjwwood
FYI @mauropasse recently opened a PR for the static executor to improve the mechanism for refreshing the executable list
nobleo#6

ros-discourse · 2020-03-24T15:32:45Z

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/singlethreadedexecutor-creates-a-high-cpu-overhead-in-ros-2/10077/23

rclcpp/include/rclcpp/executable_list.hpp

MartinCornelis2 · 2020-03-25T12:01:38Z

@wjwwood, Hi William I just saw your post on Discourse and your additions here. Besides the copyright lines, what is expected from our side?
I myself am not very familiar with the process of getting PRs merged into the core-stack and I'm not entirely certain what to do.

My two main questions are:

Are we supposed to do something with [rclcpp] adding a "static" single threaded executor #1034 ?
Is it still ok if I merge this PR (when I'm done reviewing it) from @alsora @mauropasse Implement static executor entities collector nobleo/rclcpp#6 , or do you prefer no more changes at this point?

I don't want to accidentally make changes that impede your work. Or have you wait on an action or response from us (which we might not be aware we are supposed to be taking/giving).

Clear and concise instructions (even if blunt) are much appreciated :)

wjwwood · 2020-03-25T18:11:52Z

what is expected from our side?
I myself am not very familiar with the process of getting PRs merged into the core-stack and I'm not entirely certain what to do.

Nothing at this point. If I have questions, being available to answer them quickly will help me get it in quicker (and be much appreciated). Sometimes we ask or expect contributors to address test failures and such, but given the accelerated timeline for getting changes in, I'll be editing the pr directly if I can.

Are we supposed to do something with #1034 ?

You don't have to do anything. You could, however, fix this pull request using that pull request's branch as a source. This pull request currently contains commits from master which typically indicates some sort of issue from past rebases done incorrectly, but I'm not sure in this specific case. I could have fixed this one directly, but since you had issues and pull requests on your fork I didn't want to disrupt those without asking.

Is it still ok if I merge this PR (when I'm done reviewing it) from @alsora @mauropasse nobleo#6 , or do you prefer no more changes at this point?

I'll have to have a look at it, but in general I'm fine to consider additional changes now or later (as a follow up pull request to rclcpp).

I don't want to accidentally make changes that impede your work.

I made the other pull request out of a similar concern, I wouldn't worry about it, I can work around anything you do.

Or have you wait on an action or response from us

No, I've just decided I want to get this in and then change it based on my changes to the executor I have prepared rather than the other way around.

…ntities_collector Implement static executor entities collector

rclcpp/include/rclcpp/executable_list.hpp

rclcpp/src/rclcpp/executable_list.cpp

Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl>

wjwwood · 2020-03-28T07:40:04Z

Closing since I merged #1034 as an alternative.

Thanks everyone for their contributions and patience with us. Please feel free to open new issues to continue discussions that have been taking place here.

Also, I've been working on other structural changes to the executor design in rclcpp, so these new classes may be update soon and/or subsumed into other classes.

* Use Reader seek() method for seeking/jumping in Player Signed-off-by: Sonia Jin <diegothemuich@gmail.com> * make sure playback stays paused (does not finish even when no messages left) while in pause state Signed-off-by: Sonia Jin <diegothemuich@gmail.com>

ros-discourse · 2025-06-13T05:15:38Z

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-2-real-time-working-group-online-meeting-6-nov-27-2019-7am-pdt-utc-8/11673/1

fujitatomoya reviewed Sep 30, 2019

View reviewed changes

allenh1 reviewed Sep 30, 2019

View reviewed changes

rclcpp/include/rclcpp/executor.hpp Show resolved Hide resolved

wjwwood self-requested a review October 2, 2019 17:45

ivanpauno reviewed Oct 14, 2019

View reviewed changes

Karsten1987 mentioned this pull request Oct 17, 2019

ROS 2 Eloquent Elusor ros2/ros2#734

Closed

34 tasks

mabelzhang added the enhancement New feature or request label Oct 17, 2019

hidmic and others added 6 commits October 18, 2019 11:44

Use of -r/--remap flags where appropriate. (ros2#834)

46985e9

Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com> Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl>

Force explicit --ros-args in NodeOptions::arguments(). (ros2#845)

4961f13

Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com> Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl>

Fix typo in deprecated warning. (ros2#848)

0f84abc

"it's" instead of its Signed-off-by: Luca Della Vedova <luca@openrobotics.org> Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl>

Add throwing parameter name if parameter is not set (ros2#833)

a239266

* added throwing parameter name if parameter is not set Signed-off-by: Alex <cvbn127@gmail.com> Signed-off-by: ivanpauno <ivanpauno@ekumenlabs.com> Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl>

check valid timer handler 1st to reduce the time window for scan. (ro…

43b10b0

…s2#841) Signed-off-by: Tomoya.Fujita <Tomoya.Fujita@sony.com> Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl>

ishugoel20 force-pushed the nobleo/feature/static_executor branch from 6705790 to 28a7cbe Compare October 18, 2019 09:51

ishugoel-nobleo added 2 commits October 18, 2019 12:05

Added semi-dynamic feature and made changes based on review comments

fee1a91

Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl>

ishugoel20 force-pushed the nobleo/feature/static_executor branch 2 times, most recently from 043a412 to fee1a91 Compare October 18, 2019 14:44

fujitatomoya reviewed Oct 25, 2019

View reviewed changes

ivanpauno reviewed Nov 20, 2019

View reviewed changes

ivanpauno added the backlog label Feb 6, 2020

MartinCornelis2 added 2 commits March 3, 2020 11:47

Merge remote-tracking branch 'ros2/master' into nobleo/feature/static…

687e8dd

…_executor

re-added accidentally deleted code in node.hpp, fixed static_single_t…

2b6a0a2

…hreaded_executor.cpp w.r.t. intra-process change since last commit Signed-off-by: MartinCornelis2 <martin.cornelis@nobleo.nl>

MartinCornelis2 force-pushed the nobleo/feature/static_executor branch from 095af9d to 2b6a0a2 Compare March 3, 2020 15:25

Remove not needed comparison

02f8aa6

wait_set_.size_of_* is always different than '0' if we are inside the for loop Signed-off-by: Mauro <mpasserino@irobot.com>

Merge pull request #5 from mauropasse/mauro/feature/static_executor

d1cee55

Collect entities when a new node entity is added/removed

Implement static executor entities collector

b618209

Signed-off-by: Mauro <mpasserino@irobot.com>

wjwwood removed the backlog label Mar 25, 2020

wjwwood mentioned this pull request Mar 25, 2020

[rclcpp] adding a "static" single threaded executor #1034

Merged

wjwwood reviewed Mar 25, 2020

View reviewed changes

rclcpp/include/rclcpp/executable_list.hpp Show resolved Hide resolved

Merge pull request #6 from mauropasse/mauro/feature/static_executor_e…

f1335eb

…ntities_collector Implement static executor entities collector

jacobperron assigned wjwwood Mar 26, 2020

wjwwood reviewed Mar 27, 2020

View reviewed changes

rclcpp/include/rclcpp/executable_list.hpp Show resolved Hide resolved

wjwwood reviewed Mar 27, 2020

View reviewed changes

rclcpp/src/rclcpp/executable_list.cpp Show resolved Hide resolved

adding copyright to static executor files

f34d3c8

Signed-off-by: Ishu Goel <ishu.goel@nobleo.nl>

wjwwood closed this Mar 28, 2020

zflat mentioned this pull request Dec 13, 2022

Consider different executor v-kiniv/rws#1

Open

Conversation

ishugoel20 commented Sep 25, 2019

Uh oh!

ishugoel20 commented Sep 25, 2019

Uh oh!

tfoote commented Sep 25, 2019

Uh oh!

MartinCornelis2 commented Sep 26, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fujitatomoya commented Sep 30, 2019

Uh oh!

fujitatomoya Sep 30, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ishugoel20 commented Sep 30, 2019

Uh oh!

Uh oh!

ivanpauno left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ivanpauno left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MartinCornelis2 commented Nov 27, 2019

Uh oh!

dirk-thomas commented Nov 27, 2019

Uh oh!

wjwwood commented Dec 2, 2019

Uh oh!

alsora commented Feb 18, 2020

MartinCornelis2 commented Sep 26, 2019 •

edited

Loading

fujitatomoya Sep 30, 2019 •

edited

Loading

wjwwood commented Mar 25, 2020 •

edited

Loading