Subsystem Overview
Rescue package drop subsystem is responsible for the following tasks:
(1) Rescue location Estimation: Estimating the likely locations for rescue based on the outputs of the signature detection and analysis subsystem
(2) Package drop Mechanism: Delivering a rescue package at the rescue location chosen from reported rescue locations. Due to payload limitations, our system has the capability to deliver a rescue package to only one location in one flight.
Previously, we were also thinking of using a separate power distribution system to power different components and had designed a PCB in Fall 2016. But, given the simplicity of the power requirements of various components, we are powering the components using a Mobile power bank as discussed in (2). The following page describes the power distribution system we had designed, which is not being used now:
(3) Old Power distribution system
SVE Performance Evaluation
| SVE Step | Procedure | Verification Criteria | SVE Performance | SVE Encore Performance |
|---|---|---|---|---|
| 6 | Run software to report GPS coordinates of the probable rescue locations. | The system should be able to report GPS coordinates of the rescue locations with a margin of error of +-8m | We got likely locations within +/- 5m of all signatures just except for the human. Human was reported to be 8.65 m away from actual | We got likely locations within +/- 3m of all the signatures |
| 9 | UAV flies to the provided GPS location, lands, and autonomously drops the package. | Rescue package should be dropped with distance less than 8m from the signature. (assuming the signature has not moved) | Autonomous package drop did not work, but the drone landed 2 m away while testing for a bright mattress, and 9 m away for the human | Autonomously dropped the package 2.3 m away from a human location |
The subsystem could not give its best performance during the SVE as the onboard computer stopped working and we were not able to drop the package autonomously. Also, location estimation for the human did not work well enough.
After some improvements, the subsystem started giving consistently good results. In the SVE Encore, the subsystem worked better than expected, as can be seen from the table.
Conclusions
Strong points:
- The rescue location estimation is pretty robust to false positives in the sense that it separates false positives into separate clusters easily identifiable by the user.
- The rescue location estimation is robust to change in drone’s altitude above ground level (AGL) during the flight.
- The package drop mechanism is simple and easy to control: this prevents any complex issues. Also, grip on the package is not dependent on any electrical system, but rather on structural strength: this ensures we never lose grip on the package even if other systems fail.
Weak points:
- The subsystem is highly dependent on proper synchronization between camera recording and flight data and we do not have complete control over this synchronization. The maximum extent to which we have control over this synchronization is that we can sync the camera time with a phone’s before every flight. We have noticed some lag between flight data and camera recording in some flights and it has the potential to affect the subsystem’s performance drastically. A potential solution to this problem is to have an onboard clock that can trigger all operations (for pose tracking and camera) to have exact timestamps recorded for each of the systems.
- The GPS location estimation assumes while estimating location of a signature from an individual frame that the area the camera’s field of view covers at any time instance is a horizontal flat plane. This assumption can degrade the subsystem’s performance in regions with a lot of terrain change.
Subsystem Testing
Testing of this subsystem was done in four phases:
Phase 1: Testing the reliability of package drop mechanism
Rigorous testing was done to ensure that the mechanism worked, as required. A package weighing ~160 g and dimensions 10cm x 10 cm was made for this testing. A lot of in-flight testing and ‘attach/release’ testing was done to ensure reliability of the mechanism.
Phase 2: Testing GPS location estimation for individual frames
In this phase, we took individual frames from the videos and tried to estimate the GPS locations based on the pixel location of the signatures in the images. We did this on frames from videos for different flights and made improvements.
Phase 3: Testing GPS location estimation clustering
In this phase, we took flights with the signatures set up in the same way as our Spring Validation Experiment (SVE). We kept human, bright and hot signatures in a 50m x 50m area and obtained the ground truth GPS locations by placing the drone at the locations of these signatures and taking multiple GPS readings from the drone’s GPS. An average of the readings for each location was taken as the ground truth.
We conducted numerous flights, collected the data, and ran the GPS location estimation algorithm to obtain the likely rescue locations. Then, we compared the obtained rescue locations with the ground truth to validate the correctness of the algorithm. The algorithm was tested on about 25 flights over a period of one month with continuous improvements to make it more robust.
Phase 4: Testing the complete autonomous package drop
This phase was very similar to Phase 3, with just an addition of the part of launching a rescue mission after getting the likely rescue locations. Given that the main part, the GPS location estimation had been rigorously tested during Phase 3, we did the complete testing for only 10 flights and got consistently good results.