Omar SobhandClaude Opus 4.8
62c435c648
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]>
2.2 KiB
2.2 KiB
name, description
| name | description |
|---|---|
| bridge | 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) —
.inosketches; 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
- Runtime GPIO via the deployed Bridge app — use the
gpio_read/gpio_writetools. These talk to the uno-q-bridge app (TCP :9999) that must already be running on the board (zeroclaw peripheral setup-uno-qdeploys it). Good for toggling pins on a sketch that is already flashed. - Flash a whole sketch — use
uno_q_flash(see theflashingskill) to compile and program a full.ino, including one that#include <Bridge.h>and exposes its own RPC services.
Sketch side (MCU)
#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 forarduino:zephyr:unoq. Network access is the MPU's job, reached via Bridge. gpio_read/gpio_writerequire the bridge app running; if they error with a connection failure, the app isn't up.