ROS2 for real-time applications

Next Generation ROS
1

As a newbie, I would like to understand the current status of ROS2 wrt real-time. My goal is to identify the gaps and contribute towards making ROS2 real-time compatible. Aiming to get some direction and clue.

  1. Is there some standard steps documented to setup/run/test/profile real-time apps with ROS2. This is to enable me to setup a right development environment.
  2. In the document - http://design.ros2.org/articles/realtime_background.html, there are few proposals made on how to make ROS2 achieve real-time compatibility. I would like to know if there was any decision taken or progress made wrt the proposals.
2

Check this packages in the ros 2 github repo :

  1. https://github.com/ros2/realtime_support.
  2. https://github.com/ros2/tlsf/tree/master/tlsf

There is also a demo for the realtime support :

  1. https://github.com/ros2/demos/tree/master/pendulum_control
1 Like
3

Thanks @sagniknitr
Also, I wanted to know if there are any changes made in ROS2 stack for real-time (as proposed here - http://design.ros2.org/articles/realtime_background.html ). Do we have multiple versions of ROS2 (real-time vs non real-time) or are there any special configuration to enable real-time code.

4

@lbegani real-time is a larger topic and as Jackie in above article points includes memory management (no allocations on the runtime), device IO (e.g. no logging to disk) and synchronization (thread priorities, no indefinitely blocking calls, …).

In addition you also need to have an RTOS that supports deterministic scheduling (e.g. QNX) and a real-time DDS implementation (currently only Connext Micro DDS is so and for that we do not have an rmw_* layer yet).

For below assume that I only talk about C++ code, so no python, java and friends.

Said that following has been done to make ROS 2 real-time so far:

  1. all rmw_* implementations have static type support (https://github.com/ros2/rmw_fastrtps/pull/203, https://github.com/ros2/rmw_fastrtps/pull/218)
  2. all data structures in rcutils, rmw, and rcl take in allocators (https://github.com/ros2/rcutils/pull/102, https://github.com/ros2/rcl/pull/261, https://github.com/ros2/rmw_fastrtps/pull/208/files)
  3. @wjwwood you’d have more to add here …, right?

What would still need to happen:

  1. rclcpp needs to be memory audited, e.g. if there are usages of STL containers, we need to use memory allocators for them (e.g. https://github.com/foonathan/memory)
  2. allocators need to be passed correctly between rmw, rcl and rclcpp layers
  3. threads need to have controllable stack sizes and priorities
  4. static exceptions need to be used
  5. logging to memory needs to be implemented (as oppose to the file)
  6. https://en.wikipedia.org/wiki/Run-time_type_information needs to be looked at. This is probably not real-time safe
  7. waitset concept needs to be implemented in addition to callbacks (see https://github.com/ros2/rclcpp/issues/572)
  8. …

Finally developers should also use managed nodes to be able to differentiate between memory pre-allocation and memory re-use on the runtime. Developers should also use an RTOS and a static DDS implementation.

I am probably still missing out on lots of other things but this is from the top of my head and as you see still quite some work to get there.

4 Likes
5

Would it be reasonable to write a static analyzer for checks like this? (As far as I know there is none yet.)

1 Like
6

Thanks @Dejan_Pangercic. I will perhaps have more question once I do the env setup and run real-time apps with ROS2.
I am curious to know how real-time specific code for ROS2 will be maintained . Whether there will a different branch or different configuration or some other approach.

7

@sagniknitr @Dejan_Pangercic @fkromer I have run the pendulum_demo app and below are the results. I would like to understand how do I analyze the results and what should I do to make it better -

Initial major pagefaults: 0
Initial minor pagefaults: 2208529
rttest statistics for pendulum_demo_results:

  • Minor pagefaults: 0
  • Major pagefaults: 0
    Latency (time after deadline was missed):
  • Min: 1833 ns
  • Max: 74480 ns
  • Mean: 32574.4 ns
  • Standard deviation: 1.35819e+07