There are some libraries available online, that can manipulate OpenDRIVE files to some degrees.

There’s one thing left about OpenDRIVE: how do we actually read the file from our simulator? How do we parse it and extract data from it? At least two companies specialize in that ( Atlatec, 3D Mapping), but it’s not cheap, and you only get the OpenDRIVE, so no 3D scene to use in your simulator. It’s also worth mentionning TrianGraphics, which has more or less the same feature set as RoadRunner, but seems less intuitive to work with.Īnother really different approach is to scan real road sections, and generate OpenDRIVE for it. This certainly is the future for scene creation, but this service is quite expensive right now. An extension is also available, called RoadRunner Scene Builder, which can automatically create scenes from HERE HD Maps.

In the tool, you can either create a custom road network that’s tailored to your needs, or you can use the various GIS features within the tool to import real-world data. It’s a scene creation tool, which exports both the 3D part of the scene and its OpenDRIVE description. Our favorite tool is Mathwork’s RoadRunner (which, by the way, is bundled with their Campus licence). Now that we have a clear view of what we need OpenDRIVE for, how do we get our hands on such files?

Automatic generation and positionning of traffic lights at intersections.

Pedestrians that automatically walk around their block, to add some life to our scenes.

A Virtual Driver, which can drive any car on any road network, while being controlled with high level goals, such has “keep your lane” or “turn left at the next intersection”.

With such description at hand, we’ve been able to implement some major features of our platform, that we’ll detail later in this blog. Having access to the complete road description empowers the scenario designer to easily control any actor within the scene. If your scenario involves following a lead car, you want to be able to simply set the lead car to “keep its lane”, without having to manually describe the curve it has to follow. When you’re building your experiment, you create some situations which involve other actors, such as cars or pedestrians. However, roads are never uniform and straight, so we need to have access to the actual geometry of them to compute those values.Īnother reason is scenario creation. If the road is perfectly uniform and straight, computing those is simple. Some of that data includeĪll of those values have one thing in common: they rely on the road geometry. As such, we’re interested in data that will be generated when subjects are driving. One answer lies in the reason why we use driving simulators: to run experiments. Any road network in the world can be described in the OpenDRIVE format. This includes road geometries, marking, lanes, borders, etc. Initially developped through the PEGASUS project, OpenDRIVE was then transfered to ASAM, where its development continues.Īn OpenDRIVE file follows the XML standard and contains all relevant information describing a road network. But in driving simulators, we need much, much more information than that. Google Maps, OpenStreetMap), you might notice that you don’t get much description beyond “there’s a road here”. If you’re familiar with traditional mapping tools (e.g. OpenDRIVE defines a file format for the precise description of road networks

Opendrive palo alto