Export nach OpenDRIVE / OpenSCENARIO / esmini

drawtonomy wandelt eine von Hand gezeichnete Szene in ein ASAM OpenDRIVE (.xodr) Straßennetz und ein OpenSCENARIO (.xosc) Szenario um — gebündelt in einem einzigen ZIP, das sich direkt in esmini wiedergeben lässt.

Die Konvertierung ist bewusst grundlegend gehalten: Sie deckt die Formen ab, die sich sauber auf das ASAM-Datenmodell abbilden lassen, und lässt alles andere weg. Diese Seite dokumentiert präzise, was konvertiert wird, was das exportierte Fahrzeug tatsächlich tut und was außerhalb des Umfangs liegt — damit die Ausgabe keine falschen Erwartungen weckt.

Der vollständige Round-Trip im Video

Das folgende Video zeigt einen einzigen Durchgang ohne Schnitte: Kreuzung zeichnen, Pfad zeichnen, Fußabdrücke erzeugen, esmini-ZIP exportieren, exportiertes .xosc in esmini wiedergeben.

Ein Durchgang ohne Schnitte: Kreuzung zeichnen, Pfad zeichnen, Fußabdrücke erzeugen, esmini-ZIP exportieren, exportiertes .xosc in esmini wiedergeben.

Export aus dem Editor

Es gibt einen ASAM-Exporteinstiegspunkt. drawtonomy bietet keine separaten Menüpunkte für .xodr und .xosc — beide Dateien werden gemeinsam erzeugt und in einem ZIP verpackt.

1. Zeichnen Sie Ihre Szene (Fahrspuren, eine Kreuzung, Fahrzeuge, einen Pfad …).
2. Öffnen Sie das Menü → Export → .zip (esmini).
3. Geben Sie auf Aufforderung einen Basisnamen ein (Standard: drawtonomy-<Datum>).
4. Es wird eine <Name>.zip heruntergeladen, die <Name>.xodr, <Name>.xosc und die vom Szenario referenzierten esmini-3D-Modell-Assets enthält.

Exportiert wird stets die gesamte aktuelle Seite — einen „Nur-Auswahl”-Modus gibt es für das ASAM-Ziel nicht.

Wiedergabe in esmini

unzip drawtonomy-2026-05-30.zip
cd drawtonomy-2026-05-30
esmini --osc drawtonomy-2026-05-30.xosc --window 60 60 1024 768

Das Fahrzeug fährt entlang der orangefarbenen Linie — diese Linie ist die FollowTrajectoryAction, die aus dem gezeichneten Pfad erzeugt wurde.

Was wird konvertiert

In OpenDRIVE (.xodr)

drawtonomy-Form	OpenDRIVE-Element	Hinweise
Lane	ein <road>	1 Fahrspur = 1 unabhängige Straße
Traffic light	<signal> an der nächstgelegenen Straße	nur Typ Fahrzeug / Fußgänger
Crosswalk	<object type="crosswalk">	senkrecht zur Straße platziert
Polygon (≥ 3 Punkte)	<object type="patch"> mit <outline>	füllt Kreuzungs- und Flächenvisualisierungen

Alles andere — Fahrzeuge, Fußgänger, freistehende Punkte, freie Linien, Text, Bilder — wird nicht in die .xodr geschrieben.

Zum genauen Umfang jeder Straße:

• Geometrie ausschließlich als Geraden. Die Straßenreferenzlinie wird aus den linken und rechten Fahrspurbegrenzungen abgetastet und als <line>-Segmente ausgegeben. Es werden weder arc-, spiral- noch poly3-Geometrien erzeugt.
• Festes Fahrspurlayout. Jede Straße erhält genau eine linke Fahrspur (id=1), eine Mittelspur (id=0) und eine rechte Fahrspur (id=-1), alle mit type="driving". Mehrspurige Straßen und mehrere Fahrspurabschnitte werden nicht abgebildet.
• Fahrbahnmarkierungen sind fest auf solid white 0.13 m kodiert.
• Keine Kreuzungen. Jede Straße trägt junction="-1", und es wird kein <junction>-Element erzeugt. Kreuzungen werden ausschließlich durch den Polygon-Patch (Visualisierung) und durch Vorgänger-/Nachfolger-Links aus den next- / prev-Verbindungen der Fahrspur vermittelt (nur der erste Eintrag).
• Keine Höhen- oder Querneigungsprofile — elevationProfile und lateralProfile werden leer ausgegeben (ebene, planare Straßen).
• Der Maßstab ist fest bei 16,67 px/m; der geografische Ursprung liegt bei 0.

In OpenSCENARIO (.xosc)

drawtonomy-Form	OpenSCENARIO-Element
Vehicle	ein <ScenarioObject> (<Vehicle> oder <Pedestrian>)
Path footprint (das führende Fahrzeug)	eine <FollowTrajectoryAction>

Ein „Pedestrian” ist eine Vehicle-Form, deren Template-Name einem Fußgänger-/Walk-Muster entspricht — sie wird als <Pedestrian> statt als <Vehicle> ausgegeben. Fahrspuren, Zebrastreifen, Ampeln und freie Linien werden nicht in die .xosc geschrieben.

Das exportierte Szenario ist bewusst minimal gehalten:

• Das einzige dynamische Verhalten ist FollowTrajectoryAction — eine zeitgestempelte Polylinie. Es gibt keine Geschwindigkeitsaktionen, Fahrspurwechsel, Ampelreaktionen, Kollisionsvermeidung oder Interaktionsbedingungen.
• Jede bewegliche Entität startet bei SimulationTime ≥ 0, und das Szenario besitzt einen festen StopTrigger bei 60 s.

Wie ein Pfad-Footprint zur Fahrzeugbewegung wird

Dies ist der Kern des dynamischen Exports — daher lohnt sich eine genaue Betrachtung.

Ein Path ist eine von Ihnen gezeichnete Linie; Footprints sind Geisterkopien eines Fahrzeugs, die entlang dieser Linie angeordnet sind (die Spur, die Sie im Editor sehen). Beim Export gilt:

1. Nur der vorderste Footprint (der erste) wird zu einem beweglichen <ScenarioObject>. Die nachfolgenden Geister sind eine Editor-seitige Vorschau und werden verworfen — Sie erhalten ein Fahrzeug, das den gesamten Pfad abfährt, keine Fahrzeugkolonne.
2. Die Steuerpunkte des Pfads werden zu den Trajektorie-Stützpunkten in Weltkoordinaten (ENU) in Metern.
3. Jedem Stützpunkt wird ein time-Wert zugewiesen; das Ergebnis wird als <Trajectory> → <Polyline> aus <Vertex time="…">-Elementen in eine <FollowTrajectoryAction> geschrieben.

Geschwindigkeit ist fest — das ist die wichtigste Einschränkung

Die Trajektorie wird mit einer fest kodierten Geschwindigkeit von 10 m/s (≈ 36 km/h) berechnet. drawtonomy besitzt kein Geschwindigkeitsfeld in der Benutzeroberfläche, und der Exporter überschreibt diesen Standardwert nie. In esmini meldet die Entität stets etwa 36 km/h — unabhängig davon, was Sie gezeichnet haben. Die Geschwindigkeit lässt sich nicht einstellen; stattdessen steuern Sie die zeitliche Verteilung über das Footprint-Layout, wie im nächsten Abschnitt beschrieben.

Zwei Zeitmodi

Ob der „Variable positioning”-Schalter des Pfads aktiviert ist, entscheidet, wie die Zeit entlang der Trajektorie verteilt wird:

• Gleichmäßig (Schalter AUS) — Footprints sitzen in gleichmäßigen Bogenlängen-Intervals, und die Zeit ergibt sich aus Distanz / 10 m/s. Die Bewegung erfolgt mit konstanter Geschwindigkeit. Eine Änderung des Interval-Werts ändert nur die Anzahl der geschriebenen Stützpunkte (Abtastdichte); Form und Gesamtdauer des Pfads bleiben unverändert.
• Variabel (Schalter EIN) — Jeder Footprint ist an einer bestimmten Position entlang des Pfads fixiert, und die Gesamtdauer wird in gleiche Zeitscheiben zwischen den Footprints aufgeteilt. Wo Footprints eng zusammenliegen, fährt das Fahrzeug langsam; wo sie weit auseinander liegen, fährt es schnell. Dies ist der einzige Weg, die effektive Geschwindigkeit entlang der Strecke zu variieren.

Was Sie bearbeiten ↔ was sich in der .xosc ändert

Editor-Aktion	Auswirkung auf den Export
Pfad-Steuerpunkt verschieben	Koordinaten des Trajektorie-Stützpunkts + Gesamtdauer (Länge ändert sich, Geschwindigkeit bleibt bei 10 m/s)
Footprint im Variable-Modus ziehen	Normierte Position dieses Footprints → time des Stützpunkts → lokale (effektive) Geschwindigkeit dieses Abschnitts
Variable positioning umschalten	Wechsel zwischen Gleich-Zeit- und Gleich-Geschwindigkeits-Verteilung
Interval ändern (gleichmäßiger Modus)	Nur Anzahl der Stützpunkte — Trajektorienform und Geschwindigkeit bleiben unverändert
Anchor ändern	Nur Footprint-Zeichenversatz — kein Einfluss auf die exportierte Trajektorie
Fahrzeug-Template wechseln	vehicleCategory, 3D-Modell, Bounding-Box-Höhe, Performance-Voreinstellung
Fahrzeug (w, h) skalieren	BoundingBox-Abmessungen und Achsgeometrie
Fahrzeug drehen	Anfangsausrichtung (nur wenn das Fahrzeug keine Trajektorie hat)
Fahrzeug verschieben	Init-WorldPosition (auf den Trajektorie-Startpunkt eingerastet, falls eine vorhanden ist)

Kurz gesagt: Einen Footprint im Variable-Modus entlang des Pfads zu verschieben ändert den exportierten Geschwindigkeitsplan, weil damit der betreffende Abschnitt neu getaktet wird. Ihn im gleichmäßigen Modus zu verschieben oder den Anchor zu ändern, hat keinen Effekt.

Fest kodierte Werte

Der Vollständigkeit halber: Die folgenden Werte stammen aus festen Tabellen oder Konstanten und lassen sich nicht bearbeiten — Fahrzeugkategorie und Performance-Voreinstellungen, 3D-Modellpfade, Fahrzeughöhe nach Kategorie, Achsgeometrie (aus Größe abgeleitet), Following-Modus (position), der 60-s-StopTrigger und — am wichtigsten — die Trajektoriengeschwindigkeit von 10 m/s.

Programmatischer Export

Der Exporter ist Teil von @drawtonomy/sdk und läuft ohne den Editor. Anders als das Menü erlaubt das SDK auch den getrennten Export beider Dateien:

import { exporter, createSnapshot } from '@drawtonomy/sdk'

const snapshot = createSnapshot(shapes)

// Gebündelt (entspricht dem Menü):
const { blob, baseName } = exporter.buildEsminiZip(snapshot, {
  baseName: 'my-scene',
})

// Oder jedes Format einzeln:
const xodr = exporter.exportToOpenDrive(snapshot)
const xosc = exporter.exportToOpenScenario(snapshot, {
  xodrFilename: 'my-scene.xodr',
})

Die vollständige API und alle Erweiterungspunkte finden Sie in der Exporter-SDK-Referenz.

Ausgegebene Versionen

Format	Version
OpenDRIVE	1.8
OpenSCENARIO	1.3

Unterstützter Umfang auf einen Blick

Unterstützt: Geraden-Straßen aus Fahrspuren; Ampeln, Zebrastreifen und Kreuzungs-Patches als OpenDRIVE-Objekte; ein Fahrzeug pro Pfad, das einer getakteten Trajektorie folgt; ein direkt abspielbares esmini-ZIP.

Noch nicht unterstützt: OpenDRIVE-Kreuzungen, Kurvengeometrien, mehrspurige Straßen, Straßenhöhen; OpenSCENARIO-Geschwindigkeitsaktionen, Fahrspurwechsel, Ampellogik, Mehrfahrzeug-Interaktionen oder individuelle Fahrzeuggeschwindigkeiten.

Siehe auch

• Exporter-Architektur — was die Pipeline zwischen Snapshot und Datei macht.
• Ein Zielformat hinzufügen — CARLA, SUMO, Unity oder beliebige andere Formate einbinden.