From b1a3fef881f430f4085f1d1e64c73378c1ba791a Mon Sep 17 00:00:00 2001 From: Wentao Date: Sun, 4 May 2025 23:31:03 -0400 Subject: [PATCH 1/7] Add files via upload --- wiki/interfacing/template.md | 106 +++++++++++++++++++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 wiki/interfacing/template.md diff --git a/wiki/interfacing/template.md b/wiki/interfacing/template.md new file mode 100644 index 00000000..41bc280f --- /dev/null +++ b/wiki/interfacing/template.md @@ -0,0 +1,106 @@ +--- +# Jekyll 'Front Matter' goes here. Most are set by default, and should NOT be +# overwritten except in special circumstances. +# You should set the date the article was last updated like this: +date: 2020-05-11 # YYYY-MM-DD +# This will be displayed at the bottom of the article +# You should set the article's title: +title: Title goes here +# The 'title' is automatically displayed at the top of the page +# and used in other parts of the site. +--- +This template acts as a tutorial on writing articles for the Robotics Knowledgebase. In it we will cover article structure, basic syntax, and other useful hints. Every tutorial and article should start with a proper introduction. + +This goes above the first subheading. The first 100 words are used as an excerpt on the Wiki's Index. No images, HTML, or special formating should be used in this section as it won't be displayed properly. + +If you're writing a tutorial, use this section to specify what the reader will be able to accomplish and the tools you will be using. If you're writing an article, this section should be used to encapsulate the topic covered. Use Wikipedia for inspiration on how to write a proper introduction to a topic. + +In both cases, tell them what you're going to say, use the sections below to say it, then summarize at the end (with suggestions for further study). + +## First subheading +Use this section to cover important terms and information useful to completing the tutorial or understanding the topic addressed. Don't be afraid to include to other wiki entries that would be useful for what you intend to cover. Notice that there are two \#'s used for subheadings; that's the minimum. Each additional sublevel will have an added \#. It's strongly recommended that you create and work from an outline. + +This section covers the basic syntax and some rules of thumb for writing. + +### Basic syntax +A line in between create a separate paragraph. *This is italicized.* **This is bold.** Here is [a link](/). If you want to display the URL, you can do it like this . + +> This is a note. Use it to reinforce important points, especially potential show stoppers for your readers. It is also appropriate to use for long quotes from other texts. + + +#### Bullet points and numbered lists +Here are some hints on writing (in no particular order): +- Focus on application knowledge. + - Write tutorials to achieve a specific outcome. + - Relay theory in an intuitive way (especially if you initially struggled). + - It is likely that others are confused in the same way you were. They will benefit from your perspective. + - You do not need to be an expert to produce useful content. + - Document procedures as you learn them. You or others may refine them later. +- Use a professional tone. + - Be non-partisan. + - Characterize technology and practices in a way that assists the reader to make intelligent decisions. + - When in doubt, use the SVOR (Strengths, Vulnerabilities, Opportunities, and Risks) framework. + - Personal opinions have no place in the Wiki. Do not use "I." Only use "we" when referring to the contributors and editors of the Robotics Knowledgebase. You may "you" when giving instructions in tutorials. +- Use American English (for now). + - We made add support for other languages in the future. +- The Robotics Knowledgebase is still evolving. We are using Jekyll and GitHub Pages in and a novel way and are always looking for contributors' input. + +Entries in the Wiki should follow this format: +1. Excerpt introducing the entry's contents. + - Be sure to specify if it is a tutorial or an article. + - Remember that the first 100 words get used else where. A well written excerpt ensures that your entry gets read. +2. The content of your entry. +3. Summary. +4. See Also Links (relevant articles in the Wiki). +5. Further Reading (relevant articles on other sites). +6. References. + +#### Code snippets +There's also a lot of support for displaying code. You can do it inline like `this`. You should also use the inline code syntax for `filenames` and `ROS_node_names`. + +Larger chunks of code should use this format: +``` +def recover_msg(msg): + + // Good coders comment their code for others. + + pw = ProtocolWrapper() + + // Explanation. + + if rec_crc != calc_crc: + return None +``` +This would be a good spot further explain you code snippet. Break it down for the user so they understand what is going on. + +#### LaTex Math Support +Here is an example MathJax inline rendering $ \phi(x\|y) $ (note the additional escape for using \|), and here is a block rendering: +$$ \frac{1}{n^{2}} $$ + +#### Images and Video +Images and embedded video are supported. + +![Put a relevant caption here](assets/images/Hk47portrait-298x300.jpg) + +{% include video id="8P9geWwi9e0" provider="youtube" %} + +{% include video id="148982525" provider="vimeo" %} + +The video id can be found at the end of the URL. In this case, the URLs were +`https://www.youtube.com/watch?v=8P9geWwi9e0` +& `https://vimeo.com/148982525`. + +## Summary +Use this space to reinforce key points and to suggest next steps for your readers. + +## See Also: +- Links to relevant material within the Robotics Knowledgebase go here. + +## Further Reading +- Links to articles of interest outside the Wiki (that are not references) go here. + +## References +- Links to References go here. +- References should be in alphabetical order. +- References should follow IEEE format. +- If you are referencing experimental results, include it in your published report and link to it here. From 311ada09cfd0514d7b359c6e1c2d758e04b1539e Mon Sep 17 00:00:00 2001 From: Wentao Date: Sun, 4 May 2025 23:37:46 -0400 Subject: [PATCH 2/7] Delete wiki/interfacing/template.md --- wiki/interfacing/template.md | 106 ----------------------------------- 1 file changed, 106 deletions(-) delete mode 100644 wiki/interfacing/template.md diff --git a/wiki/interfacing/template.md b/wiki/interfacing/template.md deleted file mode 100644 index 41bc280f..00000000 --- a/wiki/interfacing/template.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -# Jekyll 'Front Matter' goes here. Most are set by default, and should NOT be -# overwritten except in special circumstances. -# You should set the date the article was last updated like this: -date: 2020-05-11 # YYYY-MM-DD -# This will be displayed at the bottom of the article -# You should set the article's title: -title: Title goes here -# The 'title' is automatically displayed at the top of the page -# and used in other parts of the site. ---- -This template acts as a tutorial on writing articles for the Robotics Knowledgebase. In it we will cover article structure, basic syntax, and other useful hints. Every tutorial and article should start with a proper introduction. - -This goes above the first subheading. The first 100 words are used as an excerpt on the Wiki's Index. No images, HTML, or special formating should be used in this section as it won't be displayed properly. - -If you're writing a tutorial, use this section to specify what the reader will be able to accomplish and the tools you will be using. If you're writing an article, this section should be used to encapsulate the topic covered. Use Wikipedia for inspiration on how to write a proper introduction to a topic. - -In both cases, tell them what you're going to say, use the sections below to say it, then summarize at the end (with suggestions for further study). - -## First subheading -Use this section to cover important terms and information useful to completing the tutorial or understanding the topic addressed. Don't be afraid to include to other wiki entries that would be useful for what you intend to cover. Notice that there are two \#'s used for subheadings; that's the minimum. Each additional sublevel will have an added \#. It's strongly recommended that you create and work from an outline. - -This section covers the basic syntax and some rules of thumb for writing. - -### Basic syntax -A line in between create a separate paragraph. *This is italicized.* **This is bold.** Here is [a link](/). If you want to display the URL, you can do it like this . - -> This is a note. Use it to reinforce important points, especially potential show stoppers for your readers. It is also appropriate to use for long quotes from other texts. - - -#### Bullet points and numbered lists -Here are some hints on writing (in no particular order): -- Focus on application knowledge. - - Write tutorials to achieve a specific outcome. - - Relay theory in an intuitive way (especially if you initially struggled). - - It is likely that others are confused in the same way you were. They will benefit from your perspective. - - You do not need to be an expert to produce useful content. - - Document procedures as you learn them. You or others may refine them later. -- Use a professional tone. - - Be non-partisan. - - Characterize technology and practices in a way that assists the reader to make intelligent decisions. - - When in doubt, use the SVOR (Strengths, Vulnerabilities, Opportunities, and Risks) framework. - - Personal opinions have no place in the Wiki. Do not use "I." Only use "we" when referring to the contributors and editors of the Robotics Knowledgebase. You may "you" when giving instructions in tutorials. -- Use American English (for now). - - We made add support for other languages in the future. -- The Robotics Knowledgebase is still evolving. We are using Jekyll and GitHub Pages in and a novel way and are always looking for contributors' input. - -Entries in the Wiki should follow this format: -1. Excerpt introducing the entry's contents. - - Be sure to specify if it is a tutorial or an article. - - Remember that the first 100 words get used else where. A well written excerpt ensures that your entry gets read. -2. The content of your entry. -3. Summary. -4. See Also Links (relevant articles in the Wiki). -5. Further Reading (relevant articles on other sites). -6. References. - -#### Code snippets -There's also a lot of support for displaying code. You can do it inline like `this`. You should also use the inline code syntax for `filenames` and `ROS_node_names`. - -Larger chunks of code should use this format: -``` -def recover_msg(msg): - - // Good coders comment their code for others. - - pw = ProtocolWrapper() - - // Explanation. - - if rec_crc != calc_crc: - return None -``` -This would be a good spot further explain you code snippet. Break it down for the user so they understand what is going on. - -#### LaTex Math Support -Here is an example MathJax inline rendering $ \phi(x\|y) $ (note the additional escape for using \|), and here is a block rendering: -$$ \frac{1}{n^{2}} $$ - -#### Images and Video -Images and embedded video are supported. - -![Put a relevant caption here](assets/images/Hk47portrait-298x300.jpg) - -{% include video id="8P9geWwi9e0" provider="youtube" %} - -{% include video id="148982525" provider="vimeo" %} - -The video id can be found at the end of the URL. In this case, the URLs were -`https://www.youtube.com/watch?v=8P9geWwi9e0` -& `https://vimeo.com/148982525`. - -## Summary -Use this space to reinforce key points and to suggest next steps for your readers. - -## See Also: -- Links to relevant material within the Robotics Knowledgebase go here. - -## Further Reading -- Links to articles of interest outside the Wiki (that are not references) go here. - -## References -- Links to References go here. -- References should be in alphabetical order. -- References should follow IEEE format. -- If you are referencing experimental results, include it in your published report and link to it here. From 6f280d1a313ee1fc72098d7f832e43a29c1f9d82 Mon Sep 17 00:00:00 2001 From: Wentao Date: Sun, 4 May 2025 23:38:12 -0400 Subject: [PATCH 3/7] Create template.md --- wiki/interfacing/template.md | 106 +++++++++++++++++++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 wiki/interfacing/template.md diff --git a/wiki/interfacing/template.md b/wiki/interfacing/template.md new file mode 100644 index 00000000..41bc280f --- /dev/null +++ b/wiki/interfacing/template.md @@ -0,0 +1,106 @@ +--- +# Jekyll 'Front Matter' goes here. Most are set by default, and should NOT be +# overwritten except in special circumstances. +# You should set the date the article was last updated like this: +date: 2020-05-11 # YYYY-MM-DD +# This will be displayed at the bottom of the article +# You should set the article's title: +title: Title goes here +# The 'title' is automatically displayed at the top of the page +# and used in other parts of the site. +--- +This template acts as a tutorial on writing articles for the Robotics Knowledgebase. In it we will cover article structure, basic syntax, and other useful hints. Every tutorial and article should start with a proper introduction. + +This goes above the first subheading. The first 100 words are used as an excerpt on the Wiki's Index. No images, HTML, or special formating should be used in this section as it won't be displayed properly. + +If you're writing a tutorial, use this section to specify what the reader will be able to accomplish and the tools you will be using. If you're writing an article, this section should be used to encapsulate the topic covered. Use Wikipedia for inspiration on how to write a proper introduction to a topic. + +In both cases, tell them what you're going to say, use the sections below to say it, then summarize at the end (with suggestions for further study). + +## First subheading +Use this section to cover important terms and information useful to completing the tutorial or understanding the topic addressed. Don't be afraid to include to other wiki entries that would be useful for what you intend to cover. Notice that there are two \#'s used for subheadings; that's the minimum. Each additional sublevel will have an added \#. It's strongly recommended that you create and work from an outline. + +This section covers the basic syntax and some rules of thumb for writing. + +### Basic syntax +A line in between create a separate paragraph. *This is italicized.* **This is bold.** Here is [a link](/). If you want to display the URL, you can do it like this . + +> This is a note. Use it to reinforce important points, especially potential show stoppers for your readers. It is also appropriate to use for long quotes from other texts. + + +#### Bullet points and numbered lists +Here are some hints on writing (in no particular order): +- Focus on application knowledge. + - Write tutorials to achieve a specific outcome. + - Relay theory in an intuitive way (especially if you initially struggled). + - It is likely that others are confused in the same way you were. They will benefit from your perspective. + - You do not need to be an expert to produce useful content. + - Document procedures as you learn them. You or others may refine them later. +- Use a professional tone. + - Be non-partisan. + - Characterize technology and practices in a way that assists the reader to make intelligent decisions. + - When in doubt, use the SVOR (Strengths, Vulnerabilities, Opportunities, and Risks) framework. + - Personal opinions have no place in the Wiki. Do not use "I." Only use "we" when referring to the contributors and editors of the Robotics Knowledgebase. You may "you" when giving instructions in tutorials. +- Use American English (for now). + - We made add support for other languages in the future. +- The Robotics Knowledgebase is still evolving. We are using Jekyll and GitHub Pages in and a novel way and are always looking for contributors' input. + +Entries in the Wiki should follow this format: +1. Excerpt introducing the entry's contents. + - Be sure to specify if it is a tutorial or an article. + - Remember that the first 100 words get used else where. A well written excerpt ensures that your entry gets read. +2. The content of your entry. +3. Summary. +4. See Also Links (relevant articles in the Wiki). +5. Further Reading (relevant articles on other sites). +6. References. + +#### Code snippets +There's also a lot of support for displaying code. You can do it inline like `this`. You should also use the inline code syntax for `filenames` and `ROS_node_names`. + +Larger chunks of code should use this format: +``` +def recover_msg(msg): + + // Good coders comment their code for others. + + pw = ProtocolWrapper() + + // Explanation. + + if rec_crc != calc_crc: + return None +``` +This would be a good spot further explain you code snippet. Break it down for the user so they understand what is going on. + +#### LaTex Math Support +Here is an example MathJax inline rendering $ \phi(x\|y) $ (note the additional escape for using \|), and here is a block rendering: +$$ \frac{1}{n^{2}} $$ + +#### Images and Video +Images and embedded video are supported. + +![Put a relevant caption here](assets/images/Hk47portrait-298x300.jpg) + +{% include video id="8P9geWwi9e0" provider="youtube" %} + +{% include video id="148982525" provider="vimeo" %} + +The video id can be found at the end of the URL. In this case, the URLs were +`https://www.youtube.com/watch?v=8P9geWwi9e0` +& `https://vimeo.com/148982525`. + +## Summary +Use this space to reinforce key points and to suggest next steps for your readers. + +## See Also: +- Links to relevant material within the Robotics Knowledgebase go here. + +## Further Reading +- Links to articles of interest outside the Wiki (that are not references) go here. + +## References +- Links to References go here. +- References should be in alphabetical order. +- References should follow IEEE format. +- If you are referencing experimental results, include it in your published report and link to it here. From b5a69c2236bc4cd9eb103be43d7f1882eca2fd70 Mon Sep 17 00:00:00 2001 From: Wentao Date: Sun, 4 May 2025 23:38:15 -0400 Subject: [PATCH 4/7] Delete wiki/interfacing/template.md --- wiki/interfacing/template.md | 106 ----------------------------------- 1 file changed, 106 deletions(-) delete mode 100644 wiki/interfacing/template.md diff --git a/wiki/interfacing/template.md b/wiki/interfacing/template.md deleted file mode 100644 index 41bc280f..00000000 --- a/wiki/interfacing/template.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -# Jekyll 'Front Matter' goes here. Most are set by default, and should NOT be -# overwritten except in special circumstances. -# You should set the date the article was last updated like this: -date: 2020-05-11 # YYYY-MM-DD -# This will be displayed at the bottom of the article -# You should set the article's title: -title: Title goes here -# The 'title' is automatically displayed at the top of the page -# and used in other parts of the site. ---- -This template acts as a tutorial on writing articles for the Robotics Knowledgebase. In it we will cover article structure, basic syntax, and other useful hints. Every tutorial and article should start with a proper introduction. - -This goes above the first subheading. The first 100 words are used as an excerpt on the Wiki's Index. No images, HTML, or special formating should be used in this section as it won't be displayed properly. - -If you're writing a tutorial, use this section to specify what the reader will be able to accomplish and the tools you will be using. If you're writing an article, this section should be used to encapsulate the topic covered. Use Wikipedia for inspiration on how to write a proper introduction to a topic. - -In both cases, tell them what you're going to say, use the sections below to say it, then summarize at the end (with suggestions for further study). - -## First subheading -Use this section to cover important terms and information useful to completing the tutorial or understanding the topic addressed. Don't be afraid to include to other wiki entries that would be useful for what you intend to cover. Notice that there are two \#'s used for subheadings; that's the minimum. Each additional sublevel will have an added \#. It's strongly recommended that you create and work from an outline. - -This section covers the basic syntax and some rules of thumb for writing. - -### Basic syntax -A line in between create a separate paragraph. *This is italicized.* **This is bold.** Here is [a link](/). If you want to display the URL, you can do it like this . - -> This is a note. Use it to reinforce important points, especially potential show stoppers for your readers. It is also appropriate to use for long quotes from other texts. - - -#### Bullet points and numbered lists -Here are some hints on writing (in no particular order): -- Focus on application knowledge. - - Write tutorials to achieve a specific outcome. - - Relay theory in an intuitive way (especially if you initially struggled). - - It is likely that others are confused in the same way you were. They will benefit from your perspective. - - You do not need to be an expert to produce useful content. - - Document procedures as you learn them. You or others may refine them later. -- Use a professional tone. - - Be non-partisan. - - Characterize technology and practices in a way that assists the reader to make intelligent decisions. - - When in doubt, use the SVOR (Strengths, Vulnerabilities, Opportunities, and Risks) framework. - - Personal opinions have no place in the Wiki. Do not use "I." Only use "we" when referring to the contributors and editors of the Robotics Knowledgebase. You may "you" when giving instructions in tutorials. -- Use American English (for now). - - We made add support for other languages in the future. -- The Robotics Knowledgebase is still evolving. We are using Jekyll and GitHub Pages in and a novel way and are always looking for contributors' input. - -Entries in the Wiki should follow this format: -1. Excerpt introducing the entry's contents. - - Be sure to specify if it is a tutorial or an article. - - Remember that the first 100 words get used else where. A well written excerpt ensures that your entry gets read. -2. The content of your entry. -3. Summary. -4. See Also Links (relevant articles in the Wiki). -5. Further Reading (relevant articles on other sites). -6. References. - -#### Code snippets -There's also a lot of support for displaying code. You can do it inline like `this`. You should also use the inline code syntax for `filenames` and `ROS_node_names`. - -Larger chunks of code should use this format: -``` -def recover_msg(msg): - - // Good coders comment their code for others. - - pw = ProtocolWrapper() - - // Explanation. - - if rec_crc != calc_crc: - return None -``` -This would be a good spot further explain you code snippet. Break it down for the user so they understand what is going on. - -#### LaTex Math Support -Here is an example MathJax inline rendering $ \phi(x\|y) $ (note the additional escape for using \|), and here is a block rendering: -$$ \frac{1}{n^{2}} $$ - -#### Images and Video -Images and embedded video are supported. - -![Put a relevant caption here](assets/images/Hk47portrait-298x300.jpg) - -{% include video id="8P9geWwi9e0" provider="youtube" %} - -{% include video id="148982525" provider="vimeo" %} - -The video id can be found at the end of the URL. In this case, the URLs were -`https://www.youtube.com/watch?v=8P9geWwi9e0` -& `https://vimeo.com/148982525`. - -## Summary -Use this space to reinforce key points and to suggest next steps for your readers. - -## See Also: -- Links to relevant material within the Robotics Knowledgebase go here. - -## Further Reading -- Links to articles of interest outside the Wiki (that are not references) go here. - -## References -- Links to References go here. -- References should be in alphabetical order. -- References should follow IEEE format. -- If you are referencing experimental results, include it in your published report and link to it here. From 3167e2e6e969e9e5686bde2b2132b73c93915182 Mon Sep 17 00:00:00 2001 From: Wentao Date: Sun, 4 May 2025 23:42:28 -0400 Subject: [PATCH 5/7] Add files via upload --- wiki/interfacing/gRPC-Bridge-for-ROS2-and-visionOS.md | 1 + 1 file changed, 1 insertion(+) create mode 100644 wiki/interfacing/gRPC-Bridge-for-ROS2-and-visionOS.md diff --git a/wiki/interfacing/gRPC-Bridge-for-ROS2-and-visionOS.md b/wiki/interfacing/gRPC-Bridge-for-ROS2-and-visionOS.md new file mode 100644 index 00000000..8b137891 --- /dev/null +++ b/wiki/interfacing/gRPC-Bridge-for-ROS2-and-visionOS.md @@ -0,0 +1 @@ + From e894b731182ecdf714f4151381f2b594b7f6d4f8 Mon Sep 17 00:00:00 2001 From: Wentao Date: Sun, 4 May 2025 23:43:53 -0400 Subject: [PATCH 6/7] Update gRPC-Bridge-for-ROS2-and-visionOS.md --- .../gRPC-Bridge-for-ROS2-and-visionOS.md | 255 ++++++++++++++++++ 1 file changed, 255 insertions(+) diff --git a/wiki/interfacing/gRPC-Bridge-for-ROS2-and-visionOS.md b/wiki/interfacing/gRPC-Bridge-for-ROS2-and-visionOS.md index 8b137891..de405a74 100644 --- a/wiki/interfacing/gRPC-Bridge-for-ROS2-and-visionOS.md +++ b/wiki/interfacing/gRPC-Bridge-for-ROS2-and-visionOS.md @@ -1 +1,256 @@ +# Using gRPC as a Communication Bridge Between ROS 2 and visionOS +This tutorial will guide you through creating a bidirectional communication bridge between ROS 2 systems and visionOS applications using gRPC. By the end, you'll understand how to define communication interfaces with Protocol Buffers, implement a gRPC server within a ROS 2 environment, develop a gRPC client in Swift for visionOS, and address key considerations for robust implementation. We'll focus on architectural design patterns rather than specific code implementation. + +## Understanding the Core Concepts + +Before diving into the implementation, it's important to understand the fundamental concepts of both ROS 2 and gRPC, as well as the unique characteristics of visionOS. + +### ROS 2 Communication Mechanisms + +ROS 2 (Robot Operating System 2) is designed for distributed robotic systems and provides several communication mechanisms: + +- **Nodes**: Basic computational units that perform specific tasks within the ROS 2 ecosystem. +- **Topics**: Use publish/subscribe patterns for continuous data stream transmission. +- **Services**: Implement request/response patterns for command execution or status querying. +- **Actions**: Handle long-running tasks that require feedback and can be canceled. + +These mechanisms rely on interfaces defined in `.msg`, `.srv`, and `.action` files. Under the hood, ROS 2 uses **DDS (Data Distribution Service)** as its middleware layer, which manages node discovery and data transport, typically over UDP. + +Developers interact with ROS 2 through client libraries like `rclcpp` (C++) and `rclpy` (Python) that provide APIs for creating nodes, publishers, subscribers, and more. + +### gRPC Core Features + +gRPC is a high-performance RPC (Remote Procedure Call) framework that: + +- Uses **Protocol Buffers (Protobuf)** as its Interface Definition Language (IDL) +- Runs on top of HTTP/2, leveraging its multiplexing and header compression +- Supports four types of communication: + - **Unary RPC**: Simple request/response + - **Server streaming RPC**: Server sends a stream of responses to a single client request + - **Client streaming RPC**: Client sends a stream of requests followed by a single server response + - **Bidirectional streaming RPC**: Both sides send message streams independently + +The workflow centers around `.proto` files that define services and message structures. The `protoc` compiler generates language-specific code for both client and server implementations. + +### visionOS Platform Considerations + +When building for visionOS, be aware of these important constraints: + +- **Network APIs**: visionOS supports standard network protocols through `URLSession` and `Network.framework` +- **Background Execution Limitations**: Apps have restricted network capabilities when not in the foreground +- **Battery Considerations**: Continuous network communication can significantly impact battery life +- **Swift Support**: Official gRPC and Protobuf libraries exist for Swift, making integration feasible + +These platform characteristics significantly influence how you'll design your bridge, particularly regarding connection management and data transmission patterns. + +## Designing the Communication Bridge + +The bridge architecture consists of three main components: + +1. **Interface Definition** (.proto files) +2. **gRPC Server** (ROS 2 side) +3. **gRPC Client** (visionOS side) + +Let's examine each component in detail. + +### Interface Definition with Protocol Buffers + +The `.proto` file forms the contract between your ROS 2 environment and visionOS application. Here's how to approach its design: + +- Use **proto3** syntax for modern features and better language support +- Define **message types** that closely map to ROS 2 message structures +- Define **service methods** that represent your communication patterns + +For ROS 2 → visionOS communication, server streaming RPC is often appropriate: + +``` +service RosBridge { + // Stream sensor data from ROS 2 to visionOS + rpc StreamTopicData(TopicRequest) returns (stream SensorData) {} +} +``` + +For visionOS → ROS 2 communication, unary or client streaming RPC may be suitable: + +``` +service RosBridge { + // Send commands from visionOS to ROS 2 + rpc SendCommand(CommandRequest) returns (CommandResponse) {} +} +``` + +When mapping ROS 2 types to Protobuf: +- Simple types (int, float, string, bool) map directly +- Arrays in ROS 2 map to `repeated` fields in Protobuf +- ROS 2 Headers should be explicitly defined as a message type in Protobuf +- Complex nested structures should maintain their hierarchy + +For example, mapping a `sensor_msgs/Image` message: + +``` +message HeaderMsg { + uint32 seq = 1; + TimeMsg stamp = 2; + string frame_id = 3; +} + +message TimeMsg { + uint32 secs = 1; + uint32 nsecs = 2; +} + +message ImageMsg { + HeaderMsg header = 1; + uint32 height = 2; + uint32 width = 3; + string encoding = 4; + bool is_bigendian = 5; + uint32 step = 6; + bytes data = 7; +} +``` + +### Implementing the gRPC Server in ROS 2 + +The gRPC server runs within or alongside your ROS 2 environment and performs these key functions: + +1. Interface with ROS 2 nodes using `rclcpp` or `rclpy` +2. Convert between ROS 2 messages and Protobuf messages +3. Implement the gRPC service methods defined in your `.proto` file + +#### Architecture Options + +You have two main architectural approaches: + +1. **Integrated Node**: Implement the gRPC server directly within a ROS 2 node + - Advantages: Direct access to ROS 2 context, simpler deployment + - Challenges: Need to manage ROS 2 and gRPC execution models together + +2. **Separate Process**: Run the gRPC server as a standalone process communicating with ROS 2 + - Advantages: Cleaner separation of concerns, independent scaling + - Challenges: Additional IPC overhead, more complex deployment + +#### Implementation Strategy + +For the integrated approach: +- Create a ROS 2 node using `rclcpp` (C++) or `rclpy` (Python) +- Add gRPC server implementation in the same codebase +- Manage concurrent processing of ROS 2 callbacks and gRPC requests using: + - Separate threads for gRPC server + - Non-blocking I/O patterns + - ROS 2 executors configuration + +For example, a ROS 2 topic subscriber callback would: +1. Receive a ROS 2 message +2. Convert it to a Protobuf message +3. Stream it to connected gRPC clients + +### Implementing the gRPC Client in visionOS + +The visionOS application implements a gRPC client in Swift that: +1. Establishes connection to the gRPC server +2. Sends requests and receives responses +3. Converts Protobuf messages to Swift structures +4. Integrates with the visionOS application lifecycle + +#### Connection Management + +To handle visionOS's background execution limitations: + +- Implement connection state management (connecting, connected, disconnected, reconnecting) +- Use exponential backoff for reconnection attempts +- Consider foreground/background state transitions using `ScenePhase` +- Potentially use short-lived connections rather than persistent streaming when in background + +#### Data Flow Integration + +Integrate the received data with visionOS features: +- Update SwiftUI views with received sensor data +- Use device tracking information from ARKit to send back to ROS 2 +- Consider spatial anchoring of visualizations using RealityKit + +## Performance Optimization and Best Practices + +To ensure your bridge performs well in real-world conditions, consider these key areas: + +### Data Efficiency + +- Minimize data transfer: + - Use compression for large messages (images, point clouds) + - Filter data on ROS 2 side before transmission + - Consider downsampling high-frequency topics + +- Optimize serialization/deserialization: + - Avoid unnecessary data copying + - Reuse message objects where possible + - Profile conversion code to identify bottlenecks + +### Robustness and Error Handling + +Build resilience into your communication: + +- Implement timeouts for all gRPC calls +- Use gRPC status codes to identify and handle specific error cases +- Gracefully handle network transitions and interruptions +- Log connection events and errors for debugging + +### Platform-Specific Considerations + +For visionOS: +- Adapt network communication based on foreground/background state +- Monitor and optimize battery impact +- Consider using Background Tasks API for periodic updates when in background +- Provide UI feedback about connection state to users + +For ROS 2: +- Configure DDS for optimal network performance +- Consider QoS settings for critical topics +- Implement resource management (e.g., limit subscribers for high-bandwidth topics) + +## Alternative Approaches + +While this tutorial focuses on gRPC, consider these alternatives based on your specific needs: + +- **rosbridge (WebSocket/JSON)**: Easier to implement but less efficient than gRPC +- **MQTT**: Lightweight publish/subscribe messaging for constrained devices +- **ZeroMQ**: Flexible messaging library with various patterns +- **Native DDS**: Direct DDS communication if Swift bindings are available (limited) + +Here's a comparison of these approaches: + +| Approach | Advantages | Disadvantages | +|----------|------------|---------------| +| gRPC | Strong typing, efficient binary format, official Swift support | More complex setup, RPC model differs from ROS 2 | +| rosbridge | Simple to implement, JSON format is human-readable | Less efficient, weaker type safety | +| MQTT | Lightweight, wide adoption | Need additional serialization, no built-in RPC | +| Native DDS | Direct ROS 2 compatibility | Limited Swift support, more complex to configure | + +## Summary + +In this tutorial, we've explored how to create a communication bridge between ROS 2 and visionOS using gRPC. We've covered: + +- Protocol Buffer interface definition to map ROS 2 messages to gRPC +- Server implementation strategies within ROS 2 +- Client implementation for visionOS in Swift +- Performance optimization and platform-specific considerations + +This architecture enables robotic systems using ROS 2 to interact with spatial computing applications on visionOS, opening possibilities for innovative mixed reality interfaces for robotics. + +## See Also: +- ROS 2 Core Concepts +- Swift Development for visionOS +- Protocol Buffers for Data Serialization +- Network Programming in iOS/visionOS + +## Further Reading +- [gRPC Documentation](https://grpc.io/docs/) +- [Protocol Buffers Developer Guide](https://protobuf.dev/programming-guides/) +- [ROS 2 Design](https://design.ros2.org/) +- [Apple Developer Documentation for visionOS](https://developer.apple.com/documentation/visionos/) + +## References +- Eclipse Cyclone DDS. "About DDS: Eclipse Cyclone DDS." Accessed May 4, 2025. https://cyclonedds.io/docs/cyclonedds/latest/about_dds/eclipse_cyclone_dds.html +- Google. "gRPC overview | API Gateway Documentation." Google Cloud. Accessed May 4, 2025. https://cloud.google.com/api-gateway/docs/grpc-overview +- Google. "Language Guide (proto 3) | Protocol Buffers Documentation." Accessed May 4, 2025. https://protobuf.dev/programming-guides/proto3/ +- Apple Inc. "visionOS | Apple Developer Documentation." Accessed May 4, 2025. https://developer.apple.com/documentation/visionos/ \ No newline at end of file From ad08fb236de90e4fb95f8c40784326c4d2012ab1 Mon Sep 17 00:00:00 2001 From: Wentao Date: Sun, 4 May 2025 23:46:29 -0400 Subject: [PATCH 7/7] Update navigation.yml --- _data/navigation.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/_data/navigation.yml b/_data/navigation.yml index 6600d2a4..4874b3c1 100644 --- a/_data/navigation.yml +++ b/_data/navigation.yml @@ -389,3 +389,5 @@ docs: children: - title: Introduction url: /docs/ +- title: gRPC Bridge for ROS2 and visionOS + url: /wiki/interfacing/gRPC-Bridge-for-ROS2-and-visionOS \ No newline at end of file pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy