asam-oss/osc-alks-scenarios

ALKS scenario interpretation in OpenSCENARIO

osc-alks-scenarios's Issues

Add a solution for running on Linux

Most developers working on Automated Driving stacks are using Linux as their desktop operating system because 'everything just works'. Would it be possible to also add instructions and support for running on Linux x86_64?

mixture of entity refs for cut-in scenarios, false unit for deceleration?

Hi,

1. in Cut-In scenarios the entity ref of Cut-In story is well defined as CutInVehicle. But the entity ref inside this story of the triggering entities is ego. Would it be not also correct and more consistent to switch the entity refs of triggering entities and relativeDistanceCondition?

2. In followLeadVehicle scenario the variable is called LeadVehicle_BrakeRate_Gx_max, which seems to lead to unit G, but it is directly the input of rate, thus I think the unit is mpss?

Kind regards,

Thaddäus

Lane ID parameters need to be of type integer

in the parameter declaraions for some scenarios lane IDs are defined. In their usage they need to be strings, but this doesn't work for constraints (e.g. 3 < LaneId < 5). Therefore the parameters should be defined as integer, so they can be used for checking constraints and within expressions. They would need to be implicitly converted to a string when they are used as string attribute for a laneID

AttributeError: Only OpenSCENARIO 1.0 is supported

Hi, I tried with my own custom .xosc file. My xosc file is created in openscenario 1.1 standard. I run the file in OSC-ALKS 0.4 release the attribute error is shown. please let me know how to solve this issue.

First action for swerving lead vehicle doesn´t end

The LaneOffsetAction of the lead vehicle in scenario 4.1_2 has continuous=true as attribute. This means, it doesn´t end after the offset has been reached. Therefore the following LaneOffsetActions would not start since their start conditions are that the previous action has ended.
The attribute continuous needs to be "false" for all LaneOffsetActions.

UN No.157: Update to 130km/h

There has been an update on the regulation regarding the upgrade from the previous limit of 60km/h to 130km/h. I guess we need a bigger task force to upgrade to these requirements I guess? see here

trigger conditions correct?

Hi,

if I understand you correctly, then you are focusing on xosc v1.1 instead of v1.0.
If so, then you should use for many triggers lessOrEqual instead of lessThan (e.g. distances) and greaterOrEqual instead of greaterThan (e.g. start time). What do you mean?

Kind regards,

Thaddäus

Handle variation of curvature of road

Driver model behaviour from ECE regulation

Hi,

is it on your list to implement also the driver model from ECE regulation (including the jerk times, the lateral movement possibilities until perception, perception time, risk evaluation time, ... and also the AEB as baseline with its jerk time, delay and 0.85G deceleration, ...) as baseline for the comparison of the results?

Kind regards,

Thaddäus

Steering amount in axle definition should be in radians

This looks like a value in degrees, while the standard specifies it should be in radians.
<FrontAxle maxSteering="30" wheelDiameter="0.8" trackWidth="1.68" positionX="2.98" positionZ="0.4" />

maxSteering | double | 1..1 | XSDattribute | Maximum steering angle which can be performed by the wheels on this axle. Unit: rad; Range: [0;PI]

Add missing usage guideline and configuration files for OpenPass 0.7

Usage with OpenPASS is not documented yet.

Create functions

Hi , base on your structure you have made I am trying to replicate for another functions , still not able to understand how to implement the functions (reaction) , for now created simple scenario (Open scenario , esmini ..) , how did you ? I did not know where to raise my question as it is not issue

XML validation failed

Hi I tried to execute the supported osc files in Carla 0.9.11 (same version for scenario runner), however the xmlschema validator is throwing back errors. I tried the 4.1.1 (free driving scenario), and get an error at this first instance (I think there could be more incompatibility later on the osc file as well)

xmlschema.validators.exceptions.XMLSchemaValidationError: failed validating <Element 'ParameterDeclaration' at 0x7f54c24c36b0> with XsdElement(name='ParameterDeclaration', occurs=[0, None]):

Reason: character data is not allowed because the type's content is empty

Schema:

  <xsd:element xmlns:xsd="http://www.w3.org/2001/XMLSchema" maxOccurs="unbounded" minOccurs="0" name="ParameterDeclaration" type="ParameterDeclaration" />

Instance:

  <ParameterDeclaration name="Ego_InitSpeed_Ve0_kph" parameterType="double" value="60.0">
    <ConstraintGroup>
      
      <ValueConstraint rule="greaterThan" value="0.0" />
      <ValueConstraint rule="lessOrEqual" value="60.0" />
    </ConstraintGroup>
  </ParameterDeclaration>

Test scenarios with CARLA 0.9.13

CARLA 0.9.13 is released with improved OpenSCENARIO 1 support. We need to test how many scenarios we can now run with it (and check, if OSC 1.1 is supported)

Use of 'sinusoidal' dynamicsShape and 'rate' dynamicsDimension

Hello, we noticed that a few ALKS scenarios define a LaneChangeAction with, among other things, the following LaneChangeActionDynamics: dynamicsShape="sinusoidal", dynamicsDimension="rate". According to the OpenSCENARIO standard, the "rate" value is only used for the dynamicsShape="linear". Now I would like to ask why this combination is used e.g. in the ALKS_Scenario_4.4_1_CutInNoCollision_TEMPLATE.xosc? Thank you in advance!

Add copyright to header of all files (scenarios, catalogs, roads...)

Replace bat files with single script

ALKS Controller activation too late

For the activation of the ALKS controller the condition is SimulationTime=10000 sec. This raised some questions, since the scenario doesn't last that long.
The idea is that this value has to be changed to e.g. 1 sec., if an external controller is connected to the environment simulation.
Maybe there are more intuitive ways to model this without having to use further OpenSCENARIO 1 features. (e.g. an additional parameter "external_ego_control" with type="boolean" and default value="false" and an additional ParameterValueCondition with parameter="external_ego_control" rule="equalsTo" value="true" would also work, but not used yet in the scenarios).

Naming of ALKS controller elements is not consistent

The conditions within the ActivateALKSControllerStory do not have a consistent naming. They are named ActivateALKSControllerStart and ActivateALKSControllerStartCondition instead of ActivateALKSControllerActCondition and ActivateALKSControllerEventCondition

Usage of environment variables / Missing options to manually set filepath in "run_Scenarios.bat"

While I see the benefit in using environment variables in "run_Sceanrios.bat", defining or changing them requires administrative rights on Windows machines.

The usability of the script could be improved by adding options that allow the user to set the directory path manually,
e.g. do a
SET ESMINI=My\Path\to\esmini\binary\directory
or a
SET OPENPASS=My\Path\to\openpass\binary\directory

A script for linux based systems (as reqested in #27 ), should provide the same functionality ... ;)

esmini 2.0

Tomorrow (Friday) afternoon is planned release of esmini 2.0. Most significant news is support of OSC controller concept. A positive side effect is that we could reduce the palette of "applications". As you also pointed out, the interactive, external and hybrid modes are now implemented as controllers instead of specific application features.
Now, this led us to take the opportunity and do some desired restructuring and renaming of esmini modules. So far so good. Downside is broken backward compatibility.

There are two changes affecting your project:

1. "EgoSimulator" renamed to "esmini"
2. Trails is off by default. Instead a single argument "--trails" will turn them on. So the script option "--trails off" will actually turn them on and the "off" part will be parsed as an unknown argument and put a warning on stdout. However, esmini will run nonetheless, with trails.

First issue I've solved short term by providing a copy of esmini(.exe) named EgoSimulator(.exe). Let's say that we provide this copy during a deprecation period of a few releases.
Second issue is not a showstopper. Actually I find the trails useful since it gives a sense of speed and motion forward along the OpenDRIVE features lines. So, even though not critical, my suggestion is to eventually change into "--trails".

I've checked all 15 ALKS scenarios of yours. As far as I can see, they run all fine in esmini 2.0 BETA.

This is a heads-up in order to dampen the surprise of esmini 2.0 release tomorrow afternoon. Link to a beta version in case you would like to test before release.

Let me know if you see any issues that I did not think of!