{
  "site": "https://robotbaseline.com",
  "brand": {
    "cn": "基线",
    "en": "Robot Baseline"
  },
  "tagline": {
    "cn": "机器人 DIY 的图纸、软件与硬件基线",
    "en": "Blueprints, software and hardware baselines for robot builders"
  },
  "generated": "2026-09-28",
  "grading": {
    "A": "Official document, standard, or first-party source",
    "B": "Authoritative secondary, traced to origin",
    "C": "Our own estimate, labelled as such",
    "D": "First-hand builder account (forum, issue, build log)"
  },
  "columns": {
    "blueprints": {
      "cn": "图纸",
      "en": "Blueprints"
    },
    "software": {
      "cn": "软件",
      "en": "Software"
    },
    "hardware": {
      "cn": "硬件",
      "en": "Hardware"
    },
    "claims": {
      "cn": "说法核对",
      "en": "Claim Check"
    }
  },
  "objectTypes": {
    "robot": {
      "cn": "整机与套件",
      "en": "Robots & Kits"
    },
    "part": {
      "cn": "零件与部件",
      "en": "Parts & Components"
    },
    "lib": {
      "cn": "库与框架",
      "en": "Libraries & Frameworks"
    },
    "sim": {
      "cn": "仿真与工具链",
      "en": "Simulation & Toolchain"
    },
    "data": {
      "cn": "数据集与模型",
      "en": "Datasets & Models"
    },
    "cost": {
      "cn": "成本与采购",
      "en": "Cost & Sourcing"
    }
  },
  "objects": [
    {
      "slug": "lerobot-humanoid",
      "type": "robot",
      "name": {
        "cn": "LeRobot Humanoid",
        "en": "LeRobot Humanoid"
      },
      "description": {
        "cn": "Hugging Face 在 2026 年 5 月放出的双足人形，整机成本约 2,500 美元，75 个可打印件。它的特别之处不是便宜，是硬件、运行时、参数辨识、训练环境、策略库一次性全给了——第一台「不用重新设计就能开始训」的双足人形。",
        "en": "Hugging Face's bipedal humanoid, released in May 2026 at roughly USD 2,500 in parts with 75 printable components. What sets it apart is not the price but the completeness: hardware, runtime, identification pipeline, training environments and a policy zoo in one release — the first bipedal humanoid you can start training on without redesigning it."
      },
      "url": {
        "zh": "https://robotbaseline.com/objects/robot/lerobot-humanoid/",
        "en": "https://robotbaseline.com/en/objects/robot/lerobot-humanoid/"
      }
    },
    {
      "slug": "so-101",
      "type": "robot",
      "name": {
        "cn": "SO-101 机械臂",
        "en": "SO-101 arm"
      },
      "description": {
        "cn": "桌面级 5+1 自由度机械臂，SO-100 的改进版，整套零件约 110 美元起。开放硬件加公开物料清单，是这个价位段里「开源」含义最实在的一个：零件能自己买、结构能自己改。代价是它的能力边界同样写得很实在。",
        "en": "A desktop 5+1 DOF arm, the successor to SO-100, with parts from about USD 110. Open hardware with a published bill of materials — the most literal use of 'open source' at this price point: you can source the parts and change the structure yourself, and its limits are stated just as plainly."
      },
      "url": {
        "zh": "https://robotbaseline.com/objects/robot/so-101/",
        "en": "https://robotbaseline.com/en/objects/robot/so-101/"
      }
    },
    {
      "slug": "thor-arm",
      "type": "robot",
      "name": {
        "cn": "Thor 六轴机械臂",
        "en": "Thor 6-axis arm"
      },
      "description": {
        "cn": "用步进电机加 3D 打印齿轮与同步带做的六轴臂，全部结构件在 FreeCAD 里设计，零件约 350 欧元。关节是工业化构型；固件走 GRBL、接受 G-code，所以它天然接得上现成的 CNC 与 ROS 2 工具链。",
        "en": "A 6-axis arm built from stepper motors driving 3D-printed gears and GT2 belts, with every structural part designed in FreeCAD, in parts from around EUR 350. The joint layout mirrors industrial manipulators, and the GRBL firmware accepts standard G-code — so it plugs into existing CNC and ROS 2 tooling."
      },
      "url": {
        "zh": "https://robotbaseline.com/objects/robot/thor-arm/",
        "en": "https://robotbaseline.com/en/objects/robot/thor-arm/"
      }
    },
    {
      "slug": "unitree-g1",
      "type": "robot",
      "name": {
        "cn": "宇树 G1",
        "en": "Unitree G1"
      },
      "description": {
        "cn": "小型人形机器人，官方起售价在 9.9 万元量级，是实验室里最常见的那台。它是「开源」这个词被用坏得最厉害的一台机器——SDK 与部分文档开放，硬件、控制栈和运控策略都不是。它也是 DIY 圈最常被拿来当「闭源对照」的例子。",
        "en": "A small humanoid listed from around CNY 99,000 and the machine most often found in labs. It is where the word 'open source' gets stretched hardest: the SDK and parts of the documentation are open; the hardware, control stack and locomotion policies are not. It is also the example DIY circles cite when they want a closed-source benchmark."
      },
      "url": {
        "zh": "https://robotbaseline.com/objects/robot/unitree-g1/",
        "en": "https://robotbaseline.com/en/objects/robot/unitree-g1/"
      }
    },
    {
      "slug": "dynamixel",
      "type": "part",
      "name": {
        "cn": "Dynamixel 与 ROBOTIS 生态",
        "en": "Dynamixel and the ROBOTIS ecosystem"
      },
      "description": {
        "cn": "最经典的机器人舵机家族，硬件是闭源的、价格明显高于同类，但协议文档、SDK、仿真模型（URDF 加 MuJoCo 描述）长期免费公开。它说明了一件事：硬件闭源不等于生态封闭，可获取性和开源程度是两件事。",
        "en": "The classic robot servo family: closed hardware at a clear premium over comparable servos, but with protocol documentation, SDKs and simulation models (URDF and MuJoCo descriptions) published free for years. It makes one point plainly — closed hardware does not mean a closed ecosystem. Access and openness are two different axes."
      },
      "url": {
        "zh": "https://robotbaseline.com/objects/part/dynamixel/",
        "en": "https://robotbaseline.com/en/objects/part/dynamixel/"
      }
    },
    {
      "slug": "feetech-servo",
      "type": "part",
      "name": {
        "cn": "Feetech STS 系列舵机",
        "en": "Feetech STS series servos"
      },
      "description": {
        "cn": "SO-100 / SO-101 与 LeKiwi 用的就是这一族。它是目前「低于 20 美元一只、带总线通信与位置反馈」里最常被选中的方案，也是整个低预算机器人生态的事实基准——大量开源项目直接按它的尺寸和协议设计结构。",
        "en": "The family used by SO-100, SO-101 and LeKiwi. It is the most commonly chosen option under about USD 20 per unit that offers bus communication and position feedback, and it has become the de facto reference for the low-budget robot ecosystem — a large share of open projects design their structure around its dimensions and protocol."
      },
      "url": {
        "zh": "https://robotbaseline.com/objects/part/feetech-servo/",
        "en": "https://robotbaseline.com/en/objects/part/feetech-servo/"
      }
    },
    {
      "slug": "robstride-motor",
      "type": "part",
      "name": {
        "cn": "Robstride 关节电机",
        "en": "Robstride joint motors"
      },
      "description": {
        "cn": "国内厂商的一体化关节电机，把无刷电机、减速器与驱动器做进一个圆柱体内，走 CAN FD。LeRobot Humanoid 的行走部分用的就是它——这也是那台机器能压到 2,500 美元的关键：动力的钱花在电机上，不花在定制的关节模组上。",
        "en": "Integrated joint motors from a Chinese vendor that pack a brushless motor, gearbox and driver into one cylinder speaking CAN FD. LeRobot Humanoid uses them in its lower body, which is a large part of how that machine reached USD 2,500: the money goes into motors rather than custom joint modules."
      },
      "url": {
        "zh": "https://robotbaseline.com/objects/part/robstride-motor/",
        "en": "https://robotbaseline.com/en/objects/part/robstride-motor/"
      }
    },
    {
      "slug": "can-bus",
      "type": "part",
      "name": {
        "cn": "CAN 与 CAN FD 总线",
        "en": "CAN and CAN FD buses"
      },
      "description": {
        "cn": "一旦从舵机走到无刷关节电机，通信几乎必然落到 CAN 上。它是 DIY 机器人从「十来只舵机」跨到「十几个关节同步」时最先撞上的那道门槛：不是接线难，是终端电阻、共地、波特率与主控端 CAN 控制器这几件事同时要成立。",
        "en": "The moment you move from hobby servos to brushless joint motors, communication almost always lands on CAN. It is the first real threshold when a build grows from a dozen servos to a dozen synchronised joints: the wiring is not the hard part — termination, common ground, bitrate and whether your controller has a real CAN peripheral all have to hold at once."
      },
      "url": {
        "zh": "https://robotbaseline.com/objects/part/can-bus/",
        "en": "https://robotbaseline.com/en/objects/part/can-bus/"
      }
    },
    {
      "slug": "lerobot",
      "type": "lib",
      "name": {
        "cn": "LeRobot",
        "en": "LeRobot"
      },
      "description": {
        "cn": "Hugging Face 的机器人学习库，Apache 2.0。它把「采数据 → 训策略 → 真机部署」这条链路做成了可复制的脚本，而不是一份论文实现。对 DIY 的人，它是目前最省事的一条从零到能动的路径；代价是它假设你熟悉 Python 与 Linux。",
        "en": "Hugging Face's robot learning library under Apache 2.0. It turns the chain of collecting data, training a policy and deploying on real hardware into reproducible scripts rather than a paper implementation. For a builder it is currently the shortest path from nothing to a moving robot — at the cost of assuming you are comfortable with Python and Linux."
      },
      "url": {
        "zh": "https://robotbaseline.com/objects/lib/lerobot/",
        "en": "https://robotbaseline.com/en/objects/lib/lerobot/"
      }
    },
    {
      "slug": "ros2",
      "type": "lib",
      "name": {
        "cn": "ROS 2",
        "en": "ROS 2"
      },
      "description": {
        "cn": "机器人领域的通信与中间件事实标准，核心是 BSD 许可，商用没有版税。它管的不是策略，是消息、驱动、导航与多进程实时性。麻烦也在这里：DDS 配置、QoS、节点图，对一台桌面臂来说经常是背着一整套工厂级设施去做一件小事。",
        "en": "The de facto standard for robot communication and middleware, BSD-licensed at the core and royalty-free for commercial use. It does not handle policies; it handles messaging, drivers, navigation and multi-process real-time behaviour. That is also where the trouble is: DDS configuration, QoS and node graphs mean a desktop arm often carries factory-grade infrastructure to do a small job."
      },
      "url": {
        "zh": "https://robotbaseline.com/objects/lib/ros2/",
        "en": "https://robotbaseline.com/en/objects/lib/ros2/"
      }
    },
    {
      "slug": "mujoco",
      "type": "sim",
      "name": {
        "cn": "MuJoCo",
        "en": "MuJoCo"
      },
      "description": {
        "cn": "Google DeepMind 维护的物理引擎，Apache 2.0，CPU 上就能跑，接触丰富的操作任务里是研究标配。它的 JAX 版本 MJX 把物理编译到 GPU 上，可以做大规模并行训练。和 Isaac 的关系不是二选一：快迭代用 MuJoCo，要像素与迁移上 Isaac。",
        "en": "A physics engine maintained by Google DeepMind under Apache 2.0 that runs on CPU and is a research default for contact-rich manipulation. Its JAX port, MJX, compiles the physics onto GPU for large-scale parallel training. It is not a either-or with Isaac: MuJoCo for fast iteration, Isaac when you need pixels and sim-to-real transfer."
      },
      "url": {
        "zh": "https://robotbaseline.com/objects/sim/mujoco/",
        "en": "https://robotbaseline.com/en/objects/sim/mujoco/"
      }
    },
    {
      "slug": "isaac-sim",
      "type": "sim",
      "name": {
        "cn": "Isaac Sim 与 Isaac Lab",
        "en": "Isaac Sim and Isaac Lab"
      },
      "description": {
        "cn": "英伟达的仿真与强化学习平台，全栈免费下载、部署不收版税，「免费」是它流传最广的标签。真正决定你能不能跑起来的不是许可，而是显卡显存、驱动版本、Python 环境与依赖链的组合。",
        "en": "NVIDIA's simulation and reinforcement learning stack: free to download across the board, with no per-robot royalty at deployment — 'free' is its most widely repeated label. What actually decides whether you get it running is not the licence but the combination of GPU memory, driver version, Python environment and dependency chain."
      },
      "url": {
        "zh": "https://robotbaseline.com/objects/sim/isaac-sim/",
        "en": "https://robotbaseline.com/en/objects/sim/isaac-sim/"
      }
    },
    {
      "slug": "libero",
      "type": "data",
      "name": {
        "cn": "LIBERO 基准",
        "en": "LIBERO benchmark"
      },
      "description": {
        "cn": "视觉-语言-动作（VLA）领域最常用的仿真评测基准之一。分数曲线很漂亮，也因此成为「分数到底在测什么」争议最集中的地方——它同时在做两件事：衡量能力，和被高分刷榜。",
        "en": "One of the most-used simulation benchmarks for vision-language-action models. Its score curves look great, which is exactly why it is where the argument about 'what the score actually measures' concentrates: it is doing two jobs at once — measuring capability and being gamed."
      },
      "url": {
        "zh": "https://robotbaseline.com/objects/data/libero/",
        "en": "https://robotbaseline.com/en/objects/data/libero/"
      }
    },
    {
      "slug": "openvla",
      "type": "data",
      "name": {
        "cn": "OpenVLA",
        "en": "OpenVLA"
      },
      "description": {
        "cn": "最早被大范围复现的开源 VLA 模型之一，7B 参数、MIT 许可，量化后能在消费级显卡上跑。论文报告的成功率与不同人真机复现出来的数字之间的落差，是这个领域最常被私下讨论、最少被公开记录的一件事。",
        "en": "One of the first open VLA models to be widely reproduced: 7B parameters, MIT licensed, and runnable on consumer GPUs once quantised. The distance between reported success rates and what different people get on real hardware is the most privately discussed and least publicly recorded fact in the field."
      },
      "url": {
        "zh": "https://robotbaseline.com/objects/data/openvla/",
        "en": "https://robotbaseline.com/en/objects/data/openvla/"
      }
    }
  ],
  "entries": [
    {
      "id": "lerobot-humanoid",
      "type": "blueprints",
      "lang": "zh",
      "column": "blueprints",
      "url": "https://robotbaseline.com/blueprints/lerobot-humanoid/",
      "title": "2,500 美元的双足人形：LeRobot Humanoid 给了什么、没给什么",
      "lede": "这是第一个价位上「不用重新设计结构就能开始训策略」的双足人形。它的价值不在便宜，在于把硬件、运行时、参数辨识、训练环境和策略库一次性给全——而它没给的那几样，恰好决定你要额外付出多少。",
      "fields": {
        "files": "75 个 STL 覆盖躯干、髋、大腿、膝、小腿、踝、脚各子装配，BOM 直接给到电机型号与五金件货号，不用自己做选型。更值钱的是同一个发布里还有运行时、参数辨识脚本、训练环境（MJLab）和策略库——这是「闭环」两个字的具体含义。没给的是可编辑的结构源：只有 STL，没有 STEP。想把腿加长两厘米，得自己把网格重建成实体。",
        "bom": "电机约 1,880 美元占整机七成以上，打印件耗材约 56 美元，其余是总线适配器、五金与紧固件，合计约 2,500 美元。这个数字不含打印机、不含工具、也不含你打废的那几批件。按 3.5 kg 耗材估算，第一轮试错把材料多买一倍是常态，不是浪费。",
        "print": "最小打印尺寸 220×220×250 mm，常规桌面机就能干——但承力件（大腿、膝）要给到 80% 填充、5 圈壁厚，外壳件 20% 填充即可。这个差别直接决定它站不站得住，别为了赶时间把参数统一调低。整套打完按天计，不是按小时。",
        "hardest": "不在打印，在让两条腿真的站起来。仿真参数与真机的偏差要用官方的参数辨识脚本去补，这一步没有捷径。其次是总线：Robstride 走 CAN FD，不是舵机那种信号线，接线对了不等于通——终端电阻和主控的 CAN 控制器得同时对。",
        "checked": "我们核过三件事：①发布范围（硬件 / 运行时 / 辨识 / 训练 / 策略是否在同一许可下）②BOM 的电机型号数量与描述的 12 个主动自由度是否对得上 ③打印尺寸下限与承力件的填充要求。没核过的是第一手复刻——我们没有打印过这台机器，所以「装完到底能不能走」这条没有实测结论，按本站的分级它只到 B 档而不是 D 档。"
      },
      "facts": [
        {
          "k": "结构文件",
          "v": "75 个 STL，PLA+ / PETG 可打印"
        },
        {
          "k": "可编辑结构源",
          "v": "未公开 STEP，想改结构要自己逆向"
        },
        {
          "k": "打印条件",
          "v": "最小 220×220×250 mm；承力件 80% 填充、5 圈壁厚"
        },
        {
          "k": "BOM",
          "v": "约 2,500 美元，其中电机约 1,880 占七成"
        },
        {
          "k": "许可",
          "v": "Apache 2.0"
        },
        {
          "k": "仓库",
          "v": "github.com/huggingface/lerobot",
          "url": "https://github.com/huggingface/lerobot"
        }
      ],
      "verdict": "目前唯一一台「买齐零件就能进入机器人学习正题」的双足人形。适合已经有 3D 打印机、目标是训策略而不是搞结构设计的人。如果你是冲着「亲手造一台人形」来的，75 个件和 CAN 总线会给你足够多的活干；如果你只想快点看到腿动起来，先用桌面臂把整条链路跑通再上来。",
      "grade": "B",
      "objects": [
        "lerobot-humanoid",
        "robstride-motor",
        "can-bus"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "官方发布与硬件仓库说明（STL 数量、BOM、打印指引、许可）"
        },
        {
          "text": "官方训练环境与策略库文档（MJLab、参数辨识流程）"
        }
      ]
    },
    {
      "id": "so-101",
      "type": "blueprints",
      "lang": "zh",
      "column": "blueprints",
      "url": "https://robotbaseline.com/blueprints/so-101/",
      "title": "110 美元的臂：SO-101 为什么是 DIY 最该先做的那一台",
      "lede": "在低价位里，它是「开源」两个字含义最实在的一个——零件能自己买、结构能自己改、坏了能自己换。也是整条机器人学习链路目前最短的一条入口。",
      "fields": {
        "files": "结构件是打印件，其余是标准五金与舵机，属于「照单买齐就能开工」的那一类。它最值钱的地方不在文件本身，在于它已经被大量项目当成基准：LeRobot 把它的尺寸、舵机型号和标定流程写进了官方文档，遇到问题几乎必然已经有人踩过。",
        "bom": "整套约 110 美元起，舵机占大头。这个价位的真正意义是可以买两套——一套跑、一套拆。低价臂的价值有一半在这里：它让「先做坏一台」这件事变得负担得起，而做坏一台恰恰是最快的学习方式。",
        "print": "打印量在一公斤量级，桌面机能一次打完主要件，不需要工业设备。公差是这类打印臂最容易出问题的地方：同一份 STL 在不同机器上打出来，装配松紧能差到需要重新配孔。先打两个小件验一下尺寸，再整批铺开。",
        "hardest": "不在装配，在把标定和遥操作做稳。臂本身很快能装好，之后是相机标定、舵机零位、数据采集的一致性——这些决定了你后面训出来的策略能不能用。很多人卡在这一步，并且误以为是臂的问题。",
        "checked": "我们核过：①它在 LeRobot 官方文档里被当作入门硬件的定位 ②舵机型号与总线的对应关系 ③价格量级。没核过：具体到某一批打印件的公差表现，以及当前版本发布了哪些格式的源文件——这两项随版本变化，取之前请以仓库的实时内容为准。"
      },
      "facts": [
        {
          "k": "形态",
          "v": "桌面级 5 自由度 + 夹爪"
        },
        {
          "k": "结构",
          "v": "3D 打印件 + 标准五金，常规桌面机可打"
        },
        {
          "k": "BOM",
          "v": "约 110 美元起（SO-100 价位；SO-101 略高）"
        },
        {
          "k": "舵机",
          "v": "Feetech STS 系列，总线通信、带位置反馈"
        },
        {
          "k": "配套软件",
          "v": "LeRobot（采数据 / 训策略 / 部署一条链路）"
        },
        {
          "k": "仓库",
          "v": "github.com/huggingface/lerobot",
          "url": "https://github.com/huggingface/lerobot"
        }
      ],
      "verdict": "如果只能做一台，做这台。110 美元的入场价让「试错」第一次变成了可以承受的动作，而它配套的软件链路恰好是目前最完整的一条。它的上限很低——别指望它做精细作业——但作为整条链路的入口，这个价位上暂时没有对手。",
      "grade": "B",
      "objects": [
        "so-101",
        "feetech-servo",
        "lerobot"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "LeRobot 官方文档中的入门硬件说明与装配指引"
        },
        {
          "text": "开源硬件项目发布页（结构件、BOM、舵机型号）"
        }
      ]
    },
    {
      "id": "thor-arm",
      "type": "blueprints",
      "lang": "zh",
      "column": "blueprints",
      "url": "https://robotbaseline.com/blueprints/thor-arm/",
      "title": "Thor 六轴臂：350 欧元买一套工业构型，代价在打印工时上",
      "lede": "用步进电机加打印齿轮和同步带搭出的六轴臂，关节构型照抄工业机械臂。它的取舍很典型：省下来的钱，全部换成你的打印机时间。",
      "fields": {
        "files": "49 个 STL 覆盖六个关节、夹爪、底座与轴承固定件，结构全部用 FreeCAD 设计。控制板是架在 Arduino Mega 上的自制扩展板，把六个步进驱动、限位开关和风扇接口做在一起；固件基于 GRBL，接受的命令是标准 G-code——这一条比零件清单重要，它意味着现成的 CNC 与 3D 打印生态里的东西可以复用。",
        "bom": "零件约 350 欧元。真正占大头的是时间而不是钱：60 到 80 小时的打印是基准，失败重打按比例往上加。买一台成品六轴臂的钱和这台的总花费不在一个量级，但这台的全部结构文件在你手上，坏了任何一件都能自己再打一个。",
        "print": "60–80 小时是理想值。齿轮与同步带传动对打印质量的要求高于普通外壳件：层间结合强度和齿形精度直接决定关节虚位，这两项和喷嘴、层高、耗材品牌都相关。如果打印参数不熟，先拿废料打两对齿轮测一次回差，再决定整批参数。",
        "hardest": "不在装配，在让六个关节的虚位小到运动学能收敛。打印齿轮加同步带这套传动本身有回差，同一个目标位置从两个方向过去会停在不同的地方。这是所有打印臂的共同难题，解决手段是加紧、加补偿或改用更好的传动——三条路都要花时间。",
        "checked": "我们核过：①仓库里的 STL 清单与关节单元的对应关系 ②固件的命令协议（是否为标准 G-code）③ROS 2 / MoveIt2 集成的存在形态。没核过：我们自己没有装配过这台臂，所以 750 g 负载与重复定位精度这两项只有官方数据和社区记录，没有本站实测。"
      },
      "facts": [
        {
          "k": "结构件",
          "v": "49 个 STL，全部在 FreeCAD 里设计"
        },
        {
          "k": "打印工时",
          "v": "0.4 mm 喷嘴、0.2 mm 层高下估 60–80 小时"
        },
        {
          "k": "规格",
          "v": "高 625 mm，负载 750 g，6 轴 + 夹爪"
        },
        {
          "k": "零件成本",
          "v": "约 350 欧元（不含打印机与工具）"
        },
        {
          "k": "传动",
          "v": "步进电机 + 打印齿轮 + GT2 同步带"
        },
        {
          "k": "固件与软件",
          "v": "GRBL（吃 G-code）；上位机 Asgard；ROS 2 / MoveIt2 集成"
        },
        {
          "k": "许可",
          "v": "CC BY-SA 4.0"
        }
      ],
      "verdict": "想学运动学、想有一台能自己修能自己改的多轴臂，这台的选择很直接：承认它的核心成本是打印机时间。它不适合想一周内看到东西动起来的人；它适合愿意花一个季度做一台、并且以后还想继续改的人。",
      "grade": "B",
      "objects": [
        "thor-arm"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "项目仓库（STL 清单、硬件说明、许可条款）"
        },
        {
          "text": "官方文档与配套 ROS 2 / MoveIt2 仓库说明"
        }
      ]
    },
    {
      "id": "lerobot",
      "type": "software",
      "lang": "zh",
      "column": "software",
      "url": "https://robotbaseline.com/software/lerobot/",
      "title": "LeRobot：把「采数据到真机动起来」做成脚本的那套库",
      "lede": "Apache 2.0，Python，是目前 DIY 侧从零到能动的路上最短的一条。它的门槛不在概念，在你愿不愿意接受 Linux 与命令行。",
      "fields": {
        "solves": "它解决的是链路问题而不是算法问题：遥操作采数据、数据格式统一、训练脚本、真机推理，四段分别有人做，但把它们接起来才是真正花时间的地方。LeRobot 把这四段放进同一个仓库、同一套命令风格，并且用低价硬件验证过。对 DIY 的人，这等于别人替你把「环境配置地狱」走了一遍。",
        "alternatives": "它不是 ROS 2 的替代品——两者管的层不同：LeRobot 管策略，ROS 2 管消息、驱动与实时性，成熟方案经常是「LeRobot 训、ROS 2 部署」。仿真优先的选择是 Isaac Lab，但那个偏大规模并行训练与合成数据，不带真机采数据工具。厂商 SDK（如各家机器人官方 SDK）能让你控制那台机器，但通常不给跨硬件的训练链路。",
        "requires": "付出是三件不在它控制范围内的事：一个 Linux 环境（真机侧的设备权限、串口与相机都在这上面绕）、一台能跑的 GPU（训练需要，推理可以省）、以及接受校准这件事。它不假装自己是开箱即用的设备，文档也直说需要动手基础。",
        "pitfalls": "三个最常见的坑：①以为它是即插即用——校准与相机标定是必经步骤，跳过它后面所有训练数据都不可用；②硬件本身会飘，低价舵机与打印件的公差会随温度和使用变化，重采数据前要重新校准；③在系统 Python 里装——多版本依赖冲突是这类项目最常见的失败起点，用独立环境。",
        "checked": "我们核过：①许可与商用条件（Apache 2.0，无版税）②它明确支持的硬件清单 ③官方文档里对「需要动手基础」这一点的直接表述。没核过：本站没有从零跑过完整训练流程，所以「新手多久能训出第一个可用策略」这类时间估计没有第一手数据。"
      },
      "facts": [
        {
          "k": "许可",
          "v": "Apache 2.0（商用与再发布都不收费）"
        },
        {
          "k": "语言",
          "v": "Python；真机侧需要 Linux 环境与设备权限"
        },
        {
          "k": "配套硬件",
          "v": "SO-100 / SO-101 / LeKiwi / Reachy Mini 等低价硬件"
        },
        {
          "k": "内置策略",
          "v": "ACT、Diffusion Policy 等模仿学习方法的可用实现"
        },
        {
          "k": "数据侧",
          "v": "接 Hugging Face 数据集 Hub，并提供公开数据集的转换工具"
        },
        {
          "k": "仓库",
          "v": "github.com/huggingface/lerobot",
          "url": "https://github.com/huggingface/lerobot"
        }
      ],
      "verdict": "如果你的目标是让一台低价臂真的按你的指令做动作，这是当前最省事的一条路。如果你的目标是理解学习算法的内部原理，它太上层了，你会想直接读论文实现。两者的顺序建议是：先用它跑通，再回去看算法。",
      "grade": "A",
      "objects": [
        "lerobot",
        "so-101",
        "lerobot-humanoid"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "官方仓库与文档（许可、支持的硬件、安装要求、限制说明）"
        },
        {
          "text": "公开的技术评测与使用记录（关于 Linux/Python 前置要求与校准负担）"
        }
      ]
    },
    {
      "id": "ros2",
      "type": "software",
      "lang": "zh",
      "column": "software",
      "url": "https://robotbaseline.com/software/ros2/",
      "title": "ROS 2：什么时候它是必需品，什么时候它只是负担",
      "lede": "机器人圈的事实标准，BSD 核心许可、商用无版税。但它管的不是策略而是通信——一台桌面臂用一个系统级中间件，经常是拿工厂的设备做桌面的事。",
      "fields": {
        "solves": "它解决的是多子系统之间的通信与实时性：相机、机械臂、底盘、导航、规划各自是独立进程，要靠一套消息机制连起来，还要保证时间同步与优先级。当你的机器人只有一个臂加两个相机时，这些需求根本不存在，中间件的开销就全是纯负担。",
        "alternatives": "单臂做学习任务时，直接跑 LeRobot 会快得多，省掉整个概念栈。仿真优先看 Isaac Lab（自带训练框架）。厂商 SDK 足够用的情况也很多——如果你只控制一台机器、不做多设备协同，SDK 加一点脚本往往比引入中间件省事。ROS 2 真正的价值随系统复杂度上升，不是随技术水平上升。",
        "requires": "代价是一整套要理解的概念：DDS 配置、QoS 策略、节点图、生命周期管理。这些不是可以跳过的细节——通信不通时，问题几乎总在这几项上。加上它通常要求固定版本的 Linux 发行版，环境本身也是工作量。",
        "pitfalls": "①拿教程里的 ROS 1 内容照做：ROS 1 已停止支持，网上大量教程还没更新，照做会撞上一堆无法解释的错误；②QoS 不匹配导致订阅收不到消息——不报错，只是安静地没有数据，这是最耗时的一类问题；③为了「专业」而引入：单机小项目引入中间件，得到的复杂度远大于它解决的问题。",
        "checked": "我们核过：①许可条款与商用条件 ②发行版节奏与 ROS 1 停止支持的时间点 ③它与学习类库的分工关系（不是替代关系）。没核过：具体项目里的性能数字——DDS 配置对实时性的实际影响高度依赖硬件与配置，本站没有做过对照测试。"
      },
      "facts": [
        {
          "k": "许可",
          "v": "核心 BSD-3-Clause，商用无版税"
        },
        {
          "k": "当前 LTS",
          "v": "Kilted Kaiju（五年支持周期）"
        },
        {
          "k": "下一个 LTS",
          "v": "Lyrical Luth，2026 年 5 月发布"
        },
        {
          "k": "ROS 1",
          "v": "已于 2025 年 5 月停止支持；教程里若还写 ROS 1，那是过期内容"
        },
        {
          "k": "语言",
          "v": "Python 与 C++ 一等支持，另有 Rust 绑定"
        },
        {
          "k": "文档",
          "v": "docs.ros.org",
          "url": "https://docs.ros.org"
        }
      ],
      "verdict": "判断标准是复杂度而不是技术水平：多个子系统需要协同就用，单机单臂就不用。 一个简单的门槛是——如果你开始自己写进程间通信的胶水代码，那就是该上 ROS 2 的信号；如果你只是想让一只臂动起来，那是该离它远一点的信号。",
      "grade": "A",
      "objects": [
        "ros2"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "ROS 2 官方文档（发行版支持周期、许可、系统要求）"
        },
        {
          "text": "公开的技术对比资料（关于学习类库与中间件的分层关系）"
        }
      ]
    },
    {
      "id": "isaac-sim",
      "type": "software",
      "lang": "zh",
      "column": "software",
      "url": "https://robotbaseline.com/software/isaac-sim/",
      "title": "Isaac Sim 免费，但「装完能跑」是另一件事",
      "lede": "免费的是许可，不是门槛。第一个周末最容易花掉的地方不是学仿真，是让环境跑起来——而这部分恰恰是所有宣传语都不提的。",
      "fields": {
        "solves": "它解决的是大规模并行训练与像素级仿真这两件事：物理跑在 GPU 上，可以同时开几千个环境，配合照片级渲染生成合成数据。要做视觉策略、要做 sim-to-real 迁移，这是目前最完整的路径。而如果你的任务只关心动力学与接触，MuJoCo 在 CPU 上就能跑，迭代更快。",
        "alternatives": "MuJoCo 是主要对照：轻、快、CPU 可用，接触丰富的操作任务里是研究标配，JAX 版本能把物理编译到 GPU。PyBullet 更轻但没有同等生态。取决于任务：只关心运动学与接触 → MuJoCo；需要渲染像素与域随机化 → Isaac。很多实验室两边都用。",
        "requires": "许可成本是零，时间成本不是。真正决定能不能跑起来的是显卡型号与显存、驱动版本、Python 环境与一长串依赖的组合，而且不同版本对这三者的要求各不相同。版本组合不匹配时，报错信息通常并不指向真正原因。",
        "pitfalls": "①先装后查显卡：装完才发现显存不够，前面的时间全废，这一步应该反过来做；②用系统 Python：这是这类失败的常见起点，一定要独立环境并锁死版本；③跳过官方最小示例直接跑自己的模型：跳过之后，所有报错都变成猜谜；④拿它与 MuJoCo 比性能：两者擅长的任务不同，比出来的数字没有意义。",
        "checked": "我们核过：①许可范围（开发与部署是否都免费、有无版税）②它对硬件的硬性前提 ③与 MuJoCo 的分工关系。没核过：本站没有在指定配置上做过安装对照，所以具体版本组合的兼容性以官方文档为准。"
      },
      "facts": [
        {
          "k": "许可",
          "v": "开发与部署均免费，无按台版税"
        },
        {
          "k": "硬件前提",
          "v": "需要 NVIDIA 显卡；像素级训练对显存要求明显更高"
        },
        {
          "k": "相关组件",
          "v": "Isaac Sim（仿真）、Isaac Lab（训练）、Isaac ROS（部署）、GR00T（模型）"
        },
        {
          "k": "对手关系",
          "v": "与 MuJoCo 是分工不是替代：要快迭代用后者，要像素与迁移用前者"
        },
        {
          "k": "文档",
          "v": "developer.nvidia.com/isaac",
          "url": "https://developer.nvidia.com/isaac"
        }
      ],
      "verdict": "把「免费」翻译完整：许可免费，加上一台够用的显卡，加上一个干净的 Python 环境。这三样缺任何一样，成本就不在许可上，而在你的周末上。 如果这三样你只有两样，先用 MuJoCo 把算法跑通是更划算的顺序。",
      "grade": "B",
      "objects": [
        "isaac-sim",
        "mujoco"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "官方文档（系统要求、版本组合、许可范围）"
        },
        {
          "text": "一线使用者在论坛与项目 issue 中关于安装失败的描述（多为依赖与驱动版本问题）"
        }
      ]
    },
    {
      "id": "feetech-servo",
      "type": "hardware",
      "lang": "zh",
      "column": "hardware",
      "url": "https://robotbaseline.com/hardware/feetech-servo/",
      "title": "一只 20kg·cm 的舵机：这个数字是在什么条件下测的",
      "lede": "舵机常占一台桌面机器人物料成本的一半以上，而它的核心参数是整个清单里最不可比的。横比之前，先把口径对齐——对齐之后排序常常会变。",
      "fields": {
        "spec": "参数表上写着 20kg·cm，但这个数字至少缺四个前提：在几伏电压下测的、测的是堵转还是额定、峰值能撑多久、测试臂长与测力方式是什么。各家口径不同，同规格的两只舵机按同一口径重测，排序可能反转。看不到前提的扭矩数字，只能当量级参考，不能当排序依据。",
        "tiers": "低价带（单只十几到二十美元）是当前 DIY 生态的默认选择：总线通信加位置反馈，这个组合在几年前要贵得多。它的代价是耐久与一致性——同一批次内部也有差异，做多关节机器时要留出重新标定的余量，也要准备备件。往上一个价位带换来的主要是耐久和一致性，而不是扭矩翻倍。",
        "picking": "四条按顺序做：①把候选型号的数据手册并排打开，逐项对齐电压、堵转/额定、持续时间三项；②看齿轮材质与虚位，这两项数据手册常不写，但决定反复冲击下的寿命；③确认通信协议与上位机支持，总线舵机的生态锁定比扭矩更影响你的进度；④按多关节总数算总价，舵机占成本比例高，单只差几美元在整机上会被放大。",
        "pitfalls": "①按参数表数字排序选型——这是最贵的一个习惯，尤其在做多关节机器时；②忽略电压口径：同一只舵机在不同电压下扭矩差别很大，跨电压对比等于没比；③不留备件：低价舵机的一致性意味着偶尔会遇到个体差异，装机前就配对测试比装好之后返工便宜得多。",
        "checked": "我们核过：①这一类舵机在多个开源硬件项目里被当作默认选择的事实 ②总线通信与位置反馈这两个能力的有无 ③价格量级。没核过：本站没有对具体型号做过统一口径的扭矩台架测试——所以这里给的是对齐口径的方法，不是某两只舵机的实测排序。"
      },
      "facts": [
        {
          "k": "典型型号",
          "v": "Feetech STS 系列（SO-100 / SO-101 / LeKiwi 在用）"
        },
        {
          "k": "价位",
          "v": "单只低于 20 美元档"
        },
        {
          "k": "通信",
          "v": "总线（半双工串行），支持串联多只"
        },
        {
          "k": "反馈",
          "v": "带位置反馈，能读回当前位置"
        },
        {
          "k": "材料",
          "v": "金属齿轮为主；具体型号差异大，按型号查数据手册"
        }
      ],
      "verdict": "别按参数表的数字排序，按数据手册的测试条件排序。这是整套清单里最省钱的一条纪律——舵机占成本比例高，判断误差会被关节数量放大。买散件时多花二十分钟对齐口径，通常能省下一套备用件的钱。",
      "grade": "B",
      "objects": [
        "feetech-servo",
        "so-101"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "主流舵机厂商数据手册中扭矩测试条件的逐项对照（电压 / 堵转或额定 / 持续时间）"
        },
        {
          "text": "开源硬件项目公开的物料清单（用于确认该系列在 DIY 项目中的实际使用位置）"
        }
      ]
    },
    {
      "id": "robstride-motor",
      "type": "hardware",
      "lang": "zh",
      "column": "hardware",
      "url": "https://robotbaseline.com/hardware/robstride-motor/",
      "title": "一体化关节电机：为什么它替掉了舵机，代价在哪",
      "lede": "把无刷电机、减速器和驱动器塞进一个圆柱体，用一根总线串起来——这是低成本人形能做出 2,500 美元价位的直接原因。它同时把工具链的门槛也抬高了一档。",
      "fields": {
        "spec": "这类电机标的是关节级指标而不是裸电机指标：峰值扭矩、连续扭矩、减速比、允许的最高关节转速，以及散热条件。对比时最容易出错的地方是把峰值扭矩当连续扭矩用——峰值只在短时成立，连续扭矩才是长时间工作时真正能用的那个数字。看参数时先找「连续」两个字。",
        "tiers": "单只一百多到两百多美元，一台十二自由度的人形光电机就要接近两千美元，占整机七成。往下换舵机方案便宜一个量级，但扭矩与耐久撑不住人形尺度的关节；往上换工业关节模组，单只价格直接翻数倍。这个价位带是当前低成本人形的现实落点。",
        "picking": "①先按关节位置分档：髋、膝要的扭矩和踝完全不同，别全线用同一型号，混搭能省下可观的钱；②确认驱动方式：一体化电机的驱动器已经内置，省掉外置驱动与走线，但也意味着你少了一层可替换性；③算总线负载：一条总线上挂多个关节，控制频率与数据量要一起算；④留散热余量：连续工作时的温升是这类电机最容易低估的一项。",
        "pitfalls": "①把峰值扭矩当连续扭矩——装上之后才发现跑几分钟就触发过温降功率；②驱动器内置带来的锁定：参数与保护逻辑由厂商固件决定，出问题时可调空间小；③直接用舵机那套调试习惯：这类电机的调参、零位标定和保护阈值都不在同一套工具里，换过来需要重新学一遍。",
        "checked": "我们核过：①它的通信方式（CAN FD）与一体化结构 ②在 LeRobot Humanoid 上的具体型号与数量分布 ③价格分档量级。没核过：本站没有做过扭矩台架与温升测试，所以「连续扭矩在实际散热条件下能到多少」这条没有实测数据。"
      },
      "facts": [
        {
          "k": "结构",
          "v": "无刷电机 + 减速器 + 驱动器一体化"
        },
        {
          "k": "通信",
          "v": "CAN FD 总线，多关节串在一条线上"
        },
        {
          "k": "价位",
          "v": "单只约 110–225 美元，按型号与扭矩分档"
        },
        {
          "k": "典型用法",
          "v": "LeRobot Humanoid 的下肢 12 个主动自由度"
        },
        {
          "k": "相比舵机",
          "v": "扭矩与散热余量大得多；接线与调试复杂度也高得多"
        }
      ],
      "verdict": "如果你的关节需要持续输出较大扭矩、且要做十几个关节的同步，一体化电机是当前最省事的方案——用钱换掉了外置驱动、走线和一套自定义关节设计。如果只是桌面臂量级，舵机方案依然更划算，而且调试友好得多。分界线在「连续扭矩够不够」，不在自由度数量。",
      "grade": "B",
      "objects": [
        "robstride-motor",
        "can-bus",
        "lerobot-humanoid"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "厂商数据手册中的峰值扭矩、连续扭矩与散热条件说明"
        },
        {
          "text": "开源人形项目公开的物料清单与选型说明（型号与关节位置的对应关系）"
        }
      ]
    },
    {
      "id": "can-bus",
      "type": "hardware",
      "lang": "zh",
      "column": "hardware",
      "url": "https://robotbaseline.com/hardware/can-bus/",
      "title": "CAN 总线：DIY 机器人从舵机跨到无刷的那道门槛",
      "lede": "一旦关节从舵机换成无刷的一体化电机，通信几乎必然落到 CAN 上。接线不难，难的是几件事必须同时成立——它们不会一起报错，只会一起沉默。",
      "fields": {
        "spec": "CAN 的关键参数不是速率而是终端与拓扑：总线两端各 120Ω 终端电阻、所有节点共地、支线尽量短。少了终端电阻的症状极具误导性——不是「不通」，而是时通时不通、偶发丢包，看起来像软件问题。速率方面，CAN FD 能让两端都支持的设备传更多数据，但只要有一个节点只支持经典 CAN，整条总线就得按低的那一档跑。",
        "tiers": "入门成本很低：一个 USB-CAN 适配器就能开始，一体化电机自带 CAN 收发。真正要花钱的地方是主控侧——如果主控没有原生 CAN 控制器，就要加一块带 CAN 的板子或换主控。选主控时把「有没有 CAN 控制器」列进必查项，比事后加装省事。",
        "picking": "①先确认主控有没有 CAN 控制器，这是最容易在买完之后才发现的一项；②按总线数量选适配器：一条总线挂了多个关节时，带宽与实时性要一起算，通道不够就得加；③准备万用表：上电前先量终端电阻，两条信号线之间的电阻应该接近 60Ω（两个 120Ω 并联），这一分钟能省掉一整天；④统一波特率：所有节点必须一致，不一致的表现同样是不报错、只不通。",
        "pitfalls": "①少终端电阻——偶发丢包最难查，因为现象不稳定；②共地没做：差分线看着抗干扰，但节点之间参考电位差大了照样出错；③用不支持 CAN 的主控硬接：有些主控只能用软件模拟，时序一忙就崩；④把 CAN FD 和经典 CAN 混在一条总线上：整条总线会被拉回低档，而这不报错。",
        "checked": "我们核过：①终端电阻与拓扑这两项硬要求 ②主控侧需要真正的 CAN 控制器（不能用 GPIO 模拟）③CAN FD 与经典 CAN 混用会降档这一行为。没核过：本站没有对具体适配器做过丢包率与延迟的对照测试，所以这里只写机制与方法，不给某款适配器的性能结论。"
      },
      "facts": [
        {
          "k": "物理层",
          "v": "差分双绞线，两根信号线加共地"
        },
        {
          "k": "终端电阻",
          "v": "总线两端各 120Ω，缺一个就开始随机丢包"
        },
        {
          "k": "速率",
          "v": "经典 CAN 最高 1 Mbps；CAN FD 更高，但两端都要支持"
        },
        {
          "k": "主控要求",
          "v": "需要真正的 CAN 控制器，不是普通 GPIO 能模拟的"
        },
        {
          "k": "常见接法",
          "v": "USB-CAN 适配器接主机，或多通道 CAN FD 适配器接多个总线"
        }
      ],
      "verdict": "把它当成一道一次性门槛而不是长期麻烦：终端电阻、共地、波特率、主控的 CAN 控制器，四项一次做对，之后基本不会再碰。四项里最容易漏的是主控那一条，而它恰恰是唯一无法用接线补救的——选主控的时候就该定下来。",
      "grade": "B",
      "objects": [
        "can-bus",
        "robstride-motor"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "CAN 总线物理层规范（终端电阻、拓扑与速率的公开标准说明）"
        },
        {
          "text": "开源机器人项目与电机厂商文档中的接线与调试记录"
        }
      ]
    },
    {
      "id": "open-source-layers",
      "type": "claims",
      "lang": "zh",
      "column": "claims",
      "url": "https://robotbaseline.com/claims/open-source-layers/",
      "title": "「开源」到底开了哪一层",
      "lede": "参数表上最常见的四个字，在 DIY 圈被默认理解成「我能自己修、自己改、自己复刻」。但它在硬件圈没有统一定义，同一句话能指四件完全不同的事。",
      "fields": {
        "claim": "「这台机器人是开源的。」——因此在 DIY 语境里，它被读作：我能自己修、自己改、自己复刻，甚至自己造第二台。",
        "reality": "「开源」在机器人硬件上至少指四种东西：只给 SDK 与文档；开放硬件（原理图与结构 CAD）；公开物料清单与采购渠道；全栈（连训练数据与策略权重一起给）。同一句「开源」落到不同层上，你能做的事差得很远。还有更隐蔽的一层：给了文件，但给的是只读导出——PCB 只有 PDF 没有工程文件、三维模型只有 STL 没有可编辑的 STEP，看着齐全，实际想改结构基本没有出路。",
        "gap": "宣传语说「开源」，读者脑子里默认的是最高那一层；多数机器实际停在第①层。这不算撒谎——是「开源」在硬件圈被各方按对自己有利的口径使用的结果。同一条街上还能看到反例：Dynamixel 这类硬件完全闭源、价格明显更贵的产品，协议文档、SDK 与仿真模型却长期免费公开。**硬件闭源不等于生态封闭。**",
        "conditions": "只有当发布方明确写出「开了哪一层」时，这个词才有信息量。判据是可操作的三条：能不能拿到可编辑的工程文件而不是只读导出；能不能按公开清单独立采购齐零件；许可证是否允许商用与再发布。"
      },
      "facts": [],
      "verdict": "别问「它开源吗」，问「它把哪一层开了」。前者只会得到一句宣传语，后者能直接决定你买回来之后还能不能改。",
      "grade": "B",
      "objects": [
        "unitree-g1",
        "so-101",
        "lerobot-humanoid",
        "dynamixel"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "各项目官方仓库与文档中的 licenses / hardware 目录说明（逐项核对「给了什么文件格式」）"
        },
        {
          "text": "相关项目众筹页与发货说明（用于对照「宣称的开源范围」与「实际发布的文件」）"
        }
      ]
    },
    {
      "id": "dof-not-the-bottleneck",
      "type": "claims",
      "lang": "zh",
      "column": "claims",
      "url": "https://robotbaseline.com/claims/dof-not-the-bottleneck/",
      "title": "自由度越多越强——这条最流行，也最容易被证伪",
      "lede": "参数表上最容易比较、最容易加价的数字就是自由度。它恰好也是最不决定「能不能干活」的那一个。",
      "fields": {
        "claim": "自由度数等于能力等级：自由度多的机器比少的强，关节数是选型的核心指标。",
        "reality": "技术讨论里反复出现的是另一个结论：边缘自由度很少是瓶颈，感知管线、策略训练数据和安全边界才是。也就是说，卡住你的通常不是「少了一个关节」，而是「看见的东西不准」或「策略没在真实环境里训过」。",
        "gap": "自由度是最容易印在参数表上的数字——可量化、可比较、可加价。而真正决定能不能干活的感知与数据没有可比的数字。于是参数表被自由度主导，读者照参数表决策，预算花在了不决定成败的那一项上。",
        "conditions": "自由度确实决定能力上限，但只有在你已经把感知与策略做到位之后，多出来的关节才用得上。顺序反过来，等于把钱投在天花板上而没打地基。"
      },
      "facts": [],
      "verdict": "一台高自由度、配一套糟糕感知栈的机器，处境比低自由度、配干净策略的桌面臂更差——前者要处理的失败模式多得多。DIY 的钱先花在跑得通的策略和稳定的感知上，加关节放到最后。",
      "grade": "B",
      "objects": [
        "unitree-g1",
        "so-101",
        "lerobot-humanoid"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "机器人学习与操作方向的公开技术讨论（关于瓶颈在感知与数据而非关节数的论述）"
        }
      ]
    },
    {
      "id": "libero-shortcut",
      "type": "claims",
      "lang": "zh",
      "column": "claims",
      "url": "https://robotbaseline.com/claims/libero-shortcut/",
      "title": "LIBERO 上的高分，有多少在测环境而不是在测能力",
      "lede": "一个基准同时在做两件事：衡量能力，和被高分刷榜。当随机化不够时，后者会赢。",
      "fields": {
        "claim": "在 LIBERO 上分数高，说明模型的操作能力强。排行榜就是能力排名。",
        "reality": "复现与评测讨论里出现的一类发现是：这个基准里相当一部分样本可以被「统计捷径」拿到高分——模型不必学会抓取逻辑，只要记住环境纹理和物体的常见位置就能过关。也就是说，模型学到的是这个环境长什么样，而不是该怎么抓。",
        "gap": "基准的设计目标是公平可比，但它同时在优化两件事：衡量能力，和被高分刷榜。当采样、纹理与初始位置缺少足够随机化时，捷径是成本最低的解法——不是作弊，是优化器找到了更省力的路。",
        "conditions": "随机化足够（纹理、光照、初始位置、相机位姿）时，捷径失效，分数才回到能力本身。判断一个基准可不可信，看它写了多少随机化的细节，而不是看排行榜排到第几名。"
      },
      "facts": [],
      "verdict": "看到 LIBERO 或任何仿真基准的分数，先问三件事：初始位置随机化到什么程度、纹理与光照有没有扰动、有没有留出没被调过参的测试集。三个都答不上来，这个分数只能当参考，不能当选型依据。",
      "grade": "B",
      "objects": [
        "libero",
        "openvla"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "LIBERO 基准论文与后续复现讨论（关于随机化设置与捷径解）"
        },
        {
          "text": "视觉-语言-动作模型的复现性讨论（关于仿真分数与真机表现的差距）"
        }
      ]
    },
    {
      "id": "lerobot-humanoid",
      "type": "blueprints",
      "lang": "en",
      "column": "blueprints",
      "url": "https://robotbaseline.com/en/blueprints/lerobot-humanoid/",
      "title": "A USD 2,500 biped: what LeRobot Humanoid hands you, and what it does not",
      "lede": "The first bipedal humanoid at this price that you can start training on without redesigning the structure. The value is not the price tag — it is that hardware, runtime, identification, training environments and a policy zoo arrive in one release. What did not arrive is what decides how much extra you actually pay.",
      "fields": {
        "files": "75 STL parts cover torso, hip, thigh, knee, shin, ankle and foot subassemblies, and the BOM names the exact motors and hardware part numbers — there is no sourcing work left to do. The more valuable half is that the same release carries the runtime, the identification pipeline, the training environments (MJLab) and the policy library. That is what \"closed loop\" means concretely. What is missing is editable structure. You get STL, not STEP: lengthening a link by two centimetres means rebuilding a mesh into a solid model first.",
        "bom": "Motors are about USD 1,880 — over 70% of the machine. Printed parts come to roughly USD 56 of filament, and the rest is the bus adapter, hardware and fasteners, for about USD 2,500 total. That figure excludes the printer, the tools, and every print you ruin. At 3.5 kg of filament, buying double the material for the first round of iteration is normal rather than wasteful.",
        "print": "The minimum envelope is 220x220x250 mm, so an ordinary desktop printer can do this — but load-bearing parts such as thigh and knee want 80% infill and 5 perimeters, while shell parts are fine at 20%. That difference decides whether it stands up; do not flatten the settings to save time. Budget the whole print in days, not hours.",
        "hardest": "Not printing — getting both legs to actually stand. The gap between simulated parameters and the real machine has to be closed with the official identification pipeline, and there is no shortcut there. Second is the bus: the Robstride motors speak CAN FD, not the signal wiring hobby servos use. Correct wiring does not guarantee a working bus; termination and a controller with a real CAN peripheral both have to land.",
        "checked": "We checked three things: (1) the release scope — whether hardware, runtime, identification, training and policies sit under the same licence; (2) whether the motor types and counts in the BOM match the described 12 actuated degrees of freedom; (3) the minimum print envelope and the infill requirement on load-bearing parts. We have not built it. So \"does it walk once assembled\" carries no first-hand conclusion here — on this site's own scale that keeps the entry at grade B rather than D, and we will upgrade it when a build log exists."
      },
      "facts": [
        {
          "k": "Structural files",
          "v": "75 STL parts, printable in PLA+ / PETG"
        },
        {
          "k": "Editable CAD",
          "v": "No STEP released; changing structure means rebuilding it yourself"
        },
        {
          "k": "Print envelope",
          "v": "Minimum 220x220x250 mm; load-bearing parts at 80% infill, 5 perimeters"
        },
        {
          "k": "BOM",
          "v": "About USD 2,500, of which motors are roughly USD 1,880"
        },
        {
          "k": "Licence",
          "v": "Apache 2.0"
        },
        {
          "k": "Repo",
          "v": "github.com/huggingface/lerobot",
          "url": "https://github.com/huggingface/lerobot"
        }
      ],
      "verdict": "Currently the only biped where buying the parts is enough to get to the actual subject, which is robot learning. It suits someone who already owns a 3D printer and wants to train policies rather than design mechanisms. If you came to build a humanoid with your hands, 75 printed parts and a CAN bus will keep you busy for a long while — and if you just want legs moving soon, get the full pipeline working on a desktop arm first.",
      "grade": "B",
      "objects": [
        "lerobot-humanoid",
        "robstride-motor",
        "can-bus"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "Official release and hardware repository (STL count, BOM, printing guide, licence)"
        },
        {
          "text": "Official training environment and policy library documentation (MJLab, identification pipeline)"
        }
      ]
    },
    {
      "id": "so-101",
      "type": "blueprints",
      "lang": "en",
      "column": "blueprints",
      "url": "https://robotbaseline.com/en/blueprints/so-101/",
      "title": "A USD 110 arm: why SO-101 is the one to build first",
      "lede": "At the low end this is the most literal use of \"open source\": you can buy the parts, change the structure and replace what breaks. It is also the shortest entry point into the robot learning chain that currently exists.",
      "fields": {
        "files": "Printed structure plus standard hardware and servos — the buy-the-list-and-start category. The real value is not the files themselves but that a large number of projects use it as the reference point: LeRobot documents its dimensions, servo model and calibration flow, so almost any problem you hit has been hit before and written down.",
        "bom": "The kit lands from about USD 110, servos being most of it. What that price actually buys is the ability to own two — one to run, one to take apart. Half the value of a cheap arm is here: it makes breaking your first one affordable, and breaking your first one is the fastest way to learn.",
        "print": "Roughly a kilogram of filament; a desktop printer handles the main parts in one go, no industrial equipment needed. Tolerance is where these printed arms go wrong: the same STL off two different machines can come out needing holes reamed or pins sanded. Print two small parts first and check the fit before committing to the whole set.",
        "hardest": "Not assembly — getting calibration and teleoperation stable. The arm goes together quickly; what follows is camera calibration, servo zeroing and consistency in how you record data. Those decide whether the policy you train later is usable at all. This is where most people stall, and most of them blame the arm.",
        "checked": "We checked: its documented role as the entry-level hardware in LeRobot, the mapping between servo model and bus type, and the price band. Not checked: how a given batch of printed parts actually fits, and which file formats the current release publishes — both move with versions, so treat the repository as the source of truth at the moment you fetch it."
      },
      "facts": [
        {
          "k": "Form factor",
          "v": "Desktop 5 DOF plus gripper"
        },
        {
          "k": "Structure",
          "v": "3D-printed parts plus standard hardware; ordinary desktop printer"
        },
        {
          "k": "BOM",
          "v": "From about USD 110 (SO-100 price point; SO-101 a little higher)"
        },
        {
          "k": "Servos",
          "v": "Feetech STS series — bus communication with position feedback"
        },
        {
          "k": "Software pairing",
          "v": "LeRobot (collect, train, deploy in one chain)"
        },
        {
          "k": "Repo",
          "v": "github.com/huggingface/lerobot",
          "url": "https://github.com/huggingface/lerobot"
        }
      ],
      "verdict": "If you build one thing, build this. At USD 110, iteration becomes a thing you can afford, and the software chain around it is the most complete one available today. Its ceiling is low — do not expect fine manipulation — but as an entry point to the whole chain, nothing at this price competes.",
      "grade": "B",
      "objects": [
        "so-101",
        "feetech-servo",
        "lerobot"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "LeRobot official documentation: entry-level hardware and assembly guidance"
        },
        {
          "text": "Open hardware project release page (structural parts, BOM, servo model)"
        }
      ]
    },
    {
      "id": "thor-arm",
      "type": "blueprints",
      "lang": "en",
      "column": "blueprints",
      "url": "https://robotbaseline.com/en/blueprints/thor-arm/",
      "title": "Thor: an industrial joint layout for EUR 350, paid for in printing hours",
      "lede": "A 6-axis arm built from stepper motors driving printed gears and GT2 belts, with a joint arrangement copied from industrial manipulators. The trade is typical of the genre: the money you save is converted directly into printer time.",
      "fields": {
        "files": "49 STL parts cover the six joints, the gripper, the base and bearing fixtures, all designed in FreeCAD. The control board is a custom shield on an Arduino Mega that combines six stepper drivers with limit-switch and fan inputs. The firmware is GRBL-based, meaning it accepts standard G-code — and that matters more than the parts list, because it puts the arm inside a tooling ecosystem that has existed for over a decade.",
        "bom": "Parts come to about EUR 350. The dominant cost is time, not money: 60 to 80 hours of printing is the baseline, and failed reprints scale on top of that. A commercial 6-axis arm is in a different price universe, but you hold every structural file here, so any part that cracks can be printed again.",
        "print": "60-80 hours assumes everything works first time. Gear and belt transmission demands more from a printer than cosmetic shells do: layer bonding and tooth accuracy feed directly into joint backlash, and both depend on nozzle, layer height and filament. If you are new to tuning, print two gear pairs in scrap material and measure the backlash before committing the whole set.",
        "hardest": "Not assembly — getting backlash across six joints small enough for the kinematics to converge. Printed gears and belts have backlash by nature, so a target position approached from two directions ends up in two different places. Every printed arm faces this; the answers are preload, compensation, or better transmission, and all three cost time.",
        "checked": "We checked: the STL manifest against the joint units, the firmware's command protocol (whether it is standard G-code), and how the ROS 2 / MoveIt2 integration is packaged. Not checked: we have not assembled this arm, so the 750 g payload and repeatability figures rest on vendor and community claims, not on our own measurement."
      },
      "facts": [
        {
          "k": "Structural parts",
          "v": "49 STL files, all designed in FreeCAD"
        },
        {
          "k": "Print time",
          "v": "Estimated 60-80 hours at 0.4 mm nozzle, 0.2 mm layers"
        },
        {
          "k": "Specs",
          "v": "625 mm tall, 750 g payload, 6 axes plus gripper"
        },
        {
          "k": "Parts cost",
          "v": "About EUR 350 (printer and tools excluded)"
        },
        {
          "k": "Transmission",
          "v": "Stepper motors with printed gears and GT2 belts"
        },
        {
          "k": "Firmware and software",
          "v": "GRBL (accepts G-code); Asgard host app; ROS 2 / MoveIt2 integration"
        },
        {
          "k": "Licence",
          "v": "CC BY-SA 4.0"
        }
      ],
      "verdict": "If you want to learn kinematics and own a multi-axis arm you can repair and modify, the choice here is straightforward — accept that the real cost is printer time. It is wrong for anyone who wants something moving within a week, and right for someone who will spend a quarter building one machine and keep revisiting it afterwards.",
      "grade": "B",
      "objects": [
        "thor-arm"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "Project repository (STL manifest, hardware notes, licence)"
        },
        {
          "text": "Official documentation and the accompanying ROS 2 / MoveIt2 repositories"
        }
      ]
    },
    {
      "id": "lerobot",
      "type": "software",
      "lang": "en",
      "column": "software",
      "url": "https://robotbaseline.com/en/software/lerobot/",
      "title": "LeRobot: turning \"collect data, then make it move\" into scripts",
      "lede": "Apache 2.0, Python, and currently the shortest path from nothing to a moving robot on the hobbyist side. The barrier is not the concepts — it is whether you accept Linux and a command line.",
      "fields": {
        "solves": "It solves a plumbing problem, not an algorithm problem. Recording by teleoperation, a consistent data format, a training script and real-robot inference are four separate jobs, and the expensive part has always been joining them up. LeRobot puts all four in one repository with one command style, validated on cheap hardware. For a solo builder that means someone else already walked through the environment-configuration swamp for you.",
        "alternatives": "It is not a replacement for ROS 2 — they operate at different layers. LeRobot handles policies; ROS 2 handles messaging, drivers and real-time behaviour, and mature setups often train in LeRobot and deploy under ROS 2. For simulation-first work, Isaac Lab is the counterpart, but it leans towards large-scale parallel training and synthetic data rather than real-world data collection. Vendor SDKs let you command one specific machine but rarely give you a cross-hardware training chain.",
        "requires": "The cost is three things it does not control: a Linux environment (device permissions, serial ports and cameras all route through it), a GPU good enough to train on (inference can be lighter), and a willingness to calibrate. It does not pretend to be an appliance, and the documentation says so directly.",
        "pitfalls": "Three recurring ones: (1) expecting plug-and-play — calibration and camera setup are mandatory steps, and skipping them makes every dataset afterwards unusable; (2) hardware that drifts — cheap servos and printed parts shift with temperature and wear, so recalibrate before recording a new dataset; (3) installing into the system Python — dependency conflicts across versions are the most common way these projects die at the starting line.",
        "checked": "We checked the licence and commercial terms (Apache 2.0, no royalty), the list of hardware it explicitly supports, and the documentation's own statement that hands-on experience is required. Not checked: we have not run the full training flow from scratch, so estimates of how long a beginner needs to produce a first usable policy are not backed by first-hand data here."
      },
      "facts": [
        {
          "k": "Licence",
          "v": "Apache 2.0 — no fee for commercial use or redistribution"
        },
        {
          "k": "Language",
          "v": "Python; the hardware side expects a Linux environment and device permissions"
        },
        {
          "k": "Supported hardware",
          "v": "SO-100 / SO-101 / LeKiwi / Reachy Mini and similar low-cost hardware"
        },
        {
          "k": "Policies included",
          "v": "Working implementations of imitation-learning methods such as ACT and Diffusion Policy"
        },
        {
          "k": "Data side",
          "v": "Connects to the Hugging Face dataset hub and converts public datasets"
        },
        {
          "k": "Repo",
          "v": "github.com/huggingface/lerobot",
          "url": "https://github.com/huggingface/lerobot"
        }
      ],
      "verdict": "If your goal is to make a cheap arm do what you show it, this is the least painful route available. If your goal is to understand how the learning algorithms work inside, it sits too high up and you will want to read implementations directly. Do it in that order: get it working first, then go back and read the algorithm.",
      "grade": "A",
      "objects": [
        "lerobot",
        "so-101",
        "lerobot-humanoid"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "Official repository and documentation (licence, supported hardware, setup requirements, stated limits)"
        },
        {
          "text": "Public technical reviews and usage reports (Linux/Python prerequisites, calibration burden)"
        }
      ]
    },
    {
      "id": "ros2",
      "type": "software",
      "lang": "en",
      "column": "software",
      "url": "https://robotbaseline.com/en/software/ros2/",
      "title": "ROS 2: when it is required, and when it is just overhead",
      "lede": "The de facto standard for robot middleware, BSD-licensed at the core with no royalty for commercial use. But it handles messaging, not policies — and a single desktop arm running system-level middleware is often a factory carrying a desk job.",
      "fields": {
        "solves": "It solves communication and real-time behaviour between subsystems: cameras, arms, bases, navigation and planning each run as separate processes and need a messaging layer that keeps time and priority straight. When your robot is one arm and two cameras, none of those requirements exist, and the middleware's overhead is pure cost.",
        "alternatives": "For a single arm doing learning work, running LeRobot directly is far quicker and removes the whole concept stack. For simulation-first work, Isaac Lab ships its own training framework. A vendor SDK is often sufficient on its own: if you command one machine and do not coordinate multiple devices, an SDK plus a bit of scripting usually beats introducing middleware. The value of ROS 2 rises with system complexity, not with your skill level.",
        "requires": "The price is a set of concepts you cannot skip: DDS configuration, QoS policies, node graphs, lifecycle management. These are not optional details — when a topic is silent, the cause is almost always sitting in one of them. On top of that it generally pins you to a specific Linux distribution, so the environment itself is work.",
        "pitfalls": "(1) Following a ROS 1 tutorial: ROS 1 is end of life and a great deal of online material has not been updated, which produces a string of unexplainable errors. (2) QoS mismatches that silently drop a topic — no error, just no data, which makes it one of the most expensive classes of bug. (3) Adopting it for credibility: on a small single-machine project the complexity it adds dwarfs what it solves.",
        "checked": "We checked the licence and commercial terms, the release cadence and the ROS 1 end-of-life date, and its division of labour with learning libraries (layers, not substitutes). Not checked: performance numbers in a specific project — the real-time impact of a DDS configuration depends heavily on hardware and setup, and we have not run comparative tests."
      },
      "facts": [
        {
          "k": "Licence",
          "v": "BSD-3-Clause core; no royalty for commercial products"
        },
        {
          "k": "Current LTS",
          "v": "Kilted Kaiju (five-year support window)"
        },
        {
          "k": "Next LTS",
          "v": "Lyrical Luth, released May 2026"
        },
        {
          "k": "ROS 1",
          "v": "End of life since May 2025; tutorials written against it are out of date"
        },
        {
          "k": "Languages",
          "v": "First-class Python and C++, with Rust bindings"
        },
        {
          "k": "Docs",
          "v": "docs.ros.org",
          "url": "https://docs.ros.org"
        }
      ],
      "verdict": "Decide on complexity, not on seniority: multiple subsystems that must cooperate — use it; one arm on one machine — do not. A practical threshold: the moment you start writing your own glue for inter-process communication, that is the signal to bring in ROS 2. If you are only trying to make one arm move, that is the signal to stay away from it a while longer.",
      "grade": "A",
      "objects": [
        "ros2"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "ROS 2 official documentation (release support windows, licence, system requirements)"
        },
        {
          "text": "Public technical comparisons (the layering between learning libraries and middleware)"
        }
      ]
    },
    {
      "id": "isaac-sim",
      "type": "software",
      "lang": "en",
      "column": "software",
      "url": "https://robotbaseline.com/en/software/isaac-sim/",
      "title": "Isaac Sim is free; getting it to run is a different matter",
      "lede": "The licence is free, the barrier is not. The first weekend usually goes on making the environment start rather than on learning simulation — and that is the part no slogan mentions.",
      "fields": {
        "solves": "It solves two things: large-scale parallel training and pixel-level simulation. Physics runs on the GPU so thousands of environments can step at once, and photorealistic rendering produces synthetic data. For vision-based policies and sim-to-real transfer this is the most complete path available. If your task only cares about dynamics and contact, MuJoCo runs on CPU and iterates faster.",
        "alternatives": "MuJoCo is the main counterpart: light, fast, CPU-friendly, a research default for contact-rich manipulation, with a JAX port that compiles physics onto the GPU. PyBullet is lighter still but without a comparable ecosystem. The split is roughly: kinematics and contact only — MuJoCo; rendered pixels and domain randomisation — Isaac. Many labs run both.",
        "requires": "The licence costs nothing; the time does not. What decides whether it starts is the combination of GPU model and memory, driver version, Python environment and a long dependency chain — and different versions demand different combinations. When the combination is wrong, the error message rarely points at the real cause.",
        "pitfalls": "(1) Installing before checking the GPU, then discovering the memory is short and losing the whole session — do it the other way round. (2) Using the system Python, a common starting point for these failures; isolate and pin versions. (3) Skipping the official minimal example and jumping to your own model, after which every error becomes guesswork. (4) Benchmarking it against MuJoCo — they are good at different tasks, so the numbers mean nothing.",
        "checked": "We checked the licence scope (free at both development and deployment, no royalty), its hard hardware prerequisites, and the division of labour with MuJoCo. Not checked: we have not run installation comparisons on specific configurations, so treat the official documentation as authoritative for any given version pairing."
      },
      "facts": [
        {
          "k": "Licence",
          "v": "Free for development and deployment, no per-robot royalty"
        },
        {
          "k": "Hardware requirement",
          "v": "NVIDIA GPU; pixel-based training pushes memory requirements much higher"
        },
        {
          "k": "Related components",
          "v": "Isaac Sim (simulation), Isaac Lab (training), Isaac ROS (deployment), GR00T (models)"
        },
        {
          "k": "Position vs MuJoCo",
          "v": "Division of labour, not a substitute: MuJoCo for fast iteration, Isaac for pixels and transfer"
        },
        {
          "k": "Docs",
          "v": "developer.nvidia.com/isaac",
          "url": "https://developer.nvidia.com/isaac"
        }
      ],
      "verdict": "Translate \"free\" completely: a free licence, plus an adequate GPU, plus a clean Python environment. Miss any one of the three and the cost stops being the licence and becomes your weekend. If you have only two of the three, getting the algorithm working in MuJoCo first is the better sequence.",
      "grade": "B",
      "objects": [
        "isaac-sim",
        "mujoco"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "Official documentation (system requirements, version pairings, licence scope)"
        },
        {
          "text": "First-hand accounts in forums and project issues about installation failures (mostly dependency and driver versions)"
        }
      ]
    },
    {
      "id": "feetech-servo",
      "type": "hardware",
      "lang": "en",
      "column": "hardware",
      "url": "https://robotbaseline.com/en/hardware/feetech-servo/",
      "title": "A 20 kg-cm servo: measured under what conditions?",
      "lede": "Servos often account for more than half the bill of materials of a desktop robot, and their headline number is the least comparable figure in the whole list. Align the conditions before comparing — and the ranking often changes.",
      "fields": {
        "spec": "The datasheet says 20 kg-cm, but that number is missing at least four preconditions: at what voltage, stall or rated torque, sustained for how long, and measured at what arm length and by what method. Vendors differ, and two servos of the same nominal rating re-measured on the same terms can swap order. Without the preconditions a torque figure is an order-of-magnitude hint, not a ranking.",
        "tiers": "The low band (teens to low twenties of dollars per unit) is the current default across the DIY ecosystem: bus communication plus position feedback, a combination that cost much more a few years ago. What you pay for it is durability and consistency — units within one batch vary, so a multi-joint build needs calibration margin and spares. Moving up a band mostly buys durability and consistency rather than double the torque.",
        "picking": "Four steps, in order: (1) open the datasheets side by side and align voltage, stall versus rated, and duration; (2) look at gear material and backlash, which datasheets often omit but which decide life under repeated impact; (3) confirm the protocol and host-side support — ecosystem lock-in on bus servos affects your schedule more than torque does; (4) price the whole joint count, because servos dominate the bill and a few dollars per unit multiplies.",
        "pitfalls": "(1) Ranking by the datasheet number, the most expensive habit here, especially on a multi-joint machine. (2) Ignoring the voltage convention: the same servo delivers very different torque at different voltages, so cross-voltage comparison is no comparison at all. (3) No spares: consistency at this price means occasional outliers, and testing units as a set before assembly is cheaper than reworking afterwards.",
        "checked": "We checked that this family is treated as the default choice across several open hardware projects, that bus communication and position feedback are genuinely present, and the price band. Not checked: we have not run a torque bench test on specific models under a common protocol — so what is offered here is a method for aligning conditions, not a measured ranking of two particular servos."
      },
      "facts": [
        {
          "k": "Typical model",
          "v": "Feetech STS series (used by SO-100, SO-101, LeKiwi)"
        },
        {
          "k": "Price band",
          "v": "Under about USD 20 per unit"
        },
        {
          "k": "Communication",
          "v": "Bus (half-duplex serial), several units daisy-chained"
        },
        {
          "k": "Feedback",
          "v": "Position feedback — you can read the current angle back"
        },
        {
          "k": "Gearing",
          "v": "Mostly metal gears; differs by model, check the datasheet for the specific one"
        }
      ],
      "verdict": "Do not rank by the datasheet number; rank by the conditions the datasheet specifies. This is the cheapest single discipline in the whole parts list, because servos are such a large share of the cost that the error multiplies with joint count. Twenty extra minutes aligning conditions usually saves the price of a spare set.",
      "grade": "B",
      "objects": [
        "feetech-servo",
        "so-101"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "Side-by-side comparison of torque test conditions in mainstream servo datasheets (voltage, stall vs rated, duration)"
        },
        {
          "text": "Published bills of materials from open hardware projects (confirming where this series is actually used)"
        }
      ]
    },
    {
      "id": "robstride-motor",
      "type": "hardware",
      "lang": "en",
      "column": "hardware",
      "url": "https://robotbaseline.com/en/hardware/robstride-motor/",
      "title": "Integrated joint motors: what replaced hobby servos, and what it costs you",
      "lede": "A brushless motor, gearbox and driver squeezed into one cylinder and chained on a single bus — the direct reason a low-cost humanoid can hit a USD 2,500 price. It also raises the tooling barrier by one notch.",
      "fields": {
        "spec": "These motors are rated at the joint level, not the bare motor level: peak torque, continuous torque, gear ratio, maximum joint speed, and the thermal conditions behind each. The most common comparison error is reading peak torque as continuous — peak holds only briefly, and continuous is the figure that survives a long run. Look for the word continuous first.",
        "tiers": "From just over a hundred to just over two hundred dollars per unit, so a 12-DOF humanoid spends close to two thousand on motors alone — about 70% of the machine. Dropping to servos is an order of magnitude cheaper but neither torque nor durability holds up at humanoid scale; moving up to industrial joint modules multiplies the unit price several times. This band is where low-cost humanoids currently land.",
        "picking": "(1) Specify by joint position: hip and knee need something entirely different from ankle, and mixing models saves real money. (2) Note what integration costs you: a built-in driver removes external drivers and cabling but also removes a layer you could swap out. (3) Size the bus load: several joints on one line means control frequency and data volume have to be planned together. (4) Leave thermal margin: heat build-up under continuous operation is the most consistently underestimated figure here.",
        "pitfalls": "(1) Treating peak torque as continuous, then watching the motor throttle itself back after a few minutes of running. (2) Lock-in from the integrated driver: parameters and protection logic live in vendor firmware, leaving little room when something misbehaves. (3) Bringing servo debugging habits along: tuning, zeroing and protection thresholds are all in a different toolchain and have to be learned again.",
        "checked": "We checked the communication method (CAN FD) and integrated construction, the specific models and their distribution across joints on LeRobot Humanoid, and the price bands. Not checked: we have not run torque-bench or thermal tests, so how much continuous torque survives in a real thermal environment is not measured here."
      },
      "facts": [
        {
          "k": "Construction",
          "v": "Brushless motor, gearbox and driver integrated"
        },
        {
          "k": "Communication",
          "v": "CAN FD bus, several joints on one line"
        },
        {
          "k": "Price band",
          "v": "About USD 110-225 per unit, by model and torque class"
        },
        {
          "k": "Typical use",
          "v": "The 12 actuated lower-body DOF of LeRobot Humanoid"
        },
        {
          "k": "Versus servos",
          "v": "Far more torque and thermal headroom; far more wiring and tuning complexity"
        }
      ],
      "verdict": "If your joints need sustained torque and you are synchronising a dozen of them, integrated motors are the least painful option — you spend money to remove external drivers, wiring and a custom joint design. At desktop-arm scale, servos remain the better deal and are far friendlier to debug. The dividing line is whether continuous torque is sufficient, not the number of degrees of freedom.",
      "grade": "B",
      "objects": [
        "robstride-motor",
        "can-bus",
        "lerobot-humanoid"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "Vendor datasheets: peak torque, continuous torque and thermal conditions"
        },
        {
          "text": "Bills of materials and selection notes published by open humanoid projects (models mapped to joint positions)"
        }
      ]
    },
    {
      "id": "can-bus",
      "type": "hardware",
      "lang": "en",
      "column": "hardware",
      "url": "https://robotbaseline.com/en/hardware/can-bus/",
      "title": "CAN bus: the threshold between hobby servos and brushless joints",
      "lede": "The moment joints move from servos to integrated brushless motors, communication almost always lands on CAN. Wiring is not the hard part — the hard part is that several conditions must hold at once, and when one fails they do not raise an error together. They go quiet together.",
      "fields": {
        "spec": "The critical parameter is not the bitrate but termination and topology: 120 ohm at both ends, a common ground across every node, and short stubs. A missing terminator produces a symptom that is actively misleading — not \"no communication\" but intermittent communication and random packet loss, which looks like a software problem. On bitrate, CAN FD carries more data when both ends support it, but a single classic-CAN node on the bus drags the whole segment down to the lower rate.",
        "tiers": "Entry cost is low: one USB-CAN adapter gets you started, and integrated motors carry their own CAN transceivers. The real spending is on the host side — if your controller has no native CAN peripheral you need an add-on board or a different controller. Put \"has a CAN controller\" on the must-check list when choosing a controller; adding it later is worse.",
        "picking": "(1) Confirm the controller has a CAN peripheral — the easiest thing to discover too late. (2) Size the adapter to the number of buses: when several joints share a line, bandwidth and real-time behaviour have to be planned together, and one channel may not be enough. (3) Keep a multimeter handy: measure termination before powering up — the resistance across the two signal wires should read close to 60 ohm (two 120 ohm in parallel), and that minute saves a day. (4) Unify the bitrate: every node must match, and a mismatch again produces silence rather than an error.",
        "pitfalls": "(1) Missing termination — sporadic loss is the hardest class to diagnose because the symptom is not stable. (2) No common ground: differential signalling resists interference, but large potential differences between node references still break it. (3) Controllers without real CAN hardware: some boards can only bit-bang it, and timing collapses under load. (4) Mixing CAN FD with classic CAN: the segment drops to the lower rate and nothing reports it.",
        "checked": "We checked the two hard requirements of termination and topology, that the host side needs a real CAN peripheral rather than GPIO emulation, and the behaviour of mixing CAN FD with classic CAN. Not checked: we have not benchmarked specific adapters for packet loss or latency, so what is written here is the mechanism and the method rather than a verdict on any particular adapter."
      },
      "facts": [
        {
          "k": "Physical layer",
          "v": "Differential twisted pair, two signal wires plus a common ground"
        },
        {
          "k": "Termination",
          "v": "120 ohm at each end of the bus; miss one and packets drop sporadically"
        },
        {
          "k": "Bitrate",
          "v": "Classic CAN up to 1 Mbps; CAN FD higher, but both ends must support it"
        },
        {
          "k": "Controller requirement",
          "v": "A real CAN peripheral — not something a GPIO can emulate"
        },
        {
          "k": "Common setup",
          "v": "USB-CAN adapter to the host, or a multi-channel CAN FD adapter for several buses"
        }
      ],
      "verdict": "Treat it as a one-time threshold rather than an ongoing nuisance: termination, common ground, bitrate and a controller with real CAN hardware, all four right at once, and you will rarely touch it again. The controller item is the easiest to overlook and the only one wiring cannot rescue — settle it when you choose the board, not afterwards.",
      "grade": "B",
      "objects": [
        "can-bus",
        "robstride-motor"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "CAN physical layer specifications (published standards on termination, topology and bitrate)"
        },
        {
          "text": "Wiring and debugging records in open robot projects and motor vendor documentation"
        }
      ]
    },
    {
      "id": "open-source-layers",
      "type": "claims",
      "lang": "en",
      "column": "claims",
      "url": "https://robotbaseline.com/en/claims/open-source-layers/",
      "title": "\"Open source\" — which layer is actually open?",
      "lede": "The most common phrase on a spec sheet, and in DIY circles it is read as \"I can repair it, modify it and replicate it\". But hardware has no agreed definition, and the same sentence can mean four entirely different things.",
      "fields": {
        "claim": "\"This robot is open source.\" In a DIY context that gets read as: I can repair it, modify it, replicate it, even build a second one.",
        "reality": "In robot hardware, \"open source\" covers at least four things: SDK and documentation only; open hardware (schematics and structural CAD); a published bill of materials with sourcing channels; and full-stack, including training data and policy weights. The same phrase lands on very different layers, and what you can do differs enormously between them. There is a subtler layer still: files are provided, but as read-only exports — a PCB as PDF with no project files, a 3D model as STL with no editable STEP. It looks complete and gives you almost no way to change anything structural.",
        "gap": "The marketing line says \"open source\" and the reader's default assumption is the top layer; most machines actually stop at layer one. This is not lying — it is what happens when a term gets used by each party in the sense most favourable to them. The reverse case exists on the same street: hardware that is entirely closed and clearly more expensive, such as Dynamixel servos, has had openly published protocol documentation, SDKs and simulation models for years. Closed hardware does not mean a closed ecosystem.",
        "conditions": "The word only carries information when the publisher states which layer is open. Three operational tests: can you obtain editable engineering files rather than read-only exports; can you source every part from the published list yourself; does the licence permit commercial use and redistribution."
      },
      "facts": [],
      "verdict": "Do not ask whether it is open source. Ask which layer is open. The first gets you a slogan; the second decides whether you can still change the thing after you have paid for it.",
      "grade": "B",
      "objects": [
        "unitree-g1",
        "so-101",
        "lerobot-humanoid",
        "dynamixel"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "licences and hardware directory notes in the official repositories of the projects concerned (checking file formats offered)"
        },
        {
          "text": "Crowdfunding and shipping pages for the same projects (comparing claimed openness with files actually published)"
        }
      ]
    },
    {
      "id": "dof-not-the-bottleneck",
      "type": "claims",
      "lang": "en",
      "column": "claims",
      "url": "https://robotbaseline.com/en/claims/dof-not-the-bottleneck/",
      "title": "More degrees of freedom is better — the most popular claim, and the easiest to falsify",
      "lede": "Degrees of freedom is the easiest number to compare on a spec sheet and the easiest to charge more for. It is also the one that least determines whether the machine can do any work.",
      "fields": {
        "claim": "Degrees of freedom equals capability: a machine with more of them beats one with fewer, and joint count is the core selection metric.",
        "reality": "What technical discussion keeps arriving at is the opposite: marginal degrees of freedom are rarely the bottleneck. The perception pipeline, the training data behind the policy and the safety envelope are. What stops you is usually not a missing joint — it is that the machine sees inaccurately, or that the policy was never trained in a real environment.",
        "gap": "Degrees of freedom is the easiest number to print on a spec sheet: quantifiable, comparable, chargeable. Perception and data, which actually decide whether the machine works, have no comparable number. So the spec sheet ends up dominated by joint count, buyers decide from the spec sheet, and the budget lands on the item that does not decide anything.",
        "conditions": "Degrees of freedom do set the capability ceiling — but the extra joints only become usable once perception and policy are already in place. Reversed, you have invested in the ceiling without laying a foundation."
      },
      "facts": [],
      "verdict": "A high-DOF machine with a bad perception stack is worse off than a low-DOF desktop arm with a clean policy, because it has far more failure modes to handle. Spend on a working policy and stable perception first; add joints last.",
      "grade": "B",
      "objects": [
        "unitree-g1",
        "so-101",
        "lerobot-humanoid"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "Public technical discussion on robot learning and manipulation (the bottleneck lying in perception and data rather than joint count)"
        }
      ]
    },
    {
      "id": "libero-shortcut",
      "type": "claims",
      "lang": "en",
      "column": "claims",
      "url": "https://robotbaseline.com/en/claims/libero-shortcut/",
      "title": "How much of a LIBERO score measures the environment instead of the model",
      "lede": "A benchmark is doing two jobs at once: measuring capability and being gamed. When randomisation is thin, the second one wins.",
      "fields": {
        "claim": "A high LIBERO score means the model manipulates well, and the leaderboard is a capability ranking.",
        "reality": "A recurring finding in reproduction and evaluation discussion is that a substantial share of samples in this benchmark can be solved by a statistical shortcut: the model never has to learn grasping logic, only the environment textures and where objects usually sit. What it learned is what this environment looks like, not how to pick things up.",
        "gap": "The benchmark is designed to be fair and comparable, but it optimises two objectives at once: measure capability and be gamed. When sampling, textures and initial poses lack sufficient randomisation, the shortcut is the cheapest available solution — not cheating, just an optimiser finding the easier road.",
        "conditions": "With enough randomisation (texture, lighting, initial pose, camera pose) the shortcut stops working and the score returns to the capability itself. Whether a benchmark is trustworthy is decided by how much randomisation it documents, not by where a submission ranks."
      },
      "facts": [],
      "verdict": "When you see a LIBERO score, or any simulation score, ask three things: how much initial-pose randomisation, whether texture and lighting are perturbed, and whether there is a test set nobody tuned against. If none can be answered, the number is a pointer, not a basis for selection.",
      "grade": "B",
      "objects": [
        "libero",
        "openvla"
      ],
      "updated": "2026-09-28",
      "sources": [
        {
          "text": "The LIBERO benchmark paper and subsequent reproduction discussion (randomisation settings and shortcut solutions)"
        },
        {
          "text": "Reproducibility discussion of vision-language-action models (the distance between simulated scores and real-hardware behaviour)"
        }
      ]
    }
  ]
}