Rush hour autopilot

Inspiration

A bikeshare trip depends on two things: finding a bike at the start and a free dock at the destination. During rush hour, empty and full stations can make the network unreliable. Inspired by the Bikeshare Fleets challenge, we built Rush Hour Autopilot to help dispatchers identify service problems and choose an appropriate response.

What it does

Rush Hour Autopilot is an interactive dashboard that helps a dispatcher: Monitor station availability, failed attempts, and data coverage. Explore station inventory trends, heatmaps, and rankings. Investigate service variation using p charts, c charts, and X-bar/R charts. Estimate station risks over the next 10, 20, and 30 minutes. Distinguish failures that suggest rebalancing, maintenance, or a data check. Generate suggested bike moves and track simulated task statuses. All data are simulated. The dashboard includes three reproducible scenarios: a baseline, a planted dock fault and demand surge, and a small scenario with missing and conflicting records.

How we built it

We built the dashboard in R using Shiny and bslib, with ggplot2 for charts and Leaflet for the station map. Statistical calculations live in separate functions so they can be tested independently of the interface.

A seeded R generator produces the scenario datasets. We checked the calculations against hand-worked examples and edge cases, tested the interface, and deployed the application on Posit Connect. The source code, data codebook, and demonstration walkthrough are available on GitHub.

Challenges we ran into

Missing data must not look like normal service. We implemented rules for stale readings, conflicting snapshots, and unknown minutes, and made those issues visible in the dashboard.

We also found that simulated attempts can produce clustered failures. This matters because ordinary p-chart limits assume independent attempts with a common failure probability within each window. We documented that limitation and treat chart signals as prompts to investigate.

Accomplishments that we're proud of

We turned the dispatcher’s workflow into a working application: see the problem, investigate its cause, estimate near-term risk, and prepare a response. We also made data coverage, model assumptions, and unavailable estimates visible alongside the results.

What we learned

Correct formulas are only part of a useful statistical tool. Data validation, appropriate assumptions, and clear explanations are equally important. A reproducible dataset is valuable, but reproducibility alone does not establish that a process is statistically in control.

What's next for win2027

We would like to connect operator data, validate the forecasting assumptions, and evaluate whether the suggested rebalancing moves improve service. The current recommendations are a greedy heuristic, and we do not claim that their effectiveness has been established.