ROS1+Gazebo Engine#

This engine can be selected via --engine=engine.ros1gazebo.

This is the engine on which SIERRA will run experiments using the Gazebo simulator and ROS1. It cannot be used to run experiments on real robots. To use this engine, you must setup the SIERRA ROSBridge.

Worlds within ROS1+Gazebo are infinite from the perspective of physics engines, even though a finite area shows up in rendering. So, to place robots randomly in the arena at the start of simulation across Experimental Runs (if you want to do that) "dimensions" for a given world must be specified as part of the --scenario argument. If you don't specify dimensions as part of the --scenario argument, then you need to supply a list of valid robot positions via --robot-positions which SIERRA will choose from randomly for each robot.

Requirements#

See ROS1-based Engines.

OS Packages#

None for the moment, beyond whatever ROS1+Gazebo packages you install.

Usage#

Batch Criteria#

The following batch criteria are defined which can be used with any ROS1+Gazebo-based Project.

Population Size

Cmdline Interface#

sierra - CLI interface#

sierra [--exp-setup EXP_SETUP] --robot ROBOT
       [--robot-positions ROBOT_POSITIONS [ROBOT_POSITIONS ...]]
       [--physics-engine-type {ode,bullet,dart,simbody}]
       [--physics-iter-per-tick PHYSICS_ITER_PER_TICK]
       [--physics-n-threads PHYSICS_N_THREADS]
       [--physics-ec-threadpool PHYSICS_EC_THREADPOOL]

sierra Stage 1 options#

Options for generating experiments

--exp-setup EXP_SETUP -
Defines experiment run length, ticks per second for the experiment. See Experiment Setup for a full description.
(default: exp_setup.T1000.K5)
--robot ROBOT -
The key name of the robot model, which must be present in the appropriate section of main.yaml for the Project. See Project YAML Configuration for details.
(default: None)
--robot-positions ROBOT_POSITIONS -
A list of space-separated "X,Y,Z" tuples (no quotes) passed on the command line as valid starting positions for the robots within the world.
(default: [])
--physics-engine-type PHYSICS_ENGINE_TYPE -
The type of 3D physics engine to use for managing spatial extents within the arena, choosing one of the types that Gazebo supports. A single engine instance is used to manage all physics in the arena.
(default: ode)
--physics-iter-per-tick PHYSICS_ITER_PER_TICK -
The # of iterations all physics engines should perform per tick each time the controller loops are run (the # of ticks per second for controller control loops is set via --exp-setup).
(default: 1000)
--physics-n-threads PHYSICS_N_THREADS -
Gazebo can group non-interacting entities into computational "islands" and do the physics updates for those islands in parallel each timestep (islands) are recomputed after each timestep). Gazebo can also parallelize the computation of velocity/position updates with the computation of resolving collisions (i.e., the timestep impulse results in one entity "inside" another). You can assign multiple threads to a pool for cumulative use for these two parallelization methods (threads will be allocated evenly between them). The point at which adding more threads will start to DECREASE performance depends on the complexity of your world, the number and type of robots in it, etc., so don't just set this parameter to the # of cores for your machine as a default.

From the Gazebo Parallel Physics Report, setting the pool size to the # robots/# joint trees in your simulation usually gives good results, as long as you have more cores available than you allocate to this pool (Gazebo has other threads too).

This only applies if --physics-engine-type=ode.

A value of 0=no threads.
(default: 0)
--physics-ec-threadpool PHYSICS_EC_THREADPOOL -
Gazebo can parallelize the computation of velocity/position updates with the computation of resolving collisions (i.e., the timestep impulse results in one entity "inside" another). You can assign multiple threads to a pool for cumulative use for this purpose. The point at which adding more threads will start to DECREASE performance depends on the complexity of your world, the number and type of robots in it, etc., so don't just set this parameter to the # of cores for your machine as a default.

From the Gazebo Parallel Physics Report, setting the pool size to the # robots/#joint trees in your simulation usually gives good results, as long as you have more cores than than you allocate to physics (Gazebo has other threads too).

This only applies if --physics-engine-type=ode.

A value of 0=no threads.
(default: 0)

Environment Variables#

This engine ignores SIERRA_ARCH.

This engine sets PYTHONPATH so that roscore can run properly in HPC environments.

Execution Environments#

This engine supports:

Others may work but are untested.

Random Seeding For Reproducibility#

ROS1+Gazebo do not provide a random number generator manager, but SIERRA provides random seeds to each Experimental Run which Project code should use to manage random number generation, if needed, to maximize reproducability. By default SIERRA does not overwrite its generated random seeds for each experiment once generated; you can override with --no-preserve-seeds.