Distributed UFO Mobile Detection, Analysis, Identification and Reporting Platform

From Razing-Wiki

The Distributed UFO Mobile Detection, Analysis, Identification and Reporting Platform (aka Project UFOD Beeblebrox, UFO@HOME, SETI-On Earth, & SETI-Around Earth) is an idea I had while contemplating how to rapidly deploy people to corroborate and investigate sightings. This was discussed at some length in this ATS thread. The problems are two-fold, either:

1. deploy equipment evenly throughout the entire world to monitor for aberrant activity.
2. employ people in every city, state, county and country to investigate reports as soon they're called in.

Obviously,

1. is not only ridiculously expensive it would require, by some work of magic, all countries to work together to collaborate and share data on all events occurring in their territorial airspace.
2. is also impossibly expensive and even with the best training and response times investigators would inevitably get to the location too late to record the event while it's ongoing. So again, more posthumous data.

Looking at this I realized the best compromise for (2) was to create a mobile software application that pulls in as much information as possible from a hand-held device's built-in sensors (GPS, video, camera shots, angle of inclination, etc) and then broadcasts the sighting to other people in the vicinity to have them corroborate the visual.

This solves the cost, territorial and timing issues. The only problem is not all hand-helds have the same capabilities. At present the iPhone has the best sensory features (GPS, accelerometer, 2 megapixel camera). In my mind it's easier to design an application and remove features than it is to add. So the iPhone will be the initial target platform.

Contents 1 Goals 2 Long-term roadmap 3 High level plan 4 Getting people to download it 4.1 Marketing 4.2 Fun Factor 4.2.1 Texture 4.2.2 Functionally fun 5 The Trust Issue 5.1 The Rod 5.2 The Carrot 6 Technical Overview 6.1 Base Software Packages 7 Cost 8 Feature List 9 Notes 10 References 11 Further Reading 12 External Links

Goals

1. Get as many people to experience UFOs first-hand. My research suggests people are overwhelmingly convinced of the phenomenon when they have a personal encounter. This software helps provide that experience by encouraging people in the vicinity of a UFO report to simply look out their windows to bear witness. (psychological / sociological test: in how many cases does a simple observation change a persons UFO position?)
2. Give professional reporters access to up-to-the-second reports of UFOs. One of the big goals of this project is to get an organization like CNN to send a camera crew to record one of these objects live, up-close and personal. (psychological / sociological test: would additional reports from the MSM increase, decrease or have no effect on public interest in the subject and this project? ).
3. More detailed reports. By getting more people to sightings we get additional viewing angles, more corroborating independent first-hand reports, and if a professional camera crew is in the area validation from a trusted news source.
4. Quicker response times from qualified investigators. One of the biggest challenges facing ufology is posthumous data. This type of application reduces the overall time it takes for an authoritative investigative body to jump in to action. Rather than the observer having to record the event and then figure out who to contact (i.e./ the police, the Airforce, and days later getting forwarded to MUFON). Instead, with a handheld UFO reporting platform, the person simply records the data in the application which then does the legwork of contacting the appropriate orgs. Every second counts with a UFO sighting.

Long-term roadmap

Following iPhone development I'll focus on platforms, first, based on versatility of sensory equipment and, second, on market share. A quick analysis of current market statistics^[1] suggests I'll focus next on the:

1. RIM BlackBerry Storm
2. Palm PRE

I'd like to make a generic BREW version of the client so the project can benefit from the rest of the mobile market. Unfortunately this will likely translate in to low-resolution pictures. Also lack of GPS data and user-event signaling will reduce the quality of how these users participate in the project.

High level plan

The high level plan is to have the application record the Where, Why, What, When, Who, and How.

The program can easily figure out the Where with the built-in GPS. For the older iPhones I'll probably build in a mechanism that allows the user to narrow down where they were inside the triangulated diameter. So for example the person could pinch the Google Maps area to scroll in and then click on the spot where they believe they had the sighting.

The What can be answered by checking the accelerometer to find angle of inclination. Based off that and the GPS data (ie/ GPS compass) I can get a basic fix of where the object would be relative to the viewer or on the older iPhones use movement between cell-towers or sun-dial techniques to calculate azimuthal position. Then cross referencing that with a secondary or tertiary pictures from different locations I can triangulate angular size (assuming the person includes some form of fore-ground object) and elevation. Based off that data I could then cross-reference flight record, astronomical, and meteorological databases to automatically rule out obvious / common sightings like Venus / Jupiter, etc.

When receiving numerous corroborating pictures from different locations it would set an administrative flag notifying someone internal to the project to call the local airfields to request radar data.

Each report would then be stored in the database with temperature, dew point, relative humidity, surface and upper level winds, (if possible) released weather balloons, etc.

The When is also easy. Immediately when the person takes the picture it will record and encode location / time. Also when the message is pushed to the database it will encode the time from that as well.

The Who aspect is a little more sensitive. Not everyone wants to supply all their personally identifiable data. The goal is to get this in as many hands as possible. So I'm going to be lenient about how much information a person needs to supply. What I will require is that the person at least have their iPhone number included with their submission. The number will not be exposed to anyone unless the person who sent it authorizes its release. If the person chooses to include additional details it'll help to improve the general trustworthiness of the persons submission.

The Why / How will simply be a text / voice description of the context / circumstances leading up to the picture. The person viewing the object might say / type, "I was driving down interstate 405 and I saw the object fly over the highway and then suck up a cow from the pasture on old McDuffy's farm!" That text description would then be sent with the picture, location, time, and contact details (if the person chooses to release that information) to all other users in the area. This "Why / How" description would allow other users receiving the notification to determine if it's worth their time and effort to travel to the location of the sighting.

Getting people to download it

The first problem to deal with is getting people to opt-in. How is this solved? Do what businesses do, market it. With the iPhones the software could easily be designed to "push" an alert to the users phone. The "Wow" part would come in the form of an applet that maps the alert through to Google Earth, immediately pin-pointing the persons location and showing the quickest path to the UFO. Somewhat similar to ufomaps.com.

Marketing

I'll need people that know how to attract attention through viral marketing strategies that can also come up with a time-line to release information about the project to news syndication sites like Digg, Clipmarks, and Slashdot to name a few. Really I need to think of this project like a startup business. The goal here is to sell the idea to the public. That's no short order, especially seeing as how the idea is to "hunt down and track UFOs." It's absolutely critical that anyone who works on this project keeps that idea in focus 100% of the time. If the project gets too bogged down in its own "seriousness" it'll lose the public's attention. Then the project is already doomed.

Fun Factor

Other mechanisms to make it fun ...

Texture

Pitch it as an adventure.

Hell even mock the "crazy UFO nutzos." When the phone receives an alert print, "Crazy UFO junkie WizBangTinMan reported a UFO a mile away from your current location. Do you dare go see the crazy UFO man in his natural habitat?!" Sensationalize it to the point where the average joe gets involved, perhaps, at first to poke fun, with the hope that the sightings will expose the situation for what it is, something very real.

Functionally fun

The idea Adrian had was very astute. Shazam, the iPhone application that can identify a song by listening to a 15 second clip, isn't just useful it's entertaining. Beeblebrox can satisfy a similar need. If a person sees something in the sky it can attempt to guess at what it is and help the person narrow it down.

The Trust Issue

If the system has chinks people will lose interest, become disillusioned, and move on to the next fad. Think of this like BitTorrent for UFOs, everyone participates, but for it to work trust has to be transparently obvious.

The Rod

Once the project starts to make waves a problem will emerge - pranksters and con men. The best way I can think to deal with this is filter by sheer number of submissions. If there's a situation like the December 31, 1982 Hudson Valley sighting, with 100's of people witnessing the event, the volume of unique users all reporting from roughly the same location would act as a barometer to the truthfulness of each of the individual reports.

Tech note: A distance of a couple feet probably indicates some sort of familial or personal relationship. Separate reports 5280 ft apart likely suggest the absence of a relationship. I can probably fit this to an exponential function to provide a "relationship"-likeliness curve. For quick grouping however any report over 200 ft away from another device will be considered a unique independent observation.

Another obvious mechanism that would help validate the authenticity of a report - have the person take a snapshot of the UFO with their 2.0 megapixel iPhone camera. Numerous shots being preferable. Perhaps I'll even enable a video mode? The iPhone can capture at 15 FPS, which isn't terrible.

Standard "trust" measures could also be employed. Perhaps implementing a system where a person submits themselves to a web service that aggregates "karma" across numerous websites. So if the person has a Slashdot account they could log in through the "karma-rater" and it would measure number of posts and the persons overall rating. What if the person doesn't bother? Well then that's karma against them.

If the person wants to be taken seriously they should have to identify themselves in some manner where their integrity is on the line, even if it is only in some small virtual way.

The Carrot

On the other hand why not use the carrot as well the stick? I say reward first responders when an audience corroborates the event. This is tricky though. How do outsiders know that the people aren't acting in concert to defraud the system?

There are a lot of half-measures that could be taken, but all of them ultimately fail to establish trust. The best way I can think to do this is to use a semi-trusted third party like professional reporters. If a NY times writer corroborates a sighting, he's putting a lot more on the line then Billy Bob the farmer. It's still abusable, yes, but if the reward is small enough, say a $1000 bucks, a NY Times writer isn't going to potentially sacrifice his career and reputation on what in the grand scheme of things amounts to nothing.

This system actually works for any person of high-public standing. The point is to measure how much an individual has to gain as well as what they stand to lose. If the person stands to lose more than they gain, it's a good indicator the person is telling the truth. In this instance a panel could be setup to determine if these variables line-up and then dispense the funds as appropriate.

Technical Overview

Base Software Packages

One thing I'd love to do is contact various iPhone developers that have developed applications like:

1. Starmaps (for a basic star / planet / meteor map)
2. Cycorder (to do some basic video)
3. Shazam (might be possible to try to identify the make of a plane / helicopter by noise)
4. Weather (to pull in meteorological data)
5. Night Camera (for cleaning up night shots)

To see if I can use some of their mechanisms for this particular application.

Cost

To properly test this system I'll need an additional 5 iPhones (3 x 3G units & 2 x 2G ) along with some other units to test platform compatibility on the RIM BlackBerry Storm, the Palm PRE, and generic cellphones that support Brew. I also suspect I'll need additional server hardware to support a full roll-out.

1700 = C_iPhone = (200 + (300*2)) + (300*3)

2975 = C_iPhonesService = ((6*70*5)) + ((175*5)))

6000 = C_otherPhones

7500 = C_phoneServiceForOtherPhones = (30*60)*5

2000 = C_server

20175 = C_UFOApp = C_iPhone + C_iPhoneService + C_otherPhones + C_phoneServiceForOtherPhones + c_Server

Seeing as how this will take me about a year to develop and my going rate is $50/hr the true total is closer to:

104400 = C_TimeCost = ((50*40) * 52)

$124,175 = C_Total = C_UFOApp + C_TimeCost

Feature List

1. Impl. generic UI framework
2. Impl. compass heading
   1. Using GPS
   2. User selected heading based on sun-dial
   3. Transpose from sun to object
   4. Star ident / moon
3. Impl. accurate elevation detection from horizon.
4. Impl. identification of planes
5. Impl. identification of low magnitude planets / stars
6. Impl. on device image analysis accounting for birds, helicopters, blimps
7. Impl. location services contacting other observers
8. Network data from phones to back-end (MUFON?)
9. Work on BOINC, in-depth analysis
10. Work on Mechanical Turk component
11. Duplicate software for other devices:
    1. Palm PRE
    2. Blackberry
    3. BREW
    4. Webcams
    5. Security systems
    6. Radar devices
    7. etc

Notes

References

Further Reading

External Links