Month: February 2024

Significant Risks and Contingency Plans

This week, we met with Andrew Jong to discuss what kind of drones would be useful for our project, and what capabilities would be feasible to implement. After this, and with further discussions with Prof. Kim and Tamal, we decided that making a pivot to using a land-based autonomous vehicle instead of a drone would be more feasible to implement, as it would be less risky and expensive.

The most significant risks right now all involve the capabilities of the rover. It is imperative that we find a suitable rover that has a software API to navigate it autonomously. Additionally, the rover must be able to navigate through an uneven terrain effectively and accurately. There are also some risks with figuring out how to conduct our scenario testing for demo day, and how a camera and laser mount would exactly function. We are actively investigating many possible types of such rovers and what capabilities they hold. Our main prospect are Waveshare WAVE ROVERs, which are cheap, have software API, GPIO pins, and an all-around versatile body. Regarding this, most of our risks and back-up plans come around to learning how to use this rover, and changing our implementation plans to fit around this. While our general idea may not be changed, our implementation plans certainly will be.

Our contingency plan, in case we don’t find such a suitable rover, which seems improbable, is to buy a more expensive drone that has all of the capabilities we need to complete our project. However, it seems highly unlikely that we use a drone, as using a rover seems easier for testing purposes. Additionally, a rover would be more durable than a drone, as any accidental collisions on the drone might break it. We would also be looking into potential issues with testing a rover on campus, and look if any licenses or certifications are needed for this.

System Changes

Depending on what kind of rover we decide on purchasing, there are numerous system changes in terms of the API we would use to control the rover, how communication between the rover and the Django and CV servers would work, and what kind of path the rover would take. There are also some changes in our use case, as using a rover allows us the flexibility of being able to search an uneven terrain and potentially avoid obstacles (undecided if we actually should implement this). However, much of the implementation of the web application and the distributed CV server should remain the same. All aspects of the design and system integration of the rover are a work-in-progress, and we are working hard to make sure this pivot goes smoothly and doesn’t hinder our progress. As aforementioned, learning to interface with the rover (like the WAVE ROVER) would require implementation differences on all portions, and these differences will be the focus of our work moving forward.

Other Updates

Schedule updates are expected, but not finalized, to accommodate for the delay in obtaining our mobile platform. This delay will attempt to mitigated by ordering the parts prior to spring break, and then analyzing the documentation on using these parts during their delivery. Also, now that we plan to use a WAVE ROVER instead of a drone, each of our individual components are expected to face some changes in integration and implementation.

Significant Risks and Contingency Plans

The most significant risks to our project right now involve the uncertainty behind our drone. A large majority of our plans and back-up plans have been turned down for various reasons, creating a potential void of paths to move forward on. Fortunately, last week, we came across a very promising route, being with Prof. Basti Scherer. Prof. Basti has performed a wide variety of drone research, including areas like search and rescue. Our primary hope now is that Prof. Basti is able to lend us drones and/or the software that he uses to control them. Should he be unable to do so (unlikely, but possible, given his email), our back-up is that Prof. Basti gives us valuable information on what types of drones to use, along with other implementation-specific advice. Furthermore, we will adjust the data transmission from an RTMP video link that’s given by our original drone, DJI Mini 2 SE, to a video streaming method that’s compatible with the drone that Professor Basti may lend us to use. This new link will connect the drone to our website application as well as the object detection server.

System Changes

Under heavy advice from Prof. Kim and Tamal, finding a drone with software API proves to be the utmost important. Going this route is challenging, but under the guidance of Prof. Basti, it is now seeming much more feasible. Having a software API means that the entirety of the drone-controller controller (DCC) would not be needed anymore. On the other hand, it would require learning the entirety of the software API once we got ahold of it. The time and effort spent doing this can replace the time and effort spent on building the DCC, so generally speaking, this cost can be mitigated well.

Other Updates

There have been no schedule changes nor other updates. Potential schedule changes may occur after our meeting with Prof. Basti next week.

Specified Needs Fulfilled Through Product Solution

There are a variety of considerations that must be made with developing our product. We identify these considerations by breaking them down into three broad groups. The first group (A) deals with considerations of public health, safety or welfare. The second group (B) deals with the consideration of social factors. The third group (C) involves economic considerations. A was written by David, B was written by Nina, and C was written by Ronit.

Public health, safety, or welfare considerations (A)

Search and Aid would have significant health benefits for society. Being able to assist first responders in finding and aiding those in need is critical when fast timing is a necessity. In times where searching over an area of land is extremely difficult or impossible, sending a drone to provide air coverage would be a necessity. Having a search and aid drone could literally save lives; suppose a situation where a stranded hiker was in desperate need of water. Our drone could help scan through areas, searching for human life while  carrying an aid package (like a water bottle). Upon finding the hiker, it would be able to deliver it the water, and alert the first responders of the hiker’s location. Essentially, the Search and Aid drone is able to help provide a bird’s eye view of the land, allowing us to provide a way to ensure greater health protection of individuals in need and a higher standard of safety for all.

Social factors (B)

In our scenario of implementing a search and aid drone used by government rescue agencies, social concerns will be alleviated in areas such as search and aid in politically sensitive disaster situations. In the scenario of wartime or politically sensitive situations where people of different backgrounds are in need of assistance, a search and aid drone is perfect for providing resources without bias. Non-specific help organizations, such as Doctors Without Borders, would be able to offer medical assistance in dangerous areas without being physically in danger. Furthermore, this would reduce concerns of additional aggravation between warring parties as the help organizations would be operating remotely and even under anonymity. 

Similarly, using a search and aid drone would help alleviate the concerns of families and friends of emergency responders as they would no longer have to risk their own lives in dangerous situations. In cases of wildfires or dangerous terrains, our search aid drone would be able to peruse over the area of danger looking for those in need while workers could search and monitor along the perimeter safely. Traditionally, workers would need to search through the dark and traipse through unknown areas in order to look for people, potentially putting themselves in harm’s way. Now, through the help of the drone, this can be done entirely remotely and entirely reduce the worries of rescue workers’ loved ones. 

Economic considerations (C)

There are some significant economic considerations that come with our search and aid drone application. One of the use case sub-requirements is cost effectiveness. Overall, using drones would be cheaper than humans due to low long term costs. Currently, many search and rescue missions are costly due to the large amount of human labour required. The drone application reduces these costs and the risks associated with manned rescue operations, as drones would be able to navigate through rescue areas without the endangerment and need of humans. Through this, the economic burden on governmental rescue agencies is lessened due to lower operational costs.  Additionally, using accurate and fast drones maximises the impact of rescue efforts. Using machine learning leads to optimisation and a positive economic impact in general.

Furthermore, there are some economic considerations with the production of such drones. Even though the initial fixed cost of making these drones would be high, they would be cost effective in the long term due to factors like high durability. This would minimise the need of replacing these drones regularly. Considerations with respect to consumers of these drone applications must be made as well. These drones must only be used by governmental rescue agencies and humanitarian organisations, as the use of such drones by the general public might be dangerous. Finally, these drones would also help improve the general economy through the creation of jobs and boosting the demand for specialised drones.

Significant Risks and Contingency Plans

The most significant risks right now all involve the capabilities of the drone. Right now, it is crucial that the drone that we manage to obtain is most suitable for our project, as it may not be monetarily possible to be able to purchase another one. Having the most apt drone for our situation will make everything moving forward much easier (and possible). We are investigating many possible types of drones and their capabilities, and have many contingency plans for if we cannot find the perfect drone. These plans include shifting the purpose of our project, or coming up with different methods around whatever the drone lacks (for example, if the drone is unable to carry much weight, then an aid package may not be the best approach, in which case we adapt towards a laser pointer). In addition, due to our testing being done on campus, we will also be looking into getting a license this week for our drone if necessary.

System Changes

Depending on which drone we are able to obtain in the end, there are foreseeable system changes. Also, Prof. Kim suggests we take on a Search and Point project instead of a Search and Aid project. Should we end up switching to this, it would require many changes on all aspects – our use case and requirements would differ entirely, and our communication with the drone would need to include laser pointer controlling. Speaking of which, Prof. Kim also suggested we get a drone with an API, which would allow us to avoid having to build the drone-controller controller (and make controlling the drone a lot easier overall). These are things that are currently a work-in-progress, and should be updated more in detail in the next status report.

Other Updates

There have been no schedule changes nor other updates.