Posted on

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.

Posted on

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

Posted on

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.

Posted on

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.

 

Posted on

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. 

 

Posted on

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. 

Posted on

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.
Posted on

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.

Posted on

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.

Posted on

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.