自分で作る、デテント光学歩度測定器への道

唐突に思いついて、週末プロジェクトとして開発しながらTwitterに書き散らかしていたものを備忘録を兼ねてまとめておきたいのでレポートします。
WMOで「クソパワポ」はよく使いますが、ひさびさの「クソプログラム」、欲しいものは自分で作ろうと思い立ったことです。

作りかけの状態を動画で。



デテント脱進機の挙動を高速カメラ(iPhone12のスローモーションモード)で検出し、歩度をはじめとしたそれぞれのパラメータを測ってみようという試みです。

そもそものモチベーションとしては、デテント天文台クロノメーターを手に入れたことから始まります。
このムーブメントは日較差(日ごとの日差のバラつき)は非常に優秀でしたが、日差自体の値はプラス方向で1週間に3分程度進む状態でした。
これはデテント脱進機の脱進音は一般的なスイスレバーとは大きく異なり、音を拾って歩度を測定する一般的なWitschi社の測定器では測定できないからです(特殊なモードを持つ上位機ならできるという情報もありますが、未検証)、そのため、オーバーホール後は24時間ごとの遅れと進みを見て緩急針を調整していたようです、日較差が優秀なので日差はプラスなら良い…とはいうものの、もう少し追い込めないかな？とは常々思っていました。

もう一つの理由は、去年末に満身創痍だったiPhone SE(初代)からiPhone 12miniに機種変更し、スマホのカメラ機能の性能が格段に向上、120fps(2倍スロー)だったスローモーションが240fps(4倍スロー)で撮れるようになったことです。
ここまで来ると、8振動(4Hz)でも、1振動当たり30フレーム相当になるので、繰り返して(小数)周期を測定すれば十分な精度が出るのでは？と思い至りました。
また、視覚的に見ることができれば推定ではなく、直接振り角を測定することもできます。

旧来の歩度測定に音を使う理由は音は比較的データ量が少なくサンプリング周波数も上げやすいので、当時はそれがリーズナブルだったこととと予想されますが、現在の計算機パワーなら画像でも行けるのでは？と思って挑戦してみることにしました。

iPhone12で撮影した240fps動画をopenCVを使ったプログラムで良しなにしていろんなパラメーターが求まればいいな！が最終目標として、とりあえずテンワの回転角をフレームごとに求めることを目標としました。

使ったのは特徴量抽出とマッチングです。
これは、二つの画像に共通する特徴を見つけ出し、その対応を取ることで対応付けを行うものです。
これによって「テンワのスポーク」の位置を検出すればいいだろう…という目論見でした。



が、大失敗。
これは小さい画像に切り出したキー画像が対象の画像のどの部分に対応するか？という事を表した図で、キー画像が移動する＝テンワの回転を検出しようという試みでした。
対応する直線がまとまって、平行になっているほど一意に位置が決まっていることを示します。
見事に散らばってしまい、誤検出祭り、照明条件によって別物扱いになりスポークを見失うこと、2番車やブリッジの下にテンワのスポークが入り込むとそこでも見失うことも分かりました。

ここで、事前に切り出したキー画像を使って一意に位置を決めるのは、筋が悪いと考え方向転換することにしました。
キー画像を複数用意して無敵のディープラーニングする方法もありますが、準備が大変になるので、一旦保留。

入力データが動画なのを利用し、ひとつ前の画像と比較して「動いている位置と量を検出」と言うアプローチに切り替え、その結果が冒頭に掲載した動画です。
テンワが動くと赤いモヤモヤがテンワ外周やスポークの位置に表れています。
これは微小な領域が1つ前の画像からどのように動いたかを示すベクトル(フローベクトル)です。

処理自体はキー画像と同じく特徴量抽出とマッチングで、キーの代わりに1フレーム前の画像との対応を取っています。
また「カメラはほとんど動かない(画角はほぼ固定)」「フレーム間でテンワが動ける量は有限である」「テンワの各部の角移動量は等しい(はず)」という条件で、極端に大きい・小さいベクトルを枝狩りすることで誤検出を減らす狙いです(動画でまだゴミは出ていますが…)。

このフローベクトルを統計処理すれば「全体」としてのテンワがどのように動いているか求められることになります。
現時点で周期は割と正確に求められそうで、Witschi相当の測定はできるんじゃないかと。
ガンギ車の挙動が追えればビートエラーも求まるはずです。

他に分かったことは

• 特徴量はチラネジが稼いでいる(おそらくスムーステンワは難しい)
• チラネジ同士の区別がつかないことがある
• スムーステンワはスポークの検出が鍵？
• 180度反対側のチラネジとマッチングするのでベクトル長の制限は必須
• 2番車が覆い、チラネジが見えないと思った以上にマッチングできない
• 「全自動」よりは人間が介在した方が楽そう

特に最後は、Witschiの「全自動モード」相当を目指していましたが、振動数ぐらいは人間が入れてそれをもとにベクトル長制限などを自動計算する方法がよさそうという方向性です。
「テンワがどこにあっても自動検出」よりも、カメラで「ここにテンワを入れてくださいね」の方が楽ですし…

とりあえず、デテントで動くところまでできたら他のクロノメーターやスムーステンワでも試してみたいところです。
「巨人の肩」のおかげで非常に楽….。