Why Robot Software Is Harder Than Robot Hardware

Robotics demonstrations usually impress mechanically and disappoint behaviourally. The persistent difficulty sits in the software, which must handle a world that refuses to match its model.

Hardware problems converge and software problems do not

Mechanical engineering has mature tools. A joint that flexes too much can be analysed, redesigned and verified against predictions that hold reliably.

Software controlling a physical system faces conditions that were never enumerated, and each fix reveals another situation the designer had not imagined.

Progress therefore looks different. Hardware converges towards a specification while software accumulates handling for cases discovered in the field.

Perception delivers estimates, not facts

Every sensor provides a measurement with error attached, and the software must decide what to believe when readings disagree with each other.

A camera may report an object where a depth sensor reports empty space, and resolving that requires judgement encoded in advance for a situation nobody anticipated.

This uncertainty propagates through every downstream decision, so the whole system must be built to act sensibly on beliefs rather than on facts.

Timing is part of correctness

A control loop that computes the right output too late produces the wrong behaviour, because the world has moved on since the measurement was taken.

Real-time constraints mean that average performance is insufficient; the worst case matters, since a single missed deadline can destabilise a moving machine.

This rules out many conveniences common in other software, including unpredictable memory management and opportunistic background processing.

Failures must be handled, not merely detected

Ordinary software can stop when something goes wrong. A robot holding a load or standing on two legs cannot simply halt without consequence.

Every fault therefore requires a defined safe response, and defining those responses for combinations of faults is where most of the complexity accumulates.

Much of a mature robotics codebase consists of this handling rather than of the behaviour the machine is nominally there to perform.

Integration is where projects stall

Perception, planning, control and safety are usually developed by different people, and each works in isolation before they must operate together continuously.

Interactions between components produce behaviours nobody designed, and reproducing them requires recreating a physical situation rather than replaying a log.

This is why robotics schedules are dominated by integration and testing, and why a working demonstration is a weak predictor of a working product.