Posted on

Team Status Report for 3/15/25

The biggest risk factor is the robot being unable to move or the platform not working by the end of this week. Some things that may contribute to this problem are if the custom IP block for the IMU does not end up being useful. As a contingency plan, we may send the IMU data from the Arduino through UART, which should make retrieving and using the IMU data easier. Another concern is the speed at which our linear actuators move. The fastest rate for change in angle will be when the robot is driving from a flat surface onto a ramped surface, so we plan to slow the robot down if the linear actuators are unable to adjust quickly enough. Before, our systems for the wheelbase and the platform were independent, but we think that we could have the two systems interact to solve this issue. Another risk is keeping the pistons still. To address this, we plan on wrapping the axis with yarn to keep it still. As a contiguency, we might hot glue the yarn for more security.

We made the changes to attach the electronics using velcro tape instead of screwing them onto the base. This was done to save time on reattaching/attaching the electronics on the board. The cost is $9.51.

There is a huge schedule change. We plan on getting the robot moving, the platform tilting, and the bot moving by the end of next week so that we can test and tweak the system. We expect to run into many issues, so we made this change.

Completed the Wheelbase with Arduino

Posted on

Raymond’s Status Report for 3/15/25

This week, I was working on getting the motors to react to the IMU sensor data. I first tried to access the sensor data using the PYNQ framework. I was able to successfully access the device, but was unsuccessful in retrieving any useful data from the IMU.

i2c addresses present on i2c-3 (top) and i2c-2 (bottom)

Read / write and read over I2C to verify the write

Compared to Arduino, where you can easily extract the IMU data by calling some methods, I have not found a solution for the FPGA yet. I have also looked into a few different projects on Hackster, working with FPGAs and driving motors. Our FPGA is a Zynq Ultrascale+ MPSoc, while the projects on Hackster drive their motors with a Zynq 7000 SoC device, so mapping the block diagrams has been a bit difficult. Also, I found another project that sends IMU data from an Arduino through UART, but for the Ultra96, it would need an additional UART module, so I’ve been a bit hesitant. So throughout the week, I’ve been trying to map the Zynq 7000 module to the Ultrascale+ module, to get the motor driven. I’ve also looked into designing a custom IP block for the IMU since there’s a similar project controlling the motor with an ultrasonic sensor that is typically used for Arduino and they had built a custom IP block.

Based on our weekly meeting, and our own expectations, I have fallen behind in getting the FPGA integration done. But, if we are able to get the motors reacting to the IMU data by the next week, and get a preliminary system built, we are expected to be back on track.

In the next week, I plan to design a custom IP block for the IMU to get the data to be used for driving the motor. By the end of the week, I plan to be able to drive the motors based off the IMU data.

Posted on

Sara’s Weekly Update (March 15, 2025)

This week, I finished the bot’s body. I focused on attaching the sides to the platform. 

IMG.1 – Platform

I also finished installing the motors and wheels. (Note: Raymond is working with one of the motors, so our bot is a tripod.) Additionally, I drilled into the body and attached the mounts for the linear actuators.

IMG.2 – Wheel Base completed

Also, I made the wires for the motors to the Motor Drivers and the battery to the breadboard. The Arduino, which I got for free from Techspark, is for me to test the linear actuators using the motor controllers. I made them based on a drawing to keep them organized.

IMG.3 – The wires connecting the Motors and the Motor Drivers

IMG.4 – Motor Wiring Sketch

This week, I think I got what I wanted done for the body. I am behind on electronics since I decided to use double-sided tape to attach it. To catch up, I plan to prioritize securing the electronics first thing on Monday.

Next week, we need to get the robot moving and the platform tilting. So I plan on getting the electronics on the board and finish attaching the linear actuator, which takes two people. As a temporary solution, we’ll hold it in place with yarn. I also plan to assist Raymond with anything he needs.

 

Posted on

Raymond’s Status Report 3/8/25

This week the goal was to get the FPGA programmed to be able to receive the sensor data from the IMU as well as be able to output a signal such that the motors are driven. I was working with the PYNQ environment and had some trouble getting the environment set up. Eventually, though, I was able to get the PYNQ environment working, but I still had problems getting the sensor data. There is nothing showing up in the place where I expect the data to be. I wasn’t able to debug it for too long because I left for spring break early.

The progress is behind because our team wanted to get the goals of reading the IMU data and outputting a PWM signal to the motors done, but we were unable to get it done successfully. I plan on getting the IMU sensor data receiving working by Wednesday, by trying to debug the system. I also plan to get the motor output done by Wednesday. By the end of the week, I can work on incorporating the IMU sensor fusion algorithm in Vitis so that the raw IMU data can be seen as positional/angular data, which will be useful for us.

 

Part B:

With cultural factors, because we are automating hazardous materials transport, there are the considerations in law for who will be responsible if a device such as our Slope Stabilizer Robot were to injure someone. We want it so that robots can be used to aid humans to reduce the risk of injuries, but we also don’t want to take away from human jobs. Our simple user interface makes it accessible across language barriers and varying technical expertise levels, allowing for diverse workplace environments.

 

Part C:

From an environmental perspective, the Slope Stabilizer Robot offers significant benefits by substantially reducing the risk of chemical spills that could contaminate the environment such as soil or water. The current prototype uses wooden components, a renewable resource with lower carbon footprint than plastics,  and future iterations could incorporate more sustainable materials and energy-efficient systems.

Posted on

Team Weekly Update (3/8/25)

One significant risk is the time required to work with the FPGA and IMUs to obtain accurate inputs and outputs. Calibrating these components and ensuring they correctly control the robot is a major challenge. If we fail to do this efficiently, we risk not meeting our Minimum Viable Product (MVP). To mitigate this, we are prioritizing early testing and debugging sessions to identify and resolve issues as soon as possible. Additionally, we are documenting calibration steps to streamline the process for future iterations.

We modified the design by mounting the linear actuators (LAs) directly on the wheelbase instead of using an additional layer. The extra layer added unnecessary complexity, so removing it simplifies assembly. However, this change exposes the board to potential water spills. To address this, we will reinforce the platform’s edges with a polymer sealant to prevent water from seeping into critical components.

No schedule changes were made.

PART A:

Our slope-stabilizing robot enhances workplace safety and automation by ensuring the secure transportation of goods across uneven terrain. Industries such as construction and chemical handling face significant challenges in moving materials safely, often leading to worker injuries from slips, falls, and repetitive strain. By automating these deliveries, the robot reduces physical risks while improving efficiency. Its FPGA-driven real-time stability prevents spills, minimizes human exposure to hazardous substances, and reduces the agitation of sensitive materials. Our bot not only enhances operational reliability but also contributes to safer working conditions worldwide.

Additionally, our bot plays a role in the broader trend of automation and workforce displacement. As industries worldwide integrate robotics, concerns about job loss arise. While this technology may reduce certain manual labor roles, it also creates opportunities for new technical and maintenance jobs. In hazardous industries, such as chemical transport or waste management, automation significantly reduces human exposure to dangerous materials. This improves long-term health outcomes for workers globally.

For the additional prompts, Sara was responsible for part A, while Raymond was responsible for parts B and C. This reflects equal load distribution because Sara was previously responsible for 2 prompts.

Posted on

Sara’s Weekly Update (3/8/25)

This week, I worked on the Design Report. I also attached the mounts for the motors. We decided not to use a second board because we could put the linear actuators (LA) on the wheelbase. So, I decided to attach the mounts as the second board would have made changes to the wheelbase harder, which we are not using.

IMG 1: Board with mounts

I worked on soldering the pins for one of the IMUs. My first attempt was poor due to the fact I did not fully some of the pins to the metal parts of the board. I desoldered and redid the process later, which provided a much smoother solder on the board.

IMG 2: IMU with Solder

I was able to glue two sides on the platform board. I also cut out the other sides for this board.

I am a little behind on the platform board. I plan to solely focus on building this week to compensate. I cut the sides too large and need to be sanded or ground down a bit. I plan on doing this immediately on Monday.

I plan on using double-sided tape to stick the electronics on the board since it is easier to remove.

Next week, my main goal is to finish the body. I want to complete the platform board assembly by Wednesday. By Friday, I will mount and secure the pistons. Toward the end of the week, I will begin wiring and positioning the electronics.

Posted on

Raymond’s Status Report for 2/22/25

This week, I started implementing some code on the FPGA, specifically the complementary filter for the IMU data. I looked into the different kinds of filters such as complementary, Kalman, and Madgwick filters. Ultimately I decided on the complementary filter because it is the simplest to implement. However, if the accuracy of the data is not good enough, I may move to a Kalman filter because I could use the FPGA hardware to do the necessary matrix computations. I also watched a few videos on using FPGA’s for embedded systems projects which gave me a good idea for integrating all the sensors with the FPGA.

The schedule is a little behind once again because the IMUs have not arrived yet. So, I wasn’t able to test if the FPGA can receive data from the IO pins. Once the sensors come in, I expect that I will be able to quickly test the IO ports and get the sensors integrated with the filtering algorithm.

In the next week, I hope to get the sensors integrated with the system. The motors have also arrived and the motor drivers were ordered recently, so if the motors arrive, I also expect that I can test the FPGA with the motors.

Posted on

Team Status Report for 2/22/2025

One of the biggest risks we face is the weight of the pistons. They are heavier than expected, which may affect the robot’s structural integrity. To address this, we plan to use a combination of smaller and larger pistons to lift the platform without compromising stability. If this approach is not feasible, we have two contingency plans. The first option is to use two boards instead of one to support the piston mounts. The second option is to reduce the number of pistons on the platforms to decrease overall weight. These solutions will help maintain the structural integrity of the robot while ensuring the pistons function as intended.

Another risk is the delayed delivery of parts. To mitigate this, we are working with the components we currently have and actively following up on pending deliveries to keep progress on track. While waiting for critical components, we prioritized tasks that could be completed with available materials to minimize downtime. This approach will help prevent significant disruptions to the overall project timeline.

A minor design change was made to improve stability. Initially, the robot was designed with four columns, but we increased it to six to better support the boards, pistons, and platform. This adjustment ensures the structure is strong enough to handle the load and reduces the risk of mechanical failure. However, this change also introduces a challenge: reduced space between the first and second board, which may make it more difficult to access and repair electronic components like the FPGA. As a result, we may need to disassemble parts of the robot when making adjustments. While this adds complexity to maintenance, the improvement in structural integrity outweighs the drawbacks.

Due to delays in part deliveries, we have pushed back the completion of the full design of the wheelbase, as the wheels have not yet arrived. Similarly, the FPGA system has been delayed since some components are still pending. To maintain progress, we are focusing on assembling and testing available parts while waiting for the remaining components. When the delayed parts arrive, we will focus on integrating them promptly to get the project back on schedule.

Posted on

Sara’s Weekly Update 2/22/2025

This week, I completed the base for the project. I cut the board into an 11” x 12” square and drilled the necessary holes for the column (M5) and the motor mounts. However, I only attached one motor mount instead of fully assembling the board. This decision was made to ensure enough space in our red box and to allow me to map out the electronics before the final assembly. I wanted to avoid repeatedly disassembling and reassembling the base and columns before integrating the electronics.

A significant step forward this week was the arrival of our battery boards and motors. I drilled six holes for the mount, but during this process, I noticed that pushing while drilling caused the wood around one hole to break, making it unstable. As a result, I had to cut and drill another board. Despite this setback, I am back on schedule.

IMG. 1: Cut Board (12″)

IMG. 2: Cut Board (11″)

I am slightly behind due to the delay in the arrival of the wheels, which are needed for fitting. However, aside from that, I am satisfied with my progress. Once the wheels arrive, I am confident that I can fully construct the base. To make up for this time, I plan to focus on completing the rest of the robot build and installing the pistons.

Next week, I plan to install the FPGA and other electronics onto the board, finalize the piston on the second platform, and complete the platforms holding the water.

Posted on

Raymond’s Status Report for 2/15/25

This week, I was working with Sara to figure out the entire design of our stabilizing robot. The part specifically that I was working on this week was the interfaces for the FPGA to be able to access IMU data as well as output PWM signals to the motors. I began the setup process of the FPGA, but have yet to figure out the software implementation completely. I am researching the pros and cons of using either PYNQ (Python) or Vitis (C/C++) for the software to read the IMU data. I want to use the FPGA logic elements for generating the motor outputs, however, so I am leaning toward Vitis. I have also been working with Sara to complete the Design presentation, and have been preparing for the presentation I will need to do.

Our progress is a little behind. We planned to be able to begin testing as soon as possible, but we are currently waiting for parts to arrive. So we are going to get the whole system ready such that when the right parts arrive, we already have a base that we can test the system with, instead of starting the logic designing step once the parts arrive.

Throughout the next week, after completing the presentation, I want to set up some logic on the FPGA, such that once the motors and sensors arrive, I can quickly integrate them into our system. I would like to perform the IMU sensor fusion algorithm on the FPGA, so I could start by writing a module and creating a testbench as well.