Wiki
Clone wikiariac / 2017 / configuration_spec
This page describes how to configure the process center simulation environment by selecting and placing sensors and a robot arm.
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.
Competitor configuration file
As a competitor, you are allowed to select the quantity, type, and location of sensors.
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:
- break_beam
- proximity
- logical_camera
- laser_profiler
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]
Initial positioning and joint states of the robot arm that is automatically included in the workcell environment is not under participants' control.
Competition configuration file
Each trial of the competition is specified using a separate configuration file. 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:
- The parts specified in the orders.
- The models on the conveyor belt (which parts, where, how many).
- The models in each bin (which parts, the configuration).
- Which parts are faulty parts.
- What causes the second order to be announced.
- Which parts are dropped.
There are also some features which have been specifically implemented for use in development. These include:
- Automatically fill a kit tray with the kit specified in an order.
- Spawn models in various reference frames.
Here is a sample competition trial configuration file (based off qual2a.yaml
and qual3b.yaml
), 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 parts that are in the scenario will help.
- If, for example, you are focusing on grasping parts from the conveyor belt, you can set
insert_models_over_bins
tofalse
to temporarily not spawn parts in the storage bins. - If you are focusing on grasping parts from the bins, you can set
belt_population_cycles
to0
to temporarily not spawn parts on the conveyor belt. - If you are focusing on grasping parts from a particular bin, you can comment out the other bins listed in
models_over_bins
to temporarily not spawn them. - If you are focusing on placing parts in a particular AGV, you can manually delete the other AGV from the environment when the scenario starts.
Updated