RoboCup サッカーシミュレーション 2D における性能評価システムの開発

RoboCup

サッカーシミュレーション

2D

における

性能評価システムの開発

Development of a Performance-Evaluation System

for RoboCup Soccer Simulation 2D

久我 亮太

∗

鈴木 雄大

中島 智晴

Ryota Kuga, Yudai Suzuki, Tomoharu Nakashima

大阪府立大学大学院 人間社会システム科学研究科

Graduate School of Humanities and Sustainable System Sciences

Osaka Prefecture University

Abstract: This paper describes a performance-evaluation system for RoboCup Soccer Simulation

2D. One of the problems in developing a team for soccer simulation is that it is difficult to evaluate the general performance of the team with a large number of games. This is because resources such as developers, computers, and the time are limited. It is also difficult to automatically repeat a game because one has to manually execute a series of commands to perform a single game. In order to develop the team efficiently, we develop an interactive system that can evaluate team-performance by assigning computers automatically to run games and aggregating the results. The interactive system by using a Slack bot makes anyone use it easily through any device with Slack app. In addition, the aggregated results are recorded on the Google Sheets, so the all team developers can share the results and check it anytime. We explain the performance-evaluation system in detail that for efficient team development.

1

はじめに

近年，日本で生産労働人口の減少問題や働き方改革 が叫ばれる中，Robotics Process Automation (RPA) [1] の導入による問題解決が注目を集めている．これは 従来人間が手動で行っていた定型的なコンピュータ操 作などの単純な業務を，「ソフトウェアのロボット」に より，自動で処理可能にする技術である．これにより， 人間は単純な業務から解放され，他の業務へシフトす ることで，生産性の向上が期待できる．RPA は様々な タスクへの導入が進んでおり，多種多様な分野への適 用が可能である．本論文では，RoboCup サッカーシ ミュレーション 2D に対して RPA を応用することで， チーム開発者の生産性の向上を目的とする． 多くの不確定要素を持つ RoboCup サッカーシミュ レーション 2D では，同じ対戦組み合わせであっても 試合ごとに試合結果が異なる．パスやドリブルの出現 頻度や出現場所といった，プレイ内容も毎試合変化す る．したがって，一試合の結果のみをもってチームの優 ∗_{連絡先：大阪府立大学大学院 人間社会システム科学研究科}       〒 599-8531 大阪府堺市中区学園町 1-1        E-mail: [email protected] 劣を決定することは誤った結論を導きかねない．その ような特徴から，同一設定で複数試合を実行すること によって統計的な分析を行うことが求められる．従来， RoboCup サッカーシミュレーション 2D では，チーム の勝利のために試合中の局所的な場面におけるプレイ ヤのふるまいを強化するための研究が多くなされてき た．一方で，試合全体の大域的な評価に関する研究は 十分進んでいない．西野ら [2] は，試合全体の状態空 間とその遷移に着目した分析法について考察した．複 数試合を実行して分析することによって，チームの真 の優劣を決めることが可能であると結論づけた．これ に基づき本論文では，同一設定における複数の試合結 果を分析することでチームの優劣を評価することを性 能評価と定義する． しかし，性能評価には同一設定の試合を複数実行し， 各試合のログファイルを解析，解析した全ての結果を 集計する工程が必要である．また，一試合の開始には サーバやプレイヤといった複数のプログラムの実行が 必要となり，高い計算コストがかかるため，タスクが 重複しないように計算機を適切に割り当てる必要があ る．また，試合結果を解析するにも試合ログから再生画 面を使ってパスやドリブルの数を目で追いながら統計

情報を構築したり，数千試合以上の試合結果を手作業 で表に記入することは実質的に不可能である．これら を全て手動で行うには多くの時間と人手を必要とする ため，チーム開発における大きなボトルネックとなる． さらに， RoboCup に参加するチームの多くは，プレ イヤの機能を複数の開発メンバで分担して開発を行っ ている．たとえ，個々の実装がチームの性能に良い影 響を与えていても，全体の実装を統合すると，チーム の性能に悪影響を与える場合が起こり得る．そのため， 個々の実装だけではなく統合後の実装に対しても性能 評価を行う必要がある．以上を考慮すると，解析結果 の記入フォーマットは統一しておくことが望ましい． 本論文では，RoboCup サッカーシミュレーション 2D のチーム開発フローにおける，性能評価工程の自動化 を実現可能にするシステムを提案する．計算機割り当 て，繰り返し試合実行，試合結果の解析や共有まで一 括で行うことにより，効率的なチーム開発の実現に貢 献することができる． 本論文は以下のように構成されている．第 2 章で RoboCup の概要や RoboCup サッカーシミュレーショ ン 2D リーグの特徴，ログファイル，試合実行や分析 手順について説明する．第 3 章で我々が提案する性能 評価システムの概要と操作方法について説明する．最 後に，第 4 章で本論文のまとめと今後の課題について 述べる．

2

RoboCup

2.1

概要

RoboCup [3] は，ロボット工学と人工知能の発展を 目的とした自律移動型ロボットによるサッカーなどを題 材とした国際的な研究プロジェクトである．RoboCup には「西暦 2050 年までに，サッカーの世界チャンピオ ンチームに勝つ自律型ロボットチームを作る」という 目標があり，この目標に向けて盛んに研究が行われて いる．RoboCup にはサッカーの他に，大規模災害への 対応のシミュレーションや災害現場で活躍するロボッ トの開発を促進するレスキュー，日常生活で人間を支 援する自律ロボットによる競技を通じて，人とコミュ ニケーションしながらより役に立つ仕事を行うロボッ トの実現を目指す＠ホーム，次世代のロボット技術者 育成を目的としているジュニアなどのリーグが存在す る．サッカーシミュレーションリーグは，RoboCup 創 設当初から存在する最も古いリーグの 1 つであり，実 機を使用せず，コンピュータ内に用意された仮想フィー ルド上でサッカー競技を行う．サッカーシミュレーショ ンはモデル化の形式によって 2D リーグと 3D リーグ に分けられる．本論文における性能評価システムは， RoboCup サッカーシミュレーション 2D リーグを対象 としている．

2.2

RoboCup サッカーシミュレーション

2D リーグ

RoboCup サッカーシミュレーション 2D リーグは， 1 つの CPU もしくは人間が全てのプレイヤを操作す るような娯楽用のサッカーゲームとは異なり，全ての プレイヤがそれぞれ独立したプログラムで動くマルチ エージェント環境でサッカーを行う．また，プレイヤ やボールの位置と速度は全て二次元べクトルとして表 される． プレイヤは，kick, dash, turn などの抽象化さ れたコマンドを基本行動として 1 サイクルに 1 回だけ 実行する．試合は前後半 3000 サイクルずつ合計 6000 サイクルからなり， 1 サイクルは 0.1 秒で離散化され ている． 図 1 に RoboCup サッカーシミュレーション 2D リー グの試合の様子を示す．プレイヤやコーチはそれぞれ 独立したエージェントとしてプログラムされている．各 プレイヤには実際の人間と同様に視野が設定されてお り，自身の視野内で認識できた情報に基づいて視覚情 報が形成される．また，他のプレイヤやコーチがメッ セージとして発している情報を，聴覚情報として使用 できる．これらの視覚情報や聴覚情報からフィールド 情報を形成し，これに基づきドリブルやパスなどの意 思決定を下す．しかし，視覚情報にはノイズが含まれ， 正確な情報を得ることができない．聴覚情報について も確実に受信できるとは限らず，コーチのメッセージ は通常プレイ時には到達までに遅延も発生する．その ため，プレイヤはフィールド上の正確な情報を保持す ることができない．一方で，コーチはフィールド上の 情報をノイズなしで取得することができるので，正確 なフィールド情報を保持することができる．通常プレ イ時におけるプレイヤへの意思伝達には遅延が発生し， 回数も制限されている．しかし，ハーフタイム時にお いては，プレイヤに即時に情報を伝達することができ る．また，試合毎に異なる能力を持つプレイヤのセッ トが与えられ，各チームがプレイヤにポジションの割 当を行う． このようにプレイヤが得られる情報や物体の移動に ノイズが付加されるため，試合にはランダムで不確定 な要素が多い．よって，同一の対戦相手であっても，試 合毎に結果や内容が異なる．一回の試合結果で勝敗を 予測することは誤った性能評価につながる恐れがあり， 複数回の試合結果から有意な統計的性質を導くべきで ある．ただし，不確定要素が多いため，一つの対戦組み 合わせに対して統計的に十分な試合回数が必要となる．

図 1: Soccer simulation 2D league.

2.3

ログファイル

RoboCup サッカーシミュレーション 2D の試合が終 了すると，ログファイルが生成される．ログファイル は，試合を管理しているサッカーサーバ [4] から自動的 に出力され，各プレイヤの能力を表すパラメータ，試 合の状況，サイクル毎のプレイヤやボールの位置，プ レイヤの行動といった試合中の全ての情報が含まれて いる．よって，ログファイルを使用することにより，終 了した試合を完全に再現可能である． サッカーサーバから出力されたログファイルは，図 2 で示すように文字列で表現されているため，実際のサッ カーで用いられているパスやドリブルなどの特徴量を 直接ログファイルから抽出することはできない．した がって必要な情報のみを抽出する必要がある．

図 2: Text in a log file (excerpt).

2.4

単一試合の実行・分析手順

RoboCup サッカーシミュレーション 2D における単 一試合の実行・分析は，サッカーフィールドの準備，プ レイヤとコーチの準備，試合終了後，ログファイルの解 析という 3 つの手順からなる．まず，サッカーフィー ルドの準備では，サッカーサーバ [4] を起動する．手作 業で試合を実行する場合は，サッカーフィールドの状 態を目視確認できるように，サッカーモニタと呼ばれ る可視化ツールを起動し，サッカーサーバにネットワー ク接続する．次に，チームを構成する 11 体のプレイヤ とコーチの計 12 プロセスを起動する．プロセス起動の 際，各プレイヤとコーチはサッカーサーバへネットワー ク接続する．これを両サイドのチームに対して行う．全 プレイヤの接続を目視で確認し，サッカーサーバに指 令を送って試合を実行する．1 試合は 6,000 サイクル ＝ 10 分であるが，ゴールしたりボールがフィールド外 に出た時などに試合が一時中断するため，実際には 1 試合当たり必要な時間は 12 分程度である．また，サッ カーサーバの機能に，試合を高速化する Sync モードが 存在する．これにより，1 試合あたり 1 分程度で終了す ることができるが，チームバイナリが Sync モードに対 応している必要があるため，限られた条件でのみ高速 化ができる．人間の手作業の場合には，サッカーモニタ を通じてサッカーサーバにキックオフ指令を送る．試合 終了後，ログファイル解析ツールである LogAnalyzer3 [5] により試合結果を解析する．LogAnalyzer3 を起動 する際，サッカーサーバから出力されたログファイル が存在するディレクトリをコマンドライン引数で指定 する． しかし，これらは全て CUI 上での起動コマンドや シェルスクリプトの実行により起動されるため，単一 試合の実行や分析ごとにその都度人手による操作が必 要となる．また，上記の手順を手作業で行うと，サッ カーサーバの起動に 15 秒程度，両サイドのチームにお けるプレイヤとコーチの起動に少なくとも 30 秒程度， 試合実行に 12 分程度（Sync モード対応している場合 には 1 分程度），LogAnalyzer3 による解析に 15 秒程 度で，合計すると 1 試合に 13 分程度（Sync モード対 応している場合は 2 分程度）必要である．1,000 試合 の分析には 13,000 分（約 217 時間）となり，手作業 で大量の試合を解析することは現実には困難である．

3

性能評価システム

本論文では我々が提案する性能評価システムについ て説明する．図 3 に性能評価システムの概要を示す． 図に示すように，以下の手順で処理を行う． 1. 対話形式による試合設定選択 2. 計算機割り当て 3. 試合実行

4. 試合結果解析 5. 解析結果書き込み 本システムを用いて，従来人手で行われていた多く の工程を自動化することにより，性能評価にかかる労 力の大幅な削減が期待できる．

3.1

対話形式による試合設定選択

Slack bot [6] とは，チームコミュニケーションツー ルである Slack [7] 上で動作しコードの実行やタスクの 自動化に用いられる．ボットは 1 つまたは複数の API にアクセスできるボットユーザートークン経由でプロ グラム制御されている．本システムの UI に Slack bot を採用する利点として，PC やスマートフォン，タブ レット等，端末に関わらずマルチデバイスに対応可能 である点，複数人が同時に共通の手順で実行可能であ る点が挙げられる． 以下に，Slack bot との対話形式による試合要求手順 を示す．図 4 にボットとの対話画面の例を示す．はじ めに，性能評価を行いたいユーザが「game」と入力す ると，ボットとの対話が開始され，ボットは new また は load の選択肢を提示する．新たな試合設定で性能 評価を行いたい場合は new を選択する（load の場合 は後述）．次に，自チームで開発中の Git のブランチ の一覧から，ユーザは性能評価を行いたいブランチを 選択する．次に，性能評価を行う相手となる敵チーム の一覧から，ユーザは任意のチームを選択する．ここ で複数のチームを選択することも可能である．最後に， ユーザは試合数を入力する．試合数を入力後，これま で入力した試合設定の確認画面が表示されるため，内 容に相違なければ，ユーザが「ok」と入力することで 試合が即座に実行される． 試合が実行される際に，計算機の IP アドレス， OR-DER 番号が表示される．ここで， OROR-DER 番号とは， 実行中の各試合に割り当てられる番号である．これに より，複数の試合設定を並列で実行していても，各試合 を一意に識別することが可能となる．また，性能評価 終了後には，ボットがユーザに対して終了を通知する． 通知メッセージ中に ORDER 番号が記載されているた め，どの試合が終了したか一目瞭然となる．さらに，試 合設定を保存したい場合は，試合実行後に「save:任意 の名前.txt」と入力することで保存され，最初の選択肢 で load を選択すると，保存済みの試合設定で試合実行 が可能である．

3.2

計算機割り当て

本システムは，ボットの対話処理や計算機割り当て， 解析結果の書き込みを管理する 1 台のサーバ計算機と 試合実行や試合結果の解析を行う複数台のクライアン ト計算機から成るクライアントサーバ型のシステム構 成となっている．計算機割り当ては，監視と割り当て の 2 段階から構成される．まず，監視段階では，サー バ計算機がクライアント計算機リストから順に各クラ イアント計算機へアクセスし，CPU 使用率を確認する ことで，現在使用中か否かの判定を行う．そして，割 り当て段階では，判定の結果から，現在使用中でない 計算機へ接続を行う．これにより，試合実行タスクを クライアント計算機に対して適切に割り当てることが 可能となる．

3.3

試合実行

ボットがユーザから取得した試合設定 (自チームの Git ブランチ，敵チーム，試合数) を基に，クライアン ト計算機を割り当てる．割り当てられて計算機を使っ てサッカーサーバの起動，両チームのプレイヤとコー チを起動して試合を開始する．

3.4

試合結果解析

本システムでは，ログファイルを解析し，試合の分析 に必要な特徴量を抽出することができる LogAnalyzer3 [5] を用いる．LogAnalyzer3 は，ログファイルから試 合の勝敗，得失点数などといった試合の特徴を集計し CSV ファイル形式で出力する．このツールにより抽出 される特徴量は実際のサッカーにおけるデータ分析で も扱われているものである. 各計算機に割り当てられた試合の終了後，各試合の ログファイルを解析する．また，ログファイルの解析 は各クライアント計算機で行われ，解析結果をサーバ 計算機へ送信する．

3.5

解析結果書き込み

ログファイルの解析結果を複数の開発メンバで共有 するために，Google が提供する Web アプリケーショ ンである Google スプレッドシートを用いる．Google スプレッドシートは，Web 上で複数人による共有・編 集が可能な表計算アプリケーションという特徴を持つ ことから，本環境のような一箇所へ集約したデータに 対して複数人がアクセスする必要がある状況に適して いる．Google スプレッドシートに対してプログラムに よって読み書きを可能にする API である SheetsAPI [8] を用いて解析結果の書き込みを行った． LogAnalyzer3 によって解析され，クライアント計算 機から送信された解析結果を， SheetsAPI を用いて， あらかじめ開発メンバに共有設定をしておいた Google

スプレッドシートへ書き込みを行う．これにより，開 発メンバは結果を共有することが可能となる．図 5 に， Web 上の Google スプレッドシートに出力される解析 結果表示画面の例を示す．表の左の列から， ORDER 番号，選択した自チームのブランチ名，選択した敵チー ムとの試合結果（勝利数，敗北数，引き分け数，自チー ムにおける平均得点，敵チームにおける平均得点）を 示している．

4

おわりに

本論文では，我々が提案した RoboCup サッカーシ ミュレーション 2D における性能評価システムについ て説明した．本システムは，これまで開発フローにお いてボトルネックとなっていた性能評価を自動化する ことで，チーム開発効率の向上に貢献できる． 今後の課題として，現状では 1 つの試合設定に対し て， 1 台の計算機を割り当てているが， 1 つの試合設 定に対して複数台の計算機を割り当て並列で試合実行 を行うことにより，さらに効率的な性能評価が可能に なると考えられる．また，対話機能に人工知能技術を 適用したボットの機能拡充も考えられる．

参考文献

[1] Wil M. P. van der Aalst, Martin Bichler, Armin Heinzl,“Robotic Process Automation”, Business

and Information Systems Engineering, Vol. 60,

Issue 4, pp. 269-272, 2018. [2] 西野 順二, 長岡 俊男, 秋山 英久, “大規模マイク ロシミュレーションによるサッカー試合評価のた めのクラスタとその実装”, 第 40 回 人工知能学会 AI チャレンジ研究会 (SIG-Challenge) 予稿集, pp. 26-29, 2014.

[3] Hiroaki Kitano, Minoru Asada, Yasuo Kuniyoshi, Itsuki Noda, Eiichi Osawa, Hitoshi Matsubara, “ RoboCup: A Challenge Problem for AI ”,

AIMagazine, Vol. 18, No. 1, pp. 73-85, 1997.

[4] 秋山 英久, “ロボカップサッカー シミュレーショ ン 2D リーグ必勝ガイド”，秀和システム, 2006. [5] 福島 卓弥, 中島 智晴, 秋山 英久, “LogAnalyzer3 を用いたサッカー戦略分析” 第 35 回 ファジィ シス テム シンポジウム (FSS2019) 予稿集, pp. 26-30, 2019.

[6] Slack API | Slack https://api.slack.com 2020 年 2 月 29 日 閲覧. [7] Slack

https://slack.com 2020 年 2 月 29 日 閲覧.

[8] Sheets API | Google Developers

https://developers.google.com/sheets/api 2020 年 2 月 29 日 閲覧.

Slack bot

A

B

C

• branch A • opp123 • 100 • branch B • opp456 • 100 • branch C • opp135 • 100 ok! ok! ok! 終了通知 @A finish! 試合要求 @B finish! @C finish!

⑤解析結果書き込み

A

B

C

試合結果共有

①対話形式による

試合設定選択

サーバ

③試合実行

④試合結果解析

Slack bot

…

②計算機割り当て

ユーザ

Google スプレッドシート

LogAnalyzer3

クライアント

ログファイル ログファイル ログファイル

game

Git

ORDER

図 4: Example flow of a dialog between a user and the Slack bot.