テーパー測定、最初に試したiPhone LiDARスキャンが失敗した話

課題

前回の記事で書いたスマホ望遠カメラによるテーパー測定には、前段がある。最初から疑似平行投影を思いついたわけではない。最初に手を出したのは、もっと直接的に見える方法だった。3Dスキャンして点群に円錐をフィットすれば、一発ではないか。角度も直径も一度に出るし、撮影条件を細かく揃える必要もなさそうに見える。iPhoneにはLiDARも載っている。素直に考えれば、まずこちらである。

結論だけ読む場合はまとめへ。

きっかけは WIDAR という市販の3Dスキャンアプリ（執筆時点でサービス終了済み）を見たことだった。UI・共有・エクスポートといったプラットフォーム部分はともかく、コアのスキャン処理は Apple が標準で提供する ObjectCapture / ARKit の薄いラッパーのはずだと踏んだ。それなら同等の機能は自前で組める。そう判断して着手した。

着眼

ObjectCapture と ARKit の LiDAR メッシュ書き出しを組み合わせ、対象の周りを歩きながら撮って3Dメッシュを再構成し、そこからテーパー面をフィットする。専用の治具なしにスマホを動かすだけで3Dデータが取れる、というのが ObjectCapture の売りである。パイプラインの絵はすぐに描けた。

実装は、実際に簡単だった

「コアは標準フレームワークの薄いラッパーのはず」という読みは当たった。ObjectCapture のセッションを開始し、LiDAR メッシュを書き出すまでのアプリは、フレームワークが用意する状態遷移（検出→撮影→再構成）に沿って書くだけで組み上がった。ここまでは何の波乱もない。正直、楽勝だと思っていた。

失敗

実機でアプリを対象に向けたところ、撮影状態にすら入れなかった。startDetecting は false を返し続け、フィードバックは movingTooFast（動きが速すぎる）と environmentLowLight（照度不足）の繰り返し。動きを遅くしても、照明を変えても、距離を変えても、撮影枚数はゼロのまま動かなかった。

実装は組み上がっているのに、一歩も進まない。コードに疑うべき箇所がないぶん、原因はかえって掴みにくかった。

診断

調べていくと、これは条件出しで越えられる壁ではなかった。

分解能が足りない。公開されている検証によれば、iPhone の LiDAR が実用精度を出せるのはおおむね10cm以上のスケールの対象である。ミリ単位のテーパーディテールは、そもそもセンサの分解能の外にある。

特徴点がない。ObjectCapture の写真測量は、複数枚の画像間で表面の特徴を対応づけてメッシュを再構成する。今回の対象は小さく、滑らかで、軸対称。フレーム間で対応づけられる手掛かりが表面にほとんど無い、写真測量にとって最悪に近い形状である。movingTooFast という警告も、実際に速く動かしていたからではなく、特徴点を見失った自己位置推定が破綻していたことの表れだったと考えている。

つまり、実装がまずかったのではない。センサの分解能と対象の形状という物理の側で、この方法は最初から成立していなかった。

転換

後付けの安価なテレセントリック変換レンズで正攻法に寄せる逃げ道も探したが、市販品は見つからなかった。

そこで問題を一段引いて見直した。対象は軸対称なテーパー面であり、欲しいのは3D点群ではなく、シルエットの2本のエッジがなす角というスカラー量1つだけである。なら3D再構成はそもそも要らない。次元を1つ落とし、静止画1枚のシルエットから角度を読む方向に切り替えた。これが前回の記事の、望遠で距離を稼いで疑似平行投影に近づける手法に繋がっている。

まとめ

この失敗の教訓は「LiDARスキャンが下手だった」ではない。測りたい量に対して選んだ原理の次元が過剰で、しかもその原理が対象の形状と最悪に近い相性だった、ということだ。実装は読みどおり簡単だった。しかし実装が簡単であることと、原理が対象に対して成立することは、まったく別の軸である。

専用機材がないときに最初に問うべきは「代わりの道具を簡単に組めるか」ではない。「そもそも何次元の情報が要るのか」「その原理はこの形状で成立するのか」である。この2つに先に答えていれば、このアプリは書かずに済んだ。もっとも、書いたおかげで次の手法が正解だった理由まで説明できるようになったのだから、授業料としては安かったと思う。