From Idea to Proof-of-Concept Robot: How a Robotics R&D Project Runs Step by Step

TL;DR: The robotics proof of concept process turns a vague idea into a working proof of concept robot that answers one question: does this approach survive contact with reality? A typical run has six stages – requirements and success criteria, base platform selection, integration, lab and field testing, iteration, and a go/no-go decision. The goal is not a product. The goal is evidence. Using an existing mobile robot base such as the Leo Rover can remove months of chassis, drivetrain, and ROS 2 bring-up work so the team spends its budget on the part nobody has solved yet: the payload, the autonomy stack, or the mission logic.

Why does the robotics proof of concept process exist at all?

Robotics ideas often fail because the sensor does not see what you assumed it sees, the environment is rougher than the lab, or the economics collapse once you count integration hours. A proof of concept (PoC) exists to find out which of these is true before the budget is spent.

A PoC is not necessarily a prototype in the manufacturing sense. A prototype may be a candidate for a product and can anticipate assembly, serviceability, certification, and unit cost. A PoC is an experiment with wheels. It can have exposed cables, an oversized battery, and a laptop strapped to the top plate. What it cannot have is an unclear question. If you cannot write down the single statement the PoC will prove or disprove, the robotics proof of concept process has not started yet.

The transition from a validated PoC to a small production series is a separate discipline with its own rules – design for assembly, supplier qualification, EMC testing, documentation. This article stops at the go/no-go gate. Everything after that gate belongs to a different conversation.

What does stage one look like: requirements and success criteria?

The first stage of the robotics proof of concept process is the only one where writing is more productive than building. The output is a short document, usually two to four pages, that the whole team agrees on.

Before touching hardware, the team needs answers to a specific set of questions:

• What is the mission? Not “inspect a warehouse” but “traverse 400 m of concrete aisle, stop at 12 marked positions, capture a thermal image of each, return to dock.”
• What is the environment? Surface type, gradient, obstacle height, lighting, temperature range, dust, water exposure, GNSS availability, Wi-Fi coverage.
• What must the robot carry? Mass, dimensions, mounting geometry, power draw, data interface, and whether the payload needs vibration isolation.
• What counts as success? Measurable thresholds, not adjectives. “Detection recall above 90% on the validation set across 50 runs” is a criterion. “Works reliably” is not.
• What is explicitly out of scope? Multi-robot coordination, fleet management, certification, enclosure IP rating – list what the PoC will not attempt.

Success criteria deserve extra attention. A useful criterion has a number, a unit, a sample size, and a condition. Teams that skip this step end up in an argument six months later about whether the robot “worked,” with no shared definition to appeal to.

How do you handle unknowns in the requirements?

Some parameters cannot be known upfront. That is normal. Mark them as assumptions with a planned resolution point. For example: “Assume LiDAR localization holds in the aisle; verify in week 3 field test; fallback is fiducial markers.” An assumption with an owner and a deadline is manageable. An assumption nobody wrote down is a risk that surfaces during the demo.

How do you choose a base platform for a proof of concept robot?

The second stage of the robotics proof of concept process is a build-versus-integrate decision. Designing a mobile base from scratch means motors, gearboxes, wheel hubs, suspension geometry, motor controllers, battery management, chassis machining, waterproofing, wiring harnesses, and then the software layer on top of all of it. For a team whose actual research question concerns a sensor payload or an autonomy algorithm, that can mean months of work on mature engineering problems rather than the core research question.

Use an existing platform when the following conditions hold:

• The payload fits within the platform’s published mass and volume limits, with margin.
• The terrain the mission requires falls inside the platform’s documented capability.
• The platform ships with a maintained ROS 2 stack, so you inherit drivers, TF tree, odometry, and teleoperation rather than writing them.
• Mechanical and electrical interfaces are documented and open, so adding a mount or tapping power does not require reverse engineering.
• Spare parts are available, because a PoC that is blocked for three weeks on a broken wheel hub is a PoC that misses its gate.

The Leo Rover was designed around this pattern. It is an open-source four-wheel-drive outdoor platform with ROS 2 support, published mechanical interfaces, and a documented payload allowance, which makes it usable as an integration substrate rather than a finished product. Raph Rover extends the same philosophy to heavier payloads and rougher terrain. For requirements that genuinely fall outside what any off-the-shelf base can do – unusual footprint, extreme ingress protection, specialized kinematics – a custom robotics path based on an existing design can be faster than starting from a blank sheet.

One warning: do not choose the platform before writing the success criteria. Teams that pick hardware first tend to retrofit the requirements to match what they bought.

What happens during integration?

Integration is where the robotics proof of concept process stops being a document and starts producing failures you can learn from. It splits into three tracks that run in parallel.

Mechanical integration

Mount the payload. Check that the center of mass has not moved far enough to compromise stability on the gradients in the requirements. Verify that the sensor’s field of view is not occluded by the chassis, the mast, or its own cabling. Confirm that connectors are strain-relieved – on a mobile robot, vibration can damage connectors long before it damages electronics.

Electrical integration

Work out the power budget before wiring anything. Estimate the continuous and peak draw of the payload, the compute unit, and the drivetrain under worst-case load. Compare energy consumption with battery capacity to estimate endurance, and compare current and voltage requirements with the platform’s documented power rails. If the payload needs a voltage the platform does not provide, specify the converter at this stage rather than improvising later. Measure actual current draw once the system runs; estimated draw and measured draw often differ noticeably.

Software integration

This is usually the longest track. In a ROS 2 system the work typically includes:

1. Bringing up the payload driver as a ROS 2 node with QoS settings appropriate to its data rate and reliability and latency requirements.
2. Extending the URDF and TF tree so the payload frame is correctly positioned relative to base_link.
3. Calibrating extrinsics between the payload sensor and relevant existing sensor frames or the robot base frame.
4. Configuring the navigation stack – costmap layers, footprint, velocity limits, recovery behaviors.
5. Setting up logging with ros2 bag so every test run can be analyzed offline.

That last point is underrated. Recorded bags let the team replay relevant field data on a desk, which can turn a one-hour trip to the test site into a two-minute analysis loop.

How should lab testing differ from field testing?

Lab and field tests answer different questions, and running them in the wrong order wastes field days.

Lab testing is about control. You control lighting, surface, and temperature, so when something breaks you can isolate likely causes more easily. Lab work covers driver stability, node restart behavior, latency under full sensor load, thermal behavior of the compute unit under sustained processing, and basic battery endurance on a flat surface. A useful lab milestone is a continuous multi-hour run with no node crashes and no unexplained CPU spikes.

Field testing is about the variables you cannot simulate. Outdoor surfaces, real lighting, real GNSS multipath, real dust and moisture. Expect field conditions to break assumptions that held perfectly indoors – wheel odometry drifts differently on gravel than on epoxy floor, and a camera exposure setting tuned under office lighting will saturate in direct sun.

Make field sessions structured rather than exploratory. Each session should have a written test plan listing the runs, the conditions, the data to record, and the pass thresholds from stage one. Record bags for every run, photograph the setup, and log environmental conditions. Field days are expensive; unstructured ones produce anecdotes instead of evidence.

What belongs in a test log?

A minimum viable test log for each run contains the run identifier, date and time, weather and surface conditions, software commit hash, hardware configuration, the measured values against each success criterion, and a free-text note on anything unexpected. Mark approximate measurements as approximate. A PoC report that reports a figure without stating how it was measured is not evidence that anyone downstream can rely on.

Why are iterations the core of the process, not a sign of failure?

The robotics proof of concept process is iterative by design. A realistic project may run three to five cycles of build, test, analyze, modify. Each cycle should be short – two to four weeks can be a practical rhythm for integration work on an existing base – and each should close with a written decision about what changed and why.

Typical iteration triggers in mobile robot work include the payload mount transmitting too much vibration into the sensor, the localization stack losing track in a feature-poor corridor, the power budget being tighter than estimated under real load, or a detection model performing worse on field data than on the curated training set. None of these automatically mean the concept is wrong. They may mean the first implementation was.

Discipline matters here. Change one significant variable per iteration where feasible. If the mount, the exposure settings, and the navigation parameters all change between run 4 and run 5, the resulting improvement cannot be attributed to anything.

It is also worth distinguishing between iterations that improve the implementation and iterations that redefine the question. The first kind is healthy. The second kind – quietly relaxing success criteria so the current build passes – is how PoCs produce false positives that cost far more later. If criteria genuinely need to change because the requirements were wrong, change them explicitly and document the reasoning.

What does a go/no-go decision actually decide?

The gate at the end of the robotics proof of concept process is a decision about evidence, not enthusiasm. The team compares measured results against the criteria written in stage one and picks one of three outcomes.

• Go. The criteria were met with margin, the failure modes are understood well enough for the next phase, and the evidence supports further development. The project moves toward a prototype that anticipates production.
• No-go. A criterion failed for a structural reason – the physics does not work, the sensor cannot resolve what the mission requires, or the cost per unit of capability is not viable. This is a successful PoC. It cost a fraction of a product program and saved the rest.
• Pivot. The original mission is not achievable, but the testing revealed a different problem the system solves well. This is common and worth taking seriously rather than treating as a consolation prize.

A good gate review produces a written report containing the original criteria, the measured results, the test conditions, the known limitations, and an explicit list of what was not tested. That last section is what protects the next phase from inheriting unexamined assumptions. Teams working on industrial robotics applications often find that the “not tested” list – duty cycle over months, behavior during shift changes, operator error handling – becomes the agenda for the following phase.

What should you expect from an R&D partner?

If the project runs with an external robotics partner, a few expectations are reasonable to set before work starts.

• Written success criteria before build. A partner who starts building before the criteria are agreed may make it harder to determine whether the work answered the intended question.
• Access to raw data. Bags, logs, and measurements should be available to you under the agreed contract terms, not only summarized into a slide deck.
• Honest failure reporting. Field tests fail. A partner who never reports a failed run may not be testing hard enough or may not be giving you a complete picture.
• Documented interfaces. Mechanical drawings, wiring diagrams, and ROS 2 topic and parameter documentation for anything they build, so your team can maintain it afterward.
• Clear IP and ownership terms. Agreed before the first iteration, covering source code, designs, and recorded data.
• A defined stopping point. The scope should end at the go/no-go gate, with a separate agreement for anything beyond it.

Open hardware and open software matter more here than they might appear. If the base platform’s CAD, electrical interfaces, and ROS 2 packages are public and their licences permit the intended use, your team can inspect, modify, and maintain the system with less dependence on a single supplier.

FAQ

How long does a robotics proof of concept take?

It depends heavily on how much is genuinely new. Projects that integrate a known payload onto an existing ROS 2 mobile base, with clear criteria, can run in the range of two to four months including field testing. Projects that require new mechanics, new autonomy behaviors, and new sensing simultaneously take longer because each unknown can multiply the iteration count rather than simply adding to it.

What is the difference between a proof of concept and a prototype?

A PoC primarily answers “is this possible and does it meet the criteria?” using a hardware configuration that is fast to build. A prototype can serve many purposes, including validating manufacturability, serviceability, certification, assembly cost, and part availability. In practice, the terms can overlap, so the important distinction is the question being tested and the constraints imposed on the build.

Can you skip the PoC and go straight to a prototype?

You can, if the technical risk is genuinely low – for example, a configuration your team has already deployed and is only adapting slightly. When any of the sensing, autonomy, or environment is unproven, skipping the PoC moves the discovery of that risk to a stage where changes cost far more.

Why use an off-the-shelf platform rather than building a custom chassis?

Because chassis, drivetrain, power, and base ROS 2 bring-up are often mature engineering problems that can consume a large share of a PoC budget without producing new knowledge. Using a documented base such as the Leo Rover concentrates effort on the part of the system that carries the actual research question. A custom chassis makes sense when the requirements fall outside what any available platform can do, and even then starting from a proven design can be faster than a blank sheet.

How many field tests are enough?

Enough to produce a statistically meaningful sample against each success criterion under the conditions listed in the requirements. A single successful run proves little about reliability. Repeated runs across varied conditions – different times of day, different surface states, different payload configurations – are what distinguish evidence from a demo.

What is the most common reason a PoC produces an unclear result?

Vague success criteria. When the threshold was never written down with a number and a condition, the final review turns into an opinion exercise. Another common reason is changing multiple variables per iteration, which makes it impossible to attribute improvements or regressions to any specific change.

Who should own the data and code produced during a PoC?

Settle this in the contract before the first iteration. At minimum, the organization funding the work should secure the rights to the recorded datasets, test reports, and integration code needed to continue the project. Ambiguity here becomes expensive at exactly the moment the project succeeds.

Where to go next

If your team has an idea that needs testing on real hardware in real conditions, integrating onto a proven, open mobile base can be faster than building one from scratch. Fictionlab’s team runs this process on Leo Rover and Raph Rover platforms, from requirements definition through field validation. Explore Fictionlab’s custom robotics services to discuss how your concept maps onto an existing platform and what a PoC scope would look like.