Posted on

Team Status Report for 10/27/2024

The most significant risks that could jeopardize the success of the project are setting up the Raspberry Pi 5 and getting the drone flying with the weight of the components that we have on it. Currently, we are putting a pretty significant load onto the drone, and we want to get at least 10 minutes of flight time on the drone. With peak power, we may be able to get about 10 minutes but we are running some tests soon to see how much that changes with a drone that does not move much while also carrying a full load.

We have made some changes to the design this week. We realized that the FPGA acceleration is not worth the time and the effort of setting up the Kria, in addition to the development time of getting the Kria on the drone to keep using it. I talked to Varun and he told me about an AI accelerated Raspberry Pi 5 that we are planning to switch to. This was mentioned in Gaurav’s Status Report but the KRIA can only manage about 1 TOPS (trillion operations per second) while the AI kit with Raspberry Pi 5 can do about 13 or 26 TOPS depending on the hat that we buy. As such, the increased performance and the reduced form factor makes the Raspberry Pi the ideal platform for our uses moving on. This will cost an additional $100 which we accounted for in our budget by not allocating more than we need. Since we are also getting the Raspberry Pi from the inventory, then the extra cost is extremely minimal for this addition.

We also made some changes to our battery requirements. As mentioned above, we were not sure how long the drone could fly for with a 2200 mAh battery that we are drawing 40 A from. We will run some tests soon to see how much that changes when the motor is not running at peak power but still carrying a full load. We have some batteries we can use to test, then we will order the batteries we need, which is how we will mitigate this cost. We are only buying the battery that we will need for our use case, and using recycled parts for our initial battery tests.

Although we have made some changes, we are still on schedule and no changes have been made to our timeline.

 

Posted on

Gaurav’s Status Report for 10/26/2024

This week, I repeatedly met with Bhavik and Ankit to decide how to move forward. There were a couple things that we had realized that we wanted to reevaluate

  1. We realized that our battery may not be large enough. We had chosen a 2200 mAh Li-Po battery, but since we needed it to supply 40 Amps, that would mean that we only have about 5 minutes of flight time. So we have decided to resize our battery to get a larger flight time.
  2. We realized that our FPGA acceleration was not worth it.
    Taken from https://www.raspberrypi.com/products/ai-kit/
    Taken from https://xilinx.github.io/kria-apps-docs/kv260/2022.1/build/html/docs/nlp-smartvision/docs/hw_arch_accel_nlp.html

    As you can see from the pictures above, the Raspberry PI with AI acceleration has a significant performance boost, and in a smaller form factor because it is a hat for a Raspberry Pi 5. As such it makes sense to switch to this instead of the Kria acceleration.

We are very much on schedule. Since the issues with the Kria was causing some of our schedule to be pushed back, changing to the Raspberry PI will put us ahead of schedule because we are all much more familiar with the platform.

By next week, I hope to have helped Bhavik run the CNN on the Raspberry Pi as we wait for the AI kit to arrive. I will also help Ankit run some of the controls on the drone to check that it can stabilize itself.

Posted on

Team Status Report for 10/20/24

Gaurav did Part A, Ankit did Part B, Bhavik did Part C

The most significant risks that could jeopardize the success of the project are scheduling issues. Trying to make the first demo is definitely a time crunch, and we have lots of work left to do. The way we are managing the risks is by keeping each other accountable to make sure we stay on track. Our contingency plan for the demo is to just show the object detection working and the drone flying, and have those two subsystems be put together for the next demo.

There have not been any existing changes to the design of the system. Although we have lots of work to do, we should still be able to meet the deadlines we have set for ourselves to make the first demo.

Part A:

The search and rescue drone addresses critical global needs such as usage in disaster search and rescue scenarios. For the target audience, search and rescue teams, time is of the essence and we are able to greatly minimize the time spent searching for the target by introducing our drone into the search process. By using object detection technology and integrating the processing power of the Kria all on the drone, we are able to get rapid autonomous detection of stranded individuals and maximize the area covered in given period of time.

With respect to how our solution caters towards those who do not necessarily have a technical background, our solution will start searching as soon as the drone is turned on. It will run its start sequence, rise into the air, and start the lawnmower search. This makes our product extremely useful for non-specialized teams or SAR teams in remote regions who do not have access to highly specialized equipment or a technically proficient staff. In this way, it scales to meet the global demand for effective, autonomous emergency response systems and greatly improves disaster preparedness around the world.

Part B:

From a cultural perspective, it is the goal of governments (both federal and local) to provide safety for their residents. For coastal communities, this involves providing search and rescue for any people lost at sea or on another body of water. However, a common theme across search and rescue, especially over bodies of water, is that it is an expensive proposition. By creating this low-cost SAR drone, we are hoping to enable communities, regardless of income level, to provide safety for their residents.

The other cultural aspect of our project is that we want to maintain privacy, and so all computations related to the person detection are done onboard the drone. This means no camera footage is saved or offloaded which allows us to maintain the privacy of any people being detected at sea or any rescue crews that might show up at a later period of time.

Part C:

The autonomous SAR drone aims to help find missing people in an ocean environment, and as such, it is important we minimize the disturbance caused to the marine life and ecosystem during operations. We have designed the drone such that it doeesn’t have to interact with the ocean environment at all. Given that all the necessary components are onboard, the drone simply has to fly above the ocean environment without having to physically land or make contact with the water. This allows us to avoid interference with aquatic animals and the ocean ecosystem.

Furthermore, in order to reduce disturbances, we have designed the drone to have a small mechanical footprint made from carbon fiber. This will ensure that the drone is very light and can more efficiently make use of the battery power on board.  Additonally, we have selected efficient yet quite drone motors such that noise pollution is reduced, thus helping avoid disrupting aquatic life. In regards to powering the drone, we have elected to use a recharable battery, this allows us to reduce wastage and reuse the tools hardware for multiple flights.

 

Posted on

Gaurav’s Status Report for 10/20/2024

These last 2 weeks, I was able to accomplish many of my tasks. The first task I was able to accomplish was the design report. I worked with my teammates extensively in order to complete the design report and accomplish all the requirements. I was also able to get much of my own tasks done. I was able to finish the basic setup and start work on the DPU setup for the Kria. I also setup Vitis AI on my laptop and have been working with the AMD contact, Varun, and Bhavik in order to run our own PyTorch model on my laptop. I also worked on flashing Petalinux onto the Kria so I can connect my laptop to the Kria and upload any necessary files. This is partially working, since I am having some issues getting the internet to work.

Basic block diagram setup
Vitis AI running on my laptop

My progress is on schedule. Since I was able to setup the architecture on the FPGA that can actually accept the object detection model, then if I can resolve the issues I’m having with the Kria and Vitis AI then we can actually test the model. I just have to get the internet running on the Kria so that the Kria can download the necessary package and try running Bhavik’s Pytorch model in Vitis AI.

By next week, I hope to have the Kria board running with the internet and having the necessary Vitis AI files on it. I also hope to have the DPU architecture flashed onto the FPGA fabric so that the Kria is ready to run tests.

 

 

Posted on

Team Status Report for 10/05/2024

Currently, the most significant risks that could jeopardize the success of the project is integration. Currently we each have our own parts of the project that we need to work on individually so getting that working together will be our biggest struggle. Also making sure we can keep on each other schedule, for example that Ankit can complete the drone by the time that Bhavik has completed training the model and I have finished setting up the vision model on the KRIA. To manage these risks, we are keeping each other accountable and up to date so that we can all finish on time.

No changes were made to the design of the system. Our progress is currently on schedule. We are currently trying to finish our individual components for full integration sometime soon.

By next week, we hope to have the drone partially assembled assuming the parts get here in time and have the balloon detection algorithm working on the KRIA in some capacity. We may have to alter the model to account for the distance from the target but for now we want the KRIA to simply detect the target object.

Posted on

Gaurav’s Status Report for 10/05/2024

This week, I created an example Vivado project and got the complete workflow working. I also started on getting the Vision AI working, and I plan to finish that by the end of this weekend. I also worked on the Design presentation with Bhavik and Ankit and helped finalize the design and order all the parts.

I am slightly behind the schedule because I was hoping to have more of the toolchain working on the KRIA itself. However, because I do not have a good way to connect to the KRIA until the parts come in which they have not yet. However, once the adapter comes I will be able to flash the SD card with the linux image and test the vision AI on the board itself.

Next week, I hope to have the camera connected to the KRIA and a basic vision model working. I also want to have tried using Bhavik’s parameters to see if that can identify the target (which is a balloon).

Posted on

Gaurav’s Status Report for 09/28/24

This week I was able to flash petalinux onto the KRIA, as well as read through more of Varun’s documentation on how to setup Vitis AI on the KRIA. With the group, I met with Ankit and Bhavik to finalize the entire design as well as get ready for part ordering. This weekend, I will be ordering a KRIA compatible camera and setup a basic vision model, as well as ordering other hardware to connect to the KRIA. Much of the work I did this week was reading documentation and understanding the tools available to me and checking that I can connect to the KRIA.

My personal progress is on schedule. I was hoping to get more of the Vitis AI setup working, however I knew that it may take longer than expected and compensated as such with my plan to complete my work.

By next week, I hope to have a basic vision model running on the KRIA and have it connected to the camera or have the camera on the way.

Posted on

Team Status Report for 09/21/2024

Currently, the most significant risks that could jeopardize the success of the project are scheduling and training/calibration time. With scheduling, there are many deliverables and many components we need to ensure can work together. This could definitely jeopardize the success of the project if we have underestimated the development time. the other risk is training/calibration time. This time includes training the model and also calibrating the PID controller may take time to make sure it is stable and functions properly. If we are not able to calibrate it properly it could put the rest of the project at risk. These risks are being managed by ensuring the components of the task that could take the most amount of time are being done first and we are all working together to make it easier to deal with hurdles or obstacles. Since the calibration is unique to our drone, it is not possible for us to get around this part of the drone. We have to make sure this part functions properly. With the AI training, our contingency plan is to use an even simpler target that will be easier to spot.

There were some major changes made to the design of the system this week. We switched from the KV260 to the KR260 board. This change was necessary because another team needed the vision board so we switched. This actually reduces our cost as we no longer have to buy the accessory kit for the vision board. Another change that we made was using a pre-made drone chassis instead of 3d printing one. This change was necessary because this drone chassis we are buying has much of the power distribution and design done for us already, with a strong frame made out of carbon fiber. This will be more durable and solve our power distribution problems that we would have run into before. This will incur a cost of 60 dollars, but since this is a necessary cost, it will be mitigated by saving money in other areas. The final change we are making is our use case. We are narrowing down our use case to just over a body of water to detect people that are lost-at-sea which will make the efficacy of our drone much better.

No updated schedule required, everything is on track.

Posted on

Gaurav Savant’s Status Report for 09/21/2024

Accomplishments:

This week, I gained some familiarity with the Kria platform as well as read documentation related to the Kria boards and using the vision platform. I also met up with Ankit and Bhavik multiple times to discuss our design and work through any changes that needed to be made to make our MVP more realistic.  Earlier in the week, I spent time building the slide deck for the Proposal Presentation. and practicing the presentation.

I am currently on schedule. Since we have decided against the custom PCB and custom drone frame, my main job is getting the PyTorch model working on the Kria Robotics board, which I will definitely be able to complete in time. I will especially be able to complete this due to the abundance of documentation online for the Kria KR260.

In the next week, I hope to have the Vitis AI platform set up and a better understanding on how to use the Vitis platform with the Kria by reading through Varun’s documentation. I also want to have flashed the Linux image onto the Kria and test running a simple program on the ARM chip.