Progress this week

Most of our work this week went into the design report. We brought the three workflows into one description and worked through the use cases, design tradeoffs, requirements, and tests we will need to show that the system works. We also checked that the report separates laptop results from plans for the Jetson. The three workflows still run separately on laptops. We have not run them together on the Jetson or completed a live camera-to-tablet test.

Alan compared simple image methods with the treadmill pose model and examined where its update delay comes from. Harry tested image subtraction for rack belongings. It gave more definite answers on the scored observations but also mistook a person for belongings four times. Jerry continued testing the bench workflow, documented its errors, and measured its perception check on a laptop CPU. The bench check still has the most work to do on accuracy.

Risks and responses

Running all three workflows on one Jetson is still our largest technical risk. The laptop measurements help us plan, but they do not tell us whether the combined workload will meet our update targets. We will run each check on the board, then measure them together before deciding whether we need faster models or changes to how often stations are checked.

The bench workflow still struggles to tell which person belongs to which bench and whether plates are on the working bar. Jerry is testing those failures on separate footage. The rack workflow needs longer recordings and more kinds of belongings before we can test a full five-minute wait. We also need more footage set aside for final evaluation across all three checks.

Recording permission at the apartment gym is resolved. Confirmation for the UC gym is still pending.

Design and schedule

We did not make a major change to the system design this week. We made the requirements more specific, including when a reading is unknown, what starts or stops an unattended timer, and how we will score delays and incorrect alerts. Those details give us clearer tests, but they have not been verified on the full system yet.

The design report took priority over hardware work and longer recordings this week. First Jetson checks are now planned for the week of October 19, followed by individual live workflows and then the combined tablet path.

Part A Global factors

Written by Harry

This system is not just limited to CMU gyms. People in other gyms could also benefit from knowing whether equipment is free before walking to it. Their gyms may have different layouts, lighting, machines, and internet access, though. BenchGuard processes video locally and lets someone adjust the areas assigned to each machine, which could help it work in different settings. We would still need to check camera placement and test accuracy at each new site. Our current clips do not show how well it would work everywhere.

The display should also be easy to understand without knowing how the system works. If a camera cannot see a machine clearly, showing unknown is more useful than guessing that it is free.

Part B Cultural factors

Written by Jerry

People have different expectations about resting between sets, sharing equipment, and leaving belongings nearby. Those expectations can vary between gyms as well as between communities. Our five-minute wait is a setting to test, not a rule that says someone has given up a rack or bench. A staff member would check a flagged station and decide what to do under that gym’s rules.

The message should describe what the system saw without blaming a member. We also need to test people working out with partners, taking longer rests, and walking past nearby machines. A gym would need to review the waiting time, wording, and camera notices before using the system.

Part C Environmental factors

Written by Alan

Cameras and computers use electricity and materials, so adding more equipment has a cost beyond its purchase price. We are reusing course inventory where we can and plan to test whether one clear camera view can cover more than one machine of the same type. We cannot assume that wider coverage saves resources if it makes the readings unreliable.

We will measure the Jetson’s power use with the workflows running before claiming any energy savings from a different model or setup. We also want mounts and other prototype parts that can be moved and reused as the camera positions change.

Progress this week

This week, each team member got one use case running on recorded video. All three workflows now run on laptops, have automated tests with more than 170 passing across the team, and have been submitted for team review. None has run on the Jetson yet.

Treadmill availability (Alan)

Alan’s check uses pretrained models and no training on gym footage. A pose model finds people’s feet, and a treadmill counts as in use when feet are on its belt. For setup, an open-vocabulary detector finds the treadmills in a photo of the empty row, and a segmentation model outlines each belt. Alan tested two team-filmed clips covering seven treadmills, 66 seconds, and six step-on or step-off events.

• Every change was detected within 1.0 to 3.5 seconds.
• There were no false free readings, and people walking past did not change a treadmill’s state.
• A blocked treadmill was reported as unknown rather than free.

Alan also wrote a Jetson deployment guide and a one-command board check. He rehearsed both on a laptop.

Bench (Jerry)

Jerry built a local check for whether a bench is in use and whether plates remain on its bar. He gathered short private-gym recordings and tested the check on them. He also added a browser preview for reviewing predictions and handling stale observations. The tests exposed problems with camera angle and partly hidden equipment, and accuracy remains below the target.

Squat rack (Harry)

Harry added automatic rack setup with editable floor regions, plus detection of people and belongings. The workflow reports available, in use, waiting, review, or unknown. On four short team clips of one rack, 54 of 63 scored states were correct, nine were unknown, and none were wrong. Item presence was correct in 52 of 64 samples, with 12 unknown. These are development results from one camera view. None of the clips contains a full five-minute unattended episode.

Risks and responses

The largest technical risk is running all three checks on one Jetson. The workflows use different models. Treadmill uses a small pose model, squat adds an item detector to person and pose models, and bench uses several models, including its own equipment detector. Bench is expected to need the most computation, but we have not measured their combined speed or memory use on the board.

We will run the treadmill check first, then measure each workflow alone and all three together. If the combined workload does not fit, we can convert models to TensorRT, check racks and benches less often because their timers run for minutes, share a person detector where practical, or support fewer stations.

The bench check is our least mature workflow and remains below its accuracy target. Camera alignment and recognizing plates on the bar are the main problems. Jerry will isolate those failures, improve the pipeline, and evaluate changes on separate footage. Longer recordings will help test the five-minute timer, but they will not by themselves fix detection errors.

Our evaluation data is limited. Results so far come from short clips, often from one camera view, with labels made by one person or with assistant help. Each owner will record longer scripted sessions, hold some clips back for final testing, and ask a teammate to review a sample of the labels.

Recording permission is still unresolved. Team and private-gym recordings remain outside the code repository. We will confirm permission and consent before showing footage publicly. Access to the campus gym is also unconfirmed. If it is unavailable, we will use a controlled setup with consenting participants.

The three workflows were built in parallel and contain some overlapping code. Squat and treadmill, for example, use the same models during setup. We will agree on a shared data format and shared modules, then merge the workflows in a planned order.

Changes to the design

The main change is using models chosen for each use case instead of one shared detector with separate rules. Testing showed that the checks need different evidence. Treadmills depend on feet on the belt, squat racks depend on a person’s floor position and belongings, and benches depend on whether plates remain on the bar. No pretrained class covers plates on a bar. Using more models increases the likely Jetson workload, so we will measure each workflow and share a person detector where the implementations agree.

We made four other changes.

• Automatic setup The treadmill belts and squat rack can now be found from an empty reference frame, with a preview for a person to confirm. This responds to design-review feedback about setup effort. The larger setup models run once on a laptop rather than on every check.
• Unknown states Each workflow reports unknown when its area is blocked, the camera has moved, or observations are stale. An uncertain view should not be shown as free.
• Treadmill confirmation A treadmill is shown as in use after three of the last four checks agree and as free after five of the last six. Previously, both changes required five of six. This reduced step-on delay by about one second in our tests, though it may make brief false detections more likely. None occurred in the tested clips.
• Bench equipment detection The bench check now uses a trained detector because no pretrained class covers plates on a bar. This adds collection, labeling, and evaluation work. Our recordings remain evaluation-only for current and future training, so we do not test the detector on footage it learned from.

Updated schedule

Jetson work is about one week behind. Alan collected the board on October 2, but setup has not started. Camera and tripod requests submitted this week should make future recordings more repeatable. Fall break remains contingency time.

• By October 6 Agree on the shared data format and merge order.
• By October 7 Inventory the Jetson, run the treadmill check on recorded video, then begin running each workflow alone.
• By October 9 Complete the design report. Each owner will write about their implementation, results with sample counts, and risks.
• By October 10 Record longer scripted sessions, reserve held-out clips, and have a teammate review a sample of the labels.
• Week of October 12 Alan will test a live treadmill camera-to-tablet path on the Jetson. Jerry will address bench failures and test changes on separate footage. Harry will test the squat check with people walking past and more types of belongings.
• Before fall break ends Run all three workflows together on the Jetson and measure latency, memory, and temperature.
• November 9 or 11 Demonstrate three checks running on the Jetson with a tablet dashboard

Progress this week

This week, we worked on the design-review presentation and went back through the professor and TA feedback from our proposal. They liked the use case, but wanted clearer reasons for our camera layout, processing approach, and quantitative requirements. We compared shared cameras with one camera per machine and worked through the cost, connections, setup, and processing needs. We also reviewed the slides against the assignment guidance and documented the questions we still need to resolve.

Our preliminary experiments covered the pretrained detector, simple image processing, equipment-state logic, inference timing, scheduling, and image transport. These used laptop measurements, generated images, public examples, and simulated inputs. They have not established performance in the UC gym or on the Jetson. The YOLO11n class list does not include weight plates, and the original state prototype exposed a case where a person lingering near a station delayed an unattended flag. We also tested equipment detection and segmentation on treadmill photos. A straight-on view gave clearer machine regions than a crowded diagonal view, but some masks included neighboring equipment. These results helped narrow what we need to test next.

We also worked on separating user requirements from subsystem requirements. The five-second treadmill target needs a budget for sampling, confirming a change, processing, and updating the dashboard. We are refining the accuracy justifications around incorrect availability and unnecessary staff trips. These are proposed budgets, not achieved response times.

Design changes and their costs

Our working plan is shared cameras covering small, separate groups of machines. We are planning three selected views for the prototype, rather than claiming three cameras can cover an entire gym. More cameras could be added where clear coverage requires them. This reduces mounts, power connections, and feeds compared with one camera per machine, but we still need to confirm machine regions during setup. Keeping each machine in one camera group avoids cross-camera matching and double counting.

We used an estimated 10 treadmills, 6 squat racks, and 6 benches for the UC gym comparison. A dedicated-camera design would mean 22 camera installations. Even with inexpensive cameras, powering and connecting that many devices adds work. Shared views trade some setup and placement effort for fewer devices to maintain.

We plan to share the person/belongings detector across feeds and use separate equipment rules. We will start with PyTorch and add TensorRT only if measurements show a need. The unattended waiting period is a configurable five-minute starting point that still needs staff input and testing. For plates, we will compare simple image processing with a plate-specific method before committing to extensive training.

These changes require updates to the parts list, camera plan, timer rules, tests, and documentation. We will keep one current specification so older ten-minute settings and runtime assumptions do not conflict. The design review also delayed purchasing because the two camera approaches needed different hardware. The order is now behind, and we need to resolve it promptly.

Significant risks and mitigation

• Hardware: The parts order is not submitted, and Jetson/camera availability is still unconfirmed. Harry will check inventory and loan options, update the parts list, and submit the missing items. Laptop work will continue while hardware is pending.
• Gym access: Placement, recording, and demo approval remain open. Jerry will coordinate the request with the team. A controlled setup with consenting volunteers is our fallback.
• Detection and visibility: Plates on a bar, stored plates, passersby, and blocked views can produce misleading results. Alan will test staged cases and camera angles before a larger labeling or training effort.
• Incorrect flags: Jerry will test returns, passersby, brief detection errors, and stale or blocked views. Unreliable observations should produce an unknown state rather than show equipment as free. We also need to distinguish attendance at one station from someone using a neighboring station, so one person’s presence does not suppress another station’s flag.
• Processing load: We have not shown that three feeds need a complex scheduler. Harry will compare simpler scheduling methods and measure update delay, memory, and gaps between equipment checks on the actual board.

Schedule and next steps

Parts ordering and the recorded-feed prototype are behind the original September 25 target. The fake-data dashboard, camera-placement tests, and initial recording work also need to catch up. We have updated the schedule to keep laptop capture, vision tests, and application work moving in parallel.

The slides are due September 27. By the next report on October 3, Harry will submit the missing parts request and establish a timestamped single-feed laptop baseline, Alan will prepare an initial staged vision comparison and coverage test plan, and Jerry will build the fake-data dashboard and observation interface. The following week targets three-feed capture and board setup if equipment is available. The design report remains due October 9, with the treadmill MVP targeted for October 23. Any hardware delay will be stated clearly rather than treating laptop results as Jetson results.

Harry and Jerry will agree on station IDs, observation timestamps, and how camera failures are reported before connecting capture to the dashboard. That lets the application develop against fake observations while the capture and vision work continue.

Public health, safety, social, and economic considerations

Part A: Public health, safety, or welfare

Written by Alan Wang.

BenchGuard aims to make shared equipment easier to find and keep ready for use. Treadmill availability could save members a trip to another floor, while flags for unattended belongings or loaded bars could help staff decide where to check. We have not measured these benefits, and the system is not intended to prevent injuries or detect emergencies. Staff would inspect a flagged station before taking action.

Incorrect information can also cause problems. Showing an occupied treadmill as free wastes a member’s trip, while showing a free one as occupied hides equipment they could use. An incorrect unattended flag could lead staff to interrupt someone who is resting. A blocked or disconnected camera should therefore show unknown, and the dashboard should show how recent its information is. The waiting period gives people time to rest or briefly leave, although we still need to test whether five minutes is appropriate.

Clear equipment information may be particularly useful to members with limited time or those who find repeated trips between floors difficult. The display needs to make free, occupied, and unknown states easy to distinguish. We plan to process images locally and show equipment states rather than identifiable footage. Camera placement and recording still need facility approval and participant consent. The system would support ordinary staff checks, not replace them.

Part B: Social factors

Written by Zhanming (Jerry) Liang.

People use gym equipment differently, and belongings do not always mean someone has finished or abandoned a station. BenchGuard would report what it observes, such as items remaining while nobody is visible, without identifying an owner or judging their behavior. Five minutes is a configurable starting point, not a gym rule. Staff would decide how to handle a flag.

This matters for people taking longer rests, sharing a rack, or working out with a partner. A person standing nearby might be a trainer or passerby rather than the station’s user. Our tests will include these cases and different rest patterns. Staff-facing wording should describe the equipment, such as “items remain at an unattended station,” rather than accuse a member of leaving a mess. The system would not automatically remove belongings, reserve equipment, or enforce gym rules.

Privacy also affects whether members are comfortable with the system. We do not plan to identify faces or track named people, and the dashboard does not need to show camera footage. Existing security cameras do not automatically give us permission to add ours or access their feeds. We need to explain where cameras point, what information is shown, and how any approved test recordings are handled. Keeping the output about equipment rather than individual behavior should reduce intrusion, but local processing alone does not remove all privacy concerns.

Part C: Economic factors

Written by Yuehan (Harry) Hu.

BenchGuard could help staff spend less time checking already-clear stations and help members find available equipment. Those savings are not proven. Incorrect flags could create extra work, and frequent camera adjustment could cancel out the benefit. We plan to track useful and unnecessary flags, along with setup and maintenance effort, before claiming a financial return.

We will check course inventory before buying equipment. For our estimated 22 machines in the UC gym, one camera per machine would require 22 mounts, power connections, and feeds to maintain. Shared cameras reduce that installation burden, although confirming machine regions still takes time. Sharing the detector and starting with PyTorch also keeps initial deployment simpler. Course loans lower our spending, but a commercial installation would still need a computer, cameras, storage, mounts, cables, power, installation, and support.

Coverage matters as much as camera price. A cheaper, wider view is not a saving if it misses distant equipment or needs frequent correction. We will estimate cost per reliably monitored station from tested camera views, rather than assume three cameras cover the whole gym. Any estimate of staff-time savings should account for useful checks, unnecessary trips, and ongoing maintenance. We do not yet have enough evidence to claim a payback period or improved gym revenue.