seeの同期方法 その1

rcssserverの時間管理手法を逆手に取った同期方法を紹介する。

原理

seeメッセージの送信処理のタイミングをもう一度見てもらいたい(2D/seeの同期/視覚センサモデルを参照)。

sserver-timechart.png

この送信処理タイミングの中で、1サイクル1回のseeメッセージ受信を可能にするパターンは以下の2つ。

パターン1: change_view_sync1.png

パターン2: change_view_sync2.png

パターン2ではseeメッセージの受信がサイクル終盤(70ms以降)になってしまう場合があることが分かる。 よって、seeの同期を安全に達成するには、パターン1が望ましい。

パターン1では、3サイクルに1度、サイクル開始直後にseeを受信する機会がある。 つまり、サイクル開始直後にseeを受信できるように受信間隔を調整できれば、パターン1の受信間隔を実現できることになる。

(narrow, low)モードによる受信タイミング調整

サイクル開始直後のseeメッセージを受信するには、View Modeを(narrow, low)にしておけば良い。 (narrow, low)モードであれば全てのseeメッセージ送信タイミングでseeメッセージを受信できるので、目的のタイミングでseeを受信できるときが必ず訪れる。

seeメッセージ送信処理タイミングの図を見ると分かるが、(narrow, low)モードの場合、各サイクルでのseeメッセージの受信回数は 3回 → 3回 → 2回 のループになっている。 この受信回数をチェックすることでサイクル開始直後のseeメッセージか否かを判別できる。 すなわち、seeメッセージの受信回数が3回→2回となった次のサイクルの最初のseeメッセージは、サイクル開始直後のseeメッセージである。

以降は、現在の状態を監視しながら適切なchange_viewコマンドを正しいタイミングで送信すればよい。

長所と短所

長所

  • 同期の確実性
    少々であればパケットの遅延の影響を受けず、確実に同期できる
  • 他のView Modeとの混在が容易
    一度同期してしまえば、(normal, high)と(wide, high)を簡単に混在できる。
    ただし、change_viewの送信タイミングを失敗せず、かつ、受信タイミングを正しく管理できていることが前提。

短所

  • シミュレータの仕様に依存し過ぎ
    当然ながら、server.confのシミュレーションステップに関するパラメータが変更されると、まったく使い物にならない。rcssserverのためだけに使えるテクニックなので、他分野での応用など望むべくも無い。要するに、何の役にも立たないノウハウ。
  • 脆い
    同期の確実性のあまり、極端なパケットの遅延やロストが発生すると、一度に全て崩壊してしまう。
    立てなおすには、もう一度(narrow, low)モードでのタイミングの監視を実行しなければならない。

プレイヤの意志決定にかかる計算時間+コマンドのパケットの遅延を考慮すると、プレイヤの意志決定は遅くともsense_body受信から75ms以内には始めたい。 しかしながら、rcsssererとプレイヤクライアントが物理的に別のホストで動作する場合、パケットの遅延は想像以上に発生する。パケットの遅延以外にも、rcssserverが動作するマシンに何らかの負荷がかかってしまい、rcssserverの処理が遅れるだけでも影響が出る。 20ms以上の遅延もそれほど珍しくないので、150msの受信タイミングで同期が崩れる可能性は高い。 受信タイミングの監視と同期が崩れた場合への対処がとても重要である。


添付ファイル: filechange_view_sync2.png 392件 [詳細] filechange_view_sync2.sxd 352件 [詳細] filechange_view_sync1.sxd 379件 [詳細] filechange_view_sync1.png 400件 [詳細]

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