From CAD to Field Deployment

Executive summary

A robot is not a commercial product merely because one prototype can complete a successful demonstration. Field readiness requires the mechanical, electrical, embedded, autonomy and manufacturing systems to operate together within defined performance and safety limits. Those limits must remain controlled despite variation in parts, suppliers, assembly, calibration, software releases and operating conditions.

For an early-stage physical AI company, the central engineering challenge is therefore not simply obtaining motors, reducers, cameras, batteries or machined parts. It is owning the system definition: requirements, interfaces, failure responses, configuration, calibration and evidence of conformity. Suppliers may manufacture individual parts, but the startup must define what a conforming robot is.

Southeast Asia provides a potentially strong environment for this model. China's Greater Bay Area offers dense access to electronics, sensors, specialised mechatronic parts and rapid manufacturing services. Thailand's Eastern Economic Corridor positions automation and robotics alongside established automotive and electronics capabilities. However, geography is not a sufficient qualification criterion. A supplier must be evaluated against technical capability, traceability, process control, engineering change management, lifecycle support and total landed risk.

The central thesis of this playbook is that the most resilient strategy iscapability-led and risk-based sourcing. A startup should allocate each subsystem according to:

1. iteration speed;
2. technical differentiation;
3. qualification burden;
4. intellectual-property sensitivity;
5. logistics exposure;
6. quality-system maturity;
7. second-source availability;
8. service and lifecycle responsibility.

This playbook presents a practical route from mission definition to pilot deployment. It sets out an architecture method, sourcing matrix, BOM and configuration model, actuator and power-system considerations, calibration and HIL strategy, safety and reliability framework, lifecycle gates, production controls and field-support model. The objective is not merely to build a faster prototype. It is to create an engineering system capable of producing robots that behave consistently in the real world.

Why physical AI hardware fails between demo and deployment

Physical AI connects perception, decision-making and learned or programmed behaviour to machines that exchange energy with the real world. Unlike a purely digital service, a robot must tolerate friction, backlash, impact, thermal limits, sensor drift, power transients, component variation and human interaction.

The gap between prototype and product commonly emerges in six areas:

A successful development programme makes these uncertainties visible and retires them through evidence.

Define the mission before selecting hardware

Operational design domain

The operational design domain, or ODD, defines the conditions in which the robot is intended to operate. Before choosing an actuator, sensor or compute platform, the team should document:

• indoor, outdoor or mixed operation;
• temperature, humidity, dust, water and chemical exposure;
• floor material, gaps, ramps, thresholds and slopes;
• expected lighting and acoustic conditions;
• human proximity and access;
• task payload, reach and manipulation envelope;
• travel speed and stopping constraints;
• continuous and peak duty cycles;
• operating hours and charging opportunities;
• network availability and loss-of-connectivity behaviour;
• operator and maintenance skill levels;
• cleaning and decontamination expectations;
• transport, storage and installation conditions;
• expected product and service life.

The ODD should describe both intended use and reasonably foreseeable misuse. If a mobile platform is intended for a controlled factory aisle, operation in public areas, on wet ramps or around children should not be accepted silently as an extension of the same use case.

System key performance parameters

A useful requirement is measurable and linked to a verification method. The following structure provides a starting point.

Reference system architecture

For this playbook, the reference robot includes:

1. a wheeled mobile base;
2. one multi-axis robotic arm;
3. an interchangeable end effector;
4. LiDAR and depth or stereo vision;
5. joint, wheel and inertial sensing;
6. onboard compute and embedded controllers;
7. a rechargeable battery and power-distribution system;
8. real-time control, diagnostic and autonomy networks;
9. protective and safety-related functions appropriate to the application;
10. calibration, end-of-line test and service interfaces.

The architecture should be documented through five complementary views:

• functional view: what the robot must do;
• physical view: where functions are implemented;
• energy view: how electrical and mechanical energy flows;
• information view: commands, feedback, timing and data ownership;
• safety view: hazards, protective functions and safe-state transitions.

A capability-led China–Thailand sourcing strategy

Replace country labels with allocation criteria

The intuitive sourcing hypothesis is useful: China can provide rapid access to active mechatronics, electronics and sensors, while Thailand can provide local access to precision manufacturing, harnessing and industrial suppliers. Nevertheless, allocation should not be predetermined by nationality. Both ecosystems contain wide variations in process maturity, documentation, intellectual-property handling, quality control and lifecycle support.

For each component family, score candidate sourcing routes from 1 to 5 against:

• prototype lead time;
• recurring lead time;
• technical differentiation;
• interface complexity;
• qualification cost;
• supplier concentration;
• obsolescence risk;
• intellectual-property sensitivity;
• logistics sensitivity;
• local inspection and rework needs;
• traceability;
• change-notification discipline;
• second-source potential;
• low-volume and production-volume suitability.

The scoring should inform a decision, not automate it. A low-cost component with high safety impact may deserve more engineering attention than an expensive but easily verified structure.

Three sourcing archetypes

Buy as a commercial off-the-shelf item. Appropriate where the subsystem is not strategically differentiating, its interfaces are accessible, and its operating envelope can be qualified. Candidate examples may include development-stage compute modules, standard network components and some perception sensors.

Customise around a standard core. Appropriate when differentiation resides in packaging, integration or application knowledge. Examples include a custom housing around a standard motor and reducer, a mission-specific harness using established connector families, or an enclosure around a standard compute platform.

Design and own. Appropriate where a subsystem directly controls safety, product performance, data quality, serviceability or unit economics. Candidate areas include system architecture, protective functions, calibration, production test equipment, application-specific end effectors, diagnostics and selected actuator-control functions.

Supplier qualification

A request for quotation should be accompanied by a technical data package and a structured supplier questionnaire. At minimum, investigate:

• scope of processes performed in-house;
• subcontracted processes and approval controls;
• relevant quality-system certification and its exact scope;
• manufacturing and inspection equipment;
• material and component traceability;
• measurement-system calibration;
• non-conformance and corrective-action processes;
• engineering change notification;
• counterfeit-part avoidance;
• firmware ownership and update arrangements;
• warranty and failure analysis;
• capacity and surge constraints;
• business continuity and second-site options;
• export, transport and storage restrictions.

Certification should be treated as evidence about a management system, not automatic proof that a particular component meets the robot's requirements.

Dual-sourcing without false equivalence

A second source is useful only if it has been technically evaluated. Two nominally compatible motors, reducers, batteries or sensors may differ in dynamics, firmware, thermal behaviour, connectors, calibration or fault response. The team should decide where a proposed alternative sits on the interchangeability ladder.

BOM, configuration and engineering change control

One product, several controlled BOM views

A robotics programme should maintain at least:

Recommended records include internal part number, revision, manufacturer part number, supplier, lifecycle status, quoted lead time, MOQ, unit cost, NRE, critical characteristics, inspection method, compliance evidence, firmware version, lot or serial-control status, and recalibration impact.

Baseline control

A robot's identity is more than its mechanical serial number. A deployment baseline should connect:

• hardware revision;
• supplier and component lot where critical;
• firmware release;
• autonomy software release;
• model or policy version;
• calibration set;
• safety configuration;
• test result;
• date and station of release.

Engineering change workflow

A practical flow is:

Actuator and drivetrain engineering

Begin with the load case

For every joint or driven wheel, define:

• continuous torque;
• peak torque and its permitted duration;
• speed range;
• external and inertial load;
• gear ratio and efficiency;
• reflected inertia;
• acceptable backlash and compliance;
• shock and hard-stop loads;
• thermal path;
• regenerative energy;
• holding requirement;
• sensing and diagnostic needs;
• safe behaviour after power or feedback loss.

The actuator should be selected against the full torque-speed-time envelope, not a single peak-torque figure.

Integrated module versus discrete joint

Qualification and incoming inspection

Possible qualification tests include:

• winding resistance balance;
• insulation integrity where applicable;
• encoder linearity, repeatability and zero stability;
• no-load current;
• backlash or lost motion;
• torque constant and current-to-torque relationship;
• torque ripple;
• noise and vibration signature;
• temperature rise under a defined load profile;
• brake operation;
• communication fault response;
• overcurrent and overtemperature protection;
• destructive or teardown inspection of selected samples.

Qualification tests should be separated from per-unit incoming screening. The latter must be fast, repeatable and linked to acceptance limits.

Electrical power, batteries and communications

Power-domain architecture

A general power hierarchy comprises seven domains, from energy input to service power.

The design should address worst-case power, conductor and connector derating, inrush current, voltage drop, fuse coordination, ground and return-current paths, regenerative energy, residual-energy discharge, reverse polarity, brownout response and thermal limits.

Loss of compute should not leave an actuator executing stale commands, and removal of drive power should not cause a gravity-loaded axis to fall.

Battery and charging considerations

The programme should define:

• cell chemistry and qualification basis;
• pack voltage, capacity and current envelope;
• battery management and fault reporting;
• charge location and unattended-charging policy;
• isolation or contactor strategy where relevant;
• thermal monitoring and propagation controls;
• state-of-charge and state-of-health estimation;
• transport and storage requirements;
• replacement, recycling and end-of-life process;
• response to impact, water ingress and abnormal temperature.

Applicable battery, transport and market requirements must be reviewed for the intended product and sales region.

Network separation

The architecture should distinguish five traffic classes.

CAN-based systems, EtherCAT, Ethernet and serial links solve different problems. ROS 2 is middleware and does not itself specify a physical interface or guarantee particular real-time performance. The complete network must be measured for latency, jitter, synchronisation, packet loss, load behaviour and fault recovery.

Harness engineering

Harness design should control:

• wire gauge and temperature derating;
• flex life and bend radius;
• shielding and termination;
• keying and mis-mating prevention;
• connector retention;
• strain relief and service loops;
• separation of power and sensitive signals;
• abrasion and pinch protection;
• moving-axis routing;
• durable labelling;
• continuity and insulation tests.

Harness routing should be reviewed through the full articulation range before design freeze.

Mechanical architecture and thermal management

Tolerance and datum strategy

A tolerance stack should trace critical geometry from actuator bearing seats through links, interfaces and the end effector. Control:

• functional datums;
• bearing and shaft fits;
• coaxiality and alignment;
• locating features;
• fastener access and preload;
• shim strategy;
• tolerance interaction with calibration;
• replaceability without expert alignment.

Calibration should compensate for bounded manufacturing variation, not rescue uncontrolled geometry.

Structural verification

Candidate load cases include:

• rated static load;
• dynamic amplification;
• emergency stopping;
• joint hard-stop impact;
• tip-over or stability boundary;
• transport and handling;
• fatigue-critical mission cycles;
• cable and hose forces;
• foreseeable collision or misuse.

Finite-element analysis should be correlated with physical measurement on critical structures. Model confidence depends on realistic boundary conditions, material data, joints and load assumptions.

Thermal architecture

Instrument motor windings or representative points, power electronics, reducers, compute modules, battery cells and high-resistance connections. Verify steady and transient behaviour under the worst credible mission and ambient condition. Derating and shutdown thresholds should be reflected in system behaviour.

Environmental protection

Ingress-protection targets must be derived from the ODD. Validation should consider the complete assembly, including connectors, shafts, vents, covers, displays and service openings. A rating claimed for one component does not automatically apply to the finished robot.

Calibration, system identification and physical-AI data quality

Calibration hierarchy

Define separate processes for each calibration event in the robot's life.

Each calibration record should identify the robot, component or sensor, method, reference artefact, software version, environment, fitted parameters, residual error, acceptance threshold, station and operator.

Joint and drivetrain calibration

Potential parameters include:

• zero position;
• direction and scale;
• current-to-torque mapping;
• backlash or lost motion;
• friction and stiction;
• gear compliance;
• brake timing;
• temperature compensation.

Perception calibration

A multi-sensor robot may require:

• camera intrinsics;
• camera-to-base extrinsics;
• LiDAR-to-base extrinsics;
• inertial-sensor alignment;
• wheel radius and track width;
• time offset and timestamp verification;
• end-effector and tool-centre-point calibration.

The team should report residuals and repeatability, not merely that calibration completed successfully.

Why this matters to physical AI

Calibration and system identification influence the quality of both control and data. Errors can propagate into localisation, object pose, grasp planning, force control, collision checking and policy observations. Sim-to-real performance is affected by inaccurate mass, inertia, friction, backlash, compliance, sensor delay, actuator delay and battery behaviour.

A learning system must not be expected to conceal unstable mechanics or uncontrolled sensing. Data recorded for training and validation should be tied to hardware configuration and calibration status.

Verification, simulation and HIL

Test pyramid

A cost-effective verification strategy grows progressively in energy, integration and consequence.

Define the HIL boundary

HIL is valuable only when the simulated plant, physical controller and interfaces are clearly stated. Candidate uses include:

• controller and network timing;
• command and feedback validation;
• sensor emulation;
• encoder discontinuity;
• bus-voltage variation;
• packet delay and loss;
• actuator saturation;
• overtemperature;
• watchdog timeout;
• emergency-stop transition;
• restart and recovery behaviour.

The purpose is not simply to make the virtual robot move. It is to verify controller behaviour at boundaries and during faults before applying full energy to the physical machine.

Mission-derived endurance tests

Avoid selecting a universal burn-in duration. Build an endurance cycle from:

• load and speed distribution;
• start-stop frequency;
• ambient temperature;
• charge and discharge cycles;
• shock or obstacle events;
• expected idle periods;
• planned inspections;
• measurable degradation and failure criteria.

The test should accelerate relevant mechanisms without introducing unrealistic failures that would never occur in service.

Requirements traceability

Every safety-critical and performance-critical requirement should map to:

• verification method;
• procedure and configuration;
• calibrated equipment;
• acceptance criterion;
• result and raw evidence;
• deviation or waiver;
• approving authority.

Safety, reliability and failure engineering

Determine product category first

The standards route depends on what the robot is and where it operates. ISO 10218-1:2025 concerns safety requirements for industrial robots, while ISO 10218-2:2025 addresses industrial robot applications and robot cells. ISO 10218-1 explicitly excludes several categories, including service robots accessible to the public, medical robots and consumer products. A startup should therefore classify the product and intended application before adopting a compliance plan.

Additional requirements may apply according to market, machinery classification, mobility, battery, radio, EMC, collaborative operation and environmental use. Applicability should be confirmed by qualified specialists and relevant conformity-assessment bodies.

Hazard analysis

A staged safety process may include:

• preliminary hazard analysis;
• system FMEA;
• design FMEA;
• process FMEA;
• fault-tree analysis for selected critical hazards;
• foreseeable misuse analysis;
• risk-reduction verification.

Candidate hazards include crushing, impact, entanglement, instability, dropped loads, unexpected motion, electrical shock, fire, thermal contact, battery failure, loss of sensing, software error and unsafe restart.

Define safe states and transitions

Safety is not only a component selection exercise. The total response time, diagnostic coverage, energy-removal path and resulting machine state must be verified as a system.

Reliability growth

Reliability work should connect failure reports to design action:

1. identify failure mode and affected configuration;
2. contain the immediate product or field risk;
3. reproduce the failure where practicable;
4. determine root cause;
5. implement corrective action;
6. verify that the action is effective;
7. update design rules, tests and supplier controls;
8. trace affected units.

EVT, DVT, PVT and pilot gates

EVT, DVT and PVT should be defined by the evidence required to answer a programme question, not by a universal build quantity.

EVT: prove engineering feasibility

Gate question: Can the selected architecture satisfy the critical functions and risk controls?

Suggested evidence:

• top-level requirements and ODD baselined;
• critical interfaces demonstrated;
• actuator, power and thermal feasibility established;
• calibration concept demonstrated;
• core communication timing measured;
• preliminary hazard controls implemented;
• major technical risks retired or quantified;
• prototype BOM and sourcing risks recorded.

Do not carry forward silently: unstable interfaces, undocumented hand-tuning, unknown thermal limits or unresolved high-severity hazards.

DVT: verify the production-intent design

Gate question: Does the complete design meet requirements under intended and foreseeable conditions?

Suggested evidence:

• production-intent mechanical and electrical design;
• performance, endurance and environmental results;
• safety verification evidence;
• EMC pre-compliance or applicable testing plan;
• released firmware and software baseline;
• design FMEA actions closed to the agreed level;
• design-for-manufacture and assembly review;
• service and maintenance concept;
• certification and market-access plan;
• controlled deviations and residual risks.

PVT: prove the manufacturing process

Gate question: Can the released design be built, calibrated and tested repeatedly without undocumented expert intervention?

Suggested evidence:

• approved manufacturing BOM;
• controlled work instructions;
• qualified tools, fixtures and test stations;
• trained operators;
• serial and lot traceability;
• end-of-line test limits;
• calibration repeatability;
• defect, rework and concession processes;
• released suppliers and incoming inspection;
• production yield and process evidence;
• governed reference unit or metrology artefact.

Controlled field pilot

Gate question: Can the organisation operate and support the product responsibly in its intended environment?

Suggested evidence:

• approved site and deployment conditions;
• operator and maintainer training;
• telemetry and incident capture;
• replacement-part readiness;
• service and escalation process;
• remote diagnostic and safe-disable capability where appropriate;
• controlled software update and rollback;
• criteria for pausing or expanding deployment.

Production engineering and end-of-line test

Design for assembly and test

A production-intent robot should include:

• accessible fasteners and connectors;
• keyed and labelled interfaces;
• defined torque values and locking methods;
• assembly datums and fixtures;
• test points and diagnostic access;
• controlled software provisioning;
• automated capture of serial numbers and results;
• replacement paths for likely service parts.

End-of-line test architecture

Each test needs a controlled limit, equipment calibration status and failure disposition. A green indicator without retained measurement evidence may be insufficient for traceability.

Golden units and reference artefacts

Reference units can help detect test-station drift, but they must themselves be controlled. Record their configuration, calibration, allowable use, storage, periodic verification and retirement criteria.

Capital efficiency and total landed cost

Beyond the quoted part price

Compare sourcing routes using:

• component price;
• tooling and NRE;
• freight, duty and tax;
• inspection and supplier visits;
• expected failure and rework;
• inventory carrying cost;
• obsolescence exposure;
• calibration and test labour;
• field replacement and warranty;
• software, firmware and lifecycle support.

The cheapest prototype component can become the most expensive production decision if it creates redesign, calibration labour or unsupported field failures.

Tooling-release ladder

Move forward when design maturity, demand confidence, repeatability and unit economics justify the commitment. Avoid releasing high-cost tooling while interfaces, sealing, service access or ergonomics remain unstable.

Build-versus-buy decision

Evaluate each candidate subsystem against:

• strategic differentiation;
• performance headroom;
• internal capability;
• development time;
• NRE and recurring cost;
• safety responsibility;
• supplier lock-in;
• repairability;
• documentation and firmware access;
• forecast volume;
• second-source feasibility;
• lifecycle ownership.

Common cash-flow traps

• committing to volume inventory before DVT evidence;
• paying for tooling before interface freeze;
• accepting unqualified substitute components;
• excluding fixtures, calibration and end-of-line equipment from NRE;
• building production around developer kits without a lifecycle plan;
• underfunding certification, rework, spares and field support.

Field support and lifecycle engineering

Commercial deployment begins, rather than ends, when the robot reaches the customer.

Configuration-aware service

Diagnostics and telemetry

Define a fault-code taxonomy that separates symptoms, protective events and probable causes. Logs should contain sufficient timing and configuration context to support investigation without collecting unnecessary or unauthorised information.

Field-replaceable units

Select field-replaceable units based on failure likelihood, safety, transport, skill, calibration impact, downtime and cost. Replacing a module should have a defined isolation, mechanical, provisioning, calibration and verification procedure.

Lifecycle responsibilities

The product organisation should assign ownership for:

• component end-of-life notifications;
• supplier changes;
• spares availability;
• security and firmware updates;
• software compatibility;
• battery replacement and disposal;
• warranty-return analysis;
• design feedback from field incidents.

Worked example: an indoor mobile manipulator

This notional example shows how the playbook can be used. No numerical target should be treated as a product recommendation without application-specific analysis.

Mission statement

The robot transports small containers within a controlled industrial facility, performs visual inspection at defined stations, and manipulates objects using one arm. It operates around trained personnel under a site-specific risk assessment.

Initial allocation hypothesis

Top programme risks

1. actuator thermal performance under combined base-and-arm duty;
2. instability or tip-over at extended reach;
3. time alignment between perception and motion;
4. battery voltage sag during simultaneous motion;
5. network congestion and command latency;
6. calibration repeatability after arm or sensor replacement;
7. protective stopping performance;
8. dependence on a single actuator or sensor source;
9. assembly and harness variation;
10. field diagnosis without specialist access.

Evidence roadmap

• EVT: prove mobility, manipulation, power, timing and calibration architecture on representative hardware.
• DVT: test the production-intent system against performance, safety, endurance, environmental and service requirements.
• PVT: prove controlled assembly, calibration, end-of-line testing and traceability across a pilot build.
• Field pilot: validate operational effectiveness, failure response, maintainability and support readiness in a controlled site.

Founder decision cards

Conclusion

The hardest part of building a physical AI company is not making one robot move. It is creating an engineering system that allows successive robots to behave consistently, safely and economically despite variation in components, suppliers, assembly, calibration and operating conditions.

A Southeast Asian startup can benefit from China's dense prototyping and component ecosystem and Thailand's industrial manufacturing base. Yet the most resilient strategy does not allocate work by geography alone. It qualifies suppliers by capability, assigns components according to risk, validates critical interfaces and preserves alternatives before volume commitments are made.

The startup should retain ownership of system requirements, interfaces, safety architecture, configuration, calibration and acceptance evidence. It should design production tests alongside the robot, derive reliability tests from the mission, and prepare diagnosis and service before the field pilot.

The result is more than a faster path from CAD to a prototype. It is a controlled path from prototype to a repeatable, supportable and commercially credible physical AI product.

Appendix A: EVT/DVT/PVT gate checklist

EVT

• ODD and core use cases defined
• Top-level requirements measurable
• System architecture and interfaces documented
• Critical actuator load cases tested
• Power and thermal feasibility demonstrated
• Core network timing measured
• Calibration concept demonstrated
• Preliminary hazard analysis complete
• Highest technical risks retired or owned
• Prototype BOM and supplier risks controlled

DVT

• Production-intent design released
• Requirements traceability complete for critical requirements
• Performance and endurance evidence approved
• Safety functions verified
• Environmental and EMC plan executed as applicable
• Firmware, software and policy baseline controlled
• Design FMEA actions closed to agreed level
• DFM/DFA review complete
• Service and recalibration procedures demonstrated
• Certification and market-access evidence on plan

PVT

• Manufacturing BOM and work instructions approved
• Suppliers released and incoming controls active
• Production fixtures qualified
• Instruments and stations calibrated
• Operators trained
• Serial and lot traceability operational
• Provisioning and calibration are repeatable
• End-of-line limits approved
• Defect, rework and concession processes active
• Pilot-build evidence supports controlled manufacture

Field pilot

• Deployment site and conditions approved
• Training completed
• Support and escalation process active
• Spares and replaceable units available
• Telemetry and incident capture validated
• Software update and rollback controlled
• Safe-disable or recovery process defined
• Expansion and stop criteria approved

Appendix B: Supplier capability checklist

• In-house and subcontracted processes declared
• Quality-system scope reviewed
• Equipment and inspection capability reviewed
• Material and component traceability demonstrated
• Calibration system reviewed
• Non-conformance and corrective-action process reviewed
• Engineering change notification agreed
• Counterfeit avoidance controls reviewed
• Firmware and documentation ownership agreed
• Capacity and continuity reviewed
• Warranty and failure-analysis route agreed
• Packaging, storage and transport controls reviewed
• Alternative source or recovery plan documented

Appendix C: Red flags

• A successful demonstration is not evidence of repeatability.
• A supplier's certification is not automatic qualification of the supplied component.
• A compatible connector does not prove electrical, dynamic or safety compatibility.
• Calibration must compensate for bounded variation, not uncontrolled manufacturing.
• An emergency-stop input is not, by itself, a complete safety architecture.
• A realistic-looking simulator can still contain an inaccurate plant model.
• Low MOQ does not guarantee lifecycle support or production continuity.
• “Automotive grade” should be tied to a defined requirement and evidence.

Scope and method

This playbook is written for technical founders, chief technology officers, robotics leads and early-stage hardware investors. Its reference product is an indoor mobile manipulation robot — a wheeled base, one arm, perception sensors, onboard compute and a battery system — progressing from proof of concept through EVT, DVT and PVT to a controlled production and field pilot of roughly 10 to 100 units. Thailand and China are treated as complementary manufacturing ecosystems, not as rigid categories of capability.

Quantitative values and example thresholds are illustrative frameworks unless explicitly attributed to a source; they must be confirmed through supplier quotations, laboratory tests, interviews and standards review before being relied on. This playbook is not a substitute for product-specific safety engineering, legal advice, conformity assessment or supplier qualification.