単純な2 D(弱い3 D)シミュレーション環境(stage)

最近、強化学習でナビゲーションとバリアフリーを行いたいと考えていますが、オンライン学習テストを行う際にv-repでテストするには大量のレンダリングなどの計算が必要なため、小さなpc機のフレームレートが4～8 fpsに下がり、自己学習に多くの時間を費やすことになります.そのため、軽量級のシミュレーションプラットフォームを見つけることができるかどうかを考え、物理シミュレーションから地図レベルに主な注意力を移し、gezeboを考えたことがあります.確かに良い代替品ですが、より簡単で乱暴なシミュレーションソフトウェアを見つけたいと思っています.最終的にstageという2006年に登場した小型シミュレーションプラットフォームを発見しました.彼はほとんどグラフィックインタラクティブ機能を持っていません.障害物の導入にもドキュメントで書く必要がありますが、簡単なことは効率的で、物理エンジンに低いシミュレーション環境が必要であれば、stageは良い選択です.もう一つの大きなポイントは、v-repのように複雑なbridgeを必要とせずにrosのpackageとして直接コンパイルできるほど小さいことです.rosとの互換性が優れています.
ここでstageのプロジェクト全体をダウンロードして、下に降りて直接ワークスペースcatkin_makeは後で使えます.この部分のネット上の資料は比較的そろっています.ここを参考にしてください.
       http://wiki.ros.org/stage_ros
環境を整えた後、自分の持っているいくつかのworldファイルのdemoを走って、ネット上で相応の紹介ドキュメントを探したいと思って、一周しても見つけられなかったほうがいいので、インスタンスのworldドキュメントを少しずつ注釈して各関数の役割を見てみるしかありません.
例えばルーチンのwillow-erratic.worldファイル、コードは以下の通りです.

window
(
  size [ 635 666 ] # in pixels
  scale 22.971   # pixels per meter
  center [ -20.306  21.679 ]
  rotate [ 0.000  0.000 ]
  			
  show_data 1              # 1=on 0=off
)


define block model
(
  size [0.500 0.500 0.500]
  gui_nose 0
)

define topurg ranger
(
	sensor( 			
    range [ 0.0  30.0 ]
    fov 270.25
   samples 1081
  )

  # generic model properties
  color "black"
  size [ 0.050 0.050 0.100 ]
)

define erratic position
(
  #size [0.415 0.392 0.25]
  size [0.350 0.350 0.250]
  origin [-0.050 0.000 0.000 0.000]
  gui_nose 1
  drive "diff"
  topurg(pose [ 0.050 0.000 0.000 0.000 ])
)

define floorplan model
(
  # sombre, sensible, artistic
  color "gray30"

  # most maps will need a bounding box
  boundary 1

  gui_nose 0
  gui_grid 0

  gui_outline 0
  gripper_return 0
  fiducial_return 0
  ranger_return 1.000
)

# set the resolution of the underlying raytrace model in meters
resolution 0.02

interval_sim 100  # simulation timestep in milliseconds


window
( 
  size [ 745 448 ] 

  rotate [ 0.000 -1.560 ]
  scale 28.806 
)

# load an environment bitmap
floorplan
( 
  name "willow"
  bitmap "willow-full.pgm"
  size [54.000 58.700 0.500]
  pose [ -29.350 27.000 0.000 90.000 ]
)

# throw in a robot
erratic( pose [ -11.277 23.266 0.000 180.000 ] name "era" color "blue")
block( pose [ -13.924 25.020 0.000 180.000 ] color "red")

まず構造を分析すると、defセクションでいくつかの量が宣言されていることがわかります.これらの量の中には別のdefによって参照されているものもあり、後の環境構築で参照されているものもあります.そのため、いくつかの基礎要素グループを宣言していると見なすことができます.たとえば、次のようにします.

define block model
(
  size [0.500 0.500 0.500]
  gui_nose 0
)

この簡単な声明は「block」というmodel型の量を宣言していますが、多くの公式に提供されているmodelは例えば

Actuator model

Blinkenlight model

Blobfinder model

Camera model

Fiducial detector model

Gripper model

Position model

Ranger model

Wifi model

ここでは単純に障害物を宣言しただけで、障害物の大きさ(size)が制定され、矢印で識別されているかどうか.また

define topurg ranger

はtopurgというレーザ測距レーダーを宣言し、そのスレッド、区間などのパラメータを設定した.次にposition量を宣言しました.

define erratic position

は、将来の小型車モデルを宣言し、関数を介して

topurg(pose [ 0.050 0.000 0.000 0.000 ])

以前に構築されたレーザーレーダーを小車(x=0.05)の位置に搭載する
あとで通過
def floorplan model
地図を収容するフレームを構築し、外部から取得する.pgm図をこのフレームワークにマウントすると、図を直接障害物に変換することができ、非常に便利です.
次に、

erratic( pose [ -11.277 23.266 0.000 180.000 ] name "era" color "blue")
block( pose [ -13.924 25.020 0.000 180.000 ] color "red")

はそれぞれロボットと障害物を構築し、runというworldファイルだけでいいです.そして、センサとロボットがrosの中で自動的にtopicを作成し、topicから直接メッセージを送ることができ、私たちの配置の難しさを大幅に減らしました.