The problem
Most simulation content represents well-marked Western roads, while Indian roads often have faded or absent markings, speed breakers, unprotected junctions and dense mixed traffic. ADAS functions tested only on tidy roads may fail in these conditions. This project creates scenes that capture those features so that functions can be tested against them in simulation.
Objectives
- Catalogue Indian road features that matter for ADAS testing.
- Model at least three scenes in RoadRunner with realistic geometry and markings.
- Export scenes as ASAM OpenDRIVE and check them in MATLAB.
- Create traffic scenarios on the scenes and run an ADAS function on them.
- Compare function performance on Indian and well-marked scenes.
What you need
Tools and toolboxes
- RoadRunner — Authoring 3D road scenes: roads, lanes, junctions, markings, elevation and props.
- RoadRunner Scenario — Placing actors and defining their paths and behaviours on the scenes.
- RoadRunner Asset Library — Additional props, signs and vehicles for realistic scenes.
- MATLAB with Automated Driving Toolbox — Importing OpenDRIVE roads into driving scenarios and running test logic.
- Simulink — Running the function under test in co-simulation with RoadRunner Scenario.
Software
- RoadRunner and RoadRunner Scenario
- MATLAB, Simulink and Automated Driving Toolbox
Extra parts and data
None beyond the software above.
Key concepts
- ASAM OpenDRIVE
- An open format that describes road networks: reference lines, lanes, junctions and markings. It lets a scene built in one tool be used by other simulators.
- Lane marking condition
- Markings can be solid, dashed, faded or missing. Lane-keeping and lane-detection functions depend heavily on them, so their condition is a key test variable.
- Mixed traffic
- Traffic containing cars, two-wheelers, three-wheelers, pedestrians and animals with weak lane discipline, typical of many Indian roads.
- Scene versus scenario
- The scene is the static road and surroundings; the scenario adds moving actors and events on top of it.
Step-by-step guide
- 1
Catalogue the road features
Using your own observations and images from the India Driving Dataset (IDD) as visual reference, list features that matter for ADAS: missing or faded lane markings, unpaved shoulders, speed breakers, roundabouts, T-junctions without signals, divider gaps used for U-turns, parked vehicles narrowing the road and two-wheelers filtering between lanes. Rank them by how likely they are to affect lane detection, braking or path planning, and pick three scenes that together cover the top features.
Checkpoint: A ranked feature list and three scene descriptions, each naming the features it contains.
- 2
Gather geometry references
For each scene, decide realistic dimensions: lane widths around 3–3.5 m, carriageway width, shoulder width, speed-breaker height and length, roundabout radius and junction corner radii. Take these from your own measurements of local roads with a measuring tape where it is safe, from published road design guidance, or from scaled satellite imagery. Record every value and its source in a table so the scenes are traceable rather than invented.
Checkpoint: A dimension table for each scene with a source for every value.
- 3
Build the first scene in RoadRunner
Create a new project and scene. Use the Road Plan tool to draw the road centre line, then set lane count and widths with the lane tools. Add a T-junction with the junction tools and adjust corner radii. Shape terrain and road elevation where needed. Apply markings with the marking tools, leaving stretches unmarked or with broken markings to represent wear. Save often and check the scene from a driver's eye height.
Checkpoint: A first scene with correct lane widths, a junction and deliberate marking gaps, viewed from the driver's position.
- 4
Add speed breakers, props and clutter
Model speed breakers with road elevation profiles or suitable props, sized from your dimension table. Add parked cars, roadside stalls, poles, signboards and trees from the asset library to create occlusion and visual clutter. Build the second and third scenes, for example a roundabout with an unmarked entry and a two-lane highway with a divider gap. Where the asset library lacks a three-wheeler or animal, use the closest generic asset and state this limitation.
Checkpoint: Three scenes built, each with the features listed for it in step 1.
- 5
Export and check OpenDRIVE
Export each scene as ASAM OpenDRIVE. In MATLAB, create a drivingScenario and load the file with roadNetwork(scenario,'OpenDRIVE',fileName), then plot it to check lanes and junctions. Compare a few lane widths and lengths against your dimension table. Fix any problems in RoadRunner, such as lanes that do not connect through a junction, and export again. Keep the exported files under version control with the RoadRunner project.
Checkpoint: Each exported road loads in MATLAB with lane widths within a few centimetres of the design values.
- 6
Create traffic scenarios
In RoadRunner Scenario, place the ego vehicle and other actors and define their paths and speeds. Create at least two scenarios per scene: a two-wheeler cutting in close, a vehicle pulling out from a parked position, a pedestrian crossing at an unmarked point, and an ego vehicle approaching a speed breaker. Use speed and timing parameters so the scenarios can be varied. Keep a written description and expected outcome for each scenario.
Checkpoint: At least six scenarios that play back correctly with their parameters exposed.
- 7
Connect a function under test
Choose one function: a lane detection model working on camera images, or a simple AEB working on object lists. Run it in Simulink, connected to RoadRunner Scenario through the co-simulation interface provided by the Automated Driving Toolbox, or run the road in a MATLAB driving scenario with simulated sensors. Log the function output alongside ground truth, such as the true lane boundaries or true gap to the cutting-in vehicle.
Checkpoint: The function runs on one scenario and its output is logged with matching ground truth.
- 8
Compare against a well-marked baseline
Build or reuse a baseline scene with clean markings and orderly traffic and similar geometry. Run the function on both. For lane detection, compare the share of frames with a valid lane estimate and lateral error against ground truth. For AEB, compare minimum gap and collision count. Present the difference feature by feature, for example lane detection availability on faded markings versus clean ones.
Checkpoint: A comparison table showing function performance on baseline and Indian scenes for each feature.
- 9
Report and package the scenes
Document the feature catalogue, dimension sources, scene-building steps and the comparison results. Include screenshots from the driver's eye view and plots of the OpenDRIVE roads. Discuss limitations: assets that are not truly Indian, traffic that is scripted rather than behaviour-driven, and the small number of scenes. Package the RoadRunner project, OpenDRIVE files and scenario files so other students can extend the library.
Checkpoint: A packaged scene library with a report and a short guide for adding new scenes.
Testing & validation
- OpenDRIVE lane widths and lengths checked against the design table.
- Scenarios play back with the intended timing and parameters.
- Function performance compared between baseline and Indian scenes.
- Feature coverage table showing which scene tests which feature.
Expected results
A small library of Indian road scenes and scenarios in RoadRunner and OpenDRIVE, with evidence of how a chosen ADAS function performs on them compared with tidy roads.
Take it further
- Export a scene to CARLA and run camera perception on rendered images.
- Add rain and night lighting to the scenes.
- Model a full stretch of a real local road from survey data.
- Add behaviour models for two-wheelers that weave through traffic.
Viva and review questions
Why export to OpenDRIVE rather than only using RoadRunner?
OpenDRIVE is an open format, so the same road can be used in MATLAB, CARLA and other simulators, and the test results do not depend on one tool.
How did you make sure the scenes were realistic?
Every dimension came from a recorded source, measurements or published guidance, and the exported geometry was checked against that table in MATLAB.
Why is missing lane marking a hard case?
Camera-based lane detection relies on visible markings. Without them the function must use road edges or other cues, or report that it is unavailable, and either behaviour needs testing.
Learn it at DIYguru
These DIYguru courses and programmes teach what this project needs.
