Rayann’s Status Report for 3/21

I discussed the ethics and risks of our project with my group this week. I also attended the ethics lecture and discussed the ethics and risks of other projects in the class. We investigated the risk of using ultrasonic sensors and found that if the transmitter is driven with a high enough frequency, people in the area could suffer from dizziness and nausea. The risk threshold is 20 kHz. If we drive the transmitter with low-level voltage, the frequency range for the ultrasonic waves emitted should never exceed 1 kHz.

I characterized the ultrasonic sensor by trying different inputs to the transmitter and observing how the receiver responded, going through the process step by step for each variation. I started the collection of acoustic data using the ultrasonic sensor on healthy ductwork. We have not received our ADC yet, so I only attempted to characterize the use of our sensor on our specific duct material. Basically, I drove the transmitter and collected the output voltage range from the receiver using a voltmeter. This is not a fully detailed waveform that I can input into the processing code I have. I used one piece of duct (out of the 25 we collected) and took in total six measurements every 5 cm (the duct is about 15 cm long). I drove the transmitter with 3V, 5V, and 9V. The voltage limit for testing was 9 volts, which is the same limit provided by our current hardware design. I took two measurements for each input voltage because this seemed enough; after two, the voltage values became very repetitive without much variation. The data collection is documented in the file linked below. 

The transmitter is hooked up to the battery and the receiver is positioned next to it to collect the echo of the signal. The prongs for the sensors seem slightly too long for this breadboard so the signal is unstable. For a proper, reliable connection, I may have to redesign this system. An image of the current setup is in the file linked below.

I also used an AD3 explorer to look at the waveform captured by the ultrasonic sensor. From using this software, I was able to obtain preliminary values such as frequency and peak-to-peak voltage. An example of the image is in the file linked below.

This is my work for this week: https://docs.google.com/spreadsheets/d/17F5QZGwymYqmGGup4V3u2_v8MdibjNQDQthjUrzVp3I/edit?gid=0#gid=0

Mahati’s Status Report for 3/14

This week’s progress:
This week, I focused on understanding the physical assembly of the HVAC duct structures that we will be using for data collection. We received several square metal duct pieces from the FMS shop, but when we attempted to cut and assemble them, it turned out to be more complicated than expected. The ducts are held together using riveted sheet metal joints, and it was initially unclear whether we should remove the rivets, re-rivet the pieces ourselves, or modify them in another way. We tried to cut a part off of the HVAC ducts; however, just the process of getting the HVAC duct cut took 1 hour, and we have 20 more to go, and that’s not including putting the ducts back together. 

To address this, I spent some time researching how HVAC sheet metal ducts are typically assembled and how we might work with the pieces we currently have. In parallel, Professor Ed from FMS shared the contact information for fixit@andrew.cmu.edu, which handles fabrication and facilities requests. I reached out to them to see whether it would be possible to obtain additional duct sections that are already pre-connected or easier to work with for testing, and I am currently waiting for a response. If we can obtain pre-assembled ducts, it would significantly simplify the experimental setup and allow us to focus more on data collection rather than mechanical assembly.

In addition to the mechanical work, I began drafting the preliminary code for controlling the solenoid tapper that will be used to excite the ducts during testing. The solenoid will act as a consistent impact mechanism so that we can generate repeatable acoustic and vibration signals from the duct surface. While working on this, I also reviewed and worked to understand Aditi’s motor control code so that we can eventually integrate the actuation components with the rest of the robot’s system.

Finally, I spent time in the lab working with Aditi and Rayann to assemble most of the robot platform. We were able to get the majority of the structural components in place and ensure that the main hardware elements fit together properly.

My weekly progress (research for HVAC duct methods and code): https://docs.google.com/document/d/16fPUd4hhc9Xqjzm7Y71jKUkrX2CyWH6wOT2W3ph-IuI/edit?usp=sharing 

Things to do for next week:
Next week, the focus will be on moving from assembly and planning into more integrated system testing and data preparation.

One of the main goals will be to create a structured training and data-collection plan for the remainder of the project timeline. This will outline how many recordings we want to collect per duct condition, how the data will be labeled, and how we will structure the dataset so that it can be used effectively for model training.

In parallel, I will work on getting the robot fully operational. This includes integrating the motor control code, the solenoid tapping mechanism, and all of the sensors so that they can operate together within a single system. The goal is to reach a point where the robot can move along the duct, trigger the solenoid tapper, and collect synchronized sensor data automatically.

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.

 

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.