GP00 Scope Proposal: Worked Example

This is a fictional response to every question on the GP00 sign-up and scope form. It is written at the level of detail that makes the later checkpoints checkable: each answer commits the student to something the abstract, report, and 10-minute discussion can be measured against.

Student: (captured by sign-in)

1. Project title: your topic in one line, as it should appear on the class topic list

Onboard pavement-defect detection on city transit buses, with nightly upload of event records only.

2. The application and who it serves: what is deployed, where, and who benefits

A mid-size transit agency runs 40 buses out of a single garage, each already fitted with a forward-facing dashcam for incident review. I propose adding a small compute box on each bus that watches the same video stream for pavement defects: potholes, failed patches, and worn lane markings. Each detection is reduced on the bus to a record holding a GPS fix, a timestamp, a severity score, and one 60 kB cropped image. The records upload over garage Wi-Fi overnight and land as a ranked daily work list for the city’s public works crew, who currently rely on resident complaints and an annual survey van. The beneficiaries are the paving crew, who get near-daily coverage of every route for no new vehicles, and riders, who feel the result.

3. Which constraint is the main reason this cannot be a cloud-only design?

Bandwidth or uplink cost: too much raw data to ship.

4. Why that constraint rules out a cloud-only design, with a number attached

Streaming the video off the bus is the design I am arguing against, and the arithmetic is why. One 1080p30 camera encoded in H.264 at a quality good enough for small-defect detection runs about 6 Mbps. A bus in service 12 hours a day produces 6 Mbps × 43,200 s = 2.6 × 10¹¹ bits, about 32 GB per bus per day, so roughly 1.3 TB per day across 40 buses. At LTE rates in the agency’s current data plan that is not affordable, and the garage’s own uplink is a 100 Mbps business line shared with everything else.

Detecting on the bus and shipping only event records inverts the problem. My working assumption is about 250 detections per bus per shift (routes repeat, so the same defect is seen many times), at roughly 60 kB per record: 15 MB per bus per day, 600 MB per day for the fleet. That is a reduction of about 2,000×, and it is the single number the whole design rests on. The assumption I am least sure of is the detections-per-shift figure, which I plan to bound from the city’s existing defect inventory rather than guess.

5. Your first cut at the processing split: what runs on the device, what runs on a nearby edge node, and what, if anything, runs in the cloud

• On the bus (device tier): decode the camera stream, run a small detector at a reduced frame rate (my starting assumption is 10 fps, not 30, since a bus at 25 mph covers about 1.1 m per frame at 10 fps, which is finer than the defects I care about), tag each hit with GPS and time, crop and compress the patch, and buffer to local storage until the bus is in the garage.
• Garage edge node: collect from all 40 buses over Wi-Fi, deduplicate detections that cluster at the same GPS location across buses and days, rank by severity and repeat count, and emit one work list. Deduplication belongs here rather than on the bus because no single bus sees the whole picture.
• Cloud: the city asset database, the crew-facing dashboard, and periodic model retraining on the accumulated crops. None of it is in the detection path.

The piece I am least sure of is whether severity scoring belongs on the bus or at the garage. It depends on whether severity needs the deduplicated repeat count, which I have not settled.

6. The data sources and their scale at one site

Per bus: one forward 1080p30 camera, one IMU at 100 Hz, one GPS receiver at 1 Hz.

• Raw video: 1920 × 1080 × 3 bytes × 30 fps = 187 MB/s, about 1.5 Gbps uncompressed.
• H.264 at the quality above: about 6 Mbps, or 0.75 MB/s, which is a 250× compression ratio.
• IMU: 100 Hz × 24 bytes = 2.4 kB/s. GPS: negligible, under 100 B/s.
• One site is one garage: 40 buses, 12-hour shifts, a 6-hour overnight window in which every bus is parked and on Wi-Fi.

The IMU matters more than its data rate suggests: a vertical-acceleration spike is a cheap confirmation that the bus actually hit something, and I expect to use it to suppress false positives from shadows and wet patches.

7. The key quantitative question your analysis will answer

Can a 15 W onboard box sustain defect detection at 10 fps on 1080p video, and if it can, what nightly uplink does a 40-bus garage need to clear a day of event records before the next shift?

8. Three to five quantities you will estimate, each with its unit and where the number will come from

1. Onboard inference throughput, in frames per second, for a small detector on a 15 W class module. Source: published benchmark figures for the module and model family, cross-checked against the course lab measurements.
2. Onboard power draw, in watts, at that throughput, against the vehicle’s accessory budget. Source: module datasheet plus the benchmark’s reported power mode.
3. Event payload per bus per day, in MB. Source: my own calculation from detections per shift and record size, with the detection count bounded by the city’s published defect inventory.
4. Garage nightly uplink, in Mbps, to clear the fleet’s records in the 6-hour parked window. Source: calculation from quantity 3. First pass: 600 MB × 8 / 21,600 s = about 220 kbps, which is why I expect the interesting constraint to be on the bus rather than the wire.
5. End-to-end latency from a bus passing a defect to that defect appearing on the crew’s list, in hours. Source: calculation from the shift and upload schedule, to be compared against how fast the city can act on it anyway.

9. What do you most want to settle in your 10-minute scope meeting?

Whether detections per bus per shift is a number I can defend or one I am inventing. If the city’s inventory cannot bound it, the 2,000× reduction claim in question 4 loses its footing, and I would rather restructure the analysis now than defend a made-up figure in December. Second, whether the deduplication step is enough of an edge orchestration story or whether the project needs more happening at the garage tier.

How these answers get checked later

Section numbers refer to the written report structure. Abstract sentences follow the order the abstract asks for them.

Three failure patterns this makes visible:

• a final report whose numbers never answer Q7;
• a processing split that quietly changed from Q5 with no explanation; and
• quantities in Q8 that vanish from the report or arrive with no stated source.

← Back to the Graduate Project