センサー on Physical AI Hub

自律ドッキングの実装設計：位置合わせ・接近制御・充電接続を分解する

Sun, 01 Nov 2026 14:47:08 +0900

自律ドッキングは、接触できたかどうかだけでは成功を判断できない点が設計上の要所です。

先に結論

ロボットの自律ドッキングでは、不確実性を一度に解消しようとせず、段階的なゲートとして扱うのが基本です。まず地図と自己位置推定を使って充電ステーション周辺のステージング地点へ移動し、次にドックに対する相対位置と姿勢を精密化します。その後、低速で接近し、接触またはドッキング状態を確認してから、最後に電気的な充電成立を検証します。

「ドックへ到達した」と「充電できている」は同じ状態ではありません。したがって、成功条件は物理接触だけでなく、許容姿勢、停止状態、ドック状態、充電状態、タイムアウトを個別に評価する設計が適しています。条件を満たせない場合は前進を続けず、停止または後退、再位置推定、制限回数内の再試行、最終的な異常通知へ遷移させます。

なぜ段階分けが必要か

充電ステーションまでの移動は、通常のナビゲーションが得意とする問題です。一方、接触直前の位置合わせでは、地図上の自己位置だけでは扱いにくい局所的な誤差や、ドック設置位置のずれが問題になります。そのため、ステージング地点を境に、地図・大域自己位置推定からドック固有の相対センサーへ重心を移します。

さらに、接触したように見えても、端子の位置ずれや接続状態によって充電が成立しない可能性があります。ドッキング判定と充電判定を分離すれば、ロボットが物理的には停止しているものの、充電できていない状態を検出できます。

前提となる用語

大域自己位置推定：地図上でロボットがどこにいるかを推定する機能。ステーション周辺までの経路走行に使います。
ステージング地点：ドック固有の近距離処理へ切り替えるための待機位置です。
相対位置・姿勢推定：ロボットから見たドックの距離、横方向のずれ、向きなどを推定する処理です。
ドッキング判定：物理的にドックへ到達し、所定の姿勢や停止条件を満たしたかを確認する処理です。
充電判定：ドックとの電気的な接続が成立し、充電状態になったかを確認する処理です。

内部の仕組み：不確実性を順にゲート化する

代表的な構成は、通常のナビゲーションでステージング地点へ移動し、その後にドック固有の処理を実行する段階構成です。汎用フレームワークでは、ステージング位置の取得、相対位置の精密化、最終接近、ドッキング状態、充電状態を別々の処理として設計できます。一方、組み込み型ロボットでは、これらが一つのDockアクションに隠蔽されることもあります。抽象化の違いであり、段階的に確認する考え方と矛盾しません。

相対位置推定に使うセンサーは一つに決まりません。実装に応じて、赤外線、カメラ、レーザー・距離センサー、LiDAR、接触センサーなどが候補になります。重要なのは、センサー名を先に固定することではなく、各段階で何を観測し、どの状態を確定させるかを明確にすることです。

flowchart LR
  A["ステーション同定・大域自己位置推定"] --> B["ステージング地点へ移動"]
  B --> C["ドック相対座標系へ切り替え"]
  C --> D["相対位置・姿勢を精密化"]
  D --> E["低速接近"]
  E --> F["接触・ドッキング状態を検証"]
  F --> G["充電状態を検証"]
  G --> H["ドッキング成功"]

  B -->|"到達不可・タイムアウト"| R["停止または再位置推定"]
  D -->|"姿勢誤差・観測不安定"| S["停止または後退"]
  E -->|"障害物・異常接触・タイムアウト"| S
  F -->|"停止・姿勢・ドック状態が未成立"| T["後退して制限回数内で再試行"]
  G -->|"充電未成立・タイムアウト"| T
  S --> R
  T -->|"再位置推定後"| C
  T -->|"再試行上限超過"| U["異常通知または遠隔介入"]
  R -->|"復旧可能"| B

大域自己位置推定からドック相対位置合わせへ段階的に切り替え、ドッキングと充電を分離して検証する制御フロー。

図では、ステーションの同定と大域移動から始め、ステージング地点でドック基準の相対座標へ切り替えます。相対位置・姿勢を確認した後に低速接近し、接触・ドッキングを検証します。最後に充電状態を確認し、途中で条件を満たせなければ後退または再位置推定へ戻ります。

キャリブレーション誤差を計画へ伝える：ロボットの位置不確実性を扱う方法

Fri, 23 Oct 2026 13:32:17 +0900

校正値を高精度な固定値として扱うだけで、計画時の安全性まで十分に表せるのかが本稿の出発点です。

先に結論

キャリブレーション誤差は、単一の安全マージンやXYZ各軸の独立した誤差として扱うのではなく、校正パラメータ、関節状態、認識結果などの誤差源を分けた確率分布として保持し、最終的な手先・対象物・障害物の座標へ伝播させるべきです。姿勢にはSE(3)上の局所摂動と6次元共分散を使い、局所的な非線形性であればヤコビアンによる共分散伝播を適用します。非線形性や分布の歪みが強い場合は、シグマ点法やモンテカルロ法へ切り替えます。

経路計画では、衝突確率を制約する方法、または不確実性に応じてリンクや掃引体積を保守的に膨張させる方法を使います。把持計画では、エンドエフェクタと対象物の姿勢を同じ基準座標系へ変換し、相対姿勢の分布から接触成立、衝突回避、力閉包、把持成功のロバスト性を評価します。

なぜ校正誤差を計画へ伝えるのか

校正後の変換値を固定パラメータとして扱うと、計画器は「推定された平均姿勢が正しい」という前提で動作します。しかし実際には、校正データの測定誤差、関節角度の誤差、対象物認識の誤差などが残ります。校正パラメータの推定時に測定値の不確実性を重み付けし、パラメータ間の相関を含む推定共分散を保存できれば、その不確実性を後段の計画に入力できます。

ここで重要なのは、校正残差の共分散だけで実機の誤差全体を説明できるとは限らないことです。温度、荷重によるたわみ、バックラッシュ、摩擦、未モデル化の機構誤差などは、校正時と運用時で変化する可能性があります。したがって、検証用の姿勢、荷重、温度条件で残差を確認し、必要なら計画側の不確実性モデルへ反映します。

前提となる姿勢表現

位置と回転を別々のスカラー誤差として扱うのではなく、ロボットの姿勢をSE(3)上の状態として表します。基準姿勢の近傍にある小さな変動を6次元の局所摂動で表し、その平均と6×6共分散を保持する形が基本です。共分散には、位置と回転の相関や、回転軸間の相関も含められます。

ただし、共分散行列だけを保存しても意味は完全には決まりません。左摂動か右摂動か、摂動をbody frameで定義するかworld frameで定義するか、回転摂動をどのように定義するかによって、同じ6×6行列の解釈が変わります。実装では、共分散とともに摂動の定義、基準座標系、姿勢の変換規約を記録します。

共分散を座標変換へ伝播する仕組み

関節状態、校正パラメータ、対象物姿勢などを入力x、変換後の手先姿勢や相対姿勢を出力yとし、y=f(x)と表します。平均状態の近傍で線形化できるなら、ヤコビアンJを用いて次のように出力共分散を近似します。

Σ_y ≈ JΣ_xJᵀ

校正パラメータと関節状態など複数の誤差源を同時に扱う場合、それぞれの共分散を足すだけでは不十分です。誤差源の間に相関があるなら、交差共分散も含めて計算します。たとえば、校正パラメータの不確実性を順運動学へ入力し、手先姿勢の分布を得た後、対象物姿勢の分布と同じ座標系へ変換して相対姿勢を構成します。

一次のヤコビアン近似は、摂動が小さく、変換が局所的に線形とみなせる場合に適しています。大きな回転誤差、接触境界付近の判定、強い非線形性、多峰性のある分布では、平均と共分散だけでは形状を十分に表現できません。その場合はシグマ点法、モンテカルロ法、粒子表現を検討します。

flowchart LR
  A["校正データ"] --> B["校正パラメータ推定"]
  A --> C["測定誤差のモデル化"]
  B --> D["パラメータ平均と共分散"]
  E["関節状態"] --> F["誤差源の統合"]
  G["対象物認識結果"] --> F
  D --> F
  C --> F
  F --> H["摂動規約と基準座標系を統一"]
  H --> I["SE(3)姿勢変換"]
  I --> J["ヤコビアンによる共分散伝播"]
  J --> K["手先・対象物・障害物の姿勢分布"]
  K --> L{ "非線形性や分布の歪みが強いか" }
  L -- "いいえ" --> M["共分散を計画へ入力"]
  L -- "はい" --> N["シグマ点法またはモンテカルロ法"]
  N --> M
  M --> O["確率制約または保守的形状膨張"]
  M --> P["相対姿勢分布による把持評価"]

校正パラメータ、関節状態、認識結果の不確実性を姿勢分布へ伝播し、経路計画と把持計画へ入力する処理の全体像。

伝播手法の比較

手法	非線形性への対応	計算量の目安	相関の扱い	向いている場面	注意点
ヤコビアンによる共分散伝播	局所近似	小	共分散に含めて扱う	連続的な姿勢変換、計画の反復	大きな摂動や多峰性に弱い
シグマ点法	一次近似より広い非線形性に対応	中	入力分布から反映	姿勢変換や状態推定	分布の多峰性を完全には表せない
モンテカルロ法	強い非線形性に対応	大	サンプル間の関係として扱う	接触・衝突・把持成功の評価	サンプル数と計算時間が必要
保守的な形状膨張	分布形状を単純化	小	相関を別途考慮	衝突判定のベースライン	安全性と保守性の調整が必要

経路計画と衝突判定

経路計画では、各時刻のロボット状態と障害物との衝突確率に上限を設ける確率制約付き計画を構成できます。実装しやすいベースラインは、障害物境界へ向かう距離方向に位置分散を投影し、信頼区間や分位点を計算してリンク形状や掃引体積を膨張させる方法です。平均姿勢だけで衝突なしと判定するより、不確実性が大きい方向へ余裕を持たせられます。

ロボットビジョンのシャッター方式選定：動体歪み・同期・画質を比較する

Fri, 16 Oct 2026 13:17:57 +0900

ロボットの速度だけでは、カメラ画像の歪みを判断できない点が気になります。

先に結論

グローバルシャッターとローリングシャッターは、ロボットの関節速度や公称フレームレートだけで選ぶべきではありません。判断の中心は、画像面上の速度 v_img、センサーの実効読み出し時間 T_read、そして認識・計測で許容できる画素誤差です。

一次評価では、ローリングシャッターの行間位置ずれを v_img × T_read で見積もります。この値が許容誤差を超える可能性がある場合、特に高速な視覚サーボ、急な回転や加減速を伴う動作、数画素単位の外観検査では、グローバルシャッターを第一候補にします。対象がほぼ静止している、相対速度が低い、または許容誤差が大きい用途では、ローリングシャッターも実測を前提に選択肢になります。

なぜシャッター方式が重要か

グローバルシャッターは、フレーム内の画素を同時刻に近いタイミングで露光します。一方、ローリングシャッターはセンサーの行または行群を順番に露光するため、上の行と下の行で撮像時刻が異なります。厳密な露光開始・終了や読み出しの時間差はセンサーによって異なるため、仕様確認が必要です。

カメラまたは対象が露光中に動くと、ローリングシャッターでは行ごとに対象の位置が変わります。その結果、直線の傾き、対象形状の変形、姿勢推定のバイアスなどが生じます。視覚サーボでは画像特徴の位置が制御入力に使われ、検査では輪郭や寸法が判定に使われるため、この幾何歪みは単なる見た目の問題ではありません。

仕組みと一次評価

ローリングシャッターの歪みは、ロボットの関節速度だけでは決まりません。カメラと対象の相対運動が画像面でどれだけの速度になるか、カメラと対象の距離・姿勢、レンズの画角、行方向の読み出し時間、対象の深度差が関係します。同じ関節速度でも、作動距離や画角が変われば画像面速度は変化します。

一次近似として、行間の位置ずれは次式で表せます。

位置ずれ ≈ v_img × T_read

ここで v_img は画像面上の速度、T_read はフレームの実効読み出し時間です。これは選定初期の目安であり、回転、加減速、深度変化を含む実際の動作では動的試験が必要です。ROIやビニングによって読み出し時間が変わる場合もあるため、カメラの設定条件をそろえて確認します。

flowchart TB
  T0["FrameStartトリガー"] --> G
  subgraph G["グローバルシャッター"]
    G1["行1：露光開始"]
    G2["行2：露光開始"]
    G3["行3：露光開始"]
    G1 --- G2 --- G3
    GE["全行の露光区間が同時刻に近く重なる"]
    G1 --> GE
    G2 --> GE
    G3 --> GE
  end
  T0 --> R
  subgraph R["ローリングシャッター"]
    R1["行1：時刻 t0 に露光"]
    R2["行2：時刻 t0 + Δt に露光"]
    R3["行3：時刻 t0 + 2Δt に露光"]
    R1 --> R2 --> R3
    RE["上端と下端で撮像時刻が異なる"]
    R3 --> RE
  end
  G --> GT["実効読み出し時間 T_read と露光時間を仕様確認"]
  R --> RT["行時間・総読み出し時間 T_read・読み出し方向を仕様確認"]

FrameStartを同期しても、ローリングシャッターでは行ごとの露光時刻の差が残る。実効読み出し時間や行時間は実際の撮像設定とセンサー仕様で確認する。

露光時間によるモーションブラーは、行間の幾何歪みとは別の現象です。露光時間を短くすれば露光中のブラーは減りますが、ローリングシャッターの行間時間差や読み出し由来の歪みが自動的に消えるわけではありません。グローバルシャッターでも、露光中の移動、レンズ歪み、振動、照明フリッカーは残り得ます。

人協働ロボットの近接安全設計：人の動きを推定して速度制限へつなげる方法

Fri, 09 Oct 2026 14:54:15 +0900

人の動きを予測できても、安全判断では予測の不確実性をどう扱うかが問われます。

先に結論

人と協働するロボットの近接安全は、「人を検知したら停止する」か「AIの予測に任せる」かの二択ではない。人体の占有領域をロボットの危険源と同じ座標系で扱い、検出遅延、遮蔽、位置誤差、相対速度、ロボットの停止距離を含めて保護分離距離を継続評価することが基本になる。

分離距離を保証できる間は通常速度または制限速度で運転し、制限速度でも境界を維持できない場合は保護停止へ移行する。センサー故障、追跡断絶、通信・同期異常などで保証が失われた場合は、最後の推定値や予測値で運転を継続しない。予測軌道は先回りした速度制限の補助には使えるが、それだけを安全バリアとして扱うべきではない。

なぜ動的な評価が必要か

協働ロボットでは、人が作業領域に入ること自体が直ちに異常とは限らない。ロボットの速度、工具の形状、人体との距離、制動性能に応じて、通常動作、速度制限、保護停止を使い分ける必要がある。一方、検出から制動開始までに時間がかかれば、検知時点では安全に見えても、ロボットはその間に人体へ接近する。

そのため設計対象は人体検出器だけではない。センサー、推定器、通信、制御器、ドライブ、ブレーキを含む安全機能全体を、リスクアセスメントと安全関連制御系の要求に結び付ける必要がある。ISO/TS 15066は速度・分離監視などの協働運転方式を扱い、ISO 12100は危険源の同定、リスク低減、妥当性確認を含む設計プロセスを示している。

位置・速度・予測軌道の扱い

人体の位置は一点ではなく、人体または身体部位の占有領域として表現する。人体、ロボットの危険点、工具、周辺設備を共通座標系へ変換し、センサーの位置誤差、時刻同期と検出の遅延、遮蔽、複数人の識別不確実性を危険側に評価する。

安全レーザースキャナなどが保護フィールドへの侵入状態だけを出力する場合、その出力から連続的な位置や速度を直接得られるとは限らない。連続トラッキングを利用する場合は、時刻付きの位置推定から危険源への相対速度、つまり接近速度を算出する。平滑化や外れ値除去を行う場合も、更新遅延、推定誤差、トラッキング断絶を考慮し、瞬間値をそのまま安全入力にしない。

予測軌道は、将来位置を示す一本の確定線ではない。人の動きは周囲の人、物体、環境、相互作用、作業意図に依存し、予測ホライズンが長いほど不確実性が増す。したがって短時間先の複数の軌道候補を包絡する占有領域として扱い、最大接近速度と位置不確実性を含めてロボットの停止包絡との重なりを評価する。遮蔽、信頼度低下、追跡断絶、想定外の加速度が起きた場合は、予測を無効化して保守側へ遷移させる。

flowchart LR
  A["センサー入力\n時刻付きデータ"] --> B["時刻同期・共通座標系への変換"]
  B --> C["人体・身体部位の\n占有領域を推定"]
  C --> D["追跡・接近速度・\n不確実性を推定"]
  D --> E["短時間の複数軌道を\n占有包絡として評価"]
  E --> F["ロボットの停止包絡と\n保護分離距離を評価"]
  F --> G{"分離距離を\n保証できるか"}
  G -->|"余裕がある"| H["通常動作"]
  G -->|"制限速度なら保証可能"| I["速度制限"]
  G -->|"保証できない"| J["安全関連の保護停止"]
  D --> K{"追跡・同期・検出系に\n異常があるか"}
  K -->|"いいえ"| E
  K -->|"はい"| L["保守側へ遷移"]
  L --> I
  L --> J
  E -.-> M["予測は補助情報\n安全バリア単独ではない"]
  M -.-> F

人体の位置・接近速度・不確実性とロボットの停止性能を継続的に評価し、分離距離を保証できる範囲で速度を制限し、保証できない場合は保護停止へ移行する概念フロー。

分離距離から速度制限へ

保護分離距離の考え方では、人体の接近速度、システム全体の応答時間、ロボットの停止距離、人体または身体部位の侵入距離、センサーと位置推定の不確実性を考慮する。ISO 13855の基本関係は、接近速度をK、総応答時間をT、侵入距離をCとして S=K×T+C で表される。

不確実性を扱うロボット把持計画：成功確率に応じて実行と再観測を切り替える

Sun, 23 Aug 2026 01:51:41 +0900

把持の「自信あり」という数値が、実際の成功確率と同じ意味を持つのかが気になるテーマです。

はじめに

ロボットが物体を正しく認識できたように見えても、その把持が成功するとは限りません。姿勢推定の誤差、隠れた形状、摩擦や接触状態のばらつき、照明や視点の変化が、実行結果を左右します。ここで必要なのは、認識モデルのスコアを単純なしきい値で分類することではなく、「いま動く価値があるか」「追加観測で判断が改善するか」「安全のために中止すべきか」を分けて決める層です。

先に結論

把持計画では、生の把持スコアを成功確率として扱わず、対象・センサー・把持条件に合わせて校正した確率と、別々に評価した不確実性・安全信号を使います。実行、再観測、中止の切り替えは、成功確率だけでなく、成功時の価値、失敗や破損の損失、追加観測の時間・移動リスク、ロボットや周辺設備への安全リスクを含む期待効用、または明示的なリスク制約で設計します。

さらに、実行後も視覚などの観測で把持状態を検証し、必要なら再計画します。固定しきい値は実装の出発点にはなりますが、対象の価値やサイクルタイム、安全条件が異なる環境にそのまま移植できる普遍的なしきい値は確認されていません。

なぜ単一の信頼度では足りないのか

把持モデルの出力は、訓練データ、センサー、把持品質の定義、対象分布に依存するモデル出力です。たとえば解析的な把持品質指標から学習した予測値と、行動選択や方策価値を直接学習した出力では、数値が似ていても意味は同じではありません。高いスコアを「実際の成功確率」と解釈するには、別途検証が必要です。

また、不確実性には少なくとも二つの側面があります。観測ノイズや接触ばらつきのように、データ自体に固有の aleatoric uncertainty と、データ不足やモデルの知識不足に由来する epistemic uncertainty です。前者は同じ条件でも結果が揺れる要因、後者は未知の対象や条件に出会ったときに予測が不安定になる要因と考えられます。対応策が異なるため、合計値だけでなく内訳を保持する設計が有用です。

belief として状態を保持する

部分的にしか観測できない物体姿勢、形状、接触状態、摩擦などを、単一の推定値だけで表すと、計画は誤った前提に固定されます。そこで、状態についての信念、すなわち belief として候補や確率分布を保持し、行動と観測によって更新します。把持計画と観測計画を同じ枠組みで扱えば、把持を急ぐべきか、別の視点から見直すべきかを比較できます。

ただし、完全な belief-space 計画は計算量やモデル化の負担が大きくなります。実機では、候補生成、校正、実行ゲート、監視、検証、再計画、中止を状態機械として分離し、必要な範囲で近似する構成が扱いやすいでしょう。

確率校正と分布ずれの確認

意思決定に確率を使うなら、検証用データで校正します。予測確率をいくつかの信頼度ビンに分け、各ビンの平均予測値と実際の成功率を比較する reliability diagram を確認します。ECE や Brier score も、確率の整合性を評価する指標になります。分類精度が高くても、予測確率が実際の成功率と一致するとは限らないためです。

校正データは、学習時と同じ分布だけでなく、実行時に想定される対象、照明、視点、センサー、把持条件を含めて評価します。分布外やデータシフト下では不確実性の品質が変化し、アンサンブル、ベイズ近似、校正手法のいずれかが常に優れるとは限りません。校正済みの値であっても、安全リスクを十分に表すとは限らない点にも注意が必要です。

flowchart TD
  A["観測・状態推定"] --> B["把持候補を生成"]
  B --> C["成功確率を校正し、不確実性を分離"]
  C --> D["期待効用と安全制約を評価"]
  D --> E{"安全制約を満たすか"}
  E -- "いいえ" --> X["中止・退避"]
  E -- "はい" --> F{"追加観測で判断が改善する見込みがあるか"}
  F -- "はい" --> G["再観測"]
  G --> A
  F -- "いいえ" --> H{"実行の期待効用が許容範囲か"}
  H -- "いいえ" --> X
  H -- "はい" --> I["把持を実行"]
  I --> J["実行中の観測と状態監視"]
  J --> K["把持状態を検証"]
  K --> L{"検証に成功したか"}
  L -- "はい" --> M["完了"]
  L -- "いいえ" --> N{"別候補や別経路に価値があるか"}
  N -- "はい" --> O["再計画"]
  O --> A
  N -- "いいえ" --> X

把持候補の評価から再観測、実行、実行後の検証、再計画、中止・退避までを状態機械として示す。成功予測と安全制約は別々の判断信号として扱う。

実行・再観測・中止の判断

候補ごとに、校正済み成功確率、二種類の不確実性、把持余裕、接触や衝突に関する安全信号をまとめます。そのうえで、候補を実行したときの成功時の価値から、失敗・破損・落下・設備損傷などの損失を差し引きます。再観測については、観測によって候補順位や安全判定が変わる見込みと、観測時間、移動リスク、処理コストを比較します。これは「信頼度が低ければ必ず見る」という規則ではありません。

ロボット自己位置推定のセンサーフュージョン設計：カメラ・LiDAR・IMUの役割分担

Thu, 13 Aug 2026 01:47:13 +0900

センサーを増やすほど自己位置推定が安定するのか、環境条件から考え直せる点がこのテーマの面白さです。

導入

ロボットの自己位置推定で、カメラ・LiDAR・IMUを常にすべて使えばよいとは限りません。選択の基本は、IMUを短時間の運動伝播に使い、カメラは視覚特徴、LiDARは距離と幾何形状の拘束に使うことです。明るく特徴の多い環境ではカメラ+IMU、暗所や照明変動下で幾何が豊富な環境ではLiDAR+IMUが有力です。視覚と幾何のどちらか一方が失敗しやすく、冗長性も必要なら3センサー構成を検討します。

ただし、センサー数の多さだけで精度が決まるわけではありません。時刻同期、外部パラメータ、座標系、IMUバイアスを整合でき、追加される計算量と実装負荷を許容できることが前提です。

なぜ組み合わせの判断が必要か

自己位置推定は、各センサーの観測を同じ状態推定問題へ取り込む処理です。センサーには得意な時間スケールと失敗条件があります。IMUは高レートですが、バイアスやノイズを積分するため、単独では時間とともにドリフトします。カメラは再観測による相対的な拘束を与えられますが、照明やテクスチャに左右されます。LiDARは照明そのものではなく形状を観測できますが、幾何的に特徴の少ない場所や点群が疎になる条件では位置合わせが退化します。

したがって設計の問いは「どのセンサーが最も高性能か」ではなく、「対象環境でどの観測が残り、どの失敗を別の観測で補えるか」です。

各センサーが提供する情報

IMU：高レートの短期伝播

IMUは角速度と比力を取得し、姿勢・速度・位置の短時間の伝播を支えます。カメラやLiDARの観測間をつなぎ、高速運動時にも状態を更新できる点が役割です。一方、慣性積分だけでは誤差が蓄積するため、カメラやLiDARからの拘束でバイアスと状態を補正します。

カメラ：特徴と外観による相対拘束

カメラは画像特徴の追跡と、外観情報の再観測を利用します。十分な照明、視覚テクスチャ、適度なモーションがある環境では、IMUと組み合わせたVisual-Inertial Odometry（VIO）が機能します。画像特徴を一時的に追跡できない場合でも、IMUが短時間の運動拘束を提供しますが、視覚観測が長く失われれば慣性ドリフトを抑えにくくなります。

LiDAR：距離と幾何による拘束

LiDARは点群の距離・幾何形状を使い、スキャン間またはスキャンと地図の位置合わせを行います。暗所や照明変動の影響を受けにくい環境では、IMUと組み合わせたLiDAR-Inertial Odometry（LIO）が候補になります。IMUは短時間の運動推定だけでなく、点群のモーションデスクューにも利用できます。ただし、広く平坦な場所など幾何的な手掛かりが少ない環境では、LiDARの拘束が弱くなる可能性があります。

flowchart LR
  I["IMU\n角速度・比力"] --> P["高レートの短時間伝播\n姿勢・速度・位置"]
  C["カメラ\n画像特徴・再観測"] --> V["視覚拘束"]
  L["LiDAR\n距離・点群・幾何形状"] --> G["幾何拘束\nスキャン間または地図との位置合わせ"]
  I --> D["点群のモーションデスクュー"]
  D --> G
  P --> E["状態推定器"]
  V --> E
  G --> E
  E --> S["状態・IMUバイアスの補正"]
  E -.-> Q["品質指標の監視\n残差・イノベーションなど"]
  E --> M["推定状態"]
  K["EKF系または因子グラフ・平滑化系"] --> E

IMUによる短時間伝播に、カメラの視覚拘束とLiDARの幾何拘束を組み合わせる概念図。実際の性能や処理順序は実装に依存します。

代表的な構成の比較

構成	主な観測	向く条件	主な失敗条件・負荷
IMU単独	角速度・比力の積分	高レートの短期伝播	バイアスとノイズによるドリフト
カメラ+IMU（VIO）	画像特徴、再観測、慣性	明るく視覚特徴が豊富な屋内外	暗所、照明変動、テクスチャ不足、視覚追跡喪失
LiDAR+IMU（LIO）	点群の距離・幾何、慣性	暗所、照明変動下、幾何が豊富な場所	幾何的特徴の不足、点群が疎な条件
カメラ+LiDAR+IMU	視覚、幾何、慣性	視覚と幾何の一方が失敗しやすい環境、冗長性が必要な長時間運用	計算量、実装・校正負荷、同期や座標整合の複雑化

3センサー構成は、カメラとLiDARの観測が相互補完になるときに意味があります。たとえば照明条件が不安定でも形状が豊富ならLiDARが支え、幾何が一時的に弱くても視覚特徴が残っていればカメラが補います。ただし、3センサーの優位性をあらゆる条件で示す一般的な比較結果があるわけではなく、採用判断は環境、実装、計算資源に依存します。

接触作業のロボット制御設計：インピーダンス制御とアドミッタンス制御の選び方

Mon, 29 Jun 2026 09:02:33 +0900

接触作業の制御方式は、名称よりも信号の流れを見ると選びやすくなります。

先に結論

接触を伴うロボット作業でインピーダンス制御とアドミッタンス制御を選ぶときは、方式名の優劣ではなく、ロボットの下位制御器に何を入力できるか、力・トルクをどのように取得できるかを最初に確認する。トルクまたは電流指令を直接扱え、関節トルクを高い帯域で計測・推定できるなら、インピーダンス制御が自然な候補になる。一方、位置指令を主に扱うロボットに外部6軸力覚センサを組み合わせるなら、測定した力を位置・速度指令へ変換するアドミッタンス制御が実装しやすい。

ただし、接触の安定性や作業の成否は、インピーダンスかアドミッタンスかだけでは決まらない。ロボットと環境の剛性、仮想ダンピング、制御周期、通信・計算遅延、センサの特性、指令の飽和、安全機構を含む閉ループ全体で検証する必要がある。

なぜ選定が難しいのか

組立、研磨、挿入、押し付けでは、対象物に触れた後も手先を動かし続けなければならない。完全な位置制御では、位置誤差や幾何公差によって過大な接触力が発生し得る。そこで、手先の運動と接触力の関係を柔らかく設計する力・運動制御が使われる。

難しさは、同じ「コンプライアンス」や「力制御」という名称でも、実装の信号経路が異なる点にある。文献や製品の説明では、位置制御器を介した外側ループまで広義のインピーダンス制御と呼ぶことがある。そのため、名称ではなく、入力、出力、センサ、内側ループの構成を確認する必要がある。

2つの制御方式の前提

インピーダンス制御は、手先の運動と環境との接触力・トルクの間に、目標質量、ダンピング、剛性で定めた動的関係を実現する制御である。概念的には、目標運動と実際の運動の差から、仮想的なばね・ダンパ・質量に相当する力またはトルクを計算し、それをロボットのトルク系へ渡す。

アドミッタンス制御は逆向きの構成である。測定または推定した外力・外トルクを入力とし、仮想質量、ダンピング、剛性のモデルを通じて、位置、速度、加速度の指令を生成する。その指令を下位の位置・速度制御器へ渡し、ロボットを動かす。外部6軸力覚センサを手先に配置する構成は、この方式と組み合わせやすい。

この違いは、数式上の分類にとどまらない。実務では「力・トルクを出力しやすいか」「運動指令を出力しやすいか」というロボットAPIや内側制御器との適合性が、実装のしやすさを大きく左右する。

flowchart LR
  subgraph IMP["インピーダンス制御"]
    I1["目標運動・状態誤差"] --> I2["仮想質量・ダンピング・剛性"]
    I2 --> I3["力・トルク指令"]
    I3 --> I4["トルク／電流系の下位制御器"]
    I4 --> R1["ロボット"]
  end

  subgraph ADM["アドミッタンス制御"]
    A1["外力・外トルク"] --> A2["外部6軸力覚センサまたは外力推定"]
    A2 --> A3["仮想質量・ダンピング・剛性"]
    A3 --> A4["位置・速度・加速度指令"]
    A4 --> A5["位置・速度系の下位制御器"]
    A5 --> R2["ロボット"]
  end

  R1 --> E["接触環境"]
  R2 --> E
  E -. "接触力・運動のフィードバック" .-> I1
  E -. "外力・外トルク" .-> A1

インピーダンス制御とアドミッタンス制御の概念的な信号方向と、適合しやすい下位制御器の違いを示します。実際の実装では、外力推定、内側ループ、座標変換などの構成が異なる場合があります。

インピーダンスとアドミッタンスの比較

観点	インピーダンス制御	アドミッタンス制御
基本的な関係	運動から力・トルクを生成	力・トルクから運動を生成
主な出力	力指令・トルク指令	位置・速度・加速度指令
適合しやすい下位IF	トルク指令、電流指令	位置指令、速度指令
主な計測・推定	関節トルク、外力推定、手先運動	外部6軸力覚、外力・外トルク推定、手先運動
調整対象	仮想質量、ダンピング、剛性	仮想質量、ダンピング、剛性
典型的な構成	力学特性をトルク制御型ロボットで実現	力覚センサを外側ループに置き、位置・速度制御器へ接続
主な注意点	トルク計測・推定と内側ループの帯域	センサノイズ、遅延、位置指令の帯域
単独方式が不十分な場合	方向別の力・位置制御を追加	方向別の力・位置制御を追加

選定の手順

第一に、利用可能な指令インタフェースを確認する。トルクまたは電流指令を扱えるロボットで、関節トルクの計測・推定が十分に利用できるなら、インピーダンス制御を候補にする。タスク空間で設計した力学特性を関節トルクへ変換できるためである。

ロボットのセンサー異常処理設計：検出から安全な縮退運転まで

Fri, 15 May 2026 01:02:32 +0900

センサーが値を返し続けているときほど、通信監視だけでは異常を見逃しやすい点が気になります。

先に結論

ロボットのセンサー異常は、単一の監視箇所に集約せず、通信・データ取得、値の妥当性、状態推定、センサー間整合性、行動・安全監視の複数層で検出する設計が適しています。各層で観測できる異常が異なるためです。

欠損、異常値、不一致は同じ故障として扱いません。欠損や遅延は鮮度低下、範囲外や急激な外れ値は測定拒否、センサー間不一致は比較と故障候補の隔離として扱います。安全機能を維持できるなら速度や機能を制限し、代替観測が使えなければ停止へ移行します。

なぜ検出層を分けるのか

センサーが停止した場合、メッセージの到着間隔や通信相手の生存性を監視する層で検出しやすくなります。しかし、センサーが値を送り続けていても、固定値や環境に対してもっともらしい誤値を出すことがあります。通信が正常でも、値の意味まで正常とは限りません。

逆に、状態推定層で観測値を拒否できても、複数センサーの不一致や、安全機能に必要な観測が残っているかは別途確認が必要です。異常検出と行動決定を分け、どの層がどの種類の異常を検出したかを診断情報として伝える構成が扱いやすくなります。

前提となる用語

本稿では、欠損をメッセージが届かない、または許容される鮮度を失った状態、範囲外を扱える値域から外れた状態、外れ値を推定状態などから大きく乖離した値、不一致を複数センサーや推定結果が整合しない状態とします。

ROSの診断メッセージ仕様であるREP-107は、診断状態をOK、WARN、ERROR、STALEに分類します。ただし、各状態で停止するか、速度を制限するか、継続するかまでは規定していません。診断状態と行動ポリシーは、システム側で対応付けます。

各層の検出責務

通信・データ取得層

メッセージが期待周期で届くか、通信相手が生存しているかを確認します。ROS 2のDeadline QoSは、連続するメッセージ間の許容最大時間を定義し、期限超過をイベントとして検出できます。Liveliness QoSは、パブリッシャーなど通信相手の生存性を監視します。

これらは到着間隔や生存性を扱う機能であり、値の妥当性やタイムスタンプの意味まで検証するものではありません。

センサー値の妥当性層

型、値域、更新状態、センサー固有の自己診断などを確認し、明らかに利用できない値を上位へ渡さない層です。ただし、範囲内に収まる固定値や誤値は、この検査だけでは十分に検出できません。

状態推定層

推定状態と観測値の差を調べます。robot_localizationの資料では、マハラノビス距離による拒否しきい値を設定し、予測状態から大きく外れたpose、twist、accelerationの測定値を拒否できます。通信が正常でも、推定と整合しない観測を取り込まないための方法です。

整合性・安全監視層

冗長センサーがあれば、複数入力の整合性を比較できます。PX4には、センサーの状態や整合性を監視し、投票で使用センサーを選び、不健全なセンサーを投票から除外し、必要に応じてフェイルセーフへ移行する実装があります。

Nav2 Collision Monitorには、入力が一定時間届かない場合にソースをstaleとして扱い、速度指令の制限や停止へ移行させる実装があります。いずれも特定のソフトウェア構成に依存する実装例であり、すべてのロボットへそのまま一般化できるわけではありません。

flowchart LR
  A["センサー入力"] --> B["通信・データ取得層\n到着周期・生存性・タイムアウト"]
  B --> C["センサー値の妥当性層\n型・範囲・更新状態"]
  C --> D["状態推定層\n予測状態との差・外れ値拒否"]
  D --> E["センサー間整合性監視層\n冗長入力・推定結果の比較"]
  E --> F["行動・安全監視層\n安全機能の可用性を判定"]

  B -. "欠損・遅延・配信停止" .-> G["STALEとして診断"]
  C -. "範囲外" .-> H["異常値を上位へ渡さない"]
  D -. "推定と大きく乖離" .-> I["測定値を推定更新から除外"]
  E -. "センサー間不一致" .-> J["故障入力を隔離・冗長系を検討"]

  F --> K{ "安全機能を維持できるか" }
  K -->|"維持できる"| L["速度・加速度・可動範囲・自律機能を制限"]
  K -->|"代替観測を利用できる"| M["冗長センサーへ切替"]
  K -->|"必要な観測を確保できない"| N["停止"]

  G --> F
  H --> F
  I --> F
  J --> F

センサー異常を単一の監視ノードで判定せず、検出責務を複数層に分けて行動ポリシーへ結び付ける構成を示します。

異常種別と行動の比較

異常の種類	主な検出層	処理の例	行動の例
欠損・到着間隔超過	通信・安全監視	STALE相当として鮮度を評価	速度制限、機能停止、停止
範囲外	値の妥当性	入力から除外	代替入力の検討、継続可否判定
急激な外れ値	状態推定	イノベーションや距離で拒否	推定更新から除外、機能制限
センサー間不一致	整合性監視	比較、故障候補の隔離	冗長系切替、必要なら停止
安全観測の喪失	行動・安全監視	安全機能の可用性を評価	保守的状態、停止

表の状態名と行動の対応は、REP-107の一般規則ではありません。許容時間や安全上の意味を、対象システムごとに定義する必要があります。

カメラとLiDARの外部キャリブレーション：点群と画像を正しく重ねる方法

Sat, 25 Apr 2026 00:51:08 +0900

画像と点群のずれは、外部変換だけでなく時刻やレンズ歪みにも現れます。切り分けを手順に組み込めるかが気になったテーマです。

結論

カメラとLiDARの融合で最初に固定すべきなのは、校正アルゴリズムよりも座標系、変換方向、単位、時刻基準です。そのうえで、カメラの内部パラメータとレンズ歪みを先に校正し、同期した観測からLiDAR座標系をカメラ座標系へ写す剛体変換を推定します。最後に、校正に使っていない姿勢・距離・視野・速度のデータへ点群を再投影し、誤差の大きさと分布を確認します。

校正時の残差が小さいだけでは不十分です。画像上のずれが内部パラメータ、外部変換、時間オフセット、LiDARの走査遅延のどれに由来するかを条件別に切り分け、用途に応じた合格基準を定める必要があります。

なぜ外部キャリブレーションが重要か

カメラは画素、LiDARは3次元点として同じ対象を観測します。しかし、それぞれの座標原点や軸方向は異なります。外部パラメータに誤りがあると、LiDAR点を画像へ重ねたときに、物体の輪郭から一定方向へずれたり、距離によってずれが変化したりします。物体検出への深度付与、障害物の位置推定、画像と点群の対応付けでは、この空間的な不整合が直接結果に影響します。

前提となる用語

外部パラメータは、LiDAR座標系の点をカメラ座標系へ変換する回転と並進、つまり剛体変換として管理します。実装では、変換をどちら向きに適用するのか、フレーム名、長さの単位、時刻基準を明示します。フレーム間の関係は一貫したフレームツリーで管理し、同じ数値を別の座標軸定義へそのまま移植しないことが重要です。

内部パラメータは焦点距離や主点など、カメラ内部の投影特性を表します。レンズ歪みモデルも画像投影に関係するため、外部変換とは分けて推定し、外部キャリブレーションの前に妥当性を確認します。内部行列と歪みモデルが不正確なままでは、外部変換を調整しても再投影誤差を正しく解釈できません。

推奨する校正手順

1. センサーを剛体として固定する

カメラとLiDARの取り付けを固定し、校正中に相対位置が変わらない状態を作ります。振動や取り付け部の変形が疑われる場合、得られた変換はその時点の状態に限られる可能性があります。

2. 座標系と時刻を確認する

各センサーのフレーム名、軸方向、単位、変換の保存方向を記録します。さらに、ハードウェア同期の有無、LiDAR点ごとのタイムスタンプ、走査中の運動補償の有無を確認します。移動中に時間同期が不足すると、時間オフセットが空間的な外部パラメータ誤差として現れます。必要なら時間オフセットを別パラメータとして推定・検証します。

3. カメラ内部を校正する

平面パターンなどを複数の視点から撮影し、内部パラメータ、歪み、各撮影姿勢を推定します。単一画像だけに依存せず、複数視点の観測で結果を確認します。ここで得た投影モデルを固定してから、カメラとLiDARの外部変換へ進みます。

4. 対応を集めて初期値を求める

既知形状のターゲットを使う場合、LiDAR側の3次元特徴と画像側の2次元特徴、またはターゲット平面を対応付けます。十分な姿勢や視点の違いを含む観測から、まず外部変換の初期値を求めます。初期値の品質が低いと、後段の非線形最適化が適切な解へ到達しない場合があります。

5. SE(3)上で最適化する

初期変換を出発点に、3次元点をカメラ座標系へ変換し、内部パラメータと歪みモデルを適用して画像へ投影します。3D-2Dの再投影残差、点と平面の残差など、利用できる対応に応じた目的関数を最適化します。

flowchart LR
  A["センサーを剛体として固定"] --> B["座標系・単位・変換方向・時刻を確認"]
  B --> C["カメラ内部パラメータと歪みを校正"]
  C --> D["同期した観測データを収集"]
  D --> E["3D-2Dまたは特徴・平面の対応を作成"]
  E --> F["外部変換の初期値を推定"]
  F --> G["SE(3)上で再投影・幾何残差を最適化"]
  G --> H["未使用データで再投影・幾何・時間整合を検証"]
  H --> I["条件別の誤差を診断して合否基準を判断"]
  I -. "運動時のみ誤差が増える場合" .-> B

外部キャリブレーションは、内部校正と座標・時刻の確認を分けたうえで、初期推定、SE(3)最適化、独立データによる検証の順に進めます。

ターゲット方式とターゲットレス方式

既知ターゲット方式は、対応する幾何が明確で、初期推定と残差の意味を説明しやすい方法です。一方、設置や撮影の準備が必要で、ターゲットの見え方や配置が観測条件を制限します。

ターゲットを設置しない方式では、LiDAR点群の反射強度や投影情報と、画像の明るさ・外観との相互情報量を最大化する方法が提案されています。また、画像エッジなどの視覚特徴とレーザー点の幾何を使い、運用中に外部パラメータを調整する方式もあります。ただし、シーンのテクスチャ、反射率、天候、動的物体による安定性は個別データで確認する必要があります。

方式	準備	強み	注意点
既知ターゲット	ターゲット設置と対応抽出	幾何的に解釈しやすく、初期推定を作りやすい	設置条件と視点の設計が必要
相互情報量によるターゲットレス	専用ターゲット不要	実環境の観測を利用できる	外観や反射特性への依存を確認する必要がある
画像エッジとレーザー特徴	運用中の特徴観測	固定ターゲットに依存せず更新を目指せる	特徴の量と動的環境の影響を受ける
時空間キャリブレーション	同期状態を含む観測	空間変換と時間オフセットを同時に扱える	固定・同期済みのシステムでは必要な自由度を見極める必要がある

融合結果の検証方法

推定した変換でLiDAR点をカメラ座標系へ移し、深度が正の点だけを残します。その後、内部行列と歪みモデルで画像へ再投影し、次の項目を記録します。

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

Fri, 06 Mar 2026 00:23:05 +0900

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

先に結論

カメラ・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

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

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

イベントカメラをロボットに使う判断：高速動作・HDR・低遅延の実装上の利点と限界

Fri, 06 Feb 2026 08:13:12 +0900

高速動作を撮るカメラでは、画像の鮮明さだけでなく、いつ変化を捉えたかが判断を左右します。

先に結論

イベントカメラは、視覚処理の中心が「絶対的な画像」ではなく「時間的な輝度変化」にある場合に、フレームカメラより有利になり得ます。高速搬送物の追跡、回転体の運動推定、移動ロボットの急旋回時の光フロー、視覚オドメトリ、視覚慣性オドメトリ、明暗差の大きい環境での動体検出が代表例です。

一方、静止物体の外観、色、テクスチャ、絶対輝度を使う認識では、そのまま置き換えられません。実装では、運動推定をイベントカメラ、外観認識をフレームカメラに分担させる併用構成を優先して検討するのが現実的です。

なぜ選択が重要なのか

フレームカメラは一定周期で画像全体を取得します。高速に動く対象では、露光中の移動によるモーションブラーや、フレーム間にある時間情報の欠落が問題になり得ます。逆に、対象がほぼ静止していて色や表面模様を認識するなら、画像全体を得られるフレームカメラのほうが扱いやすいでしょう。

したがって、判断すべきなのは「どちらが高性能か」ではありません。対象タスクが必要とする情報が、時間変化なのか、絶対的な外観なのかを分けることが出発点になります。

前提となる仕組み

イベントカメラは、一定周期でフルフレームを出力するのではなく、各画素で対数輝度の変化を監視します。変化がしきい値を超えると、画素位置、発生時刻、極性、つまり明るくなったか暗くなったかを持つイベントを非同期に出力します。

そのため、静止した一様な領域からは基本的にイベントが発生しません。イベントを一定時間窓で集めて画像状に表示することはできますが、それは絶対輝度画像そのものではありません。イベント列から画像や極性画像を生成するほか、時刻と位置を直接使って光フロー、エッジ追跡、特徴点追跡、動体の速度推定を行う構成も考えられます。

flowchart LR
  subgraph F["フレームカメラ"]
    F1["一定周期で露光"] --> F2["フルフレームを読み出し"] --> F3["画像処理・推論"] --> F4["認識または運動推定"]
    F1 -.-> F5["露光条件によってモーションブラーが生じ得る"]
    F2 -.-> F6["絶対輝度や色を画像として取得しやすい"]
  end

  subgraph E["イベントカメラ"]
    E1["各画素で対数輝度の変化を監視"] --> E2["しきい値を超えた輝度変化を検出"] --> E3["位置・時刻・極性付きイベントを非同期出力"] --> E4["イベント列を処理"] --> E5["光フロー・追跡・速度推定・オドメトリ"]
    E1 -.-> E6["静止した一様領域からは基本的にイベントが出にくい"]
    E3 -.-> E7["変化が疎ならデータ量を減らせる可能性"]
    E3 -.-> E8["振動・全面運動・明滅ではイベントレートが増え得る"]
  end

  E5 --> H["ロボットの認識・制御"]
  F4 --> H
  E3 -.-> D["センサの時間性能"]
  E4 -.-> D
  D -.-> L["推論・通信・制御周期を含むエンドツーエンド遅延とは別に評価"]

フレームカメラはフルフレームと絶対的な外観情報を扱いやすく、イベントカメラは画素単位の時間情報を利用して運動推定を行う。センサの時間性能だけでなく、推論・通信・制御を含むエンドツーエンド遅延も評価する必要がある。

センサ内部の短い応答遅延と画素単位のタイムスタンプは、高速運動時の時間分解能を高め、フレーム撮影に伴うブラーを抑えやすくします。ただし、センサの時間性能はシステム全体の遅延ではありません。イベント処理、ノイズ除去、特徴抽出、推論、通信、制御周期まで含めて評価する必要があります。

ロボットに触覚と力覚を加える設計判断：視覚との役割分担

Sun, 25 Jan 2026 00:05:01 +0900

視覚に情報を集約する設計は分かりやすい一方、接触した瞬間から別の観測が必要になる点が気になります。

先に結論

ロボットに触覚・力覚センサーを追加する価値は、視覚を置き換えることではなく、接触後に増える観測の曖昧さを減らし、制御を切り替えられる点にある。視覚は対象の大域的な位置や形状を非接触で捉える。一方、指先などの触覚センサーは接触部の圧力、変形、局所形状を捉え、手首の力覚センサーは手先に作用する合力・合トルクを捉える。

したがって、対象への接近と大域的位置決めには視覚、接触検出と荷重監視には力覚、把持面の状態や滑り兆候の推定には触覚を使い分ける構成が基本になる。ただし、視覚だけで接触状態を間接推定できる場合もあるため、採用は作業の接触性、必要精度、損傷リスク、実装負荷を比較して決めるべきである。

なぜ視覚だけでは不十分になりやすいのか

カメラは対象全体の位置や形状を把握するのに向いている。しかし、手や対象に隠れた接触面、接触パッチの形状、接触圧力の分布は、視覚から直接観測しにくい。把持後に物体が正しい位置にあるように見えても、指先の接触が偏っていたり、滑り始めていたりする可能性がある。

また、挿入や嵌合では、目標位置が分かっていても、部品同士がどの方向で接触しているか、押し付けが強すぎないかを位置情報だけで判断しにくい。接触力やトルクを監視しながら、硬く位置を追従する状態から、環境になじむコンプライアンス制御へ切り替える必要がある。

「視覚では解けない」という表現は絶対的ではない。既知の対象、十分な視認性、適切な物理モデル、学習済みの推定器があれば、視覚から把持成否や力を間接的に推定できる場合もある。触覚・力覚は、視覚の全面的な代替ではなく、接触状態を観測する追加チャネルと考えるのが適切だ。

前提となるセンサーの違い

触覚センサーは、指先やハンド表面など、接触に近い場所で局所的な情報を取得する。方式によって、法線力、せん断力、圧力分布、接触形状など、得られる物理量は異なる。光学式触覚センサーの一例では、接触によるエラストマー表面の変形を画像として取得し、接触形状や力を推定する。

力覚センサーは、代表的には手首に配置され、Fx、Fy、FzとTx、Ty、Tzの6成分を扱う。複数の接触が手先に与える総合的な荷重を監視できる一方、センサー単独で接触点や圧力分布を一意に復元できるとは限らない。局所接触に強い触覚と、手先全体の荷重監視に強い力覚は代替関係ではない。

センサー	主な観測対象	強い場面	苦手・制約
視覚	大域的な位置・形状	接近、対象認識、初期位置決め	遮蔽された接触面や圧力分布を直接観測しにくい
指先触覚	局所圧力、変形、接触形状、接触状態	把持成否、接触位置、滑り兆候の推定	局所情報が中心で、手先全体の合力・合トルクは直接表さない
手首6軸力覚	手先に作用する合力・合トルク	接触検出、荷重監視、挿入・嵌合	接触点や圧力分布を単独では一意に決めにくい

内部の仕組みとデータフロー

実装では、センサーを常時同じ目的で使うのではなく、作業状態に応じて役割を切り替える。まず視覚で対象の位置と形状を推定し、ロボットを接触直前まで移動させる。次に力覚の変化から接触を検出し、位置制御からインピーダンス制御やハイブリッドな位置・力制御へ移行する。これにより、押し付け力や接触時の剛性を調整できる。

接触後は、指先触覚から局所的な接触分布や把持状態を確認する。把持が不十分、または滑りの兆候があると判断した場合は、把持力や手の姿勢を調整し、必要なら再把持する。視覚と触覚から把持成否を予測して再把持する方策は、研究上も提案・評価されている。最後に、視覚と接触情報を組み合わせ、作業完了、異常、再試行を判定する。

flowchart LR
  A["視覚で対象の位置・形状を推定"] --> B["接触直前まで接近・初期位置決め"]
  B --> C["力覚の変化を監視"]
  C --> D{"接触を検出したか"}
  D -- "いいえ" --> B
  D -- "はい" --> E["位置制御からインピーダンス制御・ハイブリッド位置力制御へ切り替え"]
  E --> F["押し付け力・接触時の剛性を調整"]
  F --> G["指先触覚で局所接触分布・把持状態を確認"]
  G --> H{"把持不十分または滑り兆候ありか"}
  H -- "はい" --> I["把持力・手の姿勢を調整"]
  I --> J{"再把持が必要か"}
  J -- "はい" --> I
  J -- "いいえ" --> K["力覚で荷重・嵌合異常を監視"]
  H -- "いいえ" --> K
  K --> L["視覚と接触情報を組み合わせて結果判定"]
  L --> M{"作業結果"}
  M -- "完了" --> N["作業完了"]
  M -- "異常・再試行" --> O["停止・退避または再試行"]

視覚は接近と初期位置決め、力覚は接触検出と荷重監視、触覚は局所的な把持状態の確認に使い、観測結果に応じて制御や再試行を切り替える。

この流れでは、センサー値を単に追加するだけでは足りない。どの観測をどの状態遷移の条件に使うか、また力の異常を停止、退避、再試行のどれに結び付けるかを制御仕様として定義する必要がある。