feat(uno-q): bundle the granular skill set alongside arduino-uno-q on every node

Vendors the fork's 11 granular UNO Q skills (bridge, flashing, led-matrix, uno-q-hardware, sketch-patterns, modulino, linux-led, audio, vision, wireless, arduino-app-lab) next to the comprehensive arduino-uno-q skill, and installs the whole set into every agent's workspace on each board. Why both: the comprehensive skill is the rich cloud reference (read_skill → references); the granular skills are keyword-triggered and match the fork's eager skill-inliner rules, so the on-board Qwen auto-inlines them (no read_skill round-trip). flashing + led-matrix carry the exact uno_q_flash + frame-API / ArduinoGraphics-not-installed detail that makes flashing reliable. - push-skill.sh generalized: a single skill dir (has SKILL.md) OR a parent dir installs every skill under it; provision-fleet now ships all of skills/. - Verified on board 65301572: cloud/Sonnet-5 lists all 12 skills. Co-Authored-By: Claude Opus 4.8 <[email protected]>
2026-07-16 09:32:11 -07:00
parent d2135a1938
commit 62c435c648
14 changed files with 555 additions and 37 deletions
@@ -0,0 +1,50 @@
+---
+name: bridge
+description: Arduino Bridge — the RPC layer that lets Python on the Uno Q's Linux side (MPU) call functions on the Arduino sketch (MCU) and vice-versa. Load this before any project that combines a Python program with an Arduino sketch, or asks how to send data between the Linux side and the sketch.
+---
+
+# Bridge — Inter-Processor RPC on the Uno Q
+
+The Uno Q is two computers on one board:
+
+- **MPU** (QRB2210, Debian Linux) — Python, web servers, AI models, OpenCV, Wi-Fi.
+- **MCU** (STM32U585, Zephyr + Arduino) — `.ino` sketches; owns every Arduino
+  header pin (digital, PWM, ADC, I²C, SPI, UART, CAN).
+
+**Bridge** is Arduino's software RPC layer so either side can call the other.
+The MCU has **no Wi-Fi and no Linux**; the MPU has **no direct Arduino pins**. Use
+Bridge whenever a project needs *both* sides.
+
+## When to use Bridge
+
+| Scenario | Why |
+|---|---|
+| Python reads a sensor wired to A0 | MCU owns the pin → Python calls the MCU |
+| Sketch needs internet/weather data | MCU has no Wi-Fi → MCU calls the MPU |
+| An AI model on Linux drives an LED | Python runs the model → calls the MCU |
+| Sketch streams data to a web dashboard | MCU samples → MPU serves HTTP/WebSocket |
+
+## Two ways to reach the MCU from ZeroClaw
+
+1. **Runtime GPIO via the deployed Bridge app** — use the `gpio_read` / `gpio_write`
+   tools. These talk to the uno-q-bridge app (TCP :9999) that must already be
+   running on the board (`zeroclaw peripheral setup-uno-q` deploys it). Good for
+   toggling pins on a sketch that is already flashed.
+2. **Flash a whole sketch** — use `uno_q_flash` (see the `flashing` skill) to
+   compile and program a full `.ino`, including one that `#include <Bridge.h>` and
+   exposes its own RPC services.
+
+## Sketch side (MCU)
+
+```cpp
+#include <Bridge.h>
+void setup() { Bridge.begin(); }
+void loop()  { /* expose services / handle calls */ }
+```
+
+## Pitfalls
+
+- The MCU has **no Wi-Fi peripheral** — `#include <WiFi.h>` will not compile for
+  `arduino:zephyr:unoq`. Network access is the MPU's job, reached via Bridge.
+- `gpio_read`/`gpio_write` require the bridge app running; if they error with a
+  connection failure, the app isn't up.