引入

以 Q1 SDK v1.0.0.0 为样本，Q1 为主、T1 对比。文中接口、参数均取自官方 SDK 源码、URDF 模型与开发者文档，配套代码见本文 AtomGit 仓库。

2026 年 9 月 20 日，启元机器人在上海发布 Q1、T1 两款个人机器人，基础版售价均为 19999 元，10 月 1 日起陆续交付；同日上线的开发者社区由 CSDN 与 AtomGit 联合建设，把 SDK、桌面端、仿真和技能分发放在了同一条链路里（来源：IT之家、dev.primebot.com）。

消费级机器人开放开发并不新鲜，真正值得拆开看的是"开放到什么粒度"。本文不写上手教程，而是顺着官方 SDK v1.0.0.0 的实际代码，把启元 Q1 的技术架构从硬件到技能包逐层讲清楚：能力如何分层、每一层暴露什么接口、安全边界划在哪里。

一、整体架构：六层技术栈

把官方文档、SDK 消息包和技能仓库拼起来，Q1 的软件栈可以归纳为六层。上层可以调用下层能力，但跨层控制（比如技能绕过运控直接写电机）不被允许。

图 1：启元 Q1 六层技术栈。开发者实际工作在第四、第五层；第二、三层由固件维护，SDK 只暴露配置和接口约定。

这条分层决定了后文的叙事顺序：越往下实时性越强、越危险；越往上语义越强、越容易开发。

二、硬件本体与双板计算

先看本体。Q1 身高 88cm、整机约 16kg、22 个自由度（双腿各 6、双臂各 4、腰部 2），采用 QDD 准直驱关节，关节模组粉末冶金减重至 260g，2.5mm 中空走线，官方标称峰值扭矩密度 85 N·m/kg（来源：primebot.com/q1.html）。探索版机身预留 USB-A、USB-C、RJ45 网口和一个 12V/5A 供电口，这是外接设备与局域网调试的物理入口。

计算上是典型的双板架构。快速入门文档写得很直白：

• 运控板（10.1.1.100）：承担 HAL 硬件抽象、MC 运动控制和交互服务，是实时性要求最高的部分；

• 大脑板（10.1.1.101）：承担 AI 算法、感知与规划，基于 NVIDIA Orin 或 RK 平台（官方未在产品页公开具体芯片型号，SDK 文档只给出平台类别）；

• 两块板子通过 ROS2 通信，开发机用网线或 WiFi 接入 10.1.1.0/24 网段后，不登录、不安装任何东西，只靠组播发现就能收发数据。

T1 在同构的软件栈上换了本体：100cm、约 16.3kg（Pro 版 16.8kg），轮足人形与四足两种形态切换，四足最大移动速度 3m/s（官方另有 10km/h 奔跑能力通过 OTA 逐步开放）、可爬 30° 坡、跨 15cm 障碍，感知配置为 5 组 ToF 加双目和两颗鱼眼（来源：primebot.com/t1.html）。理解了 Q1 的接口，T1 的差异主要体现在动作枚举（多了四足段 100–199 和形态切换 10/20）和轮足速度控制。

需要区分的是，Q1 普通版与探索版在开放程度上不同：官网参数页明确，SDK、HDK 与外接扩展接口（USB-A/USB-C/RJ45/12V 供电）仅探索版提供，普通版面向陪伴和教育，普通版支持的是零代码编排与图形化编程。换句话说，本文讨论的"技术架构"是 Q1 探索版以及 T1 开发者面对的那一层。

图 2：双板去中心化拓扑。没有中心节点，任意节点都能订阅话题、调用服务，控制权由运控板的输入源仲裁统一管理。

三、通信底座：ROS2 Humble + FastDDS

启元没有发明私有通信协议，而是直接采用 ROS2 Humble，RMW 实现固定为 rmw_fastrtps_cpp（FastDDS）。这个选择带来的直接好处是：消息定义、服务、节点都是标准 ROS2 概念，任何熟悉 ROS2 的人不需要重新学一套 SDK。

命名规范是统一的。 传感器数据走 /aima/hal/...，运动控制走 /aima/mc/...，语音交互走 /interaction/...，服务端统一挂在 /aimdk_5Fmsgs/srv/...（服务名里 aimdk_5Fmsgs 是消息包名 aimdk_msgs 的转义形式）。消息包 aimdk_msgs 按职责切成六个子模块：

子模块	职责	典型内容
hal	硬件抽象	BMS、关节状态、相机、触摸、音频、灯效
mc	运动控制	动作状态机、速度、自定义关节、预设动作
interaction	交互	TTS、表情、任务关闭
agent	智能体	ASR 语音识别结果
config	系统配置	属性读写、运行模式
common	公共定义	请求头、时间戳、通用状态码

通信参数是为机器人调过的，不是默认值。 SDK 文档给出了一整套 FastDDS 配置：UDP 单播接收缓冲调到 20M（net.core.rmem_max 等内核参数建议 24M），共享内存段给到 20GB，网卡通过 interfaceWhiteList 强制绑定，防止多网卡环境下组播发现串到错误的网卡。这几个值背后是很实际的问题：相机视频流属于高频、大包话题，再叠加高频关节指令，缓冲区不足会静默丢包，表现为画面卡顿或控制不连续。

QoS 策略按数据性质区分。 传感器话题（BMS、关节状态、视频流）统一用 BEST_EFFORT + VOLATILE + KEEP_LAST(10)，也就是允许丢帧、不保留历史，因为过期的关节状态对现在毫无价值；而动作切换、TTS 这类服务调用走可靠通道，一次都不能丢。文档还要求开发机与机器人时钟同步，否则消息里的时间戳会让跨板数据对不上。排查网络问题时，官方给的手段也很"机器人原生"：ip route 看路由、iperf 实测带宽、手动 ping 两块板子，先确认 10.1.1.100/101 都通，再谈程序。

进程管理同样是现成的开源方案。 系统使用 yamo（process_manager），开机自启动分两个阶段：先启动通信层，再启动业务进程；所有常驻服务以容器方式管理。开发者切到开发者模式后，系统自带的 HAL、MC、交互服务不能关，但可以在 yamo mode edit 里禁用大脑板上的官方 Agent 服务，把算力让给自己的程序。这意味着官方没有把"进入开发者模式"做成一个封闭开关，而是明确划分了哪些进程动得、哪些动不得。

文档把开发能力归纳为五个可配置维度：运行模式、开发方式、开发层级、领域设置、能力配置。其中"开发层级"正式分为两级：Basic（基础开发）定位为"无损能力增强"，原厂业务与安全策略保持完整，外部指令并发注入，适合非侵入式功能扩展；Advanced（高级开发）允许关闭特定官方模块，独占传感器裸流、底层运控等核心资源，做深度算法替代。入门指南则按接入深度给出了大脑板进程开发、运控板进程开发、源码级替换三条路径。模式切换后需要重新上下电才生效。carry-clothes 技能的清单里就写明 developerMode: "develop/basic"，属于基础级。需要说明的是，v1.0.0.0 版本里"领域设置"与"能力配置"暂时合并，目前只生效"运动控制—低层运控开发"选项，交互、作业和传感器领域的原子开关在文档中标注为后续开放。

四、SDK 接口层：消息域、动作状态机与控制权

这是整套架构最核心的部分。

4.1 三类接口

HAL 与 MC 的能力以三种 ROS2 原语暴露：

• Topic（订阅/发布）：持续的数据流和控制流，如 /aima/hal/bms/state（电池）、/aima/mc/locomotion/velocity（速度）、/aima/mc/custom/joint/command（上肢关节指令）；

• Service（同步调用）：一次性、有返回的指令，如 SetMcAction（切状态）、SetMcPresetMotion（播预设动作）、PlayTts（播报）、CaptureJpegImage（抓图）；

• 消息字段的统一约定：请求带 RequestHeader（时间戳、来源 source），返回带状态码 code。

以最简单的电池订阅为例，它就是一个标准 ROS2 节点：

# onboard/01_read_bms.py（节选）
from rclpy.qos import QoSProfile, ReliabilityPolicy, HistoryPolicy, DurabilityPolicy
from aimdk_msgs.msg import Bms

qos = QoSProfile(history=HistoryPolicy.KEEP_LAST, depth=10,
                 reliability=ReliabilityPolicy.BEST_EFFORT,
                 durability=DurabilityPolicy.VOLATILE)
self.create_subscription(Bms, "/aima/hal/bms/state", self._on_bms, qos)

def _on_bms(self, msg: Bms):
    self.get_logger().info(
        f"电量 {msg.remaining_capacity_percentage}%  "
        f"电压 {msg.voltage / 1000:.2f}V  "
        f"温度 {msg.temperature:.1f}℃")

Bms.msg 的字段密度很高：电压（mV）、电流（mA）、温度、剩余容量、循环次数，外加一个 32 位状态字逐位标注过流、过压、过温等故障标志。这说明 HAL 层不是包装过的"黑盒电量百分比"，而是把电池管理的原始信息完整暴露了出来。

顺着接口列表扫一遍，HAL 与交互层的能力边界也很清楚：

• 感知输入：CaptureJpegImage 服务取单帧 JPEG、/aima/hal/... 视频流话题取连续流（RTSP 同源），TouchState 是头部触摸事件，agent 模块的 ASR 话题输出语音识别结果；

• 音频：麦克风采集话题、扬声器播放服务（支持 PC 端音频推流到机器人）、独立的音量与静音服务；

• 表达输出：PlayTts 服务（优先级分 6 个层级 L1/L2/L4/L6/L8/L10，从后台服务到生命安全逐层升高，另可带播报域 domain 和 trace_id，播报状态通过 /interaction/tts_status 回传）、表情服务、头部灯带与颈灯服务；

• 系统控制：GetAgentPropertiesRequest / SetAgentPropertiesRequest 可以读写运行模式，shutdown_task 示例演示了关机流程。

可以看出一个取舍：能直接拿到的是原始数据（音频流、JPEG、触摸事件），而不是"识别好的语义"。ASR 给了结果流，但没有开放唤醒词和对话模型的配置；相机给的是图，检测模型要自己跑。这与后文技能层"selfProvided 自建视觉"的边界是一致的。

4.2 动作状态机：机器人不能"想切就切"

人形机器人不同行为之间是有拓扑约束的：不能从躺姿直接进入行走，必须先起身；自定义上肢控制只在特定状态下开放。Q1 把这套规则做成了显式状态机，McAction.msg 里给每个状态一个编号：Q1 系列主要用 1001–1019 段（如 1002 走跑、1005 全身控制、1014 上肢自定义），T1 系列用 100–300 段（101 四足站立、201 双足站立、202 双足行走、300 全身控制等）。

值得注意的是 SDK 示例里的一个设计：官方没有让开发者自己处理状态切换顺序，而是在 examples/python/common/mc_action_switcher.py 里放了一张状态有向图（_ACTION_RULES），客户端用 BFS 自动规划从当前状态到目标状态的路径，并在每一步之间等待至少 0.5 秒、轮询确认状态到达。本文配套仓库把这张图提取成了不依赖 ROS2 的离线脚本，运行即可看到规划结果：

$ python3 local/action_graph.py STORE_DEFAULT BIPED_WALK_RUN
当前状态：STORE_DEFAULT
目标状态：BIPED_WALK_RUN
需要 2 次 SetMcAction 调用（每次间隔 ≥ 0.5s，且需轮询 GetMcAction 确认状态到达）：
  第1步：SetMcAction(BIPED_GROUND_POSE)
  第2步：SetMcAction(STAND_UP)，执行后自动进入 BIPED_WALK_RUN

轮询对应的状态码同样是明确约定的：GetMcAction 返回的 info.status.value，100 表示 RUNNING、200 表示 TRANSITION、1 成功、2 失败。下发新动作前必须等状态从 200 落到 100；官方示例把两次 SetMcAction 的最小间隔钉在 0.5 秒，官方技能文档则将间隔小于 500ms 的返回记为错误码 -10001。这些是硬约束，不是建议。

4.3 控制权：输入源仲裁

机器人可能同时被语音 Agent、App、SDK 节点三方控制，必须有仲裁机制。Q1 的做法是输入源注册：任何节点下发运动指令前，先调用 SetMcInputSource 注册（action 1001=ADD、1003=DELETE），上报名字、优先级和超时时间，且速度消息里的 source 字段必须与注册名一致。官方速度示例注册的优先级是 80、超时 1000ms。

图 3：控制权获取与释放时序。超时脱锁是安全设计：节点崩溃或网线断开时，机器人不会继续执行最后一条速度指令。

五、三级运动控制：从"播一个动作"到"写每个关节"

Q1 对运动能力的开放按抽象程度分成三级，开发者按需选取，越往下越自由、也越危险。

第一级：预设动作。 切到全身控制状态（Q1 为 1005）后，调 SetMcPresetMotion 播放官方内置动作，McPresetMotion.msg 里 Q1 系列编号 3001–3048，包括招手、握手、碰拳、挥手、比心、拥抱、跳舞等。一行服务调用即可，轨迹由官方保证安全。

第二级：速度控制。 进入走跑状态后，向 /aima/mc/locomotion/velocity 持续发布 McLocomotionVelocity（前进、侧移、转向、弯腰速度）。官方示例以 50Hz 定时器发布，速度设了死区：要么为 0，要么绝对值不低于 0.2m/s，中间区间直接拒绝——这是为了避免传感器噪声被放大成抖动。

第三级：关节级控制。 进入 BIPED_CUSTOM_UPPER（1014）后，向 /aima/mc/custom/joint/command 以 100Hz 发布上肢 10 个关节（腰 2 + 双臂各 4）的目标位置，每个关节带 stiffness（刚度）和 damping（阻尼），官方默认值分别为 20.0 和 3.0。若要控制腿部，话题是 /aima/hal/joint/command，官方示例 joint_control.py 明确要求先关闭运控模块、把机器人平躺或悬挂，并引入 Ruckig 轨迹库在 500Hz 周期下做带速度、加速度、加加速度约束的在线轨迹规划（默认 max_velocity 3.0rad/s、max_acceleration 10、max_jerk 25），避免阶跃指令打坏关节。

上肢示例的核心循环只有几十行，却能看出这套接口的设计取向：

# onboard/04_upper_body.py（节选，100Hz）
PUBLISH_HZ = 100.0
# 10 个上肢关节，每个关节给定刚度/阻尼
for name in UPPER_JOINTS:
    j = JointCommand()
    j.name = name
    j.stiffness = 20.0
    j.damping = 3.0
    self.msg.joints.append(j)

# 右肩俯仰角按正弦轨迹摆动，持续整周期发布
while time.monotonic() - start < duration_s:
    self._by_name["right_shoulder_pitch_joint"].position = \
        -0.25 + 0.15 * math.sin(2 * math.pi * 0.8 * t)
    self.pub.publish(self.msg)
    time.sleep(1.0 / PUBLISH_HZ)

注意刚度/阻尼是按指令下发的，这意味着开发者可以直接调节关节的柔顺特性——这是准直驱关节的力控优势在接口层的体现。HAL 层和 MC 层的区别也在此：HAL 关节话题绕过运动模型，所以要求关闭运控；MC 上肢话题则运行在运动模型之下，机器人可以边站边动胳膊。

除了直接写关节角，Q1 还提供了示教录制这条获取动作的路径：SetMcAction(302) 进入 BIPED_RECORD_UPPER 上肢录制模式，通过 McMotionRecord 服务开始/停止录制，轨迹保存为 CSV；官方技能生态里的示教工具就是 record、play、extract 三个子命令——录制动作、回放验证、导出可直接粘进配置的关节角片段。对不会手算逆运动学的开发者来说，"把机器人手臂摆到想要的位置再录下来"比写角度更现实，这也解释了为什么产品页把"拖拽示例教学"列为面向普通用户的功能。

三级控制加示教，构成了一套完整的能力光谱：要语义化调用就用预设动作，要移动就用速度话题，要精确动作就发关节指令或直接示教，抽象层级和风险等级同步递减。

六、技能层：RPK 包规范与运行时

单个 ROS2 节点解决的是"我怎么控制机器人"，技能（Skill）解决的是"用户怎么用起来"。官方在 AtomGit 上的示例技能仓库（primebot 组织，含天气、萝卜蹲、视频通话、搬衣服等）展示了 RPK（Robot Package）的包结构。

最简单的技能包只需要两个东西：一个 cfg/pkg.yaml 清单和一个入口脚本。

# cfg/pkg.yaml（以官方 weather_forecast 为例）
user_id: "robot_local"
version: "1.0.0"
sdk_version: "v1.0.0"
package_name: "weather_forecast"
author: "primeagent"
description: "查询今天、明天或后天的城市天气预报、气温、降雨概率……"

技能运行时的调用方式非常轻：加载清单后，把机器人对象注入到入口的模块级变量 robot（具备 play_tts 等方法），把用户的语音指令放进环境变量 ROBOT_SKILL_QUERY，然后执行入口。官方天气技能的入口只有几行：

# main.py（官方 weather_forecast 技能入口，共 7 行）
import os
from weather_forecast.weather import speak_forecast
​
speak_forecast(robot, os.environ.get("ROBOT_SKILL_QUERY", ""))

复杂技能则用 manifest.json 扩展出一份相当严格的声明式规范。以官方搬衣服技能（carry-clothes，目标机型 T1）为例，清单里除了运行时（Python≥3.10、入口 main:run、启动前 source ROS2 和 SDK 环境），还有三类字段值得细看：

• capabilities：逐条声明该技能要用的每个 ROS2 接口（话题/服务）、级别（readonly/normal）和参数（如速度上限 0.35m/s、关节指令 100Hz）。打包器会校验代码里是否真的实现了这些接口，漏了直接报错；

• selfProvided：明确写出 SDK 不提供、需要开发者自建的能力。该技能里是视觉目标检测和视觉伺服——SDK 只给相机原始图和速度话题，没有导航、没有 SLAM；

• safety：最大速度、电量底线（20%，搬运中 25%）、关节限位、动作间隔 500ms、异常中止时平滑回正、必须有用户确认等。

图 4：RPK 技能的开发—声明—分发闭环。技能的权限边界在安装前就由清单确定，而不是运行时随意申请。

清单里还有两类字段，解释了技能如何被"叫起来"以及如何验收。triggers 声明意图名、若干句唤醒话术（如"把衣服拿到洗衣机旁"）和槽位（object、destination，带默认值）；语音 Agent 命中意图后，才会把这句话通过 ROBOT_SKILL_QUERY 交给技能。stages 则把任务拆成带超时的有序阶段，每个阶段标注所用接口——搬衣服技能被拆成 10 个阶段，从播报、切换直立、走到用户面前、抬臂、等待接衣、合臂、找目标、前往、下放到完成播报。

与阶段清单配套的是仿真优先的工程约定。搬衣服技能的入口支持三种后端：--dry-run 只打印 10 步计划不下发任何动作、--sim 用 MockPrimeBot 和模拟检测器跑完全流程、不带参数才是真机。真机执行前必须先 dry-run 向用户复述计划并确认。这不是摆设——Mock 后端与真机后端实现同一套接口，状态机、时序、位姿插值都在本地验证过，上真机时替换的只是通信实现。对机器人开发而言，这一步能挡掉绝大多数低级错误。

本文配套仓库的 local/rpk_skill_demo/ 实现了一个可在普通电脑上直接运行的最小技能包，并用 runtime_mock.py 模拟运行时注入：

$ python3 runtime_mock.py --offline "后天北京会不会下雨"
[运行时] 收到用户话术：后天北京会不会下雨
[运行时] 已注入 robot 对象，设置 ROBOT_SKILL_QUERY，执行技能入口……
[TTS 播报] 北京后天雷雨，16到22度，最高降雨概率90%。

这套机制的意义在于：技能逻辑与机器人通信解耦，业务代码可以不依赖 ROS2 在本地开发、测试，真机上只是 robot 对象的实现被换成真实服务。

七、仿真、URDF 与开放数据

开发闭环的另一端是"没有机器人也能做事"。

先看清桌面端 PrimeConsole 承担的角色。它是一个跨平台（Windows/macOS/Linux）的工作台，提供 macOS、Windows、Linux 三端安装包，连入 10.1.1.0/24 网段后可以查看机器人视频画面和运行日志、下发基础运动指令、管理技能的仿真与部署。它本质上是一个"标准化的 DDS 节点集合 + 图形界面"——社区由 CSDN 与 AtomGit 联合建设，PrimeConsole 负责把发现节点、看话题、跑仿真这些原本要敲命令行的动作图形化。开发者不装它也能用 rqt 等标准 ROS2 工具完成同样的事，装上则省掉配置成本。

官方提供的 Q1 URDF v1.0.0（q1_v3）是一个完整的机器人描述包：22 个关节、24 个连杆的 STL 网格，标准 ROS launch（RViz 可视化、Gazebo 仿真），以及三套 MuJoCo XML——基础版、全关节范围版 q1_v3_full_range.xml、带执行器的运控版 q1_v3_mc.xml。从 XML 里可以直接读到关节的物理参数，例如髋部俯仰关节范围 −2.95~1.47rad、电机力矩 ±36N·m，踝关节 ±22N·m，这些和 QDD 关节的硬件指标可以互相对上。

编译侧，官方提供三套 Docker 工具链镜像：ARM 原生编译（Orin/RK 平台）、x86 交叉编译 ARM、x86 原生编译。SDK 里还直接附带了 OpenCV 4.13.0 和 Ruckig 轨迹库的源码，版本钉死，避免"我本地能跑、板上编译不过"的环境漂移。

数据层面，启元在 HuggingFace 开放了家庭双臂操作数据集（challenge-2026/challenge_data，CC-BY-SA-4.0）。截至 2026 年 9 月，包含 500 小时以上真机遥操作数据和约 200 小时 UMI 数据，官方宣传口径为 1500+ 小时演示数据。数据采用 LeRobot V2.1 格式（钉版 lerobot==0.3.3、torch==2.7.0），三路 1280×720 RGB、30FPS；每条记录的状态与动作是 89 维（22 个关节的位置/速度/力矩 + 双臂末端位姿 + 轮子状态），但实际推理只要求输出 25 维：22 个关节位置加 3 个轮速，控制频率 30Hz（来源：HuggingFace 数据集卡及 arXiv:2609.03591）。对研究者来说，这组约定等价于一份明确的"模型如何变成动作"的接口契约：实现 load_model 和 predict 两个函数，输出形状为 (N, 25) 的动作块即可接入官方推理框架。

八、这套架构的开放边界

通读 SDK 和示例后，有几个判断可以客观给出。

第一，开放的层次是扎实的，且刻意使用标准。 ROS2 + FastDDS、标准 Topic/Service、URDF、MuJoCo、Docker、LeRobot，没有一个环节是私有封闭格式。接口给到了关节力矩、刚度、电池状态字这一级，属于面向开发者的真正开放，而不是只给几个动作按钮。

第二，能力边界写得比能力本身更值得肯定。 官方搬衣服技能在文档里明确列出三条"不要假设存在"：没有导航/SLAM/语义地图，没有夹爪（T1 上肢只有关节，搬运靠双臂合拢），没有 ASR（只有音频采集流，确认动作要靠头部触摸事件）。这些限制被直接写进 SKILL.md 和 manifest 的 selfProvided，而不是藏在 FAQ 里。对开发者而言，事先知道不能做什么，比事后发现做不到更重要。

第三，安全是内建在协议里的。 输入源优先级与超时脱锁、状态机合法路径、动作间隔 500ms、关节限位与刚度上限、关机/急停行为、开发者模式下服务白名单，这些组合起来让"一段失控的代码"很难造成严重后果。

现阶段的边界同样明显：能直接调用的能力集中在运动控制、交互和感知数据读取，导航与复杂操作需要自建，技能生态刚上线、数量还少，部分产品功能通过 OTA 陆续开放（官方页面已用星号标注）。对于想在它上面做完整家庭任务的开发者，视觉和规划的工作量仍然不小——但这正是它同时开放 1500 小时数据集和推理接口的原因，硬件、接口、数据三条线是一起给的。

从一台 88cm 的机器人到一个 RPK 技能包，中间隔着的六层架构，本质上都在回答同一个问题：如何让一个人写的代码安全地变成一个物理动作。启元给出的答案是标准通信、显式状态机、仲裁式控制权和声明式技能清单。这套答案是否足够好，最终要由社区里跑起来的技能数量来检验。

---

参考资料

1. 启元开发者社区：启元机器人开发者社区 · 一站式具身智能研发平台

2. Q1 产品页（硬件参数）：启元Q1 探索版 - 启元机器人 ；T1 产品页：T1 星露紫 - 启元机器人

3. PrimeBot Q1 SDK v1.0.0.0（含《快速入门与集成指南》《接口说明》、aimdk_msgs、示例代码、OpenCV 与 Ruckig 源码）

4. 官方 AtomGit 组织：PRIMEBOT - 开源代码托管,代码协作 - AtomGit

5. PrimeHub 技能市场：机器人 PrimeHub

6. 家庭双臂操作数据集：https://huggingface.co/datasets/challenge-2026/challenge_data ；论文 arXiv:2609.03591

7. IT之家：《启元机器人开发者社区正式上线》