Known deviations from standards
This section lists known intentional differences between esmini behavior and the OpenSCENARIO XML, OpenDRIVE, and OSI standards. The list is not exhaustive (others could exist), and is subject to change at any time.
Unsupported features and partial support are tracked separately in osc_coverage.txt and odr_coverage.txt. Tool-specific properties and userData conventions are not considered as deviations.
Each deviation includes a Standard reference field for links to the relevant specification version and clause, table, or model element.
OpenSCENARIO XML
TeleportAction domains
esmini intentionally lets TeleportAction operate on both the lateral and longitudinal domains, to interrupt actions ongoing on a conflicting domain.
Example: A LaneChangeAction is ongoing when a TeleportAction is triggered for the same entity. In esmini, the ongoing lane change is cancelled because the teleport claims the lateral domain. This avoids continuing the original lane change after the entity has been moved to a new position, which most likely makes sense.
Standard reference: OpenSCENARIO XML v1.4.0 / Annex A (normative): Action tables. The TeleportAction row specifies "No" for both "Assigns longitudinal control strategy" and "Assigns lateral control strategy".
Omitted position attributes
When position attributes like z (elevation), pitch, or roll are omitted, esmini automatically aligns that component of the entity pose to the road surface. While standard OpenSCENARIO interpretations treat omitted coordinates as zero (0), esmini defaults to road alignment to streamline scenario creation for common use cases.
If a value of zero (0) is explicitly required, it must be specified directly in the OpenSCENARIO XML.
See link:See Positioning for details and examples.
Standard reference, example: OpenSCENARIO XML v1.4.0 / WorldPosition.
Trajectory interpolation and alignment
For convenience, esmini can derive orientation from the trajectory or road surface and smooth polyline corners. The motivation is to reduce the need to specify every angle and to help avoid discontinuities (in heading angle at polyline corners).
The polyline corner interpolation is a clear deviation from the standard OpenSCENARIO interpretation, and it can be disabled via option pline_interpolation.
The automatic calculation of omitted orientation from the trajectory or road surface is another deviation from the standard OpenSCENARIO interpretation. Note that any specified orientation values is interpreted as given, complying with the standard.
See Positioning / Trajectory interpolation and alignment for details and examples.
Standard reference: OpenSCENARIO XML v1.4.0 / Trajectories.
Initial acceleration in SpeedProfileAction
To preserve acceleration continuity, esmini uses the entity’s current acceleration at the start of SpeedProfileAction rather than assuming zero initial acceleration. The final acceleration is zero.
Standard reference: OpenSCENARIO XML v1.4.0 / SpeedProfileAction.
Heading behavior in Road vs Lane Position
When heading is omitted, RoadPosition aligns an entity with the road direction (the s-axis), while LanePosition aligns it with the lane’s driving direction. A relative heading is applied from the corresponding default direction. The same behavior applies to RelativeRoadPosition and RelativeLanePosition.
This distinction supports both lane-aligned placement and cases where lane direction should not determine heading, such as an overtake starting in a neighboring lane. See the visual examples and issues #385 and #228 for more background.
Absolute heading is not affected by the default direction and will be applied as specified for both RoadPosition and LanePosition.
See more info in Heading behavior in Road vs Lane Position.
The specified behavior in the standard is not super clear, but to our understanding relative heading should be applied from the direction of the road s-axis, for both RoadPosition and LanePosition.
Standard reference: OpenSCENARIO XML v1.4.0 LanePosition and RoadPosition.
OpenDRIVE
No known deviations are currently documented. This does not imply complete feature coverage or correctness.
esmini-specific userData extensions, such as marking lateral offset, object color, and texture mapping, are documented in Scenario features / Road objects. These use an extension mechanism and are not classified as deviations here.
OSI
Static-content reporting
By default, esmini reports and logs static objects only once rather than repeating them in every frame. Objects created during initialization appear in the first frame; static MiscObjects added later appear in the frame in which they are created.
The motivation behind this approach is to increase simulation performance and reduce osi logfile size.
See esmini lib programming / OSI settings and OSI data via API call details, e.g. how to disable this optimization.
Standard reference: OpenSimulationInterface v3.5.0 / Ground truth.