センサー

ロボットセンサーの時刻同期設計:カメラ・LiDAR・IMUのデータを正しく重ねる方法

異なる時系列を持つカメラ、LiDAR、IMUを抽象化した波形が、共通の基準時刻へそろっていく図案
目次

センサー融合では、値の精度だけでなく「いつ取得した値か」の定義が結果を左右します。

先に結論

カメラ・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は時刻基準をそろえる手段、外部トリガーは取得イベントをそろえる手段です。ただし、対応機種、ファームウェア、ドライバによって意味が異なります。同期パルスを入力できても、センサー内部の取得からアプリケーション到着までの遅延は別途検証します。

各センサーの時計とタイムスタンプを共通の基準時刻へ変換し、共通タイムラインでデータを対応付ける概念図。PTPなどを有効にしても、センサーのタイムスタンプ経路や取得時刻の意味は別途確認が必要です。

検出の第一歩は、複数センサーで共通イベントを観測することです。同期パルスや外部イベントについて、各センサーが記録した時刻差を複数回測定し、平均値と分散を求めます。平均的な差は固定オフセット、分散はイベント検出や通信のばらつきを考える材料になります。

長時間ログでは、イベント時刻差やカメラとIMUなどの運動信号の相関ピークを時刻の関数として追跡します。差が時間とともに変わるなら、固定オフセットではなくクロックドリフトを疑います。運動データを使う場合、静止状態だけでは時間オフセットを十分に推定できないことがあります。相対運動、観測の整合性、十分な運動励起が必要です。

同期方式の比較

方法主にそろえる対象適する場面制約
PTPネットワーク接続されたクロック対応機器をネットワークで統一する場合実装、プロファイル、遅延、センサー側の時刻経路を確認する
NTPネットワーク上の時計システム時計の規律取得イベントやタイムスタンプの意味まではそろえない
PPS時刻基準共通の基準パルスを供給できる場合入力対応、パルスの意味、ドライバ処理を確認する
外部トリガー取得イベントセンサーの取得タイミングを合わせる場合転送・処理遅延は別に測定する
ソフトウェア補正センサー時刻と基準時刻の関係既存ログや非対応機器を扱う場合可変遅延や誤った時刻定義は直せない
ApproximateTimeメッセージの組み合わせ近い時刻のデータを処理する場合クロックオフセットやドリフトの補正ではない

ソフトウェア補正の実装

センサーiの時刻を基準時刻へ変換する一次モデルとして、次を使えます。

t_ref = alpha_i × t_i + beta_i

βiは固定オフセット、αiはクロックレート差を表します。共通イベントのログや運動信号からセンサーごとのパラメーターを推定し、補正後のデータを共通タイムラインへ配置します。到着時刻が異なるデータはバッファーに保持し、必要な基準時刻に合わせて処理します。

IMUでは推定時刻に合わせた状態補間、LiDARでは点または取得単位ごとのデスキュー、カメラでは露光開始・中心・終了やローリングシャッターを考慮したモデルを適用します。

時刻同期では、データの対応付けだけでなく、ずれの種類の判定、センサー固有の取得時間モデル、補正後の検証までを一連の工程として扱います。

受信時刻を測定時刻の代わりに使う設計には注意が必要です。遅延が一定なら補正しやすい一方、可変遅延があると単一の固定値では対応できません。センサー生成時刻を保持できるか、ドライバがどの段階で時刻を付与するかを仕様とログで確認します。

採用判断と失敗しやすい点

許容する同期誤差は、フレームレート、LiDARのスキャン方式、IMUレート、最大角速度・加速度、推定器のモデル、対象が静的か動的かによって変わります。一般的な単一閾値を置くのではなく、想定する運動条件で再投影誤差や推定残差が許容範囲に収まるかを検証します。

高速運動や動体追跡、カメラと点群の投影整合性を重視する場合は、可能な範囲でPTPや外部トリガーを優先します。機器が混在してハードウェア同期が難しい場合は、共通イベントと長時間ログからオフセットとドリフトを推定し、時刻変換と補間を組み合わせます。低速で遅延の影響が小さい処理ではApproximateTimeが補助になりますが、時計の問題を解決したとは判断しません。

まとめ

時刻同期は、近いメッセージを選ぶ処理ではなく、クロック、取得イベント、タイムスタンプの意味、通信遅延を含む時間モデルの設計です。共通基準を構築し、固定オフセットとドリフトを分けて推定し、カメラの露光やLiDARのスキャン時刻まで補正します。採用方式は、機器の対応機能だけでなく、実際の運動条件と検証指標で決めるべきです。

参考情報

同期方式の選択は、仕様表の機能名よりも、実際の時刻経路を検証できるかどうかで判断したいテーマです。

AI利用に関する注記

本サイトの記事は、複数のAIエージェントによる調査・執筆・レビューを経て公開しています。正確性と品質の向上に努めていますが、内容については必ず一次情報をご確認ください。

参考にした一次情報