Rayann’s Status Report for 2/28

This week, I finished the rough draft of the MATLAB code for the acoustic signal processing. The implementation includes signal pre-processing steps such as bias shifting and noise reduction, followed by feature extraction and initial analysis routines. The code is split into sections of time domain features, statistical features, and frequency domain features, which makes it easier to add more features if required in the testing and validating phase. Currently, the features chosen are completely based off of the literature review. When we begin data collection, these features can be modified or new features can be added.

In parallel, I conducted a deeper technical review of the ultrasonic sensor we purchased and  researched different amplifiers we could use with an ultrasonic sensor. This helped clarify integration constraints and informed both the signal processing assumptions and hardware design decisions. I documented key performance parameters to ensure alignment between the physical sensing capabilities and the software processing pipeline. I developed multiple conceptual designs for the acoustic data collection system. These designs explored different uses of the sensor (i.e. passive or active) and how to accomplish each of these.

I also, along with my team, wrote the design document. I was responsible for the introduction, the use-case requirements, and the acoustic data collection/processing sections of the architecture, design trade studies, and system implementation.

Next Steps:

  • Adithi will give me data from the ducts to analyze and test my processing pipeline on as well as the ML model on
  • I will modify the processing accordingly, including changing or adding new features

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

Team Status Report for 2/21

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?

The most significant risk to us right now is the sensor performance and compatibility, especially with our group thinking about acoustic emission and if the sensor will be able to clearly detect corrosion and cracks in our HVAC duct. Right now, we have figured out a solution using literature review and frequency analysis done by Rayann. Adithi has been able to pair our new, affordable, lower frequency sensor with a compatible amplifier that will be suitable before integration. Right now, our mitigation plan is that if the performance is still inadequate, we will use the microphone to collect audio data, adjust the signal processing pipeline, and perhaps expand our feature set.

Another risk we have is that we are unclear about the difference in acoustic separation between cracks and corrosion in our metallic HVAC ducts. We are a little worried about model accuracy and what that means. So, to mitigate this risk, we will make sure that we create our defects using the ASTM international standards, as researched by Mahati, so we can get our testing and data collection as accurate as possible. 

Lastly, some of the risks right now are with delay in hardware parts and integration challenges. We have written the code for motor control as well as the solenoid tapper, effectively writing code for our MCU as well as the NVIDIA Jetson Orin Nano. We will know next week how much of a risk this is once we integrate our software code with our hardware. 

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?

The biggest change we have made to the project is that we shifted our scope to metallic HVAC ducts only, and got rid of collecting data on fiberglass and generalizing our model to different materials. This was necessary and suggested by our professor so that we can keep our project feasible. This change gives us more time and flexibility to integrate hardware and software together. More than we initially planned. Another change we made is that we changed our AE sensor selection. We have found a compatible and affordable lower-frequency piezoelectric sensor and preamplifier. These changes do not influence our design heavily, rather how we are approaching our project.

Provide an updated schedule if changes have occurred.

Our schedule remains almost the same except for the fact that building our HVAC system has been moved up to the following next 2 weeks, again. This will be done instead of what we had initially planned to do, which was writing the software. Since the code was written this week, our priority next week is to combine everything so our robot chassis moves and the solenoid tapper taps the wall of the ducts. This will be a hectic 2 weeks managing hardware and software as well as building our HVAC testing and audio collection system but if we do this, testing and demo set up will be a lot easier. We have to build our system now since we will be collecting our own data rather than using a provided dataset from a research paper. This is similar to the schedule that we had given last week due to delays in purchasing and arrival of materials, although since we developed the software this week, our schedule just shifted a little bit rather than us being behind schedule. 

 

Adithi’s Status Report for 2/21

Accomplishments

This week, our team started by finalizing our design implementation following feedback we received from the design presentation. Our professor once again advised that we do not try to generalize our model and just focus on metallic ducts since we are collecting our own data. This makes our job easier since we won’t need to collect as much data. After the presentation, Rayann and I also realized that our current AE sensor that we chose was for cleaning. Luckily, we didn’t place the order for this sensor yet as we were unsure. Upon further research, Rayann found out a way to make lower frequency AE piezoelectric sensors work with our final product. In turn, upon doing some research I was able to find a preamplifier that meets the piezoelectric parts that we found. Now, all parts have been requested and purchased and we found the robot chassis and HVAC ducts will arrive early next week. After the design presentation, I reevaluated our power battery choices and our 12V rechargeable battery source should be sufficient and I am confident in our design now.

Other than finalizing the parts, I was able to find online documentation on putting the robot together so I will be ready to do that. I also started our team github repo and put the initial code for controlling our robot’s motors. I wrote the code for the Jetson Nano Orin as well as our Teensy MCU that will do most of the control for the motor and the MOSFET and Solenoid Driver. Nothing has been tested yet as our parts have not arrived but when our parts arrive, we will be ready to test the code to get the robot and solenoid tapper working. 

Resource Link for Robot Chassis: https://www.dfrobot.com/product-1860.html?srsltid=AfmBOornjmDRtYwUMkuKqLNi2cdcR3aubl-bh9vYVKoqg8luHyFGaepQ

Schedule

I am on schedule now and currently on track. Although our parts have not arrived yet, I have compensated by writing the initial code and am confident going into next week to test out our design. I ran into a small problem acquiring the HVAC from my Civil Engineering friend as I didn’t accurately provide her with the specifications of what we needed so that is a little delayed. As a team we are still a little behind but I will be working over Spring break to make up for this.  

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 also help in manually creating defects in our HVAC test system since we will have that and will begin collecting audio data with our mic as well as the sensors to get a good grasp of what data we are working with. 

Mahati’s Status Report for 2/21

This week’s progress: 

  1. Testing Methodology for Causing Damage to the HVAC 

I focused on designing a structured methodology for inducing artificial defects in HVAC duct samples in a way that is both experimentally controlled and grounded in industry practice. Rather than introducing arbitrary damage, I reviewed corrosion testing standards (particularly ASTM International guidelines such as ASTM G85 Annex A4) to understand how accelerated degradation is typically evaluated in heat exchangers and ferrous systems. Based on this research, I suggested a two-track approach targeting both chemical and mechanical degradation. For the corrosion component, I designed an accelerated protocol that begins with sanding down the galvanized surface to simulate coating failure followed by an acidified salt spray (5% NaCl and 1% acetic acid) and wet-dry hygroscopic cycling to concentrate ions and promote pitting within a compressed timeframe. This allows us to generate measurable oxidation effects without waiting for long-term natural corrosion.

In parallel, I also worked on figuring out a defect simulation strategy to intentionally alter the duct’s structural stiffness and resonant behavior for classifier training. I chose to introduce longitudinal slots (0.5–5 mm) and partial-depth notches at 25–50% wall thickness to essentially simulate cracking and wall thinning. The goal in structuring the defects this way is to ensure that the resulting acoustic signatures are systematic and scalable. 

  1. Setting Up the Preliminary Model

To prepare for working with our custom HVAC acoustic dataset, I began by exploring a publicly available dataset to build familiarity with audio signal processing and support vector machine (SVM) classification before our experimental data is collected. I selected the Electrical Tactile Dataset because it contains high-frequency sensor recordings with labeled signal patterns, making it a good analog for the kind of time-series data we expect to extract from duct vibration/acoustic sensors. I trained an initial SVM classifier to distinguish between texture categories. This preliminary model was useful in two ways: it gave me hands-on experience working with audio-based features and SVMs and it provided a baseline pretrained model that I can refine once our own HVAC dataset becomes available. Establishing this baseline early allows us to validate our feature extraction and classification pipeline, which will reduce integration time and uncertainty during the more complex stages of our HVAC testing.

Electrical Tactile Dataset (Piezoelectric and Accelerometer) for textures: https://figshare.com/articles/dataset/Electrical_Tactile_Dataset_Piezoelectric_and_Accelerometer_for_textures/28033589 

 

My work for the week can be found here: 

https://docs.google.com/document/d/1NJO_i_av8JNN0vTtEvd5TdrTgKmLdeheiv4WQtrmINs/edit?usp=sharing 

 

Things to do for next week:

We will be getting most of our materials next week so I think I’ll work on collecting data and getting the hardware and embedded systems control logic setup with Adithi. So the tasks will be as follows:

  • Receive and inventory all incoming materials needed for the experimental setup.
  • Begin collecting initial acoustic and vibration data from the hardware system.
  • Set up and integrate sensors with the data acquisition hardware.
  • Collaborate with Aditi to develop and test the embedded systems control logic for synchronized and reliable data capture.

Rayann’s Status Report for 2/21

This week, we put together our design presentation which was given by Mahati on Monday. I completed the use-case requirements, data processing pipeline, testing and verification, and schedule slides and assisted with the design requirements and risk mitigation slides. We had a successful presentation and the only commentary we received from our supervising professor was that we should only focus on steel ductwork and not include the fiberglass ductboard because we have plenty of other components to focus on for our MVP.

I also read more academic articles to figure out what type of AE sensor we should purchase and made notes on their operating frequency and amplified frequency. I have found an AE sensor and Adithi has put in the purchase order. I have also looked more into the feature processing, including which features to extract from the raw audio and how to do this. In past weeks, we thought we would focus on corrosion and leaks, but we have since shifted towards corrosion and cracks. Therefore, I have found a couple features that would be best in indicating cracks. I have completed a table of these features and methods to extract them. I must make sure that the features I have chosen are significant enough for the model to accurately classify the defects from healthy ducts and tell corrosion and cracks apart from each other. My current research indicates that sharp changes in any of the features indicate a crack while more slow changes indicate corrosion.

I have begun coding the acoustic signal processing pipeline in Matlab, using built-in functions for FFT, mean, standard deviation, and other common algorithms. This pipeline is a rough draft and is subject to change in the future after I have collected acoustic emission data.

 

Next Steps: 

I have to begin the process of creating corrosion and cracks on the HVAC duct provided by the trade school. I must also inspect this duct for previous degradation. Simultaneously, I will begin the signal processing pipeline. Hopefully, by the end of the week, the duct will be prepped and I can begin collecting data to test the pipeline.

My work for this week can be found here: Progress for 2/21

Team Status Report for 2/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?

This week, we learnt from the Professor that it would be better if we create our own dataset. In this way, our robot would perfectly interact with our physical system and we wouldn’t have to worry about fitting our physical system to that which was experimented on in the studies that produced the existing datasets we found. This was the biggest change in direction for us. While we were optimistic about being able to acquire HVAC ducts from trade school, we realized that this would take a while. One of our risks will be getting a good test system set up in order to collect our audio data. Some of the current risks we face are getting metal ducts for us to run our testing on and creating damage on the ducts that are akin to damages you would see in real life. To mitigate this, Adithi has contacted a civil engineering friend with access to metal ducts as prices online are too expensive and above our budget. We have also found various papers with set methods on how to create standard defects.

Another risk we face at the moment is making sure our Jetson Nano has enough power from our battery. To mitigate this risk as of now, we have made sure to include a DC converter which can get up to 19V to power our Jetson.

Lastly, none of us are very familiar with testing procedures and to mitigate this being a problem later on in our project, we plan to read papers on testing and ask for professor guidance to mitigate this risk.

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?

After researching and finding different solutions, we have settled on using a Behringer UM2 USB Audio interface which can act as the USB audio interface for capturing contact sensor signals. We found that this works with Jetson’s USB to capture analog vibration signals. We also settled on using a basic piezo element diaphragm which will serve as a piezo sensor detecting the taps against the HVAC duct. This change comes with the fact that AE sensors are expensive and out of our budget. Upon further research we have found that using the two components mentioned earlier will give us good data and results, while letting us stay under our $600 budget.

We have also decided we need to build our own dataset, as recommended by our professor so we will now have to process and document our data to create our own library. This will come with the challenge of creating defects in our HVAC and collecting and documenting the data for this.

Provide an updated schedule if changes have occurred.

Our schedule remains almost the same except for the fact that building our HVAC system has been moved up to the following next 2 weeks. This will be done in conjunction with what we had originally planned to do for the week. It will be a hectic 2 weeks managing hardware and software as well as building our HVAC testing and audio collection system but if we do this, testing and demo set up will be a lot easier. We have to build our system now since we will be collecting our own data rather than using a provided dataset from a research paper.

Mahati’s Status Report for 2/14

Accomplishments 

This week, our team pivoted from sourcing decommissioned HVAC duct sections from local institutions (including Carnegie Mellon University, University of Pittsburgh, Trade Institute of Pittsburgh, and Rosedale Technical College) to independently acquiring and modifying HVAC units for controlled corrosion testing. After receiving initial positive responses from facility managers and administrators, we determined that building and corroding our own duct infrastructure would give us greater experimental control and enable systematic data collection. This shift allows us to simulate realistic degradation patterns while ensuring reproducibility for robotic inspection validation.

In parallel, I conducted a deep literature review on acoustic based leak and corrosion detection systems to inform our sensing and modeling strategy. I analyzed a recent CNN based leak detection study that used adapted ResNet18, VGG16, and AlexNet architectures trained on spectrogram representations of leak audio. The paper introduced a dual dataset “acoustic mixup” approach to synthetically combine clean lab leak sounds with industrial background noise, along with targeted frequency windowing (11–20 kHz) to suppress irrelevant noise. Results demonstrated over 95% accuracy on vent leaks and strong performance on tube leaks, significantly outperforming shallow CNN baselines, highlighting the importance of network depth for extracting subtle acoustic features in noisy environments.

I also examined a corrosion severity classification framework using Acoustic Emission signals, which applied Wavelet Packet Transform and Fast Fourier Transform feature extraction followed by a Linear Support Vector Classifier. The model achieved 99% accuracy in classifying corrosion severity stages, outperforming multiple classical ML baselines. Key insights for our project include the effectiveness of multiresolution time frequency decomposition, statistical feature engineering (RMS, kurtosis, mean frequency), and the feasibility of real time, non destructive structural health monitoring. These findings are directly shaping our experimental design and model selection as we integrate acoustic sensing into our robotic HVAC inspection system.

Progress Report: 

https://docs.google.com/document/d/15zzXubsDVOVUDyqlZ87QFHDfqAO0mv9-JDg05TYcSkg/edit?usp=sharing 

Schedule

I am currently on schedule, based on this week’s literature review, I now have a structured understanding of potential model architectures. I will continue reviewing related work to evaluate alternative modeling strategies and signal-processing pipelines so that, once we generate our own training dataset, we can make better informed decisions about architecture selection, feature extraction methods, and evaluation metrics. 

In the coming week, I plan to focus on our experimental methodology for inducing controlled corrosion in HVAC duct sections and establishing a structured data collection process. This includes defining corrosion stages, selecting sensing modalities, and outlining repeatable testing protocols. In parallel, I will assist Adithi with robot setup and the hardware–software integration pipeline to ensure that our sensing, data acquisition, and robotic inspection systems operate cohesively.

Adithi’s Status Report for 2/14

Accomplishments

This week, our group had multiple discussions surrounding our implementation plans. From hardware architecture, power requirements, and design requirements, to what our testing should look like. This week, I was primarily responsible for hardware design and focusing on how our Jetson and IMU would work together with the sensors and robot chassis to make sure our project hit the overall MVP goals we set for ourselves. Working with Rayann, I discussed how the hardware would interact with the ML component of our project as well as how our audio would be collected.

At the start of the week, we were under the impression that we could use an AE sensor which would collect the sound made from our solenoid tapping against the walls of our HVAC duct. As a result, I was tasked with finding a way to approach our acoustic signal capture within the walls of an HVAC duct that we can then use for our audio processing. After researching and finding different solutions, I have settled on using a Behringer UM2 USB Audio interface which can act as the USB audio interface for capturing contact sensor signals. I found that this works with Jetson’s USB to capture analog vibration signals. I also settled on using a basic piezo element diaphragm which will serve as a piezo sensor detecting the taps against the HVAC duct. 

This week, I focused mainly on iterating and finalizing hardware systems architecture plans so that our team has a solid understanding of how all of our components will work together. I also have purchased the parts for our team and we expect to receive them next week. I also worked with Mahati and Rayann to finalize testing plans. I also found a civil engineering classmate who is willing to donate some HVAC ducts she got from her internship.

Schedule

I am on schedule now and currently on track. As a team, the goal was to finalize the parts list and research the different components. I also finished my research on power distribution to the Jetson nano as well as the rest of our system. The one thing I hoped to achieve but didn’t get round to was putting together the solenoid tapping mechanism but since we changed our approach, I plan to try and get it done next week when parts start arriving.

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. If parts do not arrive, it is not a big problem as I will be working closely with Mahati on our software development and putting together our HVAC testing system to collect initial audio data.

Rayann’s Status Report for 2/14

At the beginning of this week, I read through all of the academic papers and datasets that Adithi found last week. I found these papers to have useful information regarding data collection and processing. For instance, I found that all these papers used acoustic emission (AE) sensors for structural health monitoring (SHM). AE sensors are specialized, high-frequency piezoelectric devices that detect transient stress waves (ultrasonic energy) in materials caused by structural, mechanical, or manufacturing defects. They provide real-time monitoring to identify leaks, cracks, and friction. I began looking into how AE sensors work and finding one within our budget constraints for purchase. I also continued my search for an existing dataset. My minimum requirement for a dataset was that it must include acoustic data labeled with the defects we are focusing on (corrosion and air leaks) from the duct material we are focusing on (sheet metal and fiberglass duct board). I was able to find two datasets that directly used AE sensors to collect acoustic data of corrosion and air leaks on galvanized steel. 

However, when I presented my findings to our supervising professor on Wednesday, he said we should create our own dataset. In this way, our robot would perfectly interact with our physical system and we wouldn’t have to worry about fitting our physical system to that which was experimented on in the studies that produced the existing datasets we found. I shared our professor’s opinion with the rest of my group, who were unable to attend the meeting. Together, we have decided to focus all our energy on purchasing the robotic base and AE sensor as well as the HVAC duct system. I found an AE sensor that fits our frequency needs and I found an HVAC duct that fits our measurement requirements. We have put in the purchase orders for these.

This week, I also looked into acoustic features we can pull from the acoustic data to make meaningful conclusions about structural defects. I found a bias shift method and a denoising process specific to AE sensor data. I also discussed with my team that our visual odometry system may not be required, since we are able to calculate the distance our robot has travelled relative to its starting position based on its speed and the amount of time it moves. The visual odometry system would add unnecessary complications. My teammates agreed with me, so this system is not included in the design anymore. However, we still require a camera to allow the remote-control user to see where the robot is and whether the robot needs to turn. I also started creating the design presentation that we must deliver next week.

 

Next Week Goals:

  • In the coming week, our purchases will come in and we can begin construction of our robot and HVAC duct system. 
  • Then, we can begin the process of data collection. 
  • Simultaneously, I can continue looking into data processing techniques. 
  • We must also have our design presentation ready for Monday. 

 

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

 

Team Status Report for 2/7

Work Completed This Week As a Team:

  • Contacted local trade schools regarding access to used or damaged HVAC ducts (no response yet)
  • Researched robot simulators for early testing before physical hardware integration
  • Contacted HVAC technicians about sourcing scrap duct materials
  • Researched purchasing options for sheet metal ducts and fiberglass ductboard and documented sizes/prices
  • Reviewed research papers to identify acoustic features used for corrosion and leak detection
  • Researched publicly available ML datasets for acoustic-based defect classification
  • Reviewed guided-wave and structural health monitoring literature to understand how tap-induced vibrations propagate through ducts
  • Investigated NVIDIA Jetson Orin Nano as an onboard compute option for real-time inference
  • Explored multiple mechanical tapping mechanisms for generating consistent acoustic excitation

Summary

This week our team prepared for the project proposal presentation. We finetuned our use case requirements, settling on a couple large goals: defect detection using acoustic data, localization using image data, and a generalization to different materials. After Rayann presented the proposal on Wednesday, the team focused on our supervising professor’s largest questions: where will the HVAC duct system that we plan to test the robot on come from and where will the data to train the ML model come from. Adithi and Rayann called HVAC technicians inquiring about where damaged HVAC ducts go. These technicians were unresponsive so as a precautionary measure, Rayann looked into buying affordable sheet metal HVAC ducts and fiberglass ductboards on Amazon. She saved the links and documented their sizes and prices and shared them with the rest of the team. In the next week, our team will continue to search for old HVAC duct systems. Our new direction is to call trade schools.

Mahati has already begun by contacting the Pittsburgh Trade School. Rayann also looked into different acoustic features that are used to detect corrosion and air leaks in research papers. She was able to get a comprehensive list of features we can extract from acoustic signatures. Adithi looked into finding a dataset to train the ML model with. She has found a large amount that Rayann will have to search through and find one that matches the minimum requirements: a dataset that includes acoustic data labeled with the defects we are focusing on (corrosion and air leaks) from the duct material we are focusing on (sheet metal and fiberglass ductboard). Rayann worries that if we are not able to find a dataset that fits these requirements, we will have to collect the data ourselves.

For now, Rayann is working on choosing a dataset or concluding that none will fit. No changes have been finalized to our design as of now. If there must be a change regarding where we obtain the dataset, this decision will be made by next week. This would affect our entire schedule, moving building the robot and duct system to the front and training the ML model farther to the back as we would need time to collect data.

Meanwhile, Adithi is working on the hardware design. Specifically, Adithi has already gone through the process of requesting the robotic base from the ECE department and ordering the sensors that will be mounted on the robot. Mahati has been looking into finding a simulator that we can use for testing the robot before we get to the physical phase of testing. She has found a couple of online simulators and shared with the rest of the team. In terms of our current schedule, we have taken care of most of the parts that need purchasing or requesting. However, due to the delays with finding HVAC ducts, we are slightly behind schedule. Although, as a team, we agree to do the research into finding and ordering HVAC ducts along with our tasks for next week.

  •  Risks and Contingency Plans
  • We have found that running our ML model in real time on our Jetson might need setup and debugging time which we have not accounted for. We need to make sure we have a Jetson and a contingency onboard computing option so that we can pivot and need to account for this in our schedule.
  • We also found that there may be limited HVAC duct materials available to us but we have started to overcome this by calling suppliers and checking within CMU so that we can correctly get our own data as well as test our final product. We have looked through cheap options and have talked extensively on how testing will work.
  • We also started the week thinking we may not have enough available public datasets but have since then made sure to review multiple datasets across different HVAC materials and are learning more about guided waves through academic and industrial literature available to us. The worst case is we can collect our own data once the tapping and sensing system is operational. Since this is one of our contingency plans, we will have to build our tapping mechanism quickly.

Design Changes

We do not have any major architectural changes as of yet however the first part of next week will be spent finalizing and finetuning decisions so this may change. We are however considering simplifying our hardware by using a single onboard compute (SBC) rather than multiple controllers. We will check in with our TA and professor about this change as well.

Schedule Update

We are slightly behind schedule as we spent a lot of time thinking about testing, material supplies, datasets, and literature. However, we have completed purchasing and technical planning and plan to catch up on our schedule by Wednesday this following week.

Next week, we aim to finalize hardware architecture, secure HVAC duct materials, begin prototyping the tapping system, and set up the software environment.