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.

Posted on

Raymond’s Status Report 3/29/25

This week I focused on establishing the hardware and software foundation for our two-piston balancing platform. I created a Vivado block design for the Ultra96 board with SPI interface configuration, successfully implementing the design and generating the necessary files for PetaLinux integration to prepare for the software development phase.

On the software side, I built a custom PetaLinux image with SPI drivers enabled, modified the device tree to properly configure the SPI interface, and created the necessary boot files for the Ultra96 board. For communication testing, I established a serial connection for debugging the system boot and verified the initial boot sequence, which confirmed that the basic hardware configuration is working as expected.

I was able to successfully drive the motors from the FPGA, a significant milestone for the physical control aspect of our balancing platform. Additionally, I obtained some decently accurate readings from the IMU. While initially attempting to implement sensor fusion algorithms, I discovered the gyroscope data appeared incorrect, causing fusion results to be unreliable. As a result, I pivoted to using direct calculations instead of sensor fusion methods. To address the gyroscope accuracy issues, a new IMU has been ordered to determine if we can get more accurate gyroscope data for potential future integration of sensor fusion algorithms.

The project is slightly behind schedule as I haven’t yet finished setting up the complete serial communication for system debugging. To catch up with the project timeline, I plan to finalize the serial connection setup, implement additional testing procedures, and optimize the current SPI configuration to ensure reliable data transmission.

 

 

 

 

By tomorrow (Sunday), since mid-demo is on Monday, my primary goal is to get the IMU fully integrated with the motors such that the motors are driven based on the IMU data. This integration is critical for demonstrating the core functionality of our balancing platform. I’ll focus on implementing the control loop that reads orientation data from the IMU and converts it into appropriate motor control signals to maintain balance based on the detected platform angles. In the latter half of the week, I plan on beginning testing to tweak anything on the software side to make sure that our robot functions as desired.

Posted on

Sara’s Weekly Update-March 29, 2025

This week, I focused on getting the IMU working to process inputs and outputs. While I didn’t make much progress on the IMU itself, I contributed significantly to motor testing. I realized that we needed a lower RPM for higher torque, which led to switching to motors with a lower RPM. Initially, I attempted to decrease the RPM using a resistor, but this prevented the motor from functioning properly. Later, I tried using a capacitor to supply additional current and power, but during testing, I accidentally sent a wheel flying across the lab. I’m sorry. Through these experiments, we discovered that connecting multiple motors leads to a voltage drop, which I plan to fix by adding capacitors in parallel.

IMG. 1 – OLD RAMP

IMG. 2 – NEW RAMP

In addition to motor testing, I worked on the linear actuators (LA), testing them with an Arduino as we encountered issues with the code used to control them. Another key task I undertook was building a ramp for testing. Initially, I designed a standard adjustable ramp similar to a folding chair mechanism. This took about three hours to construct, during which I used M5 rods to lower the height and adjust the angle. After consulting an expert, I revised the design and switched to using two M5 threaded rods for better adjustability.

I am behind on this project with little time left, so I plan to dedicate significant time to working on the circuit, catching up, and putting in extra hours.

My main goal is to get the robot running and begin testing as soon as possible. I also hope to finish the ramp to test inclined angles and assess balance with water on top.

Posted on

Sara’s Weekly Update (March 22, 2025)

We are caught up with the physical build. The robot is currently designed for testing: a detachable platform to test for slop climbing, and a small linear actuator (LA) for platform testing. I drilled the L brackets onto the platform and the LA onto the board. I also completed the rest of the motor controllers to motor wires.

IMG 1. Completed Board and Platform

IMG 2. Completed Wheelbase with mounted LA

IMG 3. Added Mounts to platforms

I got our LA to run. Here is a link to the video. https://drive.google.com/drive/folders/1XDY6sC3153WC3wEnl2y9C_0TSnG_CBZb. During this part, I fried a motor controller… Sorry.

I tried to use yarn to stabilize our LA, did not work. We purchased a P-series mount to straighten the LA’s when the bot is going up a slope.

I am on schedule with the robot body, as we previously discussed that testing would be conducted in a different manner to accommodate a testing schedule for individual parts. I decided not to install the electronics yet since they are needed for separate component testing. To compensate, I plan to fully utilize this testing mode to make sure our robot works completely. This involved drilling holes in the platform for the mount, which could result in water leakage onto the board.  I plan to glue pieces of wood to the platform and the bottom for added security when we add the different p-series.

However, we are behind schedule on the robot itself. While we have the code, we are rushing to complete implementing it. To compensate, we plan on working on smaller parts and combining them later.

Next week, I plan to assist Raymond with his work and continue testing the robot platform and its driving capabilities.