Happy NY everyone.
RTWG folks, here is an agenda for our next meeting. Please add your topics if you have them.
Note: As Dejan is at CES this week, @christophebedard will coordinate the meeting.
From previous meeting minutes: ROS 2 Real-time Working Group Online Meeting 7 - Dec 11, 2019, 7AM PDT (UTC-8)
- Update: LET executor => @JanStaschulat
- Update: Single-process, real-time rmw => @eboasson
- ALL: please provide feedback on https://github.com/ros2/rmw_cyclonedds/issues/79
- DDS direct access
- ROS 2 F feature roadmap will be finalized early 2020
- ALL: Please provide your desired features to the roadmap so Dejan can take them to the TSC
- Below is an input from Apex.AI, please feel free to comment on it.
Apex.AI input regarding the ROS 2 F feature list
- Adopt DDS standard for communication. This is the most production-ready
- Strive to the performance parity with the underlying middleware
- Ensure new components are real-time in terms of blocking call and memory management.
- Do not duplicate functionality (e.g. for Logging use
Log4CXX, for time use
Sorted list of features
- Measure performance: using performance testing framework presented in item 1 here: ROS 2 Real-time Working Group Online Meeting 7 - Dec 11, 2019, 7AM PDT (UTC-8)
- Changes affecting API
- API review, specifically user facing API in rclcpp and rclpy (also necessary for quality levels) -> We should focus on bringing ROS 2 and DDS API to parity. Meaning take/read of loaned messages, conditions, waitset, instance handles etc. We need all of this for the real-time system.
- Revisit message allocators, consider using std::polymorphic_allocator to address problems with custom allocators -> We suggest to eliminate all copies in the middleware (e.g. between ROS 2 and IDL messages). This should have a priority over allocators.
- Support for IDL keys in
- New features
- RMW interface: notification about event, e.g. new entities, matching of endpoints, etc. -> We should use the DDS standard here.
- RWW configuration: unified/standard way of configuring the middleware -> This probably refers to point 6.3 here ROS 2 Real-time Working Group Online Meeting 7 - Dec 11, 2019, 7AM PDT (UTC-8)
- rosbag: support recording services (and actions) -> rosbag2 needs a thorough systematic testing.
- ros1_bridge: support actions -> We think we should encourage proper migration to ROS 2, and spend resources there.
- Executor improvements and determinism -> We agree that the ROS 2 executor needs to be probably rethought, rearchitected and rewritten. RTWG is helping here: ROS 2 Real-time Working Group Online Meeting 7 - Dec 11, 2019, 7AM PDT (UTC-8)
- Missing features - valuable for porting code
- Introspect QoS settings for remote topics (e.g. enables recording reliable and best-effort topics) -> DDS already has this feature. What would be exact plan here?
- Logging subsystem: configuration file, per-logger configuration (ala rqt_logger_level) -> We would suggest to stick to Log4CXX as much as possible.