Best Robotics Software for Small Computers and Edge Devices

On a small board, start with one program and the vendor's library, and move to HORUS or ROS 2 only when one program stops coping. Small boards fail on copying and interruption rather than raw power, so what matters is what shares the board and how data crosses between parts. The verdict flips if the robot must map a room or navigate, because that code already exists in ROS 2. This post is for a beginner choosing what to install on a board they can hold in one hand, before that choice becomes expensive to change.

You bought the board that every tutorial recommends. It sits on the robot with a fan on top and a camera taped to the front, and it does work, in the sense that things happen when you run the script. What it does not do is behave the same way twice. The robot drives straight for a while and then twitches. The camera window freezes for a moment and the wheels keep their last command through the freeze, which is exactly when they should not.

Then you tried the framework everyone told you to use, and spent a weekend on installation instead of on the robot. Half the guides assume a desktop machine under a desk. The other half assume you already know what a workspace is. Somewhere in there you started wondering whether the board is simply too small, or whether you bought the wrong one, or whether everyone else's robot secretly has a laptop bolted to the back of it.

That is the real question underneath: whether this is a hardware problem you can buy your way out of, or a software problem that will follow you onto the next board.

What is the best robotics software for a small computer?

The best choice for most small boards is the least software that gets your robot moving, which usually means one program plus whatever library came with your hardware. That answer disappoints people who expected a framework, but the board is the reason for it. A small computer has one modest processor doing everything at once: reading the camera, deciding, driving the motors, writing logs and running whatever tool you left open. Every layer you add takes a share of that, and layers you did not choose deliberately take the largest share. The useful way to think about a small board is not how powerful it is but how many things are competing on it and how much data crosses between them. Start with the smallest arrangement that works, and let the robot tell you what it needs next. The mistake that costs beginners the most time is installing a large framework on day one because it is what professionals use, then spending weeks learning tooling while the robot sits on the desk not moving.

What counts as a small computer or edge device in robotics?

A small computer in robotics is anything on the robot itself that has to decide without asking a server, and it comes in two very different shapes. The first is a single-board Linux computer, a Raspberry Pi or a Jetson or similar, which runs a full operating system, can hold several programs at once and speaks to cameras and networks the way a laptop does. The second is a microcontroller, a chip that runs exactly one program with no operating system beneath it, which is what usually sits closest to the motors. The distinction matters more than the brand. A Linux board gives you libraries, drivers and choices, and in exchange the operating system decides when your program runs, which is why a control loop on a busy board can be interrupted at an awkward moment. A microcontroller gives you timing you can predict and takes away almost everything else. Edge simply means the deciding happens here rather than in a data centre, so a stalled network slows your dashboard and not your robot.

What are your real software options on a small board?

There are about eight realistic options, and the honest ranking depends on which shape of board you have and what the robot must do. You can write one program on a microcontroller with no operating system underneath. You can use the robot kit's own library, which is the fastest route on a complete kit. You can write one Python program on a Linux board, where most beginners start and many happily stay. You can install ROS 2, the large open ecosystem where drivers, mapping, navigation and visualisation already exist and your code becomes one node among many, or micro-ROS, the version built for microcontrollers. You can use HORUS, an open-source real-time robotics middleware for Rust, Python and C++ under Apache-2.0, where the three languages share the same shared-memory ring buffers, so a Python program and a compiled program on the same board exchange messages without serialising them between processes. You can split the work across a board and a laptop over the network. Or you can write your own threads and sockets. Read the table as situations rather than a scoreboard.

Which option fits a beginner building a first robot?

Take the kit's own library and one program, and change nothing else until the robot does something you are proud of. A first robot exists to teach you what robots actually do, and every hour spent on installation is an hour not spent learning that wheels do not go the same distance on carpet as on wood. The kit's examples already match your hardware, which removes the single most demoralising class of beginner problem: not knowing whether the fault is your code, your wiring or your setup. Keep one program until you feel it strain. You will know the moment, because it is specific rather than vague — the camera work makes the wheels stutter, or a slow step makes the robot act on something it saw a while ago. That is the first genuinely interesting problem in robotics, and meeting it with a working robot in front of you is far better than meeting it inside a framework you adopted before you needed one. Whether ROS 2 is overkill for a hobby robot is the same question asked from the other end.

What if your board is a microcontroller rather than a small Linux computer?

Write one program on the chip and put anything heavy somewhere else, because a microcontroller trades away every convenience for timing you can rely on. There is no operating system deciding when your code runs, so a loop that drives motors will run when you told it to, which is exactly why these chips sit closest to the wheels and joints on serious robots. What you cannot do on one is run a camera pipeline, load a model, or install a middleware built for a full computer. The usual arrangement on a real robot is two layers: a microcontroller holding the fast, dull, absolutely-must-happen work, and a Linux board doing the thinking and talking to the microcontroller over a serial link. If the whole robot is motors, a few sensors and a battery, you may never need the second layer at all, and adding one would mean introducing an operating system between your code and your motors for no gain. Decide which layer each job belongs to before choosing software for either.

What if you want the robot moving within a month?

Use whatever your hardware already documents, and accept that you are building something to learn from rather than to keep. A month is not long enough to learn an ecosystem and debug a machine at the same time, so the kit's library plus one program will get you further than the more respectable choice. Robots that move teach you things; robots that are well organised and still on the bench teach you nothing. The debt is real and worth naming up front. Code written this way tends to have the sensing, the deciding and the safety checks tangled in one file, ordered by luck rather than design, and it will work in one room under one set of lights. Keep one boundary clean even in a rush: whatever talks to the motors should be the only thing that talks to the motors. If that one line holds, replacing everything above it later is an afternoon rather than a rewrite, and you can adopt a framework when you actually have a reason to.

What if Python is the only language you know?

Stay in Python, because on a small robot the limit you will hit is a rhythm rather than a language. Python drives plenty of real machines: classroom robots, camera projects, slow mobile bases, anything where nothing has to answer on a strict schedule. The trouble arrives when one program must both think for as long as thinking takes and keep the wheels updated on a steady beat, because those two jobs do not share a process politely. The fix is not to rewrite your robot in another language. It is to move the one loop that cannot be interrupted into its own program, often a compiled one or a microcontroller, and leave everything else in Python where you are productive. That is the point where the boundary between programs starts to matter, and where the way messages cross between them stops being a detail. Before that point, a language argument is a distraction. Learn where your own robot's rhythm actually lives, then decide.

What do beginners install first, and why does it stop working?

Most beginners install the biggest framework they have heard of, and it stops working because setup is the wrong first problem to have. The pattern is consistent enough to predict: a weekend goes into installation and dependency errors, then a tutorial half-works, then the robot does something small, and by then the enthusiasm that started the project has gone into fixing an environment. Nothing was learned about the robot. The second pattern is subtler and catches more careful people. One Python program is written, it works, and then a camera is added and everything degrades at once — not with an error, but with hesitation. Each frame is read, copied, converted and passed along, and on a small board those copies compete with the work you care about. Teams then split the program in two, which cures the stutter and creates a new question, because now every frame has to get from one program to the other. That question is where the actual software choice lives, and arriving at it with a working robot is the good way to arrive.

What does an overloaded small board actually look like?

An overloaded board looks like a robot that behaves well until something interesting happens, and then hesitates at exactly the wrong moment. The signs are ordinary and easy to miss individually. The fan runs constantly. Raising the camera resolution makes the arm hesitate. Adding a sensor makes an unrelated part of the robot worse for reasons nobody can explain. The same script gives a different result on the second run. A log line you added to investigate changes the behaviour, which should always alarm you, because it means correctness depends on how long things take. Underneath most of these is the same cause: data being copied between programs that live on the same computer, plus an operating system deciding that some other program deserves the processor for a moment. Neither shows up in your code. Both show up in the motion. Recognising this pattern is worth more than any framework knowledge, because it tells you the difference between a robot that needs a bigger board and a robot that needs a different arrangement of the same board.

What do you give up by not running the full ecosystem?

You give up other people's drivers, other people's tools and a large community that has already had your problem, and beginners underestimate all three. The ecosystem is the point: drivers for hardware you have not bought yet, mapping and navigation representing years of work you cannot reproduce, a visualiser that shows what the robot believes about the world, and recording tools that let you replay a bad run at your desk instead of chasing the robot around the floor. Going leaner means doing without those or building them, and building a visualiser is a project of its own. You also give up shared vocabulary, which matters more than it sounds when you are new, because a question asked in common terms gets answered by strangers while the same question in your own terms does not. Weigh maturity honestly too: the leaner options are younger, several are validated in simulation rather than by years of fleets in buildings, and a smaller project means fewer people have already hit the bug you are about to hit.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever the robot needs software that already exists, and on small robots that happens more often than the lean argument admits. If your robot must build a map of a room and drive to a point on that map, use ROS 2, because navigation and mapping are years of work and rewriting them is not a small-board optimisation, it is a career change. If the sensor you bought ships one usable driver and that driver is a ROS 2 package, the decision has been made for you already. If you are learning robotics to get a job, the ecosystem is a large part of what employers mean by robotics experience. If a class, a lab or a colleague already uses ROS 2, take the help. And if your robot spans more than one machine, ROS 2 was designed for that shape. HORUS is not the answer in any of those cases, and choosing it there means rebuilding the plumbing you would have got for free while losing the packages that were the point.

Is ROS 2 simply too heavy for a small board?

No, and here is why: ROS 2 runs perfectly well on small Linux computers, and thousands of hobby and classroom robots prove it every term. The weight beginners feel is real but it is mostly in the wrong place. Part of it is setup and vocabulary — workspaces, launch files, packages, build tooling — which is a learning cost, not a running cost, and it does not go away by buying a bigger board. Part is habit: leaving graphical tools running on the robot, building on the robot rather than off it, and running every optional node because a tutorial did. Where genuine weight appears on a small machine is when large data crosses between processes many times a second, since packing and unpacking frames is work the board must do on top of the work you care about. That is a specific problem with specific fixes rather than a verdict on the whole framework. Diagnose which of the three you have before concluding the framework is unsuitable for your robot.

Will a faster board make the software choice stop mattering?

Partly, but not the way you think. A better board genuinely solves one class of problem: it lets you run a larger model, or run the same work while something else is happening, and if your robot is simply short of processing then buying one is the honest fix. What a faster board does not change is the shape of the system. If every camera frame is copied three times on its way between programs, a quicker chip copies it three times more quickly and the design is unchanged, waiting for the next camera you add. If a control loop can be interrupted by a slow logging call, the interruption merely happens less often, which makes the fault harder to reproduce rather than gone. The signature to watch for is a problem that becomes rarer after an upgrade but never disappears. Rare-but-present means structural, and structural problems return with the next sensor. Whether you need shared memory for robot software walks through the symptoms before the solutions.

How do you decide which one to start with?

Answer two questions about your own robot, in order, and the choice falls out. First: does anything on this machine have to happen on a strict rhythm? If nothing does, stay with one program and stop reading about middleware, because you do not have that problem yet. Second: do you need software you cannot write yourself, such as mapping, navigation or a driver for a sensor you already bought? If yes, take ROS 2 and pay the learning cost, because the alternative is rebuilding what already exists. Only when the answers are yes to the first and no to the second does the leaner path make sense, and that combination is real — a Python model and a compiled loop sharing one board is exactly it. Do this before choosing, not after. Beginners who adopt a framework to fix a problem they never identified find the problem still there, now inside tooling they cannot debug. If you land on the lean side, what to use instead of ROS 2 on a small robot covers the alternatives in order.

Decide by situation rather than by reputation:

• If you are building your first robot from a kit -> the kit's library and one program, because your first job is learning what robots do.
• If the robot is motors and sensors with no camera -> one program on a microcontroller, because predictable timing is worth more than choice.
• If the robot must map a room or navigate to a goal -> ROS 2, because that code exists and you will not rewrite it.
• If a Python model and a compiled control loop share one board -> a shared-memory middleware, because copying between them is where the board's attention goes.
• If the thinking will not fit on the robot at all -> a board plus a laptop, with a local behaviour that keeps the robot safe when the link stalls.

When the choice gets serious, weigh it on the five axes of the HORUS Fit Framework: ecosystem size, setup effort, team size fit, deployment target and licence. No scores, just the option that loses on the fewest axes for the robot on your desk. And if that robot keeps ending up as one small board carrying a Python program, a compiled loop and a camera stream that has to reach both, star HORUS on GitHub so it is in your list when you start building. What physical AI actually means is the wider version of this question.