【論文読み会】RoboFactory: Exploring Embodied Agent Collaboration with Compositional Constraints

2025年度前期第1回 論文読会 RoboFactory: Exploring Embodies Agent Collaboration with Compositional Constraints 3つの制約で、ロボは協調する Yiran Qin, Li Kang, Xiufeng Song, Zhenfei Yin, Xiaohong Liu, Xihui Liu, Ruimao Zhang, Lei Bai ICVV 2025（POSTER）/ arXiv 2503.16408 https://github.com/MARS-EAI/RoboFactory https://iranqin.github.io/robofactory/ KaiRA社会人メンバー 柴田 たけお 0

• https://github.com/MARS-EAI/RoboFactory
• https://iranqin.github.io/robofactory/

目次 ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ 論文概要(ABSTRACT) 合成制約が支える多腕強調 はじめに(INTRODUCTION) 関連研究(Related Work) 合成制約(Compositional Constraints) RoboFactory 実験 結論 データ生成パイプライン 公開GITHUBレポコマンド解釈 補足 所感

ABSTRACT - 論文概要 1 3 5 課題 2 提案 マルチエージェント（多腕）環境で、 合成制約（論理×空間×時間）と、その制約を 安全かつ効率的な学習データの自動生成が難しい 物理世界に適用するインターフェースを設計。 。 粋組み 4 成果 合成制約にもとづく マルチエージェント操作の新ベンチマーク 自動データ収集フレームワークを構築。 RoboFactory を公開（データ生成→評価まで） 検証 模倣学習を適用し、タスク難度やアーキ設計の 有効性を実証。 。 RoboFactoryは「ベンチマークの提案」でもあり、 「データ収集フレームワーク（方法論）の提案」でもあります。 「データをどう作るか」＋「そのデータで何を測るか」を 同時に提示。 **フレームワーク：合成制約（論理×空間×時間）＋ 制約インターフェース（RoboBrain / RoboChecker）で、 マルチエージェント協調の安全・効率なデータ自動生成を実現。 **ベンチマーク：ManiSkill上で1〜4台 / 11タスクの RoboFactoryベンチマークを構築し、 模倣学習（Diffusion Policy 等）で設計比較・難易度検証まで行う。

合成制約が支える多腕協調 合成制約が効く瞬間：4台で「持つ・揃える・押す」 • タスク：ステーキを掴み、カメラで撮影（4体のアーム協調） • 役割：a1＝ステーキ把持／a2・a3＝カメラを持って位置合わせ／a4＝シャッター押下 • 課題：各アームが単独最適に動くと 誤把持・衝突・無駄待ち が発生 解決＝合成制約（Compositional Constraints） • 論理：触る部位・方向・役割を指定（例：レンズは掴まない） • 空間：3D占有（ボクセル）で衝突回避（a2 a3 など） • 時間：同時実行／順序のスケジューリング（a1の把持→a4の押下） 効果：図の t₀ → tₖ のように、安全×効率でタスク完了（Feedback: Success）

INTRODUCTION – はじめに 背景・課題 • 現行の多くは単体ロボット向け。実社会の製造/医療などは複数エージェント協調が必須。 • 同時遠隔操作でデータ収集は非効率。LLMで単体向けの自動生成は進展したが、マルチ化では破綻しやすい。 • マルチ協調では少なくとも ①論理（役割/接触部位/方向）②空間（衝突回避）③時間（順序/同時実行） を同時に満たす必要がある 。 提案：合成制約＋フレームワーク（RoboFactory） • 合成制約（Compositional Constraints）： 論理×空間×時間でエージェント挙動を制御。 • RoboBrain：タスク記述＋観測からサブゴールと暫定軌道を生成（LLM/VLM＋モーションプリミティブ）。 • RoboChecker：テキスト制約を物理に写像するインターフェースで検証（違反検出→理由付き差し戻し→再計画）。 ねらいと効果 • 単体→マルチへのスケールで問題となる安全性×効率性を両立したデータ生成パイプラインを実現。 • さまざまな協調シナリオで設計を比較・評価可能。 貢献（3点） 1.合成制約の提案：マルチ協調に特有の課題（論理・空間・時間）を統合的に扱う概念。 2.RoboFactory：合成制約＋インターフェースによる自動データ収集フレームワークと、マルチ操作ベンチマークの提示。 3.実証：模倣学習（Diffusion Policy）を適用し、タスク難度・アーキ設計・訓練戦略を系統的に評価。

関連研究 2.1 Multi-Agent System 系統：(A) ツール連携型エージェント（自動化・支援）／ (B) 社会・ゲーム系シミュレーション 限界：意思決定や対話は扱えても、実機レベルの低層操作（多腕マニピュレーション）を安全・効率に扱う枠組みは希薄 対称的に本研究(RoboFactory)の位置：実世界指向の多エージェント協調操作に焦点（低レベル制御まで踏み込む） 2.2 Robot Manipulation 模倣学習：BC（デモ模倣）／ ORL（オフラインRL） 生成的アプローチ：ACT（Transformer + CVAE）や Diffusion Policy（DP/3D-DP） が高性能 デモ取得：人手操作が中心、シミュレータ合成は補助的 ギャップ：多エージェント操作の体系的データ生成・評価は未開拓 2.3 Visual Programming LLM + Vision によるゼロショット実行が拡大 ただし 細粒度の正確さ（接触部位/方向・衝突回避・時間整合）が不足しやすい 制約付き合成（例：CaM）などが台頭中 RoboFactory の新規性 ●合成制約（論理×空間×時間）＋制約インターフェースで“テキスト指示 → 物理世界の安全・効率”を橋渡し ●データ収集フレームワークと多エージェント操作ベンチマーク（11タスク）を一体で提示 ●既存の DP/BC などを上で 設計比較・難易度検証できる実験基盤を提供

合成制約(Compositional Constraint) ねらい：実世界の多ロボ協調で 安全 と 効率 を両立するために，論理・空間・時間 の 3種の制約を組み合わせて行動を縛る。 1) 論理（Logical） 何を・どこを・どう触るか（対象／接触点／方向／役割） 例：レンズは掴まない／指定ハンドルのみ把持／押す時は正面から 2) 空間（Spatial） どこで動けるか（占有／境界／ゾーニング） 例：衝突回避（3D占有）／作業域の分割／配置誤差 ≤ 2 cm 3) 時間（Temporal） いつ・どの順で動くか（同時実行／順序／締切） 例：2台同時持ち上げ ±0.5 s／A完了→5 s 後にB開始 合成（Compositional） * 論理＝プロトコルと共有目標 * 空間＝幾何学的・意味的境界 * 時間＝依存関係に沿った同期 → 局所の自律と全体の整合を両立：衝突なし・待ちなし・手戻りなしで頑健に実行。

RoboFactory: RoboBrain × RoboChecker で回す“制約駆動”データ生成 入力 タスク指示 G₍global₎（例：「4台で撮影」） 画像観測 O = {o_global, o₁…oₙ}（全体＋各アーム視点） 前回サブゴール G₍pre₎、違反フィードバック f₍pre₎、ロボット状態 S ① RoboBrain（基盤的VLM, 例：GPT-4o） 各エージェントの次のサブゴール G₍next₎を生成 併せてテキストの合成制約 C = {Cᴸ, Cˢ, Cᵗ}（論理／空間／時間）を出力 モーションプリミティブで暫定軌道 traj₁…trajₙを合成（※まだ未拘束） ② RoboChecker（制約インターフェース） テキスト制約 → 物理表現 hᵢ に写像 論理：接触点・方向・役割（VI/VD） 空間：3D占有/ボクセルで衝突検出（VSO） 時間：同時/順序の整合・スケジューリング（VS） CheckCodeで各ステップ検証： 違反→ 実行停止＆理由付き f₍pre₎ を返して再計画 合格→ サブゴール完了として前進 ループの効果 安全 × 効率で長尺マルチタスクを収束（時空間共有も考慮） 検証済み軌道＋観測を RoboFactoryベンチマークのデータとして蓄積 要点 抽象（テキスト制約）を物理に落とすインターフェースで、 計画 → 検証 → 再計画を自動ループ化し、マルチ協調の学習データを量産。

RoboFactory: 制約インターフェース ねらい：テキストの合成制約（論理・空間・時間）を物理的な判定基準に写像し、 各ステップの軌道を機械的に検証できるようにする。 ① 論理（Logical）— どこを・どの向きで触るか • 相互作用位置（Interaction Position）：各3Dアセットに接触点を注釈（例：カメラの“ハンドル”と“シャッター”は別） • 相互作用方向（Interaction Direction）：動作ごとの進入方向を注釈（例：シャッターは正面から押す） → 位置・姿勢がルールに一致しているかを判定 ② 空間（Spatial）— どこを占有し、衝突しないか • 深度＋関節状態から3D占有を構築（5cm³ボクセル） • 変化中のアームと周囲の占有関係をチェックし、衝突/侵入を検出 → 空間ロジック（作業域・最小距離など）に違反しないかを判定 ③ 時間（Temporal）— いつ・どう並行するか • サブゴールセット Gₙₑₓₜ に対し、動的占有の時間推移をモデル化 • 同時実行／順序の整合を解析し、非合理なスケジューリングを防止 → 「同時持ち上げ ±0.5s」「A完了→5s後にB」等を満たすかを判定 効果：テキスト制約 → 物理表現（位置・方向／3D占有／時間占有）→ 自動チェック 違反なら停止＋理由フィードバック→再計画、合格なら前進。 ⇒ 安全 × 効率なマルチ協調データを安定に生成。

RoboFactory: ベンチマーク 要旨 • 基盤：ManiSkill 上に構築（オープンソース物理シミュレータ） • 特徴：マルチエージェントかつ Plan（高位計画）＋Control（低位制御）を統合 • タスク構成：11タスク／エージェント数 1–4／Franka Panda（7DoF）ベース • アセット：PartNet-Mobility 等の公開 3D アセットを利用 • 観測：各アームのエゴ視点＋グローバルカメラ • データ：各タスク 150デモ（RGB 観測＋関節アクション）を事前収集 • 多様化：シード再現可能なドメインランダム化（初期配置など） 他ベンチとの比較（Table 1:右） • EgoPlan-Bench / MMWorld / VAB / RoboCasa：Single-agent / Plan中心 • RoboTwin：Plan & Controlだが Single-agent • RoboFactory（この研究）：Multi-agent かつ Plan & Control をカバー 代表タスク（Fig. 4 :右） • Align Camera：a1が対象把持、a2・a3がカメラ位置合わせ • Place Food：a1がフタ開け→a2が食材投入（役割依存） • Stack Cube：a1→a2の順序協調で積み上げ 狙い：エージェント間の協調効率（同時実行/順序）と安全性（衝突回避） を同時に評価・学習可能な実験基盤。

実験: Diffusion Policy ベースライン 設定 • ベンチマーク：RoboFactory 全11タスク • 学習：各エージェントごとに個別ポリシー （入力＝エゴ視点RGB、 他エージェントの状態は未使用） • デモ数：タスクごとに 50 / 100 / 150 で比較 （Table 2 右） 結果（成功率） • データ増で概ね向上 → 高品質データ自動生成の重要性を裏付け • 最良設定での平均成功率： 1-Agent：49%（150デモ） 2-Agent：32.5%（100デモ） ※150で低下＝過学習傾向 3-Agent：20.5%（150デモ） 4-Agent：10%（150デモ） • エージェント数↑で性能↓ → 協調の難しさが顕著 • Long Pipeline Delivery：0% → 長期依存や時系列計画が現手法の弱点 示唆 • マルチ協調ではデータ量・構造がより重要。 • 協調アーキと学習戦略の工夫が必要

実験: 多エージェント模倣学習 4つの設計 × 2視点：どの組み合わせが協調に効く？ 設計の軸（Fig.5 右） • 観測：Global View（全体） / Local View（各アームのエゴ視点） • 方針：Shared Policy（共有） / Separate Policy（各アーム別） 4アーキ 1) Global + Shared 2) Local + Shared 3) Global + Separate 4) Local + Separate（採用） 実験ポイント • 対象タスク：Lift Barrier / Place Food（2エージェント） • Shared Policyは失速：複数エゴ視点から「誰が実行者か」を 推定する必要があり難しい • Separate Policyが有利：腕ごとのスキルを分担学習でき連携が安定 • Local Viewが効く：接触点や姿勢など細粒度情報で 把持・整列が正確に 数値ハイライト • Lift Barrier：49% → 58%（Global+Shared → Local+Separate） • Place Food：5% → 20%（同上） 設計指針 • 各アームは自分の視点（Local）＋自分のポリシー（Separate） → 役割分担＋細粒度観測で協調成功率↑、誤動作↓。

実験: アブレーション 合成制約は本当に効くか？ 検証の狙い • Q1 成功率（= 有効データ生成スピード）を上げられるか？ • Q2 データ品質は上がるか？（指標：平均エピソード長 ↓） 主な結果（Table 4・5 右） • 3タスクすべてで 成功率↑／エピソード長↓ が最良 • 成功率：Lift 97.5 / 3-Stack 98.9 / TakePhoto 88.2 (%) • 長さ：Lift 80.7 / 3-Stack 424 / TakePhoto 204 （123 / 685 / 407 から短縮） → 短縮率の目安：−34% / −38% / −50% • Spatial（空間）が無いと衝突多発で成功率が大きく低下 • 例：Logical のみ 80.2/62.5/37.1 → Spatial 追加で 95.2/92.7/53.8 • Temporal（時間）は同時実行・順序の整合で品質改善 • Temporal 追加で TakePhoto 53.8 → 88.2%、長さ 325 → 204 • Logical（論理）は前提のプロトコル整備。Spatial/Temporalを重ねて 初めて安全×効率が両立 結論（デザイン指針） • 論理×空間×時間の“合成”が最適： Spatialで物理可否と安全、Temporalで並行度と順序最適化 → • 高成功率かつ短軌道でデータ生成を加速。

結論 • 合成制約（論理×空間×時間）で、単体→マルチ協調へ安全・効率に拡張 • RoboFactory：制約駆動の自動データ生成＋マルチ操作ベンチマーク • 模倣学習で有効性確認、協調ポリシー設計の指針を提示 Limitations：微小接触・摩擦・変形など精密物理の表現に限界あり （高精度モデルや実機検証が今後の課題）

データ生成パイプライン
Task / Images / Previous Feedback
│
▼
GPT-4o (RoboBrain) ── subgoals + constraints (text/JSON風)
│
例: {"Logical":...,"Spatial":...,"Temporal":...}
│ (Pythonパーサで数値引数に変換)
▼
Motion Primitives (Python関数)
MOVE/GRASP/LIFT/ALIGN/PRESS(...params)
│ └─ 目標姿勢(SE3)・接触点・進入方向・速度など
▼
Trajectory Generator (Python)
目標の離散軌道: waypoints → action 列
形式: trajectory ∈ ℝ^[T × (8 × N_agents)] # Franka=7関節+gripper=1
│
▼
Simulator (ManiSkill / SAPIEN)
step(action_t) at t=1..T ── obs_t
入力 action_t: ℝ^[8×N] (float32)
出力 obs_t:
- RGB画像: uint8 [H×W×3]（例 320×240）
- 状態: q∈ℝ^7, qd∈ℝ^7, gripper∈ℝ^1（float32）
- （任意）接触/衝突フラグ等
│
▼
RoboChecker (Python + GPT-4oでCheckCode生成)
テキスト制約 + obs + trajectory → 物理インターフェースで検証
VI=Validate_Interaction（接触点）
VD=Validate_Direction（進入方向/姿勢）
VSO=Validate_Spatial_Occupancy（3D占有/衝突）
VS=Validate_Scheduling（同時/順序）
出力: {valid: bool, reason: str}
├─ valid=false → reason を Feedback として RoboBrain に戻して再計画
└─ valid=true → 次ステップ/次サブゴールへ

概念フロー
• RoboBrain（GPT-4o）
• 入力：タスク指示（text）、観測（画像/要約）、前回の違反理由（text）
• 出力：subgoals（text/JSON風）、constraints＝{Logical/Spatial/Temporal}（text）
• テキスト→（Pythonパーサ）→ モーションプリミティブ（
MOVE/GRASP/LIFT/ALIGN/PRESS(...)）呼び出し → 暫定軌道を合成
• Trajectory / Action
• 形式：trajectory ∈ float32 [T, 8×N_agents]（Franka：7関節＋gripper=8
）
• 実行時（Gym）はマルチアームなら {uid: action8} の辞書を渡す実装もあり
（保存は連結形が多い）
• Simulator（ManiSkill / SAPIEN）
• 入力：action_t ∈ float32 [8×N]
• 出力（Observation）：画像 uint8[H,W,3]（＋必要なら Depth/Seg）、
状態（q, qd, gripper など float32）
• RoboChecker（Python + GPT-4oでCheckCode生成）
• テキスト制約＋obs＋trajectory → 物理インターフェースで検証
• VI（接触点）／VD（進入方向）／VSO（3D占有）／VS（同時・順序）
• 出力：{valid: bool, reason: str}
（false なら理由を RoboBrain に返し再計画）
要点：計画・制約生成＝GPT-4o（テキスト）／実行＝数値アクション。
RoboCheckerがテキスト制約を数値の判定に写像し、検証→再計画で安全・効率に収束。

RoboBrain での GPT-4o 利用サンプル タスク指示・観測・過去の違反を入れて、 サブゴールと合成制約（Logical/Spatial/Temporal）を 構造化テキスト/JSONで出させるプロンプト。 RoboChecker 側での GPT-4o 利用サンプル “テキスト制約 → どの検証器(VI/VD/VSO/VS)をどう呼ぶか” のCheckCode生成。

公開GITHUBレポのコマンド解釈
GITのサンプルではLift Barrierを例示しているがTake Photoを試行

python script/run_task.py configs/table/take_photo.yaml # 1エピソードだけ“手書きプラン”で実行・可視化
*tasks/take_photo.py #タスク本体、4アーム構成,「物体を所定位置へ」「カメラ2本で整準」「最後の1本がシャッター押下」等の成功条件や観測を定義
*planner/solutions/take_photo.py #モーションの台本、これが起動の設計図
*planner/motionplanner.py #間接角のシークエンス
*assets/objects/{camera,meat}_annotated}/model_data.json #例えばcameraであれば left_handle / right_handle / shutter 等のラベル付き点・法線を記録
*configs/table/take_photo.yaml #オブジェクトをどこに置くか、アームの初期姿勢、カメラの位置/解像度、乱数ゆらぎなどを記述。randp_scale / randq_scale
に基づく物体配置・姿勢の微小ランダム化
>>>最初の環境設定などは乱数で揺らぐがその後と手続きはすべて決め打ち

python -m robofactory.script.generate_data --config robofactory/configs/table/take_photo.yaml --num 150 --save-video #模倣学習データ生成
>>>基本は上記RUN_TASKと同じだがManiSkillで試行を繰り返し、指定数「成功エピソード」が貯まるまで回し成功回だけを保存,模倣学習用の学習データにする。
上記150の成功起動データを学習データとして模倣学習させる。
GitHub版には，論理／空間／時間の“汎用制約インターフェース（RoboChecker）”は省略されている。
代わりに，制約は「台本＋注釈＋物理エンジン」に“埋め込み”で近似
RoboFactory Task "Takeo_Photo"

http://www.youtube.com/watch?v=A8sFRM80BuQ

• http://www.youtube.com/watch?v=A8sFRM80BuQ

補足 何をシミュレートしている？ ● ● ● ● ロボット：Franka Emika Panda（7自由度）＋平行グリッパ（シミュレータではグリッパ1DoFとして扱い、1アーム=8次元：7関節＋グリッパ） 台数：タスクにより 1〜4台（TakePhoto は4台など） 制御：関節位置制御（pd_joint_pos）で action_t ∈ ℝ^[8×N] を毎ステップ投げる 観測：各アームの視点RGB＋グローバルRGB（Depth/Segは構成次第） 実世界で互換性が高い実機は？ ● Franka Emika Panda ＋ Franka Hand ○ DoF・関節順・可動域・位置/インピーダンス制御が近く、libfranka/ROS のエコシステムも豊富。 ○ マルチビュー・エゴ視点カメラも現実に取り付けやすい。 その他代替（調整必要） ● ● Kinova Gen3（7DoF）、KUKA LBR iiwa（7DoF）、UFactory xArm 7（7DoF） ○ 7DoFで軌道生成・可動域の相性は比較的良い。 ○ グリッパはRobotiq 2F-85/140等の平行グリッパを使うとシミュレーションの把持モデルに近づく。 UR5e（6DoF） ○ 6DoFでも可だが「冗長性なし」になるため台本（solutions）やIKを少し調整が必要。 https://robodk.com/robot/ja/Franka/Emika-Panda Robotic Materials’ Smart Hand on Franka Emika’s Panda Bin picking using the FCI research interface sim→real の実務チェック（要点） 1. 2. 3. 4. 5. 6. 関節順序・正負・リミットを合わせる（Franka準拠） 座標系（ベース/EE/カメラ）と単位（m・rad）を一致 グリッパ開度→実機幅のスケーリング カメラ：内外部パラメータ・取り付け位置を YAML と揃える 制御周期（シミュレータのΔt vs 実機制御周波数）と遅延を補償 把持点注釈（model_data.json）の接触点・方向を実機に合わせて再定義可能にしておく **論文&実装は“Franka Panda前提のマルチアーム操作”**です。 http://www.youtube.com/watch?v=DTJi9ttrViY

• http://www.youtube.com/watch?v=DTJi9ttrViY
• https://robodk.com/robot/ja/Franka/Emika-Panda

補足

所感 面白い着眼と試みだが、以下の精度だとまだまだシミュレーター内での精度向上が必要 （実機投入:SIM2REALをするに80%以上がほしいところ、まだまだ改善必須） 1. データ＆表現を強化 データ数のさらなる追加、難サブタスク追加収集 協調特徴（相手状態・同期トークン）入力 1. シミュレータを現実寄りに ○ 摩擦・剛性・ダンピング カメラノイズ・遅延・露出 制御周期・飽和を実機仕様に近づける 1. 制約を推論時に併用 ○ 生成ポリシー + RoboChecker風制約 ガイド／軽量リプランで失敗リカバリ 1. 実機での少量FT＋フィードバック ○ 10–50エピで微調整 → Simパラメータにも反映して 次サイクルを強化