From Prototype to Small Series: What Actually Changes in Custom Robot Development

TL;DR: Moving from a single working prototype to a batch of twenty units transforms the custom robot development process from a creative exercise into a repeatable engineering discipline. What changes is not necessarily the robot’s intended function, but everything around it: component sourcing shifts toward long-lifecycle parts, assembly becomes procedural, documentation turns into a controlled artifact, acceptance testing gets formalized, and serviceability becomes a design constraint. This article breaks down what each of those shifts looks like in practice for mobile UGV platforms running ROS 2.

Why the Jump From One Unit to Twenty Breaks Naive Assumptions

A prototype proves that an idea works. A small series proves that the idea works twenty times, in representative environments, assembled by people who did not design it. That is a different engineering problem, and it reshapes the custom robot development process from the bill of materials up.

On a one-off build, you can accept a stepper driver that only one distributor stocks, hand-tune each motor’s PID loop, and keep the wiring diagram in the lead engineer’s head. On unit seven of twenty, that same distributor may be out of stock for fourteen weeks, the tuning notes may be missing, and the person soldering the harness may have never seen the robot before. The technical work does not get harder in principle. It gets harder to keep consistent.

Fictionlab works with clients moving from validated Leo Rover or Raph Rover configurations into fleet deployments. The patterns below reflect common small-series engineering requirements.

How Repeatability of Assembly Becomes a Design Requirement

In prototype phase, assembly is tribal knowledge. One engineer knows that the IMU cable has to route under the DC-DC converter, not over it, otherwise EMI may affect magnetometer readings. In a series of twenty, that knowledge has to leave their head and enter a work instruction.

Concretely, the custom robot development process at series scale enforces:

• Keyed and labeled connectors. If two connectors have the same shell but different pinouts, someone can swap them. Connector keying, clear labels, and color-coded harness identification reduce this risk.
• Torque-specified fasteners. Motor mount screws on a Leo Rover chassis get a target torque, not “snug.” This matters when a robot vibrates for 200 hours in a field trial.
• Jigs for repeatable alignment. Wheel hub concentricity, camera pitch angle, LiDAR yaw offset – all of these can require fixtures rather than eyeballing.
• Firmware flashing scripts, not manual steps. A single command can flash the MCU, verify the programmed firmware using a checksum or hash, and log the serial number to a build database.

The output is not a fancier robot. It is twenty robots where unit 20 behaves comparably to unit 1 within defined acceptance limits.

What Component Selection Looks Like When Lifecycle Matters

Prototype BOMs optimize for “available now.” Small-series BOMs optimize for “available in 18 months, and the month after that.” This is one of the most underestimated shifts in the custom robot development process.

Practical decisions that change:

• Silicon with published longevity commitments. Industrial microcontrollers from vendors such as STMicroelectronics or NXP may be covered by published longevity programs, often spanning 10 years or more for selected products. Consumer-grade parts may not have equivalent availability commitments. For a robot expected to ship over two years, that difference is not academic.
• Second-source qualification or supply-risk mitigation. Critical parts should have a qualified alternate where practical, or a documented mitigation plan where a drop-in alternate is not feasible. For example, alternate motors must be assessed for mechanical fit, electrical characteristics, control behavior, and acceptance criteria.
• Avoiding hobby-grade sensors in critical roles. A prototype can use an unbranded IMU breakout board. A series robot uses a part with a datasheet, an errata sheet where applicable, and a known temperature-drift specification.
• Connector families with distributor depth. Choosing a connector because it is 30 percent cheaper only helps until the one distributor that stocks it delists it.

For customers building on Fictionlab’s Raph Rover or Leo Rover platforms, an existing base chassis can reduce work on the core mobility stack, provided that its specifications, supply chain, and compliance requirements match the intended deployment.

How Documentation Shifts From Notes to a Controlled Artifact

Prototype documentation is a README, a wiring photo, and a Slack thread. Series documentation is versioned, reviewed, and matched to a specific hardware revision.

The minimum set for a small series typically includes:

1. A released BOM with revision number and approved manufacturer part numbers. Not “a 5V regulator” but a specific MPN and approved revision.
2. Assembly work instructions with photographs of each step. Written so an assembler who has never seen the robot can complete a unit correctly.
3. A wiring schematic and harness drawing. Separate documents, both under revision control.
4. A firmware and ROS 2 software manifest. Which package versions, which DDS implementation, which QoS profiles, and which source revisions or container images are approved for release.
5. A serial-number-linked build record. For unit 14, which motor batch, which firmware hash, which calibration values.

This is the documentation that turns a warranty claim two years later from a forensic exercise into a lookup.

What Acceptance Testing Actually Covers at Series Scale

A prototype gets accepted when it demonstrates the required behavior once, in the lab. A series unit gets accepted against a written test procedure that produces a pass/fail record for every unit shipped.

A realistic acceptance test suite for a ROS 2-based mobile robot in field robotics contexts can include:

• Electrical checks. Bus voltages under load, current draw at idle and at maximum traction effort, and, where required by the electrical design, insulation or isolation checks between the chassis and electronics ground.
• Motion tests. Straight-line drift over a defined distance, turning-radius symmetry, maximum grade at rated payload. Numbers get logged, not just observed.
• Sensor calibration verification. IMU bias within specification, camera intrinsics matching the stored calibration file, and LiDAR performance against a defined reference target where applicable.
• ROS 2 stack self-check. All expected topics publishing at expected rates, required nodes reporting healthy through a defined diagnostics interface, and DDS discovery converging within a defined time window.
• Environmental burn-in. A defined period of continuous operation, ideally with temperature cycling if the deployment environment warrants it.

The test procedure itself becomes a deliverable. When a customer’s integrator asks “how do you know unit 11 is good,” the answer is the signed test record for unit 11.

Why Serviceability Has to Be Designed In, Not Bolted On

One prototype gets serviced by the person who built it. Twenty deployed units get serviced by technicians who may be on a different continent. Serviceability stops being a nice-to-have and becomes a design input.

Practical decisions that reflect this:

• Modular subassemblies. A motor and its driver can be designed as a replaceable unit rather than a soldered-in subsystem. Field replacement in under an hour can be preferable to a two-week RMA.
• Diagnostic access without disassembly. A service port that exposes CAN or Ethernet without opening the chassis. A status LED pattern that means something specific.
• Spare parts kits defined at ship time. Not “we’ll figure out spares later.” A defined list of consumables and likely-failure parts, sourced against the same long-lifecycle criteria as the original build.
• Remote diagnostics over ROS 2. If designed and configured for it, a rolling rosbag buffer containing the last N minutes before a fault can be retrieved without physical access. This can reduce the number of issues that require a technician visit.

Serviceability decisions made at the design stage cost engineering time. Serviceability decisions deferred until deployment cost field trips.

Where This Applies in Industrial Deployments

The shifts above show up most sharply when mobile robots move into repeatable roles – inspection routes, sample collection, sensor carrying in industrial environments. Fictionlab’s work in industrial applications and broader custom robotics projects reflects a common challenge: the gap between “we have a working robot” and “we have twenty working robots” is often where projects stall. Closing that gap is engineering work, not marketing work.

Frequently Asked Questions

At what quantity does the custom robot development process actually change?

In practice, the shift often starts around five to ten units, although it depends on product complexity, team size, and regulatory requirements. At that point, undocumented decisions can start producing units that behave differently from each other.

How much longer does a small series take compared to a prototype?

The first unit of a series often takes longer than the original prototype, because documentation, jigs, and test procedures are being built alongside it. Units two through twenty can then move faster. Total calendar time depends heavily on component lead times, which can range from weeks to many months.

Can a prototype BOM be reused for a small series?

Rarely without changes. Prototype BOMs typically contain parts chosen for availability at a single point in time. A series BOM has to be reviewed for lifecycle status, alternate sources or mitigation plans, and connector standardization.

What role does ROS 2 play in series repeatability?

ROS 2 can help because its launch, parameter, diagnostics, and communication configurations can be made inspectable and reproducible. Pinned package versions, defined QoS profiles, and standardized diagnostics interfaces mean that “is this unit configured correctly” can become a scriptable check rather than a manual inspection.

Is it cheaper to start from an existing platform than to design from scratch?

For many small-series projects, starting from a validated base platform such as Leo Rover or Raph Rover can reduce development time and risk in the mobility, power, and core-electronics layers. Whether it is cheaper depends on the required payload, environmental performance, supply-chain needs, compliance requirements, and level of customization.

What documentation should exist before series production starts?

At minimum: a released BOM with MPNs, assembly work instructions, wiring and schematic drawings under revision control, a software manifest pinned to specific versions or source revisions, and a written acceptance test procedure. Without these, unit-to-unit consistency is difficult to demonstrate.

How is field serviceability tested before deployment?

Typically by having someone other than the design engineer perform a defined service task – replacing a motor, swapping a sensor, updating firmware – using only the shipped documentation and tools. If they cannot complete it, the design or the documentation is not ready.

Take the Next Step

If you are evaluating whether your project is ready to move from a working prototype to a repeatable small series, Fictionlab’s engineering team works on exactly this transition. Learn more about the process and current capabilities at Fictionlab Custom Robotics.