Team: The week prior to Spring Break, we focused on 3 actions: completing the design report, ordering the correct parts, and beginning our collaboration with Dr. Dueck and the School of Music. Based on our first meeting with Dr. Dueck, the most significant risk we encountered was regarding the audio subsystem of the project. The library we plan to use, Vosk, is meant for conversational speech, not operatic dialogue, and so this could pose a difficult problem for us. We will definitely test our system and audio pipeline with opera and check if it works under a workload like that, and our contingency plan will be to use the remote-controlled method for opera and other similar musical productions. The good news is that Vosk is compatible with multiple languages, which is great for international productions, but the issue about speech recognition when the speech is operatic still persists, and we can only determine the exact performance once we receive the parts, assemble them, complete the software, and integrate both sides. No changes have been made to our design, and as a reminder, the remote-controlled operation is our MVP, so that will be something we develop anyways and can use to confirm proper performance under all conditions. Our schedule is technically one week behind, but that’s mainly because we forgot to account for spring break when formulating our schedule. Our two weeks of slack time is able to make up for this loss.
A was written by Pareekshith, B was written by Ted, and C was written by Ahmad.
A: The design of AutoCam was made keeping in mind the fact that the productions utilizing our product probably wouldn’t be very technologically savvy, and so we’re trying to make it easy to install, easy to use, and easy to get great results. As mentioned before, we are aiming for a smartphone-agnostic design, so anyone from around the world could use AutoCam for their own purposes with whatever phone they have, and the potential use cases are vast. We want to keep options open for users, so we’ll be looking to have a feature where the system is remote-controlled, giving productions the hands-on experience that they might desire, and we’ll also be using speech technology to process dialogue and enable cueing. Different use cases will call for different implementations, and we want to give that freedom to potential users. Finally, we are designing AutoCam keeping budgets in mind, as we want to democratize filmmaking and cinematography for aspiring directors and filmmakers around the world.
B: Theater and stageplay is inherently a cultural experience. Stageplay, theater, and even oral history all share deep cultural roots in many societies around the world. Stage performances are especially governed by anything from audience expectations and behavior norms within a theater environment. In most performances, silence and minimal distractions during important scenes is generally expected. Because of this, we designed AutoCam with these norms in mind, and wanted to ensure that our system would output as little noise pollution as possible. Our design utilizes brushless DC motors in order to disrupt the audience experience as little as possible. Additionally, we’re hoping that our system will accommodate different languages by using speech recognition libraries that can be tuned for different languages and styles of performance, like spoken word vs opera. The wearable components are also intended to be lightweight and discreet so that they won’t interfere with performers’ costumes, stage moment, or cultural performance practices.
C: Environmental factors are considerable as an engineer, and placing these factors in high regard can help us better understand the beneficial and detrimental effects of our product. In this case, AutoCam poses little to no direct threat to the natural environment, since it is a small scale system intended for indoor use in stage productions. It does not require hazardous chemicals, produce emissions during operation, or consume large amounts of energy compared to traditional large scale filming infrastructure. Most of the system’s components, such as the Raspberry Pis, UWB sensors, microphones, and camera hardware, are low power electronic devices, and the physical rail itself is being constructed primarily from lightweight materials like plywood and copper piping. By using a smartphone as the recording device rather than a specialized high power camera system, AutoCam also helps reduce the need for more resource intensive equipment. On the other hand, environmental considerations still matter in the design of AutoCam because electronic systems contribute to material waste and energy consumption over time. To address this, we desgined the system to be durable, reusable, and modular so that individual components can be repaired, replaced, or upgraded without discarding the entire product. This is especially important for parts such as the wearable nodes, sensors, and rail hardware, which may experience repeated use across multiple performances.