... | ... | @@ -53,16 +53,24 @@ A sub-file should always have `World`, `Agents`, or `Policies` as its main eleme |
|
|
|
|
|
Most of the examples in our [*examples*](https://gitlab.inria.fr/OCSR/UMANS/-/tree/master/examples) folder also use sub-files. For instance, the [*examples/agents*](https://gitlab.inria.fr/OCSR/UMANS/-/tree/master/examples/agents) folder contains agent layouts, and these are used by the main files in the [*examples*](https://gitlab.inria.fr/OCSR/UMANS/-/tree/master/examples) folder.
|
|
|
|
|
|
# 'Simulation' block
|
|
|
# Coordinate system
|
|
|
|
|
|
The `Simulation` block has the following **attributes**:
|
|
|
UMANS uses a 2D Euclidean coordinate system. The simulation world is a plane (possibly with polygonal obstacles), and agents are modelled as disks that move on this plane. Units are to be interpreted as meters.
|
|
|
|
|
|
In the GUI, we draw the x-axis horizontally, with the positive x-axis pointing to the right. We draw the y-axis vertically, with the positive y-axis pointing upward. The screenshot below shows the starting situation of the `Circle15-RVO` scenario, with an indication of what the coordinates mean.
|
|
|
|
|
|
![coordinates](uploads/d209cfce20f2a1f6b999b3d4caaf4c69/coordinates.png)
|
|
|
|
|
|
# 'Simulation' element
|
|
|
|
|
|
The `Simulation` element has the following **attributes**:
|
|
|
|
|
|
| Attribute name | Mandatory? | Type, constraints | Description | Default value |
|
|
|
| ------ | ------ | ------ | ------ | ------ |
|
|
|
| `delta_time` | Yes | float, >0 | The length of a simulation time step, in seconds. | *none* |
|
|
|
| `end_time` | Yes (Console application) / No (GUI, Dynamic library) | float, >0 | The time (in seconds) after which the simulation should automatically stop. Only used in the console application. | *none* |
|
|
|
|
|
|
The `Simulation` block has the following **child elements**:
|
|
|
The `Simulation` element has the following **child elements**:
|
|
|
|
|
|
| Element name | Number of occurrences | Description |
|
|
|
| ------ | ------ | ------ |
|
... | ... | @@ -70,7 +78,7 @@ The `Simulation` block has the following **child elements**: |
|
|
| `Agents` | 1 | See below |
|
|
|
| `Policies` | 1 | See below |
|
|
|
|
|
|
# 'World' block
|
|
|
# 'World' element
|
|
|
|
|
|
The `World` element has the following **attributes**:
|
|
|
|
... | ... | @@ -84,8 +92,21 @@ The `World` element has one optional **child element** named `Obstacles`. |
|
|
|
|
|
The `Obstacles` element has 0 or more **child elements** named `Obstacle`.
|
|
|
|
|
|
An `Obstacle` element describes a single obstacle in the environment.
|
|
|
### 'Obstacle' element
|
|
|
|
|
|
An `Obstacle` element describes a single obstacle in the environment.
|
|
|
It has 3 or more child elements named `Point`. Each `Point` element has two floating-point attributes `x` and `y`. These `Point` elements describe the obstacle's boundary vertices in counter-clockwise order. The first vertex should not be replicated at the end. For example, the following XML block describes a square obstacle measuring 2 by 2 meters:
|
|
|
|
|
|
```
|
|
|
<Obstacle>
|
|
|
<Point x="-1" y="-1"/>
|
|
|
<Point x="1" y="-1"/>
|
|
|
<Point x="1" y="1"/>
|
|
|
<Point x="-1" y="1"/>
|
|
|
</Obstacle>
|
|
|
```
|
|
|
|
|
|
UMANS will treat each boundary segment of each obstacle separately. It is technically allowed to create overlapping obstacles. Obstacles with holes are not allowed, but you can replicate them by creating several smaller obstacles with touching boundaries.
|
|
|
|
|
|
# 'Agents' block
|
|
|
|
... | ... | |