2016-03-14 (月) 14:51:38 (rcssserver3d-0.5.1)
2006-03-09 (木) 19:15:35 (rcssserver3d-0.5)

TEXT_INSTEAD_OF_A_MANUAL.txt

rcssserver3Dは、物理的な環境においてサッカーをプレイするシミュレーショ ンロボットをプログラミングするためのプラットフォームを提供する。

内容


  • 1. システム概観
    • 1.1 サーバ
    • 1.2 モニタ
  • 2. サッカーシミュレーション
    • 2.1 サッカーチーム
    • 2.2 環境
    • 2.3 プレイヤ
      • 2.3.1 Create Effector
      • 2.3.2 Init Effector
      • 2.3.3 Beam Effector
      • 2.3.4 Drive Effector
      • 2.3.5 Kick Effector
      • 2.3.6 Catch Effector
      • 2.3.7 Say Effector
      • 2.3.8 PanTilt Effector
      • 2.3.9 Vision Perceptor
      • 2.3.10 GameState Perceptor
      • 2.3.11 AgentState Perceptor
      • 2.3.12 Hear Perceptor
  • 3. モニタとトレーナのプロトコル
  • 4. 参考文献

1. システム概観


まず初めにシステムの構成要素についていくぶん熟知すべきである。サッカ ーシミュレーションは3つの重要な部分(サーバ,モニタ,エージェント)に よって構成される。

1.1 サーバ


サーバを稼動させるには、SPADESミドルウェア[1]について熟知すべきで ある。知っておくべきいくつかの重要な概念:エージェントのプロセスは サーバによって開始される、すなわち、2Dシミュレーションのようにサーバが エージェントの接続を待つことは無い。SPADESライブラリは異なるエージェント タイプの起動方法の情報を含むデータベースを使用する。これは 'agentdb.xml'というファイルで、./app/simulator/ ディレクトリにある。

エージェントはUNIXパイプによってSPADES Commserverと接続する。The use a length prefixed format to exchange messages.(意味不明…)Commserverは 順番にサーバと通信する。サッカーサーバのデフォルトの構成では、統合され たCommserverが起動される。

複数のCommserverを使用してエージェントプロセスを分散実行させることが 可能である。リモートのCommserverの開始と設定の方法についての詳細は SPADESのマニュアルを参照してもらいたい。この構成の場合、シミュレーション 開始前に全てのCommserverが接続するまで待機するように3Dサーバを設定しな ければならない。関連する設定はサーバのスタートスクリプトである rcssserver3D.rb に記述されている。

これらの設定は 'Spades.RunIntegratedCommserver' と 'Spades.CommServersWanted' である。RunIntegratedCommserverは統合 Commserverが開始されるかどうかを変更する。デフォルトの値は'true'である。 CommServersWantedはシミュレーションを最初に開始する前にサーバが待ち受けるCommserverの数を与える。統合Commserverもカウントされるので、デフ ォルトの値は1である。

1.2 モニタ


デフォルトのモニタは'rcssmonitor3D-lite'と呼ばれ、 ./app/rcssmonitor3d/lite ディレクトリに置かれている。このモニタはサーバが 自動生成するログファイルの再生にも使われる(--logfile <filename>の オプションを使用)。自動生成されるログファイルは 'monitor.log' と呼ば れ、サーバを起動したディレクトリ直下の 'Logfiles/' ディレクトリ内で見 つけることができるだろう。RoboCup2004のログファイルが[2]から得られる。

実装されたモニタプロトコルはトレーナを実装するためのコマンドセットをサ ポートする、すなわち、テストのためにフィールド上の状況を自動的に再生成 することやエージェントの行動を評価することが可能になる。'モニタライブ ラリ'はカスタムモニタやトレーナアプリケーションの実装を補助するために 提供される。./app/rcssmonitor3d/lib ディレクトリを参照してもらいたい。 サーバとモニタ間のプロトコルについては、このテキストで詳細に述べられる。

独自のエージェントを実装する場合、./app/agenttest/ ディレクト リにある'agenttest'プログラムから始めるのが良いだろう。このエージェン トには単純なkickとrunの行動が実装されている。

シミュレータのマニュアルが存在しないため、シミュレートされるロボットの 特性の記述を以下で試みる。

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


2.1 サッカーチーム


サッカーチームは同一の性能を持つ多くのロボットによって構成される。チ ームを作成するために書くべきプログラムは、(仮想的な)低レベル制御シス テムでロボットとデータを交換する。ロボットの知覚受容器とエ フェクタは、いずれもS式を使用する。これは既に2Dシミュレータで使用され ているシンタックスであり、あるいは、あなたの好みのプログラミング言語で あるかもしれない :)

2.2 環境


環境とロボットに関するいくつかの技術的データ:

フィールドはFIFAの標準的なサッカーフィールドサイズ(長さ100〜110m, 幅64〜75m)の平面である。ゴールボックスとボールもFIFAの標準サイズである: ゴールの幅は7.32m、ボールは直径0.222mで重さは0.41〜0.45kgである。 ただし、エージェントは小さく、ジャンプもできないため、ゴールの高さは0.5m しかない(公式なFIFA規定の高さは2.44m)。

FIFAは重力についてあまり言及していない(恐らく、どうやっても変えられな いから)。しかし、我々のシミュレーションでは、重力を9.81m/s^2に固定する。

シミュレーションステップの長さは0.01秒である。接続されたモニタは15シミュ レーションステップごとに更新情報を受信する。

このテキストに含まれる値の多くは変更されるかもしれない。そのため、この テキストが必ずしも現状を反映するとは限らない。起動時にサーバが実行する 設定スクリプト内で現在の設定の定数セットを見つけられるだろう。 ./app/simulator/rcssserver3D.rb を参照してもらいたい。サーバを初めて実 行した後、このファイルはあなたのホームディレクトリの ~/.rcssserver3d/ にコピーされ、以後の実行時にそこから読み込まれるようになる。実験用の変 更は全てそこで行われるべきである。

2.3 プレイヤ


現在のバージョンのシミュレータでは、ロボットは球体である(来年にはより 洗練された形状にできるだろう)。全てのロボットは、直径0.44m、重さ75kg である。

ロボットは一種の全方位移動機能を持ち、ロボットの体に物理的な力を加える ことができる。全方位移動機能を使用することで、任意の方向への加速が可能 となり、ほんのわずかながらジャンプすることも可能である。ただし、 ロボットが実際にサッカーフィールドに接触している場合にのみ、全方位移動 機能は機能する。加速を止めてもロボットは少しの間動き続ける。そして、最 大スピードで動いているときに急停止することも出来ない(ブレーキ のためには使える)。ジャンプのための最大スピードと最大高さはまだ発見さ れていない。

プレイヤが最初にサーバへ接続するとき、起動のために二つのことを行わなけ ればならない。まず、試合中に使用したいロボットのタイプを生成しなければ ならない。現在は、上記のようにロボットを球体に限定している。今後はより 洗練されたロボットモデルが利用可能になるだろう。この処理はcreate effector が行い、起動時に一つのロボットを選択・作成する。更に、プレイ ヤは背番号を受信し、チームに参加しなければならない。この処理は init effector が行う。

2.3.1 Create effector


シミュレータに最初に接続したとき、エージェントは物理的な形状を何も持っ ていない。エージェントが持っている唯一のものは "CreateEffector" である。 CreatEffectorのアイデアは、異なるエフェクタ,感覚器またはロボットタイ プを要求できるということである。現在は、唯一の固定されたロボットタイプ しか存在しないため、CreateEffectorは全てのパラメータを無視する。今のと ころ、開始時に "(create)" を単に実行すれば良く、これによってデフォルト のロボットタイプを得られるだろう。

コマンド例: (create)

2.3.2 Init Effector


チーム名と背番号をセットするためには、InitEffectorを使用しなければなら ない。初期化を行わなければ、effectorとperceptorは正しく働かないだろう。

(init (unum <number>) (teamname <string>))

コマンド例: (init (unum 7) (teamname RoboLog))

2.3.3 Beam Effector


kickeffectorと同様に、エージェントが別の位置へ瞬間移動(beaming)するよ うな人工的な行動(2Dサッカーサーバの"move"コマンドに相当)は導入しない ことが最初の計画であった。今でも、瞬間移動はeffectorセットから消えるか もしれないようにサッカーシミュレーションを開発することが計画されている。

しかしながら、キックオフ前にエージェントが自陣内へ移動する場合において、 制限時間経過後の結果によって何らかの処置を行わなければならないことが問 題となった。瞬間移動を取り除くためには、適切な行動を取っていないプレイ ヤに対してイエローまたはレッドカードを与えられるように、(あなたの助け によって :) )審判を拡張しなければならない。我々は近いうちにこの機能を実 現するつもりである。そのときまで、'beforekickoff'モードでのエージェント の瞬間移動が許可される

beam effectorは3つの座標値を期待する。しかし、現在、第三要素は強制的に 0になる。すなわち、エージェントは水平面状の位置にのみ移動が許される。

(beam <x> <y> <z>)

コマンド例: (beam  -6.6 0 0)

2.3.4 Drive Effector


エージェントの全方位移動機能を使用するには、"DriveEffector"を使用しな ければならない。エフェクタは入力として100単位の最大長を持つデカルト座 標系のベクトル(x y z)を取る。x座標はフィールドの敵陣方向、zは上方向で ある。DriveEffectorを使用すると、一種のモータ力をセットすることになる。 すなわち、暫らくの間最大スピードで走りたければ、DriveEffectorを使用す るのは*一度*だけ充分である。セットされた力は、それが再び変更されるまで、 各シミュレータサイクルで適用される。DriveEffectorの動作は信頼できるも のであるが、各軸に沿った力に対して小さな誤差が発生する(適用された力の 各2%以内)。誤差は0.0周辺の正規分布である。

全方位移動の使用はバッテリを消費する。AgentStatePerceptorを読み取るこ とでバッテリの状態を知ることができる。バッテリが空であれば、全方位移動 機能は稼動しなくなる。他のロボットを押すことも可能である。敵を押すため にこの特性を使用することには反対します :)

(drive <x> <y> <z>)

コマンド例: (drive 20.0 50.0 0.0)

2.3.5 Kick Effector


ボールを移動させるためには、ロボット自身によって単純にボールを望む方向 へと押すか、または、ボールを蹴るための kickeffector を使うことができる。最初は、人工的な kickeffector を作成することを意図 していなかった。しかしながら、3次元を利用するためには、これがもっとも 容易な方法であった。現実的な物理デバイスのために、将来のバージョンでは (2004年の競技は含まない)、この種のキックエフェクタは取り除かれること が予定されている。

kickeffectorは、ロボットの体から遠ざかる方向へ放射状にボールを加速する ことができる。kickeffectorの第一引数は角度である。これは、ボールを加速 するための仰角の角度(単位は度数)である。値は0から50に制限されている。 第二引数はキックのパワーを示す。値の範囲は0から100であるが、これは利用 できる最大パワーの百分率として解釈される。kickeffectorは力とトルクをボ ールに与える。ただし、これには一定数のシミュレーションステップを必要と する。現在、10サイクルが使用されている。これはシミュレーション時間で 1/10秒に相当する。ボールを蹴るには、ボールとロボットが非常に近くなけれ ばならない、すなわち、プレイヤのキッカブルマージンと呼ばれる範囲内でな ければならない。現在、このマージンは0.04mと設定されている。

水平面上でのキックの方向を変えることは出来ない。これは、望む方向へキッ クできるようにロボットを移動させなければならないことを意味する。オフサ イドルールのようなものが用意されてないため、今のところ、kickeffectorの 効果はそれほど強くない。ボールを蹴ることによって他のロボットを移動させ ることは、更に(少なくともほとんど :) )可能であるべきではない。 DriveEffectorと同様に、kickeffectorはロボットがサッカーフィールドに触 れている場合にのみ機能する。

kickeffectorのノイズは以下のパラメータを持つ:

- x-y平面での角度の誤差はかなり小さく、0.0周辺での sigma = 0.02 による
正規分布である。

- 仰角の誤差は0.0周辺の正規分布である。角度の両極値(0度と50度)では 
  sigma = 0.9 と誤差は小さい。範囲の中間に向かって角度の誤差はより大き
  くなり、sigma は4.5まで増加する。

- キックパワーの誤差は sigma = 0.4 で0.0周辺の正規分布である。
(kick <angle> <power>)

コマンド例: (kick 20.0 80.0)

2.3.6. Catch Effector


キーパ(背番号1のエージェント)はボールをキャッチする能力を持つ唯一のプ レイヤである.プレイモードが'playe_on'で,ボールがペナルティエリア内部 にあり,かつ,ロボットの近くであれば(すなわち,プレイヤのキャッチマー ジンと呼ばれる範囲内であれば),キーパはボールをキャッチできる.現在の キャッチーマージンの値は2メートルである.

catcheffectorは,グラウンド上のキーパの正面にボールを置き,キーパから2 メートル以内のプレイヤを5メートルまで遠ざける.

(catch)

2.3.7. Say Effector


他のプレイヤへメッセージを配信するためには,SayEffectorを使わなければ ならない.メッセージ長はsayMsgSize(現在512)文字まで可能で,sayメッセー ジとして有効な文字はスペースと()を除く印字可能な文字((7ビットのアスキー 文字集合では,印字可能な文字は 0x20から0x7Eまでである))である.プレイ ヤが発したメッセージは,audioCutDist(現在50メートル)の距離内にいれば, いずれのチームのプレイヤも聞くことができる.SayEffectorの使用は,プレ イヤのメッセージ受信許容量によってのみ制限される.

(say <message>)
Example command: (say player10_Pass)

2.3.8 PanTilt Effector


StaticPerceptが使用されるならば(RVPのデフォルト設定),PanTilt Effectorは,RestrictedVisionPerceptor (RVP)による視界方向を変化させる. 視界方向を変更するコマンドは (pantilt <panDelta> <tiltDelta>) で,<panDelta> と <tiltDelta> はそれぞれパンとチルトの角度の(度数での) 変化量である. パンとチルトの角度変化の最大値は, rcssserver3D.rb における pantilteffectorの setMaxPanAngleDeltaメソッドとsetMaxTiltAngleDelta メソッドで変更可能である. これらの値は一回あたりの最大の角度変化を表します. パンとチルトの角度は agentstateperceptor によって,現在の角度をもっとも 近い整数に丸めた値で報告される.

2.3.9 Vision Perceptor


ロボットは洗練された画像処理ソフトウェア付き :) の特別な全方位カメラを所 有している。 もし通常の visionperceptor を使うなら,ロボットは360度の視界を持つ。 RestrictedVisionPerceptorを使うなら(これはバージョン0.5でデフォルトに なった),ロボットの視界は90度に制限される(これはもちろん rcssserver3d.rb で変更可能である). 視界の方向(パンとチルト)は pantilt effector によって変更することができる. カメラは任意の角度へパンすることができ(パン方向の初期値である0度は敵陣の 方向である),水平面に対して傾けることができる.

VisionPerceptorは観測された物体のリストを配送する。 物体とは、他のロボット、ボール、またはフィールド上のマーカである。 現在、フィールド上には8つのマーカ(フィールドの各コーナと各ゴールポスト)が 存在する。

知覚された各物体について以下の情報が得られる:

- プレイヤと物体間の距離
- 水平面上における角度。敵ゴール方向が常に0度となる。
- 仰角(俯角)。0度は水平面上であることを意味する。

2Dサッカーシミュレーションとは異なり、視覚システムは物体の速度を配送し ない。物体を他の物体によって閉じ込めることが出来る(これはまだ完全には 実装されていない)。すべての距離と角度はカメラの位置に相対な値が与えら れる。現在、カメラは球体ロボットの中心に位置している。

視覚システムのノイズパラメータは以下のようになっている:

- 小さな測定誤差がカメラの位置へ加えられる。各軸に対して、誤差は-0.005m
から0.005mの範囲で一様分布である。誤差は一度だけ計算され、試合中は一
定の値のままである。

- 0.0周辺の正規分布である動的ノイズ
  + 距離の誤差:  sigma = 0.0965
  + 角度の誤差 (x-y平面): sigma = 0.1225
  + 角度の誤差 (仰角/俯角): sigma = 0.1480
(Vision 
	(<Type> 
	(team <teamname>) 
	(id <id>) 
	(pol <distance> <horizontal angle> <latitudal angle>)
	)
)

取り得る型:

- 'Flag' with <id> one of '1_l', '2_l', '1_r', '2_r'
- 'Goal' with <id> one of '1_l', '2_l', '2_l', '2_r'
- 'Player' with <id> being the uniform number of the player

視覚メッセージの出力例:

(Vision (Flag (id 1_l) (pol 54.3137 -148.083 -0.152227)) (Flag (id
2_l) (pol 59.4273 141.046 -0.131907)) (Flag (id 1_r) (pol 61.9718
-27.4136 -0.123048)) (Flag (id 2_r) (pol 66.4986 34.3644 -0.108964))
(Goal (id 1_l) (pol 46.1688 179.18 -0.193898)) (Goal (id 2_l) (pol
46.8624 170.182 -0.189786)) (Goal (id 1_r) (pol 54.9749 0.874504
-0.149385)) (Goal (id 2_r) (pol 55.5585 8.45381 -0.146933)) (Ball (pol
6.2928 45.0858 -0.94987)) (Player (team robolog) (id 1) (pol 7.33643
37.5782 5.86774)))

2.3.10 GameStatePerceptor


GameStatePerceptorは現在の試合の状態をあなたに教える。この知覚器から得 られる最初の知覚対象は、ボールの重さやフィールドサイズのような、いくつ かのゲーム変数を追加して教える。

(GameState (<Name> <Value>) ...)

<Name>が取り得る値:

- 'time' は現在のシミュレーション経過時間を秒(浮動少数)で与える。

- 'playmode' は現在のプレイモードを文字列で与える。取り得るプレイモー
ドは、"BeforeKickOff", "KickOff_Left", "KickOff_Right", "PlayOn",
"KickIn_Left", "KickIn_Right", "corner_kick_left", "corner_kick_right",
"goal_kick_left", "goal_kick_right", "offside_left", "offside_right",
"GameOver", "Goal_Left", "Goal_Right", "free_kick_left",
"free_kick_right", "unknown". 全てのプレイモードの最新のリストについ
ては(./plugin/soccer/soccertypes.h)を参照。

GameStateの出力例:

(GameState (time 0) (playmode BeforeKickOff))

2.3.11 AgentState perceptor


AgentStatePerceptorは現在のエージェントの状態を教える. 現在のところ,パン/チルトの角度(もっとも近い整数に丸められた値)と バッテリレベルと温度が得られる.

(AgentState
       (pan_tilt <pan in degrees> <tilt in degrees>)
	(battery <battery level in percent>)
	(temp <temperature in degree>)
)

AgentStateの出力例:

(AgentState (pan_tilt -89 -2) (battery 100) (temp 23))

2.3.12 Hear Perceptor


プレイヤがSayEffectorを使用してメッセージを送信すると,このパーセプタ から知覚が得られる.聴覚センサメッセージのフォーマットは:

(hear <time> <direction in degree> <message>)

time>は現在の時間を示す.

direction in degree> は,送信者が他のプレイヤの場合,そのプレイヤへの (誤差無しの)相対方向である.送信者が自分自身の場合は"self"(二重引用符 は無し)となる.

message>はメッセージである.最大長はsayMsgSizeバイトである.

聴覚受容器に影響するサーバパラメータは:

Parameter                      Value
---------------------------------------
audioCutDist                    50.0
hearMax                         2
hearInc                         1
hearDecay                       2
sayMsgSize                      512

プレイヤの聴覚許容量はメッセージを聞いたときにhearDecay分だけ減少する ので,プレイヤの聴覚許容量が少なくともhearDecayであれば,プレイヤはメッ セージを聞くことができる. 聴覚許容量はサイクルごとにhearIncだけ増加する.聴覚許容量の最大値は hearMaxである.他のチームのコミュニケーションチャンネルへの過負荷を避 けるために,聴覚許容量はチームごとに設定されている.現在の値では,パー セプタが2回更新されるごとに,プレイヤは一つのメッセージを聞くことがで きる.

プレイヤが聞くことができる以上のメッセージが同時に届いた場合,実際に聞 こえるメッセージは未定義である(現在の実装では,届いた順にメッセージが 選択される).このルールは自分自身からのメッセージには適用されない.言 い替えると,プレイヤは,自分自身からのメッセージと他のプレイヤからのメッ セージを,同じパーセプタの出力で聞くことができる.

プレイヤが発したメッセージは,そのプレイヤからの距離がaudioCutDistメー トル以内のプレイヤにのみ送られる.例えば,時人のゴール近くにいるディフェ ンダは,同じチームのキーパからのメッセージを聞くことはできるが,敵ゴー ル知覚のストライカからのメッセージを聞くことはできない.

Hearの出力例:

(hear 0.8 -179.99 Test_1)
(hear 0.4 self Test_2)

3. モニタとトレーナのプロトコル


サッカーシミュレーションのためのデフォルトのモニタのポートは12001であ る。サーバはS式を含むテキストの行を定期的にモニタへ送る。

モニタログファイルは、モニタへ送られた全式の列を記録しており、ログファ イルフォーマットとして使用される。サーバを起動したディレクトリ直下の Logfile/monitor.log に自動的に生成される。

== INIT 式 ==

最初に一つの'Init'式が送られる。init式の例を以下に示す。サーバからの S式は単一の行で受信されることに注意すること。ここでは可読性のために整 形した。

(Init 
      (FieldLength 104)(FieldWidth 68)(FieldHeight 40)
      (GoalWidth 7.32)(GoalDepth 2)(GoalHeight 0.5)(BorderSize 10)
      (FreeKickDistance 9.15)(WaitBeforeKickOff 2)(AgentMass 75)
      (AgentRadius 0.22)(AgentMaxSpeed 10)(BallRadius 0.111)
      (BallMass 0.425878)(RuleGoalPauseTime 3)(RuleKickInPauseTime 1)
      (RuleHalfTime 300)
      (play_modes BeforeKickOff KickOff_Left KickOff_Right PlayOn
      KickIn_Left KickIn_Right corner_kick_left corner_kick_right
      goal_kick_left goal_kick_right offside_left offside_right
      GameOver Goal_Left Goal_Right free_kick_left free_kick_right)
      )

Init式内の各サブ式は、現在のシミュレーションで使用されるパラメータの名 前と値のペアである。それぞれのパラメータの意味は:

- FieldLength,FieldWidth,FieldHeight: フィールドの寸法(単位:m)

- GoalWidth, GoalDepth, GoalHeight: ゴールの寸法(単位:m)

- BorderSize: シミュレーションサッカーフィールドにはフィールドを囲む余
りの部分が存在する。BorderSizeは正規のフィールド寸法に対する余剰スペー
スを与える(単位:m)。

- FreeKickDistance: フリーキック時に敵側プレイヤがボールに近づける最小
距離(単位:m)

- WaitBeforeKickOff: 試合が自動的に開始される前にサーバが待機する時間
(単位:秒)

- AgentMass: 各エージェントの質量(単位:kg)

- AgentRadius: 各エージェントの半径(単位:m)

- AgentMaxSpeed: 各エージェントの最大スピード(単位:m/s)

- BallRadius: ボールの半径(単位:m)

- BallMass: ボールの質量(単位:kg)

- RuleGoalPauseTime: ゴール後からキックオフプレイモードへ変更されるま
でにサーバが待機する時間(単位:秒

- RuleKickInPauseTime: ボールがフィールド外に出てからキックインプレイ
モードへ変更されるまでにサーバが待機する時間(単位:秒)

- RuleHalfTime: 一ハーフタイムの長さ(単位:秒)

- play_modes: サッカーシミュレーションにおける各プレイモードのリスト。
このリストを0からインデックス付けしておき、後からplay_modesを参照する。

== INFO 式 ==

最初のinitメッセージが送信された後は、Info式のみが送信されるようになる。 これらの式は現在のシミュレーションの全ての状態を含む。Info式の例を以下 に示す。

(Info 
      (time 0)(half 1)(score_left 0)(score_right 0)(play_mode 0)
      (P (pos 0 0 0))(P (pos 0 0 0))(P (pos 0 0 0))(P (pos 0 0 0))
      (P (pos 0 0 0))(P (pos 0 0 0))(P (pos 0 0 0))(P (pos 0 0 0))
      (P (pos 0 0 0))(P (pos 0 0 0))(F (id 1_l)(pos -52 -34 0))
      (F (id 2_l)(pos -52 34 0))(F (id 1_r)(pos 52 -34 0))(F (id 2_r)(pos 52 34 0))
      (G (id 1_l)(pos -52 -3.66 0))(G (id 2_l)(pos -52 3.66 0))
      (G (id 1_r)(pos 52 -3.66 0))(G (id 2_r)(pos 52 3.66 0))
      (B (pos 0 0 10))
      )

Info式内のサブ式は、現在のシミュレーション状態を記録した情報を含む名前 と値のペアである。全てのサブ式が繰り返されるとは限らない。これは、フィ ールドフラッグの位置と二つのチームの名前に関係がある。この情報は一度だ け送られる。更に、スコアのような試合状態の情報はそれが変化した場合にの み送られる。それぞれの式の意味は:

- Die: モニタへシミュレーションが終了したことを通知する。

- time: 現在のシミュレーション時間(単位:秒)

- half: 現在のゲームハーフ。0は前半、1は後半を意味する。

- score_left, score_right: それぞれのチームのスコア。

- team_left, team_right: それぞれのチーム名; 情報は一度だけ送られ、以
後、変更されない。

- play_mode: 現在のプレイモード。Init式で与えられたplay_modesを0からイ
ンデックス付けしたリストの番号に対応する。

- P: プレイヤの情報。この式は更にサブ式を含むかもしれない。
  - s: プレイヤが属するチーム。0は左サイド、1は右サイドを意味する。
  - id: プレイヤの背番号。
  - pos: 3要素のベクトルによるプレイヤの位置。
  - last: このサブ式があれば、そのプレイヤは最後にボールに触れたプレ
  イヤである。
  - say: オプションのSayEffectorを使ってプレイヤが送信した文字列。

- F: フィールド上のフラッグの情報。フラッグの情報は一度だけ送られ、以
後変更されない. 
  - pos: 3要素のベクトルによるフラッグの位置。
  - id: フラッグの名前。

- B: ボールに関する情報
  - pos: 3要素のベクトルによるボールの位置。

- ack: サーバによって実行されるコマンドを確認する。パラメータとしてユ
ーザが定義した文字列を伝える。詳細な説明は以下を参照。

== Monitor Command Parser ==

接続されたモニタは、その接続を使ってサーバへS式のコマンドを送る。これ らのコマンドは、モニタが現在のプレイモードをセットすることと、プレイヤ やボールをフィールド上の任意の位置へ移動させることを可能にする。これに よってトレーナクライアントの実装が可能になる。

サポートされる式:

(kickOff): 試合を開始する。キックオフを行うチームはコイントスによって
選択される。

(playMode <play_mode>): 現在のプレイモードをセットする。可能なプレイモ
ードは、モニタの接続時に受信したInit式内のplay_modes式に含まれる文字列
によって与えられる。例:(playMode corner_kick_left).

(agent(team [R,L])(unum <uniform number>(pos <x,y,z>)(vel <vx,vy,vz))
: 指定したプレイヤの位置と速度をセットする。
例:(agent (team L)(unum 1)(pos -52.0 0.0 0.3)(vel 0.0 0.0 0.0))

(ball (pos <x,y,z>)): ボールの位置をセットする。
例:(ball (pos 10,20,1))

(dropBall): 現在の位置にボールをドロップし、全てのプレイヤをフリーキッ
ク半径以上の距離にボールから遠ざける。

(getAck <cooky string>): 実験的な機能で、現在無効。サーバからの
(ack <cooky>) という返信を要求する。サーバはコマンドが実行されるとすぐ
に返答を送信するだろう。これはトレーナとサーバとを同期させるために使用
される。getAck式は上記のコマンドの一つの後ろに付加される。
例:((kickOff)(getAck kicked_off))

4. 参考文献


[1] http://spades-sim.sourceforge.net/
[2] http://www.uni-koblenz.de/~maas/WWW/overview.html

END OF TEXT.

おまけ

If you ever get close to a human
And human behavior
Be ready to get confused
There's definitely, definitely, definitely no logic.

(Bjork, Human Behaviour)
"Duct tape is a lot like the Force... It has a dark side, it has a light
side, and it binds the galaxy together...."
	(unknown author)

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2016-03-14 (月) 14:51:38 (1254d)
SourceForge.JP
Creative Commons License
RoboCup tools by Hidehisa Akiyama is licensed under a Creative Commons 表示-非営利 2.1 日本 License.