Adithi’s Status Report for 3/14

Accomplishments

This week, one of the main things I was tasked with was finding our sources of corroded metal sheets. My contact from the trade center said that we could possibly visit some junkyards to find sheets of metal. I went to go look this week but didn’t really find anything. Another approach I have also been exploring is reaching out to student organizations since buggy and booth teams are likely to have old scrap metal. I have found one metal sheet which we can utilize and hope to find another. Since our team has received the metallic ducts, I have been working on getting them assembled to form our HVAC duct for our demo.

The robot chassis was put together and I tested the motor controller code and it is functional. Outside of this, I have started writing code for our ultrasonic transmitter and receivers to interact with our ADC module. I still need to solder some components we have received but this week I mainly worked on figuring out integration.

My work this week has mainly been on Github and can be found here: https://github.com/aphadke234/ece_capstone_C7

Schedule

I am on schedule now and currently on track. I have been writing the code for integration and Mahati has been helping me while Rayann continues to refine the ML model. In 3 weeks time by the interim demo deadline, we hope to have a moving robot inside the duct with an okay classifier detector machine learning model.

Next Week

Next week, I need to order the remote control I have found as well as our final components for our project as well as some extras. I also need to do a budget check since we should have a significant amount of money left to spend. This week, I plan to get the system set up where the robot can move autonomously for now, conduct a solenoid tapper for when a crack is detected (I will just be coding the movement response of this tapper), getting the ultrasonic transmitters and receivers to work functionally with the ADC and send data to our laptop. I also need to update our design module diagram since it has changed a little bit.

Team Status Reports for 3/14

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

Significant risks to the project include challenges with hardware integration, material variability, and component fit during assembly. Integrating the robot chassis with the acoustic data collection system introduces the possibility of vibration or electrical noise affecting sensor accuracy. To manage this risk, the hardware layout has been updated to better isolate acoustic sensors from vibration sources, and modular mounting methods are being used so components can be repositioned if interference occurs. Another risk involves the variability of corroded and cracked materials collected from junkyards for testing, which may lead to inconsistent results. To address this, our data collection program details the process of obtaining multiple samples to ensure a range of realistic testing conditions.

 

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

This week, our team built the robot chassis and updated the hardware design. The changes made to the hardware design include a redesign of the acoustic signal collection system. We updated the acoustic data collection hardware to ensure that the system can capture meaningful and reliable measurements from the ultrasonic transmitter and receiver. The original hardware configuration was not optimized for accurately detecting the high-frequency ultrasonic signals, which could have resulted in noisy or weak measurements. The ultrasonic sensors have been delivered, but not yet mounted onto the robot. This week, our team also obtained the HVAC ducts and had some of them cut and fit together. Members of our team have also been visiting junkyards to find corroded and cracked sheet metal to prepare for the data collection phase.

 

Provide an updated schedule if changes have occurred.

Currently, we are on schedule with entering the data collection phase next week and testing the robot with code. Next week, we will begin collecting acoustic data using the ultrasonic sensors. For now, we will focus on healthy duct data since we have yet to obtain corroded or cracked material. We will also begin testing the mobility and movement accuracy of the robot chassis.

Rayann’s Status Report for 3/14

This week, I completed the Individual and Group portions of the Ethics assignment. I reflected on how the design of this project affects others in a societal, economic, and global perspective. Also, my group and I had a discussion about changes in the physical design. Since we are using ultrasonic transmitter and receiver sensors, I had to change the design of this system. Before, we had discussed a microphone picking up the acoustic signal from a tapper hitting the wall of the duct. Now, a controlled voltage source will excite an ultrasonic transmitter, generating high-frequency acoustic waves that propagate through the duct system. As these waves travel along the duct, they interact with the geometry, boundaries, and internal features of the structure, producing reflections, attenuations, and resonances that collectively form a unique acoustic signature. An ultrasonic receiver positioned along the duct will detect the returning or transmitted waves and convert them back into an electrical signal. This weak signal will pass through an amplifier stage to increase the signal amplitude and improve the signal-to-noise ratio. The amplified analog signal will then be digitized using an ADC, allowing the waveform to be captured and analyzed using digital processing techniques. In terms of physical build, we completed building the robot chassis using the step-by-step guide online. I cut a couple of the healthy (no defects) HVAC duct pieces so they can fit together. After the acoustic sensors were delivered, I tested them to ensure they were functioning properly. I had to build a circuit that provides voltage to the transmitter and test that voltage was collected by the receiver. I also created a structured data collection plan detailed in the linked document.

 

Next Steps:

  • Begin healthy duct data collection using my plan

My work for this week can be found here: https://docs.google.com/document/d/1TeiFjeiLWfSxhGB2HdTZP7nY7KFwsyw6Oc9VAkEphX8/edit?tab=t.0

Team Status Report for 2/28

What are the most significant risks that could jeopardize the success of the project? How are these risks being managed? What contingency plans are ready?

One of the most significant risks at this stage of the project is ensuring that the dataset we collect from the HVAC ducts is large and diverse enough to train a reliable machine learning model. Because we decided to build our own dataset rather than rely solely on existing research datasets, the success of our model now depends heavily on the quality and quantity of the acoustic data we collect. If the dataset is too small or lacks variation, the SVM classifier may overfit and fail to generalize to new ducts. To mitigate this risk, we are structuring our dataset carefully by collecting baseline recordings from healthy ducts and then introducing controlled mechanical defects in stages (minor, moderate, and severe). This staged approach allows us to capture progressive structural degradation and increases the diversity of the training data. As our worst case contingency plan, we would need to supplement with pre-existing structural health monitoring datasets. However, this is the worst-case scenario because the data in these datasets might vary significantly from what we are aiming to test on and therefore might make our model more complicated. 

Another risk is the integration of the hardware components, particularly ensuring that the sensors, tapping mechanism, and Jetson-based computing platform can reliably capture and process acoustic signals. If the hardware components are not synchronized properly or if the signals contain excessive noise, this could affect both the data collection and the real-time analysis. To manage this risk, we are testing the signal processing pipeline early using simulated or preliminary data and researching amplifier and sensor configurations that will improve signal quality. Additionally, we are reviewing testing methodologies from relevant research papers to guide our experimental setup. As a contingency plan, we can simplify the real-time processing requirements by performing some of the feature extraction offline if we experience performance limitations.

Were any changes made to the existing design of the system (requirements, block diagram, system spec, etc)? Why was this change necessary, what costs does the change incur, and how will these costs be mitigated going forward?

We made some refinements with our system design clarifying how we will structure the defect categories used for training. Rather than using random or unstructured damage, the dataset will now be organized into controlled defect severity levels such as healthy, minor damage, moderate damage, and severe damage. This change improves the interpretability of the model and ensures that the classifier learns meaningful acoustic signatures associated with progressive damage. The cost incurred from these changes is the additional time and effort required to physically create defects in the ducts and collect labeled data. We plan to mitigate these costs by standardizing the testing procedure and collecting multiple recordings per defect stage so that we can generate a sufficiently large dataset from a limited number of duct samples in the coming week. 

Provide an updated schedule if changes have occurred.

The overall schedule of the project remains mostly consistent, but the timeline for dataset development and testing has been adjusted slightly. Now that the HVAC ducts and parts have been obtained, the next phase of the project will focus on collecting training data from intact ducts and validating the signal processing pipeline using this data. During the same period, the team will continue integrating the embedded system components that will eventually automate the data collection process.

Part A: Global Factors

LeakLink addresses a global need for more efficient and scalable inspection of HVAC duct systems, which are widely used in commercial buildings, hospitals, schools, and industrial facilities worldwide. In many regions, HVAC infrastructure is aging, and regular inspection is required to maintain indoor air quality and system efficiency. However, current inspection methods often rely on manual labor and expensive specialized equipment. Our solution provides a lower-cost and more automated alternative that can help facility managers detect structural damage such as cracks or corrosion earlier. This is especially relevant in large urban environments where buildings contain extensive duct networks that are difficult to inspect manually. By enabling faster and more frequent inspections, the system can support preventative maintenance and reduce long-term infrastructure costs globally.

Part B: Cultural Factors

In many building maintenance settings, technicians rely heavily on practical experience and quick diagnostic methods rather than complex analytical tools. Our system is designed with this in mind by providing clear classification outputs that can be easily interpreted by technicians without requiring extensive training in machine learning or signal processing. Also, this system will not replace the need for HVAC technicians and engineers, but rather feed into the narrative of human-machine collaboration. Additionally, maintenance practices vary between regions and organizations as some emphasize preventative inspections while others focus on reactive repairs. By providing an automated tool that identifies damage early, our system can help encourage preventative maintenance practices and sustainable building maintenance practices by reducing energy consumption and minimizing the material waste associated with replacing damaged HVAC components. This aligns with cultural trends around energy efficiency and climate responsibility, especially in cities pushing for greener buildings.

Part C: Environmental Factors

HVAC systems are one of the largest contributors to energy consumption in commercial and institutional buildings. Structural damage such as cracks and corrosion in ductwork can lead to significant energy loss due to inefficient airflow and pressure drops. LeakLink aims to detect these issues early so that repairs can be made before energy inefficiencies worsen. By enabling earlier detection of duct degradation, LeakLink can reduce wasted energy and improve overall HVAC efficiency. Additionally, identifying damage before it becomes severe can extend the lifespan of duct infrastructure, reducing the need for large-scale replacements and minimizing material waste. Currently, metal HVAC ducts are not routinely inspected due to the time and effort it takes to disassemble panels to perform checks, leading to the entire system worsening over time and needing to be replaced. Furthermore, LeakLink will provide the exact location of the defect whereas normal tests just indicate that a defect exists. LeakLink will perform regular system checks so only individual panels that are identified as degraded will need to be replaced. This supports more sustainable building maintenance practices and reduces the environmental impact associated with HVAC system failures.

A was written by Mahati, B was written by Rayann, and C was written by Adithi

Mahati’s Status Report for 2/28

This week’s progress: 

This week I continued working on the SVM and tried to research more in depth into the alternative methods. I also wanted to figure out the logistics of training as this will be one of the main things that we would be moving forward with. 

Adithi has obtained several large HVAC ducts from the trade school. These are galvanized steel square ducts approximately 1 ft × 1 ft in cross-section and 5–6 ft in length. These ducts will serve as the primary physical samples for generating the acoustic dataset used to train the model. For training, the goal is to generate a dataset with clear, controlled categories of structural degradation so that the classifier can learn the acoustic signatures associated with different defect types. Rather than introducing damage randomly, the plan is to structure the dataset around several levels of defect severity. 

Last week I did quite a bit of research looking into how we could structure the corrosion aspect of testing. However, during our meeting with the professor, we got the suggestion that it would be better to obtain HVAC ducts that were already corroded and focus more on the cracks simulation on the clean ducts that we obtained. So this week I tried looking more into the specifics on training for the HVAC ducts that we have:

For each duct sample, we will first collect baseline recordings with no defects present. These recordings will capture the acoustic and vibration characteristics of a healthy duct under consistent excitation conditions. The baseline data will act as the reference class for the model.

Next, we will introduce controlled mechanical defects in stages. Based on the discussion from the last meeting, the idea is to introduce multiple cracks of varying lengths and depths so that we can capture how the acoustic response changes with increasing structural damage. For example:

  • Minor damage condition: introduce ~3 small longitudinal cracks (≈0.5–1 mm width and ~1–2 cm length).
  • Moderate damage condition: introduce ~6 cracks (1–3 mm width and ~3–5 cm length).
  • Severe damage condition: introduce ~10 cracks or slots, including several deeper partial-depth cuts (up to ~25–50% wall thickness).

These cracks will be distributed across the duct surface rather than concentrated in a single location so that the model learns generalized damage signatures instead of position-specific effects. At each stage of damage, we will collect a new set of acoustic and vibration recordings. This staged approach allows the dataset to capture progressive degradation rather than only binary healthy vs. damaged states. Ideally, each condition will include multiple recordings (e.g., 20–50 samples) to account for variability and improve model robustness. This will also let us get away with gathering more data from a limited number of HVAC ducts. 

Overall, the training dataset will therefore consist of three types of samples:

  1. Healthy ducts (baseline recordings)
  2. Ducts with controlled mechanical defects
  3. Naturally corroded ducts

Collecting data across these categories should provide enough variation for training the initial SVM model and later experimenting with more advanced models if needed.

Here is my progress for the week (Continued research on training, and my improved SVM model): https://docs.google.com/document/d/1FbG87Cg-6bPmjf2CVkg7BYE6hkrSWeNEl6PgoUjYYN8/edit?usp=sharing 

Things to do for next week:

Next week is spring break, so I will be traveling. However, I will still try to assist Adithi remotely with parts of the embedded system integration while she is in the lab. The main goals for next week will be:

  • Start collecting baseline acoustic and vibration data from intact ducts.
  • Work with Adithi on the embedded systems control logic for synchronized sensor data collection.
  • Begin organizing the dataset structure so that recordings from each defect stage are labeled and stored consistently for training.

The main thing will be to get adequate training data, contact people for already corroded HVAC ducts, and work on embedded logic.

Adithi’s Status Report for 2/28

Accomplishments

This week, one of the big deliverables my team and I worked on was our design report. I was mainly responsible for explaining hardware and system design, design choices, design requirements, and the diagrams involved. I was also ultimately put in charge of formatting. The design report allowed us to finalize designs, explain trade offs and choices, and give readers an understanding of what our HVAC robot does.

Outside of this, I was able to refine the code for our robot’s motors, including the use of the motor driver we ordered and pushed this to the Github repository our team now has. I also found an online open source repo which I was referencing since I decided it would be better to use ROS1 for now and then move to using ROS2 once our robot does simple solenoid tapping and moves. Based on my research, NVIDIA is pushing towards ROS2 and it will be better long term, but since we are still prototyping, I will start with ROS1 and move to using ROS2.

I also went to a trade school to acquire the HVAC ducts. For now, we got sections of HVAC ducts that are not damaged. I will be going to the Junkyard to get metal scraps, and am aiming to follow up with Techspark and the Civil Engineering Department to get metal scraps that are rusted or have defects like cracks. I can also manually make sustained cracks on the metal we have so we will first be collecting metal sound data on healthy data. I have tried collecting data with a mic and will get this to Rayann and Mahati for the signal processing.

Resources for motor control and robot chassis and code:

Schedule

I am on schedule now and currently on track. Our parts just arrived so I have compensated by writing the initial code and am confident going into next week to test out our design. My partners are also working on the ML model and our professor is confident in our progress.

Next Week

Next week, I plan to take the parts we receive to build the initial robot chassis and have motor control. I will also put the solenoid tapper together and figure out how to make our robot chassis remote controlled. Before the remote controlled part, we will control the motor movement using our MCU and IMU. I also plan to begin testing simple connections with the solenoid tapper which will help me decide if these parts work well. I will go and collect damaged panels to put inside our ducts. One of the things we need to figure out is what our interim and final demos will look like, and I will begin writing code to integrate all our parts together: the solenoid tapper system, the camera, and motor control. I will also begin research into a remote so that the robot can be controlled by a remote control rather than on a laptop.