Basejumper.com - archive

One more tech project, then I'll shut up for a while :) I'm working on an Android app that I'm calling DroidSense and it's kind of like a FlySight, but it logs body orientation (if the phone is secured to the body) in addition to location. It saves it as a CSV file on your phone. It's on Google Play fo' free, so check it out if you're interested and let me know if you have any suggestions:

https://play.google.com/...nwstanford.kalmanbox

Do you need to have pressure sensor for that app ?

No, but if your phone happens to have a pressure sensor, then it can record pressure altitude in addition to GPS altitude. This is useful because most Android devices I've tried this on update the GPS data pretty slowly, only about once per second, but the rest of the sensors (including pressure) sample much faster than that.

If you have the altimeter setting from the nearest METAR report, you can also use that to adjust the pressure altitude readings. Making the app do that automatically is on my to-do list.

I just uploaded an update (version 1.3) where I fixed a few typos, added the ability to calibrate the accelerometer, and added the ability to include raw sensor data in the CSV output. I plan to iterate through 1.x version numbers until I get it to a state where it won't change for a while, then I'll call that 2.0. Any suggestions/requests are appreciated.

Something that'd be cool is a GPS logging app that you can leave turned on all day but only logs and actively polls GPS & other sensors when it detects active "flight" motion.

For BASE it'd be fairly easy to use the accelerometer (or barometer) to detect the exit and then immediately start logging GPS at 1hz. After landing it stops recording and switches to low power mode.

For PG/Speedflying it'd be a bit more complicated but is still possible. Once GPS speed is past, say, 12km/h and you're either climbing or sinking it'd just have to check the accelerometer & gyro to see if you're flying (phone moving around) or if you're riding a cable car (phone stationary). Driving a car up/down would be a little tricky, easiest way to detect that would be to poll an API (https://developers.google.com/maps/documentation/elevation/start) and see what your AGL is.

This would be really handy for skydiving, running laps in the Valley, or speedflying with a cablecar when you're doing 20 runs in a day and keep forgetting to cycle your GPS app (or Flysight).

If you're still bored, since you're already logging the accelerometer data if you detect something resembling a crash while in flight mode you can have an emergency contact number that it sends the GPS coords to. I'm available as crash-test dummy for the acc trigger values :)

I found my Flysight hardly got any useful data in the Valley for some reason.
I was jumping the regular exits there and while it seemed to get a signal on the exit points the data was almost always useless, whereas in Norway it usually worked perfectly.
At a guess I'd say that having trees over the exits, relatively short jumps and it just being a valley could make it hard to get good GPS data?

It should still be able to work through those trees but you might need to leave it turned on for longer before jumping so it can get a clear fix. And if you're close to the wall you're cutting off half of the sky and available satellites.

OK, yeah that makes sense.

Cool. I like the suggestions :) The low power mode seems like it should be doable. Maybe I could set it up to record and stop based on triggers that the user specifies. For base jumping, you might specify based on the accelerometer like you were saying and for skydiving you could set it to wake up when it detects pressure altitudes above 11,000ft for phones with a pressure sensor.

Something else I've been thinking about that might be pretty sweet but take a while to make would be an "instant replay" feature where you can replay the data on your phone immediately without having to download it to your computer.

One of the cool things about Android is that even though the software is the same, the hardware varies quite a bit and if a lot of people start using this, we might find out through trial and error that one model of phone is much better for our purposes than another. Some phones have pressure sensors and others don't, for example. Some also use the Russian GLONASS satellites in addition to the original GPS satellites to get a better fix while some don't. The phones I've tried so far (only two) only update the GPS at about 1 Hz but I'm sure there are Android phones that are faster than that. FlySights are $250 right now which seems like a lot. I think I paid less than that for my current phone.

Edit:
Yeah, if you look at Androids on Amazon that are a little older than the brand new models (like a Galaxy S4 or S5), they're almost all cheaper than a FlySight.

Yeah, or have a 1-click upload to something like Doarama (https://doarama.com/view/2171). That'd be pretty cool for instant feedback for tracking, WS, swooping, etc. I wouldn't spend too much time making your own playback interface.

I've looked but haven't found any Android phones that update at over 1hz. But I'm sure there will be one at some point in the future. My money is on Xiaomi or OnePlus putting one in a phone first. The rest of the manufacturers are too worried about saving battery life to risk all the complaints from the 99% of customers that only need 1hz.

I've never seen a phone with GPS refresh rate greater than 1Hz. The other problem is that there is no good place to put the phone where it has a clear view of the sky.

I've found that the best way to get good GPS data into an app is to use a Bluetooth GPS unit mounted on the helmet like a fly sight. SkyPro and BadElf both update at 10Hz and get great signal.

What software are you using?

I have been using the Bad Elf, but I'd love to have some better software for it.

Trying not to hijack the DroidSense thread, but I'm using my own software: BASEline Flight Computer for android.

I'm working on the "deluxe" 6DOF filter that integrates translational motion into the filter and it's looking good. I think I can post it in the next few days. I think the accelerometer can make up for the lower GPS sampling rate because if you get an unexpected GPS measurement after 1 second, it's due to an acceleration, which is what an accelerometer measures. The sweet thing about a Kalman filter is that all the sensors work together.

I also want to make it so that you can adjust the uncertainty of the measurements to tune the filter. Every measurement comes with a big covariance matrix that basically quantifies how much we trust each sensor. If you think having the GPS in your pocket versus on your helmet doubles the uncertainty, you can just double the appropriate value in the covariance matrix.

I think adding Bluetooth support for external GPS devices should be pretty do-able too. I've done it with other sensors over Bluetooth. It would work especially well if these different GPS devices use a standardized protocol so the same piece of code could talk to different units. You could also opt to just use the phone's internal GPS. I want to make it very customizable, but also user-friendly to people who want to just stick with the defaults.

I just uploaded a new version with the "deluxe" 6DOF filter. It uses the accelerometer in addition to the GPS to determine position. I also added the ability to calibrate all three components of the accelerometer because I saw that on my phone, it's necessary. Check it out and you should see that the accelerometer helps fill in the gaps between GPS readings. Before you use it, set an origin latitude and longitude under the settings. This is the point from which your position will be measured in meters. It defaults to 0 degrees lat and long.

I also added the ability to adjust the uncertainty of the sensor measurements under an activity called "Filter Tuning". This is where you can basically tell the app how much confidence you have in each of the measurements. The default standard deviations are values that seem to work well for my phone (an LG Flex2), but play with them if they don't seem to work for your phone.

It'll be a week or two before I have a chance to jump it, but if anyone is jumping sooner than that, I'd be interested to see DroidSense and FlySight data from the same jump for a side-by-side comparison. Hit me up.

Edit:
Another change with this version is that it now saves your settings and calibrations, so if you close the app and open it again, you shouldn't have to re-do any of that.

How much does it actually increase the uncertainty? Is doubling a good approximation? Is there a generally accepted answer? Is there a good way to measure this, like standard deviation from a specified glide angle?

The best way to set the standard deviation for the sensors would be to just do an experiment where the input is constant, you collect a bunch of samples, then use something like Excel to get the standard deviation.

For example, the standard deviations that the accelerometer calibration shows you are probably a good starting point for that sensor.

For the GPS, you could just go outside and keep the phone in the same physical location while you collect 2-3 minutes worth of data. Open it in Excel and see how much the location varies. You could repeat the experiment with and without a clear view of the sky.

It is possible to determine the standard deviation on the device itself, as its running.

The trick is to keep a moving average of the difference between raw sensor data and kalman output. Even as the sensor changes, the mean squared error stays roughly constant. Feed that back into the kalman filter as the standard deviation, and you can automatically calibrate on the fly.

I'll try that and see what the data looks like. You have to calculate the residual between the expected measurement and the actual measurement each time anyways. I could have it output them and see how it compares to the standard deviation I expected.

I just uploaded an update. I fixed a math error I found and the location should converge faster now. I also removed the torque from the state estimation (it wasn't really necessary) and added the conditional recording feature that someone suggested.