我们试过给汽车厂上协作机械臂，结果六轴的钱只赚回三轴，才搞明白人形机器人的真实切口在哪

我是沈青锋，现在是我第三个创业项目——给制造业做人形机器人的部署集成。前两个项目，一个做AGV调度系统，一个做工业视觉检测，都没能撑过B轮。这次我们把Walker S送进一家二线汽车零部件厂的产线做搬运和质检，干了快四个月，上个月刚刚跑通了连续20天无故障运行。今天这篇文章是这四个月的真实记录，包括我们怎么搞定六维力控装配、怎么在视觉引导上差点栽跟头、以及为什么我最后觉得人形机器人现阶段的真实对手不是Figure 02，而是那些被我们砍掉的协作机械臂方案。

先交代客户背景。这家零部件厂给三个自主品牌供货，主要做发动机支架和悬挂连接件，年产值4个亿左右，工人240人。他们的问题是：精加工后的支架搬运和外观质检这两道工序，招工越来越难。年轻人不愿意在噪音和切削液环境里站8小时，现有工人平均年龄47岁。去年他们试过某品牌协作机械臂+2D相机做质检，三个月就拆了，误报率太高，而且换型时间要4小时。厂长跟我说，他们一个月要换型20多次，等不起。

我们进场之前，花了三周做工序拆解，不是看PPT参数，是蹲在产线旁边拿秒表掐节拍。精加工后的支架大概12-18公斤，从加工中心取出来放到质检台，人工搬运节拍是38秒一件。质检环节用肉眼检查表面划痕、缩孔和气孔，平均45秒一件。两条线加起来，一个班次需要3个工人轮换。我们的目标是把这两个工序合在一起，用一台Walker S完成搬运+质检，节拍控制在90秒以内——比人工慢，但可以24小时不停，综合产出能打平。

我们为什么从协作机械臂转投人形机器人，烧了400万才想明白这件事

这不是我们第一次做汽车零部件厂的自动化。2023年初，我们的上一个项目给一家刹车盘厂部署过协作机械臂做上下料。我们买的是某国产六轴协作臂，负载16公斤的那款，单台13万。方案看起来很美：机械臂固定在地面基座上，配一个3D相机，从料框里抓毛坯放上加工中心。（延伸阅读：我拆解了英伟达AI工厂的TCO模型，发现万卡集群的盈亏平衡点在18个月）

六轴方案在真实产线上死在哪

问题从第三周开始集中爆发。首先是基座问题。加工中心旁边的地面不是你以为的平整水泥地，常年切削液浸泡、叉车碾压，地面的水平度差了将近8毫米。机械臂厂家说基座平整度要求在±2毫米以内，我们只好重新浇筑了一块80厘米见方的混凝土基座，养护7天，整条线停在那里等。

然后是换型。客户一个月换型15次，每次换型需要调整机械臂的取料姿态和放置位置。官方说拖动示教5分钟搞定，实际呢？换了工件之后，3D相机的点云匹配参数也要重调，光照环境变了又要调曝光。一个换型流程走下来，快则40分钟，慢则一个半小时。客户的产线主管直接跟我说：“我宁可叫两个熟练工来搬，15分钟换完。”

最致命的是工作范围。六轴机械臂臂展1.3米，覆盖范围是一个半径1.3米的半球。加工中心的门打开之后，取料点离机械臂基座中心1.1米，理论上在范围内。但机械臂要在那个姿态下保持16公斤负载，关节5和关节6的电机发热严重，连续工作4小时后伺服驱动器报过温警告。厂家建议降低节拍或者加冷却风扇，但加了风扇之后切削液的油雾吹得到处都是，把相机镜头糊了一层。

这个项目我们整体投入了大概170万，客户付了60万的首付款，剩下的全是我们自己扛。跑了大半年，最后客户退货退款，我们净亏110万。加上前期研发投入和人员成本，那个方向上总共烧掉了400万左右。关掉项目的那个晚上，我和合伙人坐在工厂门口的马路牙子上，算了一笔账：把机械臂部署到一条现有的产线上，改造费用平均在25-35万——这还不算停线损失。而一条产线的年产值大概800万，客户能接受的投资回收期是1.5年以内。用协作机械臂方案，ROI根本算不过来。

为什么人形机器人是另一种解法

这次拿到零部件厂的搬运质检需求后，我们没有直接上方案，先做了一个对比测算。核心差异在于：六轴协作臂是固定基座的，它需要你把工件送到它的工作范围内；而人形机器人自带移动底盘，它可以走到工件旁边。这个差异在账面上意味着什么？协作机械臂方案需要改造产线布局，加传送带或者翻转台，改造成本大约18万，加上机械臂本体13万，一台套31万。Walker S一台采购成本比它高不少，但部署的时候只需要在工位旁边画一个1.2米×1.2米的站立区域，地面做简单找平即可，不需要动产线。第一台部署的硬件改造成本只有3600块——就买了一块防油地垫和几个地脚螺栓。

当然，人形机器人有它自己的坑，后面我会详细讲。但至少在部署成本和换型灵活性这两个维度上，我们在刹车盘厂交的400万学费告诉我们：固定基座的方案在离散制造产线上是硬伤，这个账无论怎么算都算不平。（延伸阅读：给工厂的缺陷检测模型搬到了Trainium2上，A100的账单终于不用咬牙还了）

Walker S的搬运任务实战：全身规划不是炫技，是被产线逼出来的

Walker S在汽车零部件厂的主要搬运任务是这样：从加工中心取出精加工完的发动机支架毛坯——这是一个形状不规则的铸铁件，重14公斤，表面还有残留切削液——然后走3步到质检台，把工件平稳放到检测工装上。听起来简单，实际上每一步都有坑。

取料姿态：六维力控是底线，不是加分项

加工中心内部的取料空间极其狭小。工件被夹具固定在机床内部，上方是主轴头，左侧是刀库，留给机械手伸进去的空间大概只有35厘米宽、40厘米高。Walker S需要用双手从两侧插入，抓住工件的定位销孔，然后垂直向上提15厘米，再水平退出。

这里的关键不是运动学解算——那个在实验室里早解决了——而是力控。工件在夹具里放了十几分钟，温度还在40度左右，有轻微热胀。而且加工精度有公差，同一批次的支架，定位销孔的间距偏差在±0.3毫米。如果纯靠位置控制，不是抓不进去，就是抓进去了拔不出来。我们在第三周就遇到过，Walker S的手指卡在销孔里，往外硬拔的时候把工件表面的螺纹刮花了，一个件报废。

我们最后用的是手腕六维力传感器加手指末端触觉传感器做力控引导。具体方案是ATI的Axial80六维力传感器装在腕部，手指末端是我们自己开发的薄膜压阻阵列传感器，成本控制在1200块一个。抓取策略分三步：先用位置控制把手指送到销孔上方2厘米处，然后切换到力控模式，让手指以50牛的接触力沿着工件表面滑动找孔；找到后施加80牛的夹持力；确认夹紧后再切回位置控制做垂直提升。

# 这是我们部署在Walker S上的力控抓取核心循环
# 控制器用的是优必选提供的WBC框架，我们在上面加了力控模块

import numpy as np
from wbc_interface import WholeBodyController, ForceControlModule

class GraspForceController:
    def __init__(self):
        self.wbc = WholeBodyController()
        self.fc = ForceControlModule(sensor_type="ATI_Axia80")
        self.target_force = 50.0  # N
        self.grasp_force = 80.0   # N
        self.stiffness = np.diag([200, 200, 800, 30, 30, 50])
        
    def compliant_search(self, current_pose, force_reading):
        # 导纳控制：根据力反馈调整末端位置
        delta_x = np.linalg.inv(self.stiffness) @ force_reading
        # 只在XY平面做柔顺，Z轴保持位置控制
        delta_x[2] = 0.0
        # 限幅防止过冲
        delta_x = np.clip(delta_x, -0.01, 0.01)
        return current_pose + delta_x
    
    def grasp_execute(self):
        # 阶段1：接近工件
        self.wbc.set_mode("position")
        approach_pose = self.get_approach_pose()
        self.wbc.move_to(approach_pose, speed=0.3)
        
        # 阶段2：力控找孔
        self.wbc.set_mode("admittance")
        self.wbc.set_stiffness(self.stiffness)
        for step in range(500):
            force = self.fc.read_filtered()
            if self.finger_contact_detected(force):
                break
            new_pose = self.compliant_search(
                self.wbc.get_current_ee_pose(), force
            )
            self.wbc.command_pose(new_pose)
            
        # 阶段3：夹紧确认
        self.gripper.command(self.grasp_force)
        if not self.gripper.confirm_grasp():
            raise GraspFailedError("夹紧力未达到目标值")
        self.wbc.set_mode("position")

这套方案跑了大概两周调参，主要调的是导纳控制的刚度矩阵。刚度设太高，力控太硬，遇到公差偏大的工件还是卡；设太低，手臂太软，14公斤的工件提起来会晃。最后我们根据工件重量分段设置了3组刚度参数，换型的时候自动切换。现在搬运成功率稳定在99.2%左右，剩下的0.8%大部分是工件表面切削液残留过多导致手指打滑，我们正在加微织构的防滑手指垫。

行走搬运：模型预测控制救了我们的节拍

取完料之后要走3步到质检台。这个距离人走2秒，Walker S走4.5秒。问题出在停下的时候——早期版本停下来之后手臂会因为惯性晃动，晃幅大概3-4厘米，要等1.5秒左右才能稳定下来做下一步操作。这1.5秒看着不多，但每个搬运循环都要等，累计下来把节拍拉到了105秒，远超我们承诺的90秒。（延伸阅读：当单卡算力撞上800 TFLOPS，我翻了37份AI融资BP，发现90%的“大算力需求”都是PPT泡沫）

我们跟优必选的工程师一起排查了一周，发现问题出在运动控制架构上。原来的方案是行走和上身运动分开规划——腿先走到目标点停稳，然后上身再做操作。这种解耦控制的优点是简单，缺点是停下之后上身的动量要靠被动阻尼消耗掉，等稳定就是这1.5秒。

我们换成了基于模型预测控制（MPC）的全身规划方案。思路是把行走的最后一步和手臂放置动作融合在同一个MPC问题里求解。MPC的预测时域设在1.2秒，在这个时域内同时规划质心轨迹、脚步落点和末端执行器路径，约束条件是保证零力矩点在支撑多边形内。说人话就是：让机器人在走的最后一步就开始放下手臂，用腿部的减速来抵消手臂下放带来的上身动量，把稳定时间压缩到0.3秒以内。

这个改动让搬运节拍从105秒缩到了91秒，离目标还差1秒。剩下的1秒我们是从质检环节挤出来的，后面讲。但MPC方案有个代价——计算量大了将近4倍，车载的Orin AGX算力占用率从45%跳到了78%。我们不得不把一些非实时任务挪到边缘服务器上跑，中间加了一个5G专网做通信。好在这家工厂本来就有5G专网覆盖，省了一笔新增通信基础设施的钱。

质检环节的视觉进化：从2D翻车到3D站稳，中间差点又烧掉一笔钱

质检任务是检测发动机支架表面的铸造缺陷——主要是缩孔、气孔和表面划痕。允许的最大缺陷尺寸是0.5毫米，超过这个标准就要判废。这是一个典型的精密表面检测问题，但我们一开始差点在这个环节上重蹈覆辙。

我们几乎犯了一个跟刹车盘项目一模一样的错误

项目启动的第二周，我差点拍板上2D方案。逻辑听起来很合理：2D相机分辨率高，算法成熟，我们在上个项目的视觉检测团队有现成的模型和标注数据，两周就能出demo。而且2D工业相机便宜，一台5000块搞定，3D相机要贵一个数量级。

还好被客户那边的质量工程师拉住了。他带我们去看了一批真实的不良件——缩孔深度在1.2毫米但表面直径只有0.4毫米，2D相机从正上方拍过去，投影面积小得几乎看不到。更坑的是切削液残留——加工完的支架表面有一层薄油膜，在2D图像上形成的反光斑跟真实的气孔缺陷形态极其相似。他们之前那套被拆掉的协作机械臂质检方案，就是死在这个问题上。（延伸阅读：凌晨三点被Figure 02的抓取失败告警叫醒：宝马产线人形机器人装配系统的血泪运维实录）

我后背一阵发凉。如果当时真上了2D，大概三个月后又是同样的结局。我们紧急转向了3D方案。

3D结构光加域适应的组合拳

最终方案是：用LMI的Gocator 3520结构光3D相机做点云采集，配合我们自研的缺陷检测模型。Gocator 3520在50毫米工作距离下的Z轴分辨率是2.6微米，完全够用。但3D点云带来了新问题：数据量暴增，单帧点云大概200万个点，要在质检节拍内完成缺陷检测，对算法效率要求很高。

我们把检测流水线拆成了三级。第一级用统计滤波快速筛掉正常表面区域，只保留高度异常的候选区域——这一步在GPU上跑，耗时大概120毫秒，过滤掉95%以上的点云。第二级对候选区域做点云配准和特征提取，用的是基于PointNet++改进的轻量化网络，分类缩孔、气孔和划痕三类缺陷。第三级是尺寸测量——对已经分类好的缺陷区域计算实际几何尺寸，跟允许的公差做对比。

# 质检流水线的三级过滤架构
# 第一级：统计滤波（C++实现，跑在Orin的GPU上）
# 第二级：缺陷分类（TensorRT推理）
# 第三级：尺寸测量（CPU）

import cupy as cp
import tensorrt as trt
from pointcloud_utils import voxel_downsample, radius_filter

class DefectInspectionPipeline:
    def __init__(self):
        self.trt_engine = self.load_trt_engine("defect_classifier_fp16.engine")
        self.context = self.trt_engine.create_execution_context()
        
    def stage1_statistical_filter(self, pcd_gpu, sigma=3.0):
        # 计算点云局部高度统计量
        mean_h = cp.mean(pcd_gpu[:, 2])
        std_h = cp.std(pcd_gpu[:, 2])
        anomaly_mask = cp.abs(pcd_gpu[:, 2] - mean_h) > sigma * std_h
        candidates = pcd_gpu[anomaly_mask]
        return candidates  # 通常在1万点以内
        
    def stage2_classify_defects(self, candidates):
        # 对候选区域做体素下采样到固定点数
        voxel_grid = voxel_downsample(candidates, voxel_size=0.2)
        patches = radius_filter(voxel_grid, radius=1.5, max_points=1024)
        
        results = []
        for patch in patches:
            # TensorRT FP16推理
            input_tensor = patch.astype(cp.float16).reshape(1, 1024, 3)
            output = self.context.execute_v2([input_tensor])
            cls_id = cp.argmax(output).item()  # 0:OK 1:缩孔 2:气孔 3:划痕
            if cls_id > 0:
                results.append({
                    'patch': patch,
                    'class': cls_id,
                    'position': cp.mean(patch, axis=0)
                })
        return results
        
    def stage3_measure_geometry(self, defect_patch):
        # 对已分类的缺陷做精确尺寸测量
        # 缩孔：测量深度和等效直径
        # 气孔：测量投影面积和深度
        # 划痕：测量长度和最大深度
        measurements = {}
        z_values = defect_patch[:, 2]
        measurements['max_depth'] = float(z_values.max() - z_values.min())
        measurements['projected_area'] = float(
            self.compute_concave_hull_area(defect_patch[:, :2])
        )
        return measurements

但实际部署的时候遇到了训练数据不足的问题。客户过去一年总共只积累了大概600张标记过的缺陷样本，这个量根本不够训练一个可靠的3D分类器。我们用了两个办法：一是数据增强——对点云做随机旋转、加噪声、模拟不同光照下的点云缺失；二是域适应——用客户现有的少量真实缺陷数据对预训练模型做微调，预训练基座是用公开的ShapeNet和MVTec 3D-AD数据集训练的。最后用50个真实样本做few-shot微调，在客户现场的测试集上达到了96.7%的召回率和94.2%的精确率。

这里有个有意思的发现：3D点云模型天然比2D模型更能抵抗切削液油膜的干扰。因为油膜的厚度只有几十微米，在3D点云里几乎不产生高度变化，但在2D图像里会形成高对比度的反光区域。这解释了为什么2D方案在实验室好好的，到现场就崩。也是这个原因，我们质检节拍从45秒压到了38秒——少了大量误报需要人工复核的环节。

三个月产线跑下来的工程教训：那些PPT上永远不会出现的问题

前面讲的都是技术方案，好像挺顺利。实际上前两个月我们几乎每周都在解决一些意想不到的问题。这些问题单个看都不大，但堆在一起能让机器人趴窝。下面挑几个最有代表性的。

线缆寿命和散热：实验室从不需要考虑的东西

Walker S全身有47根走线——动力线、信号线、冷却管——出厂的时候线缆束是暴露在外的。在实验室环境没问题，但在产线上，持续的手臂抬举和弯腰动作让关节处的线缆反复弯折。第一个月还没结束，右肩关节的一根编码器信号线就出现了间歇性断连，导致手臂位置反馈偶尔跳变，抓取姿态偏差超过2毫米就会报错停机。（延伸阅读：我拿47个模型跑了一遍AWS Inf2，发现大模型部署成本砍半的核心条件90%的团队都不具备）

拆开外皮检查，线缆在关节弯折处的铜丝断了大概30%。优必选的原厂线缆用的是标准工业拖链线，标称弯折寿命1000万次，看起来很多对不对？但我们算了一下，Walker S每做一个搬运循环要弯折肩关节大概15度角，一天24小时做2000个循环，一个月60万次弯折。标称1000万次意味着大概16个月就会疲劳断裂——这在实验室测试中根本暴露不出来，因为没有人会连续跑16个月做耐久测试。

我们的临时解决方案是在所有高弯折关节处加了线缆护套和弯折限位，把弯折半径从8毫米放宽到15毫米，弯折应力降了大概60%。同时把信号线和动力线分开走线，即使信号线断了也不会短路到动力线上。长远来看，我们跟优必选在讨论把部分关节的信号传输改成无线或者滑环方案，但滑环本身又有接触电阻和磨损的问题，这个还在评估。

散热是另一个坑。Walker S的关节电机和计算单元本身有主动散热风扇，但在工厂环境下，风扇会把空气中的切削液油雾和金属粉尘吸进去。三周后我们拆开膝关节的伺服驱动器散热片，发现缝隙里积了一层油泥混合物，导热性能严重下降。关节温度从正常的55度跳到了72度，驱动器开始降功率保护，搬运节拍自动延长了12%。

我们最后的办法比较简单粗暴：在所有进风口加装可拆卸的过滤棉，每周更换一次。同时把散热风道从原来的“前进后出”改成了“上进侧出”，避免地面扬尘直接被吸入。散热效果恢复了，但增加了一个每周1.5小时的人工维护环节。我跟客户商量把这个维护纳入他们现有TPM体系里，由设备保全人员顺手做了，没有增加额外人力成本。

与Figure 02的对比：参数不是一切，生态和可维护性才是产线生命线

做海外市场的同行经常问我，你们为什么不用Figure 02？参数上看Figure 02在很多方面确实领先：负载能力、手部灵巧度、续航时间。我们认真评估过，结论是：在当前这个阶段，在汽车零部件厂这个场景里，选Walker S不是因为性能更好，而是因为三个非常实际的工程因素。

最让我头疼的不是技术参数，而是当机器人在凌晨三点停下来的时候，你能不能在一个小时内让它重新动起来。这跟软件好不好没关系，跟备件库存、工程师响应时间、以及你对底层控制框架的修改权限有关系。在这一点上，国产方案有天然的地理和供应链优势，这个优势在产线运维阶段会被急剧放大。

但说实话，Walker S也不是完美的。手指的精细操作能力跟Figure 02的全向手指相比有明显差距。我们做的搬运任务不需要太精细的手指操作，但如果以后扩展到需要操作小螺栓或者接插线缆的任务，现有手指肯定不够。另外续航也是个隐忧，Walker S目前的电池在连续搬运工况下大概撑5小时，虽然我们现在的方案是不间断换电——两台Walker S轮换，换电时间5分钟——但如果产线需要连续作业没有备份机，这个续航会是瓶颈。

简单说就是四个多月的实训跑下来，Walker S在这家零部件厂算是站稳了。搬运成功率99.2%，质检误报率从原来人工的8%降到了5.8%，综合节拍91秒虽然比人工慢，但24小时不停，实际日产出比一个工人班次高了大概30%。客户现在把这两道工序的3个人调去了后道包装，没有裁员。厂长上个月跟我说准备再上两台，把另外两条线的搬运质检也做了。但我知道，这个成功案例能复制的前提是：这家工厂的产线相对稳定，换型虽然频繁但工件种类只有12种，而且地面的工作环境我们花了大力气做适配。

人形机器人在制造业的落地，现在远远没到“开箱即用”的阶段。每一台都是高度定制化的部署。我们在这一个客户身上投入了大概3个人月、直接部署成本大概22万（包含硬件适配、软件定制和三个月驻场），这个成本需要客户3-4个月省下的人工费才能打平。能不能大规模复制，取决于我们能把部署成本压到多低。这是下一个阶段要啃的骨头。