Why the Arduino Uno Q Deserves a Place on Your Bench
Arduino Uno Q projects are real-world builds that combine a Debian Linux processor with a classic STM32 microcontroller so you can run full applications and still drive precise hardware control at the same time.
If you have ever felt boxed in by traditional microcontroller applications, the Arduino Uno Q feels like someone opened a side door. On one side you get a Qualcomm QRB2210 microprocessor running Debian Linux with networking, Docker, Python, and everything you would expect from a small server; on the other, an STM32U585 microcontroller behaves like a familiar Arduino sketch runner and GPIO driver. The two sides do not share memory or a network stack; they pass messages through a dedicated Router Bridge.
In this article, I will walk you through three practical Arduino Uno Q projects: embedded robotics control with a humanoid robot, secure transaction signing with a dedicated device, and home automation MQTT control of the onboard LED. The only real prerequisite is that you are comfortable switching between Linux command-line work and microcontroller sketches. If you can SSH into a board and upload a sketch, you are ready.
Project 1: Sonnet Humanoid Robot – Embedded Robotics Control in Two Brains
The Sonnet humanoid robot is a textbook example of using the Uno Q for embedded robotics control. On the STM32 real-time side, the robot sketch talks only to physical hardware: DC motors, arm servos through a PCA9685 driver, two ultrasonic sensors, an IR gripper sensor, and the onboard LED matrix. It does no thinking; instead, it waits for commands from a Python program running on the Linux half of the same board and carries them out over the Router Bridge.
This separation is the main pattern to copy: Linux plans and coordinates, while the microcontroller executes time-sensitive motion and sensing. According to the project code comments, the robot includes a safety watchdog that stops the motors if the Linux side goes quiet for more than a defined timeout while driving, so it never runs forever on a stale command. The grab and take arm choreography is converted from blocking delays to a non-blocking timer so sensors keep updating, and each gripper action immediately checks the IR sensor to confirm whether the object was actually gripped.
The gotcha when you adapt this pattern is remembering that watchdogs and safety logic must live on the MCU side. The Linux brain can crash or lose power, and your robot still needs to fail safe. Once you respect that boundary, the dual-core setup lets you push far beyond typical microcontroller applications: Python can handle higher-level AI or planning, while the STM32 guarantees smooth, deterministic motion.
Project 2: Agent-Q – A Dedicated Device for Secure Signing
The second pattern is about security: separating the system that prepares an action from the system that authorizes it. Agent-Q explores this boundary using M5Stack hardware as a Sui signing device. AI agents and local apps can plan tasks, call tools, prepare transactions, operate local apps, and trigger workflows, but they should not automatically sign what they create.
In the Agent-Q design, a local host process relays a bounded signing request to the device, yet it stores no signing material and cannot approve its own request. The device checks the request against device-local state, applies a policy gate or asks for device-local confirmation, and focuses on the shape of Sui Programmable Transaction Blocks: it can inspect Move calls, inputs, type tags, recipients, token facts, amounts, and balance sources when those details are available. If required facts are missing or the transaction shape is unsupported, the device fails the request closed instead of trusting a host UI, RPC response, dry run, or agent explanation.
If you adapt this idea to the Arduino Uno Q, the pattern is the same: keep long-running networking and AI agent workflows on the Linux side, but move key storage, policy checks, and final authorization into the microcontroller domain. The main trap is convenience—there is always the temptation to log or cache secret material on the host. Resist that, and use the dual-core split as a hardware-enforced line between noisy automation and quiet, auditable signing decisions.
Project 3: Home Assistant on Uno Q – Home Automation MQTT for LED and Beyond
The third project turns the Uno Q into a small home automation hub. The goal is clear: end with Home Assistant running in Docker on the Linux side, an MQTT broker bridging Linux and the STM32 microcontroller, and a working example where toggling a switch in your Home Assistant dashboard turns the Uno Q’s onboard LED on and off, with the LED entity appearing automatically without manual dashboard configuration.
Before you begin, you need an Arduino Uno Q, a USB-C cable, a computer on the same network to SSH into the Linux side and view the Home Assistant dashboard, and Arduino App Lab installed on your computer. The nice twist: you do not need any extra components, because the base tutorial controls the onboard LED. On the Linux side, Home Assistant runs in its own container, while Mosquitto runs in another; `docker run` launches Mosquitto, binding port 1883 and mounting config and data directories so you have a proper MQTT broker for home automation MQTT workflows.
- SSH into the Uno Q’s Linux side, note the IP address with `hostname -I`, and keep it handy for both SSH and the Home Assistant dashboard.
- Install and run Home Assistant in Docker on the Linux side so it can use the Uno Q as a small server for your smart home.
- Install and run an MQTT broker (Mosquitto) as a separate container, exposing port 1883 and storing its config and data under your home directory.
- Configure Home Assistant’s MQTT integration to point to the broker’s IP and port so it can publish and subscribe automations over MQTT.
- Write a Python script on the Linux side that listens to MQTT topics and forwards messages across the Router Bridge to an MCU sketch, which drives the onboard LED.
- Upload an STM32 sketch that subscribes to Router Bridge messages and toggles the LED pin so Home Assistant switch changes are reflected in hardware.
Two pitfalls stand out in this chain. First, do not assume the IP address is static; if DHCP changes it, re-run `hostname -I` before debugging anything, because a stale IP is a very common cause of nothing working. Second, Mosquitto’s default configuration in version 2.x blocks non-local or anonymous connections; without adding a listener and `allow_anonymous` configuration, Home Assistant’s MQTT integration fails even though the port is open. Another easy trap is to point your App Lab Python app at `localhost` when connecting to MQTT; the container runs on its own isolated Docker network, so `localhost` there refers only to that container, and you will see `ConnectionRefusedError: [Errno 111] Connection refused` until you use the proper broker address.
Why These Three Projects Show the Uno Q’s Range
Looking across these three Arduino Uno Q projects, a pattern emerges: the board’s dual-core architecture lets you handle things that used to demand separate machines. On the robotics side, the Linux processor runs higher-level logic while the STM32 sketch concentrates on motors, servos, ultrasonic sensors, IR sensors, and an LED matrix, staying in the realm of tight, predictable timing. On the security side, you can split AI agents and transaction preparation from signing, so the system that prepares an action does not automatically authorize it. And in home automation, Home Assistant and an MQTT broker live on the Linux half while the STM32 drives GPIO through the Router Bridge, giving you a clean chain from dashboard to LED.
The key takeaway: treat the Uno Q as two cooperating systems rather than a single board. Keep networking, Docker, and heavy logic on the Linux side, and reserve the microcontroller for real-time I/O, safety, and final decisions. It is worth the extra mental step because this split lets you grow beyond simple microcontroller applications into full robots, secure signing devices, and serious home automation MQTT setups on a single board.
