drawtonomy vs esmini
Det här innehållet är inte tillgängligt på ditt språk än.
esmini
Section titled “esmini”esmini is the open-source reference simulator for ASAM OpenSCENARIO 1.x. It’s developed in the open by maintainers in the Swedish ADAS community and has become the most widely used minimal OpenSCENARIO 1.x runtime — clean, fast, and predictable enough that essentially every OpenSCENARIO authoring tool (drawtonomy included) treats esmini as the reference it validates against. The drawtonomy team has nothing but respect for the work esmini’s maintainers have put into building and stewarding a high-quality open runtime over many years.
What esmini covers:
- A native runtime that simulates the OpenSCENARIO 1.x storyboard: acts, sequences, maneuvers, conditional triggers, parameter declarations, controllers.
- A 3D viewer (OpenSceneGraph) and a 2D bird’s-eye view, plus headless mode for CI.
- C++ / Python / JavaScript (WebAssembly) APIs, so you can embed it inside a larger simulator, validator, or training pipeline.
- Built-in vehicle models, so a stock
.xosc+.xodrsimulates without having to ship.osgbassets. - A small, fast, predictable binary that fits well in scenario regression suites.
If you need OpenSCENARIO 1.x simulation semantics — conditional triggers, parameter sweeps, custom controllers, full storyboard execution — esmini is the standard, and there’s no good reason to reach past it.
Licensing
Section titled “Licensing”esmini is open-source under the Mozilla Public License 2.0. The fact that drawtonomy can ship a browser-based OpenSCENARIO simulator at all is directly thanks to that license and the esmini team’s choice to make their work openly available. drawtonomy follows MPL-2.0’s notice and file-level copyleft requirements for the esmini-WASM binary it bundles.
How drawtonomy relates to esmini
Section titled “How drawtonomy relates to esmini”drawtonomy is a free, browser-based whiteboard for driving scenarios. Its in-browser simulator is built on top of esmini compiled to WebAssembly — the simulation core that executes the storyboard is esmini itself, with the same parser, the same storyboard semantics, and the same vehicle state. None of the simulation correctness is drawtonomy’s — it belongs to esmini and its maintainers.
What drawtonomy adds is the canvas-native shell around that
runtime: frame-accurate seek, the Follow Ego camera that pans
with the ego vehicle, Path / Footprint ghost trails, one-click
.webm export, and the same canvas you also author scenarios on.
That’s the layer drawtonomy is contributing on top — not a fork, not
a re-implementation.
The split:
| Question | esmini (native) | drawtonomy (browser simulator built on esmini-WASM) |
|---|---|---|
| Run the OpenSCENARIO 1.x storyboard (acts, triggers, conditions, controllers) | ✅ esmini runtime | ✅ esmini runtime (same engine, WebAssembly build of esmini itself) |
| 3D OpenSceneGraph viewer | ✅ built-in | ❌ 2D canvas only |
| Headless mode for CI / regression sweeps | ✅ headless flag | ❌ browser shell |
| C++ / Python APIs | ✅ | ❌ JS only (esmini-WASM) |
| Frame-accurate seek and step | depends on viewer | ✅ scrubber + arrow keys |
| Ego-following camera (Follow Ego — view pans with the ego) | possible via flags | ✅ one-toggle |
| Ghost trails (Path / Footprint) | not built-in | ✅ configurable interval |
Record the run to .webm for a slide / PR / social | external screen capture | ✅ in-app export, aspect-ratio presets |
| Install required | C++ build or release binary | ❌ runs in any modern browser |
| Sensor simulation (camera / LiDAR / radar) | ❌ | ❌ |
The two flows fit end-to-end. drawtonomy’s
OpenSCENARIO bundle export produces a zip
with the .xosc, the .xodr, and a run.sh that runs the scenario
in your local esmini. Same standards
(OpenSCENARIO +
OpenDRIVE), same simulation core, two shells.
Why use the browser shell at all
Section titled “Why use the browser shell at all”If esmini is the runtime in both cases, why does the browser shell matter?
- Triage a CI failure without an esmini install on the machine
you’re on — laptop, phone, borrowed desktop. You don’t always have
the build toolchain where you need to look at a
.xosc. - Code review a scenario PR when the reviewer doesn’t run esmini locally.
- Teach OpenSCENARIO without making the audience install anything.
- Record a
.webmof the simulation for a slide, a bug report, or a social post — drawtonomy ships 16:9, 9:16, 1:1, 4:3, and Free aspect-ratio presets directly in the export popover. - Eyeball a generated scenario from scenariogeneration or Scenic before committing to a full simulator run.
Conversely, when to skip the browser shell and run native esmini:
- You want the OpenSceneGraph 3D viewer.
- You’re running a CI sweep over hundreds of scenarios.
- You want to drive esmini from Python or C++ in a larger pipeline.
- You’re embedding esmini in another simulator.
In the same OpenSCENARIO ecosystem
Section titled “In the same OpenSCENARIO ecosystem”drawtonomy and esmini sit on the same set of ASAM standards — OpenSCENARIO and OpenDRIVE — and on the same simulation core. drawtonomy literally calls esmini under the hood; without the esmini project, drawtonomy’s browser-based OpenSCENARIO simulator would not exist. The OpenSCENARIO community is a small one, and the tools in it — esmini, drawtonomy, RoadRunner, Truevision Designer, LaneMaker, scenariogeneration — all play different roles in the same workflow. esmini is the simulator; drawtonomy is the browser shell built on top of it (plus a whiteboard you can author and sketch on).
Acknowledgement
Section titled “Acknowledgement”drawtonomy’s OpenSCENARIO simulator exists because the esmini project exists and chose to publish under an open licence. Huge thanks to the esmini maintainers and contributors for the years of work that went into building a clean, fast, well-documented OpenSCENARIO 1.x runtime — and for being a steady reference for the whole OpenSCENARIO community. If you use drawtonomy’s browser-based OpenSCENARIO simulator mode, please consider also starring esmini on GitHub and supporting the project upstream.