Email me
Raspberry Pi 5 vs Radxa Q6A
← Self-balancing robot

How it works

Raspberry Pi 5 vs Radxa Q6A

Why I chose a newer and less established SBC for the self-balancing robot.

Yahboom sells a micro-ROS version of the kit with some extra functionality, but I wanted to take the project further. My longer-term plans include vision, voice interaction and path planning, so I needed a single-board computer that could handle the higher-level work while the STM32 concentrated on balancing.

Selecting an SBC

I originally intended to use a Raspberry Pi 5. I already own an 8 GB Pi 5 that I used with a SunFounder PiCar-X kit, but it is now being used for several other projects, including automating Garage Dreams. That was an automotive website I ran, and I am now using local and paid models to create and review articles based on material I originally wrote.

The Pi 5 seemed like the obvious choice for this robot. It has a large community, good peripheral support and plenty of information about running local LLMs. The problem was price. When I looked at buying another one, the local price was nearly three times what I had paid for mine about a year earlier. That was pretty difficult to justify, so I had a search for other options.

The Radxa Q6A selected for higher-level compute

After some searching, I came across the Radxa Dragon Q6A. It was a much newer and less established board, but the specifications looked interesting. The model I chose has 12 GB of RAM, compared with 8 GB in my Pi 5, and its Qualcomm QCS6490 includes a Hexagon AI accelerator rated at up to 12 TOPS.

The Q6A also uses 12 V USB-C Power Delivery. That gives me more options for powering it from a compatible USB-C PD supply or power bank, although it still needs a source that supports the correct 12 V profile. It cannot be powered from just any USB-C connection.

The obvious trade-off is the ecosystem. Raspberry Pi has far more tutorials, accessories and community knowledge. The Q6A documentation and software support are still developing, and getting the NPU working with a local LLM looks as though it may become a project of its own (I have got an llm working, just not on the NPU).

That is also part of the appeal. I thought it would be fun to try something less established and document the problems as I work through them. If that documentation helps someone else later, even better.

If the Q6A becomes the limiting factor, I can still move my existing Pi 5 onto the robot. I would prefer not to do that, but keeping the STM32 responsible for balancing means the higher-level board is replaceable. The SBC sends movement setpoints; it does not own the part of the system that keeps the robot upright.