Custom robotics: from prototype to small series

Not every problem has a product on the shelf. A sensor that has to fit somewhere no catalog item does, a cart that travels along one specific production line, a data logger that reads an old machine and sends the data to the cloud: that is custom development. It is what we do when a client comes to us with a problem rather than a purchase order.

This article explains how such a project moves, stage by stage, what it demands from the client and where it usually slips. It is for anyone deciding whether a custom build is worth it.

First: does it have to be custom?

The honest question comes before the quote. If there is a ready-made product that solves 90% of the problem, the cost of developing the remaining 10% rarely pays off. A custom project makes sense when:

• the environment is harsh or unusual (dust, water, vibration, temperature, space);
• the equipment to be read has no open interface;
• the volume is too small to interest a large manufacturer and too large for a makeshift fix;
• integration with everything else (platform, ERP, automation) is an essential part of the problem.

When that is the case, the project follows the stages below.

1. Requirements

A site visit, conversations with the people who operate the equipment, measurement of what is already there. The output is a requirements document: what the system does, under what conditions, with what accuracy, how long it runs on battery, how it communicates, who uses the interface and what happens when it fails. It is the cheapest stage and the one that prevents the most rework. A project that skips requirements pays for them on the factory floor.

2. Concept and architecture

Choosing the big pieces: processor or microcontroller, sensors, actuators, radio (cellular, satellite, LoRa, Wi-Fi), power supply, enclosure. This is also where you decide what to build in-house and what to buy ready-made. A pre-certified radio module, for example, saves months of certification work.

3. Mechanics

3D modeling of the structure, enclosure and mounts; choice of materials and ingress protection rating (IP, per IEC 60529); simulation where needed (stress, heat). Prototypes come from 3D printing and machining; the small series from bent sheet metal, machining or a simple mold.

4. Electronics

Schematic, printed circuit board, and components chosen for guaranteed availability (a part that goes end-of-life mid-project is a classic problem). First board run, assembly, bench testing, fixes. It usually takes two or three board revisions to reach the production version.

5. Firmware

The program that runs on the device: reading sensors, driving actuators, communications, power saving, local storage when the network drops, and over-the-air updates so nobody has to drive to the field to fix a bug. When the device talks to our platform, it uses the API or our own protocol (DF-1, over UDP), which already handles authentication and the send queue.

6. Interface

What the user sees: a dashboard on the platform, an app, a display on the device, or nothing more than a WhatsApp alert. Defined early, because it changes what the firmware has to send.

7. Testing and certification

• Field tests in the real environment, long enough to catch the defect that never shows up on the bench.
• Radio certification in each market where the product will be sold: for example, FCC authorization in the US and CE marking under the Radio Equipment Directive in the EU. Using a pre-certified radio module simplifies things, but the final product still has to be assessed.
• Electrical safety and electromagnetic compatibility, depending on the product and its use.

8. Small series

Tens to a few hundred units. The output here is a manufacturing package: board files, bill of materials, assembly and test procedures, packaging. Every unit goes through an automated test before it ships. A small series is not a repeated prototype: the test has to be reproducible and every missing part needs a planned substitute.

What the client needs to bring

• The problem, not the solution. “I need to know when this machine stops” beats “I want a sensor of such-and-such model.”
• Access to the site and the equipment, for the requirements stage and for testing.
• A point of contact who answers questions and signs off on each stage.
• Expected volume and time horizon: 5 units for one plant is one project; 300 for a dealer network is another.
• Constraints: the real deadline, an approximate budget, industry standards, mandatory integration with existing systems.

Timelines, honestly

Requirements and concept take weeks. A working prototype, across electronics, mechanics and firmware, takes months, and the first version is rarely the last. Certification runs on its own calendar, set by the test lab and the certifying body, which does not depend on us. The small series, with the manufacturing package ready, is the most predictable stage.

In our experience, the biggest delays come from requirements that change after the board is done, components that become unavailable, and field tests that are too short.

What to do now

1. Write the problem down on one page: what, where, how often, and what happens today when it fails.
2. List what already exists on site and could be reused.
3. Bring that to a requirements conversation. The conversation produces a scope, and the scope produces a quote per stage.

If you’d like to discuss a project, talk to one of our engineers.

---

Sources: IEC 60529 (degrees of protection provided by enclosures, IP code).