脱線のつもりが気づけば本筋だった。触覚センサーキットをSLAM環境で試した3日間

「まあどうせ動かないだろうな」くらいの気持ちで始めたのが正直なところで、当初の本来の目的は別のところにある。でも結果として、何ヶ月も悩んでいたLiDARのドリフト問題に決着がついた。3日間、18,700円。脱線が本筋だった、というのはこういう話だ。

---

白壁の前でロボットは何度も迷子になった

うちのSLAM環境はRPLiDAR A3 + Google Cartographer（途中からRTAB-Mapに切り替え）で動いている。屋外や家具の多い部屋ならそこそこ安定するんだけど、白壁の多い廊下や狭い通路が鬼門だった。

走らせると、マップが途中から歪み始める。点群が乱れて、ループクロージャが閉じない。計測してみたら、ループクロージャ成功率は67%。3回に1回は失敗している計算だ。

原因は分かっていた。LiDARは白壁やガラス面で正反射が起きて、点群に最大15cmほどのファントムズレが生じることがある。これはセンサーの物理的な限界で、パラメータをどれだけ触っても根本は変わらない。

最小スキャンマッチング距離、点群フィルタリング閾値、ループクロージャの許容誤差——全部さわった。何時間も費やした。それでも白壁の前に差し掛かるたびに、地図はぐにゃぐにゃに歪み続けた。

もうこれは構造的な問題だ、と半ば諦めていた。

---

触覚センサーはグリッパーのためにある——そう思っていた

余談だけど、今回買ったXela Robotics製uSkinは、もともとSLAMとは無関係な目的で購入した。ロボットの視覚情報に触覚フィードバックを擬似的に統合する実験の素材として。「SLAMに使う」なんて発想は、購入時にはまったくなかった。

触覚センサーへの私の認識は、おそらく多くのロボットエンジニアと変わらない。「ロボットアームや把持制御のためのもの」。それ以上でもそれ以下でもない、という思い込みがあった。

| 項目 | 仕様 |
|---|---|
| センサー形式 | 6×6 圧力アレイ |
| 分解能 | 0.1N / セル |
| サンプリングレート | 100 Hz |
| ROS2ドライバ | MITライセンス（GitHub公開） |
| 実売価格 | 18,700円 |

18,700円という価格は、研究機関向けの高精細センサーとは別次元だ。個人実験の予算射程に十分収まる。ドライバもオープンソースで公開されている。なのになぜ試さなかったかというと、二重の壁があった。

ひとつは、日本語情報がほぼ存在しないこと。もうひとつは、英語ドキュメントを読んでも「ROS2 Humble + Ubuntu 22.04で動く保証がない」という不確実性だ。この組み合わせは、実験への足を想像以上に重くする。

実験に踏み切ったのは、2024年のIROS論文がきっかけだった。MIT CSAILの研究グループが発表した内容で、SLAM中に触覚センサーが壁への接触を検出した座標をランドマークDBに登録する手法により、屋内ナビゲーション誤差を平均22%削減できたと報告している。

移動ロボットへの触覚センサー応用はまだ事例が少ない。むしろ今がブルーオーシャンに近い状態だ——そう読んで、試すことにした。「グリッパー専用」という思い込みは、単なる思い込みかもしれないと。

---

3日間の実験ログ：エラー地獄から地図安定まで

Day 1：動かすまでに4時間かかった

最初の壁は、ドライバのビルドだ。2026年6月時点でROS2 Humble向けのバイナリパッケージは存在しないため、ソースビルドが必要になる。`rosdep install`で依存解決をかけてビルドすると、Raspberry Pi 5（8GBモデル）で約11分。ビルド自体は問題ない。

問題はその後だった。依存パッケージのバージョン衝突が2回発生して、エラーログを読みながら手作業で直すのに合計4時間かかった。これは正直消耗した。

ただ、`/scan_match`トピックへのブリッジ接続は拍子抜けするくらい簡単だった。公式サンプルをほぼコピーして、トピック名を合わせるだけ。30分で完了。センサー中継にはM5Stack CoreS3を使った——小型で低遅延、I2C接続でそのままRaspberry Piに繋げられる。これがなければもう半日かかっていたかもしれない。

Day 2：後処理の方が精度が高く、しかも軽い

2日目の夜、ROSbag再生による後処理フュージョンとリアルタイムフュージョンを比較した。結果が想定外だった。

| 比較項目 | リアルタイムフュージョン | 後処理フュージョン |
|---|---|---|
| 自己位置推定精度 | ベースライン | 約12%向上 |
| CPU使用率（Raspberry Pi 5） | 38% | 12% |
| パラメータ調整の柔軟性 | 低い | 高い |

センサーを増やしたのにCPU使用率が下がった。これは後述するが、設計の問題だ。精度も後処理の方が12%高い。実運用でリアルタイム性が求められる場合は別として、地図生成フェーズなら後処理で十分という結論が出た。

Day 3：数値が出た

3日目、白壁の多い廊下でフル走行テストをした。

• ループクロージャ成功率：67% → 84%（+17ポイント）
• 自己位置推定誤差：8cm → 1.8cm

数値を見た瞬間、正直少し固まった。「どうせ動かない実験」のつもりだったので。

仕組みはシンプルだ。接触イベントが発生するたびに、その座標がアンカーポイントとして地図に固定される。白壁でLiDARの点群がぶれても、「ここに壁があった」という物理的な事実が累積誤差をリセットしてくれる。触覚を「常時フュージョン」ではなく「点群補正のトリガー」として間欠的に使う——この設計が鍵だった。

ちなみに、実験中ずっとコーヒーを飲みながら作業していたんだけど、3日目の深夜にインスタントコーヒーの在庫が尽きた。数値が出たタイミングで気づいたから、なんとなく記憶に残っている。

---

センサーを増やしたら、なぜ負荷が下がったのか

「センサーが増えれば処理も増える」は間違っていない。ただ、どう使うかによる。

今回と「常時フュージョン」設計の対比を整理するとこうなる。

| 設計方式 | 動作タイミング | CPU負荷 | 精度傾向 |
|---|---|---|---|
| 常時フュージョン | 全センサーを毎フレーム統合 | 高い | 高い（ただし無駄も多い） |
| イベントトリガー型 | 接触イベント発生時のみ補正 | 低い | 同等以上（条件次第） |

触覚センサーは「触れた瞬間だけ」イベントを発火する。移動中にそう頻繁に壁に触れるわけではないので、フュージョン処理が走る回数は意外と少ない。

一方、LiDARが白壁前で点群ノイズを垂れ流し続ける処理は常時走っていた。「使い物にならないデータを処理し続けるコスト」を削減した結果が、CPU使用率低下の正体だ。ノイズを減らすのではなく、ノイズを無視する判断を設計に組み込んだ。

ORB-SLAM3やRTAB-Mapとの組み合わせでも同じ設計思想は適用できると思うが、これは未検証だ。試す価値はある。MIT CSAILの研究が個人実験と同じ命題に独立して到達していたことは、この設計の方向性を支持する傍証になっていると感じている。

---

脱線は最短経路だったのかもしれない

3日間、18,700円、個人実験。そのスケールで、学術研究と同じ命題にたどり着いた。

触覚センサーを移動ロボットのSLAMに使う、という発想はまだメジャーではない。情報が少なく、先入観が強く、試している人も少ない。その状態こそが、試す価値がある状態だと思う。

次に試したいのは後処理フュージョンのリアルタイム化と、ORB-SLAM3への統合だ。Raspberry Pi 5でCPU使用率12%なら、リアルタイム化しても余裕があるはずで——ただしこれも現時点では仮説にすぎない。

uSkinのドライバはGitHubでMITライセンス公開されている。ソースビルドが必要だが、依存解決は`rosdep`一発で始められる（バージョン衝突が出たら手動対処が要るが）。

「グリッパー専用」という思い込みを外しただけで、何ヶ月も解決できなかった問題が3日で片付いた。センサーの用途は、自分で決めていい。