Arduino UNO Q 2GB vs. 4GB - any difference?

I would like to extend my thanks to Mr. Chaiwat from INEX for providing the 4GB version of the Arduino UNO Q for testing. I wanted to take this opportunity to compare it with the previously released 2GB model to see exactly how they differ.

1st Step: Starting with a Clean Install

While the raw processing performance is identical since both models utilize the same QRB2210 and STM32U585 chips, the doubling of both RAM and eMMC storage is expected to significantly benefit AI-related tasks, which are notoriously resource-intensive. To accurately compare the baseline resources available on a brand-new board, I began by performing a clean firmware installation.

Arduino provides a utility called arduino-flasher-cli for downloading and installing the system image onto the eMMC. To prepare the board for flashing, you must use a jumper to short the first pair of pins on the header, as shown in the reference image.

Warning: Do not proceed with this if you do not understand that all existing files and code will be permanently erased.

The Flashing Process:

• Connect the USB cable to the UNO Q board with the jumper installed.
• Open a terminal window and execute the following command: arduino-flasher-cli flash latest.
• The program will begin downloading the image.

At the time of writing this blog, the Debian image (version 20251229) is approximately 2.4GB.

Important Note: This method acts like formatting a hard drive. I only recommend this if your Debian system software is corrupted beyond repair: an issue I personally encountered after attempting to install Python libraries via pip, which caused conflicts with the original Arduino App Lab libraries.

Once the firmware is flashed, the next step is to remove the jumper and power-cycle the board (which is just a fancy way of saying unplug and replug the USB cable). I then opened the App Lab software to configure the essentials: giving the board a name and setting up the WiFi credentials. One thing to note is that App Lab needs to update several software components, like Docker image layers, before it lets you start writing code which can be a bit of a wait, but it's a necessary step to ensure everything is current.

2nd Step: Resource Monitoring: 2GB vs. 4GB

This is where the hardware differences really start to show. After the updates were finished, I checked the baseline resource usage for both boards.

On the Arduino UNO Q-2G, the system utilized about 0.4–0.5 GB of RAM out of its total 1.7 GB. The root partition of the eMMC was already 70% full, leaving about 3 GB available, with another 3 GB remaining in the /home/arduino directory.

The Arduino UNO Q-4G, however, feels much more spacious. While it used the same 0.4–0.5 GB of RAM at idle, it had a total pool of 3.6 GB to work with. Even though its root partition was also at 70% capacity, the larger eMMC meant that the /home/arduino section had over 17 GB of free space. This extra headroom is exactly what you need once you start working with larger AI models or complex datasets.

3rd Step: The Blink LED Example

To see the system in action, I started with the Blink LED example, which demonstrates the communication between the QRB2210 and the STM32U585. This particular example is quite lightweight because it doesn't require a "Brick" (the pre-defined instruction sets for Docker containers). When you click 'Run, ' the Debian side downloads the necessary Arduino libraries, builds the MsgPack, and uses OpenOCD to flash the firmware to the STM32U585. Seeing that red LED blink for the first time confirms the RPC bridge is working perfectly. Since the Python code is simply passing commands through this bridge, I didn't see any significant changes in RAM or eMMC usage during this test.

After the basic Blink test, I moved on to the Blink LED with UI example. This one utilizes a WebUI Brick, which allows you to build a web-based interface for your project. One thing to keep in mind with App Lab is that it doesn't allow multiple apps to run simultaneously, so I had to stop the basic Blink app before starting this one. Even with the UI layer active, the RAM and eMMC usage barely budged, likely because the libraries involved are very lightweight. The real test came with the AI-focused examples: Classify Image and Object Detection. These use specialized AI Bricks. Interestingly, RAM usage only bumped up to about 0.6 GB, while eMMC usage remained stable. This suggests that for running the built-in examples, even the 2GB UNO Q model handles everything quite comfortably.

4th Step: Custom Apps and Library Management

Since the example files are read-only, I cloned one into my own workspace located at /home/arduino/ArduinoApps. To see how much of the heavy lifting was already done for us, I tried importing cv2 (OpenCV). To my surprise, the eMMC usage didn't spike, which confirms that the base system image already includes most of the essential AI and container libraries you'd need. But what if you need something that isn't pre-installed? I tried adding popular AIoT libraries like Pandas, Matplotlib, Scikit-learn, and TensorFlow. While OpenCV and Pandas were already there, others threw errors at startup. The fix is quite clever: just like with Docker, you can add a requirements.txt file to your Python folder. The system uses uv, a modern project and package tool that is much faster than pip, to prepare the libraries. It creates a virtual environment in a .cache folder before transferring everything to the Docker container. This process used about 2 GB of space in the /home/arduino directory. It’s a very smooth way to handle external dependencies that Arduino has provided for us.

5th Step: ROS Integration and Storage Constraints

For projects that require a more complex setup, I followed a guide from GitHub to install ROS within a standalone Docker container. This test revealed a critical bottleneck. During the installation, I watched the root (/) partition shrink by 1.86 GB, while the /home/arduino directory stayed almost the same. On the UNO Q, the root partition is fixed at 10 GB, and a large chunk of that (70%) is already taken up by the system image. This is a potential pain point for both the 2GB and 4GB models if you aren't careful with how you install software.

I ran into even more trouble when trying to use pip3 to install additional Python libraries. The system warned me to use apt instead, but doing so further depleted the root partition, leaving me with only 1.56 GB of free space. This is where the 4GB model really starts to show its worth, not just because of the RAM, but because its larger overall eMMC gives us a way to solve this storage crunch.

6th Step: Re-routing Docker Storage

To keep the system from running out of space, I found a safer workaround: moving the Docker data-root from the cramped root partition to the much larger /home/arduino directory. If you’re hitting storage limits, I highly recommend this process:

• Create a new directory: sudo mkdir -p /home/arduino/docker-data/.
• Stop Docker services: Stop both the docker.service and docker.socket.
• Update the config: Edit /etc/docker/daemon.json and add the line "data-root": "/home/arduino/docker-data".
• Sync the data: Use rsync command (need apt install here) to move your existing Docker files to the new location.
• Clean up: After verifying the move with docker info, you can safely delete the old /var/lib/docker backup.

After performing this move, my root partition's free space jumped back up to 5.6 GB, which is plenty for general software packages. Meanwhile, on the 4GB model, I still had 14.7 GB left in my home directory to play with.

Final Verdict

Looking at the software design of the Arduino UNO Q, it’s clear that engineers didn't intend for us to treat the Debian side like a standard Linux PC where you just apt install everything. They want us to keep the core system lean and use Docker containers for the heavy lifting. If you plan on sticking to the provided App Lab examples, the 2GB model is perfectly capable. However, if you want the freedom to build custom, complex AI applications or integrated ROS projects without constantly worrying about storage limits, the 4GB model is the clear winner. Having nearly 20 GB of usable space makes a world of difference for any serious developer.