摄像头电机自动校准实战：为什么我用「步数计数」替换了角度传感器绝对定位

最近公司开发了一套虹膜人脸一体识别系统，用的是易思科公司的虹膜识别一体设备，摄像头是可以上下移动的，开发完成后对相关逻辑有了一些技术经验，分享一下。

背景：一个看似简单的需求

我们的项目是一台跑在 RK 主板上的生物识别智能终端（虹膜 + 人脸 + NFC 刷卡），摄像头装在一个步进电机驱动的俯仰云台上：识别时摄像头要跟着人脸上下转动，没人时要自动回中。设备上带了一个角度传感器，能读出摄像头当前的俯仰角（原始值 0~359）。

直觉方案很简单：**读传感器 → 算当前角度与目标角度的差 → 按比例换算成步数 → 让电机转过去。**这就是典型的"绝对定位"思路，代码写起来也就几十行。

然而上线后，这套方案在现场反复翻车：摄像头居中时撞墙、在目标两侧来回震荡、每次开机行为不一致。最终我把整套定位体系推翻，改成了开环步数计数：位置不再由传感器读数推算，而是"回顶归零 → 顶到底扫描计数 → 位置 = 距顶部的步数"。传感器只降级用于一件事------扫描时判断"是不是顶到头了"。

这篇文章完整记录这次踩坑和演进过程。先说结论：在低成本、传动间隙大、传感器非线性的机电系统里，一个朴素的开环计数方案，往往比一个看似精确的闭环绝对定位方案更可靠。

问题现象

最初的闭环方案（姑且叫 v1）上线后，陆续出现三类症状：

1. 居中撞墙：启动校准时，摄像头在上下两个极限位置之间来回跑，每次都撞到机械限位发出咔咔声，直到重试次数耗尽，最后停在某个极限位。

2. 目标两侧震荡：居中过程中摄像头在目标位置左右来回摆动，实测每次移动过冲约 160 个传感器单位，直到最大尝试次数（最初是 6 次）用完也停不下来。

3. 每次开机行为不一致：同一台设备，今天居中位置正常，明天开机就偏到一边去了。

根因分析：角度传感器的三大坑

把现场日志捞回来逐条分析后，问题全部指向同一个源头------**角度传感器根本不像文档里暗示的那样"线性、稳定、可换算"。**它有三大坑：

坑一：灵敏度随位置非线性漂移

理论上"传感器单位/步"应该是一个常数，比如电机走 30 步，传感器变化 30 个单位，换算比就是 1.0。实测下来，这个比值随摄像头所处位置剧烈变化：

• 在某些位置，30 步只引起 0.3 单位/步 的变化；

• 在另一些位置（高灵敏度区域），高达 5 单位/步。

相差 10 倍以上。这意味着任何"固定换算系数"的闭环都注定失败：系数按低灵敏度区域调，到了高灵敏度区域就 10 倍过冲------这就是"目标两侧震荡"的直接原因。实测过冲约 160 单位，和灵敏度比值的数量级完全吻合。

坑二：零点每次开机漂移

传感器的零点不是固定的。我们同一台设备两次开机的实测数据：

• 第一次：顶部 = 46，底部 = 259；

• 第二次：顶部 = 18，底部 = 275。

行程本身（约 213 单位）大体稳定，但整个读数窗口在平移。这意味着任何持久化下来的绝对角度值，下次开机就失效了。"每次开机行为不一致"的谜题就此解开------不是机械问题，是坐标系每次都在漂。

坑三：0/360 回绕 + 行程超过 180° 的最短弧陷阱

这是最隐蔽、也最致命的一个坑。 处理 0~359 的环形角度时，教科书做法是用"最短弧"表示两个角度的差：

// 把角度差规范到 [-180, 180) 区间，取最短弧
int signedDelta = ((to - from + 360 + 180) % 360) - 180;

行程小于 180 时这没问题。但我们设备实测行程是 46→259，共 213 个传感器单位，超过了 180。此时最短弧算法选中的不再是顶→底的那条弧，而是穿过 0/360 回绕点的那条互补弧（360 - 213 = 147 单位）------而这条弧在机械上是根本走不通的！

后果就是：算出来的居中目标（比如 raw 340）位于机械不可达的弧上，电机无论怎么转都"到不了目标"，于是不停换方向、不停撞墙，直到重试耗尽。这就是"居中撞墙"的根因。

方案演进：三步走到开环计数

v2：行进弧 + 实测方向

/** 沿实测方向（顶→底）计算 from 到 to 的弧长 */
int directedDistance(int from, int to, int direction) {
    from = normalize(from); to = normalize(to);
    return direction > 0
            ? (to - from + 360) % 360
            : (from - to + 360) % 360;
}

同时行程上限校验从 <180 放宽到 <360。撞墙问题解决了，但坑一（灵敏度非线性）导致的震荡还在。

v2.5：自适应增益闭环

针对震荡，我把固定换算系数改成了在线估计的自适应增益：

double unitsPerStep = 1.0;  // 初始增益：传感器单位/步（按 213 单位 / 210 步实测）
int previousDistance = -1;

for (int i = 0; i < MAX_ATTEMPTS; i++) {
    int distance = distanceToTarget(current, target);
    if (distance <= TOLERANCE) return true;

    // 移动后反而更远：视为增益过大导致过冲，下一步步数减半阻尼
    boolean dampen = previousDistance >= 0 && distance > previousDistance;

    int steps = stepsForDistance(distance, unitsPerStep);
    if (dampen) steps = Math.max(1, steps / 2);

    int from = current;
    current = moveAndReadAngle(directionTo(current, target), steps);

    // 用本次实测"角度变化/步数"滑动平均修正增益，clamp 在 [0.2, 8.0]
    int movedUnits = movedUnitsAlongTravel(from, current);
    if (movedUnits > 0 && steps >= MIN_GAIN_SAMPLE_STEPS) {  // 少于 5 步不采样，避免噪声污染
        double measured = (double) movedUnits / steps;
        unitsPerStep = clamp(unitsPerStep * 0.5 + measured * 0.5, 0.2, 8.0);
    }
    previousDistance = distance;
}

几个设计细节值得说：

• 滑动平均而不是直接替换：new = old * 0.5 + measured * 0.5，单次异常读数不会把增益带飞；

• clamp 到 0.2, 8.0：下限防止增益被噪声压到 0 导致"永远走大步"，上限按实测 5 单位/步的高灵敏度区域留足余量；

• 移动少于 5 步不更新增益：小步移动时传感器读数噪声占比太高，采样了反而污染估计；

• 距离 ≤30 单位进入小步模式：单次最多走 10 步，临近目标时收敛而不是冲过去。

这版确实能居中了，最大尝试次数也从 6 放宽到 8 兜底。但我越维护越心虚：这套闭环的每一个环节都在和传感器的不可靠性做斗争------零点漂移、灵敏度非线性、回绕、方向映射，全都要打补丁。而且它是闭环，任何一环出问题都会以"震荡/撞墙"的形式放大出来。

v3：开环步数计数------最终方案

换一个角度看问题：我真正需要的"位置"是什么？其实只是"摄像头在行程中的相对位置"，用来回答两个问题------还能不能往这个方向走？回中要走多少步？

这两个问题都不需要知道绝对角度。于是最终方案定为：

位置一律按步数计数：0 = 顶部，totalTravelSteps = 底部。传感器只用于扫描时的停滞检测（判断到顶/到底），不再参与位置计算。

启动校准流程变为三步：

void runStartupCalibration() {
    // 1. 回顶归零：分段向上走，连续 3 段传感器读数变化 ≤5 判定到顶（停滞检测）
    scanMechanicalLimit(movingUp = true);

    // 2. 顶到底扫描计数：每段走 30 步，只在"确实动了"时累加步数，
    //    停滞 3 段判定到底，返回总步数 totalSteps
    int totalSteps = scanTravelStepCount();

    if (totalSteps >= MIN_TRAVEL_STEPS) {  // 60，校验行程合理性
        // 3. 扫描结束时摄像头停在底部，位置记为 totalSteps；
        //    居中目标 = totalSteps × 居中比例%（如 75%）
        MotorRotationManager.setStepTravel(totalSteps, /* current */ totalSteps);
        moveToStepIndexSync(totalSteps * centerPercent / 100);
    } else {
        // 兜底：回顶后向下走固定 90 步，绝不把摄像头留在极限位
        fallbackToSafePosition();
    }
}

扫描计数的关键在于只累加"确实移动了"的段：每段下发 30 步指令后读传感器，变化超过停滞阈值（5 单位）才算这 30 步真实走完，否则认为是顶到机械限位空转，不计数。这样即使电机在极限位丢步，计数也不会虚高：

int scanTravelStepCount() {
    int movedSteps = 0, stalledCount = 0;
    for (int segment = 0; segment < MAX_SEGMENTS; segment++) {
        moveDown(30);  // 固定步进
        int current = readAngleSensor();
        if (rawAngleDistance(previous, current) <= STALL_TOLERANCE) {
            if (++stalledCount >= 3) return movedSteps;  // 连续 3 段停滞 → 到底
        } else {
            stalledCount = 0;
            movedSteps += 30;      // 只累计真实移动的步数
        }
        previous = current;
    }
    return -1;
}

之后所有移动路径------人脸跟随、无人脸回中、调试页手动移动------统一走同一个计数入口，每次移动完成后同步计数：

public static void recordMovedSteps(int signedSteps) {  // 向下为正
    if (sTotalTravelSteps <= 0 || sCurrentStepPosition < 0) return;
    sCurrentStepPosition = clamp(sCurrentStepPosition + signedSteps, 0, sTotalTravelSteps);
}

极限保护也变得极其简单------不再需要读传感器、算环形距离，直接按计数钳位：

int constrainSteps(int requestedSteps, boolean movingUp) {
    int remaining = movingUp ? current : totalSteps - current;
    if (remaining <= 0) return 0;                    // 已到极限，不再下发同方向指令
    return Math.min(requestedSteps, remaining);      // 接近极限时缩短步数
}

对比一下：v1/v2 里极限保护要处理"当前位置落在行程弧外"的异常分支、要推断方向、要容忍读数失败；v3 里就是两行减法。当位置本身变得可靠，保护逻辑自然变得平凡。

开环的局限与工程取舍

必须诚实地说：步数计数是开环推算 ，它有明确的局限------丢步会累积。电机堵转、瞬时供电不足、机械卡滞导致的丢步，系统无法感知，误差会一路累积到下一次启动扫描才被纠正。

为什么这个局限在工程上可接受？

1. 归零成本极低：每次开机都跑一次完整扫描（回顶 + 顶到底，总共十几秒），累积误差的生命周期被限制在一次开机内，不会跨天发酵；

2. 应用场景对绝对精度不敏感：摄像头跟随人脸是"看到人脸偏离画面中心 → 转几步"的视觉闭环，人脸检测结果本身就是反馈；步数计数只需要保证"不撞极限、能回中"，不需要亚度级精度；

3. 机械结构变化自愈：如果维护后行程变了（比如换了传动件），下次开机扫描自动重测总步数，不需要人工改配置------这一点比任何需要标定参数的闭环方案都省心。

反过来想，如果坚持用传感器闭环，要彻底解决三大坑，就得做逐点标定（建立位置→灵敏度的查找表）+ 每次开机重新对齐零点 + 环形空间的行进弧建模------为了一个"摄像头别撞墙"的功能，不值得。

经验总结

1. **环形角度（0/360 回绕） + 行程 >180° 时，"最短弧"是个陷阱。**它可能选中机械不可达的互补弧。要么用实测行进方向建模行进弧，要么干脆跳出角度坐标系。

2. 不要假设传感器是线性的。"单位/步"这种换算系数，在低成本机电系统里随位置变化 10 倍不稀奇。上闭环前，先实测全行程的灵敏度分布。

3. **每次开机漂移的零点，意味着绝对坐标系不可用。**持久化的标定值随时可能失效，相对位置（距某基准点的偏移）才是可靠的表达方式。

4. **开环 + 定期归零，常常优于带病闭环。**闭环的可靠性上限是传感器和执行器的可靠性；当它们不可靠时，闭环会把误差放大成震荡。开环把误差约束为"单调累积 + 定期清零"，行为可预期。

5. 扫描计数时只累计"确认移动"的步数，用停滞检测把机械空转排除在计数之外，这是开环计数不虚高的关键。

6. **所有移动路径走同一个计数入口。**调试页、校准、人脸跟随如果用不同的移动实现，计数单位迟早对不上，误差就是这么混进来的。

适用场景建议

这套"回顶归零 + 步数计数 + 停滞检测"的方案，适合以下特征的场景：

• 步进电机/减速电机驱动，有明确的机械极限位可以当零点和量程基准；

• 每次开机有时间窗口做一次全行程扫描（秒级~十几秒）；

• 对绝对位置精度不敏感，但对"不撞极限、动作一致"敏感；

• 传感器廉价、非线性、零点漂移，标定维护成本高。

反过来，如果你的场景要求断电记忆绝对位置、不允许开机扫描动作、或者本身就有可靠的编码器，那还是老老实实上闭环编码器方案------开环计数解决的是"廉价硬件上的可靠性"问题，不是精度问题。