AWD 3302: Project Files

Project 3

Student id: s24

To select another student or project, return to the Project Page.

View XML Source View Formatted File

Automated Magnet Based Anti-Drone System

Automating drone movements with target based optical tracking

Oliver Scott, Nate Winn, Tanner Lindemer, Robert Daigle, Robert Peterson, Robert LeBel

August 16th 2016

Table of Contents

  • Executive Summary
  • Preliminary Analysis
    • A. Tracking
    • B. Target Acquisition
    • C. Regulations
  • Feasibility
  • Success Criteria
    • A. Hardware Design
    • B. Automated Flight
    • C. Target Acquisition
  • Cost
  • Report
  • Risk Analysis
  • Conclusion

Executive Summary

The proliferation of single board computers has greatly reduced the cost and complexity of drone development. As a result, an exponential number of drones are taking to the skies each year, outpacing the FAA and local authorities' ability to regulate them. The difficulty of regulating aerial vehicles compounded with the ability of pilots to navigate their drones from remote locations exposes serious vulnerabilities with maintaining privacy, safety and security.

This report will investigate a novel way to police drones using an anti-drone system. The approach proposed surveys an anti-drone that would autonomously track and capture a target drone using electromagnets. The project carries a high number of developmental difficulties -- chiefly due to the fact research is being performed in tandem with engineering -- making predicting success highly difficult. Even with these risks in consideration however, the design remains feasible enough to develop as a worthwhile proof of concept.

Feasibility

This project has been allotted a budget of $1,000. [p.n.] Although there are avenues available for additional funding, there do not exist products on the market that could directly address our goals even with blank check funding. It is worth noting that many equal and more advanced DIY projects have achieved success on smaller budgets.

The project can be broken down into four stages. 1) Determine necessary equipment to assemble a quad-copter drone with an attached camera. 2) Develop long range object tracking software for stationary targets. 3) Develop long range object tracking software for moving targets. 4) Develop and attach the magnet capturing system. 5) Accommodate object tracking and automated capture for stationary targets. 6) Develop tracking and capture of moving targets.

1) In order to allow for ample time to tackle the advances in research put forth by our project, it is vital to minimize the amount of time dedicated to "reinventing the wheel". With this in mind, the minimal quad-copter style frame is justified rather as opposed to investing in the more difficult to control (although more steady) hex or octo-copter designs. Additionally, by using a frame kit time can be saved by avoiding the difficult build and tuning process inherent to a custom frame. Similarly, the choice of the Pixy CMUcam5 for our camera system allows all object detection to be automated. This not only frees up time for the software development team -- allowing them to focus on other goals -- but it also justifies the use of the Raspberry Pi 3b -- which has a less complex set of barriers than the more powerful SOCs on the market.

2) The data being output from the Pixy should allow for object identification and location. Determining motor commands in order to move toward an identified object is straightforward in a low-variable environment, however the movement of our anti-drone and the frame size of the Pixy (risking the visual loss of the target) pose significant issues. This will likely need to be accommodated by slow movements and a mobile camera.

3) The chief concerns for the magnetic system are the weight that it will add to the drone and issues that EMF interference might cause. A Faraday cage might be able to offset the EMF interference, however time intensive tests must be performed in order to determine its viability.

4) Acquisition of the target must be performed in a way that does not damage the anti-drone, and does not cause an irreconcilable weight increase.

5) Capture poses issues with kinematics. Movements must be made much more precise in order to preserve downward visuals of the target drone.

6) The processes described above are made significantly more challenging due to both objects being in movement. Developing a successful mobile tracking algorithm -- even without the integration of capture technology -- would be a highly commendable technological achievement.

Lastly, acquiring the FAA required license and executing the above processes should be of no great impediment.

Success criteria

Hardware Design

  • The anti-drone must be capable of flying and must be tuned such that moderate gusts of wind and sudden weight gains do not cause the vehicle to malfunction.
  • A flying time of roughly 10 minutes is to be expected.
Automated Flight
  • The anti-drone should be capable of autonomously following a test drone. No required target acquisition times are being considered for this project, however it is worth noting that a perfected system should be able to identify and capture a target drone under time constraints.
Drone Acquisition
  • The anti-drone should be able to make contact with at least a 5lb target drone. After acquisition, the drone should be able to fly at least 100 yards with the target drone in tow before releasing it.

Cost Estimates

Pixy motion sensor : $69.00

1400 mAh LiPo Battery Pack: $28.99

Carbon Fiber Frame Kit: $98

Flip32 Flight Controller

Connectors and Cables : $50

Supplementary Components (Power cables, connectors, etc.): $86.95

Misc (Shipping, tax, nuts and bolts etc.): $120

Total : $469

Report

All stages of this process will be monitored and developed with the help of Dr. Bahram Shafai.

  • 2016-09-02: Kit drone fully assembled (but un-tuned) with with stage 1 of parts added. Stage 1 parts: Pixy, Raspberry Pi3, Flip32 flight controller, power distribution components.
  • 2016-09-04: Drone Assembly
  • 2016-09-18: Establish WiFi Control and Tuning
  • 2016-09-18: Independent Subsystem API Dev.
  • 2016-09-25: Faraday cage testing.
  • 2016-10-02: Finalize capture Method.
  • 2016-10-09: Stationary Object Tracking.
  • 2016-10-16: Hardware Design Finalization.
  • 2016-11-06: Independent Capture System Working.
  • 2016-11-06: Mobile Object Tracking.
  • 2016-11-27: Mobile Tracking and Acquisition.
  • 2016-12-24: Organize Capstone Report.
  • 2016-12-11: Capstone presentation week
  • Risk Analysis

    The project lends itself to many potential developmental issues.



    These risks can be mitigated as follows :

    • Severe Crash : Maintain a low cost of components. Less than half of the proposed expenditures relate to the on-board systems. Replacing these components is trivial if economical device choices are made.

    • Connectivity Issues : Time spent solving connectivity issues can be offset by choosing devices that are well supported and are known for their ease of development.

    • Unworkable EMF : Should the electromagnet not be a viable solution, other alternatives of capture can be investigated.

    • System Compatibility: Perform preliminary analysis on all additional components to ensure compatibility.

    • Processor Overwork : Using the Pixy to perform image analysis can heavily reduce the workload expected of the Raspberry Pi.

    • Time frame : Weekly assessments of development must be in place to ensure the workload keeps pace. Given our project tackles two new ares (tracking and capture) of drone technology, if the capture portion of the project fails to be developed in time, the group will still have presentable material using the tracking research.

    • Under-budgeting : We have received notice that an additional $200 can likely be made available should our project run over budget.

    Conclusion

    To meet the goals set by our capstone design, not only does the project require well executed engineering, but it also contains a research aspect. The engineering portion is represented by the leveraging of existing tools, whereas the research portion is represented by the development of tracking and capture algorithms. Due to the inherent uncertainty of research, not only is it impossible to accurately predict the time frame for the development process, but it also obfuscates what is realistic.

    Technical difficulties are accentuated by the limited time frame allotted. The goals presented are in the realm of possibility, however budgeting time is of paramount importance. Minimizing time spent on "reinventing the wheel" will allow us to focus on the unique aspects of our project. Even with proper time management however, it seems reasonable to doubt that the full manifestation of tracking and development will be functional before December 4th. Fortunately, assessment of the current achievements in drone technology establishes that an autonomous tracking system for moving objects in three dimensional space can be considered a satisfactory achievement on its own. The team should prioritize the tracking system, and reevaluate at a later date to determine if time allows to develop and integrate the capture mechanisms.

    Peer review

    Oliver is writing a feasibility study for developing an anti-drone system in order to combat the speedy rise of commercial drones because of the percieved risks to safety and security, and also the slowness of regulation to adapt to technology.

    So firstly, I have to hand it to the author and say that this is a really cool idea. His preliminary document mentioned that he has worked with this as part of his capstone, and I think it lends itself really well to the genre of the Feasibility Study. He mentioned that he wanted to avoid being redundant in the document, I definitely understand that because it is easy to do so here. Oliver does a really good job avoiding this and it makes the document fun to read, which feasibility studies are often not. I noted a few things I thought were discrepancies in the table of contents, but otherwise the present content matches the genre very well, at least from my understanding of it.

    That being said I think this specific feasibility study would benefit greatly from a risk analysis chart and an image/design of the proposed system. I think detailing what you believe the final result may look like, even if you don't have the full picture yet, would help support the "pick-up and read" idea of feasibility studies. It would support the simplicity of the document, and as you know everyone loves pictures.

    Oliver asked for a critique of his use of "pre_req_ana and succ_crit", but I think they are being used very appropriately. I think he avoids being redundant where it is very easy to do and successfully separated the paradigm of thinking between the two. The "What will we have to do" vs "what will make / break this project" My one thought might be to include more regulatory thoughts relating to the permitting of the anti-drone device and how you might run into legal trouble, but that could also be included in a risk analysis table.

    Instructor Note

    I really like this feasibility report, especially for how is responds to a very real exigence/rhetorical situation. As a result, your pages are very detailed and demonstrate a thorough understanding of the project and assessment of salient aspects of development. Really nice work here.