# 给主办方的通报 · 左肩抬舵机「带载失速」· 2026-09-09

> 承接 `MSG-ORGANISERS-2026-09-08-SERVO.md`。语气不变：平级通报，三段式。
> **新增的核心事实**：昨天的问题是 66°C 的热降额；今天在 **40°C** 就失速了。
> 不是同一个失效模式，不能当成「昨天那件事又发生了一次」来写。
> 这次有了昨天没有的东西：**一个可复现、可当场执行的判定动作**。

---

## 直接复制这段

Hi — a follow-up on the left shoulder-lift servo, with a new measurement that changes what
we think is going on. Same as before: nothing is broken, nothing is on fire, and the
safeguards did their job. But this one does affect a demo-critical motion, so we would like
to renew the inspection offer you made earlier if it is still possible.

**WHERE WE ARE OTHERWISE**

The rest of the pipeline is in good shape. Autonomous grasping runs on the right arm, the
scripted pour sequence runs end to end on both arms, recording and data upload work, and we
fixed a separate issue today that had been silently dropping recorded frames. The full
customer-facing story — pick up a cup, carry it to the pour position, pour, serve — is
assembled and runs. The one thing that does not hold up is the left arm holding the cup at
the pour position, and that is what this note is about.

**WHAT WE MEASURED TODAY**

We commanded the left arm to the pour-position pose it needs to hold while the right arm
pours. Reading raw encoder ticks:

```
left_arm_shoulder_lift    goal 2209    present 2297    gap -88 ticks (-7.65 deg)

  re-enable torque, re-issue the same goal, sample for 3 s:
    t=0.5s  present 2254   (moved 43 ticks)
    t=1.0s  present 2254
    t=1.5s  present 2254
    t=2.0s  present 2254
    t=2.5s  present 2254
    t=3.0s  present 2254   -> stalled 45 ticks (3.9 deg) short, and stayed there
```

It moves about half way, then stops and does not recover. Three things make this different
from the 09-08 report:

1. **It happened at 40 C, not 66 C.** This is not thermal derating. The joint was well
   below both our 50 C warn and 60 C stop thresholds, and below the servo's own 70 C limit.
2. **The same servo reaches our home pose with 0.00 deg error**, immediately afterwards. It
   is not a dead or disconnected joint — it is pose- and load-dependent.
3. **The other five joints on that arm all reached within 0.6 deg** in the same command.
   Nothing else on that bus shows anything.

No error or protection flag was latched: `Status = 0`, `Torque_Enable = 1`,
`Torque_Limit = 1000` (maximum), and the goal is comfortably inside the configured position
limits (min 1440, max 3866, goal 2209). Temperature fell from 40 C to 37 C within a minute
of leaving the pose.

**WHAT WE CANNOT CONCLUDE FROM THIS**

We have not done a like-for-like comparison. We did not put the right arm into the same
pose with the same payload, so we cannot yet say the left servo is weaker than its twin
rather than the pose simply being beyond what this servo size holds with a cup in the
gripper. That distinction matters and we have not earned it yet.

We also have no usable torque telemetry: `Present_Load` and `Present_Current` read 0 on all
six motors of that arm, including joints that were visibly holding the arm against gravity.
That reading is wrong rather than informative, so we cannot quantify how far short the
servo is falling. We are reporting the stall geometry because it is what we can actually
measure.

**WHY IT MATTERS FOR THE DEMO**

The pour sequence requires the left arm to reach that extended pose *and hold it* while the
right arm tips the can into the cup. That is a sustained held load at an extended pose —
precisely the duty cycle we were already trying to avoid on this joint after the 09-08
finding. So the mitigation we adopted last week ("avoid sustained high-load held poses")
and the motion the complete demo needs are in direct conflict, on this one joint.

We can work around it by moving the pour position closer to the robot body to shorten the
moment arm, and we will try that. But it constrains the staging, and we would rather know
whether the joint is actually below spec before we design the demo around it.

**THE ASK**

You offered earlier to try to find time, or find someone, to look at this before Demo Day.
If that is still possible, we would like to take you up on it, and we now have a much more
specific check to hand over than last week:

1. **A hands-on comparison of mechanical resistance** between the left and right
   shoulder-lift joints, with torque disabled on both. This is the same request as last
   week, but it is now the single check that separates the two explanations above: if the
   left joint feels notably stiffer to back-drive by hand than the right one, that points
   at the mechanism rather than at our pose choice.

2. **Where to find a spare Feetech STS/SCS servo**, as before — to keep on the shelf, not
   to fit now.

Neither is urgent today. What would be most useful is knowing before we freeze the demo
configuration, so we can decide whether to design around a weaker joint or not.

For context: a replacement servo was already fitted at this joint once before, so we are
not assuming another swap is the answer. That is part of why we would rather have someone
put a hand on it than keep changing parts.

---

## 中文对照与写法说明

**这封和 9-08 那封的关系。** 不是「又热了一次」，是**另一个失效模式**：
- 9-08：闲置 66°C，症状是热降额、抬升变迟钝；
- 今天：**40°C 就失速**，热完全不是因素。

如果把两件事写成同一件，对方会按「散热/占空比」去想，而那个方向今天已经被温度数据排除了。
所以开头第一句就点明「a new measurement that changes what we think is going on」。

**为什么先写「其他都好」。** 用户的原话是「其他都很成功」。但直接写「everything else is
successful」是没有边界的断言。改成列举**具体跑通了什么**（右臂自主抓取、脚本化倒水全流程、
录制上传、修掉掉帧），再说「唯独左臂端不住」。这样对方能自己判断分量，而不是接受一个形容词。

**「我们不能从中得出什么」这一段照旧保留，而且这次更重要。**
今天没做左右臂同姿势同负载的对照 —— 没做就是没做。主动写出来有两个作用：
- 它把请求 ① 从「你们来看看」变成**唯一能区分两种解释的动作**，请求因此可执行；
- `Present_Load` / `Present_Current` 六个电机全读 0（包括正扛着重力的关节），
  这个读数是**错的**而不是「没负载」。把它当证据用会毁掉整封信的可信度，
  所以明写「我们没有可用的扭矩遥测」。

**「为什么影响 Demo」这一段是新的，也是这封信存在的理由。**
9-08 提出的缓解措施是「避免持续高负载保持位姿」，而完整倒水流程**恰恰要求**左臂
保持在伸展位。缓解措施和演示需求在这一个关节上正面冲突 —— 这句话比任何温度数字
都更能说明为什么需要在冻结方案前得到答复。

**没有说的话。** 没有说「舵机坏了」（今天的数据不支持），没有说「必须换件」
（上次已经换过一次），没有说「不修就演不了」（可以把倒水位往身体侧挪来缓解）。
每一条都会在对方检查后被推翻，然后代价是这封信里其余数字的可信度。

**数据出处：** 2026-09-09 直接读舵机寄存器（`Present_Position` / `Goal_Position` /
`Min_Position_Limit` / `Status` / `Torque_Enable` / `Present_Temperature`，
均为 `normalize=False` 原始 tick），左臂总线 `/dev/ttyACM0`。
复现方式：`pour_cup.py --arm left --go` 走到 `carry` 段即可观察到。