Building a Sustainable Technology Architecture for AI Robotics Companies

1. First Define What the Technology System Must Solve

The purpose of building a technology system is to keep robots from becoming uncontrollable during feature iteration, make it possible to identify the root cause when problems occur, and ensure safe operation when some modules fail. Three questions can be used to test whether a system is qualified:

• After changing one module, do other modules need to be substantially changed at the same time?
• Can a single failure be traced back to a specific model version, data batch, and device configuration?
• When a critical sensor or network fails, can the system degrade to a safe state?

2. Five-Layer Architecture and the Deliverables of Each Layer

An intelligent robot system can usually be divided into five layers. Each layer should have clear inputs, outputs, and acceptance methods to avoid overlapping responsibilities.

Layer	Main responsibilities	Inputs	Outputs	Acceptance criteria
Perception layer	Collect and calibrate multi-source data	Raw data from cameras, radar, inertial measurement units (IMUs), encoders, etc.	Unified data frames with timestamps and status flags	Time alignment error, frame loss rate, anomaly detection rate
Cognition layer	Recognize targets, understand scenes and commands	Data frames from the perception layer	Structured semantic results and confidence scores	Accuracy on an independent test set, missed detection rate, inference latency
Decision and planning layer	Generate task plans and behavior choices	Semantic results, task goals, maps	Action command sequences	Task success rate, replanning count, safety constraint trigger count
Control and execution layer	Convert commands into motor or servo control values	Action commands, body status	Drive signals	Trajectory tracking error, control cycle jitter, fault degradation response time
Cloud-edge collaboration layer	Allocate edge and cloud tasks, synchronize data and versions	Device status, logs, model packages	Remote operations results, upgrade packages	Offline continuous runtime, resumable transfer success rate, synchronization latency

The parameters in the table need to be calibrated according to actual hardware. For example, if the time alignment error of the perception layer exceeds half of the control cycle, the timestamp mechanism should be corrected first before discussing algorithm accuracy.

Perception Layer

• The output of each sensor must carry a timestamp and be synchronized to the same clock source.
• Add a quality flag to each data frame, such as normal, occluded, failed, sudden change, or communication interruption.
• If no data is received for several consecutive frames, or if values exceed the physical range, the sensor should be judged as failed, and the status should be passed to the decision layer. The system should not pass raw abnormal values directly downstream.

Cognition Layer

• Model outputs must include confidence scores. When confidence is below the threshold, the case should be handled by rule-based methods or human confirmation.
• Training and test sets should be split by time or scene to avoid samples from the same scene appearing on both sides.
• After deployment, continuously record false recognition and missed recognition samples, and review them once before each version release.

Decision and Planning Layer

• Speed limits, spatial boundaries, collision avoidance, and emergency stops are hard constraints and have higher priority than model outputs.
• When model results are uncertain or inference times out, switch to predefined conservative actions, such as slowing down and stopping or waiting in place.
• Log task planning, behavior decision-making, and action execution separately to make it easier to locate which step caused the problem.

Control and Execution Layer

The control layer should handle faults according to their impact level:

Fault level	Example trigger condition	System action
Level 1	A single non-critical sensor fails	Record an alert and continue the task
Level 2	Data from a critical sensor is continuously lost	Limit the maximum speed and disable non-critical functions
Level 3	Actuator overload or emergency stop signal is triggered	Stop immediately, enter safe mode, and wait for manual reset

Thresholds must be determined through real-machine testing and cannot be directly copied from simulation parameters.

Cloud-Edge Collaboration Layer

• Real-time control, emergency stop, and low-latency interaction must be completed locally.
• The cloud is responsible for large-scale data analysis, model training, version management, and report generation.
• Offline cache duration should be set according to task requirements. Warehouse handling robots may only need to cache a few minutes of operational data, while long-term inspection equipment needs a longer cache time.
• Model package upgrades should use canary release: first validate on a small number of devices, then gradually expand.

3. How to Implement Data Governance

Data quality directly determines model performance. A team needs at least three documents: a data dictionary, annotation specifications, and a version record table.

Data Dictionary Example

Field	Meaning	Example	Constraint
sample_id	Unique sample ID	S20261101-0034	Globally unique, no duplicates
source	Data source	Lab, field, user feedback	Required, enumerated value
scene_tag	Scene tag	Strong light, nighttime, occlusion	Required, multiple selections allowed
label_version	Annotation specification version	v2.1	Must match the annotation specification version
collected_at	Collection time	2026-10-18 14:02	Accurate to the minute
sensitive_flag	Contains sensitive information	Yes, No	If “Yes”, must be de-identified before storage

Annotation Quality Control

• Each sample should be independently annotated by two people, and disagreements should be adjudicated by a third person.
• For each batch, a sampling inspection rate can be set to 10%, and annotation consistency should be calculated. The example target value should be defined for the project.