Over the past week, I have been focused on fine-tuning the new motor controller that we received so that the panning would work accurately regardless of where the performer is on stage. Software wise I refactored our implementation to simultaneously handle two types of motor controller. Much of my time was taken by reading the documentation of the new controller and properly configuring the different controllers to work together. I had to begin this new type of integration mostly due to the fact that I had discovered that the replacement motor controller that we ordered was faulty, and so we had to scramble to order a new one off Amazon. I will take this opportunity to complete the rest of the software integration so that both the tracking and the audio components are perfectly synchronized with motor movement. At this point, fine-tuning is the last obstacle I have to overcome, and we are currently reaching the final stage of our product! Super excited to see this completely in motion in a couple of days.
Ahmad’s Status Report 4/18
This week, I made considerable progress on the central Pi’s motion control and tracking stack. I built the homography-based motor control foundation early so software development could continue before the final pan motor driver arrives. I implemented the initial camera geometry model, environment-driven motor configuration, live Modbus motor control, and the first complete auto-tracking pipeline. I then refined the homography, camera placement, startup pose, and projection behavior to improve real-world tracking performance and better align the UWB pose stream, image-space projection, and motor commands so subject tracking behaves more reliably during live motion. Furthermore, I expanded the system into a practical manual calibration with jog controls, mark-left, mark-right, and mark-center tools, and various other commands. Additionally, I added a seamless manual-to-auto handoff which allows calibration to automation to be quite smooth. This work brings Autocam closer to the next phase of integration, where the second motor can be brought online for full pan-and-truck tracking once the remaining motor controller arrives. On the hardware side, I completed the physical setup of the motor system, including wiring, power, and bringing the core rail-drive hardware online, which enabled extensive live testing throughout the rest of the week. Those tests drove a long series of fixes and refinements across manual calibration, startup-state handoff, soft-limit behavior, control responsiveness, live status polling, left-right recovery, and safety polling to make the system behave more reliably under real motion. Now lastly, because leaving the central Pi unnecessarily exposed on a public network felt ironic while taking 18-330 Computer Security, I set up firewall protections to reduce unnecessary exposure and restrict access to only needed connections and not everyone at Carnegie Mellon.
To address the final point, I had to learn practical tools and concepts like Modbus/RS485 motor control, re learn homography and camera geometry which was a nice refresher on Computer Vision, firewall hardening for the central Pi. I learned them through documentation, hardware testing, debugging logs, and a lot of iterative trial and error on the rail system in lab.
Please check out the github for all the progress!
https://github.com/ahmadmla/autocam
Ahmad’s Status Report 3/28
This week I focused on the communication and coordination pipeline for our UWB localization system. I set up MQTT (Mosquitto) based communication between the central Raspberry Pi and the four node Raspberry Pis. Now we can transfer raw distance measurements to the central Pi for processing and filtering. I also reworked the node sender and central logger architecture so that all filtering and localization logic now runs on the central Pi, which made the system much easier to manage and debug. Another note is that centralizing our system allows our nodes to have a much stronger battery life as there is now minimal processing done by the wearable nodes. The centralized system is additionally crucial when integrating our motors, CV camera, and audio cues later on. Having this centralized system all communication goes to reliably initiates our full project implementation. I also fixed several issues during integration, one in which was correcting the node shutdown and restart behavior. Originally I would send “stop” to each node when switching nodes to ping. This caused tons of overhead as it was costly to restart a node. Now UWB sessions properly stop and can be restarted cleanly without breaking serial communication. This was achieved through a custom firmware update, which I introduced “pause” and “activate” key words to allow our anchors to quickly ping node by node. Furthermore, I was able to manually configure the UWB nodes to reliably poll at 20Hz, up from the original, slow 5Hz (4x improvement!). At this point, single and multi node tracking is working reliably and I was able to confirm that the communication pipeline between nodes and the central Pi is functioning correctly. In addition to the software work, I also continued physical system implementation, and I assisted my teammate Ted with laser cutting, material searching, and verification at TechSpark. We are on schedule.
Ahmad’s Status Report 3/21
This week I completed the hardware preparation needed for full anchor deployment by soldering and rewiring all five anchors so they could reliably operate with their battery packs. I validated the setup through over five hours of continuous operation to confirm that the system can support the required runtime. I also flashed and configured the operating systems on all of the Raspberry Pi 5 units, completed device setup, and connected them to the campus network so that our team can remotely access and manage the devices when needed. Additionally, I implemented a real time UWB tracking pipeline to begin evaluating node accuracy and movement across the anchors which now utilize a polygon system to create the 2D space upon configuration of locations. Moreover, I developed per anchor range filtering using a rolling median and adaptive EWMA approach to reduce noise while still preserving responsiveness, then using bounded Gauss Newton multilateration to estimate node position from the anchor measurements while keeping the solution within the valid anchor footprint. Next up I hope to properly calibrate the anchors, and continue fine tuning accuracy. In parallel, I built a live UWB visualizer that displays the anchor layout, current node position, and movement history, along with playback controls for reviewing recorded tracking data. I have also began software preparation on our multi-node configuration, which will be finalized in the next couple of days, maintaining our schedule.
Ahmad’s Status Report 3/14
This week I was able to demonstrate the design behind the wearable node to the opera performers including the configuration of the UWB sensor with the RPI 5, battery pack, and lavalier mic. This demonstration provided the opera performers some insight into the sizing of the equipment to help them with the outfit coordination. We also discussed script cues for future reference including, “FS,” which signals full stage view for our system. Then throughout the week I worked on configuring the DWM3001CDK UWB development boards, flashing appropriate firmware, and establishing reliable ranging between two nodes. I tested one board as an initiator and another as a standalone anchor, while verifying that ranging data could be produced and read through serial interface. Additionally, I explored different power configurations that can be utilized to allow the anchors to function in parallel with the battery pack. These steps confirmed that the hardware stack required for wireless position tracking is functioning!
Team Status Report for 03/14/2026
This week productivity revolved around the team receiving the equipment we needed and meeting again with Dr. Dueck. Our meeting this week with Dr. Dueck where we showcased the design behind the tracking sensors. This demonstration provided the opera performers some insight into the sizing of the equipment to help them with outfit coordination. The meeting was overall successful with continued discussion on script cues and camera operation. Additionally, a novel proposition was introduced to utilize the piano’s audio as a way for the AutoCam to follow script position. Pareekshith received the Lavalier microphones, and after discussion with Dr. Dueck decided that it might be better to track the sheet music rather than the performer’s speech, especially given that it might be hard for Vosk to understand operatic dialogue. The design might change for this reason, and so we might end up having a single microphone next to the piano to get clear audio of the sheet music rather than having each actor with a clip-on microphone. Ahmad’s UWB sensors, battery packs, and RPI 5s have also arrived this week and he has begun testing and integration. Due to the auto shutoff from the battery packs, the UWB sensors will have to be manually connected with additional resistors to draw more current. The software is working well on the other hand with proper anchor and node integration. Ted received the BLDC motors, timing belt, and other various parts for the physical rail. The BLDC motors don’t come attached to connectors, so the VESC motor phase wires will need to be stripped and soldered manually. Additionally, the bearings still haven’t arrived, so physical rail construction is a little delayed.
Team Status Report for 03/07/2026
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.
Ahmad’s Status Report 3/7
The week before spring break, my group and I were focused heavily on completing the design report. Along with working through several sections such as testing and validation requirements, system implementation details, and other technical documentation, I helped guide the team through organizing and finalizing the overall report structure. I spent a lot of time coordinating with teammates to make sure our sections aligned and that the technical decisions we described were consistent across the document. I also ordered the battery packs and UWB sensors right before spring break, and they’ve already arrived, so I’ll just need to pick them up once I’m back on campus so we can begin assembling and testing the hardware. Along with this, we’ve continued working with Dr. Dueck and her students, which has been really helpful for thinking about how we’ll approach testing and getting deeper insights into how the system should behave in real-world scenarios. These conversations have helped us better understand what kinds of testing setups and feedback will be most valuable once our system is operational. I’m excited to get back to Pittsburgh and start connecting all of the components together and beginning our initial testing phase. We also plan to begin building the physical rail system once we return, which will allow us to start integrating the mechanical components with the sensing hardware. Once everything is assembled and connected, we’ll be able to begin validating the system and iterating based on feedback from Dr. Dueck and her students as we move further into development.
Ahmad’s Status Report 2/22
This week, I finalized portions of our design presentation slides, ensuring that Pareekshith, our presenter, has the overview and complete knowledge he needs to successfully deliver the presentation. I made sure he was prepared to answer a wide range of questions regarding my portion of the project, including the UWB trackers, software, and overall system design. I am continuing my research on our UWB sensors and confirmed their configuration within our project. This was vital to concretely ensure that our tracking and vision configuration fully integrates with my teammate’s audio and motor systems. In addition, I prepared the final bill of materials for the team, confirming that we are within budget and proactively mitigating any potential issues that may arise.
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.