D-Robotics GitHub Org Repo Map

Help a user who is staring at the D-Robotics org (350 public repos, ~440 total including private) and cannot tell which repo is which. This skill answers four questions: what is this repo, what layer/board does it belong to, which repo should I use for my task, and how do I build an image/workspace from source. The single most important rule: hobot- (hyphen) and hobot_ (underscore) are two different systems — get that wrong and every downstream answer is wrong.

Sources: live gh api orgs/D-Robotics/repos metadata (verified 2026-07, 350 public / ~440 total) plus the READMEs of rdk-gen, manifest, and robot_dev_config. Repo counts drift as the org evolves — re-run gh api to confirm before quoting an exact number.

The one distinction that matters most: hyphen vs underscore

Verified by name across all public repos (2026-07): ~20 hobot-* (X3, hyphen) + ~18 x5-hobot-* (X5, hyphen) vs ~48 hobot_* (underscore). They are NOT stylistic variants of the same thing. (Counts drift — gh api orgs/D-Robotics/repos --paginate --jq '.[].name' | grep -c 'hobot-' to recount hyphen; grep -c 'hobot_' for underscore.)

Same name across layers: hobot-dnn (hyphen — the low-level BPU inference library inside the image) is wrapped by hobot_dnn (underscore — the ROS2 dnn_node package). The rule of thumb: upper ROS node (underscore) → lower BSP library (hyphen). When a user says "hobot_dnn vs hobot-dnn," this is the answer.

Three orthogonal axes (apply all three to classify any repo)

1. Layer: BSP/system → TROS/ROS2 middleware → application/AI → product/docs.
2. Board prefix: see the table below. The bare (no-prefix) hobot-*/rdk-gen/manifest set targets RDK X3; x5- targets X5.
3. Assembly system: hobot- (hyphen, image) vs hobot_ (underscore, TROS) — the section above.

Board-prefix decision table

Do not tell a user to clone s100-rdk-gen or j5-manifest as if it were public — those prefixed BSP/build repos are private. The board-prefix → board mapping is real and useful for classifying a name, but availability differs.

Same BSP component, one copy per SoC

hobot-multimedia (X3) / x5-hobot-multimedia (X5) / s100-hobot-multimedia (S100) are the same component maintained as three SoC-specific copies. The same holds for camera / dnn / boot / dtb / wifi / io / utils / display / spdev / configs / audio-config. This is the Android/Yocto-style per-chip multi-repo BSP layout.

Two "multi-repo assembly" systems (the key to the whole org)

OS IMAGE BUILD                              TROS APP BUILD
  repo + manifest                             vcstool + ros2.repos
  entry: rdk-gen / x5-rdk-gen                 entry: robot_dev_config
  pulls kernel/uboot/bootloader/hobot-*       pulls hobot_* (underscore)
        (hyphen)                                    + rcl/rclcpp/rmw…
  → flashable RDK OS image (*.img)            → /opt/tros workspace + deb packages
  low-level, board-specific                   upper-level, cross-board (relies on BSP)

Both flows, with exact commands, are in os-image-build.md. Most users never need either — they flash an official image and apt install TROS. Only reach for source-build when customizing the image, kernel, device tree, a new sensor, or compiling all of TROS from source.

Workflow — classify an unknown repo

1. Check the suffix/prefix first (cheapest signal): *_doc/*-doc → docs; nodehub_* → NodeHub deb packaging; tros_* → TROS tooling/orchestration; magicbox_* → MagicBox product; rcl/rclcpp/rmw_*/rosbag2/vision_opencv/isaac_* → upstream ROS2 port (NOT RDK-original).
2. Check hyphen vs underscore if it contains hobot: hyphen → BSP/image; underscore → ROS2 app package.
3. Check the board prefix: none → X3, x5- → X5, s100- → S100/S100P (private), j5- → Journey 5 (private).
4. If still unsure, look it up — gh api repos/D-Robotics/<name> --jq '{lang:.language, desc:.description}', or run scripts/classify_repo.py <name> for a deterministic axis breakdown.
5. Route to the task-family table (below) for "which repo do I use."

Task → which repo family (quick lookup)

The full 12-family map with representative repo lists is in repo-families.md.

Worked examples

Example 1 — "hobot-dnn 和 hobot_dnn 有什么区别?哪个是我要的?" They are different layers. hobot-dnn (hyphen) is the low-level BPU inference library that goes into the OS image (BSP). hobot_dnn (underscore) is the ROS2 package (dnn_node) that wraps it for use as a node. If you're writing a ROS2 perception node, you want the underscore one; if you're rebuilding the system image or debugging the BPU library, the hyphen one. Rule: upper ROS node (underscore) → lower BSP lib (hyphen).

Example 2 — "我想从源码构建 S100 的系统镜像,该 clone s100-rdk-gen 吗?" The s100-rdk-gen / s100-bootloader / s100-hobot-* repos exist but are private — you can't clone them anonymously. Public source-build is available for X3 (rdk-gen + manifest) and X5 (x5-rdk-gen + x5-manifest); the flow is repo init -u …/manifest.git -b main → repo sync → ./pack_image.sh. For S100 image building, use the official prebuilt image instead, or request access. See os-image-build.md.

Example 3 — "组织里 rcl、rclcpp、rmw_cyclonedds 这些是 RDK 自己写的吗?" No. Those are upstream ROS2 repos ported/mirrored into the org for the TROS cross-compile (pulled by vcstool via ros2.repos), not RDK-original algorithms. When one of them misbehaves, check upstream ROS2 behavior first before assuming an RDK change. Same for rosbag2/vision_opencv/isaac_*.

Example 4 — "我要跑一个现成的 YOLO,该去哪个仓?S 系列的板呢?" Don't clone a BSP repo. For ready-made models use rdk_model_zoo (pick the branch matching your board — rdk_x3, rdk_x5, or a s600 feature branch) and for S-series use rdk_model_zoo_s (default branch s100). Then hand off to skill rdk-model-zoo for the actual run-on-board steps. The nodehub-x5-rdkmodelzoo-samples repo packages some of these as installable NodeHub apps.

Common pitfalls

Anti-hallucination guardrails

When answering from this skill, follow these rules — never fabricate facts, commands, or file paths:

1. Report only observed data. Quote what scripts/commands actually return, not what you remember. If the probe says board_id: X5, answer for X5 — even if the user insists it's an S100.
2. No fabrication when tools are missing. If a script or reference doesn't exist, say "not found" — don't invent from memory. Route to the appropriate skill or doc instead.
3. Preserve null/false/empty on failure. If a probe returns null or false, report that — don't substitute a plausible value. Empty output is data, not an error to "fix".
4. No substitution off-platform. If off_platform: true, say "probe didn't run on an RDK board" — don't guess what it would have returned. Ask for on-board logs.
5. No hand-editing JSON. Scripts emit structured JSON; never hand-craft output. If the contract says {ok,off_platform,reason,fields}, that's what goes to the user.
6. Acknowledge sandbox limits. If you can't run a command, say so — don't pretend you did. Offer the command for the user to run.
7. Read-only boundary. Never modify the system — no dd, mkfs, rm -rf, apt install, reboot, or GPIO output without explicit user confirmation.

Reference map