Posted on

Rayann’s Status Report for 4/25

I have been collecting more training data on the robot to add to the handheld training data in an attempt to increase the accuracy of the SVM model. I also had to replace the ultrasonic sensors on board the robot because they were no longer working. These sensors are very responsive to changes in surface and distance, so when they were no longer responding, I knew I had to change the sensors. I also collected some raw voltage data on my computer from the set-up on the robot, meaning that I connected to the Teensy MCU, so that I could monitor the voltage and see if there may be other features we could potentially process the data into that would increase the accuracy of the SVM model. I will continue collecting data with the robot and running the tests described below.

To validate the SVM model, we first train the model on the processed data we have collected. Then, we input new, unseen processed data into the SVM and validate its classification. I repeat this last step ten times so I can form an understanding about the reproducibility of the results. From this test, we have decided to increase the amount of training data and are looking into including more features. Occasionally, based on the data taken from the sensors, we replace them. When we first started collecting data with the robot, we realized we had to increase the sampling rate because it was too low to collect the full waveform.

 

My work for this week can be found here: https://docs.google.com/spreadsheets/d/1n9EZVZOw4e8DMoP9_O2lPJV9oe4U9V2cjh6RSExgdro/edit?gid=0#gid=0

 

Posted on

Rayann’s Status Report for 4/18

This week, I collected more training data from corroded samples. We now have 100+ samples of healthy and corroded samples combined. I also did an analysis of the data we collected and chose a couple new features to include in the processing. These features work together to showcase the differences between the healthy and corroded data. The graphs I created to analyze these features are available in the team Github. Nobody should stare at these graphs for too long because they are too confusing. I simply used these graphs, as well as other graphs of other features from the data I collected, to choose which features were the most different between the defect data and the non-defect data. They are histograms of the feature values from each data input (red is for defect data and blue is for non defect). The feature graphs that had the least overlap between red and blue bars were chosen to be included in the processing pipeline. I wrote a new Python file for extracting these features. This file named extract_features can be found in the team GitHub. Then, I trained an SVM using the data I collected and processed into these features. The file for training this SVM as well as the trained SVM file we downloaded onto the Jetson are in the team Github linked below. The SVM achieves .94 accuracy. Mahati and I worked on debugging the data collection on the robot. The sampling rate was too low, so we increased it. Then, we tested how the data collection system and the SVM classification model works on the robot.

Throughout the design, implementation, and debugging of this project, I developed both technical and communication skills by learning how to select and integrate components based on specific application requirements. For example, I learned how to choose appropriate ultrasonic sensors by considering use-case constraints, such as detecting the acoustic signature of galvanized steel. To support these decisions, I reviewed research papers and analyzed the reasoning behind prior designs, which helped me establish a more structured approach to my own design choices.

In addition to component selection, I had to learn how to effectively use these sensors and integrate them with other system elements. I relied on a variety of informal learning strategies, including watching instructional videos and reading technical documentation and articles from sources such as MATLAB and Adafruit. These resources allowed me to quickly gain practical knowledge and troubleshoot implementation challenges.

Beyond technical skills, I also worked on improving my ability to communicate complex concepts to individuals with much less technical experience. I incorporated feedback from our advising professor to refine how I present and explain my work, which has helped me become more effective in conveying technical ideas clearly and concisely.

My work for this week can be found here: https://github.com/aphadke234/ece_capstone_C7/blob/master/extract_features.py

 

Posted on

Team Status Report for 4/4

This week, our team focused on preparing our project for the interim demo. Adithi and Mahati worked together to debug code for the motors to make the robot chassis move forward, backward, and turn (both right and left). Adithi worked on the code to drive the LiDAR camera in such a way so that it can detect whether or not the robot is in the duct and the physical integration between the camera and the robot chassis. Adithi has also started building our final demo HVAC duct to show our project on. Mahati worked on rebooting the Jetson and integrating all the systems including the acoustic data collection system, LiDAR, motors, and ML model with the Jetson. Mahati physically integrated the ultrasonic sensors with the ADC and Teensy MCU on the robot chassis. Rayann collected healthy duct and corroded material data using the data collection circuit. She plans to collect more samples. She also debugged the MATLAB processing code to take in the data she collected, and processed this data so it is ready to be used to train the SVM. She also wrote another processing pipeline in MATLAB specifically meant to be downloaded onto the Jetson and take data from the Teensy MCU, process the data, and hand it over to the SVM. She is currently debugging this code.

 

We are currently on schedule, with a few things to accomplish in the coming weeks. We will finish collecting data, debug our on board processing pipeline, and train the ML model. We will finish building our demo structural HVAC duct so that we can have a good presentation to show viewers what our project is. We also want to make sure the robot does not have to be connected to a charger by the NVidia and that we can have our LiPo battery pack on the Jetson. We will also begin working on the final presentation, final report, and demo poster.

 

A potential risk is the ML model not being able to reliably classify defects vs healthy ducts. This is quantified using false/true positives and negatives. In this case, we plan to either change hyperparameters or change the processing pipeline after analyzing the data (adding/removing features).

 

All of our code can be found in the github: https://github.com/aphadke234/ece_capstone_C7

Posted on

Rayann’s Status Report for 4/4

This week, I prepared for the interim demo. I continued collecting data using the hand-held data collection circuit connecting a pair of ultrasonic transmitter and receiver with an ADC and Arduino Nano. I collected more healthy duct data and started collecting corroded material data. The raw data is in the Training Data file linked below. Then, I debugged the MATLAB processing pipeline to handle the data collected and processed the data as training data for the SVM. The processed data is in the GitHub linked below. Then, I wrote another MATLAB processing function specifically meant to be downloaded onto the Jetson to collect data from the teensy MCU and input the processed data into the SVM. I am still in the process of debugging this code. Currently, the SVM is only trained on very few data samples. All of my code is also in the GitHub linked below.

 

I am on schedule, and the next step is to finish integrating the signal processing pipeline and trained model with the Jetson on the robot. Next steps include continuing to debug the on-board processing pipeline and training the SVM, as well as changing hyperparameters. I would also like to take another look at the features I decided to process the data into and verify that the processing is accurate.

 

My work for this week can be found here:

https://docs.google.com/spreadsheets/d/1n9EZVZOw4e8DMoP9_O2lPJV9oe4U9V2cjh6RSExgdro/edit?usp=drivesdk

 

https://github.com/aphadke234/ece_capstone_C7

 

Posted on

Rayann’s Status Report for 3/28

This week, I worked on collecting acoustic data for training the ML model. I worked on a handheld circuit for collecting data without the need for the robot. I first attempted working on integrating an ADS1220 and an Arduino Nano to collect the voltage from the ultrasonic sensor. I attempted debugging this circuit and Arduino code for 3 days, but the DRDY pin was always stuck at 0. I think the library I was using, Protocentral_ADS1220, might not have been sufficient for the purposes I needed. The ADS1220 was required for the robot’s data collection system anyways, so I pivoted to integrating an ADS1256 and an Arduino Nano to collect the voltage from the ultrasonic sensor. I was successful at this endeavor, and began collecting data to push through the MATLAB processing pipeline so I can train the model on the data. The data seems to be in the correct voltage range (100 mV to -100 mV) and frequency range (100 to 50 Hz) as it matches the waveform I acquired last week when I was characterizing the sensor in the duct environment. Pictures of both circuits, the ADS1220 and ADS1256 integrations with the Arduino Nano, are included in the data collection file linked below and all Arduino code was pushed into the GitHub repository linked below.

My work for this week can be found at these links:

Code: https://github.com/aphadke234/ece_capstone_C7

Data Collection: https://docs.google.com/spreadsheets/d/1n9EZVZOw4e8DMoP9_O2lPJV9oe4U9V2cjh6RSExgdro/edit?gid=0#gid=0

Posted on

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

Posted on

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.

Posted on

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

Posted on

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

Posted on

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