Blind-Spot Detection and Lane-Change Warning

The problem

Vehicles in the rear-quarter blind spot are a frequent cause of lane-change collisions, and in dense mixed traffic two-wheelers often occupy that zone. Blind-spot detection (BSD) with lane-change warning uses short-range radar to watch these zones, but the zone definition, tracking and warning logic must avoid both missed vehicles and nuisance alerts from guard rails or vehicles two lanes away.

Objectives

• Define blind-spot and closing-vehicle zones in the vehicle frame.
• Simulate rear-corner radars and track detected vehicles.
• Implement warning logic for occupied zones and fast-approaching vehicles.
• Evaluate detection timing and false alerts on scripted scenarios.

What you need

Key concepts

Blind-spot zone

A rectangle beside and behind the ego vehicle, in the adjacent lane, that the driver cannot see in the mirrors. Its size is set by requirements and is usually defined in the vehicle frame.

Closing vehicle warning

A vehicle approaching quickly from behind may not yet be in the zone but will be by the time a lane change completes; time to arrival handles this case.

Multi-object tracking

Associating noisy radar detections over time into tracks with position and velocity, so warnings use stable estimates rather than single detections.

Step-by-step guide

1. 1

   Write the requirements

   Define the zones: a blind-spot zone from the ego's rear bumper to about 3 m ahead of it and 0.5 to 3.5 m laterally on each side, plus a closing zone extending further back. Define warnings: a steady indicator when a zone is occupied and a flashing or audible warning if the driver signals towards an occupied side. Set targets for detection delay after a vehicle enters the zone, release delay after it leaves and no alerts for vehicles two lanes away or stationary roadside objects.

   Checkpoint: A requirements table with zone dimensions, warning states and timing targets.

2. 2

   Build the scenarios

   In the Driving Scenario Designer or with drivingScenario, build a three-lane straight road and a curved road. Script cases: a car overtaking on the left, a motorcycle passing on the right, a fast car approaching from behind, the ego overtaking a slow truck, a vehicle two lanes away and a guard rail along the road. Give each actor a waypoint trajectory with realistic speeds. Save the ground-truth zone occupancy for each case for later scoring.

   Checkpoint: At least six scenarios play back correctly with ground-truth zone occupancy logged.

3. 3

   Model the rear-corner radars

   Add two drivingRadarDataGenerator objects mounted at the rear corners, pointed rearwards and outwards at about 45 degrees, with a wide field of view and a range of around 70 to 80 m. Set realistic range and azimuth accuracy and a detection probability below one. Enable reporting of range rate. Visualise the coverage areas and detections on a birdsEyePlot and check that both blind-spot zones are covered.

   Checkpoint: A bird's-eye plot showing radar coverage over both zones and detections on passing vehicles.

4. 4

   Track the vehicles

   Feed the detections from both radars, transformed into the ego frame, into a trackerGNN with initcvekf as the filter initialisation function. Tune the assignment threshold and confirmation logic so tracks confirm within a few scans and are deleted after a few misses. Filter out stationary objects using ground speed computed from range rate and ego speed. Plot track positions against ground truth.

   Checkpoint: Confirmed tracks follow passing vehicles with position error well under a metre and no persistent guard-rail tracks.

5. 5

   Implement zone and warning logic

   For each confirmed track, test whether its estimated footprint overlaps either blind-spot zone, and for tracks behind, compute time to arrival from relative position and velocity. Set the zone flag when a track is inside or arriving within a threshold, with on and off delays for stability. Combine the flag with a simulated indicator input to raise the stronger lane-change warning. Write this as a MATLAB function so it can later move into Simulink.

   Checkpoint: The warning state changes correctly in each scripted scenario when replayed step by step.

6. 6

   Score against ground truth

   For every scenario, compare the warning timeline with ground-truth occupancy. Record detection delay after entry, release delay after exit, missed occupancy intervals and false alerts. Repeat each scenario with several random seeds for radar noise. Collect results in a table and highlight any requirement that fails. Treat a warning that starts within the allowed delay as correct, and count any warning raised while the zone is empty for longer than the release delay as a false alert. Keep the scoring script separate from the warning code so it cannot be tuned to pass.

   Checkpoint: A per-scenario table of delays, misses and false alerts across seeds.

7. 7

   Stress the design

   Add harder cases: dense traffic with several vehicles in the zone, a motorcycle riding close to the lane line, a tight curve where adjacent-lane vehicles appear offset, and reduced detection probability. Observe which cases cause late or false warnings and adjust zone shape, track filters or timing. Re-run the full scenario set after every change so earlier cases are not broken.

   Checkpoint: Updated results showing the effect of each change, with no regression on the original scenarios.

8. 8

   Report

   Document the requirements, sensor layout, tracking setup, warning logic and results. Include bird's-eye snapshots of key moments and the delay statistics. Discuss limitations such as the straight-zone assumption on curves and the idealised radar model. Note that real validation would use recorded radar data and a closed test track, and that no public-road testing was done. Add a table that maps each requirement to the scenarios that test it and the measured result.

   Checkpoint: A report with per-requirement results and illustrated scenarios.

Testing & validation

• Detection delay and release delay per scenario.
• Missed occupancy and false alerts across random seeds.
• Track position error against ground truth.
• Behaviour on curves, dense traffic and two-wheelers.

Expected results

A simulated BSD and lane-change warning function with radar tracking that meets stated timing targets on a scenario suite, with documented weak cases.

Take it further

• Port the logic into Simulink and generate code with Embedded Coder.
• Use road geometry to bend the zones on curves.
• Add rear cross-traffic alert for reversing out of a parking space.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.