Posted on

Team’s Status Report for 03/02/2024

On Monday and Wednesday, we were wrapping up our simulation environment and finishing the baseline implementation of RRT. Finishing up this led us to realize that we may also need a dense-matrix implementation of our RRT, which is currently in a sparser form using octrees. On Thursday and Friday, we got together to write the design report.

We won’t be meeting over spring break until the weekend after. We will work on the dense version of RRT,  and start implementing the accelerator architecture using HLS for the FPGA.

 

ABET responses:

A: The product solution we are designing, which uses FPGAs to improve motion planning in robotics, addresses a global need for advanced robotics capabilities. In a rapidly evolving technological landscape, robotics is becoming increasingly integrated with various global challenges and opportunities. By utilizing FPGAs to accelerate motion planning algorithms, our solution not only contributes to the advancement of robotics technology but also addresses broader global concerns such as automation in industries, disaster response, healthcare, and environmental monitoring. Improved motion planning efficiency can lead to safer and more efficient automation processes in manufacturing, potentially reducing labor-intensive tasks and enhancing productivity on a global scale. Moreover, in scenarios such as disaster response and healthcare, where time-sensitive decision-making is important, faster and more accurate motion planning enabled by our solution can aid in faster and more effective response efforts, potentially saving lives. Additionally, in environmental monitoring applications such as autonomous exploration and data collection in remote regions, the improved capabilities of robotic systems can contribute to better understanding and management of global environmental challenges. Thus, by advancing robotics capabilities, our product solution can benefit the world and society at large as robotics becomes a more ubiquitous technology.

B: Does not apply. We are designing an FPGA-accelerated motion planning solution product. Our design focuses on the technical and functional aspects of the product—namely, its speed, efficiency, power consumption, and cost-effectiveness. These features are universally appreciated across various cultural backgrounds due to their direct impact on performance and operational cost savings. The cultural considerations, such as beliefs, moral values, traditions, language, and laws, while critically important in many contexts, do not directly apply to the core functionality and design principles of this specific technology solution.

C:  The main goals of FPGA-AMP are to accelerate motion planning and reduce its energy and power costs.  Motion planning is one of the most compute intensive steps of the robotics pipeline and therefore consumes a significant portion of the total energy and power of the robot.  As the use of robots in industrial and domestic settings becomes more commonplace,  the reduction in their energy and power consumption is of paramount importance due to environmental factors.  A majority of the worlds electricity is produced from non-renewable resources.  This means there is a finite amount of these natural resources and it would be wise to limit our consumption of them.  Burning of fossil fuels for electricity production emits CO2 into the atmosphere.  Significant bodies of research have shown that this excess amount of CO2 results in climate change which can in turn have a detrimental effect on living organisms.  In conclusion, the targeted energy and power reduction of robots that will result from FPGA-AMP will have a positive impact on the environment.

A was written by Matt, B was written by Yufei, and C was written by Chris.

Posted on

Matt’s Status Report for 02/24/2024

This past week, I contributed to the design slides. I focused on the design requirements and the implementation details, specifically the hardware optimizations that we can implement on the FPGA for motion planning. The creating of these slides also led me to think about the format we’ll put our collision data in for transfer to the FPGA.

This week I also worked on getting the Vitis HLS environment set up by running an example project on the Ultra96 FPGA. This example project was a kernel that summed up two vectors that were 1024 elements long each. I built the hardware target, and loaded the disk image onto the micro SD card. The FPGA did not boot up, and I am suspicious of the FPGA itself—I had set up the HLS environment for the Ultra96-v2, which we used in 18-643, but this FPGA model is the Ultra96-v1. Because of this, I’ll have to do some digging to figure out what needs to change about the development environment so that I can build for the Ultra96-v1.

This upcoming week, I will try to wrap up setting up the HLS environment. I will also try to finish the octree implementation, so that it has a complete interface that will be useful later when we are actually using the FPGA for acceleration. I will be working on the design report as well with the rest of the team.

Posted on

Team’s Status Report for 02/24/2024

This past week we worked on our design presentation together. We received many of the parts we will be using, such as the Xbox Kinect, the Ultra96-v1 (temporary FPGA), and the robotic arm. On Thursday, we met to assemble and test out the robot arm. We assembled it together, and Chris was able to power on the arm and issue basic commands to it. During the meeting, I was also setting up the Vitis HLS environment.

Development on the simulation environment has paused, but we plan on meeting tomorrow to assess where we are at and where we need to make progress. Because of this, we are slightly behind schedule.

This upcoming week, we plan on making lots of progress on the simulation environment, hopefully having our baseline implementation of RRT running. We will also work on the design report together, which has already been shared with each of us as an Overleaf document.

Posted on

Matt’s Status Report for 02/17/2024

On Sunday we met to begin our implementation of the simulator. We began work on the C implementation of the octree data structure for representing 3D spaces. I implemented some of the methods, and also reworked our build system to use a Makefile.

On Monday and Tuesday, I made some further contributions to the octree data structure. I also reorganized our main RRT repo and modified the Makefile to match the project structure.

On Wednesday, I shifted my focus to thinking about how the state space (representation of the environment) will be compressed and sent to the FPGA. Our solution has the FPGA doing only the acceleration of motion planning, with the host CPU doing all other work. Thus, the CPU is responsible for perception, and also sending the perception data to the FPGA. The perception data will be stored in an octree, but we are not sure if an octree is the best data structure for the FPGA.

On Thursday, I met with Chris and Yufei to contribute to the design slides. I also spent some time thinking about how motion planning can be parallelized for the FPGA. Some ideas came from a paper I read on parallelizing RRT. I also picked up an FPGA that we ordered, and so I am in the middle of getting a Vitis HLS environment set up so that we can build our accelerator.

Next week, Chris and Yufei will hopefully have their ends of the simulation environment set up, so I might be able to strap them together with our octree to see if we can get something running. I will also continue with the HLS environment, and try running an unoptimized software version of RRT running.

Posted on

Matt’s Status Report for 02/10/2024

Earlier this week, I spent a lot of time practicing for my presentation. I ended up giving the presentation on Monday. My team then met on Thursday to lay the groundwork for our project. Together, we did some research on the hardware we will order. Afterwards, I did some more reading on RRT and a microarchitecture for accelerating collision detection.

From reading the collision detection microarchitecture paper, collision detection is the main bottleneck in motion planning (takes up “99%” of compute time in motion planning). The proposed microarchitecture seems pretty easy to implement in RTL, let alone HLS. The harder part will definitely be data movement and I/O.

Our team is meeting tomorrow (Sunday) to work on putting together a simulation environment. My next task will be to put together a Vitis HLS project.