ikalog: data collector for splatoon and machine learning (jan 2017 @ softbank)
TRANSCRIPT
本スライド中に登場するスプラトゥーン関連画像は任天堂株式会社の著作物です。
2004|
2011
2011|
2014
2014|
SEサービス プリセールス @So+wareResearchAssociates,Inc.システム構築、客先のシステム運用、提案でキャリアをスタート→プリセールス〜PMを担当するインフラエンジニア
システムアーキテクト @TrigenceSemiconductor,Inc.、ほかエンベデッド開発支援、ITシステム管理、機械学習支援まで多岐に対応
セールスエンジニア@Fusion-io,Inc.高速半導体ストレージ ioDrive/ioMemoryシリーズのSEとして活動
–
–
–
–
–
–
様々なステージとルール
• １６のステージ、４つのルール• 勝利に向けチームで立ち向かう
多様な楽しみ方
• 90以上のブキから好きなものを選んでプレイ
WiiU用ゲーム「スプラトゥーン」支援ソフト
– HDMIキャプチャを介して情報を自動取得
– 数値・文字列データとして認識
– お好みの方法で蓄積、出力
NintendoWiiU＆ スプラトゥーン
データ化{“kills”:5,“deaths”:1}
IkaLog
外部ツールへ出力(棒読みちゃん等)
出力例
HDMIキャプチャデバイス
IkaLog実行用PC
録画ソフト 自動制御
AmaRecTV
カラーLED連動
Fluentd転送
スプラトゥーン戦績記録SNS
CSV/JSONファイル保存 スクリーンショット保存
SNS投稿
IkaLog
• IkaLogユーザのひとり @fetus_hina さんが開発、
運営する Web サイト
• IkaLog からのプレイデータを受け取り、
表示・集計する
• IkaLogからの投稿を分析し
統計情報、トレンドを表示
17https://stat.ink/
自分が倒されて行動不能だった時間
イカ（味方／敵 計８匹）の生死状況
チームのスペシャル発動、キル／デス
自分の塗り面積
https://stat.ink/
https://stat.ink/
ナワバリバトル – 互いの干渉が少ない
ガチエリア – “相手を倒しつつ生存”がカギ
ガチホコ – 全体的に乱戦になりやすい
ガチヤグラ – 全体的に乱戦になりやすい
https://stat.ink/
.96ガロンデコアップデートをきっかけにユーザー数が激減
ロングブラスターカスタム夏以降、人気を博しているブキのひとつ
https://stat.ink/
データソースh^ps://stat.ink/en`re/user
【ピーク】24時間あたり370ユーザ、約15,000ゲーム
2016年11月時点にて24時間あたり 平均100ユーザ超が利用、平均2500ゲームを処理
最後の“フェス“（ゲーム内イベント）
23
勝率０％
勝率１００％
• 2014年INTEROPでの”Chainer”デモがきっかけ
– 深層学習のプレゼンテーションみて「凄いな」と思った
– “何か面白いソフトウェアを作りたいな”
– ちょうどスプラトゥーンの発売直後だった
• 未経験からのチャレンジ
– OpenCV経験 3時間ぐらい
– 機械学習／ディープライーニング経験 なし
ここまでするなら
自動化できるツールを作ろう！
ソース映像 マスク画像 加算画像
+==
正しいマスクを加算すると画像が真っ白になる
違うマスクを加算すると画像が真っ白にならない
30
31
32
33
34
35
37
• ゲーム中で使われているフォントは２種類
– 画面上に現れる数字フォントは１種類
– フォントが判っているのだから、認識できるはず
• 試行錯誤の後、既存OCRエンジンの利用は断念
– 機械学習ベースの認識エンジンを実装
•
•
–
–
–
–
–
文字として認識されないことも
●●●
●
■
■
■■
?▲
▲
▲
▲
?
?
?
?
とてもシンプルな機械学習標本 の傍にあるサンプルがどれかで分類する。K=1の場合は最寄りのサンプルがあるクラスに分類される。K=3の場合は近くに3つのサンプルがあるクラスに分類される。
• GitHub にソースあり
– https://github.com/hasegaw/opencv_knn_example/
• 三つのパターン ○ △ □ で画像を生成し、
kNNで学習する
• ランダムに ○ △ □ から画像を生成し、その画像
の種類を判定する
– KNN を用いてそれに近い画像を見つけ出す
– 見つけた画像の種類から、問題図形の種類を特定
問題図形をランダムに生成
K近傍法を用いて、学習済みの図形から、もっとも近い図形を調べる
仕分ける○ △ □
○学習済み図形
○ △ □
１）画面上の数字部分（位置固定）を切り抜き
２）縦・横のヒストグラムを生成し各文字の位置を特定
３）文字を検出用サンプルのサイズ（等幅）にリサイズ、
二値化
４）KNNにより既知の検出用サンプルと照らし合わせて
認識する
• 基本は数字の認識と一緒
• 認識率はそれほど高くないが、認識回数で精度を確保
– IkaLogは現在毎秒10フレームほど解析している
– 下記例では、死因のメッセージ合計49fを解析し、
最多頻度は96gal_deco (18f, 36%) だった → 結果的に正解
votes={'supershot':6, 'carbon_deco':1, 'bucketslosher':1, 'octoshooter_replica':1,'splashshield':1, 'sshooter_collabo':5, 'hotblaster':2, 'pablo':1, 'nzap89':6,'sharp_neo':3, 'hotblaster_custom':2, '96gal_deco':18, '52gal':1, 'hokusai':1}
•
•
•
黒いブレット明るいブレット
背景色
黒いブレット
明るいブレット
背景色
• –
–
• –
–
• –
–
57
スプラトゥーンのブキ ５９種類（スライド作成当時）
•
•
•
•
他の装備品が被っている 保護色（まだマシ） 保護色（マジつらい）
（まだバグがあった頃のバージョンの表示なので色がずれているけども）こんなかんじで特徴量を抽出していた
入力画像 ラプラシアンフィルタ適用
グレースケール K近傍法によるクラス分類
Thanks@itooon
sschooter_collabo
スプラシューターコラボ
特徴画像
63
長所
– 色の違いに鈍感
– 画像の「形」でざっくり認識
短所
– 解像度の違いに弱い
– 似た形の画像を正しく分類できない
スクリーンでは視認しにくいが、ユーザーが様々な解像度の画像を送ってくる「現実」
67
オリジナルのブキ(longblaster)
カスタムバージョン(longblaster_custom)
更に追加（Apr2016）(longblaster_necro)
出力される特徴量に被りが発生し、特徴量算出アルゴリズムの見直しが必要に
longblaster_necro
longblaster_custom
longblaster
IkaLog内部で使用する特徴量を主成分分析(PCA)で2次元空間に
投影したもの
出力される特徴量に被りが発生し、特徴量算出アルゴリズムの見直しが必要に
ゲーム終了時に表示される別の画面画面上に表示される「ギアパワー」画像を分類するKNNの問題点・「メイン」ギアパワーと「サブ」ギアパワーで 画像の大きさが異なる・ユーザー環境によって解像度が異なる・ブキ画像同様、状況によって特徴量が変化→ 「画像サイズの変化に強い分類器がほしい」
• • ❌ ⭕
–
–
– •
•
（本スライド中の画像の一部はイメージであり実際のものとは異なります。）
オブジェクトストレージ
作業用インスタンス
onIaaS
１年以上のデータを蓄積総データ量 4TB以上
IkaLogユーザ stat.ink
hasegaw
• 機械学習／深層学習の精度は前処理の精度に影響を受ける
• 画像のズレ／ゆがみ対策（自動補正）を実装し、対策
テンプレートマッチング、最小二乗法を用いて最適候補を選定
アスペクト比が壊れている なぜか画像がズレているリファレンス
分類に使用する画像
Thanks@itoooon
長所
– ニューラルネットワークにより認識率が大幅に向上
短所
– データが大きくなる（例：100MB~400MB）
– Windows版に組み込みしづらい
PythonスクリプトをEXE化する「Py2EXE」と
ディープラーニングフレームワークは相性が悪い
– 処理に時間がかかる
ゲーム終了時のスクリーンショットstat.inkから投稿データを深夜バッチで受け取り約4000枚/日
認識対象となるブキ画像約24000サンプル/日
ChainerによるDNNで自動的に分類
スクリーンショットからサンプルを生成
ブキ精度向上にあたり注目したいサンプル（絞り込み済）
実際に IkaLogが利用するブキ認識モデルの強化、テストに利用
– 入力値： RGBもしくはHSVの色情報(47*45*3=6,345units)
– 出力値： 各クラスの出力値（91units,So+maxを適用する）
– 使用する結合：全結合のみを使用（理由は後述）
– 目 的：特徴量の自動生成
• 今回の用途であれば、深層学習で特徴量を自動的に見つけ出せるはず
• 各ブキの背景色の重みが自動的ゼロに調整されれば、背景色への考慮
も不要
– 目標性能値
• 目標性能値:91クラスのマルチクラス分類が350ms未満（画面１枚あたり3秒以内）
• stat.inkの投稿データに対して99.99%の精度
0
1
2
3
..
..
n
0
1
2
3
…
89
90
InputLayer OutputLayerHiddenLayer
52gal
52gal_deco
96gal
96gal_deco
…
sschooter_wasabi
wakaba
80
• AzureML上でアルゴリズムの事前検証
– 小さなデータセットを使用し分類器を作成
– 入力層:ピクセル情報（をPCAにかけたもの）
– 隠れ層:1層、150ユニット（暫定）
– 出力層:各クラス（のはず）
• この方針でトレーニングすれば、精度が高い分類器を得られるだろうと判断
– 特に何も考えなくても９８％以上の精度が得られた
– 各種ボケ画像も、おおよそ問題なく判定できた
83
• AzureMLで得た結果をベースに、IkaLogに組み込む
モデルを作成する
– stat.inkに投稿された90万点のブキ画像を教師データとして用意
– フレームワーク「Chainer」を使用
– GPUの恩恵も受けられる
• 学習したモデルの配布用フォーマット
– float32→float16に変換
– 配布するモデルファイルのサイズが半減
CPU GPU #ofjobs
Throughput(images/s)
GPUTime/epoch(s)
RelaJveperf.
(virtual)
Corei7-4790S定格3.2GHz
使用せず 1 3,928 234.5s 1X
Corei7-4790S定格3.2GHz
GeForceGTX760
1 10,371 39.2s 5.9X
Corei7-4790S定格3.2GHz
GeForceGTX760
4 (^l)15,988 25.8s(103/4)
9.08X
Corei7-4790S定格3.2GHz
GeForceGTX1080
4 (^l)30,320 6.25s(25.0s/4) 37.52X
2XE5-2630Lv3定格 1.80GHz
TeslaP100
4 (^l)65,811 2.5s(10.3/4)
93.8X
SpecialThanksto
※スループットとEpochあたりのGPU処理時間は測定基準が異なるため単純比較できません。※マルチジョブ実行時は類似ジョブが並列動作しているためGPU実行総時間をジョブ数で割っています。
自宅のLinuxBox
K近傍法 既存ImageNet 新ニューラルネット
認識効率 一部ユーザでは低い
99.99+%
99.99+%
モデルサイズ 20MB（現時点） 400MB(AlexNet)100MB(GoogleNet)
14MB(Float32)7MB(Float16)
分類にかかる時間@IvyBridge2GHz
とても高速 ~300ms ~20ms
• 出来合いのImageNetよりも高速、より小さなモデルデータ（配布物）
• 従来のIkaLogよりも高い認識精度を実現
SpecialThanksto
• ニューラルネットの順伝播処理を新規実装
– 既存のフレームワークは組み込まない
（Windowsユーザ対策）
– 高度な機能を実装すると面倒なため、最低限の
機能を絞り込んで実装（LinearFunc`on,ReLU）h^ps://github.com/hasegaw/IkaLog/commit/3238b67749334a3c4254aa6f25c005f83e210895
– IvyBridge2.0GHzで20ms以下、PYNQ-Z1(Cortex-A9650MHz)で200ms以下で順伝播可能
88
この書籍の最初の１００ページ分がIkaLogのニューラルネットの実装
そのものです。
• ニューラルネットを他の用途にも適用
– ブキ分類器のほか、ギアパワー分類器を作る（優先度 高）
– ガチホコのタッチダウン分類器を作る
– 戦況評価関数にRNNが使えるのではないか
• 本当に必要なデータセットの選定
– 21GBのデータセットには大量の重複データが含まれている
– 重複データをうまく取り除くと学習時間、作業効率、精度にメリットがあると考える
– PCA-basedanomalydetec`onが使えそう
• IkaLogでは、複数の機械学習アプローチを適用している
– リアルタイム処理では、おもにK近傍法(KNN)を利用
– 入力画像にロバストな分類器を作るため、深層学習を利用
• 特徴量の自動抽出、何十万の画像から自動的な学習
• IkaLogとディープラーニング
– Windowsアプリケーションにそのまま組み込めるような深層学習のフレームワークは限られている
– しかし、関数や機能を限定すれば、比較的容易に実装可能
– 学習には既存の深層学習フレームワークやGPUを活用
HDMIキャプチャデバイス
IkaLog実行用PC
FPGAボード
Processor:Dual-CoreARMCortex-A9FPGA:1.3MreconfigurablegatesMemory:512MBDDR3/FLASHStorage:MicroSDcardslotVideo:HDMIInandHDMIOutAudio:Micin,LineOutNetwork:10/100/1000EthernetExpansion:USBHostconnectedto
ARMPSInterfaces:1xArduinoHeader,2xPmod(49GPIO)GPIO:16GPIO(65intotalwithArduinoandPmods)OtherI/O:6xUserLEDs,4xPushbu^ons,2xSwitchesDimensions:3.44”x4.81”
(87mmx122mm)
IntelPCの６倍の時間がかかる！！
•
–
–
•
•
• –
–
•
•
•
•
最適化の効果
•
pi@raspberrypi:~/ikalog/IkaLog $ PYTHONPATH=./lib/ python3 bench_1024mat.pyencode 0.000015974s logical_and_popcnt 0.094928265s total 0.094944239s�
<class 'ikalog.utils.ikamatcher2.reference.Numpy_uint8'>
encode 0.000014544s logical_and_popcnt 0.021027803s total 0.021042347s<class 'ikalog.utils.ikamatcher2.reference.Numpy_uint8_fast'>
encode 0.005746365s logical_and_popcnt 0.002564192s total 0.008310556s<class 'ikalog.utils.ikamatcher2.arm_neon.NEON'>
• –
– •
• –
–
ARMCoreHDMIRX
DRAM
RGB(1280,720,3)
HSV(1280,720,3)
Gray(1280,720,1) IkaLog実行時間の
10.4%が色変換ARMNEON命令使用
ARMCoreHDMIRX
ColorConverter
DRAM
RGB(1280,720,3)
HSV(1280,720,3)
Gray(1280,720,1) IkaLogは色変換済みの
データ参照のみにするキャプチャ時にPL部で色変換を済ませておきDRAMに書き込んでおく
らぴす(2000-2014)
©07strikers