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.

Posted on

Team Update (March 29, 2024)

The most significant risk to this project is the power and the FPGA and IMu not communicating with the robot. We are having issues with plugging in multiple motors, which is causing the voltage to drop across all devices. This means we cannot continuously drive the robot on the slope. We are also having issues with imu outputting accurate data. We have managed this issue by using capacitors to increase the voltage, and we planned for this by using two batteries. We might want to get a battery with the same voltage but with a higher amperage output. For the imu, we are rewriting the algorithm to account for the calibrations. We want to get a better IMU for more accurate calibration.

At this point, there are some changes to the electronics as different motors have been purchased with a lower rpm to get a higher torque. This is needed to get the robot driving. We also might have to add some capacitors to the electronic design for more voltage, since there is voltage dropping and we constant voltage across all the motors. This has cost some money, but this is a completely easy fix when we get the motors.

Our schedule this week has primarily focused on testing the robot. The updated plan prioritizes testing the robot and its performance. Moving forward, our next steps include implementing these fixes, testing the robot under real-world conditions, and refining the overall system to ensure reliability and functionality.

Posted on

Team Update (March 22, 2025)

The thing that jeopardized the success was not having the right cable. The code cannot run on the USB micro b wire. We found out that we could not connect with a normal micro USB and we debated on buying an expensive part. This means our code cannot be uploaded to the FPGA. We ordered a new one and immediately implemented code tested with Arduino. We are not moving away but improvising with this issue.

We decided to buy a P-series mount because we couldn’t find a way to straighten the linear actuators. The bracket is crucial for keeping the platform tilting properly. We spent nearly $40 on it. We plan to use our current design as a testing mode.

We pushed back driving the robot until next week because of our inability to upload the code. This is solved by testing the code on smaller pieces like the motor and the IMU, and p[reously said testing on an Arduino as a backup.

Posted on

Raymond’s Status Report 3/22/25

This week, I made progress on implementing the motor control system using the Ultra96 FPGA development board. My primary focus was on configuring the Timer Counter peripheral to generate precise PWM signals for variable speed control of our DC motors. After examining the board documentation, I determined the appropriate pin mappings for routing the timer outputs to the external connectors where our motor driver circuitry will interface.

I spent considerable time analyzing the C application code that implements an interactive console interface for selecting different motor speeds. The code efficiently configures the timer hardware, sets up interrupt handlers, and implements PWM generation using the match mode functionality, which allows for precise duty cycle control without requiring constant CPU attention.

During testing, I encountered some unexpected challenges with the development environment. I discovered that our board was running a Linux image that prevents direct hardware programming, and that the Ultra96 requires a specialized adapter for complete debugging capabilities. While these issues have slightly delayed the implementation timeline, I’ve identified clear solutions. For the coming week, I plan to either acquire the necessary adapter or create a custom boot configuration, complete the hardware setup, program the FPGA with our control logic, and begin physical testing with the motor driver to validate the speed control functionality across different duty cycle settings.