This week I have been extensively working on finalizing our UWB setup and finalizing the design with our team. This was a crucial step as each one of our components needed to work seamlessly together. As stated in our previous report, we need to minimize potential risks of order delays and or delays in our software integration. An improper step here could lead us to a rabbit hole of issues and delays which we are actively working to prevent. To reduce that risk, I completed a full architecture review and confirmed a stable deployment plan for our first implementation. The current design uses five fixed anchors, four mobile tags, lightweight onboard compute, Pi Zero 2 W, per tag for local data handling, and one central Raspberry Pi 5 gateway for aggregation and backend delivery. This structure gives us clear ownership boundaries between hardware, firmware, and networking, while also making it easier to isolate failures during testing.
Team Status Report for 02/14/2026
During the week we had the opportunity to meet up multiple times and assign each other roles. For instance, Ahmad is tasked to handle compatibility of UWB sensors and power, Ted is handling motor configuration, and Pareekshith is responsible for the microphone system. We are actively working and communicating to make sure each one of our products are compatible with one another. Some significant risks we have are related to module compatibility. We need certain requirements from modules. For example, the Lavalier mics that we now plan to use need transceivers to connect to the RPi, and we’ll need to find a way to ensure that multiple transceivers, the RPi, and the mics are all compatible with each other. Each transceiver is only compatible with 2 Lavalier microphones, so for scenes with more actors, we’ll have to ensure compatibility among the different microphones and increased transceivers. If we order parts that aren’t compatible, and we only realize that after the fact, we’ll have to wait a decent amount of time in order to research and order a new part. Another issue we might have is that the UWB sensors we plan on using don’t necessarily tend to be waterproof. If these devices are going to be placed directly on the actors, there’s always the chance that sweat or other foreign substances could affect our tag setups. To mitigate these effects, we plan on and are currently doing more extensive research to ensure everything we order has both a way to interface with other modules. This ensures that any parts we might need will arrive in an acceptable timeframe. To solve the UWB sensor issue, we additionally plan on designing some sort of water-proof enclosure that remains ergonomic for the actors and won’t interfere with any design requirements we might have. We are all currently still on track, with no changes being made to the schedule. For changes made to the design, we’ve dropped the original Arduinos and replaced them with RPis, because we will need more processing power for audio and visual. This will cause a slight increase in price, as RPis tend to be more expensive, but our budget is still under 600 dollars for now.
A was written by Pareekshith, B was written by Ted, and C was written by Ahmad.
Part A: Actors utilizing our system will wear lightweight UWB sensors that prevent them from facing any injury risks; having a light sensor will also reduce any discomfort and interference during movements. Also, our system will move at adjustable speeds which can be varied depending on the script and the play, and it can be slowed for greater safety precautions. We plan on putting foam on both sides of the cart in case someone decides to put their finger or hand on the rail system, creating greater safety. This system also reduces psychological stress on camera operators, who often have to make rapid adjustments based on the script and have little to no room for error. Finally, this project gives smaller productions the opportunity to have a better cinematographic experience and to create professional quality films based on their plays.
Part B:
AutoCam might have some issues with privacy/biometric data, as we’re currently planning on using some form of facial recognition/computer vision to track actors on stage in tandem with the UWB tag. If actors/singers are concerned about their biometric data being stored, we plan to only implement realtime processing of data so there’s no long term storage, and because all tracking will occur locally, there will be no possible cloud upload. Recordings will also only be scored locally so that there’s no possible concern of data leakage. Another issue is that audience members who don’t want to be recorded could accidentally be captured. We plan on strictly tracking individuals within predefined UWB anchor zones so that it won’t be an issue.
Part C: AutoCam has several economic implications across production. On the cost perspective, teams save money by reducing dependence on dedicated camera operators for routine tracking tasks, which would lower labor costs for small productions. However, this does not eliminate human roles. This would result in the redistribution of their role from camera operators to script operators. This way they are controlling the camera production through script commands and will have the opportunity to fine tune camera angles, timing, and even zoom. Thus, shifting work to less labor requires extensive tasks like shot supervision, system monitoring, and cueing.
Pareekshith’s Status Report for 2/14
This week, I was working heavily on the final design and the design presentation due next week, which I’ll be presenting for my group. I also requested a USB 3.0 video camera that functions in low light, which is perfect in our scenario of a stage production. I’ve been doing more research on the auditory portion of the project and was able to get through what I was hoping I would be able to accomplish from last week. Specifically, I found certain modules/libraries that come with the Raspberry Pi 5 such as WebRTC VAD for the voice activity detection component and Vosk for the automatic speech recognition portion. During our group meetings, I was also looking into the UWB sensors and their compatibility with the Raspberry Pi 5, and my team and I discussed different options for synchronization of the anchors and the tags to the Pi. My progress is on schedule, and next week, I hope to deliver a good and explanatory presentation and also find the exact microphones that our group should be using. I’m looking at Lavalier microphones over Bluetooth microphones because of their better range, but I need to look into transceiver compatibility with our Raspberry Pi 5 ports.
Ted’s Status Report for 02/14/2026
This week, I’ve been working on our design presentation and finalizing our physical rail design. I’ve been working on interfacing our motor control with the RPi, using a VESC motor controller usb-c connection to communicate with and control the DC motors. Depending on compatibility with other modules, we might swap to using motor drivers instead for movement. We are thinking about a three motor system with each motor assigned for lateral movement, one for pivoting, and one for tilting. We are currently still on schedule, with design finalization expected to be done by next week after the design presentation and report. I’m hoping to finish a CAD diagram of the physical system before the next status report to have a clear and easily editable design that my team can use for info. I’ve started design on the physical implementation, and am hoping to experiment more and finetune once we order and receive parts.
Ahmad’s Status Report 2/07
This week, I had the wonderful opportunity to present our AutoCam project to faculty and classmates. The project remains on schedule, and next week my group and I will finalize the design and bill of materials so AutoCam can be properly laid out. I have also ordered a motor driver from the capstone inventory, which will be essential to our design. Additionally, I have been exploring alternative concepts for AutoCam, including systems inspired by the NFL’s aerial camera setups that use high-strength Kevlar cables. However, this approach may not be feasible within our constraints. I will continue to consider new design ideas to help minimize audience interference.
Team Status Report for 02/07/2026
During the week we presented our proposal to faculty and classmates.The presentation proposed some questions that may jeopardize the success of the project with respect to interference from the audience. We are working on mitigating the potential intrusion of our system to the audience and the actors and will have to discuss more details with Professor Dueck if possible. We are currently still on schedule, and aim to finalize a preliminary design by the end of next week, which will specify the exact components we’ll need as well as how they’ll be integrated with each other. This also pushes to minimize potential risks of order delays by expediting our final bill of materials. Delays would be harmful to our ability to follow the schedule, especially given how our software needs to interact with physical hardware components like cameras, microphones, and sensors.
Pareekshith Status Report – 2/7
This week, I worked with my group to complete the proposal presentation slides and discuss components that would be required. After some discussion, we ordered a Raspberry Pi 5 and a motor driver, and I’m also thinking of ordering the USB 3.0 video camera that’s available on the parts list. I’ve also started taking a look at the auditory component and the technology stack that would be needed to accomplish VAD (voice activity detection) and ASR (automatic speech recognition) reliably. Currently, I’m on schedule and next week, I look to finalize the design of the entire system and its integration with my group, and on my own end, I want to figure out exactly how the audio system would work in tandem with the Raspberry Pi 5 that we ordered. Specifically, I want to see if there are any online libraries or in-built features that come with the Pi that would be helpful for transcribing the speech from the actors’ microphones into usable text.
Ted’s Status Report for 02/07/2026
This week, I collaborated with my other group members on the proposal presentation and worked together to go over what components we might need. I ordered a RPi from the ECE inventory for micro controller needs such as possible audio processing, as well as a motor controller, and am currently still working on physical rail design and motor integration. I’m trying to figure out how to implement the phone mount and rail system, whether it be through a track/wheel mechanism or a line drawn pulley type design. I am still currently on schedule, and I aim to come up with a finalized design and present it to my other group members before the end of next week, as well as go over their possible ideas for what libraries they might be using for their audio/computer vision modules.
