視覚センサモデルとseeメッセージ送信間隔

View Mode

rcssserver-10.*までで動作するプレイヤは、以下の視界の広さおよび精度を 使用できる。

  • 視界の広さ(View Width)
    • narrow
    • normal
    • wide
  • 視界の精度(View Quality)
    • high
    • low

これらを変更するには以下のようにchange_viewコマンドを実行する。

(change_view narrow low)
(change_view normal high)
(change_view wide high)

広さと精度の組合せで、合計6通りのView Modeが存在することになる。

そして、View Modeを変更することによって、seeメッセージの受信頻度が変化する、 という副作用が発生する。

View Width

View Widthとはプレイヤの視野の広さであり、具体的には視界コーンの中心角 の大きさを意味する。 実際に使用されるView Widthの数値は ~/.rcsserver/server.conf内 で 定義されているvisible_angleパラメータによって決定される。

server::visible_angle = 90

このvisible_angleの値がnormalモードでの視界の広さとなり、narrowはその 1/2倍、wideは2倍になる。

よって、実際の数値は以下のようになる。

タイプ広さ(中心角の大きさ)
narrow45度
normal90度
wide180度

View Quality

View Qualityとはプレイヤの視界の精度。 現在、highとlowの2タイプが用意されており、その違いは以下の通り。

highlow
物体の方向得られる得られる
物体までの距離得られる得られない
物体の速度得られる得られない
チーム名・背番号得られる得られる

lowモードでは距離と速度の情報が得られない。 よって、通常lowモードを使うことはありえない。

seeメッセージの頻度

seeメッセージ送信間隔は~/.rcsserver/server.conf 内の send_step パラメータによって決定される。

server::send_step = 150

このパラメータは、プレイヤのView Modeが(normal, high)のときのseeメッセージ 送信間隔を定義している。 単位はミリ秒。

View Mode(View WidthとView Quality)を変更することでプレイヤのseeメッセージ受信 間隔が変更されることは前述の通り。 パラメータsend_stepで定義される値は、プレイヤのView Modeが(nomal, high)のときに使用されるもので、この数値を基準にして他のView Modeでの seeメッセージ受信間隔が決定される。

この受信間隔の計算方法は非常に簡単で、直感的に理解できる。 View Widthが2倍になれば間隔は1/2倍、逆にView Widthが1/2倍されれば間隔は 2倍になる。 同様に、View Qualityがhighからlowになれば間隔は2倍に、その逆は1/2倍に なる。 要するに、一度により多くの情報を得ようとすれば、情報を得られる頻度が下がるように設計されている。 実際に使用される数値を表に書くと以下のようになる。

View Modeseeの間隔(ミリ秒)
narrow, low37.5 (150/2/2)
narrow, high75 (150/2*1)
normal, low75 (150*1/2)
normal, high (デフォルト)150 (150*1*1)
wide, low150 (150*2/2)
wide, high300 (150*2*1)

ただし、これはあくまで理論値であって、実際に37.5ミリ秒や75ミリ秒の間隔 でseeメッセージが受信できるわけではない(そもそも、Linuxでは1ミリ秒単 位の精度も出せないはず)。 rcssserverは独自のタイマモジュールを持っており、この間隔に近くなるよう に擬似的な時間管理を行っている。

rcssserver/src/stdtimer.cc

rcssserverの時間管理モデルを本当に理解するにはこのソースを読んで理解し なければならない。 かと言って、これをいきなり渡されて理解できる人は滅多にいないと思うので、 がんばって解説してみます。

ともかく、void StandardTimer::run()を参照。 大雑把に言って、StandardTimer::run()は以下のことを行っている。

  • 無限ループ
  • 通常時はsigpauseでスリープ
  • 10ms(param.hのTIMEDELTA)に一回アラーム割り込み
    • 割り込みごとに経過時間を更新
    • 経過時間が各イベント(サイクル更新、センサ情報配信など)のタイミン グに達していれば、その処理を実行

各イベントのタイミング管理に使用される変数は以下の通り。 いずれもStandardTimer::run()内部で定義されているローカル変数。 q_* の変数の値は、server.confで定義されているシミュレーションステップ 関連のパラメータから自動的に決定される。 ServerParam::lcmStep()の値は、各シミュレーションステップ関連パラメータ の最小公倍数(現在の設定では300になる)である。

変数名役割
lcmt経過時間格納割り込みごとに更新
c_simtシミュレーションステップ更新回数カウント発生ごとに更新
c_sentseeメッセージ送信回数カウント発生ごとに更新
c_rectクライアントコマンド受信回数カウント発生ごとに更新
c_sbtsense bodyメッセージ送信回数カウント発生ごとに更新
c_sbtcoach用seeメッセージ送信回数カウント発生ごとに更新
q_simt300(ServerParam::lcmStep())ミリ秒間でのシミュレーションステップ更新回数3 で固定
q_sent300(ServerParam::lcmStep())ミリ秒間でのseeメッセージ送信回数8 で固定
q_rect300(ServerParam::lcmStep())ミリ秒間でのクライアントコマンド受信回数30 で固定
q_sbt300(ServerParam::lcmStep())ミリ秒間でのsense bodyメッセージ送信回数3 で固定
q_svt300(ServerParam::lcmStep())ミリ秒間でのcoach用seeメッセージ送信回数3 で固定

ここで、q_sentの値が8、すなわちseeメッセージが3サイクル(300ミリ秒)に8 回送信される機会がある、と言う点に注目してもらいたい。 これが意味することは、

 300 = 37.5 * 8

つまり、View Modeが(narrow, low)であれば、3サイクルの間に8回seeメッセー ジを受信でき、理想的には以下のタイミングでseeメッセージ送信処理が実行 されることになる。

0.037.575112.5150187.5225262.5300(=0.0)

だが、上述の通り、アラームの割り込み間隔は10ミリ秒。 では、実際にはどのように送信タイミングが決定されるか?

答えは割と単純で、lcmt(経過時間)が 37.5 * c_sentを越えるたびにseeメッ セージの送信処理が実行されるようになっている。 文章では伝えづらいので以下の図を参照してもらいたい。

sserver-timechart.png

目盛は10ms単位、矢印の位置が実際のseeメッセージ送信タイミング、 下段の括弧内の数値は理想的な送信時間、上段の数値は実際の送信時間を意味する。 シミュレーションステップは、0, 100, 200, 300の時点で更新され、各物体の位置や速度などの更新も全てこのときに行われる(逆に言うと、これら以外の時には一部例外を除いて何も更新されない)。

この図はView Modeが(narrow, low)のときのseeメッセージ送信タイミングを 示しているが、この送信タイミング集合は任意のView Modeでの送信タイミングを 包含している。 言い換えると、どのView Modeであろうが、この図で示されたタイミングのいずれかでしか seeメッセージは送信されないということである。 これがサーバとの同期を複雑にしている元凶である。

seeメッセージ送信タイミング

前節で述べたように、seeメッセージは特定のタイミングでしか送信されない。 とは言え、これだけでは具体的なイメージが沸かないと思うので、実際の送信パターンを 図にしてみた。 以下の図の赤色の矢印部分がseeメッセージが送信されるタイミングである。

(narrow, high)の場合

合計2パターン。2回に1回の送信機会がある。

1サイクルに1回はseeメッセージを得られる機会があることが分かる。

narrow-pattern.png

(normal, high)の場合

合計4パターン。4回に1回の送信機会がある。

3サイクルに2回しかseeメッセージを得られない。 しかも、パターンによっては受信タイミングがサイクル終盤になってしまう。

normal-pattern.png

(wide, high)の場合

もうお分かりかと思うが、合計8パターン。送信機会は8回に1回だけになる。 図は省略する。

まとめ

これで大体お分かりいただけるんではないかと思いますが、いかがでしょう?

それにしても、何度見てもseeメッセージ送信タイミングの実装はいびつに感じてしまう。


添付ファイル: filenormal-pattern.png 443件 [詳細] filenormal-pattern.sxd 419件 [詳細] filenarrow-pattern.sxd 425件 [詳細] filenarrow-pattern.png 486件 [詳細] filesserver-timechart.sxd 415件 [詳細] filesserver-timechart.png 464件 [詳細]

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