Harry’s Status Report For 9/26

Accomplished

Most of my week went into working through the professor and TA feedback from our proposal presentation. To summarize, everyone agreed that the use case was valid, but questioned whether our implementation really fit it. A gym changes slowly, so we needed a better explanation of why we need models and a scheduler, how many cameras we actually need, and where our requirement numbers come from. These questions affect the cameras, parts, and software we would build, so I wanted to work through them before we went further with the design review.

I compared two proposed implementations: one where each camera covers a group of equipment, and another where we have one camera per machine. I estimated the UC gym to have around 10 treadmills, 6 squat racks, and 6 benches, and used that scale to compare setup, power, wiring, bandwidth, and processing needs. I calculated the dedicated-camera workload and put together a small script to see how sampling rate and processing time affect queue delays. These are estimates, and still need to be checked on the Jetson. I currently favor shared cameras covering small groups. A camera per machine would require 22 mounts, power connections, and feeds to maintain. Shared cameras reduce cost and wiring, but require confirming machine locations during setup. Camera count would depend on clear coverage, with separate machine groups to avoid cross-camera matching and double counting.

I also helped check the design presentation against the assignment guidance and worked on explaining the quantitative requirements. One thing the feedback pointed out was the difference between what the user needs and what each part of our system has to do to meet that need. For example, checking once per second and waiting for three consecutive observations takes up to three seconds after a change. Allowing another second for processing and updating the display gives a four-second budget within our proposed five-second target. That assumes the observations are fresh and correct, so it still needs testing. I also worked through what missing our accuracy targets would mean, like showing a treadmill as free when it is occupied or sending staff to check a station unnecessarily. We are still refining those justifications.

To get a better idea of whether shared-camera setup could work, I tried some models (Grounding DINO and SAM 2) on three treadmill photos. The straight-on photo gave five detections matching the five visible machines, including the one with a person on it. The diagonal view was messier, especially for distant machines and reflections, and some masks picked up parts of neighboring treadmills. This helped us think through camera placement and how much setup would be needed. It does not tell us how accurately we can detect whether a machine is in use. See below:

Progress

Behind on the parts order and the capture prototype. Our original schedule had parts ordering and the laptop prototype finished by September 25, with Jetson setup planned for September 28–October 9. I held off on ordering while we reconsidered the implementation, since one camera per machine would change a lot of what we needed. We had to sort out the general direction because it affected the whole team, but I recognize the order is now late. I will check the selected setup with the team, confirm what we can borrow, and submit the missing parts request as soon as possible. The laptop can now run models on still images, but I have not finished the recorded-video pipeline I planned last week. I will work on that while we wait for hardware.

Deliverables

  • Finish helping with the requirement explanations and design slides due September 27.
  • Update the parts list for the setup we plan to build, check inventory, and submit the order and Jetson loan request.
  • Get one recorded feed running through capture and inference, keeping timestamps and measuring processing time, memory, and how old each processed frame is. Repeat on the Jetson once we have it.
  • Agree with Jerry on the observation format and timestamps so my capture pipeline can connect to his application. Keep the results and remaining issues documented for the October 9 design report.