RoboCup Rescue Simulation 秋キャンプ2008 講習会 名古屋大学大学院 情報科学研究科修士課程２年 <SUNTORI> 原　大曜

はじめるまえに ロボカップレスキューとは何か知っている 動かしたことがある（見たことがある） エージェント開発したことがある 大会に参加したことがある 世界大会で優勝したことがある

ロボカップレスキュー 目的：自律ロボットによる災害救助活動 災害時におけるあらゆる事象をシミュレーション 役割の異なる自律エージェントによる救助活動 　救急隊 ：市民の救助 　自衛隊 ：道路の閉塞の解消 　消防隊 ：火災の消火 　市民 ：救助対象

デモしますか？ 経過時刻（1~300分） スコア 時間と共に減点 自衛隊 市民 消防隊 救急隊 死亡者 閉塞 避難所 火災

シミュレータの構成 カーネル ここを開発！ 消防隊 啓開隊 救急隊 市民 災害シミュレータ群 地図情報（ＧＩＳ） VIEWER 火災 シミュレータ 災害シミュレータ群 地図情報（ＧＩＳ） VIEWER カーネル 市民 ここを開発！ 消防隊 啓開隊 救急隊

救助エージェントの役割 消防隊 Fire Brigade 消防センター Fire Station 救急隊 救急センター 啓開隊 Ambulance Team 救急センター Ambulance Center 啓開隊 Police Force 啓開センター Police Office

消防隊エージェント 火事になっている建物に放水し、鎮火 放水可能距離は３０ｍ 給水タンクは有限⇒空になったら避難所で補給 消防隊 Fire Brigade 消防センター Fire Station 火事になっている建物に放水し、鎮火 放水可能距離は３０ｍ 給水タンクは有限⇒空になったら避難所で補給

救急隊エージェント ガレキに埋もれている市民の救出 負傷した市民の避難所への運搬 救助エージェントが救出対象になることも 救急隊 Ambulance Team 救急センター Ambulance Center ガレキに埋もれている市民の救出 負傷した市民の避難所への運搬 救助エージェントが救出対象になることも

啓開隊エージェント 道路のガレキ⇒エージェントが通行できない ガレキの撤去 啓開隊 Police Force 啓開センター Police Office 道路のガレキ⇒エージェントが通行できない ガレキの撤去

環境構築 ～必要な物～ Unix系OS Java 5.0 以降 サーバプログラム エージェントプログラム 近年はUbuntuが主流 環境構築　～必要な物～ Unix系OS 近年はUbuntuが主流 Linuxなら問題ないはず Java 5.0 以降 サーバプログラム 0.49.10が最新（あるいは0.50.0) エージェントプログラム rescuecore

環境構築 ～パッケージ～ rescue-0.50.0.tgzを解凍 tar xvzf rescue-0.50.0.tgz 環境構築　～パッケージ～ rescue-0.50.0.tgzを解凍 tar xvzf rescue-0.50.0.tgz （サーバのディレクトリができる） svn の環境があれば以下のコマンドでも可 > svn co https://roborescue.svn.sourceforge.net/ svnroot/roborescue/releases/0.50.x/0.50.0 0.50.0でいいのか確認

環境構築 ～コンパイル、サーバ起動～ コンパイル サーバ起動 cd サーバのディレクトリ/programs make cd boot 環境構築　～コンパイル、サーバ起動～ コンパイル cd サーバのディレクトリ/programs make サーバ起動 cd boot ./all.sh Map Team　または　./all2.sh Map Team 例）./all.sh Kobe Sample-NAITO

エージェントのコンパイル、サーバ接続 Sample-NAITO.tgzを解凍 コンパイル 実行 tar xvzf Sample-NAITO.tgz （Sample-NAITOディレクト リが出来る） コンパイル cd Sample-NAITO make 実行 ./run.sh FB FS AT AC PF PO (host (port)) 例）./run.sh 10 1 6 1 8 1 10.10.10.1 例2) ./run.sh - - - - - - 10.10.10.1 (“-”は数の指定をしない） NAITOの中身チェック

ルール ロボカップ2008 は以下の通り http://www.robocuprescue.org/wiki/images/ Rules2008-draft.pdf 前年度までとの差分は以下の通り Communicationlessなマップの追加 Say(チャンネル0番)の通信回数カウントが独立 事前放水の効果の上昇 火災の熱交換比率が上昇 翻訳したバージョンも作っておく？

世界大会について メーリングリストに告知が流れる クオリフィケーションの話 レスキューシミュレーション メーリングリスト登録 シミュレーション（サッカー＆レスキュー）　　 https://lists.cc.gatech.edu/mailman/listinfo/robocup-sim レスキューシミュレーション https://lists.cc.gatech.edu/mailman/listinfo/robocup-rescue-s クオリフィケーションの話 世界大会では参加資格を得るための審査がある Team Description Paper（チームの説明）を提出 学術的な内容が無ければ通過しない

エージェント開発 サンプルエージェント Sample-NAITO rescuecore 通信仕様の話 Tell Say

Sample-NAITO Sample-NAITO/ doc/ ・・・ htmlドキュメント src/ yab/　・・・ 入出力やオブジェクト定義のソース classes/　・・・ classファイルをまとめる場所

課題 Sample-NAITOの消防隊（ FireBrigadeAgent.java）の戦略を変更して，火 災を効率よく消火できるようにせよ！ 成果発表は明日の９時００分～ こちらが用意したマップで各自作成した消防隊同士で 競ってもらう

Sample-NAITO/src/sample_naito/ FireBrigadeAgent.java ・・・このプログラムを改善 FireStationAgent.java ・・・このプログラムを改善 AmbulanceTeamAgent.java AmbulanceCenterAgent.java PoliceForceAgent.java PoliceOfficeAgent.java CivilianAgent.java ・・・使用せず

戦略の例 火災の大きさによって 消火にあたる消防隊の数を変える 全ての消防隊が一つの火災に集中する 初期消火を優先的におこなう 　　　　　　　　　　　　　　　　　　　　　　　　...etc

開発のノウハウ 基礎 独自性 仕様の理解（サンプルの理解） 過去のチームの分析 救助活動の優先順位 協調行動の実現 ルールに載ってないことが盛りだくさん 過去のチームの分析 独自性 救助活動の優先順位 協調行動の実現

通信の仕様 消防隊と消防センター N:1 チャンネル番号 １～９を割り当てて通信

通信の仕様 チャンネル１ チャンネル２ １ステップ中の受信制限 エージェントは４ センターは同種エージェント数*2

通信の仕様 補足 ０番はSAY（声）用のチャンネル １エージェントが複数チャンネル使用可 １メッセージは256byteまで ３０ｍ以内で可聴 通信の仕様　補足 ０番はSAY（声）用のチャンネル ３０ｍ以内で可聴 受信数を多チャンネルと独立してカウント 市民エージェントの声を聞け １エージェントが複数チャンネル使用可 １メッセージは256byteまで ただし実質は236byte

メジャーな戦術・戦略紹介 消防隊 救急隊 通信関係 Fire Site 消火時の配置 市民の体力予測 救助の最適化 ビット構造 センターレス、コミュニケーションレスの対策

Fire Site

Fire Site 壁間の距離から火災が伝播しやすい区域 (Fire Site)を想定 消火にFire Siteの性質を反映させる MRL2007以来大流行中 SUNTORI もパクってます

消防隊の配置 良い放水位置 悪い放水位置 建物の中である（避難所やセンターだと尚良し） 次の消火活動がすぐ行える 小刻みに再移動する時間はとても無駄 他のエージェントと衝突しない 放水位置の決定は他の消防隊も考慮する 通信で位置を確認しても良い 悪い放水位置 他の消防隊エージェントが消火できない クリティカルな道路をふさいでいる

消防隊の配置 道路からの放水は渋滞の原因 建物内の市民の状況を把握できる 火傷しても給水時に回復 建物内からの消火を勧める３つの理由 ちなみに 避難所とセンターは消防隊が同時に侵入可

体力の予測 エージェントのパラメータは丸めた値で観測 ダメージ量は時間と共に増加 その比率は一定ではない ２つのアプローチ 1115⇒1000 , 2899⇒4000 ダメージ量は時間と共に増加 その比率は一定ではない ２つのアプローチ 統計的な予測法 関数的な予測法

統計を用意し、予測対象のHPの推移と比較 統計的な予測 最近某決定則(Nearest Neighbor) 結末は「1~300で死亡」か「生存」=301通り ID step0 step1 … step300 死亡時刻 1 10000 9000 10 2 3000 280 3 5000 生存 統計を用意し、予測対象のHPの推移と比較 最も近いパターンを信用

関数的な予測 ZJUBase 2008の場合 各パラメータは１ステップ前の値に依存する 各パラメータの真の値を近似的に求める ⇒未来のパラメータを推定

どっちがいいか お好みで。 統計的な予測 関数的アプローチ 十分なデータ量があれば強い 火災に巻き込まれたときなど不測の事態に弱い どこまで真の値に近づけるかが鍵 ZJUBaseによると、ほとんどの場合誤差5%以内で 正解を出せるらしい お好みで。

救助スケジューリング どの市民をどのATがどの順番で助けるか 動的計画法で最適解を得ることが可能 統一されたプランに従う必要⇒通信で連携 市民の発見や、道路状況の変化があれば そのつど再計算 強いチームの多くが採用、ほとんど最強。 ただし、 Communicationlessには弱い

通信の改善 236byteでいかに情報を詰め込むか メッセージ制限を超えても良いような設計 文字列＜byte列＜bit列 オブジェクトIdはソートして indexを使うとデータ量が削減可能 メッセージ制限を超えても良いような設計 届いた分だけでも理解可能なように

Centerless センター無し（通信は可能） 一部のセンターがない場合 全部のセンターがない場合 他のセンターが可能な範囲で負担 センター代わりのリーダーエージェント FireStation×2 , AmbulanceCenter×1, PoliceOffice×0 なんて場合も。 全部のセンターがない場合 それでも通信するとしないとでは雲泥の差

Communicationless 今年度から追加：SAY以外の通信が不可 ZJUBase 2008 SUNTORI 2008 Ri-one 2008 情報をセンターが管理し エージェントが可聴範囲まで近づいてsayで伝達

最後に 様々なMapで試すことが大事 チームを越えて手を組もう 大会で使用されたMapは公開されている 特殊なMapは意外と多い 救助エージェントが埋もれている 避難所が遠い 市民のほとんどが火災のすぐそばにいる Etc チームを越えて手を組もう 中国やイランは連携している。ぜひ日本も。