Configuration of the environment and trials

This page describes how to configure the simulated workcell environment by selecting and placing sensors. Additionally, how to configure the behavior/challenges of trials is described (only available for development, not available during the competition).

The entire trial configuration is typically comprised of two configuration files:

• the 'Trial configuration file' that details specifics of a particular trial of the competition, which users will not have control over, and
• the 'Competitor configuration file' that details the placement of objects that users have control over.

Both of these files are passed to an invocation of gear.py which parses the data and launches the appropriately configured simulation. The general format of the invocation is:

rosrun osrf_gear gear.py -f <trial_config_file> <competitor_config_file>

As an example:

rosrun osrf_gear gear.py -f \
  `catkin_find --share --first-only osrf_gear`/config/sample.yaml \
  `catkin_find --share --first-only osrf_gear`/config/sample_user_config.yaml

When testing your own system you will replace sample_user_config.yaml with the path to your own config file.

Competitor configuration file

As a competitor, you are allowed to select the quantity, type, and location of sensors. Sensors can only be placed in static locations, they cannot be attached to the arm or otherwise be moved around the environment.

Your choices must be written using the YAML syntax in a configuration file. Here is an example configuration file.

How to add sensors

The configuration YAML file contains a list of sensors denoted by the sensors: tag. Each sensor should have a unique name followed by the type of sensor and the sensor's position and orientation.

Available sensor types include:

1. break_beam
2. proximity
3. logical_camera
4. laser_profiler
5. depth_camera

A sensor's position and orientation is specified in global coordinates using and XYZ vector and Euler angles (roll, pitch, yaw).

The following is the specification of one break_beam sensor

#!yaml
sensors:
  break_beam_1:
    type: break_beam
    pose:
      xyz: [1.6, 2.25, 0.95]
      rpy: [0, 0, 'pi']

The following is the specification of both a break_beam and logical_camera sensor.

#!yaml

sensors:
  break_beam_1:
    type: break_beam
    pose:
      xyz: [1.6, 2.25, 0.95]
      rpy: [0, 0, 'pi']
  logical_camera_1:
    type: logical_camera
    pose:
      xyz: [1.21816, 3, 2]
      rpy: ['-pi', 'pi/2', 0]

Visualizing sensor views

By default, the view of the sensors in the Gazebo simulation will not be displayed. Enabling the sensor visualization may be useful while you are decided where to place sensors in the world. You can enable sensor visualization by adding --visualize-sensor-views to the gear.py invocation.

Reading sensor data

This is covered by the sensor interface tutorial.

Competition configuration file

Each trial of the competition is specified using a separate configuration file. A number of example trials are provided with the ARIAC software in the config directory. You can find the location of the config directory by running:

echo `catkin_find --first-only --share osrf_gear`/config

Each config file has a description of its behavior at the top of the file, e.g.:

$ head `catkin_find --first-only --share osrf_gear`/config/sample_interruption1.yaml
# In this scenario:
# - There are two orders of one shipment each:
#   - The second will interrupt the first at a time that is convenient for the second order.
#   - Teams can choose to re-purpose the products in the tray for the new order.
#   - After the second order is complete, the first order is to be resumed.
...

These config files can be used to practice with the various agility challenges.

Custom competition configuration files

During the competition, competitors will not have control over the settings in this configuration file. However, you may find that modifying the settings assists you during system development.

Various settings can be specified, including:

1. The products specified in the orders.
2. The models in each bin (which products, the configuration).
3. Which products are faulty products.
4. What causes the second order to be announced.
5. Which products are dropped (forthcoming).

There are also some features that have been specifically implemented for use in development, like spawning models in various reference frames.

Here is a sample development trial configuration file, which explains how you can modify all of the aforementioned settings.

Improving real-time factor during development

The real-time factor of a scenario is impacted by the number of models in the environment. For users experiencing low real-time factors, reducing the number of products that are in the scenario will help.

• If you are focusing on grasping products from the bins, you can set belt_population_cycles to 0 to avoid spawning parts on the conveyor belt.
• If you are focusing on grasping products from a particular bin, you can comment out the other bins listed in models_over_bins to temporarily not spawn them.