Clock-Driven, Not State-Aware
Fixed headways dispatch on a timer and ignore the real-time distribution of buses already on the route.
Back to Projects
Bus Bunching RL Dispatch Optimization
Taipei Bus Bunching Detection and Dispatch Optimization: The Dunhua Main Line
A reinforcement-learning dispatch optimization system for Taipei's Dunhua Main Line, designed to reduce bus bunching while balancing passenger waiting time and operating cost.
Problem
A Fixed Timetable Cannot See the Road Ahead
Bus bunching is a chronic problem on Taipei's high-frequency trunk routes: two buses close in on each other and arrive almost together, while passengers at later stops wait far longer than the timetable promises. The Dunhua Main Line — short headways, dense stops, heavy signal interference and complex traffic — makes it especially visible. The underlying cause is that fixed-headway dispatch triggers on the clock alone: it never looks at where the other buses on the route actually are.
Delay Compounds Itself
A bus that falls behind picks up more waiting passengers, falls further behind, and lets the bus behind catch up.
No Single Best Headway
Tightening the headway shortens waits but puts more buses on the road and worsens bunching; loosening it does the reverse.
Proposed Solution
Learn the Dispatch Decision From Real Road Conditions
01
One-Dimensional Route Projection
Project both bus GPS coordinates and stop locations onto the route's WKT LineString, turning 2D latitude and longitude into a 0–1 progress value so any two buses become directly comparable and bunching can be read off the gap.
02
Data-Driven Simulator
Sample segment travel times from a historical pool conditioned on direction, weekday or holiday, peak band and rainfall, rather than assuming a distribution. When a condition has too few samples the simulator relaxes it step by step instead of failing.
03
Dispatch as a Sequential Decision
Model departure control as an MDP with a binary dispatch-or-hold action every 60 seconds, and a reward that weighs bunching, headway variance, fleet size and passenger waiting against each other.
04
Ablation Instead of a Single Score
Zero out one reward component or state feature group at a time to show each element constrains a distinct failure mode, rather than reporting one aggregate number.
System Architecture
How the Dispatch Policy Was Built and Tested
A four-stage pipeline turns raw GPS traces into a simulator, and the dispatch decision is framed as a Markov decision process so the agent can be compared against the fixed headway it would replace.
Research Pipeline
Raw GPS Traces to a Comparable Policy
Stage 01
Preprocessing
Clean, Project, Split
Filter to valid in-service records, project GPS onto the route line as a 0–1 progress value, split into trips, and interpolate stop crossing times.
Stage 02
Simulation
Data-Driven Simulator
Sample historical segment travel times conditioned on direction, day type, peak band and rainfall, then validate with Leave-One-Day-Out.
Stage 03
Learning
DDQN Dispatch Agent
Train a three-layer MLP with a replay buffer and ε-greedy decay to decide, every 60 seconds, whether to release a bus.
Stage 04
Evaluation
Policy Comparison
Run 180-minute episodes against fixed headway under identical start states and seeds, then ablate reward and state components.
Decision Model
Departure Control as a Markov Decision Process
State
- Time context — peak band, weekday or holiday, rainfall
- Service state — buses on route, time since last dispatch
- Vehicle state — bunching count, headway, per-stop estimated wait
Action
- Binary: dispatch or hold
- Re-evaluated every 60 seconds
Reward
- Penalties — bunching, headway variance, buses in service, waits over target
- Bonus — waits inside target
- Targets: 8 min at peak, 15 min off-peak
My Contribution
Formulated the dispatch problem as an MDP, designed and weighted the reward function, trained the DDQN agent, and ran the comparison, sensitivity and ablation experiments.
Implementation & Outcomes
From Two Weeks of GPS Traces to a Validated Policy
Three Sources, One Dataset
TDX supplied stop sequences and route geometry, the Taipei Bus API was polled every 30 seconds from 22 April to 6 May 2026 for GPS traces, and CODIS provided hourly rainfall. The three were merged into a segment pool keyed by segment × trip.
Trip Reconstruction
Records were filtered to valid in-service trips, split into trips on a large backward jump in route progress or a 20-minute data gap, and stop crossing times were linearly interpolated to derive per-segment travel time — GPS arrives every 30 seconds and never lands exactly on a stop.
Leave-One-Day-Out Validation
To check the simulator generalizes rather than memorizes, every record from the simulated day was removed from the sample pool and the simulator had to predict out-of-bag. Trip-level MAE stayed within 6–10 minutes across all four time bands, highest in the evening peak where delay accumulates.
DDQN Training and Fair Comparison
A three-layer MLP (input→128→128→2) trained in PyTorch with Adam, a replay buffer and ε-greedy decay from 1.0 to 0.05. Evaluation ran 180-minute episodes against a fixed-headway baseline set to the actual service standard, under identical start states and random seeds.
- Bunching Volume
- −22.9%
- Against a peak 8 min / off-peak 15 min fixed-headway baseline; bunching duration also fell 16.2%
- Simulator Trip-Level MAE
- 6–10 min
- Leave-One-Day-Out validation across four time bands and both directions
- Wait-Target Overrun (Tradeoff)
- 37.9% → 42.1%
- The agent's more conservative dispatching cut bunching but stretched waits at some stops
Limitations
What Remains to Be Validated
Every number here comes from a simulator built on two weeks of GPS traces, so it describes simulated operations rather than a deployed service. The simulator carries no passenger boarding and alighting demand model, wet-weather samples are sparse enough that rainy scenarios are its least reliable regime, and the ablations ran on a single random seed. The result is also not a clean win: the agent's conservative dispatching raised the share of stops exceeding the wait target from 37.9% to 42.1%, which points at the reward weights rather than the approach. A real deployment would additionally need vehicle depot and driver scheduling constraints, and separate policies for weekdays and holidays.