RoboParty在10月3日进一步介绍了双足人形机器人RP1（ROBOTO 01）。这台机器此前于9月28日在IROS 2026公开亮相。“全栈开源”听着很响亮。实验室拿到一台机器，先要弄清楚能自己修到哪一层。RoboParty列出的范围包含RPO开源本体、Romomo执行器模块、RP Hand灵巧手以及PartyOS。PartyOS涉及双足运动、感知交互、全身操作和自主智能。团队表示10月还将公布开源路线，并计划在第四季度推进更广泛的软硬件发布和量产计划。这些是目前可据以讨论的项目边界；尚未公布的细节不能当作已经交付的能力。
下载代码以后，机器人还能不能做出来
机器人研究里常说“复现”，可复现不是在一台预先调好的设备上跑通示例。整机结构决定质量分布和关节行程，执行器决定可实现的力矩与速度范围，手部结构决定抓取对象与接触方式；传感器安装位置、时间同步与标定，又会影响状态估计。即使两组实验使用同一份上层策略，只要底层机械和驱动条件不同，运行结果就不适合直接比较。
RP1的项目表述至少把问题摆在了整机层面。它以今年1月开源的RPO（ROBOTO ORIGIN）为基础。项目方称，RPO已获得2500多个GitHub Star。Star说明有人收藏了项目。外部团队到底装出了几台机器、能否独立跑起来，还得看复现记录。后续判断要看图纸、零件清单、装配说明、接口定义、驱动代码与标定流程是否能串成连续链路。缺少其中一段，开发者仍然需要自行逆向或重新设计。
工程团队通常会先做一张复现表：哪些零件能按公开规格采购，哪些需要加工；机械公差如何表达；线束、供电、紧急停止与维护通道在图纸里有没有交代。对于双足平台，还得知道质心和关节零位怎样校准。开放CAD文件只解决“形状是什么”，加工、装配和验收方法决定另一台机器能否按相同方式工作。这是一条评估路径，不是对RP1当前文档完备程度的断言。
Romomo模块：同一个关节接口，有没有可重复的行为
执行器常被写成型号和峰值参数，而现场调试最怕“同型号、不同表现”。关节控制需要知道命令单位、采样周期、通信延迟、编码器零点、过流与过温处理，以及制动和断电状态。做步态实验时，如果角度环与力矩环的切换条件不清楚，策略在一台机器上能跑，换另一台机器可能只能重新调参。
RoboParty把Romomo执行器列在RP1开发栈里，提供了明确的审视对象。后续可以重点查两类资料。其一是电气和通信接口：实际可下发什么命令，状态回传包含哪些字段，故障码如何定义。其二是控制约束：接近限位、受到外力、温度变化或供电波动时，关节会按什么规则退让、停止或恢复。团队若公开了这些资料，外部研究者才好把算法问题与机电问题分开排查；如果只有理想工况的动作视频，复现成本仍难估计。
这里还涉及一个容易被忽略的责任划分。策略模型可以输出动作意图，但关节的安全限制必须留在执行端可验证的控制环节。试验台上的限幅、机械止挡、急停和日志，不该由大模型的提示词承担。对于准备将RP1用于实验的人，先把故障工况写成测试用例，比急着跑复杂任务更实际。
RP Hand与全身操作：抓住物体不等于完成任务
RP Hand让RP1的公开范围延伸到手部。灵巧手有多少自由度是一项参数；能否服务研究，还得看开发者还需要知道各指关节的映射、闭环反馈和接触状态如何提供给上层系统。实际抓取时，物体尺寸、摩擦、指尖接触位置都在变化。手能闭合，只说明驱动链完成一个动作；能否在取放过程中稳定保持物体，并在滑移时及时调整，是另一个问题。
手臂、躯干和双腿同时参与操作时，控制条件更苛刻。机器人伸手够物，会改变质心投影；搬运一个物体，负载和惯量也随之改变。PartyOS被描述为覆盖全身操作与双足运动，所以外部开发者尤其需要弄清楚：手部任务发起后，身体平衡由谁维护？手、足之间是否有统一的状态表示？动作被中断时，各模块如何回到安全状态？这些问题目前应当作为核对资料的清单，不能由“全栈”两个字自动作答。
做研究项目可以从小物体取放开始，把成功标准写清：初始物体位置允许多大偏差，是否容许机器人先调整站姿，抓取失败如何重新尝试。若没有这些边界，同一段“演示成功”的视频很难与后续实验结果对照。对开放平台而言，能共享失败样例和恢复步骤，往往比单条漂亮动作更有用。
展台上的外力测试能说明什么
IROS现场安排了“Kick Me”演示，以外力推踢检验姿态恢复和动态稳定性。观众容易看到“踢了也没倒”，工程师更关心推力施加的位置、方向、时机与机器人当时的站姿。外力大小、是否有外部约束、恢复期间足部是否移动，都会影响结果。现有资料没有提供这些量化条件，不能据此推出RP1在所有扰动条件下都能保持平衡。
如果要比较算法，得把这段演示改成测试矩阵。固定站立和迈步过程分别测；从前后、侧向施加扰动；记录足端接触、机身姿态、关节电流与恢复时间。对照时使用相同地面条件和相同的起始状态，并公开失败次数。这样的记录既帮助读者理解展示，也能让后续控制算法找到可比较的基线。以上是建议的评估方法，并非RoboParty已公布的试验数据。
机器人失稳后的处理同样值得看。能不能识别即将跌倒的状态？在无法恢复时是否停止关节输出、保护周围人员和设备？实验室里的安全配置需要根据场地重做；公开项目如果同时说明风险边界，开发者就不必拿展示场景的动作直接套用到拥挤环境。
PartyOS的价值，要从接口和故障记录里找
PartyOS覆盖的范围相当宽：双足运动、感知交互、全身操作及自主智能。宽范围意味着模块之间要共享时间、坐标和状态。视觉模块说“目标在前方”，足部控制与手部控制都要明白这个“前方”对应哪个坐标系、哪一时刻的估计值。若感知延迟没有进入控制策略的预算，抓取和迈步可能互相干扰。
软件栈是否开放，除了看仓库有没有代码，还要查构建环境、依赖版本、驱动接口、仿真模型与实机部署步骤能否一一对应。对外部团队来说，一份能重放问题的日志格式很重要：传感器时间戳、关节命令、反馈、故障事件和软件版本需要留痕。这样才能区分感知偏差、通信超时和执行器保护动作。若只有高层任务接口，遇到异常时依然难定位。
部署流程也要有退路。新的步态策略先在仿真里检查关节限制，再以保守参数上机；每次修改保存可回滚的配置。相同代码在不同批次硬件上运行，要记录执行器版本和标定差异。对研究平台来说，稳定的低层接口通常比频繁更换上层模型更能节省调试时间。至于PartyOS会提供哪些具体工具，目前应等待路线图和发布文档，不能替项目方预写功能表。
从开源声明到可用平台，中间还有供应链和维护
量产计划与研究平台的维护有关。团队提出第四季度推进量产，并不意味着外部研究者现在已经能以稳定价格买齐零件。BOM的成本需要同时计算本体、驱动、手部、计算与传感器、工装、备件及装配工时；只看核心部件标价，采购预算会漏项。不同地区的采购条件也会影响复现难度。
采购方可以按三个阶段做决定。先核对公开文件和许可证，确认修改机械设计、替换执行器、发布派生代码时的权利与义务。随后联系供货渠道核实交期、维修方式与备件，再用一个小范围动作任务验证软件栈。最后才安排连续运行与多机一致性测试。合同、许可证和服务条款仍要以日后正式披露的文本为准。
第三方插件生态也不宜只数仓库数量。一个外部传感器包若必须修改内核驱动、低层控制和上层任务代码才能接入，接口尚未稳定；若可以按文档接好设备、复用标定流程并提交可复现的异常报告，开放平台的价值才会落到团队日常工作里。接口稳一些，实验室就能少花时间重搭驱动和标定流程；研究结论仍需各自验证。
实验室怎样给一台新平台安排首月工作
第一周最好不碰复杂的自主任务。先确认供电、急停、遥控接管和日志保存，再依说明完成单关节、整肢和机身姿态的基础测试。每次测试写下硬件版本、固件版本、软件提交号和操作者。如果没有统一记录模板，第二周有人换了一个参数，第一周的现象就很难追溯。以RP1为研究对象时，这份清单应随公开文档和实际到货配置调整，不能照搬其他人形机器人的值。
第二周检查模型与真机的差距。仿真里关节位置可以精确读出，实机可能有背隙、摩擦和温度漂移。先做低速、低负载动作，再逐步引入步行、手部操作；对每次中止记录触发条件，不把跌倒或夹持失败都归成“算法还不够好”。若复现一次异常需要临时翻日志、拍视频和猜故障码，说明观测链还没建好，应先补记录而不是更换模型。
第三周才适合给出一个对外能比较的小任务，例如固定地面上的短距离位移、站立时拿取限定尺寸的物体。任务说明需要写清起点、物体放置范围、允许的人工干预和失败判定。最后一周让没参与调参的同事按同一份文档重做。若只能由原工程师操作成功，内部演示已经可用，平台复现性还没有被证明。首月目标也不必追求漂亮数字，能把失败重演出来就已经省去后续大量猜测。
开放接口以后，修改责任归谁
“全栈开放”会让不同团队在机械、驱动和软件之间自由替换部件，故障责任也随之变复杂。假设研究者换了手部传感器，抓取不稳可能来自新传感器标定、驱动延迟，也可能来自原有的控制策略。合理的维护办法是定义一套基线配置：原始硬件与软件版本可重复安装，改动按层记录，问题先在基线上复现，再比较变更。这样上游项目才能判断自己该修什么，派生团队也知道哪些问题由自家修改引入。
对教学或实验室采购，还应问文档是否方便新人独立维护。一个部件损坏后，替换件是否可以重新标定，控制参数如何恢复，历史数据能否沿用？硬件开放是一个起点，返修、升级与跨批次兼容会持续消耗资源。第四季度发布计划如果落地，这些细节比单次展会上能做多少动作更值得长期跟踪。
接下来盯住几件事就够了：RPO、Romomo、RP Hand与PartyOS能否在公开文件中互相对齐，外部团队能否买到和装出相近的设备，长期维护能否跟上路线图。眼下已知的是项目范围、IROS展示及接下来公布路线和推进发布的计划。对打算入场的开发者，不妨先列出自己最难复现的十个环节，等文档到齐后逐项划掉。剩下没划掉的项目，最终会写进接入预算。
让开源项目经得起外部提交
开源社区能否持续贡献，还要看外部问题如何进入项目。一个关节在某一姿态报警，报告里最好带出机械配置、复现动作、环境温度、日志片段和预期行为；维护者也需说明哪些信息足够定位。若外部开发者提交的只是“走路不稳”，项目组只能靠聊天追问；若文档给出最小复现格式，修复可以进入正常的代码审查和回归测试。外部提交的驱动、机身改件和任务示例，还应标明适配硬件版本，免得新人照抄旧教程，把不兼容误判成设备故障。
评估一套开放平台，不妨找两个互不相同的使用者试用：做步态的实验室关心关节数据与跌倒保护，做操作的团队关心手部反馈、标定和物体接触。两组人遇到的问题不一样，若都能按同一套版本和日志规则反馈，说明底层协作方式有用。反过来，若每个案例都需要项目原团队全程远程调试，就要把支持成本计入预算。公开源码并不会自动创造公共维护能力。
2026年10月后续路线图尤其值得按版本节点记录，而不是只保存发布会截图。哪个模块先发布，哪项接口仍在调整，哪一版支持怎样的硬件组合，若能逐项说清，学校和企业才容易安排采购与研究周期。对RP1而言，这些仍是等待项目方披露与社区实践回答的问题。
参考资料
- RoboParty / PR Newswire，《RoboParty Unveils RP1, a High-Performance Full-Stack Open-Source Humanoid Robot at IROS》，2026-10-03。https://www.prnewswire.com/news-releases/roboparty-unveils-rp1-a-high-performance-full-stack-open-source-humanoid-robot-at-iros-302897655.html
- RoboParty / PR Newswire APAC，RP1亚太发布，2026-10-04 00:56 CST。https://www.prnewswire.com/apac/news-releases/roboparty-unveils-rp1-a-high-performance-full-stack-open-source-humanoid-robot-at-iros-302897663.html
- RoboParty / GitHub，ROBOTO ORIGIN开源项目（背景资料）。https://github.com/Roboparty/roboto_origin