Figure below shows the risks that we were tracking throughout the Spring Semester.  Some notes on some major risks and their mitigation strategies:

• (14) related to the weight of the drone being too heavy for flight.  This was a significant problem at the beginning of the Spring semester, with us projected to be 300 grams overweight, but through weight cutting measures discussed in previous sections, we were able to keep the weight at the maximum recommended of 3.6 kg.  This was still a significant risk, since if we had to make any modifications to the hardware, the weight could go up, and potentially put the quad in danger, but we kept a close eye on the dynamic behavior to characterize the drone and limited any hardware changes in order to limit the risk of this problem.
• (21) was a risk associated with the WiFi communication.  In the Fall semester, we had significant problems with our communication system, making it a huge risk for us. We purchased all new hardware to limit the occurrence of the problem, but we were still limited in the range of the antenna, so any long distance testing could trigger problems.  We adjusted our flight plans accordingly.
• Weather (20) was a significant risk that we could not do much about. We limited the impact of this by planning ahead and testing as much as possible while we could, though we still got behind in our test plan over the course of the semester when work schedule did not match well with the weather schedule.
• (9) was related to availability of a testing ground. We did a significant amount of testing in Schenley Park, but people in the past had been hassled by park staff for flying.  This did not occur to us until the day of SVE, but we had a backup flight area of NREC (through Dimi) that we could access if Schenley Park became unavailable to us.
• (10) related to the processing of FPV frames to keep the system real-time.  This was mostly dependant on the WiFi connection (addressed earlier) and the amount of data passed through.  We limited the amount of data as much as possible and had plans to downsample the number of buffered frames if the frame rate became a significant problem.