تشغيل أي مهارة في Manus بنقرة واحدة

rdk-hardware

النجوم٨٠

التفرعات٨

آخر تحديث٢٨ يونيو ٢٠٢٦ في ٠٧:٤١

The hardware-facts base for RDK boards — the 6-board spec table (X3 / X5 / Ultra / S100 / S100P / S600) plus 40PIN/GPIO, buses (I2C/SPI/UART/PWM), power & LED meaning, display, network/IP, and CAN. Use WHENEVER a question is about a board hardware fact: are the pins the same across boards, how the 40PIN is wired, IO voltage, default username/password, model dir location, which interfaces exist, TOPS/RAM differences, cooling, OS-version line, or system paths. Answer from here — do not guess from memory, the per-board numbers really do differ. 触发词:各板引脚一样吗、40PIN怎么接、IO电平、1.8V还是3.3V、默认用户名密码、root/sunrise、模型目录在哪、有没有CAN口、ip link can0、网口默认IP、192.168.127.10、连不上板子、算力多少TOPS、内存多大、要不要散热、供电几V、电源灯什么颜色、HDMI分辨率、Ubuntu几、TROS路径、板型怎么查。Routing — error-code / boot-failure → rdk-board-knowledge; driving a peripheral (blink LED, spin motor, read I2C, send CAN frames) → rdk-peripheral-cookbook; model deploy / toolchain / camera bringup → rdk-device; which board to buy → rdk-ecosystem.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

D-Robotics

D-Robotics/moss

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مديرو الشبكات وأنظمة الحاسوبمهن الحاسوب والرياضيات·SOC 15-1244

مستكشف الملفات

4 ملفات

SKILL.md

readonly

المزيد من هذا المستودع

نفس المستودع

rdk-device

D-Robotics/moss

End-to-end deployment of a user's OWN model on RDK boards — quantize .pt/.onnx into .bin (X3/X5/Ultra) or .hbm (S100/S100P/S600) through the BPU toolchain — plus first-boot/network setup, camera bringup, and on-board inference debugging. Use whenever the user is deploying a self-trained model, reports slow inference (1-2 FPS, "pt 拷上去很慢"), is doing first boot / 开箱 / 入门, or debugging a camera or 推理 pipeline. 触发词:部署模型、YOLO 转换、hb_mapper、hb_compile、量化、.bin/.hbm、pt 直接跑很慢、BPU 推理、首次开箱、新手上手、摄像头无画面、v4l2。Routing — ready-made precompiled models → rdk-model-zoo; inference as a ROS node / stereo depth / lidar → rdk-ros; embodied ACT/VLA/Pi0 BPU compile → rdk-embodied-lerobot; pure error-code lookup → rdk-board-knowledge.

2026-07-1680

rdk-ros

D-Robotics/moss

TROS (TogetheROS.Bot) / ROS2 development on RDK boards — pick the right perception node for a capability (detection, segmentation, body/face/hand, stereo depth, 3D/lidar, VLM/LLM, audio), launch it with the correct platform and topics, debug "ros2 command not found" / package / launch problems, and follow the official end-to-end robot app cases (AMR, line-follower). Use whenever the user is on an RDK board and mentions TROS, ROS2, a perception node, a topic/launch/package, stereo depth, lidar, or a TROS app. 触发词:TROS、ros2 命令找不到、source /opt/tros、jazzy、humble、双目深度、stereonet、激光雷达、livox、点云、SLAM、nav2、人体检测、手势识别、人脸、YOLO 节点、dnn_node_example、hobot_dnn、ai_msgs、hbmem_img、巡线小车、AMR、感知节点用哪个。Routing — camera format/driver bringup (v4l2, MIPI sensor, no image) → rdk-device; GPIO/peripheral wiring → rdk-peripheral-cookbook; converting your own model to .bin/.hbm → rdk-device; ready-made model picking → rdk-model-zoo.

2026-07-1680

host-software-dev

D-Robotics/moss

Host-side (x86 PC) software/tooling for RDK dev — the RDK Studio desktop client (install/login/flash/connect/CLI), the x86 Docker BPU toolchain that produces .bin/.hbm, the host flashing tools (RDK Studio/Rufus for X-series SD, Xburn for S-series USB), AND the Electron/React/Vite/Node/TypeScript engineering of building RDK Studio itself. Use whenever the work happens ON THE PC rather than on the board — installing or driving RDK Studio, choosing a flasher, setting up the toolchain Docker, or fixing a desktop-app build/IPC/HMR/packaging issue. 触发词:RDK Studio、studio 安装、烧录工具、Rufus、Xburn、烧录系统、Type-C 直连、rdkstudio 命令行、dmoss-agent、工具链 docker、x86 转换环境、Electron、preload、IPC、Vite、HMR、tsc 报错、打包签名。Routing — running things ON the board (first boot, on-board inference, camera) → rdk-device; the .pt→.bin/.hbm conversion commands → rdk-device/rdk-model-zoo; board error-code lookup → rdk-board-knowledge.

2026-06-2880

jetson-knowledge

D-Robotics/moss

NVIDIA Jetson single-platform reference — module specs and AI performance (Orin Nano / Orin NX / AGX Orin / Xavier NX / legacy Nano), the JetPack / Jetson Linux (L4T) software stack, Super Mode power profiles, and the TensorRT engine-build workflow (.onnx → .engine via trtexec / nvpmodel / jetson_clocks). Use whenever someone asks about Jetson hardware specs, "多少 TOPS", JetPack/L4T versions, how to flash or set up a Jetson, or how to run a model on Jetson with TensorRT. 触发词:Jetson、Orin Nano、Orin NX、AGX Orin、Xavier NX、Jetson Nano、多少 TOPS、Super 模式、JetPack 版本、L4T、刷机、tegrastats、jtop、TensorRT、trtexec、engine 转换、nvpmodel、jetson_clocks、CUDA 版本。Routing — comparing Jetson against RDK / Raspberry Pi / RK3588 or "买 Jetson 还是 RDK" selection → rdk-ecosystem (cross-platform comparison lives there, anchored on RDK); Raspberry Pi specifics → rpi-knowledge; Rockchip RK3588 specifics → rk-knowledge. This skill covers Jetson itself only.

2026-06-2880

rdk-accessories

D-Robotics/moss

Bring up D-Robotics OFFICIAL finished accessories — GS130W / GS130Wi binocular depth cameras, the RDK IMU Module (Bosch BMI088), and the RDK S100/S600 Camera & MCU-Port expansion boards — covering selection, wiring/FFC orientation, mounting, and driver/SDK bring-up. These are plug-and-play modules with official pinouts and official SDK/IIO drivers, which is exactly what separates them from DIY peripherals. Use whenever the user asks how to connect/run one of these named parts, which launch file to use, how many CAN/GMSL/MIPI an expansion board has, or which board a part supports. 触发词:GS130W、GS130Wi、双目相机怎么接、22pin 线序、mipi_cam dual、RDK IMU 模组、BMI088、IMU 读数、IIO 驱动、rdk-imu-module-sdk、S100 相机扩展板、S600 相机扩展板、MCU 扩展板、几路 CAN、几路 GMSL、GMSL 供电、扩展板装在哪块板。Routing — DIY a sensor/motor/LED on raw GPIO/I2C/SPI/PWM → rdk-peripheral-cookbook; the board's OWN 40PIN/CAN/Ethernet/compute facts → rdk-hardware; bringing up an UNSUPPORTED MIPI sensor → rdk-mipi-camera-bringup; model deploy / TROS node dev → rdk-device / rdk-ros.

2026-06-2880

rdk-board-delegate

D-Robotics/moss

Deep S-series (S100/S100P/S600) "big-brain / little-brain" heterogeneous development — MCU1 FreeRTOS firmware (build, remoteproc load, IPC, UART, CAN) AND the Acore/Linux subsystems unique to S boards (hbmem zero-copy shared memory, Acore↔MCU/VDSP/BPU IPC with real-time core pinning, PCIe RC/EP, EtherCAT master, PTP/gPTP, OTA + miniboot, VDSP). Also covers delegating a board task to the OpenClaw agent (board_openclaw_chat / board_openclaw_delegate) with a complete handoff packet. Use whenever the user works on S100/S100P/S600 MCU firmware, real-time joint/motor control, CPU↔MCU IPC, EtherCAT/PTP, PCIe, system upgrade, the vector DSP, or asks how the CPU+BPU+MCU split works. 触发词:S100、S100P、S600、MCU、小脑、大脑、R52、FreeRTOS、固件、remoteproc、烧固件、关节实时控制、电机回路、IPC、共享内存、hbmem、零拷贝、EtherCAT、运动控制主站、PTP、时间同步、PCIe、OTA、miniboot、VDSP、大小脑异构、CAN、OpenClaw、板端委派。Routing — .hbm compile → rdk-device; ready-made models → rdk-model-zoo; ROS/stereo/lidar → rdk-ros; LLM/VLM → rdk-llm-deployment; error-code lookup → rdk-board-knowledge.

2026-06-2880

name: rdk-hardware description: The hardware-facts base for RDK boards — the 6-board spec table (X3 / X5 / Ultra / S100 / S100P / S600) plus 40PIN/GPIO, buses (I2C/SPI/UART/PWM), power & LED meaning, display, network/IP, and CAN. Use WHENEVER a question is about a board hardware fact: are the pins the same across boards, how the 40PIN is wired, IO voltage, default username/password, model dir location, which interfaces exist, TOPS/RAM differences, cooling, OS-version line, or system paths. Answer from here — do not guess from memory, the per-board numbers really do differ. 触发词:各板引脚一样吗、40PIN怎么接、IO电平、1.8V还是3.3V、默认用户名密码、root/sunrise、模型目录在哪、有没有CAN口、ip link can0、网口默认IP、192.168.127.10、连不上板子、算力多少TOPS、内存多大、要不要散热、供电几V、电源灯什么颜色、HDMI分辨率、Ubuntu几、TROS路径、板型怎么查。Routing — error-code / boot-failure → rdk-board-knowledge; driving a peripheral (blink LED, spin motor, read I2C, send CAN frames) → rdk-peripheral-cookbook; model deploy / toolchain / camera bringup → rdk-device; which board to buy → rdk-ecosystem.

RDK Hardware & System Facts

The single most important rule: per-board hardware facts are NOT uniform — confirm the board first, then read its row. Pin voltage, power-LED color, default IP, CAN type, and model format all differ across the six boards. Reciting a "typical RDK board" from memory is how wrong answers happen.

Sources: official D-Robotics hardware-introduction docs — rdk_x_doc (X3/X5), rdk_doc (Ultra), rdk_s_doc (S100/S600). Re-verified against those pages. Per-board numbers are pinned in board-specs.md; deterministic lookup in scripts/board_specs.py.

Confirm the board first

cat /sys/class/socinfo/board_id      # universal, all boards
cat /proc/device-tree/model          # board name string
cat /etc/version                     # OS image version (rdkos_info on 2.1.0+)

Never assume the board. An X3 pinout handed to an X5 user, or a SocketCAN command on an S100, is a real and common failure.

The 6-board hardware cheat-sheet

Board	BPU arch	INT8 TOPS	RAM	Model	OS / TROS	Power & LED	40PIN IO	CAN	Default eth IP
X3	Bernoulli2	5	2 GB	`.bin`	22.04 / Humble	5V/3A USB-C, red LED	3.3V	none	`192.168.1.10` (`.127.10` on 2.1.0+)
X5	Bayes-e	10	4/8 GB	`.bin`	22.04 / Humble	5V/5A USB-C, green+orange	3.3V	SocketCAN `can0` (TCAN4550)	`192.168.127.10`
Ultra	Bayes	96	8 GB	`.bin`	22.04 / Humble	≥12V/5A DC, red LED	3.3V	none	`192.168.1.10`
S100	Nash-e	80	12 GB	`.hbm`	22.04 / Humble	12–20V DC, green+orange	3.3V	MCU CANHAL (CAN5–9)	eth1 fixed `192.168.127.10`
S100P	Nash-m	128	24 GB	`.hbm`	22.04 / Humble	12–20V DC, green+orange	3.3V	MCU CANHAL (CAN5–9)	eth1 fixed `192.168.127.10`
S600	Nash	560	32/64 GB	`.hbm`	24.04 / Jazzy	12–28V DC, green+orange	1.8V, NO 40PIN	MCU CANHAL (MCU×5 + Main×4)	eth1 fixed `192.168.127.10`

Five facts people get wrong — verified against official docs:

Power LED color is not uniform. X3 and Ultra = RED. X5 and S-series = green power + orange status/Main-running.
Only X5 is Linux SocketCAN (can0). X3/Ultra have no CAN. S100/S100P/S600 CAN is MCU-domain via CANHAL — no can0, ip link does not apply.
S600 has no 40PIN header and its digital IO is 1.8V (every other board's 40-pin is 3.3V) on self-locking connectors (2×10 + 1×12 + 1×14-pin).
S600 runs Ubuntu 24.04 + TROS Jazzy (/opt/tros/jazzy/, tros-jazzy-*); S100/X-series run 22.04 + Humble. Don't copy paths/package names.
Default IP differs by board AND firmware. X3 ≤2.0.0 / Ultra = 192.168.1.10; everything else = 192.168.127.10 (S-series on the fixed eth1).

Model artifacts never cross BPU architectures: X3/X5/Ultra → .bin, S100/S100P/S600 → .hbm. Recompile per board. (The conversion toolchain itself is the rdk-device skill.)

Workflows

Workflow 1 — Answer a per-board hardware fact

Confirm the board (cat /sys/class/socinfo/board_id) or take it from the user's words.
Look up the row — run python3 scripts/board_specs.py <board> (or --field can|power|io_level|default_ip|...) for a deterministic answer; full detail in board-specs.md.
Quote the exact number for THAT board — never average across boards or assume a "typical" value.
Flag a cross-board trap if the user is mixing boards (X3 pinout ≠ X5; S600 IO is 1.8V; S600 path is jazzy not humble).

Workflow 2 — 40PIN / GPIO / bus wiring

Confirm the board and its IO voltage — 3.3V on X3/X5/Ultra/S100/S100P; 1.8V on S600 (and S600 has no 40-pin, use its self-locking connectors).
The header is RPi-compatible in shape only — GPIO numbering differs, never reuse RPi pin numbers. Python uses Hobot.GPIO, C uses libwiringpi.
Check what the 40-pin actually exposes — on S100/S100P only a subset (I2C5 / UART2-muxed / SPI0 / 2×LPWM / 10×GPIO on J24); the rest of the SoC's buses are on the MCU/Camera 100-pin connectors. Details in hardware-notes.md §1, §3.
For actually driving the pin (toggle GPIO, PWM a servo, read an I2C sensor) → route to rdk-peripheral-cookbook. This skill states the facts; that one does the wiring.

Workflow 3 — CAN bus

Determine CAN type by board (cheat-sheet column):
- X5 only is Linux SocketCAN: ip link set can0 type can bitrate 500000 [dbitrate ... fd on] && ip link set can0 up (TCAN4550, up to 8 Mbps; close the 120Ω termination switch for long/fast runs).
- X3 / Ultra have no CAN.
- S100/S100P/S600 CAN is in the MCU domain via CANHAL — there is no can0 netdev and ip link does NOT work. Frames go through CAN2IPC → IPC → A-core CANHAL.
If the user tries ip link on an S-series board — stop them: explain it's MCU-domain CANHAL, then route the actual send/receive to rdk-peripheral-cookbook.

Workflow 4 — Power, cooling, and the indicator LED

Match the supply (cheat-sheet): X3 5V/3A USB-C, X5 5V/5A USB-C, Ultra ≥12V/5A DC, S100/S100P 12–20V DC (150W), S600 12–28V DC (16A). Never power from a laptop USB port — under-supply causes brown-outs / reboot loops.
Read the LED correctly — X3/Ultra: a red LED means power OK. X5/S-series: green = power OK, orange = status/Main running (orange blink on X5 needs firmware 3.1.0+).
Cooling — Ultra requires active cooling (ships a fan); S-series (especially S600 @560 TOPS) needs a fan + heatsink under load. Monitor with hrut_somstatus.

Worked Examples

Example 1 — "RDK 各个板子的引脚都一样吗?能直接套树莓派的接线吗?" No on both counts. The 40-pin is RPi-compatible in shape but GPIO numbering differs (use Hobot.GPIO, not RPi numbers). Across RDK boards the pinout differs too — X5 has more UART/PWM/I2C than X3. And S600 has no 40-pin at all: it uses self-locking connectors at 1.8V IO (not 3.3V), so wiring 3.3V peripherals straight in is wrong. Confirm the board first, then read its row in board-specs.md.

Example 2 — "S100 上怎么用 CAN?我 ip link set can0 up 报错没有这个设备。" That's expected — S100's CAN is not Linux SocketCAN. The CAN controllers (CAN5–CAN9) are in the MCU domain and reached through the CANHAL library, so there is no can0 netdev and ip link doesn't apply. (Only X5 has SocketCAN can0, via TCAN4550.) For sending/receiving frames on S100, route to rdk-peripheral-cookbook.

Example 3 — "板子默认用户名密码是什么?网口连不上。" Depends on the board. X5/Ultra: root/root (and sunrise/sunrise). S100/S100P/S600: the wizard sets both sunrise/sunrise and root/root. X3: sunrise/sunrise primary, root/root usually present. For "won't connect" on an S-series board, the outer port eth1 is a fixed static 192.168.127.10 — set your PC to the same subnet (e.g. 192.168.127.100) and try ssh root@192.168.127.10.

Example 4 — "S600 和 S100 是不是一样的,文档能照搬吗?" No — re-confirm before copying. S600 is the new flagship: 18× A78AE + 6× R52+ + 4× Nash BPU (560 TOPS), and it runs Ubuntu 24.04 + TROS Jazzy (/opt/tros/jazzy/, packages tros-jazzy-*), whereas S100 is 22.04 + Humble. S600 also has no 40-pin and 1.8V IO. Same .hbm model family and hbm_runtime, but paths, package names, and the IO interface differ — don't copy S100 commands verbatim.

Common Pitfalls

❌ Don't	✅ Do
Assume one "typical RDK board" spec	Confirm the board, read its row in board-specs.md
Reuse RPi GPIO numbers on the 40-pin	Use `Hobot.GPIO` / `libwiringpi`; numbering differs
Wire a 3.3V peripheral to S600 IO	S600 IO is 1.8V on self-locking connectors (no 40-pin)
`ip link set can0 ...` on S100/S600	Only X5 is SocketCAN; S-series CAN is MCU-domain CANHAL
Expect a green "power OK" LED everywhere	X3/Ultra power LED is red; X5/S-series green+orange
Copy S100's `/opt/tros/humble` to S600	S600 is Ubuntu 24.04 + Jazzy → `/opt/tros/jazzy/`
Power any board from a laptop USB port	Use the official supply; under-power = reboot loops
Assume `192.168.1.10` for every board	X5/S-series = `192.168.127.10`; only X3≤2.0.0/Ultra = `.1.10`

Reference Map

Read this	When
board-specs.md	Need an exact per-board number — RAM / TOPS / interface counts / power / LED / IO level / default IP / probe IDs
hardware-notes.md	Board confirmed, need a subsystem deep-dive — 40PIN, camera, buses, CAN, power, display, network, BPU monitoring, paths, thermals, OS/user differences
`scripts/board_specs.py`	Deterministic board → spec lookup (`board_specs.py s600`, or `--field can`)