Posted on

Mahati’s Status Report for 3/28

This week’s progress:

  1. Hardware Setup and Embedded System Integration

This week I focused on setting up and integrating key hardware and embedded system components required for our pipeline, working closely with Adithi. We successfully set up and flashed the Jetson Orin Nano, which serves as the main compute unit for running higher-level control and machine learning tasks.

We then connected the motor driver to the motors and the Teensy microcontroller and established communication between the Teensy MCU and the Jetson, ensuring that control signals can be transmitted reliably between the embedded controller and the main system. We also connected the piezo sensor to the Teensy MCU and verified its connection to the Jetson, which is important for enabling the HVAC inspection.

In addition, we integrated the LiDAR and IMU devices into the system and worked on configuring them for use. I also figured out how to SSH into the Jetson, which will make development and debugging easier especially for our interim demo. Finally, we implemented code on the Jetson to respond to signals from the Teensy MCU and execute control logic, enabling coordinated behavior between sensing and actuation components.

Things to do for next week:

Next week is our interim demo, so the focus will be to prepare for that. The main tasks include:

  • Collect more training data
  • Improve the machine learning model using the newly collected data
  • Continue testing the system to ensure stable communication between all components

Since the ADC arrived late, we were not able to collect enough data earlier, so a key priority will be improving the machine learning model using additional data collected this week.

My work can be found here: https://github.com/aphadke234/ece_capstone_C7

Posted on

Adithi’s Status Report for 3/28

Accomplishments

This week, I worked very closely with Mahati in the week leading up to our interim demo. We accomplished a series of things.

With Mahati, I worked on fine tuning the motor control of the robot that was already in place and we soldered our final circuit onto a permaboard so that it could be elegantly presented. Currently, the motors move at the set speed according to the specification we set when we initially came up with our design. Then, we moved onto helping Rayann with collecting data from our tranceiver and receiver modules, running it through an ADC, then feeding in the values that were read into the ML model that was built by Rayann and Mahati. We can now run the ML model on our Jetson, and the Jetson controls the Teensy MCU. Mahati and I also worked on integrating the LiDAR with our robot.

On my own, I have also been building the HVAC duct with one 90 degree turn that will be used for our demo. I also took a look at our remaining schedule and how we plan to utilize the time we have before the end of the semester and before our final demo presentations.

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

Schedule

I am on schedule now and currently on track. The interim demo is this upcoming Monday and as a team, we achieved everything discussed with our Professor and our TA, except for the solenoid tapper, which we have set up but have not had success integrating in time for the interim demo. This will have to be looked at in the coming week, and be addressed immediately.

Next Week

Next week, I plan to prioritize making our robot movements smoother so they don’t damage the duct while moving through them. I also plan to integrate the solenoid driver so that Mahati and Rayann can focus on the ML model. I am still meeting with the HVAC trade school contact we made to figure out how to build the system for our final demo. I have also been going to junkyards with him and will continue to do so once a week until 2 weeks from now, at which point, I think we will have all the training samples we need for our project. I will also aid Mahati with the IMU integration next week.

Posted on

Team Status Report for 3/28

Overall Status Update

This week, overall, we have been working towards our interim demo. Since had our robot’s motors somewhat working and moving, we wanted to link the rest of our parts together. We finally started collecting data since our ADCs arrived, completed the initial training of our ML model, and we worked towards integrating the LiDAR with our robot. The goal we have set for ourselves by the interim demo is having a robot with a LiDAR feed that the user can view, a robot that can be controlled by the keyboard as we move towards making it autonomous, and a basic ML model that can identify cracks as they occur. After interim demo, we begin fine tuning and integrate the solenoid tapper to indicate where the crack or defect has occured in the HVAC duct, working towards a more robust and accurate ML model, and an autonomous robot. We want to also end with thorough testing, and throughout the entire process we will be collecting more data.

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?

We are worried about using LiDAR to enable our robot to move autonomously. Since this has been one of our pain points for the last 2 weeks, during the interim demo week we plan to work and read papers to familiarize ourselves with using LiDAR and enabling the robot to become autonomous.

Another thing that poses as a risk currently to our group is getting enough data to train our ML model. To mitigate this, we have found various surface panels with corrosions and cracks and will begin training on this while also finding other surfaces we can use for validation testing.

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?

No changes were made this week, we are proceeding with the design that was in place last week.

Provide an updated schedule if changes have occurred.

The overall schedule of the project remains mostly consistent as of now, however after the initial feedback after the interim demo this may change.

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

Adithi’s Status Report for 3/21

Accomplishments

This week, I set up the motor controller code to not only function, but move our robot forward controlled by a user input on the laptop. I began to integrate the code for moving our robot chassis left, right, forward, and backward, and have begun figuring out how to ensure our robot can make 90-degree turns.

I looked into remote controls for our robot and have purchased the part so that instead of the current model, where the user controls how the robot moves by pressing a keyboard button or a button on screen, they will be able to use a remote control with a joystick to control the robot instead.

Since the robot is moving, I began looking into writing the code for our LiDAR camera. After discussion with the team, we have decided that we will move forward with using the camera to enable our HVAC engineer to see as much of the duct that they can. Since we have scoped our project down to get rid of mappings, this is much easier.

Some of the videos aiding me this week were:
youtube.com/watch?v=gJPIJ3yxME0&t=79

Mahati has also been working on the solenoid tapper and I helped her a little bit in the development with the code for the tapper.

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. The interim demo deadline is in 2 weeks or so and I am feeling confident about having a robot that can move through a duct, and classify defects at some level. I am a little behind on building the HVAC duct for our demo however.

Next Week

Next week, I plan to prioritize integrating the machine learning model on our Jetson Orin Nano with the current motion robot controls. I will also finish integrating the LiDAR camera with our robot so the user can have real time visual feedback. I will finish building our duct system for the interim demo using 5 to 6 ducts, and then I will offer help to Mahati with the solenoid tapper as well as data collection from the duct.

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. 

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 below.

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

This is a picture of the testing set-up:

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.

Posted on

Team Status Report for 03/21

This week, our team focused on progressing several core hardware and embedded system components required for our experimental setup, including motor control, ultrasonic sensor testing, and preparation for the solenoid tapper system.

Aditi worked on developing the embedded motor control logic for the robot by implementing and testing the control signals used to drive the motors through the microcontroller and motor drivers. This work focused on ensuring that the motors respond consistently to control inputs and that the embedded code interfaces correctly with the hardware so the robot can operate reliably during experiments. At the same time, Rayann worked on characterizing the ultrasonic sensing system that will be used to collect acoustic data from HVAC duct samples. This involved testing how the ultrasonic transmitter and receiver respond to different input voltages. In addition, Mahati continued preparing the solenoid tapper control system, which will eventually generate consistent mechanical taps on the duct surface, by reviewing and iterating on preliminary control code so it will be ready for integration once the ADC and data acquisition pipeline are in place.

Overall, the team made progress toward getting the robot and sensing system ready for integration and future data collection. While we are slightly behind schedule due to the ADC not arriving on time, we feel confident that we can catch up once the remaining hardware is in place. Unfortunately without the ADC, we cannot fully record the sensor measurements for our algorithm.

Next week will be focused on completing hardware integration and beginning the process of collecting experimental data so that we can start testing our algorithm. Since we are approaching a two-week milestone, the primary goal will be ensuring that the robot and sensing pipeline are fully functional. One of the most important tasks will be beginning structured data collection from the duct samples. Once the ADC arrives and is integrated into the system, we will start recording acoustic signals that can be used as input for our algorithm. Having real testing data will allow us to evaluate our signal processing pipeline and begin running the classification algorithm on actual measurements rather than simulated or preliminary signals.

Another major priority will be getting the robot fully operational. This includes ensuring that the motors, sensors, and control systems all work together reliably. The team will focus on integrating the embedded motor control, sensor inputs, and solenoid tapper so that actuation and data acquisition can occur in a synchronized and repeatable way. Additional work will include receiving and inventorying the remaining hardware components, integrating the ADC with the sensing system, finalizing the solenoid tapper hardware integration, and verifying that the full pipeline operates correctly.

Potential issues/risks include further delays in ADC delivery or malfunction, synchronization issues between the motors, solenoid, and sensors, or unexpected behavior in the ultrasonic sensor readings on different duct materials. Despite these risks, we feel that our progress so far has been solid. We have made significant headway on motor control, sensor characterization, and solenoid preparation, and with the remaining hardware arriving soon, we expect to meet our two-week milestone and be prepared for the interim demo.

Posted on

Mahati’s Status Report for 3/21

This week’s progress:

  1. Developing the Control Code for the Solenoid Tapper
    This week, I worked on writing and testing the control code for the solenoid tapper that will be used to generate consistent mechanical taps during our experiments. The goal of this component is to produce repeatable impulses on the HVAC duct surface so that we can reliably capture acoustic and vibration responses from the system. I focused on implementing the basic control logic needed to trigger the solenoid and regulate the timing between taps. This would involve experimenting with different timing intervals and pulse durations to ensure that the solenoid actuates reliably and returns to its resting position between activations. I got the preliminary code started a few weeks back and have been iterating on that, so when we have the ADC, we will be able to properly capture the data needed with the solenoid tapper. 

My work for the week can be found here:
https://docs.google.com/document/d/1qRRPVxLNIO-z_C0ETqJalA6X_706GjrcQP8EjuErZ6U/edit?usp=sharing 

Things to do for next week:
Next week, most of the hardware materials for the experimental setup should arrive, which will allow us to begin assembling the system and collecting preliminary data. The main tasks for next week include:

  • Receive and inventory all incoming materials required for the experimental setup. We are specifically waiting for the ADC
  • Get the motors to work 
  • Finalize the solenoid tapper hardware integration with the rest of the system.
  • Begin collecting initial acoustic and vibration data from the duct samples.
  • Set up and test sensors with the data acquisition hardware to ensure signals are captured correctly.
  • Work with Adithi to integrate the solenoid control logic with the broader embedded system so that tapping and data collection can occur in a synchronized and repeatable manner.
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

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.