こんにちは。

オープンソースを活用しながら、低コストでエッジ デバイスやさらに小さなIoT デバイスで使用できる小さな AI モデルを作成する、駐車場AI R&D チャレンジの３回目です。

作成したPOCには大きく３つの課題がありました。どのような対策を施し克服したのかご紹介します。

データ注釈の課題克服

まず、時間のかかるプロセスである、データ注釈（アノテーション）の課題解決です。

利用可能なオープンソースの注釈ツールはいくつかありますが、今回のPOCの目的「AI モデルのトレーニングに使用される”ビットマップ マスク イメージを生成する”」こと。この 要件に一致するものはありませんでしたので、私はPython で OpenCV API を使用し自ら注釈モデルを作成しました。

このアプリケーション製作は慣れていれば非常に簡単です。アプリケーションは 2 つのウィンドウで構成されています。 左側が入力画像、右側が出力マスクです。

ユーザーの作業は基本的に、

「車の位置にある左側の画像をクリック」する、

たったこれだけです。 これにより、右側のマスクが自動的に更新されます。

ちなみに同じ場所をもう一度クリックすると削除できます。キーコントロールで画像を保存、次の画像を選択、ポイント設定という流れでザクザクと設定を進められます。 (すべての画像が同じディレクトリにあると想定ですが）

簡単とはいえども、画像数が多いと当然ながら非常に時間がかかります。もっと楽をしたいので私は、手動で1,000 枚の画像に注釈を付けた後で、その注釈付きの画像を活用して注釈付けAIのトレーニングと AI モデルを作成しました。

このトレーニング済みの AI モデルを使用して、残りの画像に注釈を付け作業を簡略化できました。

そもそもの元画像にミスが多かったせいで、手動で手直しも発生しましたが、とはいえゼロから画像に注釈を付けるよりもはるかに高速で処理できました。

AIモデルの課題克服

次に、注釈モデルアプリの中のAIモデルですが、IoT環境で使うため、プログラムサイズの軽量化が必要です。

私の製作した注釈モデルアプリのAI モデル（上図中央）は以下の 2 つの部分で構成されています。

• 前工程：事前学習された Mobilenet バックボーン (モデルの一部のみ)
• 後工程：カスタム FCNN (完全畳み込みネットワーク)

学習データ セットが小さかったため、私はこのアプローチを採用しました。 本AI モデルでは、小さなカスタム FCNN セクションのみがトレーニングされますので効率的です。 前工程のMobilenet は事前にトレーニングされているため、画像内の多くの低レベルの特徴を検出できます。後工程の カスタム FCNN のほうは、前工程のMobilenetの検出後画像をさらにフィルタリングし、車のみが検出できるようにしました。この結果私の製作した AI モデルのプログラムサイズは、float32 パラメーターでは約 6 メガバイトでしたが、(パフォーマンスは 1 パーセント (0.3%) ほど低下したものの)量子化 (int8) によって 4 分の 1 (2.5 メガバイト)にまで縮小できました。

データの増強とデータセットの制限の克服

次に、データセットの問題です。

前回２回目のブログで私は、駐車場画像のデータセットに偏りがあると、駐車場監視AIモデルの学習がうまく進まないこと、駐車場においては主に７つのデータセットの課題があるとお伝えしました。

そこで私は駐車場データの増強やデータセットの制限を克服するために、以下のようなアプローチを試みました。

1. データサンプリング

データ分析において、データセットの中から有意な情報を得るため、データの一部を抽出することをサンプリングと言います。また、ヒストグラムの棒のことを英語ではbin（ビン）と言いますが、ある抽出データがどのビンに属するのかの定義を決めていきます。

まず、駐車場の画像データを、ビン(bin）に配置します。

駐車場の場合は駐車台数がキーになります。たとえば、車が 0 台の画像用のビンが 1 つ、車が 1 台しかない画像用のビンが 1 つなどと決めていきます。駐車場AIデータのトレーニング中は、これらのビンに配置した画像をランダムに選択しAIに答えさせていきます。

さて、昼と夕方では明るさが違うので、AIにより賢くなってもらうには、これらの状態でのサンプリングも必要になります。そこで私はビンをさらに 駐車台数 ✖ 画像の明るさレベル (平均)、明るい、中間、暗いへと分けました。
こうして（影や車の色の違い <明るい白から黒まで>も存在するため、これだけですべての問題が解決するわけではありませんが）様々な明るさ✖台数の駐車場データを設けることで、トレーニング データをより均等に分散させて、トレーニング中のバイアスを減らすことがAIにより賢くなってもらうために必要です。

2. ランダム化によるデータ増強

特定の駐車台数、特定の明るさのデータが十分にない区間も存在します。こうしたトレーニングデータのバイアスを補い均質化する技術としてランダムパッチがあります。

画像の一部分にランダムなパッチを当てて、ふたをします。こうすると、画像内の車の数が変化しますので、違う台数条件のデータを学習させることができます。

ランダム化には他にも方法がありますが、今回のデータの課題の特性を見ながら、ランダムな明るさの変化と、ランダムなコントラスト変更 (ぼかし、シャープ化)も必要と感じ実施しました。

3. ミラーリング

データ増強の方法にミラーリングというものがあります。画像をランダムな角度に水平方向に反転させ、鏡映しのような画像をつくるのですが、私は今回これも用いてみました。

結果

AIモデルのトレーニングには、過学習(オーバーフィッティング)を減らし、バランスの良い学習でAI モデルの堅牢性を向上させる必要がありますが、以上のアプローチの実施後、現時点のデータセットでのAIモデルの認識パフォーマンスは 99% 以上をマークすることができました。

今後の展開

今回のAI モデルは、FCNN (完全な畳み込みネットワーク) と組み合わせた MobileNet バックボーンを使用しましたが、プログラムサイズがまだかなり大きくて、約 2.5 メガバイトでした。 （ただしARM M7 Cortex で MobileNet モデルを実行することは可能です）

プログラムサイズに関しては、Mobilenet バックボーンの削除＋完全にカスタム化された AI モデルの作成を行うこと、そしてNeural Architecture Search(NAS)を使ってニューラルネットワークの構造自体を最適化すれば1 メガバイト未満のモデルも構築できると想定しています。

それより重い課題は主な課題はトレーニング データです。 現在のデータセットはおそらく小さすぎて、AI モデルをゼロからトレーニングできません。費用と時間がそれなりにかけて、より多くのデータを収集していく方法は当然ありますが、予算や時間が限られる研究者も大勢いると思います。

だからこそ、私はより高度な AI モデルを使用してトレーニングデータを合成する方法で解決できる可能性に期待しています。大規模なジェネレーティブ AI モデルがトレーニング用データを合成し、その合成データを、今度はIoT やエッジ デバイスで動作する AI モデルのトレーニングに使用するプロセスです。

”合成データは AI データの未来である”

大きなAIがエッジAIのトレーニングをサポートすることが当たり前の世界に1歩でも近づけていきたい。私はこのように強く思っています。

次は、他のエッジAI開発事例についても、お話しできればと思います。

エッジ デバイスやさらに小さなIoT デバイスで使用できる小さな AI モデルを作成する、駐車場AI R&D チャレンジの２回目です。オープンソースを活用しながら低コストでの開発をしています。

今回はそうしたエッヂAI開発でありがちな、乗り越えなければならない課題をお話します。

AI モデルのサイズとパフォーマンス

オープンソースのオブジェクト検出 AI モデルはたくさんあります。 なかでも有名なのはYolo(You only look once) です。 こうしたオープンソースの検出モデルは、多くの研究データ セットで高いスコアを達成する素晴らしいものです。

ただ、小さなオブジェクトやオブジェクトが密集しているケースなどでは、検出パフォーマンスが低下する傾向があります。加えて、CPUを集中的に使用し、GPU をサポートしないようなエッジ デバイスやIoTデバイスでは、画像のフレーム レートは遅くなるので、さらにパフォーマンスに影響を与えます。

Yoloモデルのサイズは、数百メガバイトから 5 ～ 10 メガバイトまでさまざまあるのですが、 最適化されたモデルが小さいほど、パフォーマンスが低下しますので、今回のエッジAI開発のような、メモリの小さな環境ではかなり厳しい想定はありました。

とはいえ、今回の目的はそうした環境下でも「画像内の 1 つ以上のオブジェクトタイプを検出できる AI モデルを作成すること」です。

もしCPU のみのエッジ デバイスで 5 以上のフレーム レートで機能するAIモデルが実現できれば、さらに難度の高いAI/IoT デバイスでもAIモデルが実行できる可能性がありますのでやる価値はあります。

私は今回のAI モデルのサイズの目標を、エッジ デバイスの場合は 2 Mb 以下、さらに小さなAI/IoT デバイスの場合は 400kB 以下と置いて開発をすすめました。

データセットの注釈（アノテーション）

AIモデルの実行環境と同じくらい重要なのが、データセットの注釈（アノテーション）です。

有料のアノテーション済の学習データ（教師データ）は便利ですがご存じの通り高価ですので、今回は無料で扱えるKaggleのデータベースを使うことにしました。

Kaggleのデータセットのデータは4000ほどありましたが、アノテーションが付いておりません。

付けなければなりませんが、人によるアノテーションはお察しの通り途方もない作業で、開発者が自ら行うのは無理があります。そこで、前述の著名な物体検出 AI モデルの「 Yolo」 で車を認識させアノテーションを自動設定しようと試みました。

　ところが、これがうまくいかないのです。

私の感覚ですと、どうもこの「Yolo」はおおまかに１画像に移っている車の数の20%～40%程度しか車を認識しませんでした。

　なぜか。

どうやら映像内で並んでいる車のサイズが小さすぎて、前述した「小さなオブジェクトやオブジェクトが密集しているケース」に相当してしまいYoloが認識できないのが原因のようでした。

結論として今回Yoloが使えないことが分かったので、もう自作しかないと思った私は、映像内の車の位置を記録するアプリケーションをカスタム製作することにしました。

詳細はまた機会があればご紹介しますが、このアプリがうまく各車の位置をアノテーション記録してくれたので、AIモデル学習、その後のAIモデルのイメージ マスク出力までできるようになりました。

データセットのバランス

データ セットの課題はもう１つあります。それはデータセットのバランスです。

データセットのバランスとは、極端に似たデータばっかりセット内に存在するとか、逆にあまり存在しないデータがあるといった不均衡、不均一なデータであることで、そのままAIが学習するとAIモデルの性能評価に偏りが生じる可能性があります。

今回の駐車場のデータセットでもいろいろとありましたが、まとめるとこんな感じです。

1. 気象条件による明るさの変動
2. 影による画像の明るさの変化
3. 明るい日差しの中で白い車
4. 暗い場所の黒い車
5. 植物の問題
6. データセット大きな偏り
7. 一部の車種の形状

以下簡単にご説明いたします。

1.気象条件による明るさの変動

これは、霧がかかった冬の日から、明るい夏の日までさまざまな状態があります。こうした季節や気象の変化で駐車場の映像の明るさも刻々と変化します。この変動はAIモデル学習に影響を与えます。

2.影による画像の明るさの変化

また、１日の時間帯の条件も難しい時があります。朝から夕方までの太陽の位置で周囲の明るさ自体が変わります。また特に朝夕などで太陽の位置が傾いているときの映像データですと、出来る影が車の周囲に発生をして、これが邪魔をしてAIモデルが車を見分けにくくなることがあります。

3.明るい日差しの中で白い車

たとえば、明るい朝の日差しの中に白い車があるような状況です。こうなると周囲の明るさに車が埋没するので、カメラ センサーが飽和状態になり、車の特徴が見分けにくくなります。

4.暗い場所の黒い車

これは前述の逆パターンで、薄暗くなった夕方になって駐車場へやってきた黒い車は、車とその周囲の明るさが似ていてAIが認識しにくい、という問題を引き起こします。

5.樹木の問題

これもよく問題になります。この駐車場データの右下にある車は、その前にある木々の枝が茂っており、部分的に遮られています。落葉樹ですと冬には葉がありませんが、夏には葉がもっと茂るので、認識率もさらに変わってくることになります。

6.データセットの大きな偏り

この重要度は前述しましたが、駐車場の映像でのデータセットの偏りとは、なんだかわかりますか？

実は「駐車台数」です。

実際に学習用に入手できた駐車場画像は0～3台ほどが停車しているものが大半で、Kaggleでは4台～というものがほとんどなかったのです。ですので、このまま学習をすすめると、学習に大きな偏りが生じる、という問題を発生させます。

7.一部の車種の形状

こちらも前述いたしましたが、車の形状が大きく違う場合、認識率が落ちることがあります。たとえば、RVやセダンなどが多い国の映像を中心に学習していると、たまに停めに来る大型トラックなどを車と認識しない、ということが起きます。

以上、オープンソースを活用しながら低コストでエッジAI開発をするときの、AI モデルのサイズとパフォーマンス、そして駐車場データセットの課題についてまとめてみました。

いかがでしょうか。皆様の開発の参考になると嬉しいです。

次回は、これらの課題克服のポイントなどについてお伝えしようと思います。

エッジAIとは？

ディー・クルーでは、エッジAI（IoT環境で動く人工知能）の研究を行っています。

IoTデバイスでは通信負荷が高まるとデータ転送に遅延が生じるなど、問題が起き始めます。

そこで、クラウド側に過度に依存せず、ローカル環境＝エッジ側でセンシングー演算ーAI認識まで完結させて、レスポンス性能と通信負荷の低減を両立した環境にやさしいシステムを実現する。

これをめざしてディークルーで現在研究しているのが、AI開発「エッジAI」です。

すなわち、AIを組み込んだIoTデバイスやEDGEデバイスに AI オンチップ アクセラレータを組込むという構想です。

この構想のもと、私は電力負荷の高いGPU を使用せずに低電力 MCU で動作する軽量の AI システムを作りたいと思っていまして、今研究を進めています。

駐車場の空き監視AIを作ってみたきっかけ

今日は、そのなかでも、映像認識のエッジAI研究プロジェクトの１つ「駐車場監視AI」をご紹介します。

映像認識AIは例えば、今映像で映っているオブジェクト(対象物)が、人なら人、コップならコップといった具合に、「どこに、それがあるのか（ないのか）」を人工知能（AI)にリアルタイムに検出させる技術を用いて課題を解決する技術です。

当社はIoTシステムの開発案件を多く手掛けており、駐車場に関したシステムも開発していました。駐車場に止める「車」はAIモデルが認識しやすいオブジェクト（対象物）であります。

そこで、駐車場に設置したカメラから、駐車スペースの空きが分かる便利になると思い付き、AIによる駐車場空き監視システムを作ってみたので、少しご紹介したいと思います。

今回のAIモデルの概要

このプロジェクトのAIモデルについての概要を示します。

1. 図1 入力イメージからのオブジェクト検出にFCNN（完全な畳み込みネットワーク）を用います。
2. AIモデルは、図2 出力マスクを生成し、オブジェクトのおおよその位置を示します。
3. AIモデルは、この出力マスクを使いオブジェクトの位置を特定、数えることができます。
4. AI モデルは、Python向けの機械学習ライブラリである、Pytorch フレームワークを使用します。
5. AI モデルは、Raspberry PI 4 上で 4 ～ 8 Hz のフレーム レートで実行されます。
6. 学習用のデータセットソースは 、　Parking Lot Dataset | Kaggle　を使用しています。

AIモデルの動作について

作成したAIモデルの動作についてはYoutubeの動画にしましたので、ぜひご覧いただければと思います。

次に、この映像で何が起きているかということをご説明します。

• AIモデルが、映像上で「車」と認識している位置に、白い四角を打っています。
• 動画の上部（UPPER）駐車スペースと、下部（LOWER）駐車スペースの「Parked」（満）と「FREE」（空）数で、AIが認識した数を数えて、それぞれの値を変えています。
• AIが認識した駐車した車の数に合わせて、白い四角の数も変わり、これらの数字も刻々と変わっていくことがお分かりいただけるかと思います。

なお、映像がカクカクしているなとお感じかもしれません。これは、IoTならではの軽量システムでのパフォーマンスを維持するために、意図的にフレームレートを落としているからです。システム環境によっては、フレームレートを高め、AIモデルをそこに最適化することもできます。

次回は、このAIモデル作成時の課題や工夫したポイントなどについてお伝えしようと思います。