SMNL開発中止について

開発記録として残しておきます。

弊社でスマホアプリ『SpeedMeterNoLimits』（略称SMNL）の開発を進めていましたが、想定したビジネスモデルへを満足する手法が実現できなかったため、2024年12月末日をもっていったん中止します。（開発時間約160時間）

１）アプリの目標

スマホのGPS機能を利用すれば位置情報を取得できます。これを利用し自分の移動速度を調査することは可能です。また、スマホカメラの前方画像撮影画像から道路速度規制情報を取得することは可能です。この2点を合わせて、データベースに頼らないオフライン型のスピードメータ及び速度超過警戒アプリを作成しようと考えました。

データベースを利用した商用アプリは既にありますが、月額課金制なので敷居が高く、無課金で利用できるアプリであれば需要があると考えました。

製品化アプリはUnityを使用することとして考えているが、開発のスピードアップのために一部Pythonで基礎テストを実施した。いずれもOpenCVをベースにしていれば移植も簡単だろうという読みでした。

２）スピード表示部

スピード測定はGPSの位置情報から計算しました。単純に移動距離÷時間＝速度です。ここで問題なのがGPS位置情報制度です。通常3mx2程度の誤差が発生しますので、秒速6m/s≒時速20km/h程度の誤差は生じます。実際にフィールドテストではこの程度でした。これは自動車の移動速度を対象とした場合、無視できる大きさではありませんのでこのノイズをキャンセルしなければなりません。このため以下の方法を試しました

①移動距離に対するスムージング②速度に対するスムージング③速度に対するガウシアンフィルタ④速度に対する3次元B-Spline。結論としては④が一番スパイクノイズの除去が優れており、これを採用することとしました。スマホの電池消耗量削減を考えGPS位置情報取得は1秒間隔に設定していますので、直近5秒の位置情報及びこれから求まる4点の速度場情報をもとに端点の3重化を行い関数を作成。現時点から2秒前の速度を再計算し利用するようにしました。これによりスパイクノイズの除去は当然のことながらスムーズな速度変動を計算表示できるようになりました。バイクでの利用を想定した場合はサンプリング周期をもっと短くしたほうが良いかもしれません。

３）速度標識識別部

上述の通り、速度標識識別部は多様なアプローチが考えられます。一番確実なのは有料データベースにアクセスし、今の位置情報をもとに制限速度を入手する方法です。しかし、無料で行うのがSMNLの目標だったためこのアプローチはせず、いろいろ試しました

３）－１　ピラミッド式テンプレートマッチング

よくあるテンプレートマッチング。ただし、スケールが異なる場合でも対応できるように何段階かテンプレート側の大きさを変化しスキャニングを実施する。うまくいけばマッチングが早く見つかるが、重層的にスキャニングを行う必要があり、リアルタイム検出を考えた場合にはあまりよくない。また、検出確度もあまり高くない。

３）－２　特徴点テンプレートマッチング

ピラミッド式テンプレートマッチングの弱点を克服するために導入。ただし特徴点の検出が全くうまくいていなかったため中止。

３）－３　領域抽出後　TensorFlow-OCR

速度標識はすべて赤い円で囲まれていることの着目し、この領域のみを切り取り、大きさを正規化してマッチングのリソースを劇的に削減する方法を採用。以降この方法を併用することがメインとなる。また、速度標識はすべて数字2桁または3桁で表示されるため、TensorFlowを使いOCRを実施。この際ホワイトリストを作り数字だけを強制認識させる方法を使用。そこそこの認識率はあったがAndroidでの動作に不具合があったため中止。Unityでなければもっとうまくいったかもしれません。

３）－３　領域抽出後テンプレートマッチング

テンプレート画像と領域抽出後画像が正規化されているためテンプレート枚数が多少多くても時間はそんなにかからないはずなので、機械学習並みに角度成分を加えて水増しテンプレートを用意し、2値化データで比較実施。また、円の外周部は比較対象にならないように黒でマスキング。これにより通常文字における認識率は８０％程度あり、なかなか使えるロジックになった。高速道との点灯文字に関してはもっとカメラ条件と前処理条件、手納レート作成を詰めなければ満足いく結果が得られなさそう。

３）－４　領域抽出後特徴点テンプレートマッチング

AkazeおよびSift検出子を用いて特徴点検出を行いましたが、いずれも満足する特徴点を抽出できていませんでした。これにより常に満点の評価関数が帰ってきてしまい、まともな動作が得られませんでした。入力画像にガウシアンフィルタをかけるなどすればもう少しまともになる可能性もありましたが、点で書いた数字に関しては全く問題になりません。このため、このアプローチはダメでしょう。

４）試していないこと

①機械学習…数字の検出画面となるためあまりこの用途に向かないと考える。TensorFlow-liteなど使える道具は多いが、学習コストもかかるしマシンパワーも足りない。何よりfashinでスヌーピーのTシャツとウッドストックのTシャツを見分けなければならない程度に難しそうなので機械学習では無理な気がする。

②OpenCVのAlphabet認識での数字認識…tensorFlowのホワイトリスト使用方法は簡単に見つかったがOpenCVのそれに関しては調べ切れていない。一次文献に当たるしかないが調査の価値あり。

５）まとめ

それぞれのテスト要件も甘く煮詰め切っていませんが、今のリソースでこれ以上やっても明るい未来が見えてきそうにありません。また、WEBカメラでのテストで痛感しましたが、画素数や画角、ディストーションが大きく影響しますので、使用するAndroid端末も選ばないといけないことになるでしょう。そんな大量の端末は持っていないので、テストはおのずと不十分になります。テンプレートを大量に用意しても動作が遅くなるのとトレードオフなので問題です。多くのユーザー様に満足していただけるアプリを作るのは不可能でしょう。自動車メーカーのように車載標準カメラにしてしまえばゴリゴリにチューンできるし学習データもたくさん取れるのに。非常に歯がゆいです。

勉強にはなりましたがいったん開発を終了いたします。