Best Robotics Middleware for Raspberry Pi and Jetson Robots

For most Raspberry Pi and Jetson robots ROS 2 is the best default, with HORUS the pick once one board runs vision and control together. Both boards run Linux, so both run every option here, and the ready-made drivers, maps and navigation are written for ROS 2 first. The verdict flips when a single board has to do camera work and steer at the same time. The rest of this post is for someone holding a board, a battery and a chassis, deciding what to install before the first drive.

You bought the board because a video said to. Then you read a forum thread that said the board was too small and you should have bought the other one, and now there are two boards on the desk and neither has driven anything.

Every guide starts the same way: install this, source that, add this line to your shell file. The first command failed because your operating system version was not the one in the guide. The second worked but printed warnings you cannot judge. Somewhere in the third hour you were flashing a fresh card, which felt like progress and was not.

What you actually want is simple and nobody states it plainly. You want to know which one thing to install so that a wheel turns, a camera picture appears, and the robot stops before it hits the table. You do not know whether your difficulty is the board, the operating system, the framework or you, and that uncertainty is far more discouraging than any error message. Meanwhile the chassis sits half-assembled, and every evening spent on installation is an evening the robot did not move.

Which middleware should you install on a Raspberry Pi or Jetson robot?

Install ROS 2 if the robot has to find its own way somewhere, and install nothing at all if the robot only has to drive and react. Both boards are ordinary Linux computers, so the board is not what decides this. What decides it is the job.

A robot that follows a line, avoids what is in front of it, or drives where a joystick tells it, is one program with one loop. Middleware between a single program and itself is pure setup cost. Start there, get the wheels turning this weekend, and add structure the first time you have a reason.

A robot that must build a map, know where it is standing, and plan a route around a chair somebody moved needs mapping and navigation software that already exists and took years to write. That is ROS 2, and it is the correct answer even though the install is annoying.

The third case is the one this post exists for: a robot with a camera and a motor loop on the same board, where the two start interfering. That is a messaging problem, and it has its own answer.

What does robotics middleware do on a single board?

Middleware carries messages between the separate programs that make up a robot, so the program reading a camera and the program driving the wheels do not have to live in the same file. Each one starts on its own, is written in whatever language suits it, and finds the others by the name of the data rather than by a function call.

On a single board that matters more than people expect. Vision work and motor work want different things: one wants as much of the machine as it can get, the other wants to be on time, every time. Splitting them into separate programs is how you stop a busy camera from delaying a wheel command.

The price is bookkeeping. Programs must be named, built, launched in an order, and configured somewhere outside the code. For a first robot that is one script, that price buys nothing at all, which is why the honest answer for beginners is often "not yet". If the whole idea is still fuzzy, the plain-English version of what middleware does is a better first read than any install guide.

What are the real options for these boards, ranked?

Ranked by how often each is the right answer on a Pi or a Jetson: ROS 2 first, one plain Python program second, the kit vendor library third, then HORUS, then micro-ROS, then a broker such as MQTT, then Zenoh. ROS 2 leads because everything you will want to buy, from a lidar to a depth camera, ships with a driver written for ROS 2, and because mapping and navigation are solved there and nowhere else on this list.

One plain Python program ranks second because it is genuinely the right answer for a first robot, and the ranking is about fit rather than size. The vendor library ranks third: fastest to a moving robot, hardest to leave.

Fourth is an open-source real-time robotics middleware for Rust, Python and C++ in which all three share the same shared-memory ring buffers, so messages between processes on one board are never serialised. That project is Apache-2.0 and validated in simulation, and it fits the Pi or Jetson robot whose camera work and control loop have started to interfere. micro-ROS covers the microcontroller beside the board, MQTT reports to a dashboard, and Zenoh links machines across a network.

How do the options compare on a Pi or a Jetson?

Read the last column first and cross out every row that describes your robot. Most beginners are left with two rows, and the choice between them is usually about the job rather than the board.

The row people get wrong is the vendor library. Starting there is sensible and quick, and the code you write becomes an argument for never changing hardware, which is worth knowing on the first evening rather than the hundredth.

What does it look like when a single board runs out of room?

A board running out of room does not crash; it goes late, and late is much harder to recognise than broken. The camera window still updates. The logs still print. The robot simply stops feeling crisp. It drifts past the line it used to hold, the obstacle stop fires a beat after you expected, and a turn that was tidy last month now overshoots and corrects.

The usual first reaction is to blame the hardware and shop for a bigger board. Sometimes that is right. More often the board is fine and the problem is that one program is doing everything in one loop, so a slow frame of video delays the next wheel command by exactly as long as the frame took.

The second reaction is to add sleeps and tune them until the robot looks acceptable. That works for a fortnight and then stops working on a warm day, because the numbers were fitted to one moment rather than to a cause. Recognising this pattern early is worth a lot, since the fix is structural and cheap when the robot is small.

Are you learning, prototyping, or shipping a product?

If you are learning, install as little as possible; if you are prototyping for a demo, use ROS 2; if you are shipping, decide by who supports the robot in three years. Those three answers pull in different directions and most disappointment comes from applying the wrong one.

Learning means the measure is how much you understood this week. A framework that hides the loop hides the thing you came to learn, so a first robot in one file, with everything visible on one screen, teaches more per evening than a tutorial you can follow but not explain.

Prototyping for a demo, a grant or a course means somebody else will look at the result, and the packages save you months. Use them, and accept the setup.

Shipping is a different question again. A custom stack is cheapest in the first quarter and gets more expensive with every hire, because there is no documentation but yours and no candidate arrives already knowing it. A narrow product doing one job can carry a small custom stack for years; a robot with growing ambitions usually cannot.

Does it matter whether your board is a Pi or a Jetson?

The board matters for what the robot can perceive, not for which middleware to install. A Raspberry Pi is a competent Linux computer that drives motors, reads a lidar, holds a state machine and streams a camera. A Jetson is a Linux computer with a GPU attached, and the GPU exists to run vision models on the robot instead of on a laptop over Wi-Fi.

So the honest question is whether your robot has to see and understand, or just to move. Detecting a person, reading a shelf label or following a target by sight is Jetson work. Driving a route and stopping for obstacles is Pi work, and a Pi is cheaper, cooler and easier to replace after you reverse a battery lead.

Two practical differences do matter. A Jetson usually wants the vendor operating system image, which pins your versions and makes some install guides inapplicable. And a Jetson generates heat that a taped-together chassis will not remove, so the robot slows down after ten minutes on the carpet in a way no software choice explains.

How long before the robot has to do something?

If the robot must move this week, do not install a framework this week. Write one script, turn the wheels, stop before the table leg, and finish the week with a machine that moves. A robot that moves earns your next weekend; a half-installed framework does not.

With a month of evenings, you can learn ROS 2 properly, and that is a fine way to spend a month provided you name it honestly. That month buys ROS 2. The robot comes after.

With a season, do both in order. Build the simple robot first, learn what it actually needs, then rebuild it with structure. The rebuild is quick because the hard knowledge already exists, and it is a far better use of the season than starting with a stack you cannot yet justify.

The failure mode to avoid is stopping halfway up. Half-learned tooling costs the whole install and returns almost none of the packages, and it usually ends with a card that boots into something you no longer understand. If you feel that happening, shrink the target rather than the effort.

What if Python is the only language you know?

Python alone is enough to build a working robot on either board, and it is enough for longer than most people tell you. Reading a sensor, deciding a speed, driving a motor driver and even talking to a camera are all comfortable in Python, and the loop rates that ordinary wheeled robots need are within reach.

Where Python starts to strain is the point where the loop must never be late while something heavy runs beside it. The usual answer is not to abandon Python but to move the strict part elsewhere: onto a microcontroller that does nothing but the wheel loop, or into a small program in another language that talks to your Python code through messages. That is why a middleware where Python and a compiled language share the same message buffers matters more to beginners than it first appears.

The judgement about when Python stops being enough is subtle and often decided too early out of fear. A closer look at where Python genuinely runs out is worth reading before you rewrite anything in C++.

What do you give up by choosing something smaller than ROS 2?

You give up maps, navigation, visualisation, replay, simulation and every driver written by somebody else, which is a large pile to hand back. The visualiser deserves its own mention: a window showing what the robot believes about the world is the best debugging tool a beginner can have, and its absence is felt every day once you have used one.

You give up recording a run that went wrong and replaying it at your desk, so every intermittent fault has to be reproduced live with the robot moving and you following it.

You give up the depth camera driver written by somebody who read the protocol document, and the simulator that lets you keep building while the battery charges.

You also give up the search results. Pasting an error from a widely used stack returns pages of people who had the same evening; pasting an error from your own code returns nothing. For a beginner, that difference is worth more than any technical comparison, and it is the strongest argument for starting inside a big ecosystem even when a smaller tool would fit the robot better.

When is ROS 2 the better choice?

ROS 2 is the better choice for most Pi and Jetson robots with any ambition beyond driving, and HORUS is not the answer for a first robot that has never once run late. If you want a robot that maps a room, works out where it is and plans a path across it, use what exists. Writing that yourself is not a hobby project or a term project; it is a field.

Use ROS 2 when the sensors you bought ship with drivers, which is nearly every lidar and depth camera worth buying. Use it when you are doing coursework, a competition or research, because the people marking or helping you speak that vocabulary. Use it when more than a couple of people touch the code.

Use it when you want a job in robotics, because that is the word on the job adverts and the shared language of every interview you want. And use it when you want to test in a simulator before hardware arrives. A beginner on a Raspberry Pi who intends to keep going in robotics should learn ROS 2 at some point, and choosing it deliberately once the robot needs it beats installing it in week one out of obligation.

Is a Raspberry Pi too small to run real robot software?

No, and here is why: a Raspberry Pi is a full Linux computer, and the robots that people actually build on one are limited by what they ask the board to do, not by the board's dignity. A Pi drives motors, reads encoders, handles a lidar and runs a navigation stack for an indoor robot without anybody making excuses for it.

What a Pi is genuinely poor at is heavy vision on top of everything else. Decoding a video stream, running a detection model and steering a robot at the same time is where a small board runs out, and no framework choice rescues that. The fix is either a board with a GPU, a smaller vision job, or moving the strict work off the busy board altogether.

The mistake beginners make is inferring from "my robot is jerky" that the board is too small. Far more often the board is idle in patches and the software is arranged so that one slow step blocks a fast one, which costs nothing to fix and no money at all.

Does a Jetson make the software choice easier?

Partly, but not the way you think: a Jetson removes the vision bottleneck and leaves the arrangement problem exactly where it was. With a GPU on board you can run a detection model on the robot, which genuinely changes what the machine can do. What it does not change is that a heavy vision process and a motor loop still live on one computer and still get in each other's way if they are written as one program.

There is also a cost people meet late. The vendor image pins your operating system version, some install guides will not apply, and the ecosystem around the board moves at its own pace, so a tutorial written for a mainstream distribution may need translating.

And a GPU does not make images cheap to move. Passing full camera frames between processes still costs real work every time the data is copied, which is exactly the problem a shared-memory design exists to remove. Buying the faster board without arranging the software still leaves you with a robot that hesitates.

How do you decide what to flash onto the card this weekend?

Decide by writing one sentence describing what the robot must do by Sunday night, then installing only what that sentence needs. "The robot drives forward and stops before the table leg" needs Python and a distance sensor. "The robot follows me around the flat using the camera" needs a Jetson or an equivalent and probably still not a framework.

"The robot builds a map of the flat and drives to a spot I click on a screen" needs ROS 2, this weekend, and every hour spent avoiding that is an hour wasted.

Then keep one habit. At the end of each session, ask whether you can still explain every program running on the robot and why. The first evening the answer is no, stop adding and start removing, because unexplained machinery is where beginner projects go to die. The same instinct applies to the robot's job: if you are unsure whether yours even needs a framework, the case of a robot that only drives makes the boundary concrete.

Here is the decision in six lines.

• If this is your first robot -> one Python program on the board, because nothing else moves sooner.
• If you bought a complete kit -> the vendor library, because the wiring is already solved for that hardware.
• If the robot must map a room and navigate it -> ROS 2, because that software took years and already exists.
• If you want a robotics job or a course credit -> ROS 2, because the vocabulary is the part that gets read.
• If your Pi or Jetson goes late once the camera is busy -> a shared-memory middleware, because the trouble is between programs.
• If three weekends have gone into installs -> a smaller target, because a board that never drove teaches nobody anything.

The HORUS Fit Framework turns that into five axes you can score any option against: ecosystem size, setup effort, team size fit, deployment target, and licence. On a single-board robot, deployment target usually decides, since one board doing everything is a different problem from a board with a microcontroller beneath it, and ecosystem size is the axis that overrules the rest for a beginner.

When your board does start running late, you want the alternative already on the shelf instead of researched in a panic. Put HORUS on that shelf now: star it so it is in your list when you start building.