Posted on

Team Weekly Update (4-26-2025)

A major issue has been with the IMU, which has been giving faulty results. This causes the linear actuator (LA) to rapidly adjust or over-adjust. Initially, we thought the errors were caused by vibrations. So we tested by tilting the robot forward and backward to see how the IMU responded. While this helped somewhat, there were occasional faulty data points when tilting. The IMU responded inconsistently, leading to unstable platform behavior. To address this, we have been testing the IMU in different scenarios and have added foam around it to reduce vibrations. Additionally, we moved the IMU to the center of the platform to get more stable readings and changed the start time of data collection to help with initialization issues. Another problem is that the wheels sometimes came off during testing. To solve this, we plan to superglue the wheels onto the axles.

Regarding design changes, so far we have made only small adjustments. The most notable changes are relocating the IMU to the center of the robot for better stability and deciding to use only one battery instead of two.

Because of some IMU challenges, we are slightly behind schedule on FPGA integration.

For unit testing, we first tested the IMU on flat surfaces and tilted the robot to verify that the data was recorded correctly. We also created a program that allowed us to input text commands to control PWM and direction, and verified the outputs using an oscilloscope.

For overall system testing, we drove the robot up a measured ramp. Then the imu’s data (angle, speed, etc) was recorded. A video was also taken. If we were testing with water, we used a water bottle to prevent spilling and watched the video to see if the water was over a certain threshold. We tested the robot both with and without water to study how the load affected performance. Through experimentation, we found that we could only fill the container to about 70% full without significant water spillage, unless we very carefully placed the robot so that the front wheels made contact with the ramp first. This minimized water sloshing at the start. Other testing discovered that our robot tended to curve to the left, which led us to realize that some of our wheels were not aligned properly. After repositioning and securing, the robot drove much straighter.

 

IMG 1: The New Robot Positioning

Below are several videos showing our testing process. Some early tests show issues like poor traction, unstable IMU readings that caused the LAs to “shake”, and minor bugs in the code.

Poor Traction: https://drive.google.com/file/d/1WCRZMwPiRRYIEO_k6S9NhSe–4uCuD7E/view?usp=drive_link

IMU: https://drive.google.com/file/d/1WiQ-6zIasJhYvzdJRrbxLwdb7-xIRUrI/view?usp=drive_link

Minor Bugs: 1 & 2

The results from our successful runs: Water & Without Water.

Posted on

Raymond’s Status Report 4/26/25

After getting the whole system together, this week, I have just been testing the robot together with Sara. We are testing out different control algorithms. Before, we were just running the robot up the ramp at a fixed speed while adjusting the platform. Now, we are also controlling the drive of the robot based on the velocity of the robot. This is to ensure that the robot does not change angles too quickly when moving up the ramp, so that the water does not spill. We have continued more tests with water, and we see that while the robot adjusts its angle, the water does not spill. However, when the robot first hits the ramp, it causes a large jolt that will cause the water to spill. Since our only sensor is an IMU, we are unable to detect when we are going to hit the ramp, so we know when to slow down. We tried a control system where we would move as slowly as possible, but still, when hitting the ramp, it would cause a spill. In order to fix this issue, we plan to set the robot either at the base of the ramp, so that it does not need to drive up, or we will drive for a fixed distance and then stop at the base of the ramp, before accelerating again to climb up. We also have an issue where the IMU readings will be severely off when adjusting on certain runs. But it is a consistent enough issue, where we have tried to debug the source of the problem. We thought that it might be due to some microvibrations from the linear actuator, so we designed another script to just run the linear actuators while reading from the IMU. We determined that this was not the source of the problem. When examining the IMU data, however, I noticed that there were some outliers in the data. My guess is that when we react to those outliers in our control system, it accentuates the problem. So the plan is to also set an upper bound range for our control loop to react to. This won’t be a problem because we have already stopped the wheels of the robot if the angle becomes too big. So the only time it would exceed the upper bound is if it is an IMU outlier.

We are still behind. We want to get the whole system working consistently with an Arduino before we try to move to an FPGA. This system works, but it is just not consistent enough. With the solutions to the problem already in mind, we should be able to make the system more consistent the next day, so that we can try to swap the Arduino out with the FPGA. If the FPGA does not work by Tuesday, I plan to swap back to the Arduino on Wednesday, so that we can show a consistent system on demo day. Then we will also show the work we accomplished with the FPGA, even if it is not completely integrated into our system. Those are also the deliverables we hope to accomplish, including the poster and the final report.

Posted on

Sara Weekly Post (4-26-2025)

This week, I presented our final presentation. I began working on the final poster and report. We focused heavily on testing our robot. I filmed the robot climbing up the ramp and tested it on the ground to see how our wheels were performing. I found that the wheels were uneven, causing the robot to drive in multiple directions. To fix this, I removed the wheels and meticulously repositioned them until they rolled straight. I also tried to glue the remaining wheels to prevent them from falling off during testing, however, I might try and use super glue instead of hot glue later.

For testing, we built a ramp, and every time the robot went up, I moved it back to its starting position. During some of the tests, I discovered we didn’t need to implement our system with two batteries.

This week, we are on schedule with our robot, and we continue to test it regularly. We also have spare parts ready in case anything breaks.

Next week, we will test the robot to get it into its best condition. We plan to finish all final class documentation (poster, video, and final report) and prepare for a great demonstration. I might also superglue the wheels to the axis to keep them straight.

Posted on

Raymond’s Status Report 4/19/25

This week, I’ve put the whole system together with the Arduino. On Sunday, I ran into some connectivity issues with the FPGA and the IMU, but had successfully gotten all the motors running simultaneously with the new logic level shifters. The connectivity issues with the IMU seemed to stem from unstable wire connections, as it would connect and run for a bit, but then lose the connection and not be able to communicate with the device. When running a program just to read from the IMU, it runs well. But when running a program to activate the linear actuators, while reading from the IMU; it loses connection.

After Sunday, we decided to get the whole system running with the Arduino. I created a few different programs just to test the functionality of the motors, all connected together. First, to test whether all of the motors ran, I ran a script where I could run the wheels forwards/backwards, and the linear actuators up/down. I ran into some issues with this because there were some issues with the motor drivers again. But after we diagnosed the issues and replaced some of the motor drivers, we went to drive the linear actuators based on the angle of the IMU. Then I created a short run that would stop after two seconds of the robot trying to climb up the ramp. The runs were not very good because the ramp had a large lip, and I needed to run the robot pretty quickly, so the linear actuators had trouble adjusting in time. As Sara was able to smooth out the lip, I was able to run a program that incremented the duty cycle of the motors until it could get over the lip. This ensured that the robot used a minimal speed to get over the ramp, so this gave the linear actuators the best chance to adjust in time.

https://drive.google.com/file/d/1VAoIBAHETLK4q6Kjd93y6QgunjlTJPVh/view?usp=drive_link

Our schedule is behind. We want to conduct some more testing on different angles and actually get some water in the cup so that we can know how much angle we can accomodate before spilling the water. If the professor feels that this progress is good enough, I also want to replace the Arduino with the FPGA. Once I am able to debug why the IMU and FPGA have connectivity issues for certain programs, it will be at similar progress as the Arduino.

The deliverables for the next week are to test on higher angles. I think it would be beneficial to slow the robot down more, after the first set of wheels get over the lip. Then once the back wheels struggle to get over the lip again, we would continue to increment the duty cycle. This would give the linear actuators the most time to adjust its angle. Also swapping from Arduino to FPGA would also be a deliverable for the next week. 

Questions for the week:

As you’ve designed, implemented and debugged your project, what new tools or new knowledge did you find it necessary to learn to be able to accomplish these tasks? What learning strategies did you use to acquire this new knowledge?

As I was learning how to use the FPGA for the project, I read a lot of different projects on Hackster for how to drive wheels with an FPGA. I also read a few different article on how to use SPI and I2C with the FPGA on Hackster. My learning stategies were just to read different ways to solve the problem so that I had a better understanding, so that I could apply the concepts to our own project. Working through the project, I also did some circuit debugging that I haven’t done since 18-100. I think it was beneficial to go through the steps to diagnose problems and isolate potential issues. Reading the documentation to know that certain voltage levels don’t work and Googling how to solve those issues was another strategy. Watching Youtube videos on FPGA projects that did similar things, also aided in the project. The Arduino portion of the project, I just worked through it as the documentation is very clear and the integration is seamless.

Posted on

Sara’s Weekly Report (4-19-2025)

This week I wired up the IMU on the top shelf and helped with testing. We had an issue with a bump on the ramp. I tried sanding and using several methods to fix it. Eventually, a TechSpark employee used a table saw to cut off the edge, and then we smoothed it out with a sander.

During this time, I also wrote some code for the Arduino to control one of the linear actuators. I worked on our final slides, set up testing parameters, and listed what we need to measure. I also made a color-coded guide for our wires in case we forget their purpose.

I think I am on track this week because most of our tasks are finished.

Next week we have a lot of preparation to do for presentations, final demos, posters, and reports. We also need to finish the final touches on the robot. I will be presenting our final presentation, so I plan to practice what I want to say about our project. We also have some testing to gather more data for the presentation and report.

While working on this project, I learned about FPGAs and IMUs through our sensing system. The most important lessons I learned were about time management and wire organization. These have always been hard for me in the past. Setting goals and creating a clear schedule helped. When things went wrong, we were able to handle them because we had planned. One part that took much longer than expected was dealing with tangled wires. Having a good system for organizing them made things much easier.

I learned the most through trying and failing. It cost us a bit, but we learned a lot each time. We replaced parts, tried new approaches, and made improvements based on what we saw. Online forums were also helpful because they are full of shared knowledge. Our problems were sometimes very specific, so it was great to find people who had gone through similar things. Short videos helped too because they get straight to the point. I watched one about capacitors that helped me think more about voltage and current when testing motors. These tools helped me think in new ways and pay more attention to the little details.

Posted on

Team Weekly Update (4-19-2025)

Our biggest problem is that, for some reason, the motor drivers and the Arduinos are receiving excess voltage. We do not know how this is happening. However, this has caused us to burn through (not literally) several motor drivers and at least two Arduinos. We are managing this issue by constantly checking the Arduinos and motor controllers. We have backups and meticulously test the wires to ensure they are safe.

Another issue is that our robot tends to drive off the ramp on its left side. This is caused by the board bending and the robot being too wide. We plan to drill out the wheels to create a narrower wheelbase.

We did not make any significant changes to the robot itself, but we did modify our ramp. We shaved down the edge to allow for smoother robot climbing. We also changed our specifications because we had difficulty reaching a 45-degree incline.

There are no schedule changes.

Video: Wonky Drive,

Video: Test Drive

Video: Test Drive with Two Cups

Posted on

Raymond’s Status Report 4/12/25

Over the last two weeks, I’ve been working on getting the whole system working together. For mid-review, we were able to get the linear actuators moving such that when we tilted the platform, the IMU was able to detect that once the board was no longer at 0 degrees from the ground, the linear actuators would activate to even out the board. That IMU that we were using ended up breaking, and we knew this because it would get very hot to the touch when just supplying the correct input voltage. We purchased a new IMU, the BNO085, but when trying to read the data with I2C, I realized that it uses Sensor Hub Transport Protocol (SHTP), which is different from the standard I2C. So, when I was trying to access the different registers to get the sensor data, it would not return the correct information. This resulted in having to buy another IMU, the MPU 6050. I decided against buying the original IMU that I was working with because the gyroscope data was oddly inaccurate, and I had previously worked with the MPU 6050. Once the MPU 6050 arrived, through the PYNQ framework, I was able to receive the IMU sensor data and apply a simple complementary filter to get pretty accurate orientation readings.

In order to get the motors running with the PWM signal from the FPGA, I needed to use a logic level shifter since the PWM signal from the FPGA is 1.8V. I was able to successfully get all four wheels running, but just by moving the wires around, it would change behavior of the motors. They would either stop running, or they wouldn’t stop running when they were supposed to. After doing some research, I realize that this is probably because of capacitance coupling that is amplified by the level shifter. Our wires being longer does not help with this behavior, so I got a new level shifter that is supposed to be more resistant. In the meantime, we will be continuing with Arduino, such that we can test our control algorithm.

Throughout the last two weeks, we also decided to just try and get the system running with an Arduino since we were running into some blockers with the FPGA, so while simultaneously trying things with the FPGA, I was working on getting the system working with the Arduino. This was pretty simple since there is a lot of technical support for Arduino.

We are behind schedule, but we are moving along and not letting the blockers get in the way. We are working on tasks with the Arduino that can be replicated on the FPGA, so that we do not fall too far behind while working with the FPGA.

By Monday, I plan to have the whole system running up a ramp for two feet, while adjusting its platform. I will need to change the setup for the Arduino system such that are linear actuators extend halfway at the very start. Then, to make any adjustments, both linear actuators will run, but in opposite directions, so that we can increase the speed at which we change the angle of our platform. Then I will continue working on the control algorithm such that it reacts immediately to any change in slope, and try to reduce any oscillations.

Posted on

Team Update – April 12, 2025

This week, the most significant risks identified include the bending of the board and the possibility of wires coming loose. The board bending is particularly concerning because if it bends too far, it could snap and damage critical components. Additionally, we’ve been having trouble keeping the wires securely connected, which can interfere with power and signal delivery. To address the bending issue, we’ve added an extra board underneath to help stabilize the structure. If this solution proves insufficient, we plan to glue the board for extra support. To prevent wires from disconnecting, we’re being more gentle during handling and may consider better cable routing or retention methods going forward. We also might use superglue to attach the wires to the board.

For design changes, we are adding the IMU and its circuit inside the platform. This placement will allow us to better monitor changes in movement or orientation on the platform.. However, this update also introduces the need to waterproof the circuit. Additionally, we’ll need to design and install wires long enough to connect the IMU from the platform to the main board below. These are relatively small changes.

There is a change where we might measure and record our results and simultaneously improve our robot.

Video of our platform working: https://drive.google.com/file/d/1AWDLh1zZTwN2v7Hf4jVGB7jIczxpfVpt/view?usp=sharing

Posted on

Sara’s Weekly Update – April 12, 2025

This week, I helped wire and connect our new motors to the board, along with the linear actuators. I was pretty excited because we received a bunch of new parts for the robot. I also built a new wheelbase since we had to purchase new mounts for both the linear actuators and motor mounts, which required drilling a new board.

I made new wires for the motors and moved all the electronics onto the new board.

We also got a new room to store our robot, which allowed us to attach the platform. Unfortunately, I initially purchased the wrong level shifters, the wrong item, and the wrong shaft size. However, I improvised attachments using yarn and tape. I also reversed the wheel so the shaft rested on the outer rim. Later, I got the correct shafts, but they were too long and were bending the board, so I had to carve them down.

To address the bending issue caused by the board’s weight, I added an extra support board and secured it using leftover M5 screws as a temporary fix.

At one point, I accidentally burned out the Arduino, but I replaced it with a new one. I also finished purchasing the ramp.

I rewired the entire board, separating the linear actuators (LAs) and the motors onto separate boards because the signal interference was causing issues. I also rewired the LPWM and RPWM to always be enabled, which improved the control and correction.

Although we’re currently a bit behind schedule due to delayed parts, I plan to catch up by continuing to assist Raymond and keeping track of the robot’s measurements and performance.

Next week, I plan to start on the slides for the final presentation and meticulously run the robot for results.