How to Budget Time for Robot Software Integration

Budget most of the schedule for integration, not for writing code: whether you build on ROS 2 or HORUS, joining the parts dominates. Every part works alone; the cost is in what happens when parts run at the same time, on the real machine, at the moments they actually need each other. The verdict flips only when your robot is one program on one board. This post is for a team writing a plan somebody will hold you to, who need to know where the weeks actually go.

The plan looked reasonable when you wrote it. Driver, two weeks. Perception, three. Controller, three. Behaviour logic, two. Somebody added a week at the end labelled integration and testing, and everybody nodded, because nodding was easier than arguing about a word nobody had defined.

Every one of those parts finished roughly on time. That is the part that makes this confusing. The driver works, and you can prove it. The controller holds position on the bench. The perception code finds the object in a recorded file, every time, exactly as designed. Then you run all four at once on the actual robot and the arm hesitates before it grips, the camera process pushes everything else late whenever the scene gets busy, and the whole thing only starts correctly if you launch things in an order that one person knows and nobody wrote down.

Now you are three weeks into the one-week integration slot. Nothing is broken, exactly. There is just a growing list of small things, none of which is anybody's fault, and none of which was in the plan.

How much of a robot project's schedule should be integration?

Plan for integration to be the largest single block in the schedule, larger than any part you are building. The habit that produces bad robot plans is estimating from components, because components are what an engineer can picture: a driver has a shape, a filter has a shape, a planner has a shape. The joining has no shape until you are inside it, so it gets a week at the end and a hopeful adjective.

A better default is to treat every interface between parts as a task with its own estimate, the same way you would treat the parts. Two processes that must exchange data are not free just because both processes exist. Somebody has to decide what the message contains, what happens when it stops arriving, who starts first, and what the robot does when one side dies.

The useful reframe is that a robot is not a set of parts plus glue. A robot is a set of agreements between parts, and the parts are the easy half. Teams who plan that way overrun less, not because they are faster but because they stopped hiding the expensive work inside a one-word label.

What does integration actually mean on a robot?

Integration is everything that only becomes true when the pieces run together on the real machine at the same time. It is not a testing phase and it is not a merge. It is the discovery of every assumption each part made privately while nobody was checking.

Concretely, it is start-up order and what happens in the first second after power. It is units, sign conventions and coordinate frames, which is why an arm confidently moves in exactly the wrong direction on day one. It is what a process does when the data it expects stops arriving, which is usually nothing sensible unless somebody decided otherwise. It is configuration, which begins as three sensible values and becomes a file nobody fully understands. It is how a run is recorded so it can be replayed at a desk on Monday, and whether the recording contains enough to explain a fault.

And it is timing: which piece runs when, and what happens to everything else when one piece gets busy. That last one is the item that turns a two-week slip into a two-month one, because it looks like a bug in whichever part you happen to be watching.

What are your options for reducing integration time?

You have five real levers, and choosing a stack is only one of them. You can lean on an ecosystem, most obviously ROS 2, so that drivers, visualisation, recording and simulator bridges already exist and the joining work you keep is your own. You can shorten the timing conversation by putting the processes that share a deadline onto a shared-memory middleware such as HORUS, where Rust, Python and C++ read from the same ring buffers so messages between processes on one machine are not serialised; it is Apache-2.0, open source, validated in simulation, and it does nothing about drivers, mapping or the week your units are wrong. You can reduce the number of interfaces by merging processes, which trades isolation for fewer agreements to maintain. You can integrate continuously instead of at the end, joining two parts the day the second one compiles rather than waiting for all four. Or you can buy the problem away by building on a vendor's SDK, where the parts already talk, and accept that the vendor now owns your interfaces.

How do the integration approaches compare?

Match the last column against your situation first; whatever survives is where your schedule should be shaped.

None of these removes integration. Each one moves it somewhere you would rather pay for it.

What do teams try first, and why does the estimate slip anyway?

Almost every team tries the same three things, in the same order, and each one buys real time before running out. First, integrate at the end, because that is how the plan was drawn. This works while the parts are simple and fails the first time two parts disagree about something structural, at which point one of them gets rewritten and its original estimate becomes fiction.

Second, merge processes so there are fewer boundaries to argue about. This genuinely helps and is hard to criticise. The cost arrives later, when you can no longer restart one part without restarting everything, and a crash in a minor component takes the robot down mid-motion.

Third, turn things off. Logging is usually first, which is unfortunate, because logging is how you find the next problem. Then visualisation. Then the update rate on something that seemed unimportant.

The pattern worth noticing is not that these fail. Each works. It is that the fix list gradually stops mentioning the robot and starts describing your own plumbing, which is what a stalling project looks like from inside long before anybody says the word stalled.

Are you a solo builder, a small team, or a company with a hardware group?

Team size changes what integration costs more than the technology does. A solo builder holds every interface in one head, which is why one-person robots come together startlingly fast and then become unmaintainable the moment a second person arrives. If you are alone, your integration budget is small and your documentation budget should not be, because your future self is effectively a new hire.

Two to five people is where integration becomes the dominant cost and nobody notices. Everybody is building a part. The agreements between parts belong to nobody. The classic failure is two engineers who both finished on time and disagree about what the message means, discovered in week nine.

A company with a separate hardware group pays a different tax again: the software schedule now depends on a machine that does not exist yet, arrives late, and behaves unlike the model. Here the useful move is to make as many agreements as possible before the robot arrives, and to accept that the week it does arrive is a phase, not a task. Small teams often move faster here precisely because fewer handoffs means fewer agreements to renegotiate.

Does your hardware change the integration budget?

The hardware sets the shape of the budget before anybody writes a line. One Linux board with several processes sharing it puts the whole cost in how those processes behave when the machine gets busy, which is the most controllable and most frequently underestimated item on any robot plan. It is also the case where a stack choice actually moves the number.

Several boards on a network moves the cost to the link. Messages that cross a cable are limited by that cable, and nothing you change locally helps. Budget for network behaviour under load, for what each side does when the link drops, and for the fact that debugging across machines is slower than debugging on one.

A microcontroller beside the motor changes the budget again. The tight loop gets easier, because it is short and local. The expensive item becomes the boundary: what runs on the small board, what runs on Linux, how they agree, and how you update firmware on a robot that is already in a customer's building. Teams routinely budget the loop and forget the boundary, and the boundary is where the surprises live.

How does the deadline change what you should plan for?

The deadline decides which integration work you are allowed to skip. Three weeks from a demo, you should be integrating continuously and building nothing new. Take whatever already has drivers for your hardware, accept every overhead, and get the machine moving, because a demo that exists beats a design that is correct. Skip the recording tools, skip the clean configuration, and write down what you skipped.

A quarter changes the arithmetic. Now you can afford to do one thing properly, and the right one is usually whatever the audience will notice: motion quality, or the robot recovering from something going wrong instead of stopping dead. Do that one well and leave the rest crude.

A year to a product inverts everything. The dominant cost is no longer the first integration but the twentieth: updating deployed units, reproducing a customer's fault, onboarding an engineer who was not there when the decisions were made. Budget for the tooling that makes those cheap, because those are the weeks that quietly consume year two, and nobody ever schedules them in year one.

How much systems experience does the team need for integration to go to plan?

You need one person who is comfortable below your own code, and the plan should assume you sometimes will not have them. Most integration work is ordinary: agree the message, agree the units, agree who starts first, write it down. Any competent engineer does that well with a checklist.

The specialist matters in a narrower window. When a fault lives underneath the code you wrote, in a dependency or in how processes hand data to each other, somebody has to open that layer and form an opinion. A team with nobody who will do that has a schedule with an unbounded item in it, because the fallback is waiting for a stranger on the internet.

Coding assistants change this less than teams hope. They are genuinely helpful for the ordinary parts, writing the adapter, drafting the launch configuration, explaining an unfamiliar file. They are least helpful precisely where integration hurts, because the hard problems are about your specific hardware behaving in a way that appears in no documentation and no training data.

What do you give up by planning for integration up front?

Planning integration honestly costs you the appearance of speed, and that cost is political rather than technical. A plan that puts a large block in the middle labelled joining the parts looks slower than one that lists four components and a week of testing, even though the honest plan is the one that will finish nearer its date. Somebody will ask why the schedule has so much slack in it, and slack is the wrong word but it is the word they will use.

You also give up some flexibility. Agreeing interfaces early means changing them later is a negotiation rather than an edit, and there are projects where that rigidity is genuinely the wrong trade, particularly research work where the goal moves every fortnight.

And you spend real time on things with nothing to show. Nobody demonstrates a recording format. Nobody films the start-up order. The payoff arrives months later, invisibly, as problems that did not happen, which is the least persuasive form of value there is and the reason this work keeps getting cut.

When is ROS 2 the better choice?

ROS 2 is the better choice when most of your integration cost is work somebody has already done, and HORUS is not the answer when what you need is packages rather than a transport. If the robot must map a building and navigate it, adopting an existing navigation stack removes months you would otherwise spend re-deriving it. If your sensor vendor ships a driver, using it removes a fortnight of datasheet reading. If you need visualisation, recording and a simulator bridge in the same quarter, the ecosystem is the schedule.

ROS 2 also wins on people, which shows up directly in integration time. New hires arrive already knowing the conventions. A contractor can be useful in a week. Your error message has probably been posted and answered by a stranger, which is worth more during a bad week than any technical property.

And if your robot is spread across machines, the network is your constraint and local message handling is not the thing to optimise. Budget for the link, and use the stack with the most existing parts.

Can you avoid integration time by keeping everything in one process?

No, and here is why: one process removes the boundaries between programs and leaves every other agreement exactly where it was. Units are still wrong. Coordinate frames still disagree. The controller still runs at a different rate than perception, and now that conflict lives inside one program where it is harder to see rather than between two where it is at least visible.

Single-process robots are a genuinely good choice for small machines, and they are chosen too rarely. What they buy is fewer things to start, fewer places for data to be copied, and one place to look when something fails. What they do not buy is a shorter list of assumptions.

They also introduce their own schedule risk, which arrives later. One crash takes the entire robot down mid-motion instead of one behaviour. Two engineers working in the same file conflict constantly. Replaying a recorded run becomes harder because there is no boundary at which to record. Plan for one process when the robot is small and the team is one or two people, and plan honestly for what happens when either of those stops being true.

Is integration just testing under another name?

Partly, but not the way you think: testing tells you whether something works, and integration decides what working means. When two parts meet for the first time, the questions are not pass or fail. They are what should this message contain, what should happen when it stops, who owns the retry, what the robot does if perception is late, and whether late is even defined.

Those are design decisions, made under time pressure, usually by whoever is at the bench. That is why integration cannot be delegated to a testing phase at the end: by then the decisions have been made accidentally, and the accidental ones are the ones that stay for years.

The practical consequence for a plan is that integration needs senior attention, not a week of somebody running through a list. It also needs the boring infrastructure early, because you cannot decide what late means if you cannot see a run afterwards. Teams that skip recording and replay pay for it during the phase where simulation and hardware disagree and nobody can prove which one is wrong.

How do you turn all of this into a schedule you can defend?

Build the plan from interfaces rather than components, and put a named owner on each one. List every pair of parts that must exchange something, and give each pair a line in the plan: what the message contains, who starts first, what happens when it stops. That list is usually longer than the component list, which is the entire point, and it is the fastest way to show somebody why the schedule looks the way it does.

Then front-load the three things that make everything after them cheaper. Get a clean checkout building on a machine nobody has touched. Get a run recorded and replayed at a desk. Get the robot moving badly, end to end, as early as possible, because an ugly complete loop teaches more than four polished parts.

Finally, schedule bring-up as a phase and not a task, and expect the week the hardware arrives to produce its own bug list. If you need to defend the shape of that plan to somebody outside the team, the same reasoning is what a technical investor is listening for.

Here is the whole decision in five lines.

• If you are three weeks from a demo -> integrate continuously and build nothing new, because a demo that exists beats a design that is correct.
• If two engineers each own a part -> put a named owner on the interface between them, because the gap is where the schedule disappears.
• If everything runs on one machine and one loop keeps missing -> budget for the transport, because that is the class of problem it addresses.
• If your robot spans several machines -> budget for the link, because nothing local touches it.
• If the hardware has not arrived -> budget bring-up as a phase, because every assumption made in simulation gets tested in the same week.

The HORUS Fit Framework compresses the choice into five axes: ecosystem size, setup effort, team size fit, deployment target, and licence. Score every candidate on all five and pick the one that is not weak on the axis you cannot afford to lose, because that axis is where your integration weeks will go. If timing on one machine is the axis your plan keeps stumbling over, put HORUS on the reading list before the next planning session: star it so it is in your list when you start building.