This week, I’ve mainly been working on ironing out any small design issues with the physical rail system and tuning/calibrating the motor system. We had an issue where the replacement motor driver for the previously broken motor driver also arrived broken (hooray) but we managed to procure a replacement as fast as possible and am working on tuning right now. I’ve also started working on the poster and final report just to save time, and will hopefully be meeting with our SOM collaborators to record a demo with our working product. The main thing to focus on now is the motor tuning so we can capture accurate video for our video demo and our collaboration. The main concern we have now is finishing our motor movement fine tuning so we can have a presentable project before both demo days. At this point schedule isn’t really relevant, we’re just focusing on getting it done as fast as possible.
Team Status Report for 04/18/2026
The only obstacle/risk that’s present on the audio side has to do with the opera portion and the different tempos present in one of the pieces. To mitigate this, we’ll have to contact Professor Dannenberg and get his advice on how to deal with the multiple tempos using Accomplice. Apart from that, the only other obstacle is going through the blocking to figure out where the cues need to be set in the .gro file, but we’ll again communicate with Dr. Dueck and her students figured this out. The biggest obstacle regarding the physical tracking system for Autocam seems to be regarding the feedback loop for the rail. Accurately measuring the position of the trucking could be simultaneously affected by slipping belts, added friction, or even a bearing slightly losing contact with the aluminium pipe. These minute changes in variables could cause the system to be inaccurate when measuring the distance traveled across the x-axis. We aim to minimize these risks by consolidating the rail system and fine tuning and physical issues we encounter. Our mitigation methods include rebalancing the physical rail, use locktite for bearing connections, and re-tightening our trucking belt. We got the trucking part of the Autocam working and live tracking a node this week! Please see our github for more details which we hope and are designing to allow any one in the future to improve upon and create our system with detailed instructions, (GitHub).
Ted’s Status Report for 04/18/2026
This week, I mainly focus on getting the rail system up and running now that we had the replacement parts needed. The design has been slightly modified as we are now using two motor drivers instead of one VESC, and I had to adjust the design of the pan camera mount accordingly. We’re still working on getting the motor tracking up and running, and hopefully by next week we can start implementing the panning motor tracking in tandem with our trucking motor movement. I also began some validation testing, such as measuring noise levels during operation and recording our trucking motor accuracy. Our project is currently behind schedule obviously, but after the whole fiasco with the broken motor controller we’ve made a pretty good pace on catching back up once our replacement parts arrived. For next week, I plan on helping Ahmad get the motor movement calibrated and finish implementing the subsystems together with Pareek’s accomplice and stageplay audio features, as well as testing and validating for our use case and design requirements. Overall, this project has been pretty fun to work on compared to other classes I’ve taken before at CMU. I’ve learned a lot about reading through documentation and ensuring that system parts are compatible before actual ordering and testing. I’ve also learned a lot about the VESC software systems, even though we couldn’t end up using the VESC motor controller in the end. A lot of this knowledge was acquired through learning about similar motor systems or projects people did in the past and learning from their mistakes and combined experience through online forums or write-ups. I also learned a lot about communication protocols such as UART, GPIO, and MODBUS, through similar methods of youtube videos, tutorials, and online forum posts. Learning more about my partner’s project parts was also very interesting, as I had never actually realized how UWB sensors or audio libraries like VOSK or word error rate functioned either. Most of the things I learned from these topics, I learned through talking with my group members and asking questions. Also, while not technical, our collaboration with Dr. Dueck and the School of Music also exposed me to a lot of musical and technical knowledge and terminology about opera and other music performances that I hadn’t known before, which I learned mainly through our collaboration meetings and the questions I was able to ask these talented and experienced performers.
Team Status Report for 04/04/2026
The most significant risk related to the audio portion of the project is the consistency and reliability of Accomplice. While it’s been working for the most part through my testing, there’s been an issue with receiving OSC messages (mentioned more in individual reports) that should be fixed soon by Professor Dannenberg. Although this challenge should be addressed presently, there’s a worry that other issues could pop up in a variety of circumstances, and we’d have to prepare and solve each of them. This shouldn’t be impossible, but it might be difficult and annoying, especially because we wouldn’t know if it’s an issue on our side or in the Accomplice software unless we check in with Professor Dannenberg continuously. Another possible risk we have is that the VESC motor controller we’re currently using had one of its micro-usb ports for communication break off, so we’ll try to solder it back on. If that fails, we plan on trying to use the UART communication ports with the GPIO pins to control. We also had one of our printed parts for the rail system break recently, which delayed our assembly by a bit. To counteract this, we plan on printing extra parts for high strain areas of our design to ensure that if any future parts break, we’ll have a quick way to replace them and get back to testing/building.
One minor change that was made to the design of the audio system was the usage of a USB-B to USB-C adapter instead of the predetermined MIDI interface for connecting the MIDI keyboard to the Mac. Our idea is to have a RPi 5 connect to the keyboard and send cues to the central Pi, and so we will check that the USB-C port on the RPi keyboard can be used for a non-powering purpose. If this doesn’t work, we’d have to purchase an adapter from USB-B to a different USB type that’s available on the RPi. This causes one of the nodes to be used as a middle communication device as it’ll provide key information for the AutoCam system to change scenes. This upcoming week we hope to finalize the hardware integration of the AutoCam. As we finalize the hardware integration, we can bring all the systems together. From the audio cue system to the UWB tracking system. We will utilize both systems to finalize the motor controller software. This will be specifically done through the mathematical work of homography. For validation, we look to confirm the durability and the consistency of our product. We will be running the entire system at expected workloads to determine that it can work accurately for the full length of an opera or a theater performance. Each subsystem’s accuracy will be vetted thoroughly, and descriptions have been included in the individual reports. Validation testing will be done to measure the latency between the completion of the performer’s dialogue, the triggering of the cue, and the actual movement of the motors, which can then be used to optimize and minimize the time required. Additionally, final UWB accuracy testing will be performed from ground truth location to the filtered estimated location of the node. Finally, we will be testing the waterproofing nature of our wearable components and ensure that they are wearable and durable based on survey feedback from the performers and stress testing with water at different intensities. Noise levels will also be measured to ensure that our design won’t be overpowering the important audio in either the opera performances or stageplays. We’ll be spending the next couple weeks working with the opera students to ensure that our system meets their needs and fine tuning our subsystem integration.
Ted’s Status Report for 04/04/2026
This past week, I’ve been working on finalizing the rail design. Unfortunately, one of our gt2 pulleys broke during assembly, so we’ve been a little delayed in getting the pivoting motor movement up and functional. I spent this week mainly focusing on getting the rail system up and running, by finishing any possible parts we would need cut/soldered/printed. We also had a micro-usb port break on the VESC motor controller while soldering, and I’m currently working on a backup plan for firmware installation and communication in case we can’t get that fixed. I’ve been working on creating some jst-ph style connections for communication from the VESC to our GPIO pins using female dupont connectors on our RPi. I’ve also begun working on some rudimentary motor control code using a GPIo communication library with our motor controller for simple lateral movement to ensure that all our connections have been soldered correctly with no major issues that’d require disassembly down the road, which would require a lot of time and wasted effort. For verification testing, as mentioned above, I plan on first writing some motor movement code to test that our VESC to RPi communication protocols are working correctly, and then using test inputs to simulate UWB sensor communication and ensure that the rail system is moving how it’s supposed to. Noise level requirements will be tested using a decibel meter that will positioned at different locations during motor testing to ensure that our noise level is below our specified amount. Once replacement parts have been procured and our VESC repaired, I hope to get our full system up and running so we can start testing with our other subsystems and the opera students. For now, I plan to write some simple test code and fix any issues that might arise from that and hopefully have a complete system before next week.
Ahmad’s Status Report for 04/04/2026
Over the past week, I have been heavily focused on the UWB tracking system and its physical integration. Significant progress has been made through continued refinement, and I successfully mapped out the opera rehearsal room to support more accurate testing and tracking. From there, I concentrated on improving the code and debugging the system to ensure the highest level of accuracy possible. For instance, one of the key improvements was the addition of height calibration to the software implementation. This enhancement allows the AutoCam system to achieve considerably better accuracy in a wider range of situations, especially when tracking movement in a three dimensional space. This is vital when the height position of the anchors do not match the height of the node. In addition, the AutoCam system has entered the final stages of hardware integration. This has involved wiring the motors, assembling the pulley system, and connecting the central Raspberry Pi processor. One key component is that a microusb port is broken on our motor controller. I was able to find a replacement part for the port and began soldering. We were also able to meet with the opera group, further surveying questions, issues, and movement. I took the opportunity to note their movements during the opera, which provided useful insights into blocking patterns, transitions, and the areas where the tracking system will need to respond effectively. These observations will help guide further calibration and camera movement tuning so that the AutoCam can better match real performance capabilities. With both the software and hardware coming together, the system is moving closer to a fully integrated and functional state. This next week we hope to have the full system operational to begin our final testing stages.
Updated Schedule
Ted’s Status Report for 03/28/2026
This week I focused on getting the rail system up and running for testing and coordination with our other subsystems. We met with Dr. Dueck and we went over various parts of our design, such as rail length and integration with the audio system to meet requirements for working with the opera students. She introduced us to Dr. Dannenberg, who’s given us a lot of helpful input on how the MIDI audio input interaction might work and what we might need to do.I finished using Solidworks to design all the parts needed, cut them all out at TechSpark, and have been working on assembling the rail system. I’ve had to redesign various parts of the rail such as the motor pulley system as the original design isn’t within tolerances for our belts and camera mount assembly. I’m currently working on getting the VESC and RPi set up and communicating. By next week, I hope to get motor control code working so we can begin testing with our different subsystems together. Our design is still on schedule, and I’m hoping to get the motor code working in tandem with our UWB sensor code on the central processing RPi so we can determine if it will bottleneck processing or not. I also helped Ahmad with testing the UWB tracking system. We are currently still on schedule, and hope to have a basic full implementation consisting of audio, rail, and UWB tracking soon.
Ted’s Status Report for 03/21/2026
This week, I worked on connecting the VESC motor controller to the BLDC motors and power source. I mainly focused on CADing (is that the right acronym?) the 3d driver pulleys, idler pulleys, motor plates, and other miscellaneous things and printed them before our meeting Saturday. Then, I hooked up the motors to the VESC, power source, and RPi and tested them to see if all the connections had been soldered correctly and were functioning. Bearings have been delivered, but I wasn’t able to pick them up before the ECE office closed. I’m hoping to pick them up and finish constructing the rail monday, and then begin testing with our completed UWB sensor/node system. In terms of schedule, we’re developing most of our subsystems at the same time, and once the rail is finished and all parts are received, we should be at a good pace. I need to reprint some of the pulleys for a better fit on the timing belt, and I hope to get that done by next week as well. I want to reduce wear and tear as much as possible. The open source configuration software for the motor controller is a bit finicky to work with, and I’m trying to get experienced with it as fast as possible.
Ted’s Status Report for 03/14/2026
This week, we met back up with Dr. Dueck and received some feedback on the design of our wearable nodes, showing them a rough prototype to give them an estimate of what type of device they’d have on their person. I’ve also received some of the parts and have been working on interfacing the BLDC motors with the VESC motor controller. The VESC motor controller 3-phase wires come preequipped with MR-30 connectors, but the BLDC motors just come with rough wires. I’m thinking of just chopping off the connectors and simply just soldering the phase wires directly to the motor controller instead of attempting to install any MR-30 Connectors. One of the micro-usb connections on the VESC is a little loose but it shouldn’t be a source of any issues unless under heavy vibration. I’ve also finished designing the GT-2 timing pulley that will be used with our motor and timing belt, and plan to print it soon. I’ll be printing multiple copies incase they shatter or break during testing so we won’t have to wait an extended period of time to replace it. Schedule is still on track, and by next week once ball bearings have been delivered I hope to begin construction of the rail itself.