Motors, joints, cameras, and dexterous hands attract most of the attention in robot development. Inside the machine, however, the robot control board determines how those components work together—and whether the system can respond consistently while processing demanding AI workloads.
When a robot moves unevenly, pauses unexpectedly, or struggles to interpret its surroundings, the cause may extend beyond the motors or algorithms. The computing architecture matters too. A processor handling camera streams, model inference, device communication, and movement coordination can become a shared bottleneck.
This is why some robot designs pair Rockchip RK3588 with NVIDIA Jetson Orin. RK3588 handles much of the system coordination, while Orin provides additional computing resources for advanced perception and AI. The arrangement is often described as a robot’s “cerebellum” and “brain.” Understanding that division helps explain when a single application board is sufficient, when additional AI hardware is useful, and how the decision changes as production grows.
Motion Control and AI Have Different Priorities
A robot can be understood as three connected parts: its physical body, its motion control system, and its decision-making system.
The body includes motors, joints, sensors, and mechanical structures. These components establish what the machine can physically do. The motion control system turns commands into coordinated movement, while the decision-making system interprets observations and selects actions.
The two computing workloads have different priorities. Motion control depends on predictable timing. A control update that arrives too late can be a problem even if the processor performs well on average. AI workloads place greater demands on model execution, memory, and data processing, and their execution time can vary with the task.
The “cerebellum” metaphor therefore needs a precise engineering boundary. RK3588 is an application processor, commonly running Linux or Android. It can manage devices, collect sensor data, coordinate movement, and execute control tasks whose timing requirements have been validated. Its CPU performance alone does not make it a hard real-time controller.
Strictly timed motor control loops usually belong in suitable microcontrollers, servo drives, or dedicated motion controllers. Emergency stops and safety protection also require appropriate hardware and system design. RK3588 can coordinate these devices without replacing their responsibilities.
Separating the workloads gives each layer a clearer job. Advanced AI can generate a target or action proposal, the application controller can manage execution, and the motion controllers can maintain the required low-level timing.
Two Common Mistakes in Robot Control Board Selection
The first mistake is expecting an RK3588 board to handle every robot workload.
RK3588 combines an eight-core CPU with an integrated NPU rated at up to 6 TOPS, alongside camera, multimedia, and display resources. This makes it a useful platform for device management and appropriately sized AI applications. Inspection robots, commercial cleaning machines, and warehouse vehicles with well-defined tasks may find this level of computing sufficient.
The requirements change when a robot must interpret open-ended instructions, process several visual inputs, or run a substantial vision-language-action model. OpenVLA, for example, uses a language model backbone with billions of parameters. Deploying this class of model involves memory capacity, bandwidth, software compatibility, and inference latency—not simply whether a board contains an NPU.
RK3588 can run supported AI models, but a model that executes successfully may still be too slow for the intended robot behavior.
The second mistake is assuming that installing Jetson Orin immediately simplifies the whole system.
Orin provides accelerated computing and an established robotics software ecosystem, but the choice still carries costs in hardware, cooling, power supply design, and integration. A machine performing a narrow, repetitive task may gain little from a larger AI platform.
Orin also does not automatically solve deterministic motor control. Its suitability depends on the workload, the chosen module, and the complete software and hardware design.
Three Practical Levels of Robot Computing
The original distinction between control, advanced AI, and lightweight inference remains useful when selecting a robot controller board.
| Computing level | Typical platform | Main responsibility | Suitable applications |
|---|---|---|---|
| System coordination and control | RK3588 application board with appropriate motion controllers | Device communication, sensor acquisition, movement coordination, local interfaces, and supported inference | Factory inspection, commercial cleaning, warehouse AGVs |
| Advanced perception and AI | NVIDIA Jetson Orin | Demanding vision pipelines, multimodal inference, and AI-assisted task planning | Humanoid robots, flexible manipulation, robots interpreting instructions and changing environments |
| Focused edge inference | Low-power SoC, NPU module, or suitable MCU | A specific recognition or detection task within a limited power budget | Shelf monitoring, meter reading, and dedicated inspection devices |
These levels can overlap within one machine. An inspection robot might use RK3588 for its main application and a compact accelerator for one demanding visual task. A humanoid robot might combine RK3588, Orin, and several joint controllers.
“Edge AI” describes where computation happens rather than a particular type of board. A lightweight recognition model may already run on the main board’s NPU. Adding another computer is useful only when it addresses a measured requirement.
For RK3588, model conversion and runtime support must be checked against the selected software stack. For Orin, module memory, power mode, and inference software affect the result. Advertised TOPS figures help describe hardware capacity, but they do not establish the speed of a complete robot application.
How RK3588 and Jetson Orin Can Work Together
In a dual-processor robot architecture, RK3588 can manage peripheral devices, operating states, user interfaces, and communication with motion controllers. Orin can process more demanding perception or AI workloads and send results to the application layer.
For example, Orin might identify an object and propose a grasping action. The RK3588 application can check the current operating state, coordinate the sequence, and pass the relevant commands to the motion system. Joint controllers then execute the movement within their own control loops.
The communication between these layers deserves as much attention as the processors themselves. Messages need clear meanings, timestamps, and defined handling for stale or missing data. A delayed inference result should not remain valid indefinitely.
The robot also needs a specified response when the AI process stops, restarts, or loses communication. Depending on the application, that response may be a controlled stop, a restricted operating mode, or a request for intervention.
Separate boards create an opportunity to isolate workloads and failures. Achieving that benefit requires deliberate interfaces, timeout behavior, and testing under realistic load.
Buying a Board or Developing a Custom Design
Once the computing roles are clear, the next question is how to obtain the hardware. The main options are purchasing a complete board, using a system-on-module with a carrier board, or developing a more customized design.
The original article’s small, medium, and large manufacturer examples offer useful starting points, although engineering capability and product maturity matter as much as company size.
For a small team validating its first application, a purchased RK3588 board combined with a separate AI computing unit can shorten the path to a working prototype. The priority is proving that the robot can complete its intended task reliably. Existing hardware also makes it easier to change the architecture before requirements settle.
For a team with a stable core product, a custom RK3588 carrier board or application board may improve packaging and remove unnecessary interfaces. A limited number of Orin-equipped systems can support development, demonstrations, or applications that justify the additional AI capability. Prototype results should then be verified on the proposed production configuration.
At larger production volumes, a mixed platform strategy can make sense. Robots with routine workloads can use a leaner computing configuration, while more demanding models receive additional AI resources. Common interfaces and software components can help keep the product range manageable.
Custom development can reduce recurring hardware costs, but it introduces engineering, testing, tooling, and maintenance costs. The useful comparison is total cost over the product’s expected production volume and service life. There is no universal quantity at which self-development becomes cheaper.
Where the Robot Display Fits into the Architecture
6.52 inch Flexible OLED 2520x840 Touch Panel
The display belongs in this workload discussion because it communicates the robot’s operating state to people nearby. It may show that the machine is listening, processing a request, moving, charging, or waiting for assistance.
In an RK3588-and-Orin design, display rendering and interaction can remain on the RK3588 application layer while Orin handles demanding inference. This arrangement can keep basic status feedback independent of the AI application, provided the software and available resources are designed accordingly.
For a curved robot face or narrow visor, PanoxDisplay’s flexible OLED displays provide options that can fit the enclosure’s shape. The 6.52-inch flexible OLED touch panel, for example, has a 2520 × 840 resolution and a 3:1 aspect ratio, making it a candidate for a continuous facial display.
Panel integration still requires matching the display interface, initialization sequence, power supplies, connector, and mechanical mounting. Processor display support does not establish compatibility with every panel. From PanoxDisplay’s perspective, selecting the screen and its driving solution is part of the robot’s system design.
Selecting the Architecture Around the Robot’s Actual Task
A practical robot computing architecture starts with the work the machine must perform. Defined routes and repetitive tasks may be served by an RK3588 application platform with suitable motion controllers. More demanding perception, language understanding, or learned action models may justify adding Jetson Orin. A single-purpose recognition device may need a much smaller inference platform.
The value of the “brain and cerebellum” approach is the division of responsibilities: predictable movement, sufficient AI capacity, clear device coordination, and understandable feedback. Choosing hardware around those requirements gives the robot a better foundation for reliable operation and economical production.
