Updated the Zenoh queryable example for clarity and consistency. Improved structure, simplified language, and clarified the battery health calculation.

Author: madeline-underwood

content/learning-paths/cross-platform/zenoh-multinode-ros2/1_intro-zenoh.md

@@ -15,21 +15,21 @@ Such systems require fast, reliable, and scalable data communication between nod
 This includes not just broadcasting sensor updates or actuator commands (pub/sub), but also performing state queries, storing values for later use, and even distributed computation across nodes. 
 
 A modern protocol must be:
-* Low-latency: Immediate delivery of time-critical messages.
-* High-throughput: Efficient data flow across many devices.
-* Decentralized: No reliance on central brokers or fixed infrastructure.
-* Flexible: Able to run on lightweight edge devices, across WANs, or inside cloud-native environments.
+* Low-latency: immediate delivery of time-critical messages
+* High-throughput: efficient data flow across many devices
+* Decentralized: no reliance on central brokers or fixed infrastructure
+* Flexible: able to run on lightweight edge devices, across WANs, or inside cloud-native environments
 
 Traditional communication stacks such as Data Distribution Service (DDS) serve as the backbone for middleware like ROS 2. However, DDS struggles in multi-network or wireless environments where multicast is unavailable, or NAT traversal is needed. Zenoh was developed to address these challenges with a unified approach to data movement, storage, and interaction across heterogeneous, distributed systems.
 
 ## What is Zenoh? A scalable pub/sub protocol for the industrial edge
 
 [Eclipse Zenoh](https://zenoh.io/) is a modern, open-source, data-centric communication protocol that goes beyond traditional pub/sub. Designed specifically for edge computing, industrial IoT, robotics, and autonomous systems, Zenoh unifies:
 
-- Data in motion through a powerful and efficient pub/sub model.
-- Data at rest via geo-distributed storage plugins.
-- Data in use with direct query support.
-- On-demand computation via queryable nodes that can generate data dynamically.
+- Data in motion through a powerful and efficient pub/sub model
+- Data at rest via geo-distributed storage plugins
+- Data in use with direct query support
+- On-demand computation via queryable nodes that can generate data dynamically
 
 Unlike most traditional stacks, Zenoh is fully decentralized and designed to operate across cloud-to-edge-to-thing topologies, making it ideal for industrial robotics, autonomous systems, and smart environments. 
 
@@ -42,7 +42,7 @@ In this Learning Path, you’ll use Zenoh to build and validate a multi-node dis
 You can substitute Raspberry Pi with any Linux-based Arm device that supports networking, such as a Cortex-A or Neoverse board.
 
 By the end of this Learning Path, you'll be able to:
-- Explain the core architecture and data flow principles behind Eclipse Zenoh protocol, including its support for pub/sub, querying, and queryable edge functions.
-- Build and run distributed Zenoh examples across multiple Arm-based nodes using Raspberry Pi or other Arm Linux devices.
-- Rebuild and extend a Zenoh queryable node to simulate edge-side logic.
+- Explain the core architecture and data flow principles behind Eclipse Zenoh protocol, including its support for pub/sub, querying, and queryable edge functions
+- Build and run distributed Zenoh examples across multiple Arm-based nodes using Raspberry Pi or other Arm Linux devices
+- Rebuild and extend a Zenoh queryable node to simulate edge-side logic
 

content/learning-paths/cross-platform/zenoh-multinode-ros2/2_zenoh-install.md

@@ -9,11 +9,9 @@ layout: learningpathall
 
 ## Set up Zenoh on Arm devices
 
-This section shows how to install and build the open-source Eclipse Zenoh protocol on Arm-based devices like Raspberry Pi.
+This section shows you how to install and build the open-source Eclipse Zenoh protocol on Arm-based devices like Raspberry Pi.
 
-The following instructions have been verified on Raspberry Pi 4 and 5, but you can use any Arm Linux device. These steps apply to Raspberry Pi and other Arm-based Linux platforms.
-
-Before building Zenoh, make sure your system has the necessary development tools and runtime libraries.
+The following instructions have been verified on Raspberry Pi 4 and 5, but you can use any Arm Linux device. These steps apply to Raspberry Pi and other Arm-based Linux platforms. Before building Zenoh, make sure your system has the necessary development tools and runtime libraries.
 
 ### Install the Rust development environment
 

content/learning-paths/cross-platform/zenoh-multinode-ros2/3_zenoh-multinode.md

@@ -11,21 +11,16 @@ layout: learningpathall
 
 After building Zenoh and its core examples, the next step is to deploy them across multiple Arm-based devices.
 
-If you’ve already installed Zenoh on an Arm Cortex-A or Neoverse platform as shown in the previous section, you can simply copy the compiled binaries from `~/zenoh/target/release/` to each of your Raspberry Pi devices.
+If you’ve already installed Zenoh on an Arm Cortex-A or Neoverse platform as shown in the previous section, you can copy the compiled binaries from `~/zenoh/target/release/` to each of your Raspberry Pi devices. 
 
-However, to streamline deployment across multiple devices and ensure repeatability, this section demonstrates how to package Zenoh into a Docker image for batch rollout and scalable testing.
+To simplify and scale deployment across multiple devices, this section shows how to containerize Zenoh with Docker for streamlined distribution and consistent multi-node testing. This containerized approach enables repeatable rollouts and makes it easier to test distributed communication across Raspberry Pi, Arm cloud instances (like AWS Graviton), and Arm Virtual Hardware.
 
-This containerized approach not only simplifies deployment on Raspberry Pi, but also integrates seamlessly with Arm cloud platforms such as AWS Graviton Arm Cortex-A Linux or Arm Virtual Hardware, enabling a consistent cloud-to-edge development and validation workflow.
-
-In this session, you’ll use Raspberry Pi boards to simulate a scalable distributed environment. The same workflow applies to any Arm Linux system, including cloud instances and virtual hardware.
-
-This setup allows you to simulate real-world, cross-node communication scenarios, making it ideal for evaluating Zenoh’s performance in robotics and industrial IoT applications.
+In this session, you’ll use Raspberry Pi boards to simulate a scalable distributed environment. The same workflow applies to any Arm Linux system, including cloud instances and virtual hardware. This setup allows you to simulate real-world, cross-node communication scenarios, making it ideal for evaluating Zenoh’s performance in robotics and industrial IoT applications. Zenoh is ideal for robotics and industrial IoT systems that require fast, decentralized communication. It supports scalable data exchange across devices using pub/sub, storage, and query models.
 
 ### Install Docker on Raspberry Pi
-To simplify this process and ensure consistency, you can use Docker to containerize your Zenoh and ROS 2 environment. 
-This lets you quickly replicate the same runtime on any device without needing to rebuild from source.
+To simplify this process and ensure consistency, you can use Docker to containerize your Zenoh and ROS 2 environment. This lets you quickly replicate the same runtime on any device without needing to rebuild from source.
 
-This enables multi-node testing and real-world distributed communication scenarios.
+This enables scalable, multi-node testing in realistic distributed environments.
 
 First, install Docker on each Raspberry Pi device:
 
@@ -146,9 +141,9 @@ docker run -it --network=host zenoh-node
 
 The Zenoh example binaries are now available within this container, allowing you to test pub/sub and query flows across devices.
 
-## Run Zenoh in a multi-node environment
+## Run Zenoh examples in a multi-node environment
 
-You’re now ready to run and test Zenoh communication flows across distributed edge devices.
+With Zenoh running inside containers across devices, you’re now ready to explore real-time communication using prebuilt examples.
 
 The following examples are written in Rust and precompiled in your container image. They're fully interoperable and can be used to demonstrate Zenoh's key capabilities across devices. The Rust binaries are available in the `$ZENOH_LOC/target/release/examples/` directory. If you haven't set `ZENOH_LOC`, they can be found under `~/zenoh/target/release/examples/`.
 

content/learning-paths/cross-platform/zenoh-multinode-ros2/4_zenoh-ex1-pubsub.md

@@ -12,18 +12,18 @@ This example demonstrates Zenoh's real-time publish/subscribe model across two R
 
 The subscriber listens for all data published under the key expression `demo/example/**`, which matches any topic beginning with `demo/example/`.
 
-## Start the subscriber node
+### Start the subscriber node
 
-Run the subscriber example on one of the Raspberry Pi systems.
+Run the subscriber example on one of the Raspberry Pi systems:
 
 ```bash
 cd ~/zenoh/target/release/examples
 ./z_sub
 ```
 
-## Start the publisher node
+### Start the publisher node
 
-Then, log in to the other Raspberry Pi and run the publisher.
+Then, log in to the other Raspberry Pi and run the publisher:
 
 ```bash
 cd ~/zenoh/target/release/examples
@@ -34,15 +34,13 @@ cd ~/zenoh/target/release/examples
 You can run both `z_sub` and `z_pub` on the same device for testing, but running them on separate Raspberry Pis demonstrates Zenoh’s distributed discovery and cross-node communication.
 {{% /notice %}}
 
-## Observe the pub/sub data flow
+### Observe the pub/sub data flow
 
-The result is shown below:
+The results are shown below:
 
 ![img1 Zenoh subscriber receiving messages from a publisher in a two-terminal view#center](zenoh_ex1.gif "Simple Pub/Sub")
 
-The left-side window shows the `z_sub` program. 
-
-It receives values with the key `demo/example/zenoh-rs-pub` continuously published by `z_pub` running in the right-side window.
+The left-side window shows the `z_sub` program. It receives values with the key `demo/example/zenoh-rs-pub` continuously published by `z_pub` running in the right-side window.
 
 This example confirms that Zenoh’s zero-configuration peer discovery and real-time pub/sub communication are working correctly across physical nodes.
 

content/learning-paths/cross-platform/zenoh-multinode-ros2/5_zenoh-ex2-storagequery.md

@@ -7,22 +7,25 @@ weight: 6
 layout: learningpathall
 ---
 
-## Example 2: Storage and query
+##  Query historical data using Zenoh’s storage engine
 
-The second example adds Zenoh's data storage and querying capabilities by enabling nodes to retrieve historical values on demand.
+This example demonstrates Zenoh's data storage and query model which enables nodes to retrieve previously published values—even after the original publisher goes offline.
 
-Building on the previous pub/sub example, you’ll now explore how Zenoh supports persistent data storage and on-demand querying, a powerful feature for robotics and IIoT applications.
+Building on the previous pub/sub example, you’ll now run a lightweight Zenoh daemon that stores key–value pairs in memory. Then, you’ll publish data with `z_put` and retrieve it using `z_get`.
 
-In a typical warehouse or factory scenario, autonomous robots can periodically publish sensor data,such as position, temperature, or battery level—that a central system or peer robot may later need to query.
+This pattern is ideal for robotics and IIoT scenarios where devices intermittently connect or request snapshots of remote state.
 
+For example, in a warehouse or factory:
+- Robots can periodically publish position, temperature, or battery level
+- A central system or peer node can later query these values on demand
 
 Unlike Pub/Sub, which requires live, real-time message exchange, Zenoh's storage and query model enables asynchronous access to data that was published earlier, even if the original publisher is no longer online.
 
 In this example, you’ll run the `zenohd` daemon with in-memory storage and use `z_put` to publish data and `z_get` to retrieve it.
 
 This is especially useful for distributed systems where nodes may intermittently connect or request snapshots of state from peers.
 
-### Step 1: Start the Zenoh daemon with in-memory storage
+### Start the Zenoh daemon with in-memory storage
 
 On one Raspberry Pi, launch the Zenoh daemon with a configuration that enables in-memory storage for keys in the `demo/example/**` directory.
 
@@ -37,7 +40,7 @@ You should see log messages indicating that the storage_manager plugin is loaded
 
 If port 7447 is already in use, either stop any previous Zenoh processes or configure a custom port using the `listen.endpoints.router` setting.
 
-### Step 2: Publish data
+### Publish a value
 
 On 2nd Raspberry Pi device, use `z_put` to send a key-value pair that will be handled by the `zenohd` storage.
 
@@ -48,7 +51,7 @@ cd ~/zenoh/target/release/examples
 
 This command stores the string `Hello from storage!` under the key demo/example/test1.
 
-### Step 3: Query the data
+### Query the stored value
 
 Back on first Raspberry Pi, you can now query the stored data from any Zenoh connected node.
 
@@ -68,9 +71,18 @@ The result is shown below:
 
 ![img2 alt-text#center](zenoh_ex2.gif "Figure 2: Storage and Query")
 
-{{% notice tip %}}
+{{% notice Tip %}}
 If you have more than two Raspberry Pi devices, you can run the `z_get` command on a third device to validate that storage queries work seamlessly across a multi-node setup.
 {{% /notice %}}
 
 This example shows how Zenoh's storage with query model supports asynchronous data access and resilient state-sharing—critical capabilities in robotics and industrial IoT systems where network connectivity may be intermittent or system components loosely coupled.
 
+## What's next
+
+Now that you've seen how Zenoh handles pub/sub and storage-based queries, you're ready to build reactive and intelligent edge nodes.
+
+In the next example, you’ll implement a **Zenoh queryable** that responds to runtime parameters,such as battery level and temperature, by computing and returning a real-time health score. This showcases how Zenoh supports on-demand edge computation without needing to pre-store data.
+
+
+
+

content/learning-paths/cross-platform/zenoh-multinode-ros2/6_zenoh-ex3-queryable.md

@@ -1,25 +1,25 @@
 ---
-title: Run a Zenoh queryable example for edge computation
+title: Run a Zenoh queryable node for on-demand edge computation
 
 weight: 7
 
 ### FIXED, DO NOT MODIFY
 layout: learningpathall
 ---
 
-## Example 3: Computation on query 
+## Computation on query 
 
-Next, you’ll explore Zenoh's queryable capability, which lets a node dynamically respond to data queries by executing a custom computation or data generation function.
+This example demonstrates Zenoh's queryable capability, which lets a node respond to incoming data requests by computing results in real time, rather than returning previously stored values.
 
 Unlike `zenohd` which simply returns stored data, a queryable node can register to handle a specific key expression and generate responses at runtime. This is ideal for distributed computing at the edge, where lightweight devices, such as Raspberry Pi nodes, can respond to requests with calculated values. This enables sensor fusion, AI inference results, and diagnostics.
 
-### Use Case: On-Demand battery health estimation
+### Use case: estimate battery health on demand
 
 Imagine a robot fleet management system where the central planner queries each robot for its latest battery health score, which is not published continuously but calculated only when queried.
 
-This saves bandwidth and enables edge compute optimization using Zenoh's Queryable.
+This reduces bandwidth usage and enables edge-side optimization using Zenoh's queryable feature.
 
-### Step 1: Launch a queryable node
+### Launch a queryable node
 
 On one Raspberry Pi device, run the `z_queryable` Zenoh example to register a queryable handler.
 
@@ -38,7 +38,7 @@ Press CTRL-C to quit...
 
 The node is now ready to accept queries on the key `demo/example/zenoh-rs-queryable` and respond with a predefined message.
 
-### Step 2: Trigger a query from another node
+### Trigger a query from another node
 
 On the other Raspberry Pi device, run the `z_get` example.
 
@@ -71,4 +71,7 @@ This model enables edge-based intelligence, such as:
 
 Queryable is a key feature for data-in-use scenarios, allowing fine-grained, on-demand compute inside your Zenoh-powered architecture.
 
-Next, you’ll extend this Queryable pattern to perform parameterized computation, simulating edge diagnostics and adaptive inference.
+## What's next
+
+In the next example, you'll extend this queryable pattern to support **runtime parameters**, such as battery level and temperature, allowing each node to return a calculated health score on demand.
+

content/learning-paths/cross-platform/zenoh-multinode-ros2/7_zenoh-querycomp.md

@@ -1,5 +1,5 @@
 ---
-title: Run a Zenoh queryable with parameterized computation
+title: Run a Zenoh queryable with parameterized Rust computation
 weight: 8
 
 ### FIXED, DO NOT MODIFY
@@ -14,15 +14,15 @@ You’ll learn how to use Zenoh's Queryable API in Rust to build a parameterized
 
 This extends a previous example by supporting runtime query parameters like battery level and temperature.
 
-## Use Case: Real-time battery health via computation
+## Use case: real-time battery health through on-demand computation
 
 In robotic fleet management, a central controller may need to assess each robot’s battery health on demand. 
 
 Instead of streaming data continuously, robots expose a queryable endpoint that returns a real-time health score based on current battery level and temperature. 
 
 This saves bandwidth and enables lightweight edge-side decision-making.
 
-### Step 1: Create a new Zenoh rust project
+### Create a new Zenoh rust project
 
 On any Raspberry Pi:
 
@@ -40,7 +40,7 @@ tokio = { version = "1", features = ["full"] }
 url = "2"
 ```
 
-### Step 2: Implement the queryable node
+### Implement the queryable node
 
 Next, log in to the other Raspberry Pi.
 
@@ -103,8 +103,14 @@ Inside the callback:
 - A health score is computed from these inputs.
 - The result is sent back to the querying client using query.reply().
 
+{{% notice Tip %}}
+You can extend this queryable pattern to respond to other real-time diagnostics, such as CPU load, camera snapshots, or local ML inference results.
+{{% /notice %}}
+
 This design pattern enables efficient, on-demand data exchange with minimal bandwidth usage. This is ideal for edge computing scenarios where resources and connectivity are constrained.
 
+### Battery health estimation formula
+
 The health score is calculated using the following logic:
 
 ```rust
@@ -115,16 +121,15 @@ This formula estimates battery health as a percentage, considering both battery
 - battery: Current battery level (default 50%)
 - temp: Current temperature (default 25°C)
 
-The health estimation logic begins with the battery level as the baseline score. 
-If the temperature rises above 25°C, the score is adjusted downward—specifically, for every 2°C above this threshold, the health is reduced by 1%. 
+This logic computes battery health as a percentage, adjusting for elevated temperatures. If temperature exceeds 25°C, the score is reduced by 1% for every 2°C increase.
 
 To ensure the calculation remains safe even when the temperature is below 25°C, the code uses saturating_sub(25), which prevents the result from becoming negative and avoids potential underflow errors.
 
-For example, if battery = 88 and temp = 32, then:
+For example, if `battery = 88` and `temp = 32`, then:
 - Temperature offset = (32 - 25) / 2 = 3
 - Health = 88 - 3 = 85%
 
-### Step 3: Build and run
+### Build and run
 
 ```bash
 cd $HOME/zenoh/zenoh_battery_estimator
@@ -138,7 +143,7 @@ After the build process, you will see:
     Finished `release` profile [optimized] target(s) in 1m 22s
 ```
 
-### Step 4: Query it with parameters
+### Query it with parameters
 
 Run it on the Raspberry Pi you used for the build run: 
 
@@ -156,9 +161,9 @@ cd ~/zenoh/target/release/examples
 
 The result is shown below:
 
-![img4 alt-text#center](zenoh_ex4.gif "Figure 4: Dynamic Queryable with Computation")
+![img4 Estimated battery health query#center](zenoh_ex4.gif "Figure 4: Dynamic Queryable with Computation")
 
-The excepted output is:
+The expected output is:
 
 ```output
 >> Received ('robot/battery/estimate': 'Estimated battery health: 85%')