Jerry’s Status Report for 9/26

Accomplishments this week

This week, I organized a review of the instructors’ proposal feedback and the evidence behind our design choices. I used research and code-review assistance to examine camera coverage, recording permission, requirement justifications, alternatives to machine learning, and how the three checks share the local computer. I then compared these findings with Alan’s new design-review material to identify the changes needed for the presentation.

For my application and integration area, the main outcome is a clearer definition of the situations our equipment rules must handle. A blocked camera should not count as a reliable absence. One missed item detection should not restart an unattended timer. Someone walking past a rack should also be distinguished from a persistent presence at that station. The original prototype documents a case where a lingering person delays a flag, which reinforces the need for explicit tests.

I also coordinated preparation of the revised presentation, feedback-response document, purchasing instructions, and weekly-report drafts. This work gives the team a consistent set of requirements and separates completed experiments from estimates and tasks that still depend on hardware or permission.

Schedule status and corrective actions

The design review and integration planning have progressed, but the application implementation needs to catch up with the earlier goal of a dashboard driven by fake data.

I will build the smallest useful application path first: read a timestamped observation, update one treadmill or station, and display the resulting state. This can be developed without waiting for cameras or the Jetson. Once that path works, I will extend it to the unattended timers and connect it to Harry’s capture pipeline.

Deliverables for next week

  • Agree with the team on equipment states, the configurable five-minute waiting period, and how to handle unknown or outdated observations.
  • Build a dashboard using fake or recorded observations, showing treadmill availability and station flags without displaying live video.
  • Write tests for departure, return, passersby, brief detection mistakes, item removal, and blocked or disconnected cameras.
  • Define the observation format and timestamps with Harry so that the capture pipeline can connect to the application.
  • Coordinate the recording-permission request and track its actual status.
  • Save a small end-to-end demonstration and document its limitations for the October 9 design report.

Alan Wang’s Status Report for 9/26

Accomplishments this week
This week, I prepared the design-review presentation and its supporting material. The package includes ten slides, architecture diagrams, design alternatives, a testing plan, a schedule, speaker notes, and scripts for generating the figures and slides. I also documented our decisions, preliminary evidence, and remaining questions so that this work can support the design report.
I included preliminary experiments investigating the vision approach. The detector check confirms that YOLO11n recognizes people and some common belongings, but its pretrained classes do not include weight plates. On generated gym stand-in images, some plates were assigned an unrelated class. This means the bench check needs its own validation and potentially training; a confident detection does not establish that the object is a weight plate.

Schedule status and corrective actions
The design-presentation work is in place, while camera-placement validation and real-footage testing remain open dependencies. These tasks need attention so that the design report can include evidence from representative scenes rather than only preliminary examples and simulations.
I will resolve the recording location and permission status with the team. If gym access is unavailable, we will use an appropriately authorized controlled setup with consenting participants. I will also help revise the presentation so that estimates, simulations, and measured results are clearly distinguished.

Deliverables for next week
•    Finalize the vision-related claims and figures for the design presentation due September 27.
•    Prepare a scene checklist covering occupied and empty treadmills, belongings left at a rack, an empty bar, plates on a bar, and plates correctly stored nearby.
•    Collect an initial approved set of staged examples and document the camera angle and lighting. If approval remains pending, finish the test protocol without recording unapproved gym footage.
•    Compare simple image processing with a detector-based approach and document failure cases.
•    Determine what additional labeled plate data is necessary before beginning a larger training effort.

Jerry’s Status Report for 9/19

Accomplished

I presented our proposal on Monday, so a good part of my week went into the slides, rehearsing, and preparing answers for questions on our timing numbers and on why we use a scheduler rather than one shared model.

My technical task this week was writing out the equipment states and timer rules, which is the logic the rest of the application is built on. A treadmill is available, in use, or unknown, and a rack or bench is in use, free, or flagged. I also wrote down the rules the timers follow, including when a timer starts, that it only runs while nobody is at the station, that a person returning resets it, and how a flag clears once the station is reset. Getting this written down early matters because both the detection work and the scheduling work feed into it, so we all need to agree on what a detection is supposed to mean. A couple of open questions came out of it too, like how long someone has to be in a zone to count as returning so a person walking past does not reset the timer.

Progress

On schedule. The states and timer rules were this week’s task and they are written up.

Deliverables

Start on the dashboard, beginning with a version running on fake data so we can see the treadmill count and station flags before any real detections exist. Write tests for the timer rules using made up detection sequences. Help with the design presentation slides.

Alan’s Status Report 9/19

Accomplished

This week I looked at how much of our detection we get for free from a pretrained model. I went through the classes it covers and wrote a short script to run it over gym images and count what it finds. People, backpacks, handbags, and bottles are all classes it already knows, which covers most of what gets left at a rack. Weight plates are not, and neither are towels, so the bench check will need training on our own labeled images rather than working out of the box. That is what we expected, but it is good to have it confirmed early. I also started looking into whether any public datasets include gym plates so we do not have to label everything from scratch.
I started on camera placement as well. The main issue is that people and equipment block the view, so I have been working through mounting height and angle for each check and what each camera has to be able to see. The bench camera is the tricky one, since it needs both the bar and the plate storage area in frame so we can tell plates that were put away from plates left on the bar.

Progress

Mostly on schedule. The detector work is done and the plate result was not a surprise, since time to collect and label images is already in our schedule. The camera placement plan is started but not finished, and I will finish it Sunday.

Deliverables

Finish the camera placement plan and take photos of the candidate positions. Record a first round of footage, at the gym if permission comes through and at a mock setup otherwise, and start labeling plate images. Help with the design presentation slides.

Harry’s Status Report for 9/19

Accomplished

Most of my week went into the parts list. I put together a bill of materials covering the Jetson Orin Nano Super, three USB cameras, storage, mounts, and the cables and adapters we need to actually get it running, and checked how the pieces fit together. A few things came out of that. The dev kit comes with a power supply and a WiFi module already installed, but no storage at all, so a card or drive has to be ordered with it. Its video output is DisplayPort rather than HDMI, so we need an adapter for whatever display we end up using. We also planned for a powered hub so that three cameras plus a keyboard and mouse are not all drawing from the board, and for active USB extensions, since the cameras need to sit well away from it and plain USB cables stop working past a few meters. I marked which items are worth checking the course inventory for before we order anything. I also started getting a development environment going on my laptop so the pipeline work is not blocked on hardware.

Progress

On schedule. The parts list was this week’s task and it is done. The laptop environment is started rather than finished, and I will wrap that up Sunday.

Deliverables

Submit the parts order and ask course staff about borrowing a Jetson in the meantime. Get the laptop prototype running a detector on recorded video with timing. Help write the design presentation slides due 9/27.

Team’s Status Report for 9/19

The most significant risk right now is parts lead time. Purchasing opened after the proposal presentations, so this week we finalized our parts list and we plan to submit the order early next week. Nearly all of the hardware work depends on the Jetson arriving, so a late delivery would push back setup, camera capture, and integration together. Fall break is already marked as slack on our schedule, so a delay of a week or two can be absorbed.

If the Jetson does take a while, we can keep moving by prototyping on a laptop. One of us has a Windows laptop with an NVIDIA GPU, so the detection pipeline and the application logic can be built and tested there in the meantime, and it also gives us a machine to fine tune the plate model on later. The code carries over, but the environment does not entirely. The Jetson runs a different processor architecture, so the builds and installed libraries are different, and models have to be converted on the board itself. Speed and memory also behave differently, since the laptop is much faster and its graphics memory is separate from system memory, while the Jetson shares one pool between the two. So anything we measure about timing, memory, or scheduling still has to be measured on the Jetson.

The second risk is getting permission to record at a campus gym, since we need real footage to check that detection works from our camera angles and to build a test set later. We started that request this week and will send it early next week. If it does not come through, we can record at another gym with permission, and we can still test most of the logic on a mock setup.

The third risk is that the pretrained detector does not know what a weight plate is. The model we plan to start from covers people, backpacks, handbags, and bottles, but plates are not one of its classes, so the bench check will need training on our own labeled images. We are treating that as likely rather than optional, and the time to collect and label those images is already in our schedule.

No changes were made to the design this week. The three checks, the timing targets, and the hardware plan are the same as what we presented. No changes to the schedule either.

Outside of the technical work, we set up how we work together. We created a shared GitHub repository holding our proposal, slides, course guidance, and design notes, and turned on branch protection so nothing goes onto the main branch directly. We review each other’s work through pull requests instead, which already helped catch a few things in the proposal before we submitted it. We also presented the proposal on Monday and completed peer reviews on Monday and Wednesday.