├── agenda ├── 2024-12-05.md ├── 2024-07-04.md ├── 2025-02-06.md ├── 2024-10-03.md ├── 2025-04-03.md ├── 2024-04-04.md ├── 2024-02-01.md ├── 2024-05-02.md ├── 2023-12-07.md ├── 2025-03-06.md ├── 2024-11-07.md ├── 2024-03-07.md ├── 2024-06-06.md ├── 2024-01-04.md └── 2024-08-01.md ├── meetings ├── 2023-12-07 │ └── README.md └── 2023-09-07 │ └── README.md └── README.md /agenda/2024-12-05.md: -------------------------------------------------------------------------------- 1 | ### Use Cases Around Open-RMF and Interoperability by Reply 2 | 3 | This month our friends from [Reply](https://www.reply.com/en) will be presenting on work that they've been doing on robotics system integration using Open-RMF. 4 | -------------------------------------------------------------------------------- /agenda/2024-07-04.md: -------------------------------------------------------------------------------- 1 | ### Open Mic Night 2 | 3 | With the Fourth of July being a major holiday in the United States, the next special interest group meeting will be a (lightly moderated) open mic night. There will not be any special topic or presentation, so feel free to chat with the rest of the group about anything remotely in the sphere of interoperability. 4 | 5 | We will not be recording this session, but I might take notes if anything particularly interesting develops from the conversations. 6 | -------------------------------------------------------------------------------- /agenda/2025-02-06.md: -------------------------------------------------------------------------------- 1 | ### Customize and configure the rmf-web dashboard with MicroApps 2 | 3 | This month Aaron Chong will present on how to leverage the new MicroApp architecture of [rmf-web](https://github.com/open-rmf/rmf-web) to make custom dashboards for fleet management. 4 | 5 | MicroApps are React components used to customize the rmf-web dashboard. This talk will go through what MicroApps are, how they can be built, and how to integrate them with an existing rmf-web dashboard. We will also go through some of the MicroApps that already come with the rmf-dashboard-framework, and how they interact with an Open-RMF deployment. 6 | -------------------------------------------------------------------------------- /agenda/2024-10-03.md: -------------------------------------------------------------------------------- 1 | ### The Challenge of Resource Contention in Large-Scale Robot Fleets 2 | 3 | When large fleets of robots need to perform ad hoc tasks that utilize limited resources such as parking spots, (un)loading points, or chargers, operations can get messy if you don't have a way to resolve conflicts between robots that want to use the same resource at the same time. 4 | 5 | At this session of the interoperability special interest group, Arjo Chakravarty will present on the new resource reservation system that is being introduced to Open-RMF. This new system will automatically prevent robots from attempting to use the same resource at the same time, and will also redirect robots to available parking spots where they can wait until the resource that they want becomes available. 6 | -------------------------------------------------------------------------------- /agenda/2025-04-03.md: -------------------------------------------------------------------------------- 1 | 2 | ### Scenarios: How to manage a multiverse 3 | 4 | The [site editor](https://github.com/open-rmf/rmf_site) is a tool in the Open-RMF project that allows users to sketch a facility in 3D and specify the mobile robot traffic rules within it. 5 | 6 | A common requirement when designing the operations within a facility is the need to consider many different configurations of robots. You may want to see what happens when they are positioned differently or have different properties. You might see positive or negative impacts on the effectiveness or efficiency of your operations under the different circumstances. 7 | 8 | A recently introduced feature to the site editor is the concept of **Scenarios** which allows users to create inter-related variations of scenarios within the same facility. Scenarios can have parent/child relationships with each other where child scenarios inherit the characteristics of parent scenarios and then introduce their own modifications. This creates branching worlds where modifications to a parent scenario will carry over into the child scenarios, while child scenarios can diverge from each other. 9 | 10 | At this month's session, Xiyu Oh will introduce us to the scenarios feature. 11 | -------------------------------------------------------------------------------- /agenda/2024-04-04.md: -------------------------------------------------------------------------------- 1 | ### Recent feature developments in Open-RMF 2 | 3 | As a temporary break from discussing infrastructure messages, this session will cover some new features and capabilities that were developed in Open-RMF over the last 6 months. We will be talking about the motivations for the features, where they can be used, and how to use them effectively. We'll be covering the following features: 4 | * Mutex Groups: Apply a "mutex" label to a group of elements in the navigation graph to indicate that only one robot can use any element of that group at a time, regardless of whether the traffic conflict system believes there is room for multiple robots. This is useful in crowded or otherwise sensitive areas of a map where the usual conflict prevention system cannot accurately anticipate the high risk of deadlocks. 5 | * Dynamic Charging: Historically the implementation of Open-RMF has required that each robot have its own dedicated charging point, and that is not allowed to change at any time. The new Dynamic Charging feature allows the charging points of any robot to be changed at any time. 6 | * Commissioning: The new commissioning feature allows an operator to request that robot stops receiving new tasks and can also toggle the "idle behavior" (e.g. having the robot return to its charger). This feature also allows pending tasks to be reassigned across different robots within the same fleet. However, tasks that have already been started by a robot cannot be transferred to another robot. 7 | -------------------------------------------------------------------------------- /agenda/2024-02-01.md: -------------------------------------------------------------------------------- 1 | ### Standardizing Infrastructure Messages, Part 2 2 | 3 | After a fruitful discussion at the last session, we will continue exploring how to approach introducing standardized infrastructure messages into the ROS 2 ecosystem. 4 | 5 | We will present and discuss some ideas on how to encapsulate the key data structures that need to be transmitted. In particular there will be a proposal about having three types of data: 6 | 7 | * **State**: Data that describes what a device is doing at any given moment. 8 | * **Properties**: Data that describes inherent characteristics of a device, which rarely if ever change after being deployed. 9 | * **Requests**: Data that describes an action for a device to perform or a state for a device to move into. 10 | 11 | We will share some examples of how messages can be organized into these types and how pub/sub topics might be designed to use them. 12 | 13 | A particularly challenging question that will be raised is whether property data should be modular (spread across multiple message types and transmitted across a different topic for each type), and if so what the granularity should be. Or should the property data of a device all get lumped into one message and transmitted across one topic. Same for the state data. 14 | 15 | As always we will open up for general discussion at the end. Like at the last session, the concluding discussion will not be recorded, but anonymous notes will be taken to preserve any feedback or ideas that are raised. 16 | -------------------------------------------------------------------------------- /agenda/2024-05-02.md: -------------------------------------------------------------------------------- 1 | ### Sneak Peek of Next Generation Open-RMF 2 | 3 | The current implementation of Open-RMF has proven to be a valuable proof of concept for enabling heterogeneous fleets of robots to operate in shared spaces and with shared infrastructure. With the benefit of lessons learned from numerous trial deployments, we are looking towards a reimplementation to increase the scope, scale, capabilities, reliability, and ease of use that Open-RMF provides to its users. The next session of the interoperability group will reveal the new software architecture that's planned to tackle all these needs at the same time. 4 | 5 | Beyond improving the design and implementation of Open-RMF, our architectural plans may be of interest to developers that need to deal with interoperability in general. We'll be explaining how our choices will enable high performance, highly-concurrent (parallel/multithreaded), memory safe, bug-free code that can tie together disparate systems with a high degree of modularity. 6 | 7 | The key themes will be to take advantage of a high performance [Entity-Component-System](https://en.wikipedia.org/wiki/Entity_component_system) framework (specifically [Bevy](https://bevyengine.org/)) and a [service-driven architecture](https://en.wikipedia.org/wiki/Service-oriented_architecture) to create an SDK that has a broad and flexible surface area, in stark contrast to the design choice of having a very narrow and rigid API for the current Open-RMF. We'll talk about the trade-offs of these choices and why we've decided to make such a sharp pivot. 8 | -------------------------------------------------------------------------------- /agenda/2023-12-07.md: -------------------------------------------------------------------------------- 1 | ### Advantages of Rust for software system integration 2 | 3 | By now you've certainly been exposed to some of the hype behind the Rust programming language. 4 | For the last eight years Rust has [ranked #1 in the "Most admired language"](https://github.blog/2023-08-30-why-rust-is-the-most-admired-language-among-developers/#:~:text=For%20the%20eighth%20year%20in,Stack%20Overflow's%20annual%20developer%20survey.) category of Stack Overflow's annual developer survey. 5 | Perhaps no other language in the history of software programming has commanded a following so dedicated to pestering their colleagues, friends, and random passers-by to switch to it for every conceivable use case. 6 | 7 | At the next session of the Interoperability Special Interest Group, Grey will discuss the relevance of Rust to software system integration in particular. 8 | The challenge of tying together complex software systems carries significant liabilities. 9 | Failures to connect systems together correctly or to scale well can lead to cascading failures in your operations. 10 | The Rust language and its surrounding open source ecosystem offer some unique advantages when it comes to both software correctness and scaling. 11 | 12 | This will not be a session that teaches how to program in Rust. 13 | The focus will be to provide attendees with enough information to objectively evaluate whether Rust is a good candidate for their business needs, with an emphasis on software system integration use cases. 14 | We will conclude with an open Q&A, so feel free to bring along any burning questions or concerns you might have. 15 | -------------------------------------------------------------------------------- /agenda/2025-03-06.md: -------------------------------------------------------------------------------- 1 | ### Memory-safe High-performance Async ROS Programming: A Preview 2 | 3 | Interoperability often involves managing complex interactions between devices. These interactions may be transmissions of data or they may be physical activities that need to take place according to a specific procedure. In either case, good use of async programming is necessary to prevent processes from stalling while waiting for units of action to finish. Async programming is especially important when one process is managing multiple agents simultaneously. 4 | 5 | Async programming is also notoriously difficult to do correctly. Traditional imperative programming is good for describing linear sequential steps, but quickly becomes difficult to follow when it needs to describe multiple interwoven activities. Race conditions are endemic in async programming, including data races which can violate memory safety, leading to bugs that are extremely difficult to fix. Even worse, these bugs can open programs up to security vulnerabilities. 6 | 7 | This talk will provide a preview of some work in progress being done for [`rclrs`](https://github.com/ros2-rust/ros2_rust), a community-driven ROS client library for the Rust programming language. The upcoming features will allow `rclrs` to support Rust's high performance async programming capabilities, with memory safety guaranteed at compile time. We will look at the (working draft) API for these features and especially cover how the API differs from `rclcpp` and `rclpy` in order to take advantage of the unique characteristics of the Rust language, making many common use cases of async programming intuitive and fool-proof. 8 | -------------------------------------------------------------------------------- /agenda/2024-11-07.md: -------------------------------------------------------------------------------- 1 | ### What's in an interface? 2 | 3 | That which we call an API by any other name would serve just as well. But when there are many diverging opinions on exactly what names to use or exactly how to structure things, we may end up scattering instead of working together. 4 | 5 | The OSRA TGC opened a technical committee to examine the ROS Enhancement Proposal (REP) process to refine it and apply it to all of the projects that are governed by the OSRA, including Open-RMF. The PMC of Open-RMF sees this as an opportunity to formalize something similar to a Request For Comments (RFC) process for Open-RMF where we can define interfaces for our next generation development and receive comments from the public, especially from stakeholders, to make sure that we'll be developing the most useful tools possible for everyone. This would also define a formal way for anyone from the general public to propose new interfaces for Open-RMF to support. 6 | 7 | At this session of the special interest group, Grey will present a working draft of what kind of process we are considering for Open-RMF. 8 | 9 | We are eager to get feedback from the Open-RMF community and beyond about how to make this process as effective as possible. Effectiveness would be measured both in terms of making sure we are producing the highest quality stable interfaces possible and also getting contributions (proposals, feedback, and implementation) from as many community stakeholders as possible. After presenting our current thoughts, we want to open up the session to discussion and feedback, so please come ready to share your own thoughts. We will especially appreciate input from anyone that has experience (both positive and negative experiences) working with standardization bodies. 10 | -------------------------------------------------------------------------------- /agenda/2024-03-07.md: -------------------------------------------------------------------------------- 1 | ### Standardizing Infrastructure Messages, Part 3 2 | 3 | Continuing our discussion from the last session, our next session will get into more depth on how errors for building infrastructure devices should be represented. 4 | 5 | Some questions to consider: 6 | 7 | - What level of detail needs to be standardized for error messages? 8 | - Is it enough to simply communicate that the devices is unusable? 9 | - Should the standardized error messages also provide enough information for a technician to troubleshoot the device? 10 | - Should detailed troubleshooting information be provided through a separate non-standard channel instead? 11 | - How efficient should error messages be? 12 | - A simple error code is high performance and allows for millions of possible error types but then can only communicate the presence of one error at a time 13 | - Bitsets could express multiple simultaneous errors with high performance but then the number of error types is severely limited 14 | - Dynamic arrays of error codes can communicate many types of errors with no limit but then heap allocations are needed 15 | - A string of serialized JSON could represent unlimited types of errors and provide troubleshooting information for them, but then heap allocation and string parsing are needed 16 | - Should standardized error definitions be specific to each type of building device, or should the definitions be abstract enough to use across all/multiple devices? 17 | - E.g. are doors and elevators different enough that they need their own error code definitions? 18 | - What kind of errors should we expect to report for each different type of device? 19 | 20 | We will be seeking input on all of the above questions and more. 21 | Please come armed with examples of your most hated kinds of device errors that you think a good standard should be able to express. 22 | -------------------------------------------------------------------------------- /agenda/2024-06-06.md: -------------------------------------------------------------------------------- 1 | ### Preview of the RMF Site Editor 2 | 3 | In an effort to improve the usability and extensibility of RMF, we've been working on an experimental side project to create a whole new kind of editor. We're getting close to launching its first release, and we thought it would be a good time to demonstrate its capabilities to the community. 4 | 5 | This new editor, called the "[Site Editor](https://github.com/open-rmf/rmf_site)", is foremost a replacement for the [old traffic editor](https://github.com/open-rmf/rmf_traffic_editor), so its core capabilities are: 6 | * Edit 3D environments in sufficient detail for visualization and simulation 7 | * Edit the robots present in the environment 8 | * Edit the traffic rules for the robots 9 | * Edit elevators (lifts) and doors that are present in the environment 10 | 11 | But beyond that, the site editor opens up new possibilities that would not have been feasible with the old traffic editor. Since it was developed on top of the [Bevy](https://bevyengine.org/) video game engine, it will be possible for downstream users to extend and customize its capabilities. Users could even develop and sell a commercial product built on top of it. 12 | 13 | The site editor is cross-platform, being able to compile to a native desktop application on Linux, Windows, and macOS. It can even [run in a web browser](https://open-rmf.github.io/rmf_site/web/) by compiling to Web Assembly. This opens up exciting opportunities to develop commercial applications locally even if you intend to deploy them to customers as a web service. 14 | 15 | At this session, we will do a quick demonstration of using the site editor to partially build a hotel environment. If you're familiar with using the old traffic editor, you'll immediately see how much smoother the new workflow is. Feel free to bring in ideas for additional features that would make your workflows easier or more expressive. 16 | -------------------------------------------------------------------------------- /meetings/2023-12-07/README.md: -------------------------------------------------------------------------------- 1 | # 07 December 2023 2 | [Meeting Recording](https://drive.google.com/file/d/1BU5qDUPzS9jNvdCX3A-Gvh7Q30xlEgKx/view?usp=drive_link) 3 | 4 | ## Agenda 5 | 6 | - Andrei Ionescu: ISO/WD 21423 Introduction [Slides Here](https://docs.google.com/presentation/d/1e5HNCG2qqzCX6pwG_i5tqlUYqB4KJHWPQVC0wqrEGlY/edit?usp=drive_link) 7 | - Grey: Rust for System Integration [Slides Here](https://docs.google.com/presentation/d/1H--iwOXAMW7HdA5tUOGx5TkNJiq6clEcmohb37ECKZs/edit?usp=drive_link) 8 | 9 | ## Discussion 10 | 11 | - Bainian asks about using Rust-implemented code inside of a C++ program 12 | - Grey refers Bainian to [corrosion](https://corrosion-rs.github.io/corrosion/) 13 | - Bainian asks about how Open-RMF will be transitioning to Rust 14 | - Grey explains some details about the migration plans that 15 | - Some nodes/components, such as the Reservation System, could be migrated over to Rust entirely 16 | - The `rmf_fleet_adapter` C++ API will remain available and its implementation will be replaced with a Rust implementation 17 | - New (hopefully better) SDKs for all supported languages (Rust, C++, Python) will become available based on the new Rust implementation 18 | - Bainian asks about how the migration will affect traffic negotiation in RMF 19 | - Grey explains that the negotiation implementation has never been stable and is not exposed to the `rmf_fleet_adapter` API, so changes to negotiation will not impact existing fleet integrations 20 | - Bainian asks about stability within the Rust community, e.g. drama related to the Rust Foundation 21 | - Grey responds that he is aware of these events but does not find it concerning overall 22 | - Drama is not unusual in large open source communities, but the communities generally still thrive 23 | - All core Rust language software is permissive and open source so no one can pull the rug on the community 24 | - In the worst case scenario, the language and its tools can be maintained or forked off into something new regardless of the Rust Foundation 25 | -------------------------------------------------------------------------------- /agenda/2024-01-04.md: -------------------------------------------------------------------------------- 1 | ### Standardizing Infrastructure Messages 2 | 3 | There is a growing need for mobile robots to able to interact with general infrastructure such as automatic doors and elevators (referred to as "lifts" in some regions). 4 | For convenience we will lump these non-robot devices under the umbrella term of facility "infrastructure". 5 | Typically system integrators will perform ad hoc integration with infrastructure devices, using various protocols, often based on OPC-UA and/or MQTT. 6 | This may require developing a custom ROS node to integrate the infrastructure into a ROS-based system. 7 | 8 | We would like to see the development of a community standard message package for infrastructure interactions. 9 | The Open-RMF project has [various message packages](https://github.com/open-rmf/rmf_internal_msgs/) that it has been using to do infrastructure integration, but these message definitions were developed specifically for the use cases that we needed to deal with and never targeted for general consumption. 10 | Nevertheless, there are many lessons we learned while working with these message definitions, and we would like to leverage that experience towards general-purpose infrastructure messages for the community. 11 | 12 | This session of the interest group is meant to facilitate an open discussion about this topic. 13 | We are specifically hoping for community input on the matter, especially from anyone who is aware of similar existing efforts in open infrastructure integration. 14 | Most likely we will have follow-up sessions in later months as we attempt to iterate towards a set of message definitions that have compelling buy-in from the community. 15 | A desired final result of this effort would be an [REP](https://ros.org/reps/rep-0001.html) along with a release of one or more message packages related to infrastructure integration. 16 | 17 | We will start the session with an overview of lessons learned from our efforts with Open-RMF, including some open questions that we would appreciate specific community feedback on. 18 | Some of those open questions include: 19 | * What to use to uniquely identify different "participants" in a system? E.g. unique string (centrally controlled), unique integer (centrally controlled), UUID (distributed generation)? 20 | * Representation of different modes of operation: standardized integer (like http error codes) or user-defined string? 21 | * Device-specific message definitions or generic/abstract message definitions? E.g. `DoorState` vs `DeviceState`. 22 | * Release separate message packages for each type of device, or one unified `infrastructure_msgs` package? 23 | 24 | After that we will open up for general discussion, with priority for anyone who knows of relevant existing standards/specifications/efforts that they would like to share. 25 | -------------------------------------------------------------------------------- /meetings/2023-09-07/README.md: -------------------------------------------------------------------------------- 1 | # 07 September 2023 2 | [Meeting Recording](https://vimeo.com/866899277) | [Meeting Announcement](https://discourse.ros.org/t/special-interest-group-in-interoperability/33081) 3 | 4 | ## Agenda 5 | - Grey (Open-RMF): Intro and presentation of the Interoperability Interest Group. 6 | [Slides here](https://docs.google.com/presentation/d/1mqAuq4llmWopb-5RgX-_C8QjSCvfPf_KQIr3_AlNvjE/edit?usp=sharing) (Min. 00:00). 7 | - Daniel Theobald (MassRobotics Interop): "Interoperability: What It Is and Why We Need it." 8 | [Slides here](https://docs.google.com/presentation/d/1cFZXvimJdHJOpY8TzB1lPHmiLmnA1Gpi/edit?usp=drive_link&ouid=105800562763083176452&rtpof=true&sd=true) (Min. 10:45) 9 | - Grey (Open-RMF): "Open-RMF Brief Overview." 10 | [Slides here](https://docs.google.com/presentation/d/1tDYIunOreVIWiqeDfgBrNAE8M3iZ-tRbpegyiWsPxlg/edit?usp=drive_link) (Min. 23:48) 11 | 12 | ## Administivia 13 | 14 | - Meetings will run monthly for 1 hour with announcements on the [ROS discourse](https://discourse.ros.org). 15 | - Github org for collaboration: [https://github.com/osrf-sig-interoperability](https://github.com/osrf-sig-interoperability) 16 | 17 | ## Discussion 18 | 19 | - Gillaume Autran worked with VDA5050 so he gave and commented how it targets AMRs with a bit of AGVs support. (Min. 40:40) 20 | - Grey and Daniel commented on how Open-RMF, MassRobotics Interop and VDA5050 can complement each other. (Min. 41:30) 21 | - Grey answered follow up questions on possible collaborations (Min. 47:28) 22 | - Grey answered what interoperability means in the context of Open-RMF and Daniel answered for MassRobotics Interop. (Min. 48:05) 23 | - Grey and Daniel answered for network requirements for Open-RMF and MassRobotics Interop respectively. (Min. 52:00) 24 | - Grey commented on the differences on the future event driven simulation expected for RMF vs scaling gazebo. (Min. 54:04) 25 | - Grey commented on how to deal with fleetstate semantics for system validation. (Min. 55:23) 26 | - Daniel asked regarding having physics turned on on simulation on a per robot level and Grey commented 27 | regarding the Gazebo Trivial Physics Engine and how extremely hard it would be to combine that with actual physics. (Min. 56:27) 28 | - Daniel addressed how the VDA5050 standard efforts will correlate with MassRobotics work. (Min 59:35) 29 | - Grey commented on the workflow on how to deploy Open-RMF, specifically how to obtain the map using the traffic editor. (Min. 60:00) 30 | - Grey commented on possible workflows for Open-RMF when remapping environments and handling transforms. (Min: 1:07:00) 31 | - Grey explained how the easy full control API makes easier custom actions although there are more sophisticated 32 | ways to deal with task customization to come. (Min. 1:11:45) 33 | - Grey addressed how Open-RMF some nodes are already robust to teardown and restart and others still need work to get there. (Min. 1:15:00) 34 | -------------------------------------------------------------------------------- /agenda/2024-08-01.md: -------------------------------------------------------------------------------- 1 | ### Multi-Agent Process Workflows 2 | 3 | In the field of process modeling, workflow diagrams (a.k.a. flowcharts) are an intuitive way to describe how a process evolves from its initial state to being complete. In the fields of discrete event systems and distributed systems, there is a well-studied state machine formulation of workflow diagrams called [workflow nets](http://mlwiki.org/index.php/Workflow_Nets) which are a specialization of [Petri nets](https://en.wikipedia.org/wiki/Petri_net). Workflow nets are particularly good at representing processes with a distinct beginning, distinct finish, and which may involve asynchronous events, cycles, simultaneous parallel actions, and synchronization between multiple independent agents. 4 | 5 | While behavior trees are a popular way to express finite state machines in robotics, their tree structure encumbers them with limitations that make it difficult--sometimes impossible--to express workflows that involve arbitrary process branching, arbitrary synchronization, or arbitrary cycles. While behavior trees __can__ do all of these operations to a limited extent, each operation must always somehow fit within a rigid hierarchy. Workflows are not limited in this way, and can support any structure of branching, syncing, and cycling. Put simply, every behavior tree can be converted into an equivalent workflow, but not every workflow can be represented as a behavior tree. 6 | 7 | The Open-RMF project has a long history of developing systems where one program needs to juggle attention for many agents, and each agents has multiple sub-processes that need to be run simultaneously and synchronized safely. Developing and maintaining these systems has historically been a very taxing burden for the project since we couldn't find a framework for process modeling and control that met all our requirements around flexibility, performance, safety, expressiveness, and openness. 8 | 9 | To build the "next generation" of the Open-RMF project, we are rolling out [`bevy_impulse`](https://github.com/open-rmf/bevy_impulse) which implements arbitrary workflow building and execution on top of the [Bevy](https://bevyengine.org/) game engine. This will serve as a crucial foundation for many aspects of next gen Open-RMF: 10 | * Synchronization between robot state updates, multi-agent planners, and robot platform APIs 11 | * Defining and executing complex tasks, especially multi-agent tasks 12 | * Defining and executing modular behaviors for robots which can be used as building blocks for tasks 13 | * Synchronization between multiple devices, e.g. customizing workflows for how an AMR interacts with a door or elevator 14 | 15 | At this session of the Interoperability Special Interest group, we will discuss the current capabilities of `bevy_impulse` as we get ready to fire off its first release. We'll go over the key concepts that are driving its design, discuss its API, and show some usage examples. 16 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # OSRF Special Interest Group for Interoperability 2 | 3 | This is the community landing page for the Open Source Robotics Foundation's Special Interest Group for Interoperability. 4 | Our mission is to discuss and promote the objective of making robotics systems and relevant infrastructure (both software and hardware) interoperable. 5 | Interoperable can mean components are interchangeable or it can mean different systems work together correctly and with minimal friction. 6 | 7 | # Meetings 8 | 9 | Monthly meetings will be held [at this Zoom link](https://openrobotics-org.zoom.us/j/82222141986?pwd=30wAfBwxIQ66O12HslQVvBziGxPmJ0.1). 10 | 11 | A recurring event can be found for the interest group on the [Official OSRF Events Calendar](https://calendar.google.com/calendar/embed?src=agf3kajirket8khktupm9go748%40group.calendar.google.com&ctz=UTC). 12 | 13 | Meetings will usually take place on the first Thursday of each month. 14 | Check the [agenda](agenda) directory for specific plans for upcoming sessions. 15 | 16 | To reach as many time zones as possible, sessions are scheduled at 15:00 UTC+0. 17 | To give an idea of the spread, this would be the usual session time for various time zones: 18 | * 07:00 Pacific Time (west coast of USA) 19 | * 10:00 Eastern Time (east coast of USA) 20 | * 16:00 Central European Time 21 | * 20:30 Indian Standard Time 22 | * 23:00 UTC+8 (China, Taiwan, Singapore, Malaysia, Indonesia) 23 | 24 | # Agenda Planning 25 | 26 | As much as possible, we would like the agenda of our sessions to be driven by what the community is interested in. 27 | If there are topics around interoperability that you'd like to see highlighted, please open an [issue ticket](https://github.com/osrf-sig-interoperability/community/issues) in this repository explaining what you would like to see covered. 28 | If you are interested in presenting on a relevant topic, feel free to open an issue ticket or leave a comment on someone else's ticket to volunteer. 29 | You may also contact mxgrey@intrinsic.ai to volunteer as a presenter. 30 | 31 | We envision a few different formats for sessions that we would like to arrange: 32 | 33 | ### Regular Presentation 34 | 35 | One invited expert presents on a relevant topic and provides a Q&A at the end of the session. 36 | 37 | ### Panel Session 38 | 39 | Multiple invited experts on one topic (or multiple related topics) give brief presentations according to each of their own expertises and then take questions from the audience in facilitated discussion. 40 | 41 | ### Roundtable Session 42 | 43 | We decide on a topic ahead of time, and then any interested community members volunteer ahead of time to give a short ~3-5 minute presentation sharing their thoughts or relevant work on the topic. 44 | After all prearranged presentations are finished, we facilitate an open discussion on the topic. 45 | 46 | ### Lightning Talks 47 | 48 | Similar to a roundtable, but with a more strictly enforced 3 minute time limit and no constraints on topic except that it cannot violate the [ROS Community Code of Conduct](https://osrf.github.io/code_of_conduct/#:~:text=Members%20of%20the%20ROS%20community,patches%2C%20problems%2C%20or%20otherwise.). 49 | Preferably the topic of each talk should be relevant to people who care about interoperability, but we will humor a loose interpretation of that criteria. 50 | Leave a comment [here](https://github.com/osrf-sig-interoperability/community/issues/5) to express your interest in sharing a lightning talk. 51 | --------------------------------------------------------------------------------