What Robotics Teams Should Standardise Early

Standardise how your programs talk, start and log before anything else; whether that means ROS 2 conventions or a smaller stack like HORUS comes second. Those three decisions get expensive to change later, because every file and every teammate ends up depending on them. The condition that flips it: one person shipping one demo should standardise almost nothing and keep moving. The rest of this post is for a small team whose robot now has more than one author, more than one program, and a delivery date somebody else picked.

Nobody planned it this way. The first version was one person's project, and the conventions were whatever that person happened to type. Then a second person joined, and a third, and each of them made reasonable choices that were reasonable in isolation.

Now there are two ways to describe a position, and they disagree about which direction counts as forwards. There are four ways to start the robot, three of which are in somebody's shell history and one of which is in a document that is out of date. The newest person has been here two weeks and still cannot run the machine without a colleague sitting next to them. Two components send data that means the same thing under different names, so somebody wrote a translator, and now the translator has bugs.

Every one of these is small. Together they are why a feature that should take a day takes a week, and why the answer to any question about the robot is that you would have to ask a particular person, who is on holiday.

What should a robotics team standardise first?

Standardise the interfaces between people before you standardise anything technical, which in practice means three things: how programs exchange data, how the robot starts and stops, and how logs come out. Those three are the places where one person's choice becomes everyone else's constraint, and they are the ones that get expensive to unpick later.

Data comes first because it is the hardest to change. The moment two components agree on a message shape, its fields, its units and its frame of reference, every program touching that data has a dependency on the agreement. Change it in month six and you change six programs and everyone's tests.

Starting and stopping comes second because it is what onboarding runs into. If bringing the robot up lives in someone's shell history, then only that someone can bring the robot up, and the team has a single point of failure who takes holidays.

Logging comes third because it decides whether you can debug at all. A team that records the same thing the same way every run can compare two runs. A team that cannot compare runs argues from memory.

What does standardising actually mean on a robot?

Standardising means writing down the agreements that programs and people already depend on, so nobody has to guess or ask. It is not a style guide, and confusing the two is why engineers roll their eyes at the word. Nobody is talking about tabs and spaces here. They are talking about the small number of facts every part of the robot has to share.

Concretely, it looks like this. There is one file that defines what a joint command contains and what units it uses. There is one command that brings the robot up and one that takes it down. Recordings land in one place with one naming rule. A new person clones the repository, runs one setup command, and gets a machine that behaves like everyone else's.

That is the whole ambition. It is deliberately small, because standards nobody asked for get ignored, and ignored standards are worse than none: they read as authoritative and describe a world that stopped existing two months ago. The test for whether something belongs is whether its absence has already cost you an afternoon.

What do teams actually standardise on?

Teams standardise on a foundation, and there are five that occur in the wild. ROS 2 is the common answer, and it comes with message definitions, a launch system, recording tools and a hiring pool already fluent in all of it, which is a large part of why teams choose it. Where several programs on one computer must share camera-sized data every cycle, a shared-memory middleware such as HORUS is the other serious option, an Apache-2.0 project where Rust, Python and C++ read and write the same ring buffers so messages between processes on one machine are not serialised. Those two answer different questions and a team should know which question it has.

The other three are common and less discussed. A vendor SDK standardises everything for you and quietly standardises you onto one supplier. A message broker from the web world plus your own conventions works when data mostly leaves the robot and struggles when data drives a loop. And a house framework, which every team believes will stay small, and which becomes the thing new hires spend their first month learning.

How do the options compare side by side?

Read the last column first. Eliminating options is faster than choosing between them, and most teams find their real decision is between two rows once the impossible ones are gone.

Does team size change what you should write down?

Yes, and it is the single strongest factor. One person needs no standards at all, because the agreement lives in one head and updating it is free. Writing conventions for yourself is a way of feeling organised while shipping nothing.

Two or three people is where the first standards pay for themselves, and the list is short: message shapes, one startup command, one recording location. That is an afternoon of work and it prevents the class of bug where two people implement the same idea slightly differently and neither notices for a month.

Beyond about five people, the constraint changes shape. Nobody can hold the whole robot in their head any more, so standards stop being a convenience and start being how the machine stays coherent. This is also the size where informal agreements fail silently, because a convention transmitted by conversation only reaches people who were in the conversation.

Teams that grow past this point without writing anything down do not notice a crisis. They notice that everything takes longer, and they blame the code.

What hardware are you standardising for?

Standardise for the hardware you will ship on, not the hardware you are developing on, because those differ more than teams expect. A stack that assumes a workstation carries habits a small board will not tolerate: heavy visualisation running alongside the loop, generous memory assumptions, tools that were fine on a laptop and are not fine on the robot.

The other hardware question is how many computers the robot has. One board means every program can potentially share memory with every other, and your standards can assume that. Two or more computers means a network link in the middle, and any convention assuming shared memory stops applying across that link. Teams that standardise on the single-board assumption and later split the machine end up with two sets of rules and a seam between them.

Decide the shape of the machine before you write conventions that depend on it. Should your robot run one computer or several is the prior question, and getting it settled first saves rewriting the agreements you are about to make.

How early is early if you already have a deadline?

Early means before the second person writes code against the first person's assumptions, which for most teams is week two, not month six. The window is small and it closes quietly. Nothing goes wrong on the day it closes; the cost simply moves from an afternoon of writing things down to a sprint of reconciling things people already built.

If a deadline is close and nothing is standardised, do not attempt the whole list. Do the one that is bleeding. If onboarding is the pain, write the startup command and the setup script and stop. If bugs keep tracing to units or coordinate frames, write the message definitions and stop. A single standard that everyone follows beats a document nobody reads.

After the deadline, the honest move is to schedule the rest deliberately rather than hoping for a quiet week, because quiet weeks do not arrive. Teams that treat standards as a task with an owner and a date get them. Teams that treat them as something to do when there is time never do.

What if half your team has never written robot software?

A team where half the people are new to robot software should standardise more than a veteran team, and should start at the boring end of the list. Web and application developers joining a robotics team are usually strong programmers meeting an unfamiliar failure model: code that works but arrives late, data that is stale rather than wrong, a bug that only appears when the machine is warm. Conventions are how that knowledge gets transferred without a senior person narrating every task.

The most valuable thing to write down for a mixed-experience team is not a coding rule. It is the map: which program owns which job, what data flows between them, what each one is allowed to assume about timing. One diagram in the repository does more for a newcomer than a week of pairing.

The language question comes up here too, and it usually resolves as a boundary rather than a rule. Should you mix languages in a robot project covers where that boundary belongs, which is a decision worth making once rather than per component.

What should you deliberately leave unstandardised?

Leave the inside of components alone, and resist the urge to standardise anything you have not yet felt the absence of. How a perception module structures its internals is that module's business, and a rule imposed on it costs argument now and rework later when the module turns out to need something different.

The list of things to leave alone is longer than the list to standardise. Testing style, folder layout inside a package, logging verbosity, which editor, which linting rules beyond what a formatter settles automatically, how a person structures a class. Each of these has a defensible standard and none of them has ever been the reason a robot missed a delivery date.

There is a second category worth naming: anything you expect to be wrong. Early message definitions for a component still being designed should be marked as provisional and revisited, not frozen. Freezing a bad agreement is worse than having no agreement, because people build around it and the eventual change costs more. Standardise what is stable, flag what is not, and be honest about which is which.

What do you give up by standardising early?

You give up speed in the first weeks, and for a very small team that is a real loss. Writing a message definition takes longer than passing a dictionary between two functions, and setting up a shared startup path takes longer than a shell alias. If a project might be abandoned in a month, all of that work is wasted, and pretending otherwise is dishonest.

You also give up some options. A standard is a decision, and a decision made early is made with less information than the same decision made later. Some of what you write down in week two will be wrong, and you will discover which parts in month four.

The third cost is social. Standards create a moment where someone has to say no to a teammate's preference, and teams without the habit find that uncomfortable enough to skip the standard entirely. Naming this out loud helps. The purpose is not that one person's taste wins, but that the robot has one answer instead of four.

When is ROS 2 the better choice?

ROS 2 is the better default for most teams standardising for the first time, and it is the better choice for a wider set of robots than enthusiasm for alternatives suggests. Standardising on ROS 2 gives you message definitions somebody already argued about, a launch system, recording and playback tools, visualisation, and drivers for hardware you have not bought yet. If your robot needs a map, a planned path, or a transform tree keeping track of where the gripper is relative to the base, ROS 2 is the answer and HORUS is not.

Hiring pushes the same direction. Standardising on something a candidate already knows shortens the ramp for a new hire, and the shared vocabulary means a question has a public answer instead of requiring the person who wrote the code. For a team that expects to grow, that is a decisive argument.

The narrow case where the default stops fitting is several programs on one board sharing camera-sized data every cycle, and a team that does not have that case should not go looking for it.

Is standardising early just bureaucracy for a small team?

No, and here is why the accusation misses. Bureaucracy is process that exists for its own sake and costs more than the problem it prevents. What is being described here is four decisions, each of which takes an afternoon, each of which stops a specific failure a small team is guaranteed to hit: the coordinate-frame bug, the person who is the only one who can start the robot, the run that cannot be compared to yesterday's run, the newcomer who takes weeks to become useful.

The test is whether a standard has a named failure behind it. If someone can point to the afternoon that was lost, the standard is earning its keep. If nobody can, it is bureaucracy and should be deleted.

The genuine bureaucracy risk in robotics teams is not too many standards. It is standards nobody maintains, which describe a robot that no longer exists and quietly teach everyone that written agreements are unreliable. One correct page beats ten stale ones.

Does standardising early lock you into one stack?

Partly, but not the way you think. What locks a team in is not the standard; it is how much of the codebase reaches directly for the foundation. A robot where every file imports the middleware is hard to move regardless of how carefully the conventions were written. A robot where message shapes, unit choices and component boundaries are defined separately from the transport carrying them can change foundations at a cost measured in weeks rather than quarters.

So the standard that actually reduces lock-in is the data contract, because data outlives frameworks. Message definitions, units, coordinate conventions and component responsibilities survive a change of middleware nearly intact. Launch mechanics and build tooling do not, and that is fine, because rewriting those is a known quantity.

The teams that get burned are not the ones that standardised. They are the ones that never separated what the robot means from how the robot ships it, and discovered the difference during a migration. Why your robot slows down as you add features is the usual reason that migration turns up in the first place.

How do you decide what to write down this week?

List the last five afternoons your team lost, and standardise only what would have prevented them. This works because it grounds an abstract argument in things everybody already remembers being annoyed about, and because it produces a short list. Most teams find two or three items, and most of those items are the same across teams: message shapes, one startup path, one recording convention, one setup command.

Then give each item an owner and a date, because standards without an owner are wishes. Write each one on a single page, put it in the repository next to the code it describes, and delete it the moment it stops being true. A page that is wrong is worse than no page.

• If you are one person on a prototype -> standardise nothing yet, because the agreement fits in your head.
• If you are two or three people -> message shapes and one startup command, because those are where you already collide.
• If you are onboarding somebody new -> the setup command and a diagram of the robot, because that is the whole first week.
• If your robot needs maps or planning -> standardise on ROS 2, because the ecosystem is most of the value.
• If several programs on one board share large data -> standardise on a shared-memory path, because delivery cost grows with readers.
• If nothing is written down and a deadline is near -> fix the one that is bleeding, because a document nobody reads changes nothing.

The HORUS Fit Framework puts the choice of foundation on five axes worth scoring before you commit: ecosystem size, setup effort, team size fit, deployment target, and licence. For a team standardising early, ecosystem size and team size fit usually decide it, while licence is the axis that gets ignored until a lawyer asks and then decides everything. How do you choose a robotics framework in 2026 works through the same five in more detail.

Whichever way that goes, it is worth knowing what the alternative on your shelf is before the day you need one. Put HORUS on that shelf now: star it so it is in your list when you start building.