SlothMesh:Hacktoberfest Week 3 的 Arduino UNO Q 邊緣 AI 網絡監測原型
week 3 ( Hacktoberfest )
SlothMesh 是以 Arduino UNO Q 為基礎的開源邊緣 AI 原型,結合 TinyML 無線連線分類、Gemma 4 E4B 本地分析,以及用來限制模型建議的 Laya 決策層。
🦥 SlothMesh: Energy-Paced Edge AI with Gemma 4 on Arduino UNO Q
This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.
What I Built
What if your wireless network could detect problems, investigate what went wrong, and help choose a response without requiring you to constantly monitor dashboards or manually inspect network metrics?
That is the idea behind SlothMesh, an open-source edge AI prototype built around the Arduino UNO Q.
SlothMesh combines lightweight embedded machine learning with a locally running language model to explore a more efficient approach to wireless network monitoring and remediation.
The system has two complementary AI layers:
- TinyML on the Cortex-M33: A compact INT8 neural network classifies wireless link conditions as healthy, degrading, or critical.
- Local language-model reasoning: Gemma 4 E4B, a model with 4 billion effective parameters, is used in the current demonstration for higher-level analysis and diagnosis.
The goal is simple: detect cheaply, reason when needed, and keep decisions under deterministic control.
Instead of invoking a large language model for every telemetry observation, the architecture uses a lightweight classifier for routine monitoring and reserves more expensive reasoning for situations that need further investigation.
SlothMesh also includes a deterministic Laya decision layer intended to constrain model-generated recommendations and prevent unrestricted AI-controlled actions.
The project explores how edge AI can support network diagnostics while reducing unnecessary computation and avoiding mandatory dependence on a remote, paid AI API.
Demo
🎥 Watch the video demonstration: SlothMesh — Arduino UNO Q and Gemma 4
💻 Source code: github.com/yashwan7/uno-Q
The demonstration accompanies a repository containing the TinyML model, firmware, simulation workflows, an interactive dashboard, automated tests, and benchmarking scripts.
Run the project locally
Clone the repository:
git clone https://github.com/yashwan7/uno-Q.git
cd uno-Q
Install the development dependencies:
make setup
Run the automated tests:
make test
Launch the interactive simulation:
make demo
To start the web dashboard:
python3 -m http.server 8085 --directory dashboard
Open http://localhost:8085/ in your browser.
The repository also provides benchmark and power-analysis workflows:
make bench
make power
Reproducibility note: The checked-in quickstart and benchmark artifacts currently describe the earlier Qwen-based workflow. The Gemma 4 E4B demonstration is presented separately; the Qwen benchmark results below are not measurements of Gemma 4.
Code
The full project is open source:
GitHub repository: https://github.com/yashwan7/uno-Q
The repository is released under the MIT License.
Important components include:
-
models/train_slothmesh_tinyml.py— trains and quantizes the TinyML classifier. -
models/slothmesh_int8.tflite— the compact INT8 model. -
firmware/— Cortex-M33 firmware and the telemetry communication protocol. -
agent/sloth_agent.py— agent logic and constrained remediation workflow. -
agent/baseline_agent.py— the deterministic baseline. -
tests/— automated checks for the protocol, scaling, and decision logic. -
dashboard/— the interactive web interface. -
BENCHMARK.md— the model comparison and benchmark methodology. -
docs/POWER_MEASUREMENT.md— instructions for measuring physical power consumption.
The purpose is to make the system inspectable and reproducible rather than present an AI demo as an unexplained black box.
How I Built It
1. TinyML for fast wireless monitoring
The first layer is a compact INT8 neural network designed for the Arduino UNO Q's STM32U585 ARM Cortex-M33 microcontroller.
It evaluates six wireless telemetry features:
-
rssi_dbm— received signal strength. -
snr_db— signal-to-noise ratio. -
packet_error_rate— the proportion of unsuccessful transmissions. -
retry_count— transmission retries. -
channel_busy_ratio— the proportion of time the channel is busy. -
jitter_ms— variation in packet arrival timing.
The classifier produces one of three states: HEALTHY, DEGRADING, or CRITICAL.
The repository's recorded TinyML results are:
| Metric | Reported result |
|---|---|
| INT8 model size | 4,632 bytes |
| Tensor arena | 2 KB |
| Float32 test accuracy | 97.84% |
| INT8 quantized test accuracy | 97.48% |
| Accuracy change after quantization | −0.36 percentage points |
| Cortex-M33 inference latency | 1.18 ms |
These measurements and benchmark figures come from the repository's recorded model artifacts. The accuracy evaluation uses a session-based test set and should not be interpreted as guaranteed accuracy on every real-world network.
The training dataset contains 600,000 synthetically generated telemetry samples. A separate capture utility is included for collecting real wireless telemetry for future evaluation.
2. Two compute domains on the Arduino UNO Q
The UNO Q combines a Linux-capable Qualcomm Dragonwing QRB2210 application processor with an STM32U585 Cortex-M33 microcontroller. The 4 GB board provides LPDDR4 memory and 32 GB of eMMC storage. Arduino hardware specifications.
SlothMesh uses these compute domains for different jobs.
The microcontroller handles lightweight telemetry processing and TinyML classification, providing a fast path for routine link-health decisions.
The Linux application processor handles more complex tasks, including local language-model inference and higher-level analysis.
The intended pipeline collects wireless metrics through Linux networking interfaces, passes telemetry to the microcontroller through the project’s serial communication protocol, and uses the classification result to determine whether deeper analysis is warranted.
This division of work avoids making language-model inference the default response to every observation.
3. Gemma 4 E4B for local AI
The current video demonstration features Gemma 4 E4B, Google's edge-oriented Gemma 4 model with 4 billion effective parameters.
Gemma 4 supports reasoning and multimodal capabilities, with its smaller variants intended for resource-constrained devices. Official Gemma 4 documentation.
For SlothMesh, the language model's role is higher-level interpretation: helping analyze a concerning wireless state and formulate a possible explanation or remediation recommendation.
Running AI locally is valuable because it gives developers more control over their prompts, model deployment, and data flow without making a hosted proprietary API a requirement.
There is an important hardware consideration, however. The exact model artifact, quantization, and inference runtime determine whether Gemma 4 E4B fits within 4 GB of RAM. Google's documentation lists an approximately 2.2 GB memory requirement for its optimized mobile, text-only E4B configuration using LiteRT-LM. The standard model package offered through Ollama is substantially larger. These formats should not be treated as interchangeable.
For reproducibility, the model artifact and runtime used in the video should be documented alongside the deployment instructions.
4. Laya as the deterministic safety boundary
A language model should not have unrestricted authority to change network configurations or trigger hardware actions.
SlothMesh therefore uses a deterministic Laya decision layer to constrain suggested actions and provide predictable fallback behavior when the model diverges from the expected decision.
The repository includes an earlier benchmark comparing a rule-based baseline, an unconstrained Qwen 0.6B model, and the safety-constrained cascade across 52 standardized RF scenarios.
| Earlier benchmark configuration | Correct remediation decisions |
|---|---|
| Deterministic rules baseline | 50/52 (96.15%) |
| Unconstrained Qwen 0.6B | 39/52 (75.0%) |
| Qwen-based cascade with safety layer | 52/52 (100.0%) |
These results belong to the Qwen-based evaluation recorded in the repository, not to Gemma 4 E4B. The 100% figure represents performance on those specific benchmark scenarios, not a guarantee of production reliability.
The key engineering principle remains the same: model-generated reasoning should operate within an explicit and testable boundary.
5. The Slow and Steady approach to energy
The energy strategy is to minimize unnecessary work by combining an inexpensive embedded classifier with conditional higher-level reasoning.
The proposed monitoring design uses a five-second interval for the microcontroller's classification loop, with a reported inference latency of 1.18 ms.
The repository's power analysis estimates a 27% whole-board energy reduction relative to its chosen ten-second polling baseline. This is a modeled estimate, not a physically verified whole-board power measurement. The repository includes a procedure for measuring actual consumption on the hardware.
That distinction matters: an optimization should be presented as measured only when the corresponding physical measurements have been collected.
Why Does Open Innovation Matter?
Open innovation is central to SlothMesh because embedded AI systems need more than an impressive output. Developers should be able to inspect how data becomes a classification, how a recommendation is generated, and how the final action is constrained.
Using an open-weight language model allows the reasoning component to be deployed locally, subject to its model license and hardware requirements. The model, prompts, surrounding software, and decision logic can be evaluated and adapted instead of relying entirely on a remote black-box API.
The repository also exposes the TinyML training script, model artifact, firmware, telemetry protocol, tests, and benchmark workflows under an MIT License.
This matters in embedded development, where memory, computation, energy consumption, connectivity, and reliability shape what can realistically run on the device.
Open tools make it easier to compare architectures and answer a practical question: where does a language model add genuine value, and where is a small model or deterministic rule a better solution?
For SlothMesh, the answer is not to run the biggest model for every task. It is to use the right amount of computation for each stage.
My Agent Session
A separate shareable DevRelay agent-session URL is not included in this submission.
The public repository and video demonstration provide the main project references:
The Lazy Payoff
SlothMesh is designed to reduce the repetitive effort involved in diagnosing wireless link problems.
Instead of manually inspecting metrics, deciding whether the connection is deteriorating, and choosing whether further analysis is necessary, the system can automate the monitoring and classification stages.
The intended benefits are:
- Less manual inspection: the TinyML classifier evaluates telemetry automatically.
- Less unnecessary reasoning: higher-level inference can be reserved for concerning situations.
- More predictable decisions: the deterministic layer constrains model-generated recommendations.
I have not yet measured end-to-end human troubleshooting time saved in a real deployment, so I am not claiming a specific number of minutes saved per incident.
The current project focuses on embedded inference, model evaluation, reproducible scenarios, and an energy-aware architecture. The next step is to validate the complete workflow against real wireless traffic and physically measured whole-board energy consumption.
Prize Categories
Best Use of Arduino
SlothMesh uses the Arduino UNO Q's Linux application processor and Cortex-M33 microcontroller as complementary compute domains, combining embedded machine learning with local open-weight AI and a deterministic decision layer.
The project fits the Slow and Steady theme by using lightweight inference for routine monitoring and reserving more expensive reasoning for situations that need it.
Final Thoughts
SlothMesh started with a simple idea: an edge AI system should know when to act, when to reason, and when to do less.
By combining TinyML, local language-model inference, and deterministic decision-making, the project explores a practical architecture for AI-assisted wireless diagnostics on embedded hardware.
There is still work to do, particularly around real-world RF validation, reproducible Gemma deployment details, and physical energy measurements. Publishing the code and documenting the limits of the current results gives other builders a foundation they can test, challenge, and improve.
Sometimes, the smartest system is not the one that thinks the most. It is the one that knows when it can do less. 🦥
Project: SlothMesh on GitHub
Video demo: Watch on YouTube
Challenge: Hacktoberfest Open-Source AI Challenge — Week 3
hacktoberfest #hf26challenge #opensource #ai #arduino #machinelearning #edgeai
來源:DEV Community · dev.to