College Bus Live Tracking Android App with Driver Console using Flutter and Firebase

College students who ride campus buses lose roughly 15–30 minutes a day (approximate) to a simple information gap: nobody knows where the bus actually is. They reach the stop early and wait in the sun, or arrive two minutes late and watch the bus pull away. CampusGo — a college bus live-tracking Android system built with Flutter and Firebase — closes that gap with two cooperating apps. The student app shows every bus moving live on a campus map, lists each route with arrival estimates per stop, and pushes delay alerts the moment a driver reports one. The driver console gives verified drivers a trip panel: start and end trips, stream GPS position every few seconds, tap checkpoints as they pass, and broadcast a delay with one tap. Positions flow through Firebase Realtime Database; Firebase Authentication restricts the driver console to verified drivers. Students check the map, time their walk to the stop, and get notified instead of waiting blind.

The loop starts in the driver's pocket. Tapping Start trip makes the driver console request high-accuracy GPS fixes from Android's Fused Location Provider and write each fix — latitude, longitude, speed, timestamp — to that bus's node in Firebase Realtime Database every 5 seconds (design target). Firebase pushes every write to all connected clients, so the student app's listener receives the update and moves the bus marker with no polling and no refresh button. The student app also watches an alerts node: when the driver marks a checkpoint or broadcasts a delay, the event fans out to every student's feed in milliseconds. ETAs are computed on the student device from the bus's latest position and remaining route distance, so no application server is needed at all. Firebase Authentication gates the driver console, so every position and broadcast is provably from a verified driver.

1. The driver signs in with email and password through Firebase Authentication; the console unlocks only for accounts flagged as drivers.
2. Tapping Start trip begins high-accuracy location requests via the Fused Location Provider on the driver's phone.
3. Every 5 seconds (design target) the console writes the GPS fix to /buses/{busId} in Firebase Realtime Database.
4. Each student phone holds a realtime listener on the buses node; every write arrives as a push and the map marker glides to the new position — no polling.
5. The student app recomputes each stop's ETA from the bus's latest position and remaining route distance, refreshing every 10 seconds (design target).
6. Checkpoint taps and delay broadcasts are written to /alerts/{pushId} and fan out to every student's feed — about 25 ms from broadcast to render in the demo build (measured, same-browser realtime path).
7. Tapping End trip stops location sharing, archives the trip log, and the bus leaves the live map.

Tech stack:

• Flutter 3 · Dart
• Firebase Realtime Database
• Firebase Authentication
• Google Maps SDK for Android
• google_maps_flutter plugin
• Fused Location Provider (Google Play services)
• Android Studio · Gradle
• Cloud Functions for Firebase (optional fan-out)

The student live map is the heart of CampusGo: every bus appears as a labeled marker moving along its colour-coded route line, with a live-connection indicator, so a student sees at a glance which bus to catch. Route-wise ETAs turn raw positions into decisions — each stop shows an arrival estimate recomputed from the bus's latest position every 10 seconds (design target), with delayed buses flagged in red. The driver console is the system's other half: a verified driver starts a trip, streams GPS fixes, taps checkpoints as they pass, and broadcasts a delay with a reason in a few taps. Broadcasts land instantly in the student alert feed — in the demo build, a driver broadcast rendered on the student screen in about 25 ms (measured). Firebase Authentication gates every driver write, so position data always comes from a real driver.

• [Live bus map] Every bus renders as a labeled marker moving along its colour-coded route on a Google-Maps-powered campus view, with a pulsing live indicator while the realtime connection is healthy. Tapping a marker opens the bus's next two stops with ETAs.
• [Route-wise ETAs] Each stop on each route shows an arrival estimate recomputed on-device from the bus's latest reported position and remaining route distance, refreshed every 10 seconds (design target).
• [Driver trip control] Verified drivers start and end trips from the console; trip state, elapsed time and location sharing sit in one panel, and ending a trip cleanly removes the bus from the live map.
• [Checkpoint marking] Drivers tap each stop as they pass; the mark is timestamped and pushed to the student alert feed, so regular riders learn the bus's rhythm.
• [Delay broadcast] One screen, three taps: pick a delay length, pick a reason, send. The alert fans out to every student's feed instantly.
• [Driver authentication] Email/password sign-in through Firebase Authentication; only accounts flagged as drivers can write positions, checkpoints or broadcasts.
• [Last-known-position fallback] If a bus goes dark mid-route, the map keeps showing its last reported position with an age stamp instead of a blank screen.

Configurable at build time: position update interval (5 s default), ETA refresh cadence, map style, route/stop lists. Optional add-ons: SMS fallback for delay alerts, admin web panel, trip-history analytics. Future scope: predictive ETAs trained on historical runs, parent-view mode.

• Two Flutter apps with full Dart source: CampusGo Student and CampusGo Driver
• Firebase project configuration: Realtime Database schema, security rules, driver-role setup
• Admin seeding tool for routes, stops, buses and driver accounts
• Builder notes from the working reference demo — including the realtime listener-ordering fix (an explicit initial read after subscribing, because a driver's first write can land before the student view attaches its listener)
• Project report PDF and 10-section abstract
• PPT presentation and viva Q&A document
• Demo walkthrough script recorded from the reference demo
• Build timeline: 3–4 weeks (expected); 30 days of build-query support after delivery (expected)