RoboCupRescue Simulationにおける開発・実験を支援する環境の提案

(1)

RoboCupRescue Simulation

における

開発・実験を支援する環境の提案

Proposal of environment to support development and experiment

in RoboCupRescue Simulation

鷹見竣希

1∗

_{高柳和央}

1

_{伊藤暢浩}

2

_{岩田員典}

3

_{村瀬洋介}

4

_{内種岳詞}

5

Shunki Takami

1

_{, Kazuo Takayanagi}

1

_{, Nobuhiro Ito}

2

_,

Kazunori Iwata

3

_{, Yohsuke Murase}

4

_{, and Takeshi Uchitane}

5

1

_{愛知工業大学大学院経営情報科学研究科}

1

_{Graduate School of Business Administration and Computer Science,}

Aichi Institute of Technology

2

_{愛知工業大学情報科学部}

2

_{Department of Information Science, Aichi Institute of Technology}

3

_{愛知大学経営学部}

3

_{Department of Business Administration, Aichi University}

4

_{国立研究開発法人理化学研究所計算科学研究機構}

4

_{RIKEN Advanced Institute for Computational Science}

5

_{神戸大学経済経営研究所}

5

_{Research Institute for Economics and Business Administration, Kobe University}

Abstract: RoboCupRescue Simulation is provided as a testbed of multi-agent systems research for disaster relief. However, researchers have to implement a combination of a plurality of al-gorithms, and need a complicated experimental procedure for the experiment. These tasks are heavy burden for the researchers. Therefore, we propose an environment that integrates an agent development framework and an experiment management system in order to support researchers.

1 はじめに

近年の大規模な自然災害に対する様々な取り組みの 1 つに国際的な RoboCupRescue Simulation(以降，RRS) プロジェクトがある [1]．RRS は，災害救助エージェント及びシミュレーションを対象とした研究と，その成果による社会貢献を目指している．しかし RRS が対象とする災害救助問題の解決には，経路探索や情報共有, 資源割り当てアルゴリズムなど，複数のアルゴリズムを組み合わせた実装が求められる．また実験では火災，建物倒壊，通信など多様な条件を考慮しつつ，複数の被災地に対して膨大な回数のシミュレーションが必要であり，研究者への負担が大きい．そこで研究者を支援するため，エージェント開発フレームワークと実験管理システムを組み合わせた，開発と実験を統合して総合的に支援する環境を提案する． ∗_{連絡先：愛知工業大学大学院} 〒 470-0392 愛知県豊田市八草町八千草 1247 E-mail: [email protected] 提案した環境の有効性を，講習会において複数のエージェント開発者で開発範囲を分担して開発可能であることと，実験における負担を軽減できていることを確認した．

2 RRS

における研究・開発について

2.1 RRS の概要

RRS は都市直下型地震を対象に，被災地域と災害救助活動をコンピュータ上で再現し，災害発生から約 5 時間程度の災害救助活動を取り扱うことができる研究プラットフォームである．災害救助活動においては，消防隊・救急隊・ガレキ撤去隊と各部隊の司令部の 6 種類のエージェントを制御する．RRS におけるエージェントの活動内容を図 1 に示す．消防隊 (赤丸) は火災の消火，救急隊 (白丸) は自力で移動できない市民 (緑丸) の救出，ガレキ撤去隊 (青丸) は道路閉塞の啓開をおこ

(2)

Ĉȅइȅฅఆ ആ؉؉ആആȅ І̅؉ԅԉആȅ Ԇ؉Ԇąആȅ Ĉȅ ؉ȆЅฅఆ 図 1: RRS の主要エージェントなう．移動できる市民については，シミュレーション内で自力で避難所まで向かう． RRS を用いることで災害救助問題を応用とした人工知能や情報科学の研究が可能であり，災害環境下での経路探索や情報共有，タスク割り当てアルゴリズムなどの研究がおこなわれてきた．特に RRS プロジェクトでは Group Formation(グループ形成)，Path Planning(経路探索)，Search(情報探索)，Multi-Task Allocation(マルチタスク割り当て)，Communication(情報共有) の 5 つの課題が提唱されている．また毎年，技術交流を目的としてエージェントプログラムを用いた競技会が開催されている．

2.2 RRS におけるエージェント開発

RRS が取り扱う災害救助問題は複雑な複合問題である．災害救助問題では様々な被災地において，火災や建物倒壊，無線通信の可否などの被災状況が刻一刻と変化する．これを被災地によって異なる災害救助ロボットチームの災害救助戦略で解決する．災害救助戦略の実現においては，災害環境下での経路探索や情報共有，資源割り当てアルゴリズムなどを全て用意する必要がある．また図 1 にあるガレキ撤去隊による啓開活動などでは，啓開する方向やエージェントの位置を角度や座標により指定する必要がある． RRS を用いた研究を促進させるためには，複雑な災害救助問題の構造を解明し，問題を細分化して解決していくことが必要である．図 2: RT ミドルウェアの動作イメージ

2.3 RRS における実験

RRS ではエージェントの開発・評価にあたって，火災の発生場所や建物の倒壊率，通信状況など多様な条件を考慮し，複数の被災地を対象として実験をおこなう必要がある．またエージェント内のパラメータの設定をそれら各状況に対しておこなう場合がある．これらの実現には膨大な回数のシミュレーションが必要である. RRS では 1 回のシミュレーションに約 20 分程度の時間を要するため，複数の計算ホストで同時にシミュレーションを実行し，実験の効率化を図ることがある．また 1 つのシミュレーションにおいてエージェントの処理を複数の計算機に分散させることが多いため，複数の計算機を同時に制御する必要がある．

2.4

2.5 実験の実行を支援するツールについて

2.5.1 ジョブ管理システム

複数のジョブと計算機におけるジョブの実行を管理するシステムである．主なシステムの例として，NTT データ社の Hinemos[4] や，独 Software- und Organisations-Service 社の JobScheduler[5] がある．実験を各ジョブとして扱うことで実験の実行を自動化することができ，複数の計算ホストでの実行管理も可能である．また高度な実験のスケジューリングや GUI による実行管理などを実現することができる． 2.5.2 OACIS OACIS は理化学研究所計算科学研究機構の離散事象シミュレーション研究チームが開発しているシミュレーション実行管理フレームワークである [6]．先に挙げたジョブ管理システムの機能に加えて，シミュレーションに特化したジョブ管理機能や，実験結果の管理機能が実装されたシステムである．実験パラメータの管理や結果の自動管理機能により，多様な条件による膨大な数のシミュレーション及び分析を支援することが可能である．しかし OACIS は，様々なシミュレーションソフトウェアを対象とした汎用的なシステムであるため，シミュレーション実行時に複雑な操作が必要である RRS では，シミュレーションスクリプトの作成，またエージェントプログラムや地図・シナリオファイルを別に管理しなければならず，単純に使用することができない．

3 開発・実験を支援する環境の実現

3.1 本研究の目的

本研究では RRS におけるエージェント開発と実験の現状を踏まえて，災害救助問題における複雑な問題を解明・解決，およびプログラムコードを再利用しやすくするため，モジュール構造を導入したエージェント開発フレームワークの実装する．また実験における負担を減らすために，シミュレーション実行管理フレームワークである OACIS を導入した RRS 用の実験環境を実装する．これらエージェント管理フレームワークと RRS 用の実験環境を組み合わせ，エージェントの開発と実験を統合し総合的に支援する環境を提案する．

3.2 開発を支援する環境の提案

3.2.1 エージェント開発フレームワークの設計複雑な問題を多くの研究者で解明・解決するため，またプログラムコードの一部をモジュール化することで，コードの再利用をしやすくし研究者への負担を減らすために，エージェント開発フレームワークを開発する．フレームワークの設計にあたって 2.4 節の関連研究で挙げた OpenRTM-aist に基づいて設計する方法も考えられたが，RRS ではシーケンシャルな構造でエージェントがプログラミングされていることが多いため，既に存在するコードや知識を活用しやすいよう，RRS 独自のエージェント開発フレームワークを設計・提案する． 3.2.2 エージェントの共通アーキテクチャの導入エージェントの全体的な動作を共通アーキテクチャとして固定することで，開発者ごとに生まれるコンポーネントの組み合わせの差異を減らし再利用性を確保する．エージェントプログラムの開発時は，このエージェントの共通アーキテクチャの基にモジュールを実装する．図 3 に共通アーキテクチャの導入前と導入後のイメージ図を示す．図の左側が共通アーキテクチャの導入前を表しているが，これまでは各研究者が自身の研究内容に合わせて，エージェントプログラムを独自に構築していたため，プログラムの移植性が低かった．図の右側は共通アーキテクチャの導入後を表している．網掛け部のようにエージェントのプログラム構造を共通化し，プログラムコードを容易に移植できるようにする．またエージェント間通信プロトコルを統一し，他の開発者が開発したエージェントとも通信を可能にする． 3.2.3 プログラムコードのモジュール化エージェント開発において用いるプログラムコードを細分化，また再利用できるようにし，開発における負担を減らすため，2.4.1 項で挙げた RT ミドルウェアでも実現されているコンポーネントのモジュール化を導入し，エージェント開発における研究者への負担を軽減する． • アルゴリズムのモジュール化 アルゴリズムモジュールの分割にあたって現段階では，RRS プロジェクトで提示されている 5 つの課題を基準にできるかぎり分割した．図 4 に課題とモジュールの割り当てを示す．図の左側が 5 つの課題で右側がフレームワークのモジュールである．また複合的な問題を解くアルゴリズムと，単純な問題を解くアルゴリズムをそれぞれ

(4)

図 3: 共通アーキテクチャの導入前と導入後

図 4: RRS における課題と ADF のモジュール

Complex Modules， Algorithm Modules として分類し，どのようにプログラムを書くべきなのかを明確化した．複合的な問題を解くアルゴリズム (Complex Modules) は単純な問題の集合体であると考え，できるだけプログラム内部の構造を分割して構成すべきである．また今後プログラムを分割できると経験的に判明した場合は，新たなコンポーネントとして切り出すことにより複雑な問題の解明を目指す． • 制御プログラムのモジュール化 2.2 節で述べたように，RRS では座標や角度などを指定してエージェントを制御する必要がある．このような低レベルの制御については，制御プログラムとしてモジュール化する．意思決定のようなマクロなアルゴリズムと座標や角度を用いた制御のようなミクロなアルゴリズムを分離することで，意思決定のようなアルゴリズムを研究したい研究者への負担を軽減する． 3.2.4 その他共通アーキテクチャの導入により，エージェン間通信プロトコルとパラメータの一括管理が可能になった．ここではこれらについて述べる． • エージェント間通信プロトコルの統一 RRS ではエージェント間通信のプロトコルが統一されていない．エージェント間の通信プロトコルが統一されていない場合コンポーネント間の依存関係が強くなり，アルゴリズムのモジュール化が難しい．そこで太田ら [7] や尾橋ら [8] によって提案された RRS におけるエージェント間通信プロトコルを参考にすべてのエージェントが共通で利用する通信プロトコルを策定する．このプロトコルのもとで通信するメッセージを情報共有系

(5)

図 5: フレームワークの構造と命令系として定義する．情報共有系では各エージェント，道路，建物について取り扱う．命令系では救助，消火，啓開，偵察について取り扱う． • パラメータの一括管理 使用するモジュールの指定や実験時に書き換えたいアルゴリズム内の固有値をフレームワークで一括管理することにより，パラメータの入力インタフェースを共通化し，2.5 節で挙げた実験を支援するツールからのパラメータの入力を容易にする．

3.3 エージェント開発フレームワークの実装

3.3.1 フレームワークの実装今回実装したエージェント開発フレームワークの構造のイメージを図 5 に示す．図 5 の網掛け部である Agent 内がフレームワークの実装である．また点線で示した部分がモジュールであり，エージェント開発時にプログラミングする対象となる．本節ではフレームワーク内部のそれぞれの実装について 3.2 節の設計に基づいて述べる． 3.3.2 エージェントの共通アーキテクチャエージェントがどのようにアルゴリズムモジュールや制御プログラムモジュールを呼び出して行動を決定するか定めるコンポーネントである．このクラスを Tactics と呼ぶ．各エージェントは Tactics に記述した基礎とな図 6: モジュール群の読み込みるエージェントのアーキテクチャから，タスク割り当てや経路探索アルゴリズム，制御プログラムモジュールなどを呼び出して行動を決定する．また呼び出すモジュールはモジュールの共通名で Tactics 内に記述することで，エージェントの設定ファイルから実際に使うモジュールと紐付けることが可能である． 3.3.3 モジュール群 3.2.3 項の設計で示した図 4 のようにグループ形成を Clustering，経路探索を PathPlanning，情報探索とタスク割り当てを TargetDetector としてモジュール化した．また制御プログラムは ExtAction として同様にモジュール化した．これらモジュールの Tactics への読み込みについて図 6 に示す．図右側に示したモジュールのインスタンスは，図上部に示す ModuleManager と呼ぶクラスで生成・管理する．またエージェント起動時にモジュールの設定ファイル (module.cfg) を読み込むことで，使用するモジュールを切替可能にする． 3.3.4 パラメータの一括管理読み込むモジュールの設定は前述の module.cfg から読み込む．またアルゴリズム内で使用する固有値は DevelopData クラスから取得できるようにし，各値はエージェント起動時の引数として JSON で入力可能にした．

3.4 実験を支援する環境の提案

RRS における実験を支援する環境を実現するにあたり，シミュレーション実行管理フレームワークである OACIS による実験管理を導入する．図 7 に OACIS による実験管理の導入前と導入後のイメージ図を示す．図の左側が OACIS による実験管理の導入前，右側が導入後を表している．RRS でエージェ

(6)

図 7: OACIS による実験管理の導入前と導入後ントの実験をするには，図内青丸で示すように，各種エージェントのパラメータの指定や，シミュレーションを実行する計算機クラスタの制御，膨大な結果の収集や管理などの操作をおこなう必要があった．OACIS による実験管理の導入により，図内網掛けで示した部分の作業が自動化され，実験でおこなう操作を減らすことができる．また実験における操作の大半を自動化できることにより，実験の再現も容易におこなえるようになる．しかし OACIS は汎用的なシステムであるため RRS の実験へ適用するには足らない機能が存在する．そこで OACIS を RRS の実験へ適用する際に補助すべき機能を RRS 用の拡張として開発する．本節では補助すべき機能について述べる． • エージェント管理 OACIS でシミュレータや実験パラメータの管理は可能であるが，エージェントプログラム自体の管理はできない．そこでエージェントプログラムを管理する拡張を用意する． • 地図・災害シナリオ管理 エージェントプログラムと同様に OACIS では地図・災害シナリオの管理ができないため，地図・災害シナリオを管理する拡張を用意する． • 計算機クラスタ管理 RRS では複数の計算機を組み合わせた計算機クラスタで 1 つのシミュレーションをおこなう．しかし OACIS には計算機クラスタを制御する仕組みがない．そこで計算機クラスタの管理をできる仕組みを導入する． • シミュレーションスクリプト OACIS から呼び出し，シミュレーションにおける一連の動作を記述したスクリプトを用意する必要がある．この中で実際にエージェントや地図・災害シナリオを読み込み，計算機クラスタの各計算機へ接続しシミュレーションを実行する．これにより実験を 1 つのジョブとして扱えるようにする． • シミュレータ管理 OACIS ではシミュレーションスクリプトと，指定できるパラメータ群のセットをシミュレータと呼ぶ．しかしパラメータは，使用するエージェントや使用するモジュール，アルゴリズムの固有値など実験の目的により変化する．そこで様々なシチュエーションに応じてシミュレータを OACIS に登録できる仕組みを導入する．

3.5 RRS のための OACIS の拡張

拡張の実装にあたり，保守性を保つため OACIS 本体のプログラムには手を加えず，OACIS が提供する API を通じて拡張部から OACIS の制御をおこなう．拡張後のイメージ図を図 8 に示す．青色で示した部分が RRS のための拡張である．この部分について次に述べる． • エージェント管理 エージェントプログラム本体を拡張部管理下のディレクトリにアップロードできるようにし，拡張部のデータベースにエージェントの名前と位

(7)

Scenario Management

Computer Cluster Management RRS Experiment Management System

OACIS Design of experiments Simulation Script Simulator(OACIS) Management Agent Management Computer Clusters Job&Results Management Automatic result evaluation Host Management Simulator Management Upload Agent & Scenario

[Retry] Monitoring API RRS Simulation RRS Simulation 図 8: RRS のための OACIS の拡張置，使用するパラメータ，コメント，登録日時を登録・管理する．これによりエージェントファイルの管理も統合的におこなうことを実現する． • 地図・災害シナリオ管理 エージェントプログラムと同様に地図・災害シナリオを拡張部管理下のディレクトリにアップロードできるようにし，拡張部のデータベースに名前と位置，コメント，登録日時を登録・管理する． • 計算機クラスタ管理 計算機クラスタの情報を拡張部のデータベースで管理する．シミュレーション実行の際は，ローカルホストのシミュレーションスクリプトを呼び出し，そこから各計算機を用いてシミュレーションをおこなう．シミュレーションスクリプト内での計算機クラスタの切り替えは，作業ディレクトリを換えて OACIS に計算ホストとして登録することで実現する．シミュレーションスクリプトは各作業ディレクトリに配置した，計算機クラスタの設定ファイルを読み込むことでそれぞれ指定された計算機に接続する．これにより計算機クラスタを用いたシミュレーションの実行を実現する． • シミュレーションスクリプト SSH を用いて各計算機にシミュレーションに用いるエージェントプログラムや地図・災害シナリオを転送し，エージェントのコンパイルスクリプトを実行した後，シミュレーションを開始する．シミュレーションの開始において必要な起動タイミングの制御もおこなう．スクリプトが正常に終了した場合は終了コード 0 を出力し，異常終了した場合は 0 以外の終了コードを出力することで， OACIS で正常終了を判断できるようにする．これにより OACIS を用いた計算機クラスタを用いた RRS の実行を実現する． • シミュレータ管理 データベースに登録したエージェントや地図・災害シナリオを元に OACIS にシミュレータとして登録する．パラメータのパターンは各種類のエージェントにおいて以下のパターンで登録できるようにする．含まれない値については固定値としてシミュレータを登録する． – エージェントプログラム – エージェントプログラム+各種モジュール – アルゴリズムの固有値 これにより実験の目的に応じたパラメータを持つシミュレータの作成を実現する．

4 実験と評価

4.1 評価の目的

3 章で提案した開発・実験を支援する環境において，実際に複数のエージェント開発者でエージェントプログラムを開発・実験し，コードの再利用性が確保できているか，実験における負担が軽減しているかについての評価および考察する．これにより提案した環境においてプログラミング思想が異なる複数のエージェント開発者で開発範囲を分担して開発可能であるか，実験における開発者への負担を軽減できているかを確認する．

4.2 実験について

2016 年 10 月 22-23 日に福岡大学において開催された RoboCup Simulation リーグの講習会で，約 30 人を 6 チームに分けてそれぞれエージェントの開発をおこなった．そこでチームが異なるエージェント開発者が開発したエージェントを組み合わせてもエージェントが連携して活動できるか，各チームで開発したエージェント群の救急隊，消防隊，ガレキ撤去隊をそれぞれ他チームのものと組み合わせる実験をした．講習会においては時間の都合で 6 種類の組み合わせで実験したが，後日，全 216 の組み合わせで実験をおこなった．

(8)

表 1: 成績上位 8 位までの組み合わせ順位救急隊消防隊ガレキ撤去隊 Score 1 A C A 143.4091 2 A B A 141.4178 3 E B A 140.9280 4 A B F 136.5078 5 E B B 134.8257 6 B B D 134.3782 7 C B D 134.3404 8 B B E 133.8126

Sample Sample Sample 114.2580

A A A 114.2574 B B B 126.5861 参考 C C C 124.3933 D D D 114.2580 E E E 119.9167 F F F 120.8222

4.3 実験結果と考察

各チーム (A–F) 組み合わせた実験の成績上位 8 位までの結果と，参考値として Sample と各チームごとの結果を表 1 に示す．実験の結果から特に同じチームだから結果が良くなるというわけでは無いということがわかる．このことから今回提案したフレームワーク上で開発したエージェントであれば，別々に組み合わせても連携して活動できることがわかった．これによりコードに再利用性があることを確認できた．また実験の実行においては，講習会の様な場で実験的にシミュレーションする場合には，基本的に 1 人のオペレータが直接シミュレータを操作し，シミュレーション結果の管理などをおこなう．この際操作する手数が多いため，誤って結果を保管し忘れてしまう場合もあった．しかし今回は複数のオペレータが操作に携わったが，操作する内容が単純であるため，また多くが自動化されているためトラブルはおこらなかった．このことから実験時の研究者への負担を軽減できていることがわかる．

5 まとめ

本研究では，RRS を利用する研究者を支援するため，エージェント開発フレームワークと実験管理システムを組み合わせた，開発と実験を統合し研究者を総合的に支援する環境を提案した．評価では複数のエージェント開発者で開発範囲を分担して開発可能であり，コードの再利用性を確保できていること，実験における負担を軽減できていることを確認できた．今後は 3.2.3 項で述べたように，複合的な問題を解くアルゴリズム (Complex Modules) は単純な問題の集合体であると考え，切り出せる問題は新たなコンポーネントとして切り出し複雑な問題の解明を目指す必要がある．

参考文献

[1] “RoboCupRescue Simulation”, http://roborescue.sourceforge.net/ [2] 産業技術総合研究所, “OpenRTM-aist” http://www.openrtm.org/

[3] Noriaki ANDO, Takashi SUEHIRO, Kosei KITA-GAKI, Tetsuo KOTOKU, Woo-Keun Yoon, “RT-Middleware: Distributed Component Middleware for RT (Robot Technology)”, IROS2005, (2005) [4] 株式会社NTTデータ, “Hinemos”

https://ja.osdn.net/projects/hinemos/

[5] Software- und Organisations-Service,“JobScheduler” http://www.sos-berlin.com/jobscheduler

[6] Yohsuke Murase, Takeshi Uchitane, Nobuyasu Ito, “A tool for parameter-space explorations”, Physics Procedia, 57, p73-76, (2014)

[7] Takefumi Ohta, Fujio Toriumi, “RoboCupRes-cue2011 Rescue Simulation League Team Descrip-tion”, RoboCup 2011 Istanbul, (2011)

[8] Dai Obashi, Toshiyuki Hayashi, Kazunori Iwata, Nobuhiro Ito, “An implementation of communication library among heterogenous agents NAITO-Rescue 2013(Japan)”, RoboCup 2013 Eindhoven, (2013)

RoboCupRescue Simulationにおける開発・実験を支援する環境の提案