ROS 2 Real-time Working Group Online Meeting 7 - Dec 11, 2019, 7AM PDT (UTC-8)

Next Generation ROS
1

RTWG folks, here is an agenda for our next meeting. Please add your topics if you have them.

  1. Presentation: SLX ROS Performance Testing Platform by Silexica
  2. Discourse post on how to measure performance correctly
    1. Jaime’s talk transcribed
  3. LET executor ROS 2 Real-time Working Group Online Meeting 6 - Nov 27, 2019, 7AM PDT (UTC-8) => @wjwwood @ralph-lange @JanStaschulat
  4. Architecture of single-process, real-time rmw => @eboasson
    1. @erik would now be a good time?
  5. static_executor recap:
    1. William suggests to change executor design in ROS 2 F: SingleThreadedExecutor creates a high CPU overhead in ROS 2
    2. Martin agrees and offers the current version as an independent library
    3. After the changes in ROS 2 F, we will port some parts from https://github.com/nobleo/static_executor to rclcpp?
  6. Direct DDS Access
    @BorjaOuterelo
    @gavanderhoorn
    @Tommy_Persson
    @tomoyafujita

Zoom coordinates: TBD.

2

More information from the meeting recording:

  • eProsima published latency tests results, looking at the median value of multiple runs
  • using a clone of the system and same configuration as the one used by their competition
  • with open source code for reproducibility

I’ll let @Jaime_Martin_Losa add more details on Wednesday!

3

Hi Dejan,

Both Ishu and I are busy/not in the office tomorrow, so we won’t be able to attend this meeting.

To address points 5.1-5.3:
Our reasoning is as follows: We are very excited that our static_executor has gotten as much attention as it did (this was very unexpected for us) and we hope some of our work will end up in the core of ROS2 (this would be amazing!), but we’ve always seen the static-executor more as a POC w.r.t. “just” CPU utilization. The executor in ROS2 has some more flaws (i.e. scheduling as highlighted in the paper by Tobias) and our static-executor POC is build on top of legacy that blocks/prevents neat minimal code and further other improvements.

It is difficult to rework rclcpp, rcl and rmw with everything sitting on top of it and equally difficult from the other perspective to keep up with API changes. We want to see what design OSRF/William/the community can come up with and what changes to ROS2 will (need to) happen to realize that design.

With the limited manpower we have, we decided the nicest thing we could do was to wrap the static-executor into a separate library for both dashing and eloquent users to use. When we get closer to the F release and the design has been settled on, then we are definitely willing to contribute and help port the static-executor if desired. However, keeping up our PR with master in (what is expected to be) a quite tumultuous time w.r.t. rclcpp, rcl and rmw, is not really possible (especially since both Ishu and I are on different projects atm that take up a lot of our time).

My apologies for the long explanation, but hopefully this shines a light on our point of view. We hope for your understanding and look forward to the design discussions and of course the final design for F turtle :fox_face::turtle::robot:

2 Likes
4

is that available now?

5

At all, sorry for being late but here are the meeting coordinates:

Topic: RTWG Meeting 7
Time: Dec 11, 2019 07:00 AM Pacific Time (US and Canada)

Join Zoom Meeting

Meeting ID: 910 363 819
Password: 935893

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

Dial by your location
+1 669 900 6833 US (San Jose)
+1 929 436 2866 US (New York)
Meeting ID: 910 363 819
Find your local number: https://zoom.us/u/acGuzJFesI

6

@joespeed
@eboasson

about Direct DDS Access only to connect specific device/robot, yesterday you mentioned some new feature is submitted by @eboasson to DDSI-RTPS, right? is it already ready on DDS-RTPS 2.3?

could you enlighten me a little bit more? I’d like to catch up this.

Best

7

Hi Tomoya, Yes, Erik @eboasson added domainTag to DDS-RTPS 2.3 and implemented iRobot’s use case in Eclipse Cyclone DDS:

Find Roomba by serial # among ~1,000 robots on the network

With domainTag things talk if domain and the tag (e.g. robot serial #) are matched.

//CycloneDDS/Domain/Discovery/Tag
Text
String extension for domain id that remote participants must match to be discovered.
The default value is: "”

Happy to chat about that and other Eclipse IoT contributions to the ROS community.

“Eclipse Cyclone DDS makes ROS 2 Easier, Smaller, Faster” talk today at ROS-Industrial Stuttgart RICEU2019 is a good overview of the Eclipse IoT Eclipse Cyclone DDS project and interesting use cases from the community http://bit.ly/eclipsecyclone

1 Like
8

@joespeed
@eboasson

thanks, will look into it.

9

Meeting minutes (thx @christophebedard for help):

Video recordings: https://drive.google.com/file/d/1WUcAIcEyRRS76j5z30e1pY3NaI_LhfQi/view

Next meeting: Jan 8 2020 (skipping the one on Dec 25 2019).

  1. Presentation: SLX ROS Performance Testing Platform 2019-11-28-ros2-rt-wg-proposal.pptx.pdf by Silexica/Ben
    1. AI Dejan: Ask Amazon if they want to host HW for performance testing platform (on https://aws.amazon.com/about-aws/whats-new/2019/02/introducing-five-new-amazon-ec2-bare-metal-instances/)
    2. Ben to give regular updates in the RTWG
  2. LET executor
    1. AI @JanStaschulat: comments on the rcl PR (https://github.com/ros2/rcl/pull/534) will be addressed and then the PR will be re-directed to rclc (https://github.com/ros2/rclc)
    2. Bosch will also provide the documentation and the use case description for LET executor
    3. William is OK with the full restructure of the rclc project
  3. Architecture of single-process, real-time rmw
    1. Erik’s comment on memory allocation for the data path in rmw_cyclconedds: https://github.com/ros2/rmw_cyclonedds/issues/79
    2. AI: Members of the RTWG should provide feedback
    3. Doing it from scratch vs. building on rmw_cyclonedds => 2nd option is preferred
    4. Erik thinks it makes sense to implement the zero-copy interface (from Bosch) first
    5. ROS 2 F => Erik thinks that we should start making use of DDS keys
      1. AI Dejan: take this request to ROS 2 TSC
  4. static_executor work to be done for ROS 2 F:
    1. be able to use more than one executor per node.
    2. Implement Waitset similar to the one at Apex => AI @carlossv: to work with William
    3. Interface clean up around the executor
  5. ROS 2 F Roadmap will be finalized early 2020
    1. Input to the roadmap: brainstorming of ROS 2 team@OSRF & others
    2. AI RTWG members: provide your input for the ROS 2 F roadmap
  6. DDS direct access (A more unified and standard way of configuring the DDS layer)
    1. There exist 2 different solutions/approaches: DDS configuration vs accessing DDS APIs
    2. Borja’s use case in microROS => configuring vendor specific implementation
    3. William => 3 ways to expose more DDS features:
      1. out of bound for configuration of the underlying DDS implementation
      2. programmatically (e.g. rmw_init(payload) which has been done at Apex, but it is not portable across DDS vendors,
      3. ROS way with lots of abstraction and which must be portable
      4. AI @BorjaOuterelo @joxoby: provide more concrete set of requirements for this use case
4 Likes