Skip to content
This repository has been archived by the owner on Aug 15, 2024. It is now read-only.

Server Specification of the Virtual Soccer Competition の翻訳

Jump to bottom
Yasuo Hayashibara edited this page May 30, 2021 · 1 revision

仮想サッカー大会のサーバ仕様 本ドキュメントは，ロボカップヒューマノイドリーグの仮想サッカー大会のサーバインフラを説明したものです．もし、あなたのチームがロボットコントローラを動かすために、このドキュメントに記載されていない、あるいは、このドキュメントに抵触する要素を必要としていると感じた場合には、できるだけ早くTCにご連絡ください。 ホスティングとコンピューティング 本大会は，Amazon Web Services を利用して開催されます。大会では、2 種類の仮想マシンを使用します。

  • シミュレータ用のインスタンス。AWS g4dn.4xlargeインスタンス
  • GPU NVIDIA T4
  • CPU 第2世代 Intel Xeon Scalable (Cascade Lake) プロセッサ、8 vCPU (インスタンスタイプはデフォルトで16個ですが、1コアにつき1スレッドで起動します)
  • メモリ： 64GB
  • オペレーティングシステム Ubuntu Server 18.04 LTS、64ビットx86
  • ロボットインスタンス。AWS g4dn.xlargeインスタンス
  • GPU NVIDIA T4
  • CPU 第2世代Intel Xeon Scalable（Cascade Lake）プロセッサ、4 vCPU
  • メモリ： 16GB
  • オペレーティングシステム Ubuntu Server 18.04 LTS, 64-bit x86

各ロボットは、専用のロボットインスタンス（「ロボットVM」）を持っています。 各ロボットVMの中では、ちょうど1台のロボット用のロボット制御ソフトウェアを含むDockerイメージが実行されます。ロボットVM上では、Dockerコンテナ内のプロセス以外にも他のプロセスが実行されていますが、これらのプロセスのフットプリントはごくわずかです。 AWS上でロボットコントローラーを試してみたい場合は、技術委員会が提供するWebotsシミュレータのパブリックイメージを使用することができます。AWSのリージョンとしてOhio (us-east-2)を選択し、robocupをプレフィックスに持つ最新のAMIを検索する必要があります。 AWSでのWebotsサーバーVMのセットアップ 以下の手順を始める前に、AWSのリージョンがOhioに設定されていることを確認します。これは、AWSコンソールに入ったときに右上で変更できます。また、8台のロボットコントローラーと1台のシミュレーターインスタンスでゲームを起動するためには、g4dnインスタンスに48 vCPUのクォータが必要です（4台のロボットと1台のシミュレーターインスタンスの場合は32 vCPU）。vCPUクォータの増加は、「サービスクォータ」でリクエストできます。

  1. コミュニティ AMI から新しいインスタンスを起動します。robocupを検索し、サーバーVMの最新リリースを使用します（オイシャルイメージはAWSアカウント079967072104で公開されています）。

  2. インスタンスタイプとして g4dn.4xlarge を設定します。CPUオプションでコアあたりのスレッド数を2（デフォルト）から1に明示的に設定して、インスタンスを構成します。

    1. シミュレータVMが、クライアントインスタンスと同じ仮想プライベートクラウド（クラウド内のローカルネットワーク）に作成されていることを確認します。
    1. インスタンス用に30GBの汎用SSDストレージを残しておきます（AMIで事前に設定されています）。

  5. セキュリティグループのオプションで、ポート10001、10002、10003、10004、10021、10022、10023、10024（ロボットモデルへのクライアントAPI接続用）のTCP接続と、ポート3838と3939（GameController用）のUDP接続を許可することを確認してください。

    1. インスタンスを起動したら、 ssh -i key.pem ubuntu@ip（key.pemはインスタンス作成時に設定したキー、ipはインスタンスのパブリックIP）を使って、sshでインスタンスに接続します。

  7. 以下のコマンドを実行してXorgサーバを起動する。 /usr/bin/Xorg -noreset +extension GLX +extension RANDR +extension RENDER ˶ˆ꒳ˆ˵ )

  • logfile /log-xdummy.log -config /etc/X11/xorg.conf :1
  1. 以下の環境変数を設定してください。 (a) export DISPLAY=:1 (b) export GAME_CONTROLLER_HOME=/home/ubuntu/GameController (c) エクスポートJAVA_HOME=/usr
  2. webots/projects/samples/contests/robocup/controllers/refereeにあるgame.jsonファイルを適応させます。 (a) hostにwebotsサーバーVMのローカルIPアドレスを設定します。 (b) チーム赤とチーム青は、ホストリストを以下のように変更します。127.0.0.1を最初のエントリとして残し、クライアントインスタンスのローカルIPアドレスを2番目から5番目のエントリとして追加します。
    1. シミュレーションを開始します。 cd /home/ubuntu/webots ./ webots --batch --no-sandbox --no-rendering --stdout --stderr ◎シミュレーションを開始します。 ./ project/samples/contests/robocup/worlds/robocup.wbt

1つのチームで4台以下のロボットでプレイしたい場合は、game.json内のクライアントインスタンスのローカルIPアドレスを127.0.0.1に置き換えてください。ロボットコントローラーのIPアドレスの数が、team.jsonファイルで定義されたロボットの数と一致していることを確認してください。 ドッカーイメージ チームは、技術委員会が提供するコンテナレジストリを介して、ロボット制御ソフトウェアのDockerイメージを提供することが期待されます。チームには、各チームのコンテナレジストリへのイメージの読み書きを可能にする特定のユーザーアカウントが与えられます。各Dockerイメージの最大サイズは10GBに制限されています。チームのレジストリに登録されているすべてのDockerイメージの最大サイズの合計は40GBです。10GB以上のイメージは自動的にレジストリから削除され、そのロボット制御ソフトがない状態でゲームが開始されます。最大サイズの合計を超えた場合、ランダムなDockerイメージが自動的に削除され、最大サイズの合計が40GB以下になるまで削除されます。team_config.jsonでは、ロボットごとに異なるDockerイメージを設定することができます。また、Dockerイメージの実行時に渡される引数（CMD）もteam_config.jsonで設定できます。さらに、Dockerコンテナには以下の環境変数が用意されています。

  • ROBOCUP_ROBOT_ID: team_config.jsonで指定されたロボットのIDです。有効な値は1～4（KidSize）または1～2（AdultSize）です。
  • ROBOCUP_TEAM_COLOR: ゲームスケジュールに記載されているチームカラー。赤か青のいずれかになります。
  • ROBOCUP_SIMULATOR_ADDR：game.jsonで定義されている、各ロボットのプレイヤーコントローラーのIPとポートです。例えば、192.168.123.22:10002のようになります。 ミラーサーバーの目的は、ブロードキャストをエミュレートすることです（ブロードキャストは利用できません）。自分のチームのロボットVMがミラーサーバにデータを送信すると、そのデータは自分のチームの他のロボットVMにも送信されます（ミラーリング）。
  • ROBOCUP_TEAM_PLAYER1_IP: チームの1台目のロボットを動かすロボットVMのIP（"1 "はteam.jsonに記述されているロボットの順番です）。
  • ROBOCUP_TEAM_PLAYER2_IP: あなたのチームの2台目のロボットを動かすロボットVMのIP。
  • ROBOCUP_TEAM_PLAYER3_IP: あなたのチームの3番目のロボットを動かすロボットVMのIP
  • ROBOCUP_TEAM_PLAYER4_IP: 自チームの4台目のロボットを動かすロボットVMのIP

ドッカーイメージのアップロード TCはチームに提供します。

  • AWSアクセスキーID
  • AWSシークレットアクセスキー
  • DockerレジストリのURL

こんな感じでイメージを押し出すことができます。

  1. AWS CLIツールをインストールします。https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html
  2. AWS CLI にログインし、TC から受け取ったクレデンシャルを提供します。 AWS CONFIGURE
  3. Docker レジストリにログインします。 aws ecr get-login-password --region us-east-2 | docker login ˶ˆ꒳ˆ˵ ) --username AWS --password-stdin ここで、はTCから提供されます。 各レジストリは、チームの認証情報（およびTC）でのみアクセスできます。
    1. Dockerイメージにタグを付けて、プッシュします。 docker tag :. docker push : を実行します。 なお、TCから提供されたレジストリURLで定義されたDockerイメージ名は、各チーム1つだけです。しかし、Dockerイメージのタグは各チームが自由に選ぶことができます。team.jsonファイルでは、どのDockerイメージタグを使用するかをロボットごとに設定することができます（APIの仕様を参照）。

上記のコマンドは、Linuxでのみテストされました。Dockerイメージのプッシュに関する詳細（他のOSでDockerイメージをプッシュする方法を含む）は、https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html。 ネットワーク構築 ネットワークは以下の参加者で構成されています。

  • ロボットVM。各チームは4台（KidSize）または2台（AdultSize）のロボットVMを持っています。
  • シミュレータVM。
  • ウェボット。各チームに4台（KidSize）または2台（AdultSize）のロボットを搭載したシミュレータ本体です。
  • APIサーバー。ロボットVMは、APIサーバを介して仮想ロボットにアクセスします。
  • GameController: GameControllerは、ゲームの状態に関する情報をロボットVMに送信します。
  • AutoRef：AutoRef（自動審判サービス）は，人間の審判に代わって，その判断を GameController に伝える．

API サーバと AutoRef の両方が Webots supervisor として実装されています。 1 つのチームのすべてのロボット VM とシミュレータ API との間の総帯域幅は 350 MB/s に制限され、プレイしているすべてのロボットに均等に分配されます。たとえば，KidSize のチームが，4 つのロボット ID を含む team_config.json を提供した場合，各ロボット VM の帯域幅は 87.5MB/s となります．同じチームのロボットVM間の合計帯域幅は1MB/sに制限されます。対戦チームのロボットVMは通信できません。 Dockerイメージは、ホストネットワークを使って実行されます（docker run --network hostと考えてください）。したがって、Dockerコンテナ内のすべてのポートは、ロボットVMの外部から到達可能です。

image

図1：仮想サッカー大会のネットワーク通信の様子。Webots シミュレータからの情報は、API サーバを介してのみアクセス可能です。AutoRefはGameControllerとのやり取りのみで、ロボットVMとの直接の通信はありません。 ロボット間の通信では、マルチキャストやブロードキャストは機能しません。これは、Docker（[multicast1]および[multicast2]を参照）やAWS Virtual Private Clouds（[broadcast]を参照）の制限事項です。そこで、技術委員会では、Simulator VM上で動作するUDPサーバを用意し、以下の方法でパッケージの送信を処理します。

  • GameControllerのアップデート。例年通り、ロボットは GameController の状態を 3838 番ポートで受信する。
  • GameControllerの応答。例年通り、チームは3939ポートでGameControllerにアップデートを送信できる。この場合、メッセージはGameControllerにのみ送信され、他のロボットはこのメッセージを受信しないことに注意が必要である。
  • チーム内部のコミュニケーション。自分のチームの全ロボットにメッセージを送信するには、3737ポートにメッセージを送信する。これまでとは異なり、UDPサーバーは、このポートを介して送信されたメッセージが自分のチームのロボットVMにのみ送信されることを保証する。UDPサーバーは，ルールブックに設定されたサイズ制限を超えるメッセージをすべて無視することで，チームがチーム内通信の制限を守ることを保証します．

シミュレータVMがUDP送信を行うため、チームはROBOCUP_SIMULATOR_ADDRで指定されたIPを、上記のポートを持つDockerイメージに使用する必要があります。 ゲームログ ゲームのビデオストリームが終了すると、そのゲームのログが公開されます。ログには一般公開されるものと、各チームのみに公開されるものがあります。 公開されるログ

  • ゲームの録画。ゲームの録画は、ビデオと、サイバーボテック社が提供する3dリプレイバージョンを生成するためのカスタムフォーマットの両方で利用可能です。
  • AutoRefのログ。AutoRefereeシステムによって行われたすべての決定事項。
  • GameControllerのログ。ロボット制御インスタンスに送られる内部ログメッセージとアップデート。

チーム内でのログ。

  • ドッカーログ。ロボット制御ソフトの出力（stdout、stderr）です（dockerのログをイメージしてください）。
  • カスタムログフォルダ。チームがデバッグ目的でログを記録できるようにしたいのですが、ロボットVMごとに10GBの制限があります。そのため、各Dockerコンテナには/robocup-logsというフォルダがあり、そこにファイルを書き込めるようになっています。ゲームが終了すると、各ロボットのカスタムログフォルダのファイルがチームに転送されます。ログファイルを受け取るためには、大会が始まる前に、プライベートホストのftpサーバーまたはAWSのS3インスタンスのcredentials.jsonをヒューマノイドリーグのサブミッションシステムを通じて提供する必要があります。試合のストリームが終了すると同時に、ログファイルの書き込みを試みます。このフォルダはDockerコンテナ間で共有されません（つまり、このフォルダを介して他のDockerコンテナと通信することはできません。

各ロボットはそれぞれのフォルダを持っています）。) また、このフォルダはゲーム間で永続的ではなく、各ゲームの開始時に最初は空の状態になります。

これは、credentials.jsonでチームが提供するFTPアクセスの例です。

{ "type": "sftp", "credentials": { "hostname": "ab", "port": "secret", "username": "test_bucket", "password": "test_bucket" } } これは、credentials.jsonでチームが提供するS3アクセスの例です。 { "type": "s3", "credentials": { "access_id": "test_id", "access_secret": "test_secret", "bucket": "test-bucket" } } S3インスタンスを作成するには、AWSコンソールにログインして、S3ダッシュボードに切り替える必要があります。その後、ログファイル用の新しいバケットを作成することができます。Identity and Access Management（IAM）ダッシュボードでは、新しいユーザーアカウントを作成して、credentials.jsonで提供する必要のある認証情報を取得できます。ここではプログラム的なアクセスのみを必要としており、AWSコンソールへのログインは必要ありません。IAMを作成すると、access_idとaccess_secretが記載されたファイルをダウンロードできるようになります。その後、新しく作成したユーザーがバケットへの書き込み権限を持っていることを確認し、バケットへのs3:PutObjectアクセスを付与する必要があります（例：[s3policy]で実証済み）。 パブリックログは一般に公開され、少なくとも大会終了まではアクセス可能な状態となります。チーム・インターナル・ログは、それぞれのチームのみに公開されます。チーム・インターナル・ログは、チームのftpまたはS3インスタンスへの転送が成功した後、または最新のバージョンが3つ入った後に削除されます。チームは、TCがデータを転送できるようにftpサーバーまたはS3インスタンスを利用可能にしておく責任があります。3つ以上のゲームがチームへの送信を待っている場合は、チームがアクセスするかどうかに関わらず、最も古いものが削除される。 ストレージ 各VMには、少なくとも10GBの空き容量を持つSSDストレージが搭載されています。このストレージは、Dockerオーバーレイファイルシステム（Dockerコンテナの/にマウントされたメインファイルシステム）を介してアクセスできます。ストレージはゲーム間で永続的ではなく、各ゲーム後にリセットされます。 なお、チームはファイルシステムに事前に情報を入力することはできず、必要なデータ（ニューラルネットワークの重みなどのアセットを含む）はすべてDockerイメージに保存することになっています。ファイルシステムは、一時的なファイルの保存にのみ使用できます。 なお、/robocup-logsのカスタムログフォルダには、10GBの追加ストレージがあります。 ゲームの手順 大会に先立ち、チームは team_config.json（チームの設定ファイル、APIドキュメント[apidocument]を参照）と PROTO ファイル（Webots ロボットのモデル）を Humanoid League の提出システムを介して提出します。 大会期間中、各試合のOÿcial Streaming Scheduleがチームに通知されます。通知されるスケジュールはストリーミングの時間であり、実際のシミュレーションゲームが行われる時間ではないことに注意してください。模擬試合は、ラウンドロビン戦ではストリーミング配信される前の4時間、ノックアウト戦では7時間の時間枠で行われます。 試合の進行は以下の通りです。

  1. ラウンドロビンマッチのOÿcial Streaming Scheduleの4時間前、またはノックアウトマッチのOÿcial Streaming Startの7時間前に、team_config.jsonで定義されたDockerイメージがプルされます（各試合の前にプルされるので、チームは競技中に修正することができます）。
    1. 技術委員会によってシミュレーションが開始され、ロボットのモデルファイルがシミュレーターに読み込まれる。
    1. team_config.jsonで定義された各ロボットにVMが割り当てられ、各ロボットのVM上で、team_config.jsonで指定されたコマンドでDockerイメージ（既にプルされている）が実行される。
  4. AutoRefは、ロボットVMの起動から試合開始までの間、少なくとも2分間待機します。試合開始とは、ゲームの法則に従って、前半のハーフタイムにゲームステートがREADYに設定されることで定義される。
  5. GameControllerが試合の終了をアナウンスします。チームのDockerコンテナには、キルされる前に潔くシャットダウンするための時間が2分間与えられます（docker stop --time=120のように考えてください）。
  6. ゲームのスケジュールに沿って、Twitchでゲームを一般に配信する。
    1. ゲームのストリーミングが終了した後、ゲームのログが各チームに転送される。

また、実際のゲーム時間は、シミュレーションのリアルタイム性に依存しますのでご注意ください。 チームが無効なDockerイメージを提供した場合でも、それぞれのロボットモデルはteam_config.jsonに基づいてゲーム内に生成されます。少なくとも1つの有効なDockerイメージが提供された場合は、ゲームは正常に進行します。有効なDockerイメージが提供されていない場合、そのゲームは没収されたとみなされます。

参考文献 apidocument API Specifications for Virtual Soccer Competition, https://cdn.robocup.org/hl/wp/2021/05/v- hsc_simulator_api_v1.0.pdf broadcast AWS Virtual Private Cloud documentation, https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ Subnets.html multicast1 Cannot receive external multicast inside container, https://github.com/moby/moby/issues/23659 multicast2 Multicast in Overlay driver, https://github.com/moby/libnetwork/issues/552 s3policy S3のバケットにポリシーを設定する方法についてのドキュメント、 https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-with-s3-actions.html#using-with-s3-actions-related-to-objects

Clone this wiki locally