ROS 2 TSC Meeting Minutes: 2020-04-16

General
1

ROS 2 TSC Meeting Agenda - 2020-04

  • Attendees

    • LG Electronics: Lokesh Kumar Goel
    • Open Robotics: Brian Gerkey, Louise Poubel, DIrk Thomas, Tully Foote
    • eProsima: Jaime Martin Losa
    • Bosch: Karsten Knese
    • ROBOTIS: Will Son
    • Samsung: Steve Macenski
    • Canonical: Kyle Fazzari, Sid Faber
    • Tier IV: Geoffrey Biggs
    • Microsoft: Sean Yen
    • ADLINK: Joe Speed
    • Amazon: Aaron Blasdel, Thomas Moulard
    • Toyota Research Institute: Toffee Albina
    • Apex.AI: Dejan Pangercic
    • SwRI, representing GVSC: Jerry Towler

  • Preliminaries

  • Old business

    • [Gerkey] Update on REP 2005: ROS 2 Common Packages (nĂ©e ROS 2 Standard Library, nĂ©e ROS 2 Essentials)
      • TSC subgroup met to discuss conceptual changes, which are under review in a PR.
    • [Gerkey] ROSCon 2020: (still) proceeding as planned and monitoring the situation.
    • Follow-ups on CI improvements:
      • [Pangercic] Sharing guidance on Apex’s CI triage process
      • [Blasdel] Investigating Jenkins plugins for use in broken (intermittently failing) test identification
      • Discussion of how to respond to broken/flaky tests:
        • Potentially consider disabling broken tests that fail intermittently to increase trust, If we do it is important that we track broken tests we have disabled and prioritize fixing them. [Blasdel]
        • Can quarantine tests for a period using a macro. This works well with a testing lead who reviews disabled tests and actively triages it to zero. [Pangercic]
        • Use a label/marker to annotate such tests, don’t run tests with that label by default [DThomas]
        • There needs to be a clear path (with a timeline) when such a test needs to be reenabled [DThomas]
        • There are tests that pass locally but fail intermittently on the buildfarm [Speed]
          • These are issues with the test as they’re platform dependent.
        • Pangercic to convene group to discuss (see above).
      • [Foote] Creating GitHub team for TSC
        • Done: osrf/ros2-tsc
    • [Fazzari] Status update on WG template
      • Granted access to osrf/ros2-tsc
      • Turned into an actual template repository
      • Hoping to get a few more votes

  • New business

    • [Biggs] Community representatives on the TSC
      • Common in many communities to have one or two elected representatives on the council-of-nine/committee-of-the-elite/overwatch-squad/whatever that manages the project. Also having representation of the academic communities.
      • Having a couple on the TSC would increase transparency, ease fears amongst some in the community about corporate takeovers,losing their voice to the companies, etc., and ensure that the community as a whole always has a voice
      • Things to decide:
        • Do we want community representatives?
        • How many? 1? 2? Proportional to the total number of TSC members?
        • How are they nominated?
        • How are they elected? (One idea: anonymous vote on Discourse, must be signed up to Discourse before the start of nominations to vote - no idea if this is actually possible or not.)
          • They could be invited.
          • Could we have rotating guests?
            • Benefits of diversity, challenges of bringing up to speed.
        • What are their responsibilities? (e.g. nav, moveit, autoware, ros control, etc)
        • Should we have them appointed based on project / ecosystem
      • Consensus is that it’s worthwhile considering; Biggs will draft a proposal for discussion.
    • [Macenski] Out-of-the-box Wifi Behavior
      • Topic on Discourse (ROS2 Default Behavior (Wifi))
      • We’re having mobile robot users having issues with ROS2 on wifi out of the box. Current work arounds require going into the DDS configs to work in a relatively typical office environment or typical deployed location.
      • Goal: For 2 sigmas of users (before optimization for mass deployment), they shouldn’t have to know about or care about DDS configs, works out of the box for all Tier-1 vendors.
      • [Martin Losa]
      • [Gerkey (echoing Macenski)]
        • It’s an insufficient answer to tell users that their wifi hardware is the problem, especially when they have experience using ROS 1 successfully with the same equipment.
        • If multicast is indeed not reliable in our most common use cases, then we may need to consider moving to a roscore-style discovery mechanism as the default. Such a change would need to be well justified and planned.
      • [Erik Boasson & Joe]
        • Please do not push any more major changes into Foxy. Agreed solution(s) can be provided via rolling update to Foxy. We’ll collaborate to continue improving WiFi user experience. We fully intend to make Eclipse Cyclone DDS more efficiently use bandwidth on WiFi environment.
        • WiFi does multicast but is unreliable. But that’s OK if only used for the first step in DDSI discovery. In any case, the nasty WiFi problems are not in discovery but are in application data.
        • Discovery in DDSI scales badly but is only an issue if you run into the consequences of inefficiency. The change of node to participant mapping dramatically changes that, makes it much less of an issue. But this is not the problem most people are running into anyway.
        • Yes, DDSI discovery scales badly, but most ROS2 robots are not actually suffering from that yet. We have DDSI customer deployments running DDSI discovery with >10k endpoints without any need for brokered discovery. These deployments are at scales larger than what we’ve seen thus far in ROS community.
        • We have experience doing brokered DDSI discovery that provably interoperates and is being rolled out in 10ks of things in Smart City projects. Working on next-gen variant of that which we intend to be open source.
        • As ROS community we should not legislate in this area, forcing suboptimal solution. There are instead fully interoperable ways to do this that play by the rules of the DDSI protocol.

  • [45 mins] Recurring business

    • Next ROS 2 distro release
      • [DThomas] [10 mins] Update on schedule and status
        • Latest date to freeze is still April 22th (could be earlier)
        • Assuming the freeze will be effectively two weeks later than planned the release date will likely shift by the same amount
    • Working groups [<=5 mins each]

      • [Knese] Control

        • More work on design documents. Mainly work on hardware interfaces and controller execution management.
        • Starting on implementation hopefully soon after Foxy release.

      • [Speed] Edge AI

        • WG survey of ROS & ROS2 current use of ML … (A: not much)
        • ros2 cv_bridge updated to OpenCV 4.x and tested. OpenCV 4.x confirmed for ubuntu focal
        • ros2-tensorflow 2 package & dockerfile updated to ros2 eloquent, tensorflow 2.0, ubuntu 18.04. Exposed bugs that images from cam2image node will not be rendered in rviz.
        • ROS2 OpenVINO being updated for Eloquent (Foxy too, right?)
        • NVIDIA joined WG and commits to contribute.

      • [Martin Losa] Embedded

      • [Macenski] Navigation

        • Nothing of note to share.

      • [Pangercic] Real-time

        1. Meeting minutes: https://docs.google.com/document/d/1zBKwDUDeWvJNyCvjzYriaZQoZO2VYGWe1uxw5Xxn5cY/edit#heading=h.68a67ubxxdel
        2. Performance Testing Platform will not happen as per the initial plan
          • We need a backup plan
          • Dedicated hardware with ROS 2 flashed onto it and tests run to collect performance metrics and detects performance regressions.
        3. WaitSet was implemented: https://github.com/ros2/rclcpp/pull/1047 (it will improve the performance in the rclcpp layer)
        4. iRobot has ran performance test for the static executor https://github.com/ros2/rclcpp/pull/1047#issuecomment-608032502
          • [Pangercic] We really need the Middleware WG to start up, as a way to handle architectural discussions that arise in the RTWG (and others).
          • [DThomas] We will start this group up as soon as we have enough spare cycles as our work for Foxy gets done.
          • [Gerkey] We’ll revisit this topic in future TSC meetings until it’s done

      • [Fazzari] Security

        • Mostly finished move away from nodes in security features. Didn’t move to contexts though, but processes, which means a new term: enclaves, which represent a set of security files for all the contexts/nodes in a given process. Last bit of work in flight being tracked here.
        • Initial DDS security logging plugin in Fast RTPS has landed, RMW part proposed but not yet landed.
        • Curating public API of SROS2 utilities for Foxy
        • Security features have been merged into Eclipse Cyclone DDS middleware. All Tier 1 rmws now have security support available.

      • [Blasdel] Tooling

        • Rosbag2 : adaptive and override QoS feature nearing completion
        • Rosbag2 : transaction-based inserts should improve recording performance considerably
        • Github Action CI : moving to Docker-based build which should be much faster on average
        • Topic statistics : going into rclcpp now
        • New release of cross-compile tool to pypi
4 Likes
2

+1 to community representation on the TSC.

I would suggest an odd number of representatives proportional to the total number of TSC members so there can be a clear signal on the community’s opinion if things come down to a vote.

7 Likes