ROS 2 Humble vs Jazzy: Which Distro Should You Start With?

Start a new robot on ROS 2 Jazzy; stay on Humble only if a driver you depend on has not moved yet. Jazzy is supported for years longer and matches the Ubuntu version new machines ship with, so the guides you read match the system you installed. A vendor driver that only builds on Humble flips that, and neither answer involves replacing ROS 2 with HORUS. The rest of this guide is for anyone picking a base for a robot they intend to still be running two or three years from now.

You have a robot to build and a fork in the road before you have written a line of your own code. Every tutorial you open assumes a different release. The blog post that solves your exact camera problem targets one, the university course you are working through uses another, and the driver repository for the arm you bought has an open issue asking for a port that nobody has answered in a year. Meanwhile the laptop on your desk shipped with a newer Ubuntu than the one your team's install guide names, and the very first command in that guide fails.

So you do what everyone does. You pick the release that appears most often in search results, install it, and get moving. Three months later a colleague asks why packages have stopped appearing for your base, or why the new engineer's machine cannot reproduce your environment, and you realise the choice you made in ten minutes has become the shape of the whole project. This is a small decision with a long tail, and it deserves an afternoon rather than a coffee break.

Should you start a new robot on Humble or Jazzy?

Start on Jazzy if you are beginning now. Jazzy is the current long-term release, it is built against the Ubuntu version that new laptops and new single-board computers ship with, and its support window runs years past the point where Humble stops receiving fixes. The reason this matters is not novelty. When a distro reaches end of life, packages stop being built for it, security fixes stop arriving, and the answers people write move on without you. If your robot will still be driving around in three years, starting on the older base means scheduling a migration into some future quarter when you would much rather be shipping.

One condition overrides all of that, and it is not a matter of taste. If a driver you cannot replace, usually for an arm, a lidar or a depth camera, only builds on Humble, then Humble is your answer until that driver is ported. Hardware you already own beats a longer support window every time. Check that one thing before you read anything else about either release, because it settles the question outright in a good number of cases.

What is a ROS 2 distro, and what does picking one commit you to?

A ROS 2 distro is a dated snapshot of the core libraries plus thousands of community packages, built and tested together against one specific Ubuntu release. Picking one is closer to picking a Linux version than to picking a library version. The choice quietly decides your operating system, your compiler generation, your Python version, and which community packages install with one command rather than from source.

Each long-term distro comes with a support window measured in years. Inside that window there are prebuilt packages, security fixes, and a shared build system that tells maintainers when they have broken something for everyone else. Outside it, packages stay downloadable for a while, but nothing new appears, and every question you ask from then on has been answered for a different release.

The practical effect is that a distro is a compatibility agreement with the rest of the community. Stay inside it and most things install on the first try. Step outside it by mixing packages from two releases and you spend evenings on build errors that have nothing to do with your robot. If the vocabulary here is new, the plain-English guide to robotics middleware covers the ideas underneath.

What are the actual options besides Humble and Jazzy?

There are five, and only two of them are really distro choices. Humble is the older long-term release. Jazzy is the current one. Around them sit the non-long-term releases, supported for roughly a year and aimed at people who want core changes early and accept re-basing on a schedule. Rolling is the development line, useful if you maintain packages and painful if you just want a robot to drive. Staying on ROS 1 remains technically possible and is a poor choice for anything new, because the community has moved.

The fifth option is not a distro at all. If what actually hurts is the timing of one control loop rather than the framework around it, a real-time middleware can sit beside ROS 2 instead of replacing it. HORUS is one of those: open-source middleware for Rust, Python and C++ where all three languages share the same shared-memory ring buffers, so messages between processes on one machine are never serialised. Apache-2.0 licensed, currently validated in simulation, and not an answer to a distro question.

Which of these should each kind of team pick?

The table below is the whole decision in one place. Read the last two columns first, because the quickest route to an answer is eliminating the options that are wrong for you rather than falling in love with one. The bottom row is not competing with the rows above it for the same job, and reading a table like this as a single ranked list is the most common way people get the decision wrong.

Are you learning robotics or shipping a product?

Learners should take Jazzy, and teams with a deadline should take whatever their working machines already run. When you are learning, a missing package costs you an afternoon and a better search query, and the payoff for being on the current release is that the material you find next year still describes your setup. When you are shipping, a missing driver costs you a schedule, and a base your build system already produces working images for is worth more than any support window on a chart.

Research groups sit awkwardly between the two, because machines arrive from different eras and students arrive every term. The answer there is not a distro so much as a rule: standardise on one release, write it at the top of the readme, and put it in a container image so nobody has to guess. Mixed distros inside one group are how a lab ends up with three subtly different definitions of the same message type and a week of debugging that produces no science.

Does the computer on your robot decide the distro for you?

Often it does, and this is the constraint people discover last. Single-board computers with vendor Linux images are frequently pinned to an older Ubuntu for a long time after a newer one exists, because the graphics stack and camera drivers come from the board maker rather than from the distribution. If your board's supported image is the older Ubuntu, the older ROS 2 distro is the path of least resistance. Containers help only partly. You can run a newer userland inside one, but the moment you need the GPU, a camera pipeline or a vendor kernel patch, the container boundary costs more than the upgrade saved.

Ordinary x86 machines have no such excuse. If your robot's brain is a normal mini PC, install the newer Ubuntu and take Jazzy. Microcontrollers are a separate world: they run a cut-down client library rather than a full distro, so the distro question applies to the computer they talk to and not to the board itself.

How soon does the robot need to work?

Under a month, change nothing. If you have weeks, the correct distro is whichever one your working machines run today, because a distro migration is never a small task and it always lands in the week you can least afford to lose. Anything you gain from a longer support window is dwarfed by the risk of an environment change days before a demo.

Between one and six months, take Jazzy and absorb the setup cost early, while nothing is at stake and a broken machine is an inconvenience rather than an incident. Over a year, take Jazzy without hesitation, and schedule a rehearsal upgrade on a spare machine long before you actually need one, so that the first time you do it is not the time it matters.

There is a general rule hiding in this. Every migration is cheapest before real users exist, before a fleet exists, and before someone outside your team depends on the exact behaviour of a build. Delay makes it more expensive, never less.

How much Linux and C++ do you need for each?

The same amount for both, which surprises people who assume the newer release is harder. Both install from a package manager, both use the same build tooling, and the concepts you have to absorb, nodes, topics, launch files, parameters and coordinate transforms, are identical across them. The difference is not difficulty but the shape of your search results.

Humble has years of accumulated blog posts, course material and forum answers written against it. On Jazzy you will occasionally land on an answer written for the older release and have to translate a package name or a changed launch argument. That translation is a genuine tax during your first week, and it is the strongest honest argument for Humble for someone following a specific book or a specific course start to finish.

The rule that resolves it: if you are following a course, use the release the course uses. If you are following the official documentation, use Jazzy, because the documentation defaults to the current release. Neither path teaches you less about robotics.

What does it look like when you picked the wrong distro?

It looks like small friction that never resolves. The package manager cannot find a package that everyone in the forum thread clearly has. You build one dependency from source, which needs another built from source, and a week later you are maintaining a tree of other people's code you never wanted to own. The arm starts up, then dies with an error about a message type that does not match, because two halves of your system were built against different definitions.

Then it becomes a people problem. A new teammate cannot reproduce your machine and you cannot explain why, because the working setup grew by accident. The container image builds on your laptop and not on the robot. Security updates quietly stop arriving and nobody notices for months.

None of these look like a distro problem while they are happening. They look like bad luck, one thing at a time. The tell is that the fixes never accumulate into stability, and every new component costs the same painful week that the last one did.

What do you give up by starting on Jazzy?

You give up a slice of the community's written history and a handful of packages nobody has ported. Concretely: a few vendor drivers, some smaller community packages maintained by one person who has not had a free weekend, and a great deal of tutorial writing that still assumes the older release. You also give up the reassurance of doing what most people around you did last year.

You do not give up the core. Navigation, manipulation, visualisation, transforms, recording and replaying runs, and the client libraries for Python and C++ are all present and maintained on the current release. The gap is at the edges, and the edges are exactly where your specific hardware lives, which is why the gap feels bigger than it is.

The way to make this concrete instead of anxious: write down the packages you genuinely cannot rewrite yourself, usually three to six of them, and check each one against the current release before you commit. Decide on that list rather than on a feeling about newness.

When is ROS 2 the better choice?

ROS 2 is the better choice for nearly everyone reading this, and the honest version of this section is that the title question is a ROS 2 question with a ROS 2 answer. Take ROS 2, on either distro, when you want mapping and navigation somebody else has already debugged, when you need drivers for cameras, lidars and arms you did not build yourself, when you want to record a run and replay it later, when you want to see what the robot believes about the world, and when you want to hire people who already speak the vocabulary. That describes most robots and most teams.

HORUS is not the answer to which distro to start with, being neither a distro nor a replacement for mapping stacks, drivers and tooling. The narrow case for reaching past ROS 2 is a loop that must finish before the next cycle needs its result, where the cost of moving messages between processes is what stops that happening. The write-up on fusing IMU and odometry data walks through what that failure feels like. If it does not describe your symptom, stay where the ecosystem is.

Is Humble the safer choice because more people use it?

No, and here is why. Popularity in a distro is a lagging measure of where people started, not a forward measure of where support is going. The count you actually care about is how many people will be running your release in the year you hit your hardest problem, and by that measure the older release is the one shrinking while the newer one grows. Choosing the crowd of two years ago puts you at the back of the queue for every future answer.

Safety in this decision comes from three concrete things instead. First, a support window that outlasts your project, so nobody has to migrate under pressure. Second, an Ubuntu version your hardware vendor still supports, so the graphics and camera stacks work. Third, the specific packages you cannot write yourself, available as prebuilt packages rather than as a source tree you maintain.

Check those three and the popularity question dissolves. Skip them and a crowded release will not save you, because the crowd is not debugging your robot.

Will moving from Humble to Jazzy break your whole codebase?

Partly, but not the way you think. Your own nodes usually survive with small edits. What breaks is around them: a package that was renamed, an argument removed after being deprecated for two releases, a launch file that used a syntax now retired, a dependency pinned to a version that no longer exists in the newer archive. Each fix is small and the total is a few days for a moderate project, not a rewrite.

The part people underestimate is that a distro upgrade is really an operating system upgrade wearing a robotics hat. The Ubuntu version changes underneath you, which means a new Python version, new compiler behaviour, new graphics drivers, and possibly a new vendor image for your board. That is usually the larger half of the work and the half nobody budgets.

So plan it as an OS migration with a ROS upgrade attached. Do a spare machine first, keep the old one bootable, and write down every fix as you go, because you will be doing it again on the fleet.

How do you decide in an afternoon?

Work through four checks in order and stop at the first one that answers. Check one: list the drivers and packages you cannot rewrite yourself, then confirm each is available on the current release. If one is not, and the hardware is bought, you are on Humble until that changes. Check two: find the Ubuntu version your board's vendor image supports. If the vendor is pinned to the older one and you need their GPU or camera stack, you are on Humble.

Check three: look at your calendar. If something has to work within a month on machines that already work, do not migrate anything today. Check four: if all three came back clear, take Jazzy, and stop deliberating, because the remaining differences are small enough that the deliberation costs more than the choice.

Then write the decision down. Put the distro name at the top of the readme, pin it in a container image, and make it the first line of your onboarding notes. A decision nobody can find gets remade by accident every time a new machine arrives.

If you are starting a new robot this month -> Jazzy, because the support window outlasts the build.

If you are three weeks from a demo on working Humble machines -> Humble, because a distro migration is not a demo task.

If a lidar or arm driver you cannot replace only builds on Humble -> Humble, because a missing driver stops everything else.

If you are teaching on lab hardware you do not control -> whatever the lab images already run, because setup time is the whole lesson.

If your control loop stutters identically on both -> keep ROS 2 and add a real-time layer for that one loop, because the distro was never the cause.

We rate options on this blog with the HORUS Fit Framework, which scores each one on five axes and no numbers: ecosystem size, setup effort, team size fit, deployment target, and licence. A distro choice moves the first two; a middleware choice moves the last three.

If the last line of that decision block is the one that matched you, HORUS is open source under Apache-2.0 and validated in simulation. Star it so it is in your list when you start building, and come back to it on the day a loop starts arriving late. For a gentler on-ramp, the Python-versus-ROS 2 walkthrough is a shorter read.