ROS2 Real-time Working Group Online Meeting 3 - Oct 2, 2019, 7AM PDT (UTC-7)

Hi real-time folks, time for our 3rd meeting.

Proposed agenda:

  1. Single process, real-time rmw => ADLink
  2. Repository of tools for static and dynamic code analysis => @Ingo_Lutkebohle
  3. Performance testing on target hardware => Apex.AI
  4. I would propose to hold meetings regularly, every 2 weeks

Last meeting agenda and minutes.

Respond to this conversation by answering to:

  1. Are you available?
  2. Do you have additional items for the agenda?
  3. Can you expand on your agenda items?

@joespeed @eboasson @Ingo_Lutkebohle @razr fyi

1 Like

Hi Dejan,

We (@ishugoel and I) will be attending this meeting.

  1. Yes we are available
  2. We created a POC StaticExecutor for rclcpp that can be added without breaking existing source code. If someone wants to use the StaticExecutor instead of the SingleThreaded executor, this only requires a change to one line of code at user-code level.
  3. The code and preliminary results can be found here This StaticExecutor significantly reduces CPU usage. We can quickly explain how we changed the existing executor. We have aligned with Ingo and his team to collaborate on a better executor for ROS2. Our focus is on optimization whereas Ingo and his team are working on proper scheduling, both of which are important for RT.

The version we will discuss is a POC on the latest stable dashing release. We are currently also working on a PR (master) version.


thanks for taking care of this thread, i would like to join at this time.


1 Like


Thanks for the invitation. I’m available.
These would be my topics:

  • go via AIs from the last meeting
  • discuss probably the goals of the RT WG (Personally I’m not sure I understand them, and during the last meeting I got a feeling that those goals are quite different for the RT WG participants)

Kind Regards,

Hi all, below are the meeting invite details.

Topic: ROS2 Real-time Working Group Online Meeting 3 - Oct 2, 2019, 7AM PDT (UTC-7)
Time: Oct 2, 2019 07:00 AM Pacific Time (US and Canada)

Join Zoom Meeting

Meeting ID: 571 727 736
Password: 074189

One tap mobile
+16699006833,571727736# US (San Jose)
+19294362866,571727736# US (New York)

Dial by your location
+1 669 900 6833 US (San Jose)
+1 929 436 2866 US (New York)
Meeting ID: 571 727 736
Find your local number:

@MartinCornelis thanks a lot.

Can you and @Ingo_Lutkebohle then present this in details tomorrow?

@Ingo_Lutkebohle Will you be able to attend the meeting tomorrow (4PM German time)?

If yes - do you have any update on this topic:

Ralph Lange and Jan Staschulat will be there.

Hi Dejan,

I’ve made a small presentation that shows the differences between the current executor and our proposal. I think it is easy to follow even for people who don’t have a deep understanding of how the current executor works. I will need about 10-15 min. to explain the executors and their differences, but I will need presenter view for this (screen-sharing). Is this possible? I have no experience with Zoom Meetings.

The presentation will be quite short, but if people are interested we can have a discussion after the presentation about the possible next steps and features people require. The executor we made shows possible CPU gains and gives an alternative for specific use-cases, but a proper all-round executor will need additional features.
Features that are currently on the TODO list:

  1. Different scheduling mechanism (Bosch, create RT safe scheduling, add priority)
  2. Semi-dynamic setup (Nobleo, rebuild the system based on event triggers, i.e. something added to a node)

If there is no time during the meeting to discuss these things then people can just post their thoughts on the PR

Kind Regards,


1 Like

@MartinCornelis yes, this is absolutely possible and easy.

@razr we started with the long list of goals couple of months back: ROS 2 and Real-time.

In that thread I proposed an overall goal which would be to make ROS 2 hard real time. This would then mean that we’d need to “analyse an entire stack, from the hardware platform to the applications written with ROS 2” and improve the realtime across the entire stack.

However the guys have, rightfully so, convinced me that this is simply too much work and it depends too much on the use case and selected underlying stack (ECU, RTOS, network interfaces, …).

As a result we agreed to work on the following sub-goals:

  1. Provide a use case description and requirements
  2. Implement real-time able rmw (single threaded, static executor)
  3. Present findings on real-time audit in rcutils, rcl and rclcpp and continue improving
  4. Create a shared repository for tools for static and dynamic code analysis and tracing

Additional goals are of course welcome but we will also need someone to work on them.

All (12 participants), thanks for attending.


  1. Joe Speed, Erik
  2. Ralph, Jan
  3. Dejan
  4. Andrei
  5. Carlos
  6. Martin

Meeting recordings:

Old link:

New link:

Action items:

  1. Check out zhe rmw implementation - all

  2. Looking for 1-2 candidates to join Erik and his team in creating rmw on top of - @Dejan_Pangercic

  3. Create a system for documentation sharing (GDrive, Github project, …) - @razr is this something that you could maybe do?

  4. Get the presentation from Martin - @MartinCornelis could you paste it here?

  5. Present the mini buildfarm with resource guarantees at Apex.AI - @Dejan_Pangercic

  6. Carlos has been working on the demo that shows some of the real-time characteristics. - @carlossv can you share the demo with us?

  7. Dejan to take content and conclusions of this meeting to OSRF and TSC- @Dejan_Pangercic

    1. @wjwwood - would you be able to join the meetings for this group?
  8. PRs for the static executor - all have a look and comment

  9. ROS 2 Real-time WG to meet every 2 weeks (Wednesdays 7AM PST)


Yes, I’m happy to join any meeting you think I could help with, please ping me directly for each meeting you’d like me to attend. If you need me on a regular basis I can do that too, though selfishly I’m trying to stay out of the way as much as possible.

Is it at all possible to shift this? It clashes perfectly with AWF board meetings.

Hey everyone,

Discourse won’t let me upload the presentation as a powerpoint and the presentation in pdf format is not really usable (the transition of images on a single slide is how I show the working of the executors). Instead I will share some links here, while I look for a way to share the powerpoint.

rclcpp Dashing this link contains a README where the executors are explained with flowcharts. The flowcharts + explanations get the ideas across of each executor.

rclcpp Master fork This is the fork we use for the pull request that is up to date with master (slightly behind by now probably).

rclcpp Master fork with intra_process we also made a version that we merged with @alsora PR for improved intra_process communication.

For the people that are not aware of why we worked on this static executor here is a very short history. There is more links in the links pointing to more links if you feel like going on an adventure.
Original ROS answers post
ROS discourse discussion on STE
ROS discourse discussion on participant mapping (related, but less interesting)

Hopefully this gets everyone what they are looking for. If you want more information or help with the code or understanding the STE or static executor, don’t hesitate to send me a message.


Your flow chart for your static executor is missing some labels on the decision branches.

I do not have a lot of experience making flowcharts, nor do I know the exact rules to making them. I hope that despite the inaccuracies they are still readable. Sorry for the possible inconvenience.

Any diamond is a decision. Each arrow going out of the diamond needs a label to say what the condition is for that branch being taken.

I added the powerpoint that I used during the meeting for my presentation to rclcpp Dashing in the presentation folder. Please let me know if it works by downloading it and looking at it in presentation view (to cycle through the images).

Sidenote: The dashing version now uses the nodes’ guard_conditions as event trigger to rebuild the executable list and the wait-set. Making the use of the static executor less restrictive (semi-dynamic, rebuild only when necessary). We will continue work on a master (eloquent) version and look into a multi-threaded version.