01 / 03Sensor geometry
Design perception around what the robot must see.
Field of view, placement, exposure, occlusion, vibration, cabling, and environment determine the usable camera and sensor layout.
Robotics Perception
Design the vision path around the robot, not one component.
Bring cameras, sensor timing, edge compute, perception software, power, thermal, and production constraints into one robotics design-in review.
Explore the system path
System operating context
Designed for
- Robotics and AMR OEMs
- Perception teams
- Robotics system integrators
Physical AI starts at the sensor
Perception fails at the seams between subsystems.
A robotics platform depends on more than model throughput. Sensor placement, timing, memory movement, control interfaces, power, and environment shape the usable perception architecture.
- 01
Timing crosses every layer
Camera exposure, synchronization, timestamps, preprocessing, inference, and control handoff must share a measurable timing model.
- 02
Compute lives inside a physical envelope
Power, thermal strategy, vibration, enclosure, connectors, service access, and weight affect the platform choice.
- 03
Prototype parts need a production owner
Carrier, camera, driver, BSP, FPGA, perception runtime, harnessing, and test responsibilities need to be assigned before scaling.
Architecture review
Connect sensing, perception, and machine action.
YUAN reviews the video-native portion of the robotics stack and the interfaces it must maintain with sensors, software, and the machine controller.
Robotics Perception
Active stage 01
Sense
Camera layout, field of view, interfaces, and environment
Evidence before performance claims.
Performance is configuration-specific. The review defines the target, test configuration, and evidence needed before latency, frame integrity, stream density, power, or thermal results are treated as claims.
Follow the operating path
See where source reality becomes a production decision.
01 / 03
02 / 03Compute carrier
Fit timing and compute into a physical machine.
The carrier, camera links, driver, runtime, power budget, thermal strategy, connectors, and service access form one platform decision.
Build perception around the moving machine.
The useful vision path moves with the robot. Cameras, timing, compute, and control boundaries have to remain connected through real operating states.
03 / 03Control boundary
Keep perception, machine control, and safety ownership explicit.
The review documents middleware, controller handoff, logging, fleet interfaces, and the boundaries owned by autonomy and safety teams.
Match the perception topology to the machine.
These patterns describe ownership and data movement. They do not imply a universal latency, safety, or autonomy result.
01
Central perception node
- Fits when
- Camera and sensor paths can terminate at one compute and service location.
- Review first
- Link count, synchronization, preprocessing, compute load, power, thermal, and enclosure.
- Evidence to collect
- Representative sensor, model, control-handoff, and thermal validation.
02
Distributed sensing
- Fits when
- Sensors are physically separated or pre-processing belongs near each source.
- Review first
- Clock and timestamp model, transport, failure behavior, bandwidth, and ownership.
- Evidence to collect
- Alignment, recovery, network, and end-to-end behavior across operating states.
03
Sensor-bridge path
- Fits when
- High-bandwidth perception modules need a defined bridge into supported edge compute.
- Review first
- Sensor protocol, bridge, memory path, runtime interface, control boundary, and mechanics.
- Evidence to collect
- Exact bridge-to-runtime validation with the target sensors and software graph.
Architecture review
Turn what you know into a testable system brief.
Bring to the review
Start with the constraints you already know.
- Camera and sensor layout
- Interface, trigger, and timing requirements
- Perception graph and software runtime
- End-to-end latency budget and action boundary
- Power, thermal, mechanical, and environmental limits
- Prototype quantity and production target
Review output
Leave with a clearer evaluation path.
- Video and sensor ingest architecture
- Timing and responsibility boundary
- Candidate edge compute and I/O path
- Evaluation and production design-in plan
Related YUAN capabilities
Continue with product and software evidence.
Evaluation questions
Separate current decisions from the items that still require testing.
Is TOPS enough to choose the robotics platform?
No. The useful choice also depends on sensor count, preprocessing, memory movement, runtime, control workload, power, thermal design, and the mechanical envelope.
Does YUAN own the complete autonomy stack?
The review focuses on the supported video, sensor-ingest, compute, and software-integration path. Planning should explicitly identify the owners of autonomy, control, safety, and fleet systems.
Can latency be guaranteed from a page review?
No. The review defines the end points, workload, configuration, and measurement method required for a representative benchmark.
Prepare the technical brief
Ask the YUAN hardware expert which inputs and constraints belong in your review.
Other design-in paths
Review another system pattern.
YUAN USA design-in
Bring us the architecture before the component list is fixed.
Share the video sources, software workload, physical constraints, project stage, and production intent. The YUAN USA team will route the review to the relevant product and integration specialists.