「遅延検証の方法」の編集履歴（バックアップ）一覧はこちら

「遅延検証の方法」(2019/08/16 (金) 03:42:52) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

このページでは、[[コントローラー遅延検証]]の測定方法の詳細を解説する。
#contents(,fromhere=true,level=3)
----
**測定方法の概要
コントローラー基板に電子回路を接続し、Aボタンを入力すると同時にLEDが点灯するように設計する。
ハイスピードカメラでLEDとゲーミングモニターを撮影し、LEDが光ってから画面に入力が反映されるまでのコマ数を数える。
この計測で測定されるのは、
-''コントローラーの処理時間''
-ゲーム内部の処理時間
-モニター内部の処理時間
-モニター液晶パネルの応答時間
の合計である。
計測回数は100回以上を目安とし、それらの平均を取って測定結果とする。

データ解析には、手動・自動の2種類の方法がある。
実験の設計などで異なる部分については別々に解説する。


**使った機材
-各種コントローラー
-[[I-O DATA EX-LDGC251TB>>https://www.iodata.jp/product/lcd/wide/ex-ldgc251tb/]]
--応答速度&tt(){5ms}（オーバードライブ2+GtG時 &tt(){0.8ms}）、モニター内部遅延&tt(){0.53ms}。
--forとSPの比較のみ、[[ViewSonic VX2363SMHL>>https://www.viewsonic.com/jp/products/lcd/VX2363SMHL.php]]を使った&footnote(モニターを買い換える前に検証したため)。
-[[サンハヤト 小型ブレッドボードパーツセット SBS-203>>https://www.sunhayato.co.jp/material2/index.php/item?cell003=%E6%95%99%E8%82%B2%E5%AE%9F%E7%BF%92%E3%83%BB%E9%9B%BB%E5%AD%90%E5%B7%A5%E4%BD%9C%E8%A3%BD%E5%93%81&cell004=%E3%83%96%E3%83%AC%E3%83%83%E3%83%89%E3%83%9C%E3%83%BC%E3%83%89%E3%82%AA%E3%83%97%E3%82%B7%E3%83%A7%E3%83%B3&name=%E5%B0%8F%E5%9E%8B%E3%83%96%E3%83%AC%E3%83%83%E3%83%89%E3%83%9C%E3%83%BC%E3%83%89%E3%83%91%E3%83%BC%E3%83%84%E3%82%BB%E3%83%83%E3%83%88+%E3%82%BF%E3%82%A4%E3%83%9E%E3%83%BCIC%E3%80%8C555%E3%80%8D%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9F%E9%9B%BB%E5%AD%90%E5%B7%A5%E4%BD%9C%E3%82%BB%E3%83%83%E3%83%88&id=803&label=1]]
-導線
-白色LED
-[[OLYMPUS Stylus XZ-10>>https://www.olympus-imaging.jp/product/compact/xz10/]]（最大240fps）/[[CASIO EX-ZR400>>http://arch.casio.jp/dc/products/ex_zr400/]]（最大1000fps）


**回路設計
****共通
コントローラー基板の各ボタンに対応する位置には、分断された電極がある。
ボタンが押下されて導電性ゴムが電極に接触すると、通電してボタンが入力されたと処理される。
この検証では2つの電極にそれぞれ導線を接着し、導線を通して通電させることでボタン入力する。

LEDとコントローラー基板を並列に繋いだ電気回路を設計する。
電気回路がONになると、LEDとコントローラー基板が同時に通電する。
コントローラー以外の回路の応答時間は考慮しない。
&image(GC_connect.jpg, width=300,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/705/GC_connect.jpg, inline)&image(swpro_connect.jpg, width=300,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/704/swpro_connect.jpg, inline)
&small(){↑ GCコン・Switchプロコンの接続。導線はテープ+洗濯バサミで固定。導線の正極・負極の向きも適切に配線する必要がある。}

****回路：手動解析用
#image(circuit.png,width=360,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/668/circuit.png)
コントローラー側の抵抗R2はコントローラーに応じて調整が必要。
適切な抵抗を使わないと、スイッチを入れてもボタンが反応しなかったり、全く別のボタンが押された扱いになったりする。
なお、適切な抵抗値に幅があるコントローラーについて、&u(){抵抗値は応答速度に明白な影響を及ぼさない}ことを確認している。

****回路：自動解析用
[[タイマーIC555_ダミーセキュリティ>>http://www.sunhayato.co.jp/dcms_media/other/MNL-SBS203-06.pdf]]の回路を改良したものを使用。
R1=82.456kΩ, R2=10kΩ, C1=1μFとし、
-点灯時間：約0.069秒
-消灯時間：約0.638秒
の周期で回路をオン/オフさせる。合計周期の精度は±0.02秒程度だった。
コントローラー側の抵抗は適宜調整する。


**撮影
****共通
LED点灯および画面応答をカメラの1つの画面に収めて動画撮影する。

#divclass(bggray){
&u(){＜ゲーム側の設定＞}
-ピカチュウの弱攻撃
-75m終点化
-トレモのカメラ「もっとアップ」設定
}
ピカチュウの弱攻撃は
-キャラの色が背景色（黒）と大きく違っていて見やすい
-1F目から姿勢が大きく変わる
-全体Fが短く、続けて測定しやすい
といった理由により、測定に適している。

無線コントローラーの測定時には、他の機器によるノイズを極力抑えるように努めた。
当方の測定環境でノイズになりそうなものは以下の通り。
-近くに起動状態のPCがある（周辺機器は全て有線接続）
-隣室から無線LANが飛んでいる

****撮影：手動解析用
240fpsカメラで、画面全体+LEDを写す。
手動でスイッチを入/切し、10回×10セットを基本に撮影。
#image(pikamove.gif, https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/669/pikamove.gif)
&small(){↑ 撮影の様子。}

****撮影：自動解析用
1000fpsカメラで、モニターの一部だけをアップで撮影する。
撮影する位置は毎回同じになるよう努める。
回路を自動で入/切させ、約1000回の測定を1~4セット録画する。
#image(autodetect.png,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/696/autodetect.png,width=360)
#image(autodetect2.png,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/697/autodetect2.png,width=360)
&small(){↑ 撮影の様子。}


**映像解析
カメラで撮影した映像を解析して、応答時間を算出する。
解析は、&u(){手動（目視）}もしくは&u(){自動（プログラム）}で行う。

***手動解析
撮影した動画をAviutlで読み込み、コマ送りでLED点灯とモニター応答の時間差（コマ数）を数える。
LEDが光ったコマを基準とし、その何コマ後にモニター画面に変化が現れるかを記録する。
画面の変化は''全て目視''で判断する。
LEDは、少しでも色が変化したら「光った」とみなす。
モニター画面は、ピカチュウの体の黄色い部分に少しでも変化が見られたら「切り替わった」とみなす。
#image(measurement.png,width=360,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/670/measurement.png)
&small(){↑ 手動解析の手順。図の27コマ目の変化は分かりづらいが、コマ送りで見ると前コマとの差が識別できる。}

****映像解析補正について
&u(){自動解析の理論の方が正確であるという見解に基づき、}''自動解析と結果が揃うように補正をかける。''
揃える対象としたのはGCコンの数値。
その結果、通常の測定では&tt(){0.36F (6ms)}, 携帯・テーブルモードでは&tt(){0.57F (9.5ms)}を測定結果から引くこととなった。

#region(close,2019/8以前の補正方法)
本検証では、&b(){計測結果の平均から&tt(){0.15F (2.5ms)}を引いた値を応答速度の推定値としている。}

スマブラでは垂直同期が有効であるため、画面は必ず上方から、1Fかけて画面下部まで切り替わる。
理論上は画面一番上のピクセルが変化する瞬間を画面の切り替わりとするべきである。
しかし、ピカチュウの体の黄色い部分は、画面縦方向1080pxのうち上部の約150pxには映らない。
#image(pikachu.png,width=360,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/671/pikachu.png)
↑ 立ち状態のピカチュウ。
最も高い位置にある黄色い部位は耳の先端で、上から約150px。

したがって、&u(){本記事の方法では画面上部約1/7に起こる変化を観測することが不可能である。}
これはすなわち、''画面の応答を&tt(){約1/7F≒0.143F}だけ遅く見積もってしまう''ことを意味する。
さらに、実際の目視判定では1px単位の画面変化には気付けないため、実際の見積もり時間はもっと遅くなる。
ここでは読み取りに&tt(){0.15F}の遅れがあるとみなし、これを測定結果から引くことにした。

また、&bold(){携帯・テーブルモードの検証では、計測結果の平均から&tt(){0.18F(3.0ms)}を引いた値を応答速度の推定値としている。}
TVモードでは画面は上方から変化するが、''携帯モード・テーブルモードでは画面右方から変化する。''
映像処理で注目するのは、''左を向いたピカチュウのしっぽ''である。
変化を観測できないのは画面右部約1/6なので、見積もりの遅れは&tt(){約1/6F≒0.167F}。
目視判定の遅れを考慮し、補正は&tt(){0.18F}とした。
#endregion


***自動解析
****解析プログラム
#image(autodetect.png,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/696/autodetect.png,width=360)
&small(){↑ 撮影の様子（再掲）。}

解析プログラムは、
-LEDがある領域（&color(red){赤枠}）の輝度が上がったらLED点灯
-ピカチュウ頭の領域（&color(blue){青枠}）の輝度が下がったら画面応答
というように設計した。
画像読み込みにはPythonの&tt(){cv2.VideoCapture}を使用した。
周期性の分析には、高速フーリエ変換（Pythonの&tt(){scipy.fft}）を使用した。

****映像解析補正
青枠の上端は画面上方から約1/4の位置にある（上から約270px）。
したがってこの方法では、''画面の応答を&tt(){約1/4F}だけ遅く読み取ってしまう''。
この影響を取り除くため、計測結果の平均から&tt(){0.25F}を引いた値を応答速度の推定値とした。


***手動解析と自動解析の関係性
順序的には、シンプルな手動解析でしばらく検証を進め、正確さと効率向上のために自動解析を開発したという経緯がある。
現状では手動・自動のデータが混在しているので、結果の提示にあたっては''両者の整合性''を第一に考える。
ここでは前述の通り、GCコンの測定結果が揃うように自動解析の数値に合わせる。

それぞれの理論に基づいて解析・データ補正を行うと、自動は手動よりも&tt(){約0.2F}早い結果を出す。
主要因は、プログラムによる画像解析で&u(){目視では気付けなかった輝度変化を拾えている}こと。
とはいえ少々差が大きすぎるように思われるので、今後も議論が必要である。

また手動→自動の移行に伴い、カメラを替えてフレームレートを上げたことで、測定間のバラつきが目に見えて小さくなった。
理論的には、バラつきは240fpsでも十分小さいはずなのだが…。
カメラのフレームレートの安定性に差があるのかもしれない。


**データ処理
計測したN個のデータから、平均・標準偏差・標準誤差を次のように計算した。
 平均(mean) = sum(data) / N
 標準偏差(stdev) = sum((data-mean)^2) / N
 標準誤差(sterr) = stdev / sqrt(N)
その後、平均に対して上述の映像処理補正をかける。


**周期性の分析
無線コントローラーの応答速度は、周期&tt(){約500秒}・変化幅&tt(){約0.3F}で周期的に変化する。&footnote(通信規格の異なるウェーブバードのみ、周期約300秒)
この性質は、検証に用いた無線コントローラー全てに共通して見られる。原因は、
+SwitchもしくはBluetoothの通信規格
+測定環境に固有のノイズ
にあると考えられる。
測定環境を変えた''[[遅延検証＠オフ会場]]''でも同様の周期変化が確認できたので、可能性が高いのは前者。

この応答速度の周期性は、以前に原因不明と判定した測定のずれを説明可能である。
#region(close,参考：以前の考察)
****2019/1/2
以下のコントローラーは、''複数回の計測結果が標準誤差の範囲で一致しなかった。''
-TNS-1724
-CYBER無線
-SN30Pro
-携帯モード
これらについては2~3回の計測を平均した結果を掲載した。

****2019/2/8
GCコンやSwitchプロコン有線でも、複数回の検証結果が95%信頼区間（2σ）を超えて乖離するケースが確認された。
一番差が開いている結果の差（50or100回の平均）は、GCコンで0.1F程度、Switchプロコン有線では0.2F程度である。
ちなみに上述の無線コントローラーでは、0.2~0.3F程度の差が認められる。
いずれも測定方法は特に変更していない。
本章で列挙した要素で説明できる範囲をはるかに超える誤差であるため、未知の誤差要因があるのではないかと思われる。
コントローラーの接続数・登録数も変えて検証してみたが、有意な差は見られなかった。

****2019/7/25
映像自動解析によって試行回数Nを200~500回程度に増やせるようになったが、それでも異なる測定同士の大きな乖離が発生。
1000fpsカメラでもこのずれが発生するかどうかを検証すべきか。

****参考
ストリートファイターⅤでは「50秒の周期で入力遅延が4~7Fの間を変化する」という仕様が指摘されたことがある。（[[参考記事>>https://kakuge-checker.com/topic/view/06148/]]現在はアップデートで改善）
本検証で確認された差はここまでの幅ではないが、ソフトまたはハードの処理時間にゆらぎが存在する可能性はある。
#endregion

#image(swL_signal_N.png,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/699/swL_signal_N.png,width=300,inline)#image(swL_Amplitude_tlog.png,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/698/swL_Amplitude_tlog.png,width=300,inline)
&small(){↑ 無線接続したSwitchプロコンのデータ。}
&small(){左：応答速度の時系列データ（平均との差を描画）。右：フーリエ変換による周期成分抽出。}


一方、測定結果によっては、500秒周期に匹敵する強度を持つ周期成分（数秒～数十秒）が存在する。
しかし今のところ測定間・コントローラー間の共通性が見出せないため、詳しい議論は避けている。

周期性を有する場合に正確な応答時間を得るためには、&u(){計測時間を周期の定数倍にするのが望ましい。}
しかしながら数十分程度の検証では、500秒前後の周期の長さを正確に求めるにはデータ長が不足している。
不正確な周期に基づいて下手にデータを切り取ると、別の長周期の変化を見落としてしまう可能性がある。
そのため今回は暫定的に、最低でも500秒×3周期分の測定時間を確保した上で、&bold(){データを加工せずに平均を取った。}

また有線コントローラーでも、&u(){異様にはっきりした周期性や異常な推移をする測定区間}が突発的に見られることがあった。
原因はコントローラーと回路の一時的な相性不良、電気回路の点滅周期の不定性などが考えられる。
再現性が無く、結果の正確性を損なう可能性が高いため、これらの異常があった場合には&bold(){回路を調整して再測定}した。
#image(tns_signal_N.png,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/702/tns_signal_N.png,width=300, inline)#image(GC_signal_N.png,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/703/GC_signal_N.png,width=300, inline)
&small(){↑ 左：TNS-901, 右：GCコン。いずれもデータは破棄。}



**誤差の議論
この節では計測結果に誤差・バラつきを与える原因を取り上げる。
240fpsカメラで10回×10セット=100回の測定を行ない、映像を手動解析する場合を考える。

****コントローラー・ゲーム機の特性
ハードウェアの処理・通信速度自体のバラつき。
他の外的要因を全て除いたときに残るのがこの誤差である。
&u(){とりわけ標準偏差が他と大きく異なる場合は、コントローラーの特性由来のばらつきだと考えてよい。}
標準偏差が大きいコントローラーは接続や処理が不安定な傾向にあると言える。
今回はAボタンのみの検証だが、同時押しやスティックを併用した場合、処理時間にばらつきが出るかもしれない。


****カメラのフレームレート
実験装置によって生じる誤差。&u(){理論的には、平均値に与える影響は±0}。
カメラのフレームレートを上げるか、測定回数を増やすことで誤差の振れ幅を小さくできる。
しかし結論から言うと、240fpsどころか''60fpsのカメラでも有意義な結果を出すことは可能''である。
240fpsのカメラでは、発生した現象をカメラが捉えるまでに&tt(){0 ~ 0.25 F}のラグが発生する（一様分布。平均0.125F）。
LED（開始時刻）とモニター（終了時刻）の両方をカメラで計測するため、&b(){両者のラグは全体としてキャンセルされる。}

カメラのフレームレートに依存する誤差の大きさを推定する。
LEDは、100回の点灯のたびにラグの値が一様ランダムに決まり、それらを均したものが誤差の振れ幅となる。
モニターについては、撮影1セットごと、計10回分の一様ランダムなラグを均す&footnote(240fpsが60fpsの整数倍であるため、1回の撮影中はカメラのフレームレートに起因するラグが一定となる)。
一様分布は 1/12*(b-a)^2 の分散を持つ。
本項の誤差幅は、一様分布100個/10個の和の標準誤差と考えることができる。
分布和に対し中心極限定理が適用できると仮定すれば、誤差幅は
 LED撮影：± sqrt(0.25^2 /12 /100) ~ 0.0072 F
 モニター撮影：± sqrt(0.25^2 /12 /10) ~ 0.023 F
 撮影合計： ~ ± 0.024 F　（誤差伝播則）
と求まる。これは他の要因による誤差に比べて小さい。



****ゲーム・モニターのフレームレート
&b(){ゲーム及びモニターの画面更新周期}で生じる誤差。
影響は平均で&u(){+0.5F}で、測定回数を増やせばその振れ幅を小さくできる。
ボタン入力などの情報は、ゲームのフレームレートである1フレームの周期でしか画面に反映されない。
例えば、1.00~1.99フレームの間に届いた入力は全て2フレーム目の画面に表示される。
このように任意のタイミングのボタン入力は、ゲーム機に届いてから画面に反映されるまで+0~1Fのラグが必ず発生する。
そのため、ゲーム画面を撮影orキャプチャして計る場合、&u(){応答速度は系統的に+0.5フレーム遅く計測される}。
本計測では、&b(){この0.5フレームの遅れは補正せず、結果に含めて表示している。}
どんな機器を使っても、60fpsのゲームを遊ぶ以上必ず発生するラグだからである。

この誤差幅については、+0~1Fの一様分布が100回観測されることから、カメラのフレームレートと同様の議論で
 モニター：± sqrt(1^2 /12 /100) ~ ± 0.029 F
となる。


****コントローラーのサンプリングレート
コントローラーがボタン入力信号を受け付ける周期。
遅延の性質としてはゲーム・モニターのフレームレートと同種で、見かけ上はゲーム・モニターのフレームレートと区別できない。
サンプリングレートがゲームのフレームレートの整数倍である限り、ゲーム・モニターのフレームレートと一括りで考えてよい。
例えばGCコンのサンプリングレートは120fpsで、ゲームのフレームレートのちょうど2倍である。
参考：[[スマブラDX対戦攻略指南 コントローラ入力のサンプリングレート>>http://dx.smashbr0s.com/%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%A9%E5%85%A5%E5%8A%9B%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AA%E3%83%B3%E3%82%B0%E3%83%AC%E3%83%BC%E3%83%88/]]


****映像記録のミス
&u(){＜手動解析の場合＞}
映像の変化を目視で読み取る際の人為的なミス。
240fpsでは、LEDの点灯を見落とすことはまずない。
一方モニターは映像の小さな変化を見落とす可能性がそれなりにあり、100回中1~3回ミスが発生してもおかしくない。
モニターの見落としは、応答速度が遅くなる方に働く。
1コマ分（0.25F）のミスが多めに見積もって5回あるとすると、平均ではおよそ&tt(){+0.0125F}のエラーが出ることになる。

&u(){＜自動解析の場合＞}
画面や周囲の明るさなど、明度に関する検証環境の違いがアルゴリズムの検出精度に影響を及ぼす可能性がある。


**検定について
[[コントローラー遅延検証]]のページにおける「統計的に」や「有意な」などという表現は、統計学的な分析に基づいている。
分析には標準誤差のほか、&bold(){コルモゴロフ–スミルノフ検定（KS検定）}を用いた。
KS検定は、「2つのデータがどのくらい似ているか」を"p値"として出力する。
p値は0以上1以下の値を取る。通常、p値が0.05を下回れば、2つは十分に異なる（＝性能に差がある）とみなされる。
※ここでは大雑把な説明にとどめています。

参考までに、いくつかの測定結果の組に対してKS検定を適用した結果を以下に掲載する。
下に行くほどp値が小さく、分布の異なり具合が大きい。
|項目1|項目2|p値|h
|GCコン1月|GCコン6月|0.8756|
|GCコン|SwPro無線|0.8020|
|GC4台黒端子|GC4台黒灰端子|0.6766|
|CYBER無線|CYBER無線USB|0.3439|
|GCコン|HORIコン|0.1703|
|SwPro無線|Joy-Con|0.0356|
|SwPro無線1月|SwPro無線6月|10^(-21)|
#table_zebra(01, #f0f0f0, #fff, #bbb)


----
**コメント
#comment()

このページでは、[[コントローラー遅延検証]]の測定方法の詳細を解説する。
#contents(,fromhere=true,level=3)
----
**測定方法の概要
コントローラー基板に電子回路を接続し、Aボタンを入力すると同時にLEDが点灯するように設計する。
ハイスピードカメラでLEDとゲーミングモニターを撮影し、LEDが光ってから画面に入力が反映されるまでのコマ数を数える。
この計測で測定されるのは、
-''コントローラーの処理時間''
-ゲーム内部の処理時間
-モニター内部の処理時間
-モニター液晶パネルの応答時間
の合計である。
計測回数は100回以上を目安とし、それらの平均を取って測定結果とする。

データ解析には、手動・自動の2種類の方法がある。
実験の設計などで異なる部分については別々に解説する。


**使った機材
-各種コントローラー
-[[I-O DATA EX-LDGC251TB>>https://www.iodata.jp/product/lcd/wide/ex-ldgc251tb/]]
--応答速度&tt(){5ms}（オーバードライブ2+GtG時 &tt(){0.8ms}）、モニター内部遅延&tt(){0.53ms}。
--forとSPの比較のみ、[[ViewSonic VX2363SMHL>>https://www.viewsonic.com/jp/products/lcd/VX2363SMHL.php]]を使った&footnote(モニターを買い換える前に検証したため)。
-[[サンハヤト 小型ブレッドボードパーツセット SBS-203>>https://www.sunhayato.co.jp/material2/index.php/item?cell003=%E6%95%99%E8%82%B2%E5%AE%9F%E7%BF%92%E3%83%BB%E9%9B%BB%E5%AD%90%E5%B7%A5%E4%BD%9C%E8%A3%BD%E5%93%81&cell004=%E3%83%96%E3%83%AC%E3%83%83%E3%83%89%E3%83%9C%E3%83%BC%E3%83%89%E3%82%AA%E3%83%97%E3%82%B7%E3%83%A7%E3%83%B3&name=%E5%B0%8F%E5%9E%8B%E3%83%96%E3%83%AC%E3%83%83%E3%83%89%E3%83%9C%E3%83%BC%E3%83%89%E3%83%91%E3%83%BC%E3%83%84%E3%82%BB%E3%83%83%E3%83%88+%E3%82%BF%E3%82%A4%E3%83%9E%E3%83%BCIC%E3%80%8C555%E3%80%8D%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9F%E9%9B%BB%E5%AD%90%E5%B7%A5%E4%BD%9C%E3%82%BB%E3%83%83%E3%83%88&id=803&label=1]]
-導線
-白色LED
-[[OLYMPUS Stylus XZ-10>>https://www.olympus-imaging.jp/product/compact/xz10/]]（最大240fps）/[[CASIO EX-ZR400>>http://arch.casio.jp/dc/products/ex_zr400/]]（最大1000fps）


**回路設計
****共通
コントローラー基板の各ボタンに対応する位置には、分断された電極がある。
ボタンが押下されて導電性ゴムが電極に接触すると、通電してボタンが入力されたと処理される。
この検証では2つの電極にそれぞれ導線を接着し、導線を通して通電させることでボタン入力する。

LEDとコントローラー基板を並列に繋いだ電気回路を設計する。
電気回路がONになると、LEDとコントローラー基板が同時に通電する。
コントローラー以外の回路の応答時間は考慮しない。
&image(GC_connect.jpg, width=300,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/705/GC_connect.jpg, inline)&image(swpro_connect.jpg, width=300,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/704/swpro_connect.jpg, inline)
&small(){↑ GCコン・Switchプロコンの接続。導線はテープ+洗濯バサミで固定。導線の正極・負極の向きも適切に配線する必要がある。}

****回路：手動解析用
#image(circuit.png,width=360,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/668/circuit.png)
コントローラー側の抵抗R2はコントローラーに応じて調整が必要。
適切な抵抗を使わないと、スイッチを入れてもボタンが反応しなかったり、全く別のボタンが押された扱いになったりする。
なお、適切な抵抗値に幅があるコントローラーについて、&u(){抵抗値は応答速度に明白な影響を及ぼさない}ことを確認している。

****回路：自動解析用
[[タイマーIC555_ダミーセキュリティ>>http://www.sunhayato.co.jp/dcms_media/other/MNL-SBS203-06.pdf]]の回路を改良したものを使用。
R1=82.456kΩ, R2=10kΩ, C1=1μFとし、
-点灯時間：約0.069秒
-消灯時間：約0.638秒
の周期で回路をオン/オフさせる。合計周期の精度は±0.02秒程度だった。
コントローラー側の抵抗は適宜調整する。


**撮影
****共通
LED点灯および画面応答をカメラの1つの画面に収めて動画撮影する。

#divclass(bggray){
&u(){＜ゲーム側の設定＞}
-ピカチュウの弱攻撃
-75m終点化
-トレモのカメラ「もっとアップ」設定
}
ピカチュウの弱攻撃は
-キャラの色が背景色（黒）と大きく違っていて見やすい
-1F目から姿勢が大きく変わる
-全体Fが短く、続けて測定しやすい
といった理由により、測定に適している。

無線コントローラーの測定時には、他の機器によるノイズを極力抑えるように努めた。
当方の測定環境でノイズになりそうなものは以下の通り。
-近くに起動状態のPCがある（周辺機器は全て有線接続）
-隣室から無線LANが飛んでいる

****撮影：手動解析用
240fpsカメラで、画面全体+LEDを写す。
手動でスイッチを入/切し、10回×10セットを基本に撮影。
#image(pikamove.gif, https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/669/pikamove.gif)
&small(){↑ 撮影の様子。}

****撮影：自動解析用
1000fpsカメラで、モニターの一部だけをアップで撮影する。
撮影する位置は毎回同じになるよう努める。
回路を自動で入/切させ、約1000回の測定を1~4セット録画する。
#image(autodetect.png,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/696/autodetect.png,width=360)
#image(autodetect2.png,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/697/autodetect2.png,width=360)
&small(){↑ 撮影の様子。}


**映像解析
カメラで撮影した映像を解析して、応答時間を算出する。
解析は、&u(){手動（目視）}もしくは&u(){自動（プログラム）}で行う。

***手動解析
撮影した動画をAviutlで読み込み、コマ送りでLED点灯とモニター応答の時間差（コマ数）を数える。
LEDが光ったコマを基準とし、その何コマ後にモニター画面に変化が現れるかを記録する。
画面の変化は''全て目視''で判断する。
LEDは、少しでも色が変化したら「光った」とみなす。
モニター画面は、ピカチュウの体の黄色い部分に少しでも変化が見られたら「切り替わった」とみなす。
#image(measurement.png,width=360,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/670/measurement.png)
&small(){↑ 手動解析の手順。図の27コマ目の変化は分かりづらいが、コマ送りで見ると前コマとの差が識別できる。}

****映像解析補正について
&u(){自動解析の理論の方が正確であるという見解に基づき、}''自動解析と結果が揃うように補正をかける。''
揃える対象としたのはGCコンの数値。
その結果、通常の測定では&tt(){0.36F}, 携帯・テーブルモードでは&tt(){0.39F}を測定結果から引くこととなった。

#region(close,2019/8以前の補正方法)
本検証では、&b(){計測結果の平均から&tt(){0.15F (2.5ms)}を引いた値を応答速度の推定値としている。}

スマブラでは垂直同期が有効であるため、画面は必ず上方から、1Fかけて画面下部まで切り替わる。
理論上は画面一番上のピクセルが変化する瞬間を画面の切り替わりとするべきである。
しかし、ピカチュウの体の黄色い部分は、画面縦方向1080pxのうち上部の約150pxには映らない。
#image(pikachu.png,width=360,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/671/pikachu.png)
↑ 立ち状態のピカチュウ。
最も高い位置にある黄色い部位は耳の先端で、上から約150px。

したがって、&u(){本記事の方法では画面上部約1/7に起こる変化を観測することが不可能である。}
これはすなわち、''画面の応答を&tt(){約1/7F≒0.143F}だけ遅く見積もってしまう''ことを意味する。
さらに、実際の目視判定では1px単位の画面変化には気付けないため、実際の見積もり時間はもっと遅くなる。
ここでは読み取りに&tt(){0.15F}の遅れがあるとみなし、これを測定結果から引くことにした。

また、&bold(){携帯・テーブルモードの検証では、計測結果の平均から&tt(){0.18F(3.0ms)}を引いた値を応答速度の推定値としている。}
TVモードでは画面は上方から変化するが、''携帯モード・テーブルモードでは画面右方から変化する。''
映像処理で注目するのは、''左を向いたピカチュウのしっぽ''である。
変化を観測できないのは画面右部約1/6なので、見積もりの遅れは&tt(){約1/6F≒0.167F}。
目視判定の遅れを考慮し、補正は&tt(){0.18F}とした。
#endregion


***自動解析
****解析プログラム
#image(autodetect.png,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/696/autodetect.png,width=360)
&small(){↑ 撮影の様子（再掲）。}

解析プログラムは、
-LEDがある領域（&color(red){赤枠}）の輝度が上がったらLED点灯
-ピカチュウ頭の領域（&color(blue){青枠}）の輝度が下がったら画面応答
というように設計した。
画像読み込みにはPythonの&tt(){cv2.VideoCapture}を使用した。
周期性の分析には、高速フーリエ変換（Pythonの&tt(){scipy.fft}）を使用した。

****映像解析補正
青枠の上端は画面上方から約1/4の位置にある（上から約270px）。
したがってこの方法では、''画面の応答を&tt(){約1/4F}だけ遅く読み取ってしまう''。
この影響を取り除くため、計測結果の平均から&tt(){0.25F}を引いた値を応答速度の推定値とした。


***手動解析と自動解析の関係性
順序的には、シンプルな手動解析でしばらく検証を進め、正確さと効率向上のために自動解析を開発したという経緯がある。
現状では手動・自動のデータが混在しているので、結果の提示にあたっては''両者の整合性''を第一に考える。
ここでは前述の通り、GCコンの測定結果が揃うように自動解析の数値に合わせる。

それぞれの理論に基づいて解析・データ補正を行うと、自動は手動よりも&tt(){約0.2F}早い結果を出す。
主要因は、プログラムによる画像解析で&u(){目視では気付けなかった輝度変化を拾えている}こと。
とはいえ少々差が大きすぎるように思われるので、今後も議論が必要である。

また手動→自動の移行に伴い、カメラを替えてフレームレートを上げたことで、測定間のバラつきが目に見えて小さくなった。
理論的には、バラつきは240fpsでも十分小さいはずなのだが…。
カメラのフレームレートの安定性に差があるのかもしれない。


**データ処理
計測したN個のデータから、平均・標準偏差・標準誤差を次のように計算した。
 平均(mean) = sum(data) / N
 標準偏差(stdev) = sum((data-mean)^2) / N
 標準誤差(sterr) = stdev / sqrt(N)
その後、平均に対して上述の映像処理補正をかける。


**周期性の分析
無線コントローラーの応答速度は、周期&tt(){約500秒}・変化幅&tt(){約0.3F}で周期的に変化する。&footnote(通信規格の異なるウェーブバードのみ、周期約300秒)
この性質は、検証に用いた無線コントローラー全てに共通して見られる。原因は、
+SwitchもしくはBluetoothの通信規格
+測定環境に固有のノイズ
にあると考えられる。
測定環境を変えた''[[遅延検証＠オフ会場]]''でも同様の周期変化が確認できたので、可能性が高いのは前者。

この応答速度の周期性は、以前に原因不明と判定した測定のずれを説明可能である。
#region(close,参考：以前の考察)
****2019/1/2
以下のコントローラーは、''複数回の計測結果が標準誤差の範囲で一致しなかった。''
-TNS-1724
-CYBER無線
-SN30Pro
-携帯モード
これらについては2~3回の計測を平均した結果を掲載した。

****2019/2/8
GCコンやSwitchプロコン有線でも、複数回の検証結果が95%信頼区間（2σ）を超えて乖離するケースが確認された。
一番差が開いている結果の差（50or100回の平均）は、GCコンで0.1F程度、Switchプロコン有線では0.2F程度である。
ちなみに上述の無線コントローラーでは、0.2~0.3F程度の差が認められる。
いずれも測定方法は特に変更していない。
本章で列挙した要素で説明できる範囲をはるかに超える誤差であるため、未知の誤差要因があるのではないかと思われる。
コントローラーの接続数・登録数も変えて検証してみたが、有意な差は見られなかった。

****2019/7/25
映像自動解析によって試行回数Nを200~500回程度に増やせるようになったが、それでも異なる測定同士の大きな乖離が発生。
1000fpsカメラでもこのずれが発生するかどうかを検証すべきか。

****参考
ストリートファイターⅤでは「50秒の周期で入力遅延が4~7Fの間を変化する」という仕様が指摘されたことがある。（[[参考記事>>https://kakuge-checker.com/topic/view/06148/]]現在はアップデートで改善）
本検証で確認された差はここまでの幅ではないが、ソフトまたはハードの処理時間にゆらぎが存在する可能性はある。
#endregion

#image(swL_signal_N.png,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/699/swL_signal_N.png,width=300,inline)#image(swL_Amplitude_tlog.png,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/698/swL_Amplitude_tlog.png,width=300,inline)
&small(){↑ 無線接続したSwitchプロコンのデータ。}
&small(){左：応答速度の時系列データ（平均との差を描画）。右：フーリエ変換による周期成分抽出。}


一方、測定結果によっては、500秒周期に匹敵する強度を持つ周期成分（数秒～数十秒）が存在する。
しかし今のところ測定間・コントローラー間の共通性が見出せないため、詳しい議論は避けている。

周期性を有する場合に正確な応答時間を得るためには、&u(){計測時間を周期の定数倍にするのが望ましい。}
しかしながら数十分程度の検証では、500秒前後の周期の長さを正確に求めるにはデータ長が不足している。
不正確な周期に基づいて下手にデータを切り取ると、別の長周期の変化を見落としてしまう可能性がある。
そのため今回は暫定的に、最低でも500秒×3周期分の測定時間を確保した上で、&bold(){データを加工せずに平均を取った。}

また有線コントローラーでも、&u(){異様にはっきりした周期性や異常な推移をする測定区間}が突発的に見られることがあった。
原因はコントローラーと回路の一時的な相性不良、電気回路の点滅周期の不定性などが考えられる。
再現性が無く、結果の正確性を損なう可能性が高いため、これらの異常があった場合には&bold(){回路を調整して再測定}した。
#image(tns_signal_N.png,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/702/tns_signal_N.png,width=300, inline)#image(GC_signal_N.png,https://img.atwikiimg.com/www65.atwiki.jp/smashsp_kensyou/attach/90/703/GC_signal_N.png,width=300, inline)
&small(){↑ 左：TNS-901, 右：GCコン。いずれもデータは破棄。}



**誤差の議論
この節では計測結果に誤差・バラつきを与える原因を取り上げる。
240fpsカメラで10回×10セット=100回の測定を行ない、映像を手動解析する場合を考える。

****コントローラー・ゲーム機の特性
ハードウェアの処理・通信速度自体のバラつき。
他の外的要因を全て除いたときに残るのがこの誤差である。
&u(){とりわけ標準偏差が他と大きく異なる場合は、コントローラーの特性由来のばらつきだと考えてよい。}
標準偏差が大きいコントローラーは接続や処理が不安定な傾向にあると言える。
今回はAボタンのみの検証だが、同時押しやスティックを併用した場合、処理時間にばらつきが出るかもしれない。


****カメラのフレームレート
実験装置によって生じる誤差。&u(){理論的には、平均値に与える影響は±0}。
カメラのフレームレートを上げるか、測定回数を増やすことで誤差の振れ幅を小さくできる。
しかし結論から言うと、240fpsどころか''60fpsのカメラでも有意義な結果を出すことは可能''である。
240fpsのカメラでは、発生した現象をカメラが捉えるまでに&tt(){0 ~ 0.25 F}のラグが発生する（一様分布。平均0.125F）。
LED（開始時刻）とモニター（終了時刻）の両方をカメラで計測するため、&b(){両者のラグは全体としてキャンセルされる。}

カメラのフレームレートに依存する誤差の大きさを推定する。
LEDは、100回の点灯のたびにラグの値が一様ランダムに決まり、それらを均したものが誤差の振れ幅となる。
モニターについては、撮影1セットごと、計10回分の一様ランダムなラグを均す&footnote(240fpsが60fpsの整数倍であるため、1回の撮影中はカメラのフレームレートに起因するラグが一定となる)。
一様分布は 1/12*(b-a)^2 の分散を持つ。
本項の誤差幅は、一様分布100個/10個の和の標準誤差と考えることができる。
分布和に対し中心極限定理が適用できると仮定すれば、誤差幅は
 LED撮影：± sqrt(0.25^2 /12 /100) ~ 0.0072 F
 モニター撮影：± sqrt(0.25^2 /12 /10) ~ 0.023 F
 撮影合計： ~ ± 0.024 F　（誤差伝播則）
と求まる。これは他の要因による誤差に比べて小さい。



****ゲーム・モニターのフレームレート
&b(){ゲーム及びモニターの画面更新周期}で生じる誤差。
影響は平均で&u(){+0.5F}で、測定回数を増やせばその振れ幅を小さくできる。
ボタン入力などの情報は、ゲームのフレームレートである1フレームの周期でしか画面に反映されない。
例えば、1.00~1.99フレームの間に届いた入力は全て2フレーム目の画面に表示される。
このように任意のタイミングのボタン入力は、ゲーム機に届いてから画面に反映されるまで+0~1Fのラグが必ず発生する。
そのため、ゲーム画面を撮影orキャプチャして計る場合、&u(){応答速度は系統的に+0.5フレーム遅く計測される}。
本計測では、&b(){この0.5フレームの遅れは補正せず、結果に含めて表示している。}
どんな機器を使っても、60fpsのゲームを遊ぶ以上必ず発生するラグだからである。

この誤差幅については、+0~1Fの一様分布が100回観測されることから、カメラのフレームレートと同様の議論で
 モニター：± sqrt(1^2 /12 /100) ~ ± 0.029 F
となる。


****コントローラーのサンプリングレート
コントローラーがボタン入力信号を受け付ける周期。
遅延の性質としてはゲーム・モニターのフレームレートと同種で、見かけ上はゲーム・モニターのフレームレートと区別できない。
サンプリングレートがゲームのフレームレートの整数倍である限り、ゲーム・モニターのフレームレートと一括りで考えてよい。
例えばGCコンのサンプリングレートは120fpsで、ゲームのフレームレートのちょうど2倍である。
参考：[[スマブラDX対戦攻略指南 コントローラ入力のサンプリングレート>>http://dx.smashbr0s.com/%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%A9%E5%85%A5%E5%8A%9B%E3%81%AE%E3%82%B5%E3%83%B3%E3%83%97%E3%83%AA%E3%83%B3%E3%82%B0%E3%83%AC%E3%83%BC%E3%83%88/]]


****映像記録のミス
&u(){＜手動解析の場合＞}
映像の変化を目視で読み取る際の人為的なミス。
240fpsでは、LEDの点灯を見落とすことはまずない。
一方モニターは映像の小さな変化を見落とす可能性がそれなりにあり、100回中1~3回ミスが発生してもおかしくない。
モニターの見落としは、応答速度が遅くなる方に働く。
1コマ分（0.25F）のミスが多めに見積もって5回あるとすると、平均ではおよそ&tt(){+0.0125F}のエラーが出ることになる。

&u(){＜自動解析の場合＞}
画面や周囲の明るさなど、明度に関する検証環境の違いがアルゴリズムの検出精度に影響を及ぼす可能性がある。


**検定について
[[コントローラー遅延検証]]のページにおける「統計的に」や「有意な」などという表現は、統計学的な分析に基づいている。
分析には標準誤差のほか、&bold(){コルモゴロフ–スミルノフ検定（KS検定）}を用いた。
KS検定は、「2つのデータがどのくらい似ているか」を"p値"として出力する。
p値は0以上1以下の値を取る。通常、p値が0.05を下回れば、2つは十分に異なる（＝性能に差がある）とみなされる。
※ここでは大雑把な説明にとどめています。

参考までに、いくつかの測定結果の組に対してKS検定を適用した結果を以下に掲載する。
下に行くほどp値が小さく、分布の異なり具合が大きい。
|項目1|項目2|p値|h
|GCコン1月|GCコン6月|0.8756|
|GCコン|SwPro無線|0.8020|
|GC4台黒端子|GC4台黒灰端子|0.6766|
|CYBER無線|CYBER無線USB|0.3439|
|GCコン|HORIコン|0.1703|
|SwPro無線|Joy-Con|0.0356|
|SwPro無線1月|SwPro無線6月|10^(-21)|
#table_zebra(01, #f0f0f0, #fff, #bbb)


----
**コメント
#comment()