做机器人这些年，我最烦的一件事就是信息差。想评估一款人形机器人的方案，要翻官网、找论文、找供应链朋友打听价格，最后凑出来的数据口径还不一致，根本没法横向比。所以当“全球人形机器人数据库Atlas”在Github开源的消息传出来时，我第一时间就去仓库里翻了个遍。它做的事情很直接：把全球多款人形机器人的基本参数、结构构型、BOM清单、成本估算和真机供应链数据全部结构化地收进一个库，对外开放、可复用、可参与维护。对机器人架构师、硬件工程师、采购人员和产业研究来说，这东西的价值不亚于一本行业白皮书。注意，这里的Atlas是数据库项目名，不是某款具体的机器人产品，别理解错了。这篇文章我会按“数据底细、核心维度、实操方法、避坑指南、行业影响”的顺序讲，尽量说得细一点。1. 先把这个开源项目的底细摸清楚1.1 数据库里究竟装了什么Atlas数据库不是简单的Excel表格，它更像一套多模块数据集。我拉下来以后，看到数据主要有五块：基本信息、结构参数、成本估算、BOM清单和供应链数据。基本信息记录机器人型号、厂商、发布年份、产地、身高、体重、自由度和负载；结构参数会拆到腿部构型、关节布局、执行器方案；成本估算会给出单台物料成本区间、研发成本摊销，甚至不同量产规模下的成本变化；BOM清单则拆到子系统级，比如执行器、传感器、计算单元、结构件和电池；供应链数据最有意思，它会告诉你某台真机上用的关键物料来自哪些供应商或供应区域，并且以节点关系的形式组织，方便做可视化分析。我把五个模块的关键字段整理成了下面这张表：数据模块覆盖内容典型字段基本信息型号、厂商、发布年份、产地model_name, maker, year, country结构与参数身高、体重、自由度、负载、续航height, weight, dof, payload, endurance成本估算单台BOM成本、研发分摊、量产成本bom_cost, rnd_amortized, unit_costBOM清单子系统、部件、数量、参考供应商category, part_name, qty, supplier供应链数据关键物料供应节点、地域分布、关系链component, supplier, region, tier我第一次看完目录结构之后，第一个感受是：这事终于有人做了。之前我自己也尝试整理过类似表格，但数据源一多，口径就开始打架，最后根本推不下去。Atlas相当于把“数据收集、字段定义、汇总发布”这条链路直接开源出来，省掉了大量重复劳动。1.2 为什么这类数据以往很难拿到人形机器人行业有一个很明显的问题：信息极度分散，而且各说各话。有的厂商喜欢标峰值扭矩，有的标额定扭矩；有的自由度把灵巧手算进去，有的只算本体；成本方面，有的报的是研发样机成本，有的报的是目标量产成本，完全不在一个频道上。更麻烦的是，成本和BOM属于核心商业机密，厂商通常只给发布会上的宣传参数，拆机报告又覆盖不到所有型号，普通从业者想把某个赛道看明白，往往得花几周时间四处打听。供应链信息更是碎片化。减速器、电机、驱动器、芯片、传感器分布在完全不同的产业链里，你想从机械工程师的角度去摸清电气物料的价格，再从采购的角度去核对供应商交期，来回折腾几轮，效率极低。打个比方，这就好比有人把几十款车的“发动机型号、底盘配置、零部件采购价、供应商地图”全部摊在一张表上放到你面前。汽车行业有成熟的咨询报告，但人形机器人行业还在早期，公开资料很少，所以Atlas这类项目才显得稀缺。1.3 为什么放在Github而不是做成一个网站有人可能会问：做成网站不是更方便浏览吗？我的理解是，建站容易，维护难，而且很难建立信任。放到Github上，好处至少有三层。第一层是版本管理。每一次数据更新都有记录，哪条数据是哪个版本加的，哪个字段后来被修正过，全部可回溯。这个对工程研究太重要了，你拿到一份旧报告，至少能知道它对应哪个时间点的数据。第二层是协作机制。谁都可以提Issue、提PR，发现某个型号的参数错了，直接提交修改，维护者审核后合并。比起静态网站，这种社区纠错机制能让数据的存活率更高。第三层是格式透明。数据文件就是JSON、CSV，还有一堆解析脚本，所有人都能看到数据口径和处理过程，而不是一个黑盒后台。对做工程的人而言，可审计比漂亮界面重要得多。我甚至觉得，这个项目的核心不只是数据本身，而是把“收集、校验、发布”的流程也开放出来了。2. 四个核心数据维度：成本、结构、BOM与供应链2.1 成本数据：不是报价单，是估算区间先说成本这块。很多人拿到成本数据后，第一件事就是问“这个价格准不准”，这个问题本身就得拆开看。Atlas里的成本一般分为几个层级：BOM成本、研发成本摊销、制造成本和完全成本。BOM成本就是物料清单直接累加，决定整机的边际成本；研发成本摊销则是把研发投入分摊到每台机器上，量产数量越大，分摊越低；制造成本还包括装配、调试、测试、物流；完全成本再加售后和管理费用。开源数据覆盖较多的是BOM成本加研发摊销，越往量产端走，越依赖估算模型，误差也会变大。我从多个型号的BOM聚合来看，人形机器人的物料成本结构大致有这样一个规律：成本模块占比参考说明执行器（电机+减速器+驱动器）40%~60%自由度越多、性能越高，占比越大计算单元（工控机/边缘计算板）8%~15%包含AI算力硬件与散热传感系统（力/触觉/视觉/IMU）10%~18%六维力传感器往往很贵结构件（骨架/外壳/腿部结构）10%~18%铝合金机加工、碳纤维电池与电源5%~10%高能量密度电芯加上BMS其他（线束/接插件/散热/包装）5%~10%容易被低估的部分为什么执行器占比能到一半以上？因为人形机器人全身自由度通常在20到40个，每个关节都需要高力矩密度电机、高精度减速器、高带宽驱动器，这三样单独买都不便宜。哪怕平均每个关节执行器成本按千元级算，整机执行器成本也会迅速堆起来。看到这个数据，你就能理解为什么很多人形机器人公司都在死磕“关节一体化设计”，因为这是成本的大头，优化一个关节的成本，比优化十个结构件的效果都明显。2.2 结构数据：从构型判断技术路线结构数据这部分，外行看起来只是一堆三维模型和关节命名，实际上它非常能说明问题。我从数据库里读到的结构信息，主要围绕三个技术决策点。第一个是腿部构型。串联腿的调试资料多、控制方案成熟，但大腿小腿的惯性偏大；并联腿刚度高、抗冲击好，但结构复杂、校准麻烦；还有一些方案用线性执行器直接驱动，相当于把“肌肉”集成到腿部结构里，对机械加工精度要求很高。第二个是执行器方案。高减速比旋转执行器、线性执行器、准直驱低减速比方案，这三条的力控特性、能量效率、成本区间都不一样。准直驱方案对电机本体要求极高，但力控友好；高减速比方案更接近传统工业机器人思路，动态性能受限，但控制体系成熟。第三个是自由度分配。髋关节3个、膝关节1个、踝关节2个是比较常见的下肢配置，上肢和灵巧手的自由度差异很大。自由度越多，执行器越多，BOM成本越高，这是铁律。通过结构数据，你就能判断一个型号到底是“为了功能而堆自由度”，还是“为了量产而控制自由度”。我把几种常见技术路线的倾向整理了一下，方便大家参考：技术路线典型优点典型代价成本倾向串联腿+高减速比旋转执行器控制成熟，调试资料多惯性大，关节冲击大中等偏高并联腿+线性执行器刚度高，抗冲击好结构复杂，校准麻烦偏高准直驱/低减速比方案力控友好，能量回馈好对电机本体要求高中高液压驱动方案爆发力强系统复杂，维护成本高很高，多数不量产这不是数据库给出的绝对结论，而是我读结构数据时沉淀出的一般规律。真正有价值的是，当你把结构数据和成本数据放在一起看时，能看出一个型号的“钱花到哪里去了”。2.3 BOM清单：读懂它才能复现BOM清单是整个数据库里最容易被低估的部分。很多人看到长长的部件列表就头疼，其实BOM的正确打开方式不是逐行读，而是先分类聚合，再看成本大头。我综合多个公开拆解信息和Atlas数据库的BOM结构，整理了一个简化示例，方便大家理解它的信息密度：系统部件数量单件成本参考备注执行器髋关节旋转电驱执行器23000~5000元含电机、减速器、驱动器执行器膝关节线性执行器24000~6000元丝杠/连杆结构执行器腕部紧凑执行器21200~2500元尺寸限制驱动成本高计算边缘AI计算板16000~12000元含算力模组与散热传感六维力/力矩传感器41500~4000元腕部与踝部传感深度相机2800~2000元视觉导航与感知结构铝合金骨架+碳纤维覆盖件1套5000~10000元视定制加工程度电池高倍率锂电池组1组2000~4000元含BMS与线束需要注意，这张表只是示例，不完全对应某个具体型号。真实的BOM文件里，字段会更细，甚至直接给出supplier或supplier_region。分析BOM时，我建议关注三个点：第一，是否包含研发类物料，有些BOM把仿真夹具、调试工具也算进去了；第二，单价对应的采购量级是样品价还是批量价，这直接影响估算结果；第三，看版本日期，BOM是时点快照，芯片价格和铝价一变，整个表就过时了。2.4 真机供应链可视化数据：谁在供应什么供应链数据是Atlas里最有特色的部分。所谓“真机供应链”，指的是真实原型机或小批量量产机上能追溯到的物料来源，不是PPT里的规划。数据库里的供应链图通常有三类节点：机器人型号、子系统或物料、供应商或供应区域。节点之间的边就是“某型号使用某物料”“某物料由某供应商供应”“某供应商位于某区域”。这个图能做的事情很多。比如，你可以快速看到全球人形机器人的供应链分布，知道哪些物料存在高度集中风险；也可以看到哪些供应商同时覆盖多家机器人型号，判断它在产业链里的卡位。如果某个核心运动控制部件在多个型号里都来自同一个供应区域，那么在自研规划时，就要认真考虑备选方案了。供应链可视化数据的局限也需要提前说明。开源仓库里的图节点，很多是脱敏后的区域级信息，而不是具体到某家厂商。官方不会把真实的独家供应关系放出来，所以要把它当“寻源地图”而不是“采购名录”。但即便如此，它仍然能提供很好的产业洞察，尤其是当你把供应链数据与BOM成本做交叉时，能看出哪些物料是全球范围内的硬通货。3. 实操：把仓库数据变成自己可用的情报3.1 克隆仓库、看清目录结构实操部分我直接讲怎么上手。第一步，把仓库克隆到本地。具体地址以项目主页为准，我建议你直接在Github搜索“Atlas humanoid robot database”，不用背死链接，因为仓库地址有迁移风险。git clone <仓库地址>我拉下来之后看到的典型目录结构大致是这样：data/ robots/ index.json 某型号.json bom/ 某型号.json costs/ cost_summary.csv supply_chain/ graph.json suppliers.csv docs/ schema.md scripts/ parse_bom.py merge_cost.py CONTRIBUTING.md LICENSE README.md拿到仓库之后，我的习惯是先看README和docs/schema.md，搞清楚字段定义，再跑一遍scripts里的解析脚本，最后才动数据。很多人上来就直接读JSON，结果对“unit_cost到底含不含税”这种问题毫无概念，分析半天方向错了。3.2 用Pandas快速解析机器人与BOM数据第二步，用Python把数据读成DataFrame。以我常用的方式为例，先读机器人索引文件：import pandas as pd robots = pd.read_json("data/robots/index.json") print(robots.columns.tolist()) print(robots.head(3))然后批量读取BOM文件：import json from pathlib import Path bom_dir = Path("data/bom") parts = [] for f in bom_dir.glob("*.json"): data = json.loads(f.read_text(encoding="utf-8")) for item in data.get("bom", []): parts.append({"model": data.get("model_id"), **item}) bom_df = pd.DataFrame(parts) print(bom_df.head())如果仓库给的是CSV，直接pd.read_csv会更省事。核心技巧是：先打印列名，再分析数据。然后做一次成本聚合，把整个BOM的物料按系统分类归并：cost_by_category = bom_df.groupby("category")["unit_cost"].agg(["sum", "count"]) print(cost_by_category.sort_values("sum", ascending=False))为什么要先按category聚合？因为人形机器人的BOM往往有上百条明细，逐行看很容易迷失方向。先聚合找出大头，再针对重点子类展开看，才是有效率的读法。3.3 用成本数据做方案选型对比我平时做方案预研，最喜欢干的一件事是把不同型号的成本数据拉到一个透视表里对比：pivot = bom_df.pivot_table( index="model", columns="category", values="unit_cost", aggfunc="sum" ) pivot["total"] = pivot.sum(axis=1) print(pivot.sort_values("total"))这样能直接看出每个型号的总成本构成，以及不同类目之间的差异。实际情况里，两个型号的总成本可能很接近，但一个执行器占比高，一个结构件占比高，这说明它们走的技术路线完全不同。一个更接近量产状态的型号，往往在执行器和传感器选型上更依赖成熟货架产品，而不是大量定制件。如果数据量足够，我还会做一版简单的自由度与成本回归分析，用少量脚本估算“自己想做的新方案大概需要多少物料成本”。当然，这只是一个量级测算，不能替代详细设计，但它能把“拍脑袋”变成“可引用的估算”，在立项讨论时非常有用。3.4 把供应链图数据导成可视化关系图供应链数据如果以node-link格式存放，可以直接用网络分析工具读进去：import networkx as nx import json graph = json.load(open("data/supply_chain/graph.json", encoding="utf-8")) G = nx.node_link_graph(graph) print(len(G.nodes), len(G.edges))然后把图结构写成GraphML，丢进开源可视化工具里看：nx.write_graphml(G, "supply_chain.graphml")这种做法的价值在于，供应商节点如果连接到多个人形机器人型号，那么它在图里的“入度”就会明显偏高，意味着它在产业链里有较高的通用性。如果某类物料只有单一来源，那它在图中就是一个明显的“瓶颈节点”。如果你不想用专门的图工具，也可以用Pandas做区域聚合。比如把供应链表按“区域、部件类型”分组，看一眼哪个区域在哪类关键物料上集中度高：suppliers = pd.read_csv("data/supply_chain/suppliers.csv") region_pivot = suppliers.groupby(["region", "component_type"]).size().reset_index(name="count") print(region_pivot.sort_values("count", ascending=False))实操中我建议先用脚本把节点统计跑出来，再上重工具做图，这样不容易被可视化效果带偏。3.5 建立自己的私有扩展信息最后一条实操建议：不要直接改主仓库的数据文件。我会建议你fork一份，在本地增加local_quote、lead_time、risk_level这类自定义字段，用来整合自己询价得来的真实数据。公开库的价值是提供一个基础坐标系，而你自己的采购经验和供应商反馈才是真正能落地的信息。如果上游仓库有更新，我会定期把本地分支和上游同步，避免数据偏移越来越大。这一步很关键，因为机器人行业物料价格变化极快，三个月不更新，成本估算就失真了。4. 用之前必读：常见问题与避坑指南4.1 数据可信度：先分清“实测”还是“估算”任何开源数据库，第一个要问的问题就是：这些数据是从哪来的。Atlas里的数据来源大致有几类：厂商官网与发布会披露、论文与技术报告、公开拆机报告、社区贡献者根据访谈和询价整理的信息。不同来源的可信度差别很大，我更相信官方披露和拆机报告，二手转述一定要再核验一遍。使用时有个习惯可以养起来：先把每条数据的来源字段拉出来看一眼，如果某条数据只有一个来源，就把它当成“待验证参考”。做横向对比时，我会给不同来源设置不同的置信度权重，比如官方披露权重1.0，社区整理权重0.6，这样汇总出来的结论会稳很多。4.2 汇率、单位与口径陷阱这是最容易翻车的地方。数据库里不同型号可能来自不同国家，成本有的标美元，有的标人民币，还有的标欧元；有的价格含税，有的不含税；有的把物流和组装算进去了，有的只算物料。年份差异也很大，不同时期的芯片价格、铝合金价格、汇率都会影响结果。所以在做对比前，一定要先做单位统一。我通常会写一个小脚本，把所有成本字段统一换算成同一货币和同一口径：bom_df["unit_cost_usd"] = bom_df.apply( lambda r: r["unit_cost"] / rate_map.get(r.get("currency", "USD"), 1), axis=1 )不夸张地说，很多人在这一步省事，结果图表做出来很漂亮，但结论完全不可靠。统一口径后再分析，永远是最优先的操作。4.3 供应链可视化数据的滞后与脱敏问题供应链数据本质上是“快照”，它反映的是某个时间点的物料来源关系。但供应链是流动的，一家供应商可能三个月后就换了，某个芯片可能一年内完成两次替代。所以读图的时候不要过度解读：节点多不代表重要，要看它的不可替代性和切换成本，这些在开源数据里不一定能看出来。另外，脱敏问题也要心里有数。很多敏感供应商在公开数据里会被替换成“某区域厂商”，你能看到的是区域级依赖关系，而不是具体公司名。因此在做供应商寻源时，公开图只能帮你锁定“该往哪个方向找”，不能帮你直接找到答案。4.4 开源许可证与商用边界很多搞技术的人只看代码不看License，这一点在机器人行业尤其要警惕。Atlas仓库的许可证不同，使用边界也不同：有的允许商用但要署名，有的代码部分强制开源，有的数据部分只允许非商用。这不是形式问题，而是真实的合规风险。我的建议很直接：如果你只是在个人项目里做研究，问题不大；但如果是公司内部报告、招标方案或研报引用，一定要在文档里标注“数据来源：Atlas开源数据库，许可证为XX”。商用之前，最好让法务确认一遍。数据不是免费的，只是开源不等于免费商用。5. 这个开源项目对行业的影响与后续玩法5.1 人形机器人研发：把预研周期从论月变成论天在没有这种数据库之前，我做方案预研的流程是：搜资料一周、整理对比一周、和供应商初步接触两周，一个月下来可能还没到立项阶段。有了Atlas这种数据库，两天时间就能把几个型号的参数、BOM和成本批量拉出来，直接进入实质性的方案评估。比如评估“做一台1.6米左右、25自由度人形机器人的整机物料成本”，可以先筛数据库里相近型号，看平均自由度和成本的关系，建立一版粗略的回归模型，给出一个量级，再根据自己打算采用准直驱还是高减速比方案去做修正。整个过程大概一个下午就能完成。这不代表它能替代详细设计，但能把“拍脑袋”变成“可引用的估算”，在决策时意义很大。5.2 采购与供应链：把数据库当寻源清单供应链视角下，这类数据库也很有用。你可以看到同行在大量用哪类部件，发现哪里有国产替代空间，甚至在做采购谈判时有一个基准价参照。如果数据库显示某个执行器类目在多个型号里都被列为关键成本项，那说明这个品类的市场供给相对成熟，值得重点去约供应商聊。采购人员拿到BOM之后，还可以做“同类物料跨型号汇总”，把多个机器人共用的部件类目合并，放大采购量优势。这属于典型的数据化采购思路，也是Atlas这类项目给行业带来的额外价值。5.3 产业研究和投研：用统一口径看全球格局做产业研究的人，最痛苦的不是缺资料，而是资料口径五花八门。Atlas至少提供了一个可以被引用和校验的统一坐标系，分析师可以把几十个型号放在同样的字段框架下看，比一篇篇读发布会新闻有效得多。后续还可以基于它做很多深度分析，比如“人形机器人成本随量产规模变化的曲线”“不同技术路线的执行器成本占比分布”“全球人形机器人供应链集中度分析”。这些在以前都是很难从公开渠道得到的，现在至少有了一个起点。5.4 你可以参与共建的几个方向开源数据库最需要的是持续贡献。如果你看到了新的机器人型号发布，可以按schema提交一份JSON；如果你有真实的拆机信息或供应商数据，可以提交PR修正过时的BOM；如果你擅长做分析工具，可以写一键导出Excel、PDF报告的工具脚本；如果你在做多语言社区，可以帮忙翻译文档，降低使用门槛。我给所有想参与的人一个建议：先从小条目开始，别一上来就改大结构。提PR之前，明确说明你的数据来源和修改理由，维护者审核起来也快。社区共建这件事，靠的不是一次性的大贡献，而是持续的小修正。我个人在实际操作中最直观的感受是：Atlas数据库最有价值的不是某一个精确数字，而是它提供了一个统一的人形机器人“成本坐标系”。以前我评估不同方案时，总要把各种口径的数据放进Excel手工对齐，经常对到一半就乱了。现在直接跑一遍脚本，就能得到相对一致的对比结果，整个分析链路顺畅很多。最后再提醒一句，任何公开数据库都不能替代真实的供应商询价，但做早期方案筛选和行业研究，它的性价比已经非常高了。后续我会继续盯这个仓库的更新，也会把自己整理的一些本地分析脚本陆续发出来，感兴趣的朋友可以一起交流。
做机器人这些年，我最烦的一件事就是信息差。想评估一款人形机器人的方案，要翻官网、找论文、找供应链朋友打听价格，最后凑出来的数据口径还不一致，根本没法横向比。所以当“全球人形机器人数据库Atlas”在Github开源的消息传出来时，我第一时间就去仓库里翻了个遍。它做的事情很直接：把全球多款人形机器人的基本参数、结构构型、BOM清单、成本估算和真机供应链数据全部结构化地收进一个库，对外开放、可复用、可参与维护。对机器人架构师、硬件工程师、采购人员和产业研究来说，这东西的价值不亚于一本行业白皮书。注意，这里的Atlas是数据库项目名，不是某款具体的机器人产品，别理解错了。这篇文章我会按“数据底细、核心维度、实操方法、避坑指南、行业影响”的顺序讲，尽量说得细一点。1. 先把这个开源项目的底细摸清楚1.1 数据库里究竟装了什么Atlas数据库不是简单的Excel表格，它更像一套多模块数据集。我拉下来以后，看到数据主要有五块：基本信息、结构参数、成本估算、BOM清单和供应链数据。基本信息记录机器人型号、厂商、发布年份、产地、身高、体重、自由度和负载；结构参数会拆到腿部构型、关节布局、执行器方案；成本估算会给出单台物料成本区间、研发成本摊销，甚至不同量产规模下的成本变化；BOM清单则拆到子系统级，比如执行器、传感器、计算单元、结构件和电池；供应链数据最有意思，它会告诉你某台真机上用的关键物料来自哪些供应商或供应区域，并且以节点关系的形式组织，方便做可视化分析。我把五个模块的关键字段整理成了下面这张表：数据模块覆盖内容典型字段基本信息型号、厂商、发布年份、产地model_name, maker, year, country结构与参数身高、体重、自由度、负载、续航height, weight, dof, payload, endurance成本估算单台BOM成本、研发分摊、量产成本bom_cost, rnd_amortized, unit_costBOM清单子系统、部件、数量、参考供应商category, part_name, qty, supplier供应链数据关键物料供应节点、地域分布、关系链component, supplier, region, tier我第一次看完目录结构之后，第一个感受是：这事终于有人做了。之前我自己也尝试整理过类似表格，但数据源一多，口径就开始打架，最后根本推不下去。Atlas相当于把“数据收集、字段定义、汇总发布”这条链路直接开源出来，省掉了大量重复劳动。1.2 为什么这类数据以往很难拿到人形机器人行业有一个很明显的问题：信息极度分散，而且各说各话。有的厂商喜欢标峰值扭矩，有的标额定扭矩；有的自由度把灵巧手算进去，有的只算本体；成本方面，有的报的是研发样机成本，有的报的是目标量产成本，完全不在一个频道上。更麻烦的是，成本和BOM属于核心商业机密，厂商通常只给发布会上的宣传参数，拆机报告又覆盖不到所有型号，普通从业者想把某个赛道看明白，往往得花几周时间四处打听。供应链信息更是碎片化。减速器、电机、驱动器、芯片、传感器分布在完全不同的产业链里，你想从机械工程师的角度去摸清电气物料的价格，再从采购的角度去核对供应商交期，来回折腾几轮，效率极低。打个比方，这就好比有人把几十款车的“发动机型号、底盘配置、零部件采购价、供应商地图”全部摊在一张表上放到你面前。汽车行业有成熟的咨询报告，但人形机器人行业还在早期，公开资料很少，所以Atlas这类项目才显得稀缺。1.3 为什么放在Github而不是做成一个网站有人可能会问：做成网站不是更方便浏览吗？我的理解是，建站容易，维护难，而且很难建立信任。放到Github上，好处至少有三层。第一层是版本管理。每一次数据更新都有记录，哪条数据是哪个版本加的，哪个字段后来被修正过，全部可回溯。这个对工程研究太重要了，你拿到一份旧报告，至少能知道它对应哪个时间点的数据。第二层是协作机制。谁都可以提Issue、提PR，发现某个型号的参数错了，直接提交修改，维护者审核后合并。比起静态网站，这种社区纠错机制能让数据的存活率更高。第三层是格式透明。数据文件就是JSON、CSV，还有一堆解析脚本，所有人都能看到数据口径和处理过程，而不是一个黑盒后台。对做工程的人而言，可审计比漂亮界面重要得多。我甚至觉得，这个项目的核心不只是数据本身，而是把“收集、校验、发布”的流程也开放出来了。2. 四个核心数据维度：成本、结构、BOM与供应链2.1 成本数据：不是报价单，是估算区间先说成本这块。很多人拿到成本数据后，第一件事就是问“这个价格准不准”，这个问题本身就得拆开看。Atlas里的成本一般分为几个层级：BOM成本、研发成本摊销、制造成本和完全成本。BOM成本就是物料清单直接累加，决定整机的边际成本；研发成本摊销则是把研发投入分摊到每台机器上，量产数量越大，分摊越低；制造成本还包括装配、调试、测试、物流；完全成本再加售后和管理费用。开源数据覆盖较多的是BOM成本加研发摊销，越往量产端走，越依赖估算模型，误差也会变大。我从多个型号的BOM聚合来看，人形机器人的物料成本结构大致有这样一个规律：成本模块占比参考说明执行器（电机+减速器+驱动器）40%~60%自由度越多、性能越高，占比越大计算单元（工控机/边缘计算板）8%~15%包含AI算力硬件与散热传感系统（力/触觉/视觉/IMU）10%~18%六维力传感器往往很贵结构件（骨架/外壳/腿部结构）10%~18%铝合金机加工、碳纤维电池与电源5%~10%高能量密度电芯加上BMS其他（线束/接插件/散热/包装）5%~10%容易被低估的部分为什么执行器占比能到一半以上？因为人形机器人全身自由度通常在20到40个，每个关节都需要高力矩密度电机、高精度减速器、高带宽驱动器，这三样单独买都不便宜。哪怕平均每个关节执行器成本按千元级算，整机执行器成本也会迅速堆起来。看到这个数据，你就能理解为什么很多人形机器人公司都在死磕“关节一体化设计”，因为这是成本的大头，优化一个关节的成本，比优化十个结构件的效果都明显。2.2 结构数据：从构型判断技术路线结构数据这部分，外行看起来只是一堆三维模型和关节命名，实际上它非常能说明问题。我从数据库里读到的结构信息，主要围绕三个技术决策点。第一个是腿部构型。串联腿的调试资料多、控制方案成熟，但大腿小腿的惯性偏大；并联腿刚度高、抗冲击好，但结构复杂、校准麻烦；还有一些方案用线性执行器直接驱动，相当于把“肌肉”集成到腿部结构里，对机械加工精度要求很高。第二个是执行器方案。高减速比旋转执行器、线性执行器、准直驱低减速比方案，这三条的力控特性、能量效率、成本区间都不一样。准直驱方案对电机本体要求极高，但力控友好；高减速比方案更接近传统工业机器人思路，动态性能受限，但控制体系成熟。第三个是自由度分配。髋关节3个、膝关节1个、踝关节2个是比较常见的下肢配置，上肢和灵巧手的自由度差异很大。自由度越多，执行器越多，BOM成本越高，这是铁律。通过结构数据，你就能判断一个型号到底是“为了功能而堆自由度”，还是“为了量产而控制自由度”。我把几种常见技术路线的倾向整理了一下，方便大家参考：技术路线典型优点典型代价成本倾向串联腿+高减速比旋转执行器控制成熟，调试资料多惯性大，关节冲击大中等偏高并联腿+线性执行器刚度高，抗冲击好结构复杂，校准麻烦偏高准直驱/低减速比方案力控友好，能量回馈好对电机本体要求高中高液压驱动方案爆发力强系统复杂，维护成本高很高，多数不量产这不是数据库给出的绝对结论，而是我读结构数据时沉淀出的一般规律。真正有价值的是，当你把结构数据和成本数据放在一起看时，能看出一个型号的“钱花到哪里去了”。2.3 BOM清单：读懂它才能复现BOM清单是整个数据库里最容易被低估的部分。很多人看到长长的部件列表就头疼，其实BOM的正确打开方式不是逐行读，而是先分类聚合，再看成本大头。我综合多个公开拆解信息和Atlas数据库的BOM结构，整理了一个简化示例，方便大家理解它的信息密度：系统部件数量单件成本参考备注执行器髋关节旋转电驱执行器23000~5000元含电机、减速器、驱动器执行器膝关节线性执行器24000~6000元丝杠/连杆结构执行器腕部紧凑执行器21200~2500元尺寸限制驱动成本高计算边缘AI计算板16000~12000元含算力模组与散热传感六维力/力矩传感器41500~4000元腕部与踝部传感深度相机2800~2000元视觉导航与感知结构铝合金骨架+碳纤维覆盖件1套5000~10000元视定制加工程度电池高倍率锂电池组1组2000~4000元含BMS与线束需要注意，这张表只是示例，不完全对应某个具体型号。真实的BOM文件里，字段会更细，甚至直接给出supplier或supplier_region。分析BOM时，我建议关注三个点：第一，是否包含研发类物料，有些BOM把仿真夹具、调试工具也算进去了；第二，单价对应的采购量级是样品价还是批量价，这直接影响估算结果；第三，看版本日期，BOM是时点快照，芯片价格和铝价一变，整个表就过时了。2.4 真机供应链可视化数据：谁在供应什么供应链数据是Atlas里最有特色的部分。所谓“真机供应链”，指的是真实原型机或小批量量产机上能追溯到的物料来源，不是PPT里的规划。数据库里的供应链图通常有三类节点：机器人型号、子系统或物料、供应商或供应区域。节点之间的边就是“某型号使用某物料”“某物料由某供应商供应”“某供应商位于某区域”。这个图能做的事情很多。比如，你可以快速看到全球人形机器人的供应链分布，知道哪些物料存在高度集中风险；也可以看到哪些供应商同时覆盖多家机器人型号，判断它在产业链里的卡位。如果某个核心运动控制部件在多个型号里都来自同一个供应区域，那么在自研规划时，就要认真考虑备选方案了。供应链可视化数据的局限也需要提前说明。开源仓库里的图节点，很多是脱敏后的区域级信息，而不是具体到某家厂商。官方不会把真实的独家供应关系放出来，所以要把它当“寻源地图”而不是“采购名录”。但即便如此，它仍然能提供很好的产业洞察，尤其是当你把供应链数据与BOM成本做交叉时，能看出哪些物料是全球范围内的硬通货。3. 实操：把仓库数据变成自己可用的情报3.1 克隆仓库、看清目录结构实操部分我直接讲怎么上手。第一步，把仓库克隆到本地。具体地址以项目主页为准，我建议你直接在Github搜索“Atlas humanoid robot database”，不用背死链接，因为仓库地址有迁移风险。git clone <仓库地址>我拉下来之后看到的典型目录结构大致是这样：data/ robots/ index.json 某型号.json bom/ 某型号.json costs/ cost_summary.csv supply_chain/ graph.json suppliers.csv docs/ schema.md scripts/ parse_bom.py merge_cost.py CONTRIBUTING.md LICENSE README.md拿到仓库之后，我的习惯是先看README和docs/schema.md，搞清楚字段定义，再跑一遍scripts里的解析脚本，最后才动数据。很多人上来就直接读JSON，结果对“unit_cost到底含不含税”这种问题毫无概念，分析半天方向错了。3.2 用Pandas快速解析机器人与BOM数据第二步，用Python把数据读成DataFrame。以我常用的方式为例，先读机器人索引文件：import pandas as pd robots = pd.read_json("data/robots/index.json") print(robots.columns.tolist()) print(robots.head(3))然后批量读取BOM文件：import json from pathlib import Path bom_dir = Path("data/bom") parts = [] for f in bom_dir.glob("*.json"): data = json.loads(f.read_text(encoding="utf-8")) for item in data.get("bom", []): parts.append({"model": data.get("model_id"), **item}) bom_df = pd.DataFrame(parts) print(bom_df.head())如果仓库给的是CSV，直接pd.read_csv会更省事。核心技巧是：先打印列名，再分析数据。然后做一次成本聚合，把整个BOM的物料按系统分类归并：cost_by_category = bom_df.groupby("category")["unit_cost"].agg(["sum", "count"]) print(cost_by_category.sort_values("sum", ascending=False))为什么要先按category聚合？因为人形机器人的BOM往往有上百条明细，逐行看很容易迷失方向。先聚合找出大头，再针对重点子类展开看，才是有效率的读法。3.3 用成本数据做方案选型对比我平时做方案预研，最喜欢干的一件事是把不同型号的成本数据拉到一个透视表里对比：pivot = bom_df.pivot_table( index="model", columns="category", values="unit_cost", aggfunc="sum" ) pivot["total"] = pivot.sum(axis=1) print(pivot.sort_values("total"))这样能直接看出每个型号的总成本构成，以及不同类目之间的差异。实际情况里，两个型号的总成本可能很接近，但一个执行器占比高，一个结构件占比高，这说明它们走的技术路线完全不同。一个更接近量产状态的型号，往往在执行器和传感器选型上更依赖成熟货架产品，而不是大量定制件。如果数据量足够，我还会做一版简单的自由度与成本回归分析，用少量脚本估算“自己想做的新方案大概需要多少物料成本”。当然，这只是一个量级测算，不能替代详细设计，但它能把“拍脑袋”变成“可引用的估算”，在立项讨论时非常有用。3.4 把供应链图数据导成可视化关系图供应链数据如果以node-link格式存放，可以直接用网络分析工具读进去：import networkx as nx import json graph = json.load(open("data/supply_chain/graph.json", encoding="utf-8")) G = nx.node_link_graph(graph) print(len(G.nodes), len(G.edges))然后把图结构写成GraphML，丢进开源可视化工具里看：nx.write_graphml(G, "supply_chain.graphml")这种做法的价值在于，供应商节点如果连接到多个人形机器人型号，那么它在图里的“入度”就会明显偏高，意味着它在产业链里有较高的通用性。如果某类物料只有单一来源，那它在图中就是一个明显的“瓶颈节点”。如果你不想用专门的图工具，也可以用Pandas做区域聚合。比如把供应链表按“区域、部件类型”分组，看一眼哪个区域在哪类关键物料上集中度高：suppliers = pd.read_csv("data/supply_chain/suppliers.csv") region_pivot = suppliers.groupby(["region", "component_type"]).size().reset_index(name="count") print(region_pivot.sort_values("count", ascending=False))实操中我建议先用脚本把节点统计跑出来，再上重工具做图，这样不容易被可视化效果带偏。3.5 建立自己的私有扩展信息最后一条实操建议：不要直接改主仓库的数据文件。我会建议你fork一份，在本地增加local_quote、lead_time、risk_level这类自定义字段，用来整合自己询价得来的真实数据。公开库的价值是提供一个基础坐标系，而你自己的采购经验和供应商反馈才是真正能落地的信息。如果上游仓库有更新，我会定期把本地分支和上游同步，避免数据偏移越来越大。这一步很关键，因为机器人行业物料价格变化极快，三个月不更新，成本估算就失真了。4. 用之前必读：常见问题与避坑指南4.1 数据可信度：先分清“实测”还是“估算”任何开源数据库，第一个要问的问题就是：这些数据是从哪来的。Atlas里的数据来源大致有几类：厂商官网与发布会披露、论文与技术报告、公开拆机报告、社区贡献者根据访谈和询价整理的信息。不同来源的可信度差别很大，我更相信官方披露和拆机报告，二手转述一定要再核验一遍。使用时有个习惯可以养起来：先把每条数据的来源字段拉出来看一眼，如果某条数据只有一个来源，就把它当成“待验证参考”。做横向对比时，我会给不同来源设置不同的置信度权重，比如官方披露权重1.0，社区整理权重0.6，这样汇总出来的结论会稳很多。4.2 汇率、单位与口径陷阱这是最容易翻车的地方。数据库里不同型号可能来自不同国家，成本有的标美元，有的标人民币，还有的标欧元；有的价格含税，有的不含税；有的把物流和组装算进去了，有的只算物料。年份差异也很大，不同时期的芯片价格、铝合金价格、汇率都会影响结果。所以在做对比前，一定要先做单位统一。我通常会写一个小脚本，把所有成本字段统一换算成同一货币和同一口径：bom_df["unit_cost_usd"] = bom_df.apply( lambda r: r["unit_cost"] / rate_map.get(r.get("currency", "USD"), 1), axis=1 )不夸张地说，很多人在这一步省事，结果图表做出来很漂亮，但结论完全不可靠。统一口径后再分析，永远是最优先的操作。4.3 供应链可视化数据的滞后与脱敏问题供应链数据本质上是“快照”，它反映的是某个时间点的物料来源关系。但供应链是流动的，一家供应商可能三个月后就换了，某个芯片可能一年内完成两次替代。所以读图的时候不要过度解读：节点多不代表重要，要看它的不可替代性和切换成本，这些在开源数据里不一定能看出来。另外，脱敏问题也要心里有数。很多敏感供应商在公开数据里会被替换成“某区域厂商”，你能看到的是区域级依赖关系，而不是具体公司名。因此在做供应商寻源时，公开图只能帮你锁定“该往哪个方向找”，不能帮你直接找到答案。4.4 开源许可证与商用边界很多搞技术的人只看代码不看License，这一点在机器人行业尤其要警惕。Atlas仓库的许可证不同，使用边界也不同：有的允许商用但要署名，有的代码部分强制开源，有的数据部分只允许非商用。这不是形式问题，而是真实的合规风险。我的建议很直接：如果你只是在个人项目里做研究，问题不大；但如果是公司内部报告、招标方案或研报引用，一定要在文档里标注“数据来源：Atlas开源数据库，许可证为XX”。商用之前，最好让法务确认一遍。数据不是免费的，只是开源不等于免费商用。5. 这个开源项目对行业的影响与后续玩法5.1 人形机器人研发：把预研周期从论月变成论天在没有这种数据库之前，我做方案预研的流程是：搜资料一周、整理对比一周、和供应商初步接触两周，一个月下来可能还没到立项阶段。有了Atlas这种数据库，两天时间就能把几个型号的参数、BOM和成本批量拉出来，直接进入实质性的方案评估。比如评估“做一台1.6米左右、25自由度人形机器人的整机物料成本”，可以先筛数据库里相近型号，看平均自由度和成本的关系，建立一版粗略的回归模型，给出一个量级，再根据自己打算采用准直驱还是高减速比方案去做修正。整个过程大概一个下午就能完成。这不代表它能替代详细设计，但能把“拍脑袋”变成“可引用的估算”，在决策时意义很大。5.2 采购与供应链：把数据库当寻源清单供应链视角下，这类数据库也很有用。你可以看到同行在大量用哪类部件，发现哪里有国产替代空间，甚至在做采购谈判时有一个基准价参照。如果数据库显示某个执行器类目在多个型号里都被列为关键成本项，那说明这个品类的市场供给相对成熟，值得重点去约供应商聊。采购人员拿到BOM之后，还可以做“同类物料跨型号汇总”，把多个机器人共用的部件类目合并，放大采购量优势。这属于典型的数据化采购思路，也是Atlas这类项目给行业带来的额外价值。5.3 产业研究和投研：用统一口径看全球格局做产业研究的人，最痛苦的不是缺资料，而是资料口径五花八门。Atlas至少提供了一个可以被引用和校验的统一坐标系，分析师可以把几十个型号放在同样的字段框架下看，比一篇篇读发布会新闻有效得多。后续还可以基于它做很多深度分析，比如“人形机器人成本随量产规模变化的曲线”“不同技术路线的执行器成本占比分布”“全球人形机器人供应链集中度分析”。这些在以前都是很难从公开渠道得到的，现在至少有了一个起点。5.4 你可以参与共建的几个方向开源数据库最需要的是持续贡献。如果你看到了新的机器人型号发布，可以按schema提交一份JSON；如果你有真实的拆机信息或供应商数据，可以提交PR修正过时的BOM；如果你擅长做分析工具，可以写一键导出Excel、PDF报告的工具脚本；如果你在做多语言社区，可以帮忙翻译文档，降低使用门槛。我给所有想参与的人一个建议：先从小条目开始，别一上来就改大结构。提PR之前，明确说明你的数据来源和修改理由，维护者审核起来也快。社区共建这件事，靠的不是一次性的大贡献，而是持续的小修正。我个人在实际操作中最直观的感受是：Atlas数据库最有价值的不是某一个精确数字，而是它提供了一个统一的人形机器人“成本坐标系”。以前我评估不同方案时，总要把各种口径的数据放进Excel手工对齐，经常对到一半就乱了。现在直接跑一遍脚本，就能得到相对一致的对比结果，整个分析链路顺畅很多。最后再提醒一句，任何公开数据库都不能替代真实的供应商询价，但做早期方案筛选和行业研究，它的性价比已经非常高了。后续我会继续盯这个仓库的更新，也会把自己整理的一些本地分析脚本陆续发出来，感兴趣的朋友可以一起交流。