URDF 動力学ツールチェーン構想

URDF を中心データにした検証・同定・重力補償ツール群のロードマップ。Pinocchio ベースの skill + Artifact ビューアの二段構え

要点 #

URDF を表示物ではなく実機開発の中心データにする。エンジンは Pinocchio (再発明しない)、作るのはその上の検証・書き出し層と可視化層。

背景 #

STEP から URDF を生成する手段は整備済み (step-to-urdf-freecad、ForteFibre/skills の step-to-urdf)
生成直後の URDF の慣性は概算 (体積 × 仮定密度 + bbox 近似)
GUI で編集・検証できる URDF ツールは空白地帯 (urdf-viewers-and-editors)
Pinocchio が URDF から τ_g(q)・RNEA・同定用回帰行列を直接出せる

機能リスト #

モデル ↔ 実測の突き合わせ (優先度 1)#

実測残差の可視化: MCAP ログの関節角・電流と、RNEA によるモデル予測トルクを重ね描き。残差の形で摩擦・質量誤差・バックラッシュを切り分ける
同定ループ: 励起軌道生成 → 実機走行 → MCAP 回収 → 回帰行列 + 最小二乗で慣性パラメータ推定 → URDF に書き戻し。概算 URDF を実測校正済み URDF に育てる
摩擦同定: 等速運転ログから Coulomb + 粘性を推定し <dynamics> に反映

設計検証 (優先度 2)#

モータ選定検証: 想定軌道の必要トルク・速度系列を T-N 曲線と照合。減速比スイープ
TOPP-RA 接続: 同定済み動力学 + トルク上限で時間最適軌道 (topp-ra)
ワークスペース・可操作度マップ
消費エネルギー・発熱見積もり (電流二乗積分)

ファーム・運用への出口 #

重力補償テーブルの C 配列生成 (格子評価 + 補間コード)
URDF lint の CI 化: 慣性の物理的整合性 (正定値・三角不等式)、limit 妥当性、メッシュ参照切れ。 → 独立ツールにせず生成器の check サブコマンドに統合する (generate = check 通過後に出力、check = 検査のみで exit code)。生成器が URDF + base.yaml の全情報を持つので、CAN ID 重複や「URDF の limit vs base.yaml の limit」の横断整合性まで検査できる。 launch の $(command) が失敗 = 起動が止まる fail-fast。ルール on/off (--disable) は warning 級のみ。エラー級 (物理整合性・ ID 重複) は常時有効に固定し、本番だけ緩める運用を作らない

ビューア拡張 #

IK (4 軸なら閉形式)
軌道再生: CSV / MCAP の関節角系列をアニメーション
重心・慣性楕円体・重力トルクのオーバーレイ

実装形態 (2026-08-25 改訂)#

WebUI 主体。Robot-Path-Editor と同じ構成 (Vite + TypeScript、 GitHub Pages + fortefibre.net サブドメイン) に載せ、環境構築ゼロでチーム全員が使える形にする。

WebUI: 表示・編集・同定計算・ファイル書き出しまでほぼ全機能。
- MCAP 読み込みは Foxglove 公式の @mcap/core (JS)
- 動力学 (RNEA) と同定用回帰行列は TypeScript 自前実装 (シリアルアーム限定なら現実的。RNEA は 100 行程度)
- 最小二乗は正規方程式の逐次計算でメモリに畳む
- 実機ライブ表示は foxglove_bridge / rosbridge への WebSocket
- 書き出しはファイルダウンロード (patheditor 方式)
ローカル skill: 補助に縮小。
- TS 動力学実装の検証用リファレンス (同一入力で Pinocchio とトルク一致を確認、CI 化)
- URDF lint の CI
- 大量ログの一括処理

Pinocchio は WASM 版が無くブラウザでは動かない。これが自前実装の理由。自前動力学は符号・座標系ミスに気づきにくいので、Pinocchio 突き合わせを必ず CI に入れる。

既存資産との接続: MCAP 解析 skill (ros2-mcap-analysis)、step-to-urdf skill、 pid-ff-autotune、ff-stack

同定モードの判定基準 #

「URDF の有無」ではなく「FF が姿勢の関数かどうか」で分ける:

姿勢依存 (多関節アーム、昇降を含む機構): URDF 必須。回帰行列・励起軌道設計・交差検証・URDF 書き戻しのフルパイプライン
姿勢非依存 (1 軸: ステア軸・ホイール軸・ベンチ単体): URDF 不要の軸単体モード (J + 摩擦の 1 自由度同定)。ただし結果はサイドカーに記録し、後でその軸が URDF 化された時に引き継ぐ

適用範囲 (RC27 系ロボットへの展開)#

アーム専用にしない。TS 動力学実装は最初から次の仕様で書く:

木構造対応 (チェーン限定にしない。シャーシ + 複数肢の構成)
revolute + prismatic 両対応
部分同定 (対象関節を選んで同定。昇降だけ・ステア 1 軸だけが可能)

ロボット種別ごとの適用:

直動昇降脚: そのまま適用。重力補償が一定力 m·g で効果大。カウンタウェイト・ガススプリングはサイドカーにばね模型として持つ
ハンド: シリアルチェーンとしてそのまま
独立ステア台車: 全身剛体同定は不適 (走行はタイヤの領分)。軸単位の慣性 J + 摩擦同定 (1 自由度) として使う。台車上の上物への加速度混入は RNEA の重力ベクトルを g − a_base に差し替える拡張で将来対応可

パラメータ配布 (fibril_can への受け渡し)#

fibril_can に物理パラメータを渡す際、「設定ファイルに書くと二重管理、 topic で流すと疎結合が崩れる」というジレンマは、導出責務を合成層に置くことで解消する。fibril_can は URDF を知らないまま:

A. launch 時注入: launch がモデルを読み、導出値をノードパラメータで渡す。重複ファイルが存在しない。実行時パラメータの本命
B'. launch 時生成 (採用): fibril_can 用 YAML を起動のたびにモデルから生成する。
- YAML は手書き断片 (CAN ID・リミット等の base.yaml) と導出断片に分割。 launch がモデル + base.yaml を読んでマージし、tmp に書いて渡す
- 導出は係数評価だけなので数十 ms (同定計算は事前に済んでいる)
- XML launch では生成器を CLI 化し $(command 'fibril_config_gen ...') で呼ぶ (xacro と同じパターン)。CLI は tmp に YAML を書いてパスを stdout に返す
- ビルド時生成にしない理由: symlink-install の「編集 → launch し直すだけ」という習慣と衝突し、ビルド忘れで古い生成物が走る事故が起きる。 launch 時生成なら古い生成物という概念自体が無い
- 生成ロジックはロボット側 bringup パッケージに置く。fibril_can は YAML スキーマを公開するだけの汎用部品のまま (依存方向を守る)
- マージ結果に入力内容のハッシュを刻む。基板永続化 (C) と併用時、起動時照合で「基板の値が今のモデルと一致するか」を検出できる
C. 基板永続化 + ハッシュ刻印: configurator が設定コマンドとして書き込み。モデルの git hash も一緒に焼き、起動時照合で古さを検出

いずれも「URDF + サイドカー = 唯一の編集点、下流は導出物」を維持する。 WebUI の書き出し機能が A の導出関数・B の生成器・C の書き込みデータを担う。