#22 從 launchd 服務啟動時 Tailscale 綁定靜默失敗 已修

手動在終端機啟動一切正常；改由 launchd 服務啟動後，只綁上 loopback， 啟動訊息寫「Tailscale 未啟動或已停用」。

根因：launchd 給子行程的 PATH 是 /usr/bin:/bin:/usr/sbin:/sbin，而 tailscale 裝在 /usr/local/bin。互動 shell 找得到，launchd 生的行程找不到， 偵測函式就回傳 None 並靜默退回本機模式。

修法：先試幾個絕對路徑（/usr/local/bin、 /opt/homebrew/bin、Tailscale.app 內），再退回解析 /sbin/ifconfig （/sbin 一定在 launchd 的 PATH 上），完全不依賴 Tailscale CLI。 順帶把位址判斷從「開頭是 100.」收緊成真正的 CGNAT 範圍 100.64.0.0/10——100.7.x.x 是一般公網位址，不該被誤認。

教訓：在互動 shell 測過不代表在 launchd/cron 下會過，兩者的環境不同。 這個 bug 只有實際「用 launchd 服務啟動一次」才會現形。

#23 每次模擬的前 0.5 秒都是假暫態 靜默 已修

MR2（時間平移）失敗，差 57°。追下去發現不是測試的問題，是生產程式碼的 bug。

run_mujoco.run() 的註解寫「start settled at the home pose so the first frame is not a drop test」，但實作沒做到：setup() 只設了 commanded_us，此時 latched_us 仍是 1500 µs，所以 joint_setpoint() 回傳的是伺服中心姿態 而不是程式的起始姿態。每次模擬都從中心姿態滑移到起始姿態。

影響已發表的數字：修正後 j3 峰值追蹤誤差 14.35°→8.47°、 j4 12.96°→8.70°、j5 10.27°→8.68°。 那三個關節先前的峰值有四成是開機暫態而非程式造成。j1/j2 與任務結果不變。

修法：新增 SG90.settle()，在初始化 qpos 前把伺服直接跳到指令位置。

#24 關節極限太軟，隨機程式能陷進去 6.8° 已改善

T6 的隨機程式把關節推過極限 6.79°。MuJoCo 的關節極限是軟約束， 預設 solref 時間常數 0.02 s 對 1 ms 時步而言太鬆。

修法：收緊到 solreflimit="0.002 1" → 降到 1.20°。 再收緊或增加求解器迭代都不再改善——那是這個約束模型的下限。 1.2° 對塑膠齒輪伺服撞上機械停點是合理的順應量，所以界線訂在 2°， 並另外驗證它是有界的（極端程式下不會發散）而非約束在失效。

#25 堵轉扭矩被定義兩次，改一個不影響物理 靜默 已修

由變異測試發現。堵轉值同時存在於 sim/sg90_servo.py（報告用）與 urdf/sg90_arm.py（真正進 MJCF forcerange）。把前者改小 10% 完全不影響模擬結果，而且沒有任何檢查會察覺。

修法：T2 新增三向一致性檢查——兩個常數彼此相等， 且都等於編譯後模型實際的 forcerange（那才是唯一真正限制出力的地方）。

#26 沒有東西驗證關節行程等於 SG90 的 180° 靜默 已修

同樣由變異測試發現。把行程放寬 20% 後：T2 的「未超出關節極限」因為極限也跟著放寬而 空洞地通過，而取放程式根本碰不到極限，所以完全沒有測試察覺。

修法：新增「每個關節的行程寬度 = SG90 的 180°」與「行程中心 = 舵盤索引角」， 兩者都從 datasheet 常數獨立推導，不依賴模型自己的值。

#27 模型常數被截斷成 6 位有效數字 已修

加上一致性檢查後才浮現：關節行程寫出來是 180.0004° 而不是 180°， forcerange 是 0.1765 而不是 0.1765197。MJCF/URDF 產生器用 %.6g／%.4g 格式化，把模型常數截斷了。

修法：關節極限、ctrlrange、forcerange、kp 全部改成 %.12g。 數值影響很小，但它會讓任何嚴格的一致性檢查無法收斂——而那類檢查正是抓出 #25/#26 的工具。

#1 pybullet 編譯失敗，還連累 mujoco 沒裝到 已修

pip install mujoco pybullet numpy 整筆失敗。pybullet 內附的舊版 zlib 在 zutil.h 第 128 行有：

#if defined(MACOS) || defined(TARGET_OS_MAC)
  #ifndef fdopen
    #define fdopen(fd, mode) NULL   /* No fdopen() */

現代 macOS SDK 會定義 TARGET_OS_MAC，於是這個巨集把 SDK <stdio.h> 裡 fdopen 的宣告污染成 NULL，clang 報 expected identifier or '('。

次生問題：pip 是單一交易，pybullet 建置失敗導致整筆回滾， 所以 mujoco 也沒裝上。錯誤訊息只提 pybullet，很容易誤以為 mujoco 裝好了。

修法：下載 sdist、註解掉那一行、重新建置。分開安裝 mujoco。

#2 手臂板比 SG90 鎖孔間距還窄 靜默 已修

板寬 26 mm，但鎖孔間距 27.2 mm。特徵普查顯示 Ø1.7 孔只有 5 個而非 6 個—— 有一顆孔完全落在材料外，切除運算移除了零體積，build123d 不會有任何反應。

修法：在伺服端加寬凸緣至 Y ∈ [−23, +13]。

#3 J5 掛在不存在的面上 靜默 已修

腕座的板材在 X ∈ [6, 10]，但 J5 用 s=+1 時耳片座應在 X < −6.8。兩顆鎖孔全部空切。

這個錯誤逼出了整個專案最重要的結構規則：關節手性必須交替（見設計章節）。 一開始我以為只要調整某個數字，實際上是拓樸層級的約束。

#4 夾爪舵盤沉孔把整個樞紐轂吃掉 靜默 已修

在 3 mm 厚的夾爪上切 4 mm 深的 Ø21.4 沉孔 → 變成貫穿孔，連帶把 Ø14 樞紐轂和 4 顆舵盤螺孔一起移除。 普查結果：Ø1.7 = 0、Ø3.0 = 0、Ø3.2 = 0，全部消失。

修法：主動指的轂加厚到 5 mm，沉孔改為只開在舵盤側的盲孔。

#5 兩片夾爪的轂互相干涉 已修

主動指的轂 Ø25.4（要吞下 Ø21.4 沉孔）、惰指 Ø14，兩樞紐間距原設 18 mm < 12.7 + 7 = 19.7 mm。

修法：樞紐間距加大到 ±11 mm，並把這個約束寫成程式碼註解，避免以後改動時再犯。

#6 干涉檢查抓到兩處互穿 已修

零件全部通過特徵稽核之後，成對實體交集運算仍然找出：

• 夾爪墊片互穿 51.7 mm³（閉合姿態下兩指的夾持面重疊 3 mm）
• 惰爪曲柄撞到腕部橋接件 12.0 mm³（Z 方向重疊 1 mm）

兩者的體積都和手算吻合。渲染圖完全看不出來——這是為什麼要算交集體積而不是看圖。

#7 慣性張量算出負值 已修

7 個連桿裡有 6 個的 Ixx／Iyy 是負的，物理上不可能。

根因：我假設 OCC 的 GProp_GProps::MatrixOfInertia() 回傳的是對參考點（原點） 的張量，於是用平行軸定理往回減。實測（把 10 mm 立方體移到 x=100，對角線數值不變）證明它回傳的是 對質心的張量——平行軸項應該是加而不是減。

教訓：函式庫的參考點約定用猜的不行，寫三行測試就能確定。

#8 扭矩少了 10 倍 已修

URDF 的 effort 是 0.0176 而非 0.1765 N·m。單位換算寫成 1.8 * 0.0980665 / 10.0——但 0.0980665 這個常數已經包含了 cm→m 的換算， 多除了一次 10。

為什麼重要：這個錯會讓手臂在模擬裡直接垮掉，然後我就會錯誤地推論 「SG90 帶不動這支手臂，要換 MG90S」——一個完全由單位錯誤製造出來的假結論。

#9 MuJoCo 沒有自動排除父子碰撞 已修

基座偏航關節在模擬裡完全不動（指令 −56.6°、實際停在 4.6°）。我原本以為是扭矩不足。

實際查接觸點：底座與轉盤的碰撞箱互穿 10 mm，產生 4 個接觸點，摩擦力把關節鎖死。 兩夾爪之間也互穿 1 mm。

修法：用 contype/conaffinity 位元遮罩分三組——機器人 (1, 6)、地面 (2, 5)、工件 (4, 3)， 機器人各連桿之間不自我碰撞，但都能碰地面與工件。

#10 解析 IK 的符號錯誤——往返測試抓不到 靜默 已修

我寫的 fk 與 ik 互相驗證通過，往返誤差 0.000 mm。 但兩者同時與物理模型不符，兩個錯誤在函式對內部互相抵消：

• 繞 +X 正向旋轉是把連桿往 −Y 倒，不是 +Y——手臂伸向了基座的另一邊
• 夾持點不在末端連桿的中心線上：實際偏離手臂平面 7.5 mm、距腕關節 73 mm， 而我假設的是沿連桿 77 mm。我還誤用了碰撞箱中心（local z=13）而不是夾持墊（local z=31）， 造成 18 mm 的高度差

症狀：工件位移 0.0 mm，夾爪根本沒碰到它。

修法：改用 mj_jacSite 對 MuJoCo 自己的運動學做阻尼最小平方數值 IK。 這消除了整類錯誤——因為只剩一份運動學描述，而且就是物理引擎在用的那一份。

教訓：自洽性測試（round-trip）證明不了正確性。要對外部基準驗證。

#11 數值 IK 卡在初始姿態 已修

不論給什麼目標都收斂到同一組角度、殘差 241 mm。原因是 mj_jacSite 需要 data.subtree_com，而 mj_kinematics 不會填它。

修法：補一行 mj_comPos。修好後殘差降到 0.04–0.11 mm。

#12 夾爪用外接盒當碰撞體，工件在搬運途中掉落 已修

工件被舉起 39.7 mm 之後掉回地面。逐格追蹤顯示兩片夾爪確實都接觸到工件， 但接觸幾何完全不對：夾爪的碰撞體是包含樞紐轂在內的整體外接盒（Y 向 26 mm）， 模擬中真正接觸工件的是這個大方塊的邊角，而不是設計的夾持墊。工件在夾合時被推歪 1.7 mm， 一加速就被擠出去。

修法：每片夾爪改用兩個依實際幾何定義的碰撞盒（手指 + 夾持墊），夾持墊另給較高摩擦。 修正後：舉高 50.0 mm、搬運 73.9 mm，成功。

教訓：碰撞體的簡化不是免費的。對夾爪這種接觸就是功能的機構， 外接盒抽象會直接摧毀被模擬的行為。

#13 腕關節需要 +118°，但 SG90 只有 ±90° 真實限制 已修

IK 要求手指在折疊姿態下垂直向下時，腕關節需 +118°，超出行程 28°。

修法：SG90 舵盤壓在 21 齒花鍵上，組裝時可以每 ~17° 換一齒重新索引。 把 j4 的舵盤偏移整整兩齒（34.29°），可用窗口從 ±90° 移到 −55.7°…+124.3°。這是實機上的標準做法， 所以做成正式參數 HORN_INDEX_DEG，並讓 URDF/MJCF 的關節極限跟著它一起算，避免兩邊不同步。

#14 +Y 側完全不可達 真實限制

手臂零位朝上，所有俯仰關節正轉都往 −Y 倒。要伸到 +Y 需要肩關節超過 +90°，超出行程。 IK 在該側殘差 100 mm 且不收斂。

處理：這不是 bug 而是設計事實，把工件改放在 −Y 側，並在文件中明確記錄。 若要雙側作業，需要把肩伺服的舵盤重新索引（同 #13）。

#15 MuJoCo 離屏緩衝區預設只有 640×480 已修

要求 900×600 算圖時 mujoco.Renderer 拒絕配置，並直接把需要的 XML 片段印出來。

修法：在 MJCF 加 <visual><global offwidth="900" offheight="600"/></visual>。 （這是本清單裡少數會主動告訴你怎麼修的錯誤訊息。）

#16 step.parts 的 SG90 鎖孔間距與 datasheet 差 0.6 mm 未解

模型量到 27.2 mm，一般 datasheet 標 27.8 mm。本專案的座槽依模型實測值開孔， 所以 CAD 內部是自洽的；但如果要用實體 SG90 組裝，必須先量過手上那批的實際間距， 或把鎖孔改成長孔以吸收差異。

沒有解決——手邊沒有實體件可以量。這是已知風險而非已修正的問題。

#17 「模擬時間預算」被當成錯誤，三個正常範例全部編譯失敗 已修

沙盒的四個內建範例，有三個一編譯就報「模擬時間超過 60 s 上限」。

根因：我把兩件意義完全不同的事用同一個常數處理—— 「要模擬多長」和「無窮迴圈防護」。Arduino 的 loop() 本來就會永遠重複， 跑到時間預算是「模擬夠了，乾淨截斷」，不是錯誤；只有「迴圈裡完全沒有 delay()」 才該當成錯誤擋下。

修法：拆成 BUDGET（截斷，附警告）與 MAX_STEPS（真錯誤）。

#18 底座被畫成一整塊平板，還蓋住手臂 已修

3D 預覽直接拿碰撞箱當視覺幾何。碰撞模型裡整個底座（底板＋塔身＋推力環） 是一個 100×100×39 的方塊，畫出來就是一片巨大平板，手臂看起來浮在上面。

同時深度排序用的是投影前的中間量，導致這片大平板會被排到手臂前面。

修法：視覺幾何另外定義（底板方塊＋塔身圓柱＋推力環圓柱，尺寸仍從 CAD 常數來）， 並把排序改用真實的相機深度。順帶替繪製器加了圓柱基本體——碰撞模型用不到，但眼睛需要。

#19 伺服模型比對腳本自己差了一格，誤報「兩邊不一致」 已修

JS 與 Python 伺服模型的比對顯示每個關節都差 6.000°——一個可疑的整齊數字。 6.0° 正好等於一個迴轉步長（10.472 rad/s × 0.01 s）。

根因在測試腳本：JS 是「套用事件 → 前進伺服 → 記錄」，我的 Python harness 卻是 「記錄 → 前進」，取樣相位差一格。模型本身沒有問題，對齊之後是 0.00000° 逐位元一致。

教訓：測出來的差異若在所有通道上都一模一樣，先懷疑量測而不是被量測的東西。

#20 直線度測試量錯了段落 已修

「lineTo 要走直線」的測試失敗，偏離 69.77 mm。但那段路徑包含了開頭的 moveTo——關節內插，本來就該走弧線，那正是整個對照要展示的差異。

修法：改成分開量。整段（含 moveTo）必須明顯彎（實測 69.8 mm）， 純 lineTo 段必須是直的（實測 0.003 mm）。這樣兩個方向都被測到。

#21 逆向運動學的精度被 write() 量化吃掉 真實限制

IK 把末端解到 0.1 mm 以內，但 Servo.write() 只能表達 181 個整數角度（間距約 1.03°）。 規劃路徑與伺服實際到達的路徑之間因此存在一段無法靠改進求解器消除的誤差， 在渲染圖上表現為藍色軌跡的高頻抖動。

沒有「修」，而是量化並揭露：對照頁把「求解器規劃 vs 伺服實際」單獨列成一項。 要真的改善，得改用 writeMicroseconds()（解析度約 10 倍）或換伺服。

#28 v2 的伺服耳片螺絲頭埋在實心塑膠裡 靜默 已修

T8 報「9/32 根螺絲兩側都被擋住」，同時長度挑選器一直選出 M2×16。兩個症狀是同一個病根。

v1 的「托架」是薄板，v2 改成一根從 X=−29.2 貫穿到 +10.8 的實心錐形樑。伺服窗與耳片凹槽 只清掉本體那一帶，而耳片孔位在 Y=8.2 / −18.9，落在窗外——那條線上樑是實心的。 沿孔軸實測材料 17.0 與 20.4 mm：螺絲頭埋在實心塑膠中間，沒有地方伸起子。

修法：在座板背面加一組 Ø5.6 起子井（servo_screw_access）， 從座板背面往外貫穿，同時給螺絲頭一個座面、給起子一條通道。真實列印托架本來就有這個沉頭井。

為什麼看圖抓不到：這是「實心體內部」的問題，任何外部視圖與爆炸圖都看不見； 只有沿孔軸量材料長度才會浮出來。

#29 「可咬合深度」量的是孔的包絡，不是材料 已修

螺絲長度由 bore.hi − bore.lo 決定。但螺絲穿過托架後是空氣、再到對面壁， 包絡把空氣也算成可咬合深度，於是 4.2 mm 的托架被判定需要 M2×16。

修法：material_along_bore()——在孔壁外套一圈薄環狀探針， 以體積除以環面積得到沿孔軸的真實材料厚度。BOM 最長從 M2×16 降到 M2×10，M2 總數仍為 30。

順帶抓到的自身 bug：探針長度原本寫 (hi−lo)+4，會超出孔的兩端而飽和， 回報出「9.9 mm 的孔裡有 13.9 mm 材料」。已夾到孔本身的跨距。

#30 起子路徑用「成品全機」判定 已修

這一項不是零件的錯，是檢查問錯了問題。伺服耳片螺絲是在「伺服單獨坐在托架上」時鎖的， 下一節連桿的叉臂之後才套上去。拿成品狀態去問「起子伸得進來嗎」， 會把任何雙剪設計的每一根耳片螺絲都判成缺陷——這就是 9/32 的來源。

修法：改成順序感知。依零件編號建立裝配順序，每根螺絲只跟 「到它為止」的零件集合比對。修正後 0/32。

教訓：一個檢查失敗時，先確認它問的是不是你真正想問的事。這一輪三個失敗裡有兩個屬於這類。

#31 夾爪曲柄銷正落在舵盤的螺栓圓上 已修

T8 報 M3×12 × M2×6 干涉 13 mm³。曲柄銷在夾爪局部座標 (y=4, z=−6)，半徑 7.2； 舵盤四顆螺孔在 BC14 的 ±45°，最近那顆在 (4.95, −4.95)。兩者相距只有 1.4 mm， M3 與 M2 直接互穿。

修法：曲柄銷移到 (y=4, z=−11.5)，半徑 12.2，離螺栓圓 5.2 mm；連桿與曲柄臂一併跟著加長。

#32 R7 的「孔周 2 mm 壁厚」在 SG90 上不可能 真實限制

T10 報 p1_base 等處只有 78%。但這不是設計沒收斂，是算術：

耳片孔距 27.2  →  孔心距伺服中心 ±13.60
本體長   22.5  →  本體壁在      ±11.25
                 孔心到本體壁 =   2.35 mm
                 − 落入座槽的間隙 0.40
                 − 攻牙孔半徑     0.85
                 ─────────────────────
                 壁厚上限         1.10 mm

孔距與本體長度都是伺服的固定尺寸，即使間隙為零上限也只有 1.50 mm。 MeArm、EEZYbot 同樣是這個數字。

處理方式：不偷偷放寬門檻，而是把門檻從 SG90 常數推導出來再檢查 （TAB_FLOOR = HOLE_PITCH/2 − BODY_L/2 − FIT_CLR − TAP_D/2）。 這樣「達不到的標準」變成「可驗證的預測」——10 個耳片孔全部剛好達到 1.10 mm。 與 R12 vs R1 同一類，已記為規則衝突 R7b。

#33 壁厚檢查把刻意留的凹槽當成缺料 已修

加了起子井之後，耳片孔的壁厚讀數掉到 45%。連續兩次歸一化都錯：

• 同軸大孔：起子井與螺孔同軸，環狀探針把井本身算成缺料。缺 22%、 而井與孔重疊 2.5/9.9 = 25% —— 數字對得太準，是假象。
• 非圓形凹槽：改用同軸裁切後仍是 45%，因為耳片凹槽是方盒， 同軸裁切抓不到。
• 環半徑算錯：探針環跨 [x+0.10, x+0.75]，我用 x = r+floor−0.30， 等於拿 1.55 mm 的標準去量 1.10 mm 的門檻。

正解：不用幾何跨距當分母，改用孔壁本身有材料的那段長度 （最內圈探針的讀數）。井、沉頭、凹槽一律在分子分母同時消掉，也不再需要任何特例裁切。 修正後 33 個非耳片孔全達 2 mm、10 個耳片孔全達 1.10 mm。

誠實的保留

以上是調查結果，不是實作。我沒有在這台機器上真的裝 ROS 2、沒有跑過 MoveIt、也沒有把本專案的 URDF 餵進 ros2_control。 套件可用性是查 conda channel 的 metadata 確認的（真實查詢，非推測）， 但「查得到套件」與「接起來會動」之間還有距離。

另外一個要先想清楚的取捨：接上 ROS 2 會讓本專案失去目前最大的優點—— 現在整條鏈（CAD → URDF → MJCF → 模擬 → 韌體）是自足的、可用 205 項檢查釘住的。 換成 MoveIt + ros2_control 之後，IK 與控制器變成外部黑箱， T1（解析解對照）、T4（差異測試）、T7（黃金回歸）都要重新設計成「驗證我們怎麼用它」 而不是「驗證我們算得對」。這不見得不值得，但那是另一個專案的規模。

結論：本專案的真正瓶頸是硬體選型，不是軟體

四個領域查完之後收斂到同一件事。SG90 是開環的，於是：

• ROS 的執行期驗證做不到——沒有狀態可監視，MTL 性質也就無從判定
• SAGE 的配對比對做不到——實機那側沒有位置／速度／力矩
• LeRobot 的模仿學習做不到——遙操作要靠領導臂的反驅與位置回報
• 205 項檢查因此結構上只能停在 verification

三條出路，代價各不相同：

1. 外加感測器（AS5600 ×5 + TCA9548A + INA219）。保留 SG90 與整套已驗證的數字， 成本最低，但要自己接線與寫韌體，而且電流換力矩本身是個需要校正的近似
2. 換匯流排伺服（STS3215 之類）。一次拿到位置／速度／負載／溫度， 還打開 LeRobot 整個生態。代價是整支手臂要重畫——伺服外形、扭矩、 安裝介面全都不同，驗證項目裡與 SG90 常數綁定的部分（例如推導出 1.10 mm 壁厚上限的那條）全部作廢
3. 維持現狀，明確承認邊界。把本專案定位成「機構設計與模擬管線的驗證示範」， 不追求閉環。這是目前的狀態，也是我沒有擅自改動的理由

這是取捨而不是待辦事項，該由你決定。

#44 torque_is_peak 旗標裝飾了一整段時間 靜默 已修正

我在做 DM-J4310 的資料時就發現「7 N·m 是峰值不是連續」，於是加了 torque_is_peak 旗標並寫進註解。然後沒有任何東西強制它。 扭矩預算照樣拿峰值算伸距：

重力保持是連續工況。峰值是馬達在過熱前能短暫做到的事， 拿它算出來的手臂會在停下來的那一刻下垂，而試算表上一切正常。 兩支手臂分別被高估 32% 與 24%。

修法：預算改成強制檢查——峰值標記的致動器必須有連續值才算得下去， 沒有就印 擋住；連續值若只有單一來源就印 BUDGET_UNVERIFIED_BASIS。

#45 FT5425BL 的 245 N·cm 追不到任何出處 靜默 已修正

記錄裡寫 torque_ncm=245.0（25 kg·cm）。查下去發現：

• 原廠 feetechrc.com 的 FT54 系列頁：堵轉 28.5 kg·cm@8.4V
• 經銷商 aifitlab：堵轉 28.5、額定 9.5 kg·cm、質量 67.6±1 g

245 N·cm 兩者皆非，也找不到任何來源。它大概是從產品標題的 「25kg」直接抄下來的，而那是型號代稱不是規格。

額定 9.5 kg·cm 也不能照單全收：它剛好是堵轉的 1/3， 比例整齊得像經驗法則而不是量測，而且只有經銷商一個來源。 所以記錄成 torque_rated_verified=False， 預算會把這支手臂標為「依據未驗證」——不是擋住，是不讓「沒驗證」這件事消失。

#46 把 STEP 的整體包絡當成馬達本體 靜默 已修正

記錄寫 body=(62.60, 34.90, 20.00)，標為實測。確實是實測—— 但量的是整個 STEP 的包絡。拆成實體逐一看：

拆開之後 STEP 與資料表完全吻合：40.6 / 20 / 30.9 對上 A=40.6、B=20、C=30。 用包絡當本體，會讓手臂裡每一個間隙悄悄放大最多 22 mm—— 反過來（用本體當包絡）則會讓干涉檢查漏掉。所以兩個欄位分開存。

同時查出安裝孔的真實位置：Ø4.50、四孔、X 間距 49.50、Z 間距 10.00， 但相對輸出軸是 −36.25 / +13.25，不對稱—— 輸出軸偏在一端，跟 SG90 一模一樣的陷阱。

#47 新測試層自己有兩個循環／看不見的檢查 靜默 已修正

為上面三件事寫了 D0 致動器資料層，13/13 一次全過。 照例先做變異測試，結果只有 2/4：

(a) 峰值檢查是循環的。我寫成 if a.torque_is_peak: 檢查沒被當成保持扭矩—— 把旗標拿掉，檢查就整條關掉了。等於「只在已經宣告的時候才檢查宣告」。
修法：改成不看宣告、只看兩個數字的關係—— 若記了一個較低的額定值，主數字依定義就不是連續值。 這條拿掉旗標也不會閉嘴。

(b) 孔位檢查只比跨距。把 SG90 的 −18.95/+8.25 改成對稱的 ±13.6，跨距一樣是 27.2，檢查照過—— 而那個不對稱正是這個欄位存在的全部理由。
修法：回去量 STEP 幾何。 用「最多圓柱面共用的軸心＝輸出軸」定位，再比對孔對軸的偏移。 （第一版比對又寫錯：用 round(...,1) 撞到 36.25 的進位邊界， 把一筆準到 0.05 mm 的資料判成不符——改用容差。）

修完 4/4。SG90 那條目前是 SKIPPED：它的 STEP 裡找不到 Ø2.00 的孔， 記錄的 2.00 可能是螺絲尺寸而非孔徑。標成跳過並寫明理由， 不是讓它假裝通過。

#54 MJCF 的 frictionloss 是 0，代表模擬手臂完全沒有靜摩擦 靜默

報告說預設模擬器「僅有庫倫+黏滯摩擦，無法反映 SG90 塑膠齒輪的高靜摩擦」。 查下去發現比它說的更糟：兩份 MJCF 的 frictionloss 根本沒設，也就是 0——連庫倫摩擦都沒有，只有黏滯阻尼。

它引的論文是真的：Duclusaud 等人 《Extended Friction Models for the Physics Simulation of Servo Actuators》，並且開源了辨識工具 （Rhoban/bam）。三個模型是：

M1 庫倫-黏滯   τ = Kv·|θ̇| + Kc
M2 加 Stribeck  τ = Kv·θ̇ + Kc + exp(−|θ̇/θ̇ˢ|^α)·Kcˢ
M3 加負載相關   τ = Kv·θ̇ + Kc + Kl·|τm − τe|

但他們辨識的是 Dynamixel MX-64/MX-106 與 eRob 諧波減速機， 沒有一顆是 9 g 的塑膠齒輪 SG90——參數不能直接搬。 而要辨識就需要實體與擺錘試驗台，那是本專案定義上沒有的東西。

所以不憑空指定一個數字，改成把它當不確定度處理 （ASME VVUQ 對未知參數的標準做法）：掃過 0–25% 堵轉扭矩的合理範圍， 看哪些結論撐得住。

結論分成兩類：

• 撐得住的：任務成敗（四個取樣點全成功）、搬運距離（離散 <0.5%）、 以及扭矩包絡那節的 44.7%——因為峰值扭矩取自 qfrc_bias（重力/科氏）， 摩擦根本不進入那一項
• 撐不住的：舉高。0→25% 之間掉 12%， 所以本頁原本寫的「最大舉高 +50.0 mm」是無摩擦上界，不是值。 已更正為區間。

零摩擦不是中性預設，是最樂觀的那一端——這句話現在是 tests/suite_uq.py 的第一條檢查，而不是一句散文。 新增 U1 不確定度層 6 項，含「摩擦越大舉得越低」的單調性檢查 （摩擦只會吃能量不會給能量，非單調代表求解器出問題而非物理）。

#55 齒輪虛隙（backlash）從未建模 靜默

報告指出 SG90 的 4–5 級塑膠齒輪有 1–3° 虛隙，剛體 URDF 表現不出來。 查證：backlash 這個字在整個 repo 只出現一次， 而且是在 FT5425BL 檔頭講皮帶虛隙的註解裡——關節虛隙確實沒有建模。

影響方向與摩擦相反：虛隙讓關節在換向時有一段不受控的自由行程， 會使定位誤差變大、也會讓夾爪在夾持瞬間有一段空行程。 以 1–3° 計，對 202 mm 的手臂尖端是 3.5–10.6 mm 的位置不確定—— 比目前報出的任何追蹤誤差都大。

MuJoCo 沒有原生的虛隙關節，要做得用兩個關節加軟約束或 solreflimit 的死區來近似。暫不實作， 理由與摩擦相同：沒有實測參數，做出來只是把一個猜測寫得像測量。 記為明確的驗證缺口，並列進已知限制。

#56 多顆舵機同時堵轉的電壓驟降沒有進模型 靜默

報告指出峰值電流可衝到 500–700 mA/顆，與控制板共用電源會使電壓掉到 4.2–4.5 V，實際扭矩比理論值衰減 20% 以上。

本專案有寫電源要獨立（韌體註解與製作清單都寫了 「五顆舵機需外部 5–6 V ≥3 A」），但模型裡的堵轉扭矩是定值， 不隨同時動作的軸數衰減。也就是說：接線建議有了，模型沒跟上。

這一項可以在不買硬體的情況下部分處理——電壓-扭矩關係是線性的， 資料表給了 4.8 V 與 6 V 兩點。但同時動作幾軸、電源內阻多少， 仍然是未知參數，所以處理方式與摩擦一致：下一步做成 U1 的第二個掃描維度， 量「扭矩衰減 0–25% 時哪些結論還成立」。

#58 產生這張對照表時，資料自己揭穿了 #48 只改到一半 靜默 已修正

對照表第一版印出 SG90　0.18 N·m　依據：連續。 但 0.18 N·m 是堵轉值——#48 就是在講這件事， 而我當時只更正了頁面上的敘述，沒有更正資料。

D0 有一條規則正是為此存在：「若記了較低的額定值，主數字依定義就是峰值」。 它對 SG90 不觸發，因為 SG90 根本沒有額定值可以比—— 那條規則的盲點就是「什麼都沒記」的情況。

修法：SG90 的 17.6 N·cm 標為峰值，並依同一套 1/3 慣例補上未驗證的額定值 （與 FT5425BL 的處理一致）。改完之後：

SG90 額定 0.059 N·m
第一支手臂最壞姿態 0.0788 N·m  →  134% 額定

與 #48 的結論完全一致——只是現在資料本身這樣說， 而不是靠一段散文說。

為什麼是「產生一張表」揭穿的：那張表把四支手臂的同一欄位排在一起。 單獨看 SG90 的記錄，「0.18 N·m」沒有任何不對； 和另外三支的「額定」並排時，「連續」兩個字才顯得刺眼。 對照本身就是一種驗證，這也是為什麼這張表要由程式產生而不是手打。