Category: Ahmad Status Report

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.

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

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. 

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.

 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!

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.

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.