AEB for Pedestrians and Two-Wheelers: Scenario Design and Tuning

The problem

Pedestrians, cyclists and motorcyclists make up a very large share of road deaths in India. Vulnerable road users move unpredictably, appear from behind parked vehicles and are smaller targets for sensors than cars. AEB for these users needs crossing-path prediction, short reaction times and careful handling of false alarms in crowded streets where people walk close to traffic. Designing and tuning it on realistic scenarios is an important and practical research topic.

Objectives

• Define VRU AEB requirements and an operational design domain for urban Indian streets.
• Build pedestrian, cyclist and motorcyclist scenarios, including occluded crossings and turning cases.
• Implement path prediction and collision-check logic for crossing and longitudinal targets.
• Tune staged warning and braking thresholds against false activations in crowded scenes.
• Measure avoidance rate, impact speed reduction and false activations across scenario variations.

What you need

Key concepts

Crossing-path collision check

For a target crossing the ego path, the logic predicts when the ego and the target will both occupy the conflict zone. A collision is predicted if their occupancy times overlap.

Occluded VRU

A pedestrian stepping out from behind a parked car or bus is detected late, leaving little time. This is one of the hardest and most common real cases.

Avoidance and mitigation

Avoidance means no contact; mitigation means contact at reduced speed. Both are reported because injury risk for pedestrians rises steeply with impact speed.

False activation in crowded scenes

People walking along the roadside or stopping at the kerb must not trigger braking. The logic needs path prediction and confidence checks to separate them from real threats.

Step-by-step guide

1. 1

   Define requirements and the operating domain

   Write the ODD: urban streets at ego speeds from 10 to 60 km/h, daylight and dusk, with parked vehicles, narrow or missing footpaths and mixed traffic. Write requirements for warning, partial and full braking for pedestrians, cyclists and motorcyclists, plus false-activation limits for pedestrians on the roadside. Set targets for avoidance up to a stated speed and impact speed reduction above it, with measurable acceptance criteria.

   Checkpoint: An ODD description and testable requirement list with avoidance, mitigation and false-activation targets.

2. 2

   Build the reference scenarios

   In Driving Scenario Designer, load the prebuilt Euro NCAP VRU scenarios for adult and child pedestrians crossing from near and far sides, a pedestrian walking along the lane, cyclists crossing and riding ahead, and motorcyclists ahead. Export them to MATLAB functions and script variations of ego speed, target speed and impact point. These give a standard basis for comparison before adding Indian-specific cases.

   Checkpoint: A parameterised set of reference VRU scenarios that regenerate by script.

3. 3

   Build Indian street scenarios in RoadRunner

   In RoadRunner, build a two-lane urban street with parked cars and a bus along the edge, a narrow footpath, a side lane joining at a T-junction and a market frontage. Create scenarios with a pedestrian stepping out from behind the bus, a two-wheeler emerging from the side lane, a cyclist riding against traffic and a group of pedestrians crossing between vehicles. Export the scenes and use them in simulation alongside the reference scenarios.

   Checkpoint: At least six Indian-street scenarios that play back with correct actor paths and occlusion.

4. 4

   Set up perception and target selection

   Mount a forward camera and radar on the ego vehicle with realistic detection ranges and probabilities for small targets, and lower radar cross-section for pedestrians. Fuse with the Multi-Object Tracker block. For each confirmed VRU track, estimate position, velocity and class. Measure time from first visibility to track confirmation in the occluded scenarios, since this sets how much time AEB has to act.

   Checkpoint: A table of detection and confirmation delays for each VRU type and occlusion case.

5. 5

   Implement path prediction and collision checks

   Predict the ego path from speed and yaw rate, and each VRU's path from its velocity with a constant-velocity model. For crossing targets, compute when each enters and leaves the conflict zone and flag a collision if the ego occupies it at the same time, with margins for target size and uncertainty. For longitudinal targets, use TTC as for vehicles. Compute the time remaining to the latest braking point.

   Checkpoint: Collision flags that are correct for crossing, near-miss and roadside-walking test cases.

6. 6

   Design the staged logic

   In Stateflow, build states for warning, partial braking and full braking, triggered by the time to the latest braking point and the collision confidence. Because VRU cases are often short, allow a direct jump to full braking when the threat appears late. Add an override for strong driver steering or acceleration. Use a brake model with realistic build-up delay and maximum deceleration.

   Checkpoint: Animated runs showing correct stage sequences, including a direct jump to full braking for an occluded pedestrian.

7. 7

   Build the false-activation set

   Create scenarios where AEB must not brake: pedestrians walking along the roadside, stopping at the kerb, crossing well ahead and clearing the lane in time, two-wheelers filtering past the ego and cyclists turning away. Vary distances and speeds. Treat any braking here as a false activation and any warning as a nuisance warning. This set is as important as the avoidance set for tuning.

   Checkpoint: A false-activation scenario set of at least 50 variations, documented.

8. 8

   Tune thresholds and margins

   Sweep the conflict-zone margins, collision-confidence threshold and braking-trigger times on a tuning subset. Plot avoidance rate against false activations for each setting, separately for pedestrians, cyclists and motorcyclists. Choose a setting that meets the requirements, and explain any trade-offs where targets conflict. Keep the remaining variations for the final test. Record every setting tried, not only the final one, so the examiner can see the tuning was systematic and not chosen after looking at the test results.

   Checkpoint: Trade-off curves per VRU type with the chosen setting marked and a tuning record.

9. 9

   Run the full evaluation

   Use Simulink Test to run every reference, Indian-street and false-activation scenario variation. Record contact, impact speed, minimum distance, stage timings and false activations. Plot impact speed against ego speed per VRU type and scenario family. Report avoidance rate and mean impact speed reduction, and every false activation with its cause. Group results by scenario family so weak cases stand out, and keep the logged signals for each run so any surprising result can be replayed and inspected.

   Checkpoint: Impact-speed plots, avoidance and mitigation figures and a false-activation list for the test set.

10. 10

    Study sensitivity and limits

    Vary detection range, confirmation delay, road friction and brake build-up time, and rerun the occluded-pedestrian and two-wheeler scenarios. Identify which parameter limits performance most. For occluded scenarios, show the physical limit: below a certain visibility distance, no braking can avoid contact at a given speed. This links the results to sensor requirements and speed choices. Present the limit as a curve of visibility distance against ego speed.

    Checkpoint: Sensitivity plots showing which parameter limits avoidance most in occluded scenarios.

11. 11

    Write up the research

    Present the ODD, requirements, scenarios including the Indian-street set, perception analysis, collision logic, tuning and results. Discuss known limits: constant-velocity prediction of pedestrians, simulated sensors and no night or rain conditions. Make clear that AEB testing beyond simulation uses closed tracks with soft VRU targets under supervision. Release the RoadRunner scenes and test files where licences allow. Add a short discussion of how the results relate to consumer test protocols.

    Checkpoint: A thesis chapter with results for every scenario family and released scenarios.

Testing & validation

• Detection and confirmation delays for each VRU type and occlusion case.
• Avoidance rate and impact speed reduction for pedestrians, cyclists and motorcyclists.
• False activations and nuisance warnings in crowded roadside scenarios.
• Results on both reference Euro NCAP-style scenarios and Indian-street scenarios.
• Sensitivity to detection range, confirmation delay, friction and brake delay.

Expected results

A tuned VRU AEB function with avoidance, mitigation and false-activation results on both reference and Indian-street scenarios, plus a sensitivity analysis linking performance to sensor and brake parameters.

Take it further

• Replace constant-velocity pedestrian prediction with a learned intention model.
• Add steering-based evasive assistance when braking alone cannot avoid contact.
• Add night and rain sensor degradation to the scenarios.
• Use detections from a trained pedestrian detector on recorded IDD or BDD100K frames to calibrate sensor models.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.