システム同定 on Physical AI Hub

ロボットのオンラインシステム同定：実機の変化を制御モデルへ反映する設計

Sun, 18 Oct 2026 13:15:09 +0900

実機の変化を追従する仕組みほど、更新しない経路の設計が安全性を左右します。

結論

ロボットのオンラインシステム同定は、推定モデルを制御器へ直接書き込む機能ではなく、監視・検証・更新を担う監督層として組み込むべきです。まずシャドーモードで入力・出力、残差、推定共分散、物理的なパラメータ範囲を確認し、条件を満たした場合だけ、非安全系の限定されたパラメータを段階的に反映します。

安全停止、速度・トルク上限、保護領域、フォールバック制御は推定器から分離します。更新に失敗した場合は、直前の有効モデルまたは保守的な安全モデルへ戻せる構成にします。オンライン同定の採用判断では、追従性だけでなく、推定の確からしさ、安定性の仮定、変更管理まで確認する必要があります。

なぜオンライン同定が必要か

ロボットの動特性は導入時のモデルから変化します。積載物、温度、摩擦、減速機の状態などが変われば、同じ入力に対する速度やトルクの応答も変わり得ます。固定モデルとの不一致が大きくなると、追従性能や外乱・接触検出の信頼性に影響します。

一方、観測された変化が摩耗によるものとは限りません。接触、外乱、負荷変化、センサーずれ、モデル誤差も似た残差を生みます。したがって、同定器は原因を自動的に断定する装置ではなく、変化の兆候と推定の不確かさを継続的に評価する仕組みとして扱います。

前提となる用語と仕組み

システム同定とは、入力と出力のデータから対象の動特性を表すモデルやパラメータを推定することです。オンライン同定では、データを逐次処理して推定値を更新します。再帰的最小二乗法や予測誤差法は、その代表的な考え方です。

忘却係数を使うと、古いデータの影響を相対的に小さくし、時間変化する動特性への追従を狙えます。ただし、忘却を強くすると変化への追従性が高まる反面、ノイズへの感度や推定バイアスが増える可能性があります。十分な励起、信号品質、推定不確かさの監視が欠かせません。

残差は、測定トルクとモデルから予測したトルクとの差のように、実測値とモデル出力の差を示します。外力や衝突の検出に利用できますが、残差だけで劣化、負荷変化、接触を一意に識別できるわけではありません。励起が不足した運転では、異なる原因が同じ残差を生む可能性があります。

推奨アーキテクチャ

高速の制御ループと、低速の推定・保全ループを分離します。高速ループは既知の安定モデルと安全制約で動作させ、低速ループは温度、負荷、摩擦、残差、推定パラメータを蓄積します。候補モデルは妥当性検証を通過した場合だけ、非安全系の制御パラメータへ反映します。

検証項目は、少なくとも次の通りです。

推定に必要な励起が確保されているか
残差が想定範囲に収まっているか
推定共分散または信頼区間が過大でないか
パラメータが物理的な範囲にあるか
一回の更新幅と更新頻度が制限内か
独立した安全監視が介入していないか

flowchart LR
  subgraph DATA["観測・入力データ"]
    S["センサー値"]
    U["制御入力"]
  end

  subgraph EST["低速の推定・検証ループ"]
    P["データ前処理"]
    I["オンライン推定器"]
    V["妥当性検証\n励起・残差・共分散・物理範囲"]
    C["更新候補モデル"]
    G["更新ゲート"]
  end

  subgraph CTRL["制御系"]
    M["既知の安定モデル"]
    K["制御器"]
    R["非安全系のモデル補正"]
  end

  subgraph SAFE["独立した安全系"]
    L["安全監視"]
    T["速度・トルク上限"]
    E["非常停止"]
    F["フォールバック制御\n直前の有効モデルまたは安全モデル"]
  end

  S --> P
  U --> P
  P --> I
  I --> V
  V --> C
  C --> G
  G -->|"検証済みの場合のみ"| R
  M --> K
  R -.->|"非安全系に限定"| K
  K -->|"制御出力"| T
  T -->|"許可された出力"| ROBOT["ロボット"]
  L --> T
  L --> E
  L --> F
  G -.->|"失敗時は反映しない"| F
  F -.-> K

オンライン推定の結果を直接制御器へ書き込まず、妥当性検証と更新ゲートを経て非安全系に限定して反映する。安全監視とフォールバック制御は推定器から独立させる。

モデル更新は、BASELINE_MODEL → SHADOW_ESTIMATION → VALIDATING → CANDIDATE_MODEL → ACTIVE_MODEL のような状態で管理できます。励起不足、残差異常、共分散の過大化、物理範囲からの逸脱、安全監視の介入があれば候補モデルを有効化せず、ベースラインまたは安全モデルへ戻します。ROS 2のライフサイクル状態は、Inactive状態で更新を準備し、遷移時に有効化する実装パターンの参考になります。ただし、それだけで機能安全が保証されるわけではありません。

ロボット制御を実機に合わせる：アクチュエーター制約をモデル化して計画へ反映する方法

Mon, 05 Oct 2026 14:22:52 +0900

実機でだけ現れる追従誤差は、制御器の調整不足だけでなく、制約の表現方法にも原因があります。

結論：制約は一つの上限値にまとめない

ロボットの軌道がシミュレーションでは追従できるのに、実機では誤差が増えたり停止したりする場合、アクチュエーターの非理想特性を層ごとに分けて扱う必要があります。基本となる流れは、指令値、量子化、出力制限、伝達機構、実機状態を分離してモデル化し、シミュレーターと低レベル制御器の両方に同じ制約を適用することです。

上位計画には、位置だけでなく速度、加速度、ジャーク、動力学から得られるトルク制約を入れます。さらに、量子化による誤差やバックラッシュの不確実性は、安全余裕、方向反転の回避、またはロバストな可到達集合として反映します。

問いが重要な理由

幾何学的に正しい経路でも、時間の割り当てが速すぎれば、必要なトルクや加速度が実機の能力を超えます。また、指令値を細かく変化させても、通信や制御テーブルの分解能を下回れば、実際の出力は変化しません。減速機などにバックラッシュがあれば、方向を反転した直後の指令が出力軸の運動に直結しないこともあります。

これらを低レベル制御だけで吸収すると、上位計画が「実行できない軌道」を生成し続けます。制約を計画層まで伝えることで、軌道生成の段階で実行可能性を判定できます。

前提となる用語

飽和は、入力または出力が上限・下限に達し、それ以上増えない状態です。制御入力のクリップ、アクチュエーター内部で生成できる力・トルクの制限、関節へ実際に伝達される力・トルクの制限は、同じものではありません。

量子化は、連続値を有限の刻みで表現する処理です。指令値側とセンサー側を分け、量子化幅、丸めまたは切り捨て、ゼロ次ホールド、サンプリングや遅延を確認します。

バックラッシュは、伝達機構の遊びによって入力と出力の関係が方向依存になる現象です。単純な加法ノイズではなく、入力方向、相対変位、接触状態を持つヒステリシスやプレイ演算子として扱うのが適切です。

内部の仕組み：制約を層に分解する

第一に、コントローラーが生成した指令を量子化します。指令単位が粗い場合、微小な補正は同じ離散値に丸められます。第二に、速度リミッターや電流リミッター、入力範囲の制限を適用します。第三に、アクチュエーターが生成できる力・トルクを制限します。最後に、減速機などの伝達機構を通して関節へ出力される力・トルクを計算します。

この分離が必要なのは、入力をクリップしても、実際の出力トルクが同じ割合で制限されるとは限らないためです。MuJoCoのアクチュエーター機構でも、制御入力、生成力、関節へ伝達される力が別の段階として扱われています。一方、標準的なロボット制御インターフェースでは、位置・速度・加速度・ジャーク・努力量などは扱えても、量子化幅やバックラッシュ状態まで標準化されているとは限りません。伝達機構とハードウェア固有の非線形性は、追加のモデルとして実装します。

計画側では、経路上の位置を時間パラメータ化し、速度・加速度と動力学的なトルク制約を同時に評価します。時間スケーリングを遅くすれば、必要トルクが下がる場合がありますが、速度依存の限界や制御遅延があるため、単純に低速化すれば十分とは限りません。

flowchart LR
  P["上位計画"] -->|"位置・速度・加速度・ジャーク・トルク制約を適用"| T["時間パラメータ化された軌道"]
  T --> C["低レベル制御器"]
  C --> Q["指令値量子化"]
  Q --> R["速度・入力範囲の制限"]
  R --> E["電流・努力量の制限"]
  E --> A["アクチュエーターの生成力・トルク制限"]
  A --> B["バックラッシュ・伝達機構モデル"]
  B --> J["関節出力"]
  J --> M["実機状態"]
  M --> S["センサー量子化・サンプリング・遅延"]
  S --> C
  M --> I["実機同定・検証"]
  I -.->|"制約値と不確実性を更新"| P
  I -.->|"層ごとのモデルを更新"| Q

制約を入力、アクチュエーター、伝達機構、観測の層に分け、同じモデルを計画器と低レベル制御器に反映する流れ。

計画に反映する選択肢

対象	推奨するモデル	上位計画への反映
連続トルク限界	通常運転で継続可能な値	基本の動力学制約として使用
短時間ピーク限界	時間や条件付きの上限	短い区間に限定し、連続値と分離
指令値量子化	指令単位、丸め、保持	微小な指令変化を実行可能とみなさない
センサー量子化	観測値の刻みと更新周期	状態推定の不確実性や余裕に反映
バックラッシュ	プレイ演算子、ヒステリシス、伝達機構モデル	方向反転回避、余裕、ロバスト計画
温度・電圧・速度依存	条件ごとの限界値	運転状態に応じて保守的な制約を選択

制約値は、定格値、連続許容値、短時間ピーク値を区別します。メーカーが示す最大トルクや最大電流は瞬間的なピーク値の場合があり、計画にそのまま使うと連続運転で余裕を失う可能性があります。通常の計画には、同定誤差と制御遅延を含む保守的な連続許容値を使い、ピーク値は時間や条件を限定して扱います。

Sim-to-Realの性能劣化を分解する：物理パラメータ・センサー・制御の補正手順

Sat, 14 Feb 2026 00:12:29 +0900

シミュレーション上の成功が実機で崩れるとき、物理モデルだけを疑う前に、ログと時間の整合性を確認したくなります。

先に結論

Sim-to-Realで性能が落ちたとき、いきなり摩擦や質量を調整するのは得策ではありません。まず単位、座標系、アクションスケール、時刻、制御周期などのインターフェースを確認し、次にセンサーと遅延、アクチュエータと低レベル制御、剛体・運動学、接触・環境の順で補正します。その後、残る不確実性に対してダイナミクスランダム化、実機データによる分布更新、オンライン適応、方策の再調整を検討します。

この順序は、すべてのロボットやタスクで保証された標準手順ではありません。各段階で学習に使っていない実機ログを検証し、残差のパターンが変わったかを確認することが前提です。

なぜ原因分解が必要か

実機で方策が失敗すると、物理モデルが間違っていると考えがちです。しかし性能差は、観測・レンダリング、時間同期と通信遅延、アクチュエータと低レベル制御、剛体・接触ダイナミクス、環境分布、方策の汎化誤差に分かれます。複数の要因が同じ軌道誤差を生むこともあるため、単一種類のログだけではパラメータを一意に決められない場合があります。

たとえば、定常的な位置や角度のずれはゼロ点や座標系、位相遅れはタイムスタンプ・通信・制御遅延、自由空間での振幅差はゲイン・摩擦・慣性を優先的に疑います。接触時の衝撃や滑りは摩擦、剛性、接触形状の不一致と結び付きやすく、視覚入力時だけ失敗するならカメラやレンダリング分布の差を調べます。

まず確認する用語

システム同定は、実機の入力と状態のログから、質量、摩擦、遅延などのモデルパラメータを推定する考え方です。ダイナミクスランダム化は、質量、摩擦、モーター出力などをエピソードごとに変化させ、単一モデルへの過適合を避ける方法です。視覚系ではテクスチャ、照明、カメラ姿勢、背景、オブジェクト配置などを変化させます。

オンライン適応は、実機の履歴から環境やダイナミクスの潜在状態を推定し、方策を適応させる方法です。固定パラメータの精密化だけでは扱いにくい、時間変化する差への選択肢になります。

実機データでの補正手順

1. ログとインターフェースを監査する

最初に、単位、座標系、アクションのスケール、飽和処理、ログ時刻、制御周期をそろえます。センサー、制御入力、状態推定、時刻情報は同一試験単位で保存し、後から再生できる形にします。ROS 2ではros2 bagに指定トピックを記録・再生できます。

ここが崩れていると、後段で物理パラメータを調整しても、入力と観測の対応がずれたままになります。まず再生ログとシミュレーションの入出力インターフェースが一致するかを確認します。

2. センサー、座標系、時間を合わせる

センサーのバイアス、ゼロ点、外部パラメータ、ノイズ、観測遅延を調べます。視覚入力を使う場合は、テクスチャ、照明、カメラ姿勢、背景、物体配置の差も対象です。実機画像に近い観測分布を作るだけでなく、視覚以外の状態推定値についても、シミュレーションと同じ前処理になっているか確認します。

3. アクチュエータと低レベル制御を合わせる

指令値が同じでも、モーターの応答、トルク制限、内部制御器、フィルタ、遅れによって実際の運動は変わります。脚ロボットなどでは、アクチュエータモデルをシミュレーションに含めることが、剛体パラメータを合わせることとは別の補正対象になります。

4. 剛体・運動学を調整する

質量、重心、慣性、関節減衰などを確認します。重力姿勢や自由空間の運動を使い、剛体モデルと運動学の誤差を切り分けます。MuJoCoのモデル定義では、ボディ、関節、アクチュエータ、センサー、接触・摩擦関連の要素を個別に設定でき、パラメータをカテゴリ別に管理する際の参照になります。

5. 接触と環境を調整する

接触時だけ残差が増える場合は、摩擦、接触剛性、反発、接触形状、床など環境側の条件を調べます。自由空間の運動が合っていても、接触ダイナミクスがずれていれば、滑りや衝撃を再現できません。

flowchart LR
  A["実機で性能劣化"] --> B["残差パターンを観測"]
  B --> C["定常的な位置・角度オフセット"]
  B --> D["位相遅れ"]
  B --> E["自由空間での振幅差"]
  B --> F["接触時の衝撃・滑り"]
  B --> G["視覚入力時だけの失敗"]
  B --> H["時間変化する差"]
  C --> C1["ゼロ点・座標系・初期姿勢"]
  D --> D1["時刻・通信・制御遅延"]
  E --> E1["ゲイン・摩擦・慣性・アクチュエータ"]
  F --> F1["摩擦・剛性・接触形状・環境"]
  G --> G1["カメラ・レンダリング分布・前処理"]
  H --> H1["オンライン適応・履歴からの状態推定"]

実機ログに現れる残差パターンを手掛かりに、優先して確認する原因カテゴリを切り分ける。

6. 不確実性と方策を扱う

点推定したモデルで実機を再現できない場合は、同定値の周囲に不確実性を持たせたダイナミクスランダム化を行います。実機ロールアウトとシミュレーション軌道の差を使い、ランダム化分布やシミュレーションパラメータを更新する方法もあります。それでも時間変化する差が残るなら、オンライン適応や残差方策を追加し、最後に方策自体を再調整します。