実機ログ on Physical AI Hub

ロボットのデジタルツイン実装：実機状態とシミュレーションを同期する設計原則

Sat, 17 Oct 2026 13:08:07 +0900

デジタルツインの同期を「高頻度にすればよい」と考えると、ログの再現性や安全境界を見落としやすい点が気になります。

結論：同期周期は一つに統一しない

ロボットのデジタルツインでは、すべてのデータを同じ周期で同期するのではなく、データクラスごとに同期粒度、更新トリガー、許容遅延、欠損時の動作を定義するのが基本です。

関節位置・速度・トルク、ベース姿勢・速度、インターロックなど、制御や安全に直結する状態は、実機の制御・計測周期または状態変化イベントに近い粒度で扱います。環境・シーン、ロボット形状、質量や摩擦などのモデルパラメータ、劣化・保全情報は、状態変更、再キャリブレーション、保全イベント、モデル再同定などを契機に更新します。運用ログは最新値への上書きではなく、後から時系列を再現できる記録として保存します。

つまり、問うべきなのは「何Hzで同期するか」だけではありません。何の時刻を表すデータか、どの値を正当な実機状態とみなすか、遅延や欠損が起きたときどう扱うかを、データクラス別の同期契約として明文化することが重要です。

なぜ同期粒度が重要か

ISO 23247は、製造要素、デジタルツイン、サービスや利用者の関係を整理する参照枠組みを示しています。一方で、すべてのロボットやデータに共通する同期周期を規定しているわけではありません。ロボットの制御周期、通信構成、シミュレータ、利用目的によって適切な粒度は変わります。

また、文献によってデジタルモデル、デジタルシャドウ、デジタルツインの区分も異なります。一般には、実体からデジタル側への一方向のデータ連携と、デジタル側から実体への自動反映を含む双方向連携を区別します。監視のための読み取りと、実機へ影響を与える書き戻しを同じ経路で扱うと、権限や安全性の境界が曖昧になります。

四つのデータクラスに分ける

制御・安全状態

関節状態、ベース状態、インターロックなどは、シミュレーションの状態推定や安全判断に直接影響します。値には取得時刻とシーケンス番号などの順序情報を付け、受信時刻だけで実機状態の時刻を表さないようにします。

OPC UAのデータモデルにあるSourceTimestampとServerTimestampのように、値が生成された時刻とサーバーが受け付けた時刻を分ければ、通信遅延や到着順を分析できます。

環境・シーン情報

周囲の物体、作業空間、配置、経路などは、制御状態と同じ周期で送る必要があるとは限りません。配置変更やシーン再構成をイベントとして同期し、シミュレーション側では、どの時点の環境を表す情報かを保持します。

モデル・保全情報

ロボットの形状、質量、摩擦などのパラメータ、再キャリブレーション結果、劣化状態、保全履歴は、モデル再同定や保全イベントを更新トリガーにします。高頻度に送るより、変更理由、適用範囲、バージョンを管理する方が、検証と保全に向いています。

運用ログ

運用ログには、実機側の取得時刻、受信時刻、クロックの種類、シーケンス番号、通信状態、モデル・設定バージョンを残します。シミュレーション入力用のデータと、改変しない原記録を分離すれば、再生検証と監査に利用できます。

flowchart LR
  subgraph Physical["実機"]
    Sensor["センサー・計測"]
    Controller["制御器"]
    RobotState["関節・姿勢・トルク・安全状態"]
    Scene["環境・シーン情報"]
    Model["モデル・保全情報"]
    Events["イベント・運用ログ"]
    Sensor --> RobotState
    Controller --> RobotState
    Scene --> Events
    Model --> Events
    RobotState --> Events
  end

  subgraph Ingest["収集・記録"]
    Collector["データ収集"]
    Timestamp["時刻・順序付与\nSourceTimestamp / ServerTimestamp / シーケンス番号"]
    RawLog["不変の原記録\n取得時刻・受信時刻・通信状態・版情報"]
    Collector --> Timestamp
    Timestamp --> RawLog
  end

  subgraph Gate["同期契約・判定"]
    Contract["データクラス別の同期契約\n更新トリガー・鮮度上限・欠損時動作・権威性"]
    QoS["QoS判定\nReliability・Deadline・Durability・History・Liveliness"]
    Freshness["鮮度・順序・版の検査"]
    Contract --> QoS --> Freshness
  end

  subgraph Twin["シミュレーション"]
    SimInput["シミュレーション入力"]
    SimTime["シミュレーション時刻"]
    Sim["デジタルツイン"]
    SimInput --> SimTime --> Sim
  end

  RobotState --> Collector
  Scene --> Collector
  Model --> Collector
  Events --> Collector
  Timestamp --> Contract
  Timestamp --> RawLog
  Freshness --> SimInput
  RawLog --> Replay["再生・監査・再現検証"]
  Sim --> CommandGate["コマンドゲート\n認証・認可・妥当性検査・範囲制限・監査"]
  CommandGate -. "双方向反映が必要な場合のみ" .-> Controller

データクラスごとに時刻、順序、鮮度、QoS、権威性を検査し、シミュレーション入力と改変しない原記録を分離する同期構成。

時刻と実行方式を分ける

シミュレーション時刻は壁時計時刻と同一ではありません。ROS 2ではシステム時刻、安定した経過時間を扱う時刻、ROS時刻を区別でき、シミュレーション時には/clockでROS時刻を提供できます。ROS時刻は一時停止、速度変更、時刻ジャンプの影響を受けるため、受信時刻や単調増加する経過時間と混同しない設計が必要です。

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. 不確実性と方策を扱う

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