Update with single repo approach

Author: annietllnd

content/learning-paths/embedded-and-microcontrollers/device-connect-strands/_index.md

@@ -22,7 +22,9 @@ prerequisites:
     - Basic familiarity with Python virtual environments and command-line tools.
     - (Optional) A Raspberry Pi for testing a full infrastructure setup
 
-author: Annie Tallund
+author: 
+    - Annie Tallund
+    - Kavya Sri Chennoju
 
 
 

content/learning-paths/embedded-and-microcontrollers/device-connect-strands/background.md

@@ -73,3 +73,5 @@ By working through the remaining sections you will:
 - Optionally extend the setup to a Raspberry Pi connected over the network, discovering and commanding it from your laptop through the Device Connect infrastructure.
 
 The next section covers the environment setup.
+
+TODO: add links to the Strands Robots docs, mesh.md, pypi?, 

content/learning-paths/embedded-and-microcontrollers/device-connect-strands/run-example.md

@@ -29,10 +29,10 @@ You will need two terminal windows open at the same time: one to keep the simula
 | Host or Target | 1 | Simulated robot — keep running throughout |
 | Host | 2 | Agent tool invocations |
 
-Make sure you are in the workspace directory you created during setup and that your virtual environment is activated:
+Make sure you are in the repository directory and that your virtual environment is activated:
 
 ```bash
-cd ~/strands-device-connect
+cd ~/strands-device-connect/redacted
 source .venv/bin/activate
 ```
 
@@ -45,18 +45,21 @@ python <<'PY'
 import logging
 logging.basicConfig(level=logging.INFO)
 from strands_robots import Robot
-Robot('so100')
+r = Robot('so100')
+r.run()
 PY
 ```
 
-When the `Robot('so100')` object is created, the SDK downloads the MuJoCo physics model for the SO-100 arm (this download happens only on the first run and takes a minute or two), then starts the simulation and registers the robot on the Device Connect device mesh. The robot publishes a presence heartbeat every 0.5 seconds under a unique device ID, for example `so100_sim-abc123`.
+When the `Robot('so100')` object is created, the SDK downloads the MuJoCo physics model for the SO-100 arm (this download happens only on the first run and takes a minute or two), then starts the simulation and registers the robot on the Device Connect device mesh. The robot publishes a presence heartbeat every 0.5 seconds under a unique device ID, for example `so100-abc123`.
 
 You should see INFO-level log output similar to:
 
 ```output
-INFO:strands_robots.mesh:Zenoh session started
-INFO:strands_robots.mesh:Peer ID: so100_sim-abc123
-INFO:strands_robots.mesh:Heartbeat thread started
+device_connect_sdk.device.so100-a3f1b2 - INFO - Using ZENOH messaging backend
+device_connect_sdk.device.so100-a3f1b2 - INFO - Connected to ZENOH broker: []
+device_connect_sdk.device.so100-a3f1b2 - INFO - Driver connected: strands_sim
+device_connect_sdk.device.so100-a3f1b2 - INFO - Subscribed to commands on device-connect.default.so100-abc123.cmd
+🤖 so100-abc123 is online. Ctrl+C to stop.
 ```
 
 Leave this process running. The simulated robot is only discoverable as long as this process is alive.
@@ -79,9 +82,9 @@ PY
 The output is similar to:
 
 ```output
-Found 2 robot(s):
-  so100_sim-abc123 — idle
-  so100_sim-def456 — idle
+Discovered 1 device(s):
+  [robot] so100-lab-1 — idle
+    Functions: execute, getFeatures, getStatus, reset, step, stop
 ```
 
 The peer ID (for example `so100_sim-abc123`) is assigned at startup and changes each run. Note the actual ID shown in your terminal - you will need it in the next step.
@@ -105,7 +108,8 @@ PY
 You will see the following output:
 
 ```output
-Result: {'success': True, 'result': {'status': 'success', 'content': [{'text': "🚀 Policy started on 'so100' (async)"}]}}
+-> so100-lab-1: pick up the cube
+  {"status": "success", "content": [...]}
 ```
 
 {{% notice Robot output in terminal 1 %}}
@@ -158,7 +162,10 @@ if devices:
         'execute',
         {'instruction': 'pick up the cube', 'policy_provider': 'mock'},
     )
-    print(f'Result: {result}')
+    print(f'Execute result: {result}')
+
+    status = invoke_device(devices[0]['device_id'], 'getStatus')
+    print(f'Status: {status}')
 PY
 ```
 
@@ -173,8 +180,9 @@ The output is similar to:
 
 ```output
 Found 1 robot(s):
-  so100_sim-abc123
-Result: {'success': True, 'result': {'status': 'accepted'}}
+  so100-lab-1 — idle
+Execute result: {'success': True, 'result': {'status': 'success', 'content': [...]}}
+Status: {'success': True, 'result': {...}}  # full sim state dict
 ```
 
 ## What you've accomplished and what's next

content/learning-paths/embedded-and-microcontrollers/device-connect-strands/run-infra-example.md

@@ -10,7 +10,9 @@ layout: learningpathall
 
 The previous section ran entirely on a local network, with Device Connect handling device-to-device discovery automatically. That approach is fast and requires zero configuration, but it has natural limits: both the robot and the agent must be on the same LAN, device state is ephemeral, and there is no registry you can query by device type.
 
-This section goes one step further. You will run the Zenoh router, an etcd state store, and a registry service on your machine using Docker, then connect a Raspberry Pi on the same network as the remote device. The agent running on your machine will discover the robot running on the Pi through the infrastructure, as if both were part of the same managed fleet. The Pi never needs to run Docker — it just needs Python and the packages from setup.
+This section goes one step further. You will run the Zenoh router, an etcd state store, and a registry service on your machine using Docker, then connect a Raspberry Pi on the same network as the remote device. You can use a different device as long as you can access it, but the Raspberry Pi will be used as an example. This device is also referred to as the target.
+
+The agent running on your machine will discover the robot running on the Pi through the infrastructure, as if both were part of the same managed fleet. The Pi never needs to run Docker — it just needs Python and the packages from setup.
 
 Confirm Docker and Docker Compose v2 are available on the host before continuing:
 
@@ -19,6 +21,14 @@ docker --version
 docker compose version
 ```
 
+## Clone and bring up the Docker image
+
+```bash
+cd ~/strands-device-connect
+git clone --depth 1 https://github.com/arm/device-connect.git
+
+```
+
 ## Machine and terminal layout
 
 This section involves two machines. Keep track of which commands run where:
@@ -36,6 +46,7 @@ In host terminal 1, bring up the Device Connect infrastructure stack. The Compos
 ```bash
 cd ~/strands-device-connect/device-connect/packages/device-connect-server
 docker compose -f infra/docker-compose-dev.yml up -d
+cd ../../..
 ```
 
 Confirm the services are healthy:
@@ -71,7 +82,7 @@ Note the address returned — for the rest of this section it is referred to as
 
 ## Step 3 — Prepare the Raspberry Pi
 
-On the Raspberry Pi, follow the same repository and environment setup from the setup section of this Learning Path: install Python 3.12, clone both repositories, create the virtual environment, and install the packages with the same editable install commands.
+On the Raspberry Pi, follow the same repository and environment setup from the setup section of this Learning Path: install Python 3.12, clone the `redacted` repository, create the virtual environment, and install the packages with the same editable install commands.
 
 Once the environment is ready, export the three variables that tell the SDK to route traffic through the Device Connect router on your host rather than using local network discovery:
 
@@ -92,7 +103,8 @@ python <<'PY'
 import logging
 logging.basicConfig(level=logging.INFO)
 from strands_robots import Robot
-Robot('so100')
+r = Robot('so100')
+r.run()
 PY
 ```
 

content/learning-paths/embedded-and-microcontrollers/device-connect-strands/setup.md

@@ -17,24 +17,14 @@ git --version
 
 These instructions are tested on Python 3.12. Earlier versions of Python 3 may work but are not validated against the `redacted-branch` branch used in this Learning Path.
 
-## Clone the repositories
+## Clone the repository
 
-You need two repositories. The `device-connect` contains the SDK and agent tools as local packages. The `redacted` repository contains the robot runtime and the `robot_mesh` Strands tool.
+The code run in this Learning Path sits in the `redacted` repository. It contains the robot runtime and the `robot_mesh` Strands tool.
 
 ```bash
-mkdir -p ~/strands-device-connect
-cd ~/strands-device-connect
-
+mkdir ~/strands-device-connect
+cd strands-device-connect
 git clone https://github.com/redacted
-git clone https://github.com/arm/device-connect.git
-```
-
-After cloning, your workspace should look like this:
-
-```output
-~/strands-device-connect/
-├── device-connect/
-└── redacted/
 ```
 
 ## Check out the integration branch
@@ -44,7 +34,7 @@ The Device Connect integration code for `redacted` lives on the `redacted-branch
 TODO: remove feature branch? replace redacted and redacted-branch
 
 ```bash
-cd redacted
+cd ~/strands-device-connect/redacted
 git checkout redacted-branch
 cd ..
 ```
@@ -58,17 +48,13 @@ python3.12 -m venv .venv
 source .venv/bin/activate
 ```
 
-Now install the packages:
+Now install the packages and make sure they are available on your `PYTHONPATH` environment variable:
 
 ```bash
-pip install --upgrade pip setuptools wheel hatchling hatch-vcs
-pip install -e device-connect/packages/device-connect-sdk
-pip install -e "device-connect/packages/device-connect-agent-tools[strands]"
-pip install -e "redacted[sim]"
+pip install -e ".[sim]"
+export PYTHONPATH="$PWD:$PYTHONPATH"
 ```
 
-TODO: simplify commands?
-
 ## How discovery works — no configuration needed
 
 The `strands-robots` SDK uses Device Connect's built-in device-to-device discovery: every `Robot()` instance announces itself on the local network at startup, and any process running `discover_devices()` or `robot_mesh(action='peers')` on the same network segment will find it automatically.