You can see more complete versions of a “teleop” code with various options and arrows key-pressed listener here:
In the scenario described above, the zenoh application discovers the zenoh/DDS bridge via its scouting protocol that leverages UDP multicast - when available. Once discovered, a TCP connection is established between the app and the bridge
But the zenoh application can also be configured to directly establish a TCP connection with a known host, without relying on scouting protocol. Thus, it can connect directly to the bridge (if reachable) or to 1 or more zenoh routers that will route the zenoh communications between the application and the bridge.
Let’s see the different use cases:
Assuming you can configure your internet connection to open a public TCP port (e.g. 7447) and redirect it to the host running the zenoh/DDS bridge, you can do the following deployment:
Where:
the zenoh/DDS bridge is started with this command:
zenoh-bridge-dds -m peer -l tcp/0.0.0.0:7447
+You can see more complete versions of a “teleop” code with various options and arrows key-pressed listener here:
In the scenario described above, the zenoh application discovers the zenoh/DDS bridge via its scouting protocol that leverages UDP multicast - when available. Once discovered, a TCP connection is established between the app and the bridge
But the zenoh application can also be configured to directly establish a TCP connection with a known host, without relying on scouting protocol. Thus, it can connect directly to the bridge (if reachable) or to 1 or more zenoh routers that will route the zenoh communications between the application and the bridge.
Let’s see the different use cases:
Assuming you can configure your internet connection to open a public TCP port (e.g. 7447) and redirect it to the host running the zenoh/DDS bridge, you can do the following deployment:
Where:
the zenoh/DDS bridge is started with this command:
zenoh-bridge-dds -m peer -l tcp/0.0.0.0:7447
The -l option makes the bridge to listen for TCP connection on port 7447.
Our zenoh teleop application must be configured to connect to the public IP and port of the bridge.
In Python, this is done adding a "peer" configuration when initializing the API:
# note: replace "123.4.5.6" with your public IP in here:
session = zenoh.net.open({"peer": "tcp/123.4.5.6:7447"})
With the “teleop” demos provided here, you can use the -e tcp/123.4.5.6:7447 program argument.
If you can’t open a public TCP port in your LAN, let’s use a zenoh router in a public cloud instance that will intermediate the communications between the bridge and the zenoh application:
To deploy this:
Pick your favorite cloud provider and provision a 64-bit Ubuntu VM with a public IP.
Install the zenoh router in this VM following those instructions: diff --git a/blog/2021-11-09-ros2-zenoh-pico/index.html b/blog/2021-11-09-ros2-zenoh-pico/index.html index 9e5ace4c..ee2fc132 100644 --- a/blog/2021-11-09-ros2-zenoh-pico/index.html +++ b/blog/2021-11-09-ros2-zenoh-pico/index.html @@ -100,7 +100,7 @@ zn_write(s, *reskey, (const uint8_t *)buf, twist_serialized_size); } -
Note: auxiliary structs and serialization functions are missing in the previous snippet. For the full code, including the adaptations for the turtlesim, please check the code under https://github.com/eclipse-zenoh/zenoh-demos/tree/master/ROS2/zenoh-pico-teleop-gyro
In order to set up the infrastructure and the turtlebot / turtle in different configurations, follow the steps described in our previous blog. However, note that Zenoh-pico currently supports client mode only (a lightweight peer mode is coming soon). As such, you might need to deploy at least one Zenoh router to which your microcontroller application will need to connect to. The minimum steps are shown below:
If everything goes well, you might be able to control the robot just like in the video below.
| Turtlebot3 Burger | Turtlesim | ||
|---|---|---|---|
 |  |
Really cool, isn’t it?!
Although it seems a very simple demonstration, it is supported by several state-of-the-art technologies and protocols that are running under the hood. For you as a developer, being abstracted from all of them means that you can focus on the core business of your application.
Moreover, Zenoh and Zenoh-pico are bridging the gap between ROS 2 and microcontroller environments, allowing ROS 2 users to make use of all its capabilities within their applications. Summarizing some key points:
Tell us about your ideas on how to unlock the power of microcontrollers. We will provide all the support you need either in GitHub or Discord.
–CG +
Note: auxiliary structs and serialization functions are missing in the previous snippet. For the full code, including the adaptations for the turtlesim, please check the code under https://github.com/eclipse-zenoh/zenoh-demos/tree/main/ROS2/zenoh-pico-teleop-gyro
In order to set up the infrastructure and the turtlebot / turtle in different configurations, follow the steps described in our previous blog. However, note that Zenoh-pico currently supports client mode only (a lightweight peer mode is coming soon). As such, you might need to deploy at least one Zenoh router to which your microcontroller application will need to connect to. The minimum steps are shown below:
If everything goes well, you might be able to control the robot just like in the video below.
| Turtlebot3 Burger | Turtlesim | ||
|---|---|---|---|
| |
Really cool, isn’t it?!
Although it seems a very simple demonstration, it is supported by several state-of-the-art technologies and protocols that are running under the hood. For you as a developer, being abstracted from all of them means that you can focus on the core business of your application.
Moreover, Zenoh and Zenoh-pico are bridging the gap between ROS 2 and microcontroller environments, allowing ROS 2 users to make use of all its capabilities within their applications. Summarizing some key points:
Tell us about your ideas on how to unlock the power of microcontrollers. We will provide all the support you need either in GitHub or Discord.