3 ms·
Correct. It sounds a bit far-out (and it is) but we've proven the feasibility with a testing group of around 300 passengers using a multitude of different phone
by csteubs 5y ago
Correct. It sounds a bit far-out (and it is) but we've proven the feasibility with a testing group of around 300 passengers using a multitude of different phones/altitudes/conditions/routes. GPS works in airplane mode, so we pre-cache target coordinates based on the filed flight plan and alert the passenger to hold the device to the window when overflying the target. The gyroscope is used to provide feedback on phone orientation so we can get as close to nadir as possible, but we're still able to correct for obliques at around 20miles on the horizon using some general inference. Resolution is a function of altitude and device, but upscaling techniques enhance the images even further after they're transmitted.
We've also developed our own sensing device prototype we call "The Box" that's equipped with a much more powerful array of sensors, but the mobile device-sensing approach makes the most sense for a scalable MVP.
- protomikron 5y agoDo you have an example of the final (aerial) imagery result?
- newman8r 5y agoInteresting approach, I can see how that's the easiest path to an MVP.
- Nextgrid 5y agoWhat's the user experience of this and what are the incentives for users to do this? How much are they paid?
- csteubs 5y agoUX on the flight contributor side is currently a low-touch app that accepts the user's flight number and prompts for their seat selection (assuming a commercial flight). We load an image correction profile based on whether the seat is fore or aft of the wing in order to correct for the blur caused by engine exhaust, after which we cache the image task coordinates we anticipate they'll be flying over. We provide a code for free in-flight wifi (actually 2--one for each side of the plane) that can be redeemed after completing a simple calibration task while taxiing or shortly after takeoff. The calibration looks at window opacity, occlusions, and considers atmospheric conditions for each leg of the flight. In order to maximize battery life and prevent user fatigue, we only alert the user to begin recording when they're approaching a task coordinate by referencing the cached coordinate with the current GPS coordinate which is readily available even in Airplane mode. The "workload" for test users so far averages about 5 alerts per flight or 5-10 minutes of "recording", typically shortly after takeoff and prior to landing. We're using Lobe to train an ML model with the image feeds, so we're working on implementing a Captcha-style post-flight survey where a few sample images taken in flight are presented to the user for first-pass labeling. If a user completes this survey, they're rewarded with additional airline miles as a thank you There are plenty of other opportunities to gamify the recording process and we've been taking cues from apps like Waze and OpenStreetMaps to inform some of these potential reward features. Possibilities include revenue sharing, free flights after reaching milestones, travel gear, etc. I remember flying Spirit years ago and they always had a fun way to reward the unlucky souls in the middle seat by putting a sticker on one of the tray tables. The passenger sitting in the "lucky" middle seat got a free round-trip ticket which I've always thought was really cool, so perks like those are top of mind as well. Tl;dr - we're intent on keeping the UX transparent, engaging, and unobtrusive for the recorder--point, shoot, disembark--while rewarding them in kind for their time and effort.