Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference…
Meeting ID: 892 1636 3368
Passcode: HWwgMTG
One tap mobile
+13462487799,89216363368#,*5585911# US (Houston)
+16699006833,89216363368#,*5585911# US (San Jose)
Dial by your location
+1 346 248 7799 US (Houston)
+1 669 900 6833 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 408 638 0968 US (San Jose)
+1 646 876 9923 US (New York)
+1 301 715 8592 US (Washington DC)
+1 312 626 6799 US (Chicago)
Meeting ID: 892 1636 3368
Passcode: 5585911
Find your local number: Zoom International Dial-in Numbers - Zoom
Thanks to everyone that attended today.
Today’s edition focused on initial topics that sub groups could potentially coalesce around to enable parallel tracks of progress. The current proposed topics include:
Toolbox for type adaptations that are utilized outside of the ROS community to enable quicker onboarding
Jeremy, type adapters in the Humble release. The interpretation type adapter interfaces that may be more flexible. What would be standardized? There is a message set. The type adapter may provide the ability to get vendors to use the same messages/message types. Are there types of adapters that are reusable? Some of this is in ROS 1. Only works in one way. No python. REP 2007 -- Type Adaptation Feature (ROS.org) Similar to image transport in ROS 1. There may be an external subset/data structures may not be so common, so this utility could help these outsiders. (?)
Identify data types that meet a specific need that are currently not present in the ROS domain relative to cameras and sensors. Some vendors will create custom messages to meet a need. Identify these cases, understand if they are “needed” or there is no existing, and for custom that have no clear alignment create a standard for those types.
First step would be a review of published data types in ROS and how they are not adapted from internal data types (on the hardware), id if anything is missing or common that are mis-identified.
Standardization with PLC/PLC-like devices (i.e. ethernet ip) and interfacing and efficient communication with the ROS-based system. Practices to for more efficient interfacing when an PLC may be of interest in the system. Interpretation of bytes. You need to know what is connected internal to the PLC. You can create the mapping on the PLC to provide a nice interface. Doug has written an interface to not have to write/map the specific bytes/bits. Higher abstraction level to enable interpretation by the PLC. To this point, in Doug’s case, he is creating the info models from scratch. Layout the PLC interface to at that level handle the set up between PLC/ROS automatically.
Currently the next meeting is slated for June 9. Please feel free to add agenda topics under the heading for Meeting #6 at the TOP of the notes document.
