センサー融合では、値の精度だけでなく「いつ取得した値か」の定義が結果を左右します。
先に結論
カメラ・LiDAR・IMUの時刻同期では、近いタイムスタンプのメッセージを組み合わせるだけでは不十分です。まず、各センサーがどのクロックを使い、タイムスタンプが取得時刻、露光時刻、スキャン時刻、受信時刻のどれを表すのかを確認します。そのうえで、可能な範囲ではPTP、PPS、外部トリガーなどを使って共通の時間基準を構築し、残った固定オフセットやドリフトをログから推定します。
補正では、センサー時刻を基準時刻へ変換し、IMUの状態補間、LiDARのデスキュー、カメラの露光時刻モデルを適用します。最後に、共通イベントの時刻差、運動信号の相関、推定残差、再投影誤差を確認します。ROS 2のApproximateTimeはメッセージの対応付けには使えますが、センサー内部の時計を直す機能ではありません。
なぜ時刻同期が問題になるのか
センサーフュージョンでは、同じ「時刻」のデータを重ねているつもりでも、実際には異なる時間基準、単位、エポックを参照していることがあります。センサーが生成した時刻をドライバがホスト受信時刻に置き換えている場合もあります。
ずれは、主に四つに分けて考えます。一定に近い固定オフセット、クロック周波数の差によるドリフト、通信・ドライバの可変遅延、タイムスタンプが示す物理的な時刻の違いです。最後の問題は、数値に固定値を加えるだけでは解消できません。角速度をω、時刻誤差をΔtとすると、短時間近似では角度誤差は概ね|ω|×|Δt|に比例します。高速回転や急加速、動体追跡、点群の画像投影ほど同期ずれの影響が大きくなります。
前提となる時刻の意味
ROS 2ではSystem Time、Steady Time、ROS Timeが区別されます。ROSの時刻とセンサーのハードウェア時刻が自動的に同一になるわけではありません。IMUメッセージのHeader stampは測定時刻として扱われますが、メッセージ定義だけでは、センサーのクロックやドライバが時刻を付与した位置までは保証されません。
カメラでは、フレーム時刻が露光開始、露光中心、露光終了、転送完了のどれを示すかを確認します。ローリングシャッターでは行ごとに露光時刻が異なるため、フレーム全体を単一時刻の観測として扱えるとは限りません。
LiDARの1スキャンも瞬間的な観測とは限りません。ビーム、列、パケットなどで取得時刻が異なる場合があるため、点ごとの時刻、またはセンサー固有のスキャン時刻モデルを使って運動補正します。時刻の提供粒度は機種、ファームウェア、データ形式、ドライバによって異なります。
同期の仕組みと検出方法
PTP(IEEE 1588)は、ネットワーク上のクロック間のオフセットと遅延を測定して同期する標準です。ハードウェアタイムスタンプを使える実装では、ソフトウェアだけで時刻を取得する場合より不確実性を抑えやすくなります。ただし、精度はネットワーク遅延の対称性、タイムスタンプ方式、プロファイル、実装に依存します。ptp4lでネットワーク上のクロックを同期しても、LinuxのPHC、システムクロック、センサーのタイムスタンプ経路まで自動的に同一になるわけではありません。
PPSは時刻基準をそろえる手段、外部トリガーは取得イベントをそろえる手段です。ただし、対応機種、ファームウェア、ドライバによって意味が異なります。同期パルスを入力できても、センサー内部の取得からアプリケーション到着までの遅延は別途検証します。
flowchart LR
subgraph S1["センサー側の時刻"]
C["Camera Clock\n露光時刻モデル"]
L["LiDAR Clock\n点・パケット・スキャン時刻"]
I["IMU Clock\n測定時刻"]
end
P["PTP・PPS・外部トリガー\n利用可能な同期手段"]
R["Reference Clock\n共通の基準時刻"]
T["時刻変換\nt_ref = α_i × t_i + β_i"]
X["共通タイムライン\n対応付け・補間・融合"]
P -. "クロックまたは取得イベントを同期" .-> C
P -. "クロックまたは取得イベントを同期" .-> L
P -. "クロックまたは取得イベントを同期" .-> I
C --> T
L --> T
I --> T
R --> T
T --> X
D["固定オフセット β_i\nクロックレート差 α_i"]
D -. "ログから推定" .-> T検出の第一歩は、複数センサーで共通イベントを観測することです。同期パルスや外部イベントについて、各センサーが記録した時刻差を複数回測定し、平均値と分散を求めます。平均的な差は固定オフセット、分散はイベント検出や通信のばらつきを考える材料になります。
長時間ログでは、イベント時刻差やカメラとIMUなどの運動信号の相関ピークを時刻の関数として追跡します。差が時間とともに変わるなら、固定オフセットではなくクロックドリフトを疑います。運動データを使う場合、静止状態だけでは時間オフセットを十分に推定できないことがあります。相対運動、観測の整合性、十分な運動励起が必要です。
同期方式の比較
| 方法 | 主にそろえる対象 | 適する場面 | 制約 |
|---|---|---|---|
| PTP | ネットワーク接続されたクロック | 対応機器をネットワークで統一する場合 | 実装、プロファイル、遅延、センサー側の時刻経路を確認する |
| NTP | ネットワーク上の時計 | システム時計の規律 | 取得イベントやタイムスタンプの意味まではそろえない |
| PPS | 時刻基準 | 共通の基準パルスを供給できる場合 | 入力対応、パルスの意味、ドライバ処理を確認する |
| 外部トリガー | 取得イベント | センサーの取得タイミングを合わせる場合 | 転送・処理遅延は別に測定する |
| ソフトウェア補正 | センサー時刻と基準時刻の関係 | 既存ログや非対応機器を扱う場合 | 可変遅延や誤った時刻定義は直せない |
| ApproximateTime | メッセージの組み合わせ | 近い時刻のデータを処理する場合 | クロックオフセットやドリフトの補正ではない |
ソフトウェア補正の実装
センサーiの時刻を基準時刻へ変換する一次モデルとして、次を使えます。
t_ref = alpha_i × t_i + beta_i
βiは固定オフセット、αiはクロックレート差を表します。共通イベントのログや運動信号からセンサーごとのパラメーターを推定し、補正後のデータを共通タイムラインへ配置します。到着時刻が異なるデータはバッファーに保持し、必要な基準時刻に合わせて処理します。
IMUでは推定時刻に合わせた状態補間、LiDARでは点または取得単位ごとのデスキュー、カメラでは露光開始・中心・終了やローリングシャッターを考慮したモデルを適用します。
flowchart TD
A["Clock Domainと時刻の意味を確認\nクロック・単位・エポック・取得段階"] --> B["共通イベントまたは同期統計を収集\nイベント時刻差・PTP統計・長時間ログ"]
B --> C["ずれの種類を判定\n固定オフセット・ドリフト・可変遅延・物理時刻差"]
C --> D["固定オフセットとドリフトを推定\nα_i・β_iをログから推定"]
D --> E["基準時刻へ変換してバッファリング\n到着時刻と取得時刻を区別"]
E --> F["センサー固有の時間モデルを適用"]
F --> F1["IMU\n推定時刻への状態補間"]
F --> F2["LiDAR\n点・取得単位ごとのデスキュー"]
F --> F3["カメラ\n露光時刻・ローリングシャッターを考慮"]
F1 --> G["同期結果を検証"]
F2 --> G
F3 --> G
G --> H["運動信号の相関ピーク\nイベント時刻差の統計"]
G --> I["推定残差・再投影誤差"]
H --> J{"許容範囲に収まるか"}
I --> J
J -- "いいえ" --> K["クロック経路・時刻モデル・遅延を再確認"]
K --> B
J -- "はい" --> L["補正済みデータをセンサーフュージョンへ"]受信時刻を測定時刻の代わりに使う設計には注意が必要です。遅延が一定なら補正しやすい一方、可変遅延があると単一の固定値では対応できません。センサー生成時刻を保持できるか、ドライバがどの段階で時刻を付与するかを仕様とログで確認します。
採用判断と失敗しやすい点
許容する同期誤差は、フレームレート、LiDARのスキャン方式、IMUレート、最大角速度・加速度、推定器のモデル、対象が静的か動的かによって変わります。一般的な単一閾値を置くのではなく、想定する運動条件で再投影誤差や推定残差が許容範囲に収まるかを検証します。
高速運動や動体追跡、カメラと点群の投影整合性を重視する場合は、可能な範囲でPTPや外部トリガーを優先します。機器が混在してハードウェア同期が難しい場合は、共通イベントと長時間ログからオフセットとドリフトを推定し、時刻変換と補間を組み合わせます。低速で遅延の影響が小さい処理ではApproximateTimeが補助になりますが、時計の問題を解決したとは判断しません。
まとめ
時刻同期は、近いメッセージを選ぶ処理ではなく、クロック、取得イベント、タイムスタンプの意味、通信遅延を含む時間モデルの設計です。共通基準を構築し、固定オフセットとドリフトを分けて推定し、カメラの露光やLiDARのスキャン時刻まで補正します。採用方式は、機器の対応機能だけでなく、実際の運動条件と検証指標で決めるべきです。
参考情報
- ROS 2 Clock and Time
- sensor_msgs/Imu Message
- Approximate Time Synchronizer
- IEEE 1588-2019
- linuxptp ptp4l Documentation
- Precision Time Protocol
- Ouster Time Synchronization
- Unified Temporal and Spatial Calibration for Multi-Sensor Systems
- Visual-inertial sensor fusion
- IMU-Camera Calibration
- RFC 5905
同期方式の選択は、仕様表の機能名よりも、実際の時刻経路を検証できるかどうかで判断したいテーマです。
AI利用に関する注記
本サイトの記事は、複数のAIエージェントによる調査・執筆・レビューを経て公開しています。正確性と品質の向上に努めていますが、内容については必ず一次情報をご確認ください。