ROS 2 TSC Meeting Minutes: 2019-07-18

General
1

ROS 2 TSC Meeting Minutes: 2019-07-18

  • Attendees
    • Open Robotics: Tully Foote, Brian Gerkey, Louise Poubel, Dirk Thomas
    • Microsoft: Lou Amadio, Sean Yen
    • ROBOTIS: Yoonseok Pyo
    • Bosch: Karsten Knese
    • Acutronic Robotics: Victor Mayoral Vilches
    • eProsima: Jaime Martin Losa
    • Intel: Kelly Hammond
    • Tier IV: Geoff Biggs
    • LGE: Brian Shin
    • Apex.AI: Dejan Pangercic
    • TRI: Toffee Albina
    • Amazon: Adam Duncan
  • Old business
    • [2 mins] [Gerkey] ROS trademark update
      • Application in process of being filed
      • Draft usage policy under legal review
  • New business
    • [15 mins][Gerkey] TSC member participation level and admissions process
      • We now have 6 pending applicants
      • Review data on TSC member participation to date
      • Suggestions for improvement:
        • Establish formal “waiting period” for new orgs before joining and/or require a minimum history of contributions before considering an application.
        • Clarify that all members are expected to make public commitments on the tracking ticket for the upcoming release.
        • Provide more structure for the commitment comments on the tracking tickets.
        • Clarify that all members are expected to provide at each meeting an update on how their >= 1 FTE of effort is currently being directed. Members who can’t attend would fill in that update in this agenda before the meeting.
      • AD: The data is useful.
      • KK: Ok if people don’t have time for the meetings. Would like to see more review of git activity. Qualitative evaluation of active or not active.
      • AD: Might want to see activity for new members for one release cycle. DT: A full year is a long time.
      • KH: Contributions ahead of time makes sense. Need companies coming in to address list of things that are needed, maybe a higher bar for coming in. To make sure it’s a place for action, not just talking. A year might be too long, but probably not 6 months.
      • BG: Should we formalize that an update expected even if you don’t attend? Brian to make a low overhead process for this.
      • BG: Does anyone object to a public commitment on GitHub tracking ticket?
        • GB: Public commitments are good for tracking funding from management.
        • DP: Tickets aren’t the best planning tool. There might be better tools, but it’s better than nothing.
          • BG: Certainly valid
          • DT: External visibility is helpful too.
        • AD + DP: It’s valid to call out the companies that haven’t made their updates yet. So Brian et al don’t need to nag individual companies.
      • KK: It’s hard to vote for new members with little information.
      • GB: If there’s no track record, it’s hard to make a judgement.
      • AD: Would almost like that there’s no vote, but a criterion based on the track record.
      • BG: Will review applicants for contribution activity and summarize back to TSC
  • Standing updates
    • [2 mins each] Member contribution updates

      • Acutronic Robotics

        • Departure from TSC. Thanks and best wishes.

      • Amazon

        • Plan to update the eloquent tracking ticket with our contributions by end of next week.
        • Working on automated release testing
        • Enabled QoS Liveliness in RMW_FASTRPTS with the release of 1.8.1 into ROS 2 mainline
        • All build warnings passing for ARMHF, entire test suite now passing
        • Still investing in performance tests, not clear how we can get alignment on one performance suite
          • DP: Apex and iRobot talking about how to merge the implementations.

      • Apex.AI

        • We will follow this proposal and are committing to ROS 2 TSC Meeting Minutes: 2019-06-20
          • Documentation testing extension to launch_testing (in which the documentation files written in markdown are instrumented such that they become integration tests)
          • Support for ROS2 QNX (compilation and testing (we actually got python and thus colcon to run on QNX) => we will start with the design document first
          • Static code analysers (we are evaluating LDRA, TrustInSoft)
          • Upstream the velodyne driver from https://gitlab.com/AutowareAuto/AutowareAuto/tree/master/src/drivers to https://github.com/ros-drivers
        • I had to spend lots of time in the past month analysing Adaptive Autosar => will report after consulting with Open Robotics

      • Arm

      • Bosch

        • Maintaining and bug fixes of rosbag2
          • Start, stop and resume bag files
          • Recording QoS settings correctly
        • Migrating diagnostics
          • Finishing up diagnostics_aggregrator
          • Internally requesting open source permission to officially maintain the ros2-devel branches
        • Resuming work on real time executor for rcl and rclcpp
          • Bosch’s PhD student to work on EDF scheduler for rclcpp
          • Micro-ROS scheduler for microcontrollers on top of rcl

      • eProsima

        • Released Fast RTPS 1.9 beta
          • Allocation QoS : Static Memory Allocation
          • Discovery Server
        • WIP: Fast RTPS Performance tests: new infrastructure
          • Already online, but still working in the tests and analyzing the first results.
        • Micro-ROS WIP:Porting to dashing, solving bugs

      • Intel

        • Working on Navigation 2 close to landing with a few more things to work through on CI

      • LG Electronics

        • Continued work on OpenEmbedded support - targeting Tier 2 platform support
        • Have taken maintainership of ros/meta-ros repository - pushed generated recipes for dashing and crystal to meta-ros
        • Created legacy branch for old meta-ros, reviewed outstanding PRs
        • Adding support for ROS1 distros

      • Microsoft

        • Been doing ROS1 infrastructure and dependencies support on Windows, translates to ROS2
        • Took over VSCode extensions with debuggability and launching
        • Working on supporting RViz or Gazebo in unaccelerated modes in Azure
        • Working to connect vcpkg with rosdep
        • Working to implement modular package for windows, leveraging bloom and vcpkg and chocolaty

      • Open Robotics

        • Implementation of XML frontend for launch
        • Design for passing key/value parameters (beside remappings)
        • rviz: interactive markers, torque ring, message filters
        • rqt parameter plugin
        • continue porting rosbrige_suite
        • RPM packaging for CentOS
        • Various bug fixing

      • ROBOTIS

        • Still in preparation of TurtleBot3 on ROS 2 Dashing, we have some issue of Micro-XRCE-DDS-Agent, so we need help from eProsima.
        • These are the efforts ROBOTIS is working on for ROS 2 Eloquent:
          • TurtleBot3:
            • Support ROS 2 Eloquent
            • Support ROS 2 binary packages for TurtleBot3
            • Support Linux distro image based on Raspbian for ROS 2 Dashing and Eloquent with TurtleBot3
            • Porting ROS 1 package of existing TurtleBot3 to ROS 2
              (https://github.com/ROBOTIS-GIT/turtlebot3 and family packages)
          • Turtlesim:
          • ros2arduino:
            • Support ROS 2 Eloquent and add examples and documentation
            • Support Arduino boards and OpenCR (provide completely open-source hardware and software for ROS 1 and 2)
          • ROS 2 Tools (rqt plugin):
            • We want to join the development of the existing ROS 2 Tools based on rqt and contribute to the more diverse ROS 2 tools.

      • GVSC (nee TARDEC)

      • Tier IV

        • Investigation of the work necessary to add Debian as a supported platform (beginning with Tier 2) has begun.
          • Targeting Debian Boxer.
        • Investigation of work necessary to improve real-time support for executors/nodes/publish/subscribe has started but is in extremely early stages. Need to coordinate with the real-time WG but there have not been any meetings.
        • Work on support for RTI’s micro DDS in rmw has started, but progress is likely to be slow.
          • Can drop this?
        • Have also identified other features of need but unsure how to proceed.
          • Most notable is a new diagnostic system that does software as well as hardware.
          • Also raised recently was the need to get large amounts of data out of AWS instances after the fact without paying huge amounts of money, so some kind of compressed storage support for rosbag2. Especially compressed point clouds.

      • Toyota Research Institute

        • Collaborating with Open Robotics on many features
        • There’s a new ROS 2 robot that will come out soon.
    • [2 mins each] Working group updates
      • Embedded
      • Manipulation – Pause group for now
      • Navigation
        • No updates
      • Real time
      • Safety
        • Held a third (?) meeting two weeks ago.
        • Agriculture WG presented their small robot application
        • Identifying specific things we can do to be useful is proving to be difficult.
      • Security
        • Created a framework for testing vulnerabilities and contributed initial attacks and validated those attacks. Need to validate the mitigation.
        • Design is still open: https://github.com/ros2/design/pull/235
        • Next security working group will be scheduled for within the next two weeks to demo and get feedback.
      • New proposed WG: dev tools
        • Rqt_
        • Plot_juggler
        • webviz
        • Seconding Developer Experience focus: LA GB
        • AD Will start with a proposal for graphical tools and information
2

If I may, it would be helpful to applicants to clarify the participation that is actually judged (and how it’s judged). The current charter (version 0.4) doesn’t actually provide any insight into what is expected of a given applicant, it just says to send an email. Do you expect that initial email to contain all the contributions to be judged as well as the story of what the applicant is looking to accomplish on the steering committee? Or are you going to crawl through all ROS repos looking for commits from our email addresses (in which case, what is a “ROS repo” and how did you determine our email addresses)? Neither seem ideal.

Additionally, are there guidelines for what the contributions should be? As an example, I expect that our contributions to SROS 2 would count, but off-hand I’d say our contributions to Fast RTPS would not as it’s not a ROS-specific project. However, given that eProsima is a member of the steering committee, I expect that assumption would be wrong. In that case, do our contributions to support ROS 2 in Snapcraft count toward this? If we were a company creating a robot that runs ROS 2, does that count?

I don’t mean to call anyone out here, I think all the current members are excellent, I’m just saying these lines to external observers look very fuzzy, and guidelines for what counts toward the steering committee members’ FTE don’t seem to exist. Such things would be very useful for applicants. Otherwise it’s hard to even know when one should apply in the first place, especially if you start requiring a minimum history.

3

Hi @gerkey,
Thanks for the meeting minutes.
if possible I’d like to join a real-time discussion as well.

Kind Regards,
Andrei

4

Hi @Dejan_Pangercic

I have seen that you have spent some time on adaptive AUTOSAR: It can have DDS as a transport layer it would be nice to have a bridge between ROS2 and ADAR. We have adaptive AUTOSAR running on Linux and VxWorks. Would be interesting to know what your conclusions are :slight_smile:

Kind Regards,
Andrei

1 Like
5

@kyrofa Thanks for the feedback and the questions. You’re right in pointing out that the lines are fuzzy, and these are among the issues that we’re working through right now. We aim to be as fair and as transparent as possible, but I also want to avoid unwittingly constraining ourselves with rules that won’t age well.

E.g., it was suggested early on that we enumerate the set of repositories that count as being valid destinations for ROS 2 contributions. I argued against that idea because I don’t believe that any such enumeration will stand the test of time. In exchange we have the question you’ve raised, which is what should count?

You’re right that FastRTPS isn’t strictly part of ROS 2, but given the critical role that it plays as a dependency in the ROS 2 ecosystem (not to mention that (I’m guessing) ROS 2 is the most significant use case for FastRTPS), I would consider contributions to FastRTPS to be helping ROS 2. I appreciate that this line of reasoning can be carried to an extreme, wherein patches to LLVM are helping ROS 2.

It’s clear to me that we should improve the rigor of the process for joining and remaining part of the TSC. Please bear with me while we make some improvements.

1 Like