Skip to content

1.18.0

Compare
Choose a tag to compare
@github-actions github-actions released this 24 May 06:37
· 2977 commits to master since this release

Description

Abstract

This PR adds a TrafficSource class for the OpenSCENARIO TrafficSourceAction and an API function defineTrafficSource that creates a TrafficSource.

Background

Scenario simulator does not fully support OpenSCENARIO specification, meaning not all features of OpenSCENARIO are implemented.
In order to increase the support for OpenSCENARIO new features have to be implemented. One such feature is the TrafficSourceAction.
Changes made in this PR enable adding a TrafficSource in the API of traffic simulator by calling the function API::defineTrafficSource.
For a full support of TrafficSourceAction, changes in the openscenario interpreter are also needed.

Details

These changes enable adding the TrafficSource from API of traffic simulator.
The TrafficSource can operate in several configurations.
These configurations specify how the entities are spawned. User defining a TrafficSource can choose to

  • Spawn only Pedenstrians
  • Spawn only Vehicles
  • Spawn both Pedestrians and Vehicles
    • In all these modes, Pedestrians are spawned on road and crosswalk and Vehicles are spawned only on road lanelets.
  • Require to spawn entities on lane (note: currently traffic simulator allows spawning vehicles only on lane, so turning this off is advisable only for TrafficSource spawning only Pedestrians) - if this is enabled, then the orientation will be aligned to the lane on which the entity is spawned.
  • Require to fit entity footprint inside the lane polygon (Note: enabling this adds computational cost, mainly when defining the TrafficSource. This should not make much of a difference, except for very large radiuses.)
  • Enable random orientation to be used for spawning - otherwise the TrafficSource.position orientation is used, and this orientation is used in all subsequent stages performed, including lane matching, which is orientation dependent.
    Please note, that turning this off will result in using the same orientation for all entities spawned. The orientation of requested spawn pose is - in the current implementation of traffic simulator - used for lanelet matching using a horizontal bar method (for more details, see here). This means that preserving the TrafficSource.position orientation will bias the spawning of entities to the lanes that have similar orientation as the TrafficSource.position. In some situations this may be a desired behavior, but for most use cases, when a random and uniform distribution is required this option should be enabled.

Spawned entities are randomly chosen from a list of provided "blueprints" with all required parameters and corresponding random distribution weights. User can define for example a TrafficSource that will spawn 2 Vehicles:

  • a bicycle with a random distribution weight of 1 and
  • a car with a random distribution weight of 3.

Such a TrafficSource will - on average - spawn 1 entity according to the bicycle "blueprint" every 3 entities spawned according to the car "blueprint".

Entities are spawned only when their whole footprint fits inside the TrafficSource circle.

The pose selection can be described with a diagram below:

image

All entities spawned by one TrafficSource have the same initial speed set.

The TrafficSource can have a spawn rate greater than the rate at which execute function is called.

TrafficSource only calls one of the spawn functions that it is provided, so if API::spawn allows spawning one entity in place where some other entity already exists (which is true at the time of this writing) then if such random position is selected, the entity will be spawned there.

As part of implementing TrafficSource, several cpp mock scenarios have been created.

References

INTERNAL LINK.

Destructive Changes

There are no destructive changes. The PR adds new feature. The only code that needed to be changed was that TrafficController::execute passes time information to traffic modules, which was necessary to enable spawning at a given rate.

Known Limitations

If TrafficSource is required to fit an entity bounding box into a lane polygon, then additional calculations of the lanelet polygon need to be performed. For a TrafficSource that has a lot of lanelets inside its spawning area, this can take some time. For this purpose, an example define_traffic_source_large scenario has been created, where the radius is set to 200m, and it takes approx 1.5s to initially calculate the lanelet polygons.
Please note that this calculation is performed only once for each TrafficSource and after that each spawn position selection is fast.

Related Issues