We’re living in 2026 and everyone knows that they can ask a large language model (LLM) a question and get an answer. But most people assume that requires an internet connection, because those LLMs live in massive data centers. The truth is that LLMs can run on local hardware, answering questions without any internet at all. Cameron Coward, of the Serial Hobbyism YouTube channel, took advantage of that fact, connecting an Arduino UNO Q to a vintage terminal.
That terminal is a Texas Instruments Silent 700 (Model 745), which is a paper terminal that was made in the 1970s. Back then, it would have been used as an input/output device for something like a minicomputer, connected through either an acoustic coupler (remote) or RS232 (local). Users would type commands on the keyboard and computer output would print on the thermal paper.
For this project, Coward connected the Silent 700 to his custom-built device, Termi3, to give it the ability to answer questions. The user types a question and a moment later, the terminal prints out the answer.
As the name suggests, Termi3 is the third version of the device. The first two required internet access, because they retrieved answers through the Wolfram Alpha API.
Termi3 doesn’t need any internet connection at all, because it generates an answer locally on an UNO Q (2GB). The Arduino runs a local LLM, Llama 3.2-1B, on the Linux side without ever touching a network. It interfaces with the terminal though bit-banging on the STM32 side, which goes through a MAX3232 transceiver (for level conversion) to the terminal’s RS232 port.
It is amazing that an LLM can run on the small and affordable UNO Q at all, especially with 2GB of RAM. So, the LLM isn’t particularly sophisticated and its answers aren’t always accurate — or even coherent. But they are often entertaining, which makes Termi3 a lot of fun to talk to.
Not a lot of thought went into the “mouse droid” in the first Star Wars movie. It was just a bit of cute world-building, created by putting a box on an RC car. But it became a fan favorite and that in-universe model, the MSE-6, appears throughout subsequent movies, TV shows, and video games. All of them, however, are identical. Cass, the maker behind Chaos Theory, imagined how mouse droids would actually fit into the world and the result is this MSE-6 that knows how to party.
According to the lore, billions of MSE-6 droids were built. For those living in the Star Wars universe, they wouldn’t be any more special than toasters or Huffy bicycles. It is only natural that individuals in that universe would customize mouse droids and Cass’ creation is an exploration of the kind of personalization that Sabine Wren would perform.
For those who aren’t deep into Star Wars lore, the simpler explanation is that this is an adorable mouse droid capable of navigating autonomously and features blinky lights, a radical paint job, and a rave mode. In that mode, it turns into a graffiti-covered mobile party machine that spins around while blasting music and flashing its lights.
Underneath the 3D-printed shell in that iconic shape, this is an Arduino UNO Rev3-controlled rover robot. It has a pair of motors, which the Arduino controls through an L298N driver. Power comes from a 7.4V lithium battery pack, with a buck converter to reach 5V. An ultrasonic sensor prevents collisions and the sound plays through a DFPlayer Mini MP3 module. Finally, arrays of 5mm red LEDs provide visual flair.
That all came together thanks to Cass’ fantastic paint job. She explains her inspiration, thought process, and supplies, but the great results are mostly attributable to her artistic talent. It is exactly the kind of mouse droid that Sabine Wren would adopt.
This Arduino UNO Q Headband Uses 13 Vibration Motors for Screen-Free Awareness Through Haptic Feedback
Maker pasquale887 developed HaloSense V1, an Arduino UNO Q-powered haptic headband using 13 vibration motors for screen-free awareness. It helps users sense directions, people, and objects through…
An SO-101 robot arm, originally a desktop toy, now picks and places rubber ducks by reasoning with a vision-language-action model. Dmitry Maslov’s project swaps the original brain for an Arduino VENTUNO Q board, which runs Hugging Face’s SmolVLA model locally. The result shows that robotics tasks combining vision and language, once confined to costly labs, now fit on a 299-dollar board.
Hardware: two processors on one board
The Arduino VENTUNO Q board has a dual nature. On one side sits an SBC system with a Qualcomm Dragonwing IQ8 processor, equipped with an Adreno 623 GPU and a Hexagon Tensor NPU, built for AI processing. On the other side is an STM32H5F5 microcontroller with an Arm Cortex-M33 core running at 250 MHz, which handles real-time servo control. The board offers 16 GB of LPDDR5 RAM and 64 GB of integrated eMMC storage.
The original SO-101 arm carries gearmotors on every joint and two cameras: one fixed overhead and one on the gripper. The images and joint position data go to the Dragonwing IQ8 processor, where the SmolVLA model interprets them. The model was trained with 50 demonstrations of the task of grabbing and moving the rubber ducks.
The SmolVLA model and the system’s numbers
SmolVLA is an open source vision-language-action model from Hugging Face. It processes the camera images and joint data, then produces the commands for the servo motors. All the processing happens locally on the VENTUNO Q board, with no connection to external services. The board costs 299 dollars, against 399 dollars for the Jetson Orin Nano Super Developer Kit, cited as a competitor.
Dmitry Maslov’s system points the way to accessible robotics. What’s more, the fact that the model runs on a commercial board costing less than 300 dollars opens up new scenarios for makers. For anyone who wants to see the project in action, Dmitry Maslov’s video shows the arm grabbing and moving the rubber ducks.
Arduino VENTUNO Q board with Qualcomm Dragonwing IQ8 processor and STM32H5F5
Hugging Face SmolVLA model running locally
50 demonstrations to train the pick-and-place task
Two cameras: one overhead and one on the gripper
16 GB of LPDDR5 RAM and 64 GB of eMMC storage
For anyone wanting to rebuild the project, the trickiest part is the integration between the SBC side and the microcontroller side of the board. The Dragonwing IQ8 processor runs the model, while the STM32H5F5 controls the servos. Communication between the two sides is essential to synchronise vision with movement.
This Open-Source DIY Drone Uses FMCW Radar and RTK GPS for High-Resolution SAR Imaging and Ground Mapping
This DIY open-source drone project by Henrik Forstén uses custom FMCW radar and RTK GPS for high-resolution Synthetic Aperture Radar (SAR) imaging and Interferometric SAR (InSAR) for detailed ground…
A recent article revealed that OpenAI is purchasing tens of thousands of Mac minis and Mac Studios to give AI agents dedicated environments to run, make mistakes, and learn. It’s a smart infrastructure decision for agents meant to operate inside a computer clicking, navigating, using software: they need a full computer to practice on. But it got us wondering: is that always the right environment for an agent?
Why agents need their own environment
An AI agent isn’t a chatbot. It perceives a situation, takes an action, observes the result, adjusts, and tries again – in a loop that requires a persistent local environment with compute, I/O, and feedback. You can’t outsource the whole thing to a cloud API, because the agent needs somewhere to live and something to interact with. In OpenAI’s situation, the answer is: give it a computer. That works well when the goal is teaching agents to use software. But software isn’t the whole world.
Physical AI needs something different (and surprisingly cheaper)
A Mac mini today starts at around $900. At the scale OpenAI is reportedly operating, the infrastructure bill is substantial. That cost is justified when you need a full computing environment. But what if the agent’s environment doesn’t need to be a general-purpose computer? What if it needs to be a temperature sensor, a camera feed, a production line?
At a fraction of the cost, an Arduino® VENTUNO Q board can provide a persistent Linux environment for the agent runtime, local AI inference, and direct access to real-world I/O: cameras, sensors, actuators. The economics of deploying agent environments at scale look very different when each node costs significantly less, and can be embedded directly in the physical context it’s meant to ultimately operate in.
What an Arduino agentic environment actually looks like
VENTUNO Q is built to combine a Linux-capable MPU with NPU acceleration and a dedicated real-time MCU on a single board. The Linux side is engineered to run the agent – its reasoning, its model, its decision logic. The MCU side is designed to connect it to the world: motors, sensors, cameras, industrial interfaces. No cloud dependency. No separate controller. One self-contained unit that perceives, decides, and acts.
Arduino® UNO Q is structured to extend this further as a low-cost remote node. David Groom demonstrated this clearly leveraging OpenClaw, developing an agent framework on UNO Q designed to enable agents to interact with physical hardware. By connecting to Arduino shields and accessing additional hardware capabilities, the framework supports physical-world interactions while enabling deployment across multiple units simultaneously, each maintaining its own context and operational role.
With these tools, it’s easy to envision a “swarm” model: VENTUNO Q built to serve as a local processing hub, with UNO Q units designed for distributed deployment as remote nodes, all supporting agent-based workflows that interact with physical environments rather than simulated ones.
More agents, more learning, lower cost
This is where the conversation becomes more interesting than individual compute specifications alone. Lower deployment costs can make broader deployment economically feasible, creating opportunities for more agent interactions, richer feedback loops, and exposure to a wider range of real-world operating conditions.
An agent that has operated across multiple physical environments, each with its own sensors, lighting conditions, and sources of noise, may be exposed to a broader set of inputs than an agent trained exclusively in software simulations.
Arduino can give agents something else to learn from: the physical world. By combining accessible hardware with scalable deployment models, Arduino platforms are designed to support the creation of large numbers of agent-enabled environments for experimentation, testing, and real-world interaction.
VENTUNO Q is also available on the Arduino Store or through our official distribution partners: DigiKey, Farnell, Kubii, Mouser, Robu.in, and RS, along with other authorized distributors and resellers.
Arduino, UNO, and VENTUNO, and the Arduino logo are trademarks or registered trademarks of Arduino S.r.l.
This project builds a basic electronic door lock with the Arduino UNO R4 WiFi. A touch sensor detects contact, a relay controls a solenoid lock, and an OLED display shows the system status. The principle is simple: touch the sensor, the door unlocks for 5 seconds, then locks itself again. It is a starting point for customizable smart locking systems.
The central board is the Arduino UNO R4 WiFi, which manages the whole flow. The touch sensor sends a signal to the board, which activates the relay to power the lock. The 128×64 pixel OLED display shows the startup, locked, and unlocked screens. The system uses a relay module to separate the control circuit from the power circuit, so the solenoid lock operates safely.
The circuit and components of the lock
Assembly requires few components: the Arduino board, the touch sensor, the OLED display, the relay module, and a solenoid lock. Everything connects on a breadboard with jumper wires. The relay is essential because the lock runs at 12 VDC, while the Arduino operates at 5 V. Without the relay, the lock’s current would damage the board.
The OLED display connects via I2C, using the SSD1306 and Adafruit_GFX libraries. The 128×64 pixel resolution is enough to show the system status with clear characters. The touch sensor connects to a digital pin: when it detects a touch, it sends a high signal to the Arduino. The response is immediate, and the relay trips right away.
The firmware and unlock time
The code is written in the Arduino IDE and uses the SSD1306, Adafruit_GFX, and Adafruit_SSD1306 libraries. The sketch reads the touch sensor state and, when it detects a touch, activates the relay. The display shows the unlock screen for 5 seconds, then the system locks the door again. The unlock time is fixed at 5 seconds, but it can be changed in the code.
The operation is cyclic: startup, waiting, unlock, relock. The OLED display updates the status in real time, so you always know whether the door is locked or unlocked. The project demonstrates the principle of a basic electronic lock, and the maker’s website collects the details for replicating it. It is a simple but complete system.
For assembly you also need a universal acrylic support to keep the Arduino and breadboard tidy. 15 cm male-to-female jumper wires help connect the modules without soldering. The project can be expanded with a numeric keypad, an RFID reader, or a Wi-Fi module for remote control.
In short, this project is an excellent base for anyone who wants to understand how an electronic lock works. The components are few, the code is essential, and the result is functional. With the Arduino UNO R4 WiFi you also have the option to add connectivity in the future, turning the prototype into a real smart lock.
An inexpensive robot kit with Arduino UNO Rev3, obstacle-avoidance sensors, and line-following capability becomes a face-tracking robot. The trick is in the control board: just replace the UNO Rev3 with an Arduino UNO Q, which has the same headers and mounts an STM32U585 microcontroller alongside a Linux microprocessor. Iulia Feroli’s project shows how local artificial intelligence can be added to a low-cost robot without touching the mechanics.
The robot starts from the Elegoo kit, with its motor shield and sensors for obstacle avoidance and line following. The UNO Q slots in place of the original board, and the shield moves over without any modification. Thanks to the STM32 microcontroller and the Linux microprocessor, the new board runs machine learning models locally, with no cloud connection. A standard USB webcam is connected to the UNO Q to provide vision.
Video stream and face tracking
The webcam video stream is processed with the face tracking Brick from Arduino App Lab. The code converts the face position in the frame into movement commands for the robot. The robot rotates to center the face and moves toward it, always staying in front of the person. The result is a responsive face tracker that requires no external servers or Wi-Fi connections.
Iulia Feroli’s project is documented in a video showing the robot in action, with an explanation of the assembly and the code. Swapping the board is the core of the intervention: the UNO Q maintains electrical and mechanical compatibility with the UNO Rev3 but adds the computing power needed for AI. In addition, the face tracking Brick in Arduino App Lab simplifies managing the machine learning model, making the code accessible even to those without neural network experience.
What you need to rebuild the project
To replicate the robot you need only a few components, all easily available. The list includes the Elegoo kit, a USB webcam, and the control board. Here are the main steps:
Remove the Arduino UNO Rev3 from the Elegoo kit and keep the motor shield.
Mount the Arduino UNO Q in its place, checking that the headers align.
Connect the USB webcam to the UNO Q port.
Upload the sketch with the face tracking Brick from Arduino App Lab.
Power the robot and test it in front of a face.
The UNO Q is the heart of the system: it combines the simplicity of the STM32U585 microcontroller with the power of the Linux processor. This combination allows local machine learning models, such as face tracking, to run without additional hardware. The board is also available in a 4GB version with a full accessory kit, which includes everything needed to get started.
The original Elegoo kit, with its Arduino UNO Rev3 board, remains an excellent base for other projects. However, for this face tracker, the UNO Q is the right choice: it offers the necessary computing power and maintains compatibility with the shield. The overall cost stays low, and the result is a smart robot that impresses with its responsiveness.
Let’s find out how to use the MAX7219 to drive an LED matrix. Wiring, Arduino libraries and sketches will guide us through building custom graphic and numeric displays.
An LED matrix display is one of the most fascinating components for anyone starting to experiment with Arduino: with a small square module we can bring to life numbers, letters, symbols and animations that immediately catch the eye. The problem? An 8×8 matrix means no fewer than 64 LEDs to control individually: an almost impossible task without dedicated support. That is where the MAX7219 chip comes in, an IC designed specifically to simplify the management of matrix and 7-segment displays, reducing the connection to the Arduino board to just a few pins. In this article we will see how to connect the MAX7219 to an 8×8 matrix, how to use the ready-made modules available on the market and how to program everything with the LedControl library.
The MAX7219
Fig. 1 Pinout of the chip and of the display.
The MAX7219 chip has 24 pins. The 8×8 display (Fig. 1) is connected so that the rows are linked to the DIG pins and the columns to the SEG pins of the MAX7219.
Brightness is varied in software after setting the maximum current with an external resistor connected to the Iset pin. Three pins are dedicated to communication with the control board: DIN (to transfer data from the board to the chip), CS (for device selection) and CLK (for the data clock). A further pin, DOUT, is used to connect the DIN of the next chip, in case you want to chain several LED matrices together (for example to build scrolling text).
The complete schematic of the connection between the chip and the display is shown in Fig. 2, with particular emphasis on the links to the Arduino board and to a second chip. Using the MAX7219 is made even simpler by the availability on the market of modules (such as those in Fig. 3) that integrate both the chip and the LED matrix, along with the relevant wiring.
Fig. 2 Schematic of the connection between the chip and the display.
Fig. 3 Schematic of the connection between modules and the Arduino board.
Using a module reduces the wiring to just the connections between the module and the Arduino board, and between modules possibly arranged in a chain. Each module has 5 input pins (VCC, GND, DIN, CS/LOAD and CLK, to be connected to a board such as the Arduino UNO R3) and 5 output pins (VCC, GND, DOUT, CS and CLK, for any subsequent modules in the chain). The Arduino UNO R3 board can be replaced by the more recent Arduino UNO R4 versions, available in the Minima and WIFI models, both fully compatible electrically and in software with the previous R3. Both versions keep the same pin layout and are compatible with most shields and libraries already developed for the R3.
Programming with Arduino
Several libraries make programming the MAX7219 easier; among them, in particular, the LedControl library, which is very widespread and simple to use.
An object of the LedControl class is created, to which an identifying name is assigned (for example, LC). The DIN, CLK and CS parameters will be replaced with the numbers of the Arduino pins (for example: 2, 4, 3) to which the respective signals are connected.
LC.SHUT (module_number, 0/1)
Enables or disables the chip. The value 0 makes it operational, while 1 puts it in standby. On power-up, the chip is in standby mode by default. The module_number parameter identifies the module in a serial chain, numbered starting from 0.
lc.setIntensity (module_number, intensity)
Adjusts the brightness of the LEDs, with a value between 0 (minimum) and 15 (maximum). The value 0 does not turn the LEDs completely off; to do that, you need to use LC.Shutdown(module_number, 1).
lc.clearDisplay (module_number)
Turns off all the LEDs of the specified module, clearing the displayed content.
Turns a single LED on or off. row_number and column_number indicate the position of the LED (numbered from 0 to 7). state = true (or 1) turns the LED on, false (or 0) turns it off. Rows are numbered from 0 (top) to 7 (bottom), columns from 0 (left) to 7 (right).
For example, the top-left LED occupies position (0, 0), the bottom-right one (7, 7).
lc.setRow (module_number, row_number, byte)
Lets you turn all the LEDs of a row on or off, specifying their state with a binary byte. For example, to turn on the first four LEDs of a row you use: B11110000.
lc.setColumn (module_number, column_number, byte)
Works in a similar way to setRow, but acts on a column. The byte defines which LEDs to turn on or off in the specified column.
Let’s now look at some practical examples of use.
Example 1
The first sketch, shown in Listing 1, is meant to display the 8 rows in sequence, one at a time, starting from the top; then the 8 columns, one at a time, starting from the left; then the 8 rows starting from the bottom; then the 8 columns starting from the right. Finally, all the LEDs are turned on gradually in pairs of rows, starting from the two middle rows and following the order: 4-5, 3-6, 2-7, 1-8. In this last phase, the lighting happens at low intensity, with brightness varying progressively from 10 to 2.
The first sketch lights up rows and columns of the matrix in sequence.
Example 2
The purpose of this sketch (Listing 2) is to gradually light up the LEDs of the matrix rows starting from the bottom, as a consequence of a voltage varying between 0 V and 5 V set by a potentiometer connected to pin A5; the comments inside the sketch describe how the gradual lighting works.
The second sketch lights the rows gradually as the potentiometer voltage changes.
Using arrays
The goals of the two previous examples can be achieved in a similar way using arrays. One approach is to define the row structure inside an array of bytes (for example in binary): with 8 elements of 8 bits you describe the LED states of the whole display. The first cell of the array corresponds to the state of the eight LEDs of row 0 (from left to right), the second to that of row 1, and so on up to row 7.
If, for example, you want to turn off all the LEDs of the first four rows and turn on those of the last four, you can use the following array:
The purpose of this sketch (Listing 3) is to display in sequence all the numbers between 0 and 9 using 10 arrays that define the numbers and 10 for loops that call them up.
The third sketch displays the digits 0 to 9 in sequence.
Example 4
The fourth sketch shows temperature and humidity thresholds on the matrix.
Fig. 4 Display of the temperature and humidity thresholds.
The purpose of this sketch (Listing 4) is to show when certain temperature and humidity thresholds (set in the program) are exceeded, as shown in Fig. 4.
In the left half of the display (columns 0-1-2) the temperature data is shown, while in the right half (columns 5-6-7) the humidity data is shown.
In the upper part of the display (rows 0-1-2) the letters T and U appear; in the lower part (rows 4-5-6-7) the lighting of the LEDs indicates that a given temperature or humidity threshold has been reached.
Four thresholds are defined in the code: as the value increases, the corresponding rows light up progressively, starting from row 7. Temperature and humidity are measured with the HTS221 sensor, integrated into the STMicroelectronics IKS01A3 expansion board (Fig. 5), mounted on the Arduino UNO board. Those who do not have this board can use other sensors, such as the DHT11 or DHT22, adapting the data acquisition part of the software accordingly.
Fig. 5 The IKS01A3 expansion board.
Conclusion
The MAX7219 makes LED matrix management accessible to everyone, turning a complex task into a fun, stimulating and creative experience. Once you understand the basic commands, the possibilities become practically endless: custom scrolling text, small animations, graphic indicators, simple light games and real-time data visualisations. All that is left is to experiment, adapt the sketches provided and let yourself be inspired: with a simple LED matrix your Arduino project can finally “speak with light” in a clear, dynamic and original way.
Physical AI needs a board that can think and act at the same time. This project pairs a Qualcomm Dragonwing IQ8 processor with an STM32H5 in a dual-brain architecture. The first runs AI models with 40 TOPS, while the second controls motors and peripherals in real time. The result is a complete platform for robotics and automation.
The board carries 16 GB of LPDDR5 RAM and 64 GB of eMMC storage. Connectivity includes tri-band Wi-Fi 6, Bluetooth 5.3, 2.5 Gb Ethernet, and CAN-FD. The board with integrated display from the Arduino UNO Q family offers a similar starting point for anyone approaching this world. The project board is open source and free of proprietary lock-ins.
How the dual-brain architecture works
The Qualcomm Dragonwing IQ8 processor handles the artificial intelligence. The STM32H5, on the other hand, guarantees deterministic control over motors, CAN bus, and other peripherals. The two processors communicate efficiently, so the AI can make decisions and the hardware executes without unpredictable latencies.
The preinstalled operating system is Ubuntu with an Ubuntu Pro license. The Arduino core runs on Zephyr RTOS, which offers guaranteed response times. In addition, the environment supports VS Code, PyCharm, Jupyter, and Docker for development.
AI models optimized for the NPU run through Arduino App Lab. The platform supports importing GGUF models from Hugging Face and training with Edge Impulse Studio. There are over 100 ready-to-use examples.
40 TOPS of AI power
16 GB LPDDR5 RAM
64 GB eMMC
Tri-band Wi-Fi 6 (2.4/5/6 GHz)
Bluetooth 5.3
2.5 Gb Ethernet
CAN-FD
Why a board for Physical AI is needed
Modern robotics requires perception, decision, and action in a single device. This board unifies everything in an open format. Makers can prototype with Arduino UNO shields and Raspberry Pi HATs. Moreover, ROS 2 support and the CAN-FD, I2C/I3C, SPI, PWM, and UART interfaces make it suitable for professional projects.
Compatibility with existing shields lets you reuse sensors and actuators you already own. For example, those with the more powerful processor board from the Raspberry Pi family can compare performance. In addition, the Works with Arduino program allows scaling prototypes to production level with certified SOMs from SECO and Toradex.
An open ecosystem for physical AI
The board uses Ubuntu Pro as its main operating system. Zephyr RTOS handles real-time hardware control. This mix ensures flexibility for development and robustness for execution.
Arduino App Lab is the access point for AI models. It supports importing from Hugging Face and training with Edge Impulse. There are also over 100 ready-made examples to get started right away.
The board is powered by a 65W USB-C power supply. It is designed for those who want to move from prototyping to production without changing platforms. Finally, support for Arduino shields and Raspberry Pi HATs makes it versatile.
For those starting out with embedded AI, the board with the STM32 microcontroller offers a simpler alternative. However, this board represents the next step for advanced robotics projects. Physical AI thus becomes accessible to makers, educators, and professionals.
