RK3588 - это проверенная встраиваемая плата для управления роботами AGV и AMR, сочетающая в себе 6 TOPS NPU для обнаружения препятствий и искусственного интеллекта на роботе. восьмиядерный процессор для ROS2 и объединения датчиков, а также полный набор промышленных входов/выходов для управления двигателями и систем безопасности. По сравнению с промышленными ПК на базе архитектуры x86, эта плата обеспечивает снижение себестоимости на 30-60% и уменьшает потребляемую мощность системы с 50-80 Вт до 5-13 Вт. Это подходящая плата управления для складских логистических роботов, роботов-инспекторов и доставочных AMR, где краевой искусственный интеллект, слияние нескольких датчиков и навигация в реальном времени работают одновременно на одной встраиваемой платформе.
Основные выводы
- По прогнозам, рынок AGV/AMR достигнет $22 миллиарда к 2030 году при 18-30% CAGR - AMR растут быстрее всего (LogisticsIQ)
- RK3588 полностью поддерживает ROS2 Humble на Ubuntu 22.04 - Лучшая совместимость с ROS2 среди промышленных SoC ARM, готовых к производству
- 6 TOPS NPU работает Обнаружение препятствий YOLOv8n со скоростью 65 кадров в секунду и обнаружение людей при 200 кадрах в секунду одновременно, не требуется внешняя карта AI
- По сравнению с промышленными ПК x86: Стоимость BOM -30-60%Потребляемая мощность снижена с 50-80 Вт до 5-13 Вт, что позволяет использовать пассивное охлаждение в герметичных корпусах роботов
- Встроенный двойной провайдер поддерживает LiDAR + стереокамера + IMU объединение нескольких датчиков на одной плате
- RK3588J промышленный вариант работает при от -40°C до +85°CКорпус, совместимый с классом защиты IP65, для работы в суровых условиях
Почему производители AGV и AMR переходят на встраиваемые платы управления ARM
Мировой рынок мобильных роботов претерпевает структурные изменения. По данным исследования рынка LogisticsIQ 5th EditionОжидается, что рынок AGV и AMR достигнет примерно $22 миллиарда к 2030 годуа темпы роста AMR составили 30% в год. В 2024 году в мире будет развернуто более 200 000 единиц AGV и AMR, что на 25% больше, чем в 2022 году.
Этот рост обусловлен тремя сходящимися силами: расширением инфраструктуры электронной коммерции, хронической нехваткой рабочей силы на складах и производствах, а также развитием аппаратных средств искусственного интеллекта, которые делают роботизированный интеллект экономически оправданным в масштабе.
Проблема традиционных x86-контроллеров для роботов
Традиционные системы управления AGV опирались на промышленные ПК на базе архитектуры x86 - проверенную технологию с развитыми программными экосистемами, но плохо приспособленную к форм-фактору, мощности и стоимости современных автономных мобильных роботов.
Основные проблемы носят конструктивный характер. Потребляемая мощность 50-80 Вт требует активного охлаждения, что означает наличие вентиляторов - значительный риск для надежности герметичных корпусов роботов, работающих 7×24 в условиях пыльного склада. Размер платы вынуждает использовать более крупные шасси роботов, что увеличивает стоимость машины и снижает маневренность в узких проходах. Стоимость $500-$1 500 за единицу оборудования делает масштабирование парка непомерно дорогим для малых и средних операторов.
Почему RK3588 меняет уравнение
RK3588 решает все три проблемы одновременно. При общей потребляемой мощности системы 5-13 Вт она позволяет создавать герметичные корпуса с пассивным охлаждением без движущихся частей. Размеры платы, равные размерам кредитной карты, позволяют инженерам-механикам проектировать более компактные корпуса роботов. Стоимость BOM $80-$250 за единицу делает экономически оправданным развертывание парка из 40 или 100 единиц там, где альтернативы x86 были бы невозможны.
Что очень важно, RK3588 добавляет возможности, с которыми промышленные ПК x86 не могут сравниться ни по какой цене: выделенный 6 TOPS NPU для выводов ИИ на роботе, двойной ISP для одновременной обработки потока камер и встроенная поддержка ROS2 в Ubuntu 22.04 - стандартного программного стека для современной AMR-навигации.
RK3588 Аппаратная архитектура для управления роботами
Чтобы понять, почему RK3588 превосходит все остальные платы управления роботами, необходимо взглянуть не только на основные характеристики процессора, но и на полный набор функций SoC, которые автономные мобильные системы действительно используют во время работы.
ПРОЦЕССОР: Почему восьмиядерная архитектура A76/A55 важна для ROS2
Восьмиядерный процессор RK3588 - четыре производительных ядра Cortex-A76 и четыре эффективных ядра Cortex-A55 - практически идеально соответствует профилю вычислительной нагрузки современного AMR.
Ядра A76 справляются с интенсивными вычислительными задачами, чувствительными к задержкам: вычисления по планированию траектории Nav2, предварительная обработка данных датчиков, обновление карт SLAM и планирование работы узлов ROS2 для высокочастотных шаблонов издателей и подписчиков. Ядра A55 выполняют устойчивые фоновые задачи: циклы опроса датчиков, управление коммуникационным стеком, ведение журналов и обработка протоколов управления парком. Такая гетерогенная архитектура означает, что "думающие" и "слушающие" задачи робота не конкурируют за одни и те же ресурсы процессора.
Примечание по резьбе ROS2
Многопоточный исполнитель ROS2 распределяет обратные вызовы по пулу потоков. На RK3588 привязка обратных вызовов высокочастотных датчиков (LiDAR, камеры) к ядрам A76 с помощью масок сродства процессора уменьшает джиттер планирования Nav2 с ~120 мс до ~65 мс в протестированных конфигурациях - значительное улучшение для задержки реагирования на препятствия.
NPU: 6 TOPS для вывода ИИ на роботе без внешнего оборудования
6 TOPS NPU - это особенность, которая в наибольшей степени отличает платы управления роботами на базе RK3588 от ARM-платформ предыдущего поколения. В приложениях AGV и AMR он справляется с задачами искусственного интеллекта, которые непомерно дорого перекладывать на удаленный сервер: обнаружение препятствий в реальном времени, обнаружение человеческого тела для безопасной остановки, распознавание наземной разметки и идентификация ориентиров по QR/штрих-кодам.
Running YOLOv8n for person and obstacle detection at 65 FPS, with MobileNetV2 for landmark recognition simultaneously, the NPU maintains full throughput with the CPU cores largely unoccupied — leaving them free for navigation computation. This parallel execution model is a fundamental architectural advantage over CPU-only platforms. For deeper benchmark data on the RK3588 NPU across vision workloads, see our Руководство по производительности NPU RK3588.
ISP and Camera Interface for Multi-Sensor Vision
The dual ISP — supporting sensors up to 32MP — is not a specification that matters for smartphones but matters considerably for robot perception systems. Robots often need simultaneous front-facing obstacle detection (wide-angle camera), downward-facing floor marking detection (narrow camera), and optional 3D depth input (stereo pair). The dual ISP handles two of these streams in hardware simultaneously, with noise reduction, HDR tone mapping, and lens shading correction applied before the data reaches the CPU or NPU.
The 4×4-lane MIPI CSI-2 interface connects industrial cameras, stereo vision modules, and time-of-flight sensors without USB latency overhead. USB 3.0 ports remain available for Intel RealSense depth cameras and USB-connected LiDAR units.
Industrial I/O for Motor Control and Safety Integration
CAN bus, RS485, UART, SPI, I2C, and GPIO are all present in the RK3588’s I/O matrix. For AGV/AMR applications, each interface has a defined role. CAN bus connects motor drive controllers — the standard industrial protocol for servo and brushless motor drivers. RS485 links secondary sensors, safety scanners, and legacy industrial peripherals. GPIO provides hard-wired emergency stop signal output and safety light curtain input — deterministic hardware signals that don’t depend on OS scheduling. UART receives serial data from LiDAR units (RPLiDAR, SICK S300, Hokuyo URG series).
| Интерфейс | AGV/AMR Use | Max Performance | Notes |
|---|---|---|---|
| CAN Bus | Motor drive controllers | CAN FD up to 5 Mbit/s | Standard for servo/BLDC drivers |
| RS485 | Sensors, safety scanners | Up to 10 Mbit/s | Multi-drop topology, up to 32 nodes |
| UART ×10 | LiDAR, GPS, IMU | Up to 4 Mbit/s | RPLiDAR A3 / Hokuyo direct connect |
| GPIO | E-stop, safety curtain, LED | Configurable IRQ | Hardware-level safety signals |
| PCIe 3.0 ×4 | Safety MCU expansion board | ~8 GB/s | Real-time co-processor interface |
| USB 3.0 ×2 | Depth camera, USB LiDAR | 5 Gbit/s | Intel RealSense D435i compatible |
| 2× Gigabit ETH | Fleet management, IP cameras | 1 Gbit/s each | Isolated robot/infrastructure networks |
Complete System Architecture for RK3588-Based AGV/AMR
The following architecture represents a production-validated reference design for an RK3588-based AMR. Each layer is mapped to the specific SoC interface or software component that handles it.
Why the MCU Safety Layer Matters
The RK3588 runs Linux — a non-real-time OS. For motion control tasks requiring deterministic sub-millisecond response (emergency stop within 50ms of obstacle trigger, brake actuation synchronized with motor command), Linux scheduling jitter makes the main SoC insufficient as the sole control element. The correct architecture separates concerns: RK3588 handles high-level planning and AI, while a dedicated STM32 or similar safety MCU handles real-time motor control and safety-critical GPIO. The two communicate via CAN bus, with micro-ROS running on the MCU providing a ROS2-compatible interface. This matches standard practice recommended by ANSI safety guidelines for AGV/AMR systems.
ROS2 Integration on RK3588: Practical Setup Guide
ROS2 (Robot Operating System 2) is the standard middleware framework for modern AMR development. Its publisher/subscriber communication model, standardized message types, and extensive package ecosystem — including the Nav2 navigation stack and SLAM Toolbox — make it the default starting point for new robot software platforms. The RK3588 supports ROS2 natively on Ubuntu 22.04, with no cross-compilation or custom kernel modifications required.
Recommended ROS2 Distribution and Installation
ROS2 Humble Hawksbill (Ubuntu 22.04 LTS) is the recommended distribution for production RK3588-based robot deployments. Its Long Term Support commitment extends to May 2027, providing a stable base for products with multi-year deployment horizons. Installation follows the standard apt repository method.
# Добавьте репозиторий ROS2 apt
sudo apt install software-properties-common
sudo add-apt-repository universe
sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key \
-o /usr/share/keyrings/ros-archive-keyring.gpg
# Install ROS2 Humble base + Nav2 stack
sudo apt install ros-humble-desktop
sudo apt install ros-humble-navigation2 ros-humble-nav2-bringup
sudo apt install ros-humble-slam-toolbox
sudo apt install ros-humble-robot-localization
# LiDAR driver (SLAMTEC RPLiDAR)
sudo apt install ros-humble-rplidar-ros
Key ROS2 Packages for AGV/AMR on RK3588
The following packages form the core software stack for a production AMR deployment on RK3588. Each package maps to a specific subsystem in the robot’s operational architecture.
| Package | Функция | CPU Load on RK3588 |
|---|---|---|
| nav2_bringup | Path planning, costmap, behavior trees | Medium (A76 cores) |
| slam_toolbox | 2D LiDAR SLAM — online/offline mapping | Medium-High |
| robot_localization | EKF multi-sensor fusion (odometry + IMU) | Low-Medium |
| rplidar_ros | SLAMTEC RPLiDAR A1/A3/S2 driver | Низкий |
| realsense2_camera | Intel RealSense D435i depth driver | Low (USB3) |
| micro_ros_agent | Bridge to STM32 safety MCU via UART | Очень низкий |
| rknn_ros (custom) | NPU inference results → ROS2 topics | Low (NPU handles inference) |
AMP Architecture: ROS2 High-Level Control + Real-Time MCU
A common misconception in embedded robotics is that the main application processor must handle all control tasks. For RK3588-based AMR designs, the correct architecture is Asymmetric Multi-Processing (AMP): the RK3588 runs ROS2 for high-level perception and planning, while a separate real-time MCU handles motor control loops and safety-critical outputs.
Communication between the two processors uses micro-ROS on the MCU side, providing a standard ROS2 topic interface for velocity commands and encoder feedback. Total command latency from Nav2 velocity output → CAN frame → MCU → motor driver is typically under 5ms in well-tuned implementations — sufficient for AMR speeds up to 2 m/s. For more detail on Linux real-time considerations for RK3588, see our Linux vs Android на RK3588 руководство.
SLAM and Sensor Fusion on RK3588
Simultaneous Localization and Mapping (SLAM) is the foundational technology that enables an AMR to build a map of its environment and determine its position within that map in real time. According to the standard definition, SLAM requires concurrent estimation of the robot’s pose and the structure of the unknown environment — a computationally intensive task that runs continuously during operation.
LiDAR SLAM vs. Visual SLAM: Which Approach for Your Robot?
Two primary SLAM approaches are viable on RK3588-based platforms. The right choice depends on the operating environment, cost constraints, and accuracy requirements.
| Размер | LiDAR SLAM | Visual SLAM (vSLAM) |
|---|---|---|
| Точность | High (2–5 cm typical) | Medium (5–20 cm) |
| Sensor cost | Higher ($100–$800+) | Lower (camera $30–$150) |
| Lighting dependency | Low (IR-based) | High (degrades in low/harsh light) |
| RK3588 interface | UART / USB (serial data) | MIPI CSI + NPU feature extraction |
| CPU load on RK3588 | Medium (SLAM Toolbox) | Medium-High (ORB-SLAM3) |
| NPU acceleration | Not applicable | Feature extraction CNN (partial) |
| Typical use case | Warehouse AMR, industrial AGV | Cost-sensitive AMR, outdoor robot |
| Recommended package | SLAM Toolbox (ROS2) | ORB-SLAM3 / RTAB-Map |
Multi-Sensor Fusion with robot_localization
Accurate localization in dynamic warehouse environments requires fusing data from multiple sensor modalities. The robot_localization package implements an Extended Kalman Filter (EKF) that combines wheel odometry, IMU acceleration and gyroscope data, and LiDAR scan matching into a single consistent pose estimate. On the RK3588’s A55 cores, the EKF update loop runs stably at 50 Hz with typical CPU utilization under 8%.
The NPU contributes to the visual localization pipeline when stereo cameras are used. Feature extraction backbone networks (MobileNetV3) run on the NPU at low latency, providing point descriptors to the SLAM algorithm without CPU overhead. As DigiKey’s AMR integration guide notes, combining proprioceptive sensors (encoders, IMU) with exteroceptive sensors (LiDAR, cameras) through sensor fusion is essential for robust AMR navigation in real-world environments.
Obstacle Detection Pipeline: NPU to Safety Stop
The obstacle detection pipeline is the most latency-sensitive AI workload on the robot. A person stepping into the robot’s path must trigger a safety stop within a time window defined by operating speed and braking distance — at 1.5 m/s with a 30 cm braking distance, the system has approximately 200ms from detection to full stop.
The RK3588 NPU runs YOLOv8n at 65 FPS (15ms per frame). Postprocessing and GPIO emergency stop signal generation adds approximately 8–12ms. The safety MCU receives the stop command via CAN and activates the brake within 5ms. Total detection-to-brake latency: approximately 30–35ms — well within the 200ms budget at 1.5 m/s operating speed and within standards for safety-critical motion systems.
Safety Standards for AGV/AMR: What Your Embedded Control Board Must Support
Safety compliance is not optional for commercial AGV/AMR deployments. Warehouse operators, insurance providers, and regulatory bodies in major markets require demonstrable compliance with applicable safety standards before autonomous vehicles operate in spaces shared with personnel. Understanding which standards apply and how your control board architecture must support them is a prerequisite for product development — not an afterthought.
Applicable Standards
ISO 3691-4 covers industrial trucks — including driverless industrial trucks (AGVs) — and specifies safety requirements for the vehicle and its control systems. It requires that safety-relevant functions (emergency stop, speed limiting, obstacle response) be implemented with sufficient reliability and that failure modes be analyzed.
ANSI/ITSDF B56.5 is the North American equivalent standard for driverless automatic guided industrial vehicles. Both standards require a safety architecture where safety-critical functions cannot be overridden by application software failures.
IEC 61508 / SIL2 defines functional safety requirements for electrical/electronic systems. Most AMR deployments target SIL2 for safety functions — meaning the safety subsystem must have a probability of dangerous failure on demand below 10⁻³ per hour.
Architecture Requirement
The RK3588 running Linux is not certifiable as a SIL2 safety controller — Linux is not a safety-certified RTOS. The correct architecture places all safety-critical functions (emergency stop actuation, safety scanner monitoring, speed envelope enforcement) on a separate dedicated safety MCU or safety PLC, with the RK3588 handling perception and planning only. This two-processor architecture is standard practice and does not limit the robot’s capabilities.
Control Board Architecture for Compliant Designs
A compliant RK3588-based AGV/AMR control system separates responsibility clearly. The RK3588 handles environment perception (SLAM, obstacle detection), path planning (Nav2), fleet communication, and HMI. The safety MCU — running a certified RTOS or bare-metal safety firmware — handles emergency stop signal monitoring, safety scanner zone evaluation, maximum speed enforcement, and brake actuation. The two processors communicate over CAN, but the safety MCU operates independently and can enforce safety limits even if the RK3588 experiences a software fault.
RK3588 vs. X86 Industrial PC for AGV/AMR Control
The decision between ARM-based embedded control boards and x86 industrial PCs is frequently framed as a performance comparison. In practice, for AGV/AMR applications, it is primarily a cost, power, and thermal management comparison — with the RK3588 holding structural advantages on all three dimensions.
| Размер | X86 Industrial PC | Встраиваемая плата RK3588 | Advantage |
|---|---|---|---|
| BOM Cost | $500–$1,500/unit | $80–$250/unit | RK3588 −60–80% |
| Typical Power Draw | 50–100W | 5-13W | RK3588 −85% |
| Cooling Requirement | Active (fan required) | Passive (heatsink) | RK3588 |
| Board Dimensions | Mini-ITX+ (170×170mm) | SBC ~100×72mm | RK3588 |
| Integrated NPU | ❌ (GPU card needed) | ✅ 6 TOPS | RK3588 |
| ROS2 Support | ✅ Mature x86 ecosystem | ✅ Ubuntu 22.04 ARM64 | Even |
| Real-Time Control | Needs RT patch/RTOS | Needs safety MCU (same) | Even |
| Время загрузки | 30–60 seconds | 10–20 seconds | RK3588 |
| Operating Temp (J-grade) | 0–60°C (standard) | от -40°C до +85°C | RK3588J |
| MTBF (fanless config) | Limited by fan lifecycle | Higher (no moving parts) | RK3588 |
| 100-unit fleet BOM delta | ~$75,000–$150,000 | ~$8,000–$25,000 | RK3588 saves $50K–$125K |
The x86 platform retains one meaningful advantage: a broader ecosystem of pre-compiled robotics software packages and greater single-thread CPU performance for computationally intensive tasks like 3D point cloud processing. For AMR applications that require Velodyne-class 3D LiDAR with dense point cloud SLAM, or that run large neural network models beyond the NPU’s capacity, x86 remains viable. For the majority of warehouse AMR, inspection robot, and service robot applications, the RK3588’s advantage profile is decisive.
Solving a Thermal Throttling Crisis on a Warehouse AGV Fleet
A logistics automation integrator contacted us eight months into a 24-unit AGV fleet deployment at a large regional distribution center. Their vehicles — responsible for pallet shuttling between receiving docks and sortation stations — were experiencing an operational pattern that had stumped their software team: after approximately four hours of continuous operation, a growing number of AGVs would begin triggering unnecessary safety stops, slowing progressively and eventually requiring manual restart to resume normal operation.
The integrator’s engineering team had ruled out software bugs (the behavior was time-correlated, not event-correlated), navigation map drift (static environment, consistent map quality), and fleet management system issues (the FMS was logging normal command traffic). What they had not checked was the x86 industrial PC’s thermal log.
We requested the system performance logs from five units over a 6-hour run. The pattern was unambiguous: CPU temperature inside the sealed AGV chassis climbed steadily from 42°C at startup to 74°C at the 4-hour mark, at which point the processor began throttling from its nominal 2.8GHz to 1.1GHz. Nav2’s path planning computations — which ran in approximately 80ms at full speed — were now taking 290–340ms at throttled speed. The Nav2 controller server was timing out velocity commands, which the robot’s safety logic correctly interpreted as a control system fault and responded to with a safety stop.
The fix was a platform migration, not a software patch. We replaced the x86 industrial PC with an ieeker RK3588J industrial SBC plus a dedicated STM32 safety MCU on a custom carrier board. Total system power draw inside the chassis dropped from 68W to 11W. The sealed chassis internal temperature during 12-hour continuous operation peaked at 47°C — 27°C below the previous platform’s throttling threshold.
47°C
Peak chassis temp (was 74°C)
11W
System power (was 68W)
72ms
Nav2 planning latency (stable)
$420
BOM saving per unit
The 24-unit re-fitted fleet has operated for six months since migration with zero thermal-related incidents. The integrator has since specified the RK3588J platform for their next 40-unit project from the design phase. The lesson is consistent with what we see across deployments: in sealed mobile robot enclosures, thermal design constrains your platform choice far more than peak compute specifications suggest.
40-Unit Goods-to-Person AMR Fleet for E-Commerce Intralogistics
In Q3 2024, a cross-border e-commerce warehouse operator based in Malaysia contracted us for embedded computing hardware to power a 40-unit autonomous mobile robot fleet for their 10,000 m² fulfillment center. The fleet’s job: goods-to-person transport between storage racks and picking stations, running three shifts, 7 days a week.
Hardware specification per unit: ieeker RK3588 industrial SBC, RPLiDAR A3 (UART), Intel RealSense D435i (USB3), 9-axis IMU (SPI), STM32-based motor control sub-board (CAN). Software stack: Ubuntu 22.04, ROS2 Humble, Nav2, SLAM Toolbox, robot_localization EKF, custom YOLOv8n person detection node using RKNN Runtime. Fleet management via proprietary FMS over WiFi 6.
The NPU runs person detection continuously during operation. When a person enters the robot’s forward detection zone (3m radius), a ROS2 safety topic publishes a slow-down command; when they enter the 1m stop zone, a GPIO signal triggers the STM32’s emergency stop sequence directly — bypassing the ROS2 communication layer entirely for deterministic response.
4.2 min
Avg task time (human: 7.1 min)
>2,000h
MTBF — 6 months, zero downtime
±15mm
Docking accuracy at shelf
99.97%
Person avoidance success rate
3.8W
Control board power (12V LiPo)
$380/unit
Saving vs x86 alternative
The 3.8W control board power draw — versus 65W for the x86 alternative considered during vendor selection — extended the AMR’s battery range by approximately 22% per charge cycle, enabling the three-shift schedule without mid-shift recharging interruptions that the x86-based design would have required.
Choosing the Right RK3588 Development Board Form Factor for Your Robot
Three hardware form factors are available for RK3588-based robot control systems. The right choice depends on production volume, chassis space constraints, and the degree to which your robot’s I/O configuration diverges from standard development board layouts.
🧩 Core Board (SoM) + Custom Carrier
- Minimum board footprint (45×45mm to 70×40mm)
- Full custom I/O layout for motor interfaces
- Ideal for mass production (>500 units)
- Highest design effort, longest lead time
- Best long-term BOM cost per unit
🔧 Industrial SBC (Development Board)
- Complete board with standard I/O matrix
- Fastest path to prototype and validation
- Suitable for 10–500 unit production runs
- Standard CAN, RS485, UART, MIPI included
- ieeker RK3588 SBC: Orange Pi 5 compatible
For the majority of new robot programs, the industrial SBC is the right starting point. It eliminates hardware bring-up time, provides a validated BSP, and supports full ROS2 development from day one. Once the software stack is stable and the production volume justifies the engineering investment, a migration to a custom carrier board with SoM can optimize size and cost for high-volume production. For a detailed treatment of when SoM vs. SBC is the better choice, see our SoM vs. SBC guide.
Is RK3588 the Right Robot Control Board for Your Application?
Use this checklist to evaluate fit before committing to the platform. A majority of green items confirms strong alignment; multiple amber or red items suggests evaluating alternatives or supplementary hardware.
✅Warehouse AMR / goods-to-person robot — optimal fit. LiDAR SLAM + Nav2 + NPU person detection runs within spec.
✅Inspection robot (factory, substation, data center) — strong fit. Camera-based defect detection + NPU + multi-interface connectivity aligned.
✅Service robot (hotel, hospital, retail) — strong fit. Android or Linux HMI, face recognition NPU, compact form factor.
✅Light industrial AGV (<1,000 kg payload) — strong fit with RK3588J + safety MCU architecture.
✅Delivery robot (indoor, campus) — strong fit. Low power, compact, WiFi/5G fleet management support.
⚠️Heavy industrial AGV (>1,000 kg) — workable with supplementary safety PLC. RK3588J handles perception; dedicated safety controller handles motion authority.
⚠️Outdoor full-terrain AMR — workable with additional GPS module and weather-rated enclosure. RK3588J temperature range is sufficient.
⚠️Dense 3D point cloud SLAM (Velodyne VLP-16+) — CPU-intensive; profiling recommended. May require Buildroot-optimized image and CPU affinity tuning.
❌SIL3+ certified safety functions — RK3588 cannot be the safety controller. Use a certified safety PLC or safety-rated MCU for all SIL3+ functions.
❌CUDA-dependent model inference — models requiring TensorRT/CUDA (Jetson-specific optimizations) are not portable to RKNN. Evaluate Jetson Orin Nano for CUDA-dependent workloads.
Часто задаваемые вопросы
Can RK3588 run ROS2 without a real-time OS patch?
Yes. ROS2 Humble runs on standard Ubuntu 22.04 on the RK3588 without any RT kernel modifications. For most AMR applications, standard Linux scheduling is sufficient for high-level navigation tasks. Real-time requirements for motor control are handled by a separate STM32 or similar MCU communicating via CAN or micro-ROS. If soft real-time latency improvement is needed for specific ROS2 nodes, the PREEMPT-RT patch is available for the RK3588 Linux kernel.
Does RK3588 support SICK, Hokuyo, and RPLiDAR scanners?
Yes. All major 2D LiDAR brands used in AGV/AMR applications connect via UART or USB. SICK S300/TiM series, Hokuyo URG-04LX/UST series, and SLAMTEC RPLiDAR A1/A3/S2 all have ROS2 driver packages and connect to the RK3588’s UART or USB 3.0 ports without modification. ieeker’s RK3588 SBC BSP includes validated UART DMA configuration for low-latency LiDAR data reception.
What is the difference between RK3588 and RK3588J for robot deployments?
The RK3588J is the industrial-grade variant with extended operating temperature validation (−40°C to +85°C vs. 0°C to 70°C for commercial grade), enhanced ECC memory support, and AEC-Q100-aligned qualification testing. For robot deployments in controlled indoor warehouse environments, the commercial RK3588 grade is typically sufficient. For outdoor robots, cold-storage warehouse AGVs, or any deployment with ambient temperatures outside the 0–70°C range, the RK3588J is the correct choice.
Can SLAM and obstacle detection run simultaneously on the RK3588?
Yes. This is one of the RK3588’s defining advantages for robotics. SLAM Toolbox (LiDAR-based, CPU) runs on A76 cores while YOLOv8n obstacle detection runs on the NPU — the two pipelines do not compete for the same compute resource. In our deployment testing, simultaneous SLAM + YOLOv8n + EKF sensor fusion + Nav2 path planning consumes approximately 55–65% of A76 CPU capacity, leaving headroom for fleet communication, logging, and additional sensor drivers.
Ready to Build Your Next AGV or AMR on RK3588?
Whether you’re evaluating the platform for the first time, scaling an existing fleet, or designing a custom control board for a new robot program — ieeker’s RK3588 industrial SBCs provide a production-validated starting point with pre-configured ROS2 images, CAN/RS485 driver support, and engineering team backing from prototype to mass productio
Sources & References
- AGV and AMR Market to Reach ~$22 Billion by 2030 — LogisticsIQ (5th Edition)
- Mobile Robots Market Size & Forecast 2025–2030 — Mordor Intelligence
- Simplify AMR and AGV Integration with ROS2 Components — DigiKey
- Powering Autonomous Mobility with RK3588J AGV/AMR Controller — Vantron
- Simultaneous Localization and Mapping — Wikipedia
- Navigation2 (Nav2) ROS2 Documentation — nav2.org
- RK3588J SBC Solution for AGV/AMR — Dusun IoT
- Применение интеллектуального инспекционного робота на базе RK3588J - Forlinx
- RKNN-Toolkit2 - Rockchip GitHub
- ANSI/ITSDF B56.5 - Американский национальный Институт стандартов
