Weekly Status Reports

Some risks we noticed were the RPis we were planning to use with our UWB node weren’t fully compatible with our design. Additionally, a risk that also came to light was the possibility that RPi 5s wouldn’t be consistent in their compatibility with other aspects of our design, such as the UWB nodes and Microphones due to port configuration. Furthermore, what we expect for our project is the fact that we have so many moving parts and modules that depend and interact with each other. If we get slightly delayed in development of one part, the delay could cascade down our schedule and cause pretty bad problems in terms of development down the line. We plan on mitigating these risks by first testing with the RPi 5 to ensure that they work with our modules, as well as including slack time in our schedule to ensure that if we are delayed, we have sufficient time to catch up and finish before any deadlines. As of right now, the only potential change to our design might be the shift from using the RPi 5s to the RPi 4s because of the powering/communication issue that could happen with the Pi 5s and the UWB tags. We do want to test both and see if there is genuinely an issue with the Pi 5. If the Pi 5 works, we’ll stick with that because we already got several from the inventory, and we wouldn’t have to use a portion of our budget on purchasing 4 different Pi 4s. Additionally, we switched to using BLDC motors instead of stepper motors, as we realized the VESC motor controller we’re borrowing from inventory doesn’t support stepper motor operation. Not many costs are incurred, as connections all stay the same.We slightly delayed our ordering schedule to wait for the design review from our TA and Professor Qing. This way we can adjust the bill of materials accordingly within specification. We are now planning to order the necessary parts before spring break starts on 02/28. Doing so will allow us to have the necessary parts and initialize our first prototype.

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.

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.