LOG93R2R2R2026/3/14

mechArm 270のPickAndPlaceデータ収集を始めた｜Unity × Python記録設計

ロボットアームに「記憶」を持たせた日

FixedJoint把持ループが動いた。ミッションは3つ。

関節制限値の修正（Elephant Robotics公式スペックへの準拠）
CSV出力の実装（動きをデータ化する）
把持方式の刷新（FixedJoint → IsKinematic追従）

※注釈：デジタルツイン学習（R2R2R）の検証プロセス本プロジェクトは、AIの判断を物理的動作へ変換する設計を検証するものです。現実空間をデジタルツイン化し、仮想空間での大量試行（Real-to-Render）から得た最適解を、実世界のモーター駆動（to-Real）へ還元する「R2R2Rパイプライン」の実装過程を記録・考察します。

関節制限値の修正

URDFと実装にズレがあった。

関節	修正前	修正後
link3 upper	65°	45°
link5 upper	+115°	+100°
link5 lower	-115°	-100°

たった3つの数値変更。でもこれがないと、アームが「物理的にあり得ない姿勢」を取ろうとして暴れる。正確な制限値は、安定したIKの前提条件だ。

CSV出力の実装

ロボットの動きを数値で記録する。取得したデータは2本のCSVに分かれる。

robot_frame_log.csv — 毎フレーム記録

6軸の関節角度・速度・トルク
EndEffector位置（X/Y/Z）
現在ステートと距離

robot_event_log.csv — ステート遷移時のみ記録

TO_GRASP / GRASP_START / TO_REACH_PLACE / TO_PLACE / PLACE_DONE / TO_REACH_CUP

実際に10秒間Playして取得したevent_logの一部：

0.0619, TO_GRASP,        0.1662
0.0701, GRASP_START,     0.1747
1.5618, TO_PLACE,        0.0299
1.5667, PLACE_DONE,      0.0299
3.0616, TO_GRASP,        0.0085

ループ周期が約1.5秒で安定していることが読み取れる。「動いているように見える」から「数値で確認できる」へ。これが本質的な変化だ。

把持方式の刷新：FixedJoint → IsKinematic

以前まで使っていたFixedJointが機能しなかった。カップがアームに追従しない。

原因はUnityのArticulationBodyの仕様。ArticulationBodyの階層内にRigidbodyを配置した場合、FixedJointによる接続が正常に機能しない。

解決策は方式の全換。

GRASP時：
  cupRb.isKinematic = true     ← 重力・物理から切り離す
  毎フレーム: cup.position = endEffector.position  ← 強制追従

PLACE時：
  cupRb.isKinematic = false    ← 重力・物理に戻す
  1.5秒後: cup を初期位置にリセット

コードから「FixedJoint」という単語が消えた。シンプルになった。そしてカップが初めてアームと一緒に動いた。

震え問題と限界

IsKinematic方式への変更で把持は解決した。しかし新たな問題が浮上した。

ループを重ねるとアームが加速する。折り返し時に震える。

原因は drive.target の蓄積。CCD IKは毎フレームtargetに角度を加算するため、サイクルを重ねるほど「目標値と実際の角度のズレ」が蓄積していく。クールダウン時にIKを止める、ResetCooldown時にtargetを物理角度に同期する——様々な対処を試みたが、根本解決には至らなかった。

把持は動いた。しかしループの安定性は未達だ。