Flysight vs GoPro

[jallison 8]

I recently managed to extract GPS data from my GoPro hero 7 footage. I was in the market for a Flysight unit but I think I might reconsider now.

The (crappy) GoPro Quik app used to tell me my footage hadn't recorded any GPS data for lack of satellite fixes. That doesn't seem to be true as there actually is data attached to the mp4 files.

1. Use https://tailorandwayne.com/gopro-telemetry-extractor/ to extract data from the mp4 file
2. Export to .gpx file
3. Import in baseline.ws, or Flysight viewer, or whatever gpx interpreter app

Now for the nerdy part. I've never owned a Flysight unit, nor analyzed any data coming from one. But according to the specs, it seems to output data at a ~5Hz rate, whereas the GoPro GPS chip writes ~18Hz worth of data. That's more than 3 times the rate of a Flysight.

There seem to be a few outliers here and there, but overall I'm pretty impressed with the GoPro's GPS feature. I wouldn't have bet on this level of accuracy. Especially coming from a device that freezes out from time to time, or chews up a whole battery while powered off.

Here are a few acro lines (Funk 3):

• https://baseline.ws/tracks/d91e5f18-fc01-4b7f-9a6b-581dfd8ae8ea
• https://baseline.ws/tracks/87a4aed6-ed70-4605-8fc6-a604ad2d29e9
• https://baseline.ws/tracks/2ca462ea-6173-4610-b5c0-8e20be9c62e1

And a Freak 2 (heli skydive) line over the swiss Alps:

• https://baseline.ws/tracks/8afcce5a-ef26-48e4-bf69-ebef01ccd157

 

Flysight nerdy users: what's your take on this? Does the data from my GoPro seem reliable? Are there too many outliers compared to a Flysight?

Edited May 2, 2019 by jallison

[verticalflyer 11]

Well it seems to work. However the reason I use a flysight are: 

• Small - sits unobtrusively on back of helmet
• Charge - single charge lasts all day no problem
• Automated viewer is very easy to use and already built- plug and play
• Performance feedback - Realtime in ear comms to either navigate or improve performance or give altitude keys or all three
• The additional hz data for me is not worth it I can see meter by meter already! I don't need cm by cm

 

[meat.missile 25]

The 18Hz from the GoPro just isn't needed when evaluating wing suit jumps as the human brain cannot react that fast to anything. I don't know this for a fact bus I suspect the 5hz was picked because it is close to human reaction times. The real advantage to the flysight is the realtime audio feedback. When training speed or distance you can hear how the suit react to changes in your body position. That feedback is more important than a graph on a computer. 

[skow 6]

New flysights have 10Hz rate (and some old ones after software update)

For me it's just so much easier to use flysight data as you can just drag and drop it to software straight from the device. Also the battery lasts for super long

Edited May 3, 2019 by skow

[jallison 8]

Thanks for the input. 

I'll take 18Hz over 5-10 anytime, more data can't hurt in this context.
Ease of use: I've made a script on OS X - drag and drop mp4 file onto it -> outputs a .gpx -> ready to import in any analysis website or software

No audio feedback: good point, I'll have to try this out when I can get my hands on a flysight!

[dgingold 2]

Any way you might upload that script? would be cool to compare data head to head with a flysight. 

[jallison 8]

Sure thing, I'll add it to the original post. It's an automator script, so OS X only, and you'll need ffmpeg installed on your machine for it to work.

It does exactly the same thing as this website :  https://tailorandwayne.com/gopro-telemetry-extractor/

extractgpx.zip

Edited May 6, 2019 by jallison
Ah. Looks like I can't edit the original message anymore... File attached here instead.

[20kN 93]

20 hours ago, jallison said:

Thanks for the input. 

I'll take 18Hz over 5-10 anytime, more data can't hurt in this context.

Actually it can. Pinging the GPS modem more often consumes more battery. The Flysight will have less operational time when pinging the sats at 10 Hz vs 5 Hz, as will any other device.

[DanielRistow 3]

Knowing not much on the technical sides of these things besides how to turn on my FlySight and how to check how many satellites are connected for each point it records, I get that this records more points but can anyone confirm if the points are as accurate as a FlySight? I’ve seen different speeds and glide come out of a GoPro than a FlySight on the same jump. Obviously if the GoPro is more accurate or the same then it’s better with more points but if it’s just more points and less accurate then it will become dangerous with analyzing BASE exits. 

[meat.missile 25]

10 hours ago, DanielRistow said:

Knowing not much on the technical sides of these things besides how to turn on my FlySight and how to check how many satellites are connected for each point it records, I get that this records more points but can anyone confirm if the points are as accurate as a FlySight? I’ve seen different speeds and glide come out of a GoPro than a FlySight on the same jump. Obviously if the GoPro is more accurate or the same then it’s better with more points but if it’s just more points and less accurate then it will become dangerous with analyzing BASE exits. 

Found this on GoPro's website linked to by a GoPro support person. 

~400 Hz 3-axis gyro readings
~200 Hz 3-axis accelerometer readings
~18 Hz GPS position (lat/lon/alt/spd)
1 Hz GPS timestamps
1 Hz GPS accuracy (cm) and fix (2d/3d)
1 Hz temperature of camera

[crwper 7]

It's been a while since I checked the forums, but I came across this post and thought I'd add a little more information. The latest FlySight hardware uses the NEO-M8Q module, which supports 10 Hz update while tracking both GPS and GLONASS satellites, or 18 Hz while tracking a single GNSS constellation. There's nothing magical about 18 Hz, so I think the GoPro is probably also using a u-blox M8 chip.

The main limitation with the latest FlySight hardware is processor speed. I haven't checked to see if we can run at 18 Hz, but it might be possible, especially if we disable audio output.

However, I would say that we've seen some really good results with GPS + GLONASS tracking. Roughly speaking, this doubles the number of satellites in view, which makes the fix a little more accurate and a lot more robust. If I had to choose, I would probably go with 10 Hz and two constellations as opposed to 18 Hz and GPS only. My guess is that the GoPro is using GPS only at 18 Hz. This could be confirmed by looking at the number of satellites used in the fix (assuming this is reported). If you see a number around 8-12, it's likely GPS only. If you see a number more like 12-18, it's probably tracking GPS and GLONASS.

There is one other thing I would pay close attention to. One of the things I like most about the u-blox module inside the FlySight is that it reports 3D velocity, so there is no need to calculate velocity from differences in position (which is notoriously error prone). This may very well be the same interface that the GoPro uses, but it's very common for consumer GPS units to use the NMEA interface instead. This is an old interface which doesn't have native support for 3D velocity, which means vertical speed needs to be calculated from differences in elevation. You can probably tell which method GoPro is using by looking specifically at vertical speed. How clean are the measurements? If you hold the GoPro in your hand and wave it over your head, up and down, etc., do you see clean velocity measurements on all three axes (even though position may not reflect that motion)?

[jallison 8]

36 minutes ago, crwper said:

My guess is that the GoPro is using GPS only at 18 Hz. This could be confirmed by looking at the number of satellites used in the fix (assuming this is reported). If you see a number around 8-12, it's likely GPS only. If you see a number more like 12-18, it's probably tracking GPS and GLONASS.

Spot on. Thank you for the simple explanation on different constellations. The gps fix is nowhere near 12-18, I've consistently had a value of 3 (best case scenario). 

37 minutes ago, crwper said:

There is one other thing I would pay close attention to. One of the things I like most about the u-blox module inside the FlySight is that it reports 3D velocity, so there is no need to calculate velocity from differences in position (which is notoriously error prone).

Again, you're absolutely right. There's no 3D velocity in the GoPro's data so it has to be calculated from position afterwards. Far from ideal.

Thank you so much for clarifying those points, that's exactly the kind of precision I was hoping for. 

[crwper 7]

7 hours ago, jallison said:

Spot on. Thank you for the simple explanation on different constellations. The gps fix is nowhere near 12-18, I've consistently had a value of 3 (best case scenario).

It sounds like you might be looking at the <sat> field in the GPX file, which actually gives the fix time--i.e., 2D or 3D--so it typically has a value of 2 or 3. The minimum number of satellites required for a GNSS fix is 4, so if you're seeing a value of 3, it's definitely not the number of satellites used in the fix.

Can you post an example of the GPX data produced by the GoPro? It looks like the <sat> field in the GPX file would give the number of satellites used in the fix.

[jallison 8]

I'm realizing as I read you that I'm relying on my GPX data without questioning its origin. Here's how I proceeded: 

1. Extracted raw data from mp4 into a raw file, using ffmpeg :

   ffmpeg -y -i "/path/to/theFile.MP4" -codec copy -map 0:3 -f rawvideo outputFile.bin

2. Used the "gopro2gpx" util from this repo to parse raw data into gpx :
   https://github.com/JuanIrache/gopro-utils

Here's where I was wrong - step 1 preserves all data. Step 2, not so much. I overlooked the fact that it might leave data behind while parsing the binary extract into gpx.

So I'm currently trying out this other util (slower, in JS) : https://github.com/JuanIrache/gopro-telemetry

And... I seem to get a 3D velocity! I get a more thorough output in JSON, I still have to convert it to gpx though. Files attached, work in progress! Also included, GPS data in CSV.

Fun stuff!!

chablais.json

chablais.raw

flares.json

flares.raw

GH010928-gps chablais.csv

GH018648-gps flares.csv

[crwper 7]

18 hours ago, jallison said:

And... I seem to get a 3D velocity! I get a more thorough output in JSON, I still have to convert it to gpx though. Files attached, work in progress! Also included, GPS data in CSV.

Looking at the JSON file, it does seem to be a direct dump of the GPMF data embedded in the MP4. Here's a collapsed view of what's in the file which shows the headers but not the data itself:

Looking at the "GPS5" key, it seems to include only 5 values:

• latitude
• longitude
• altitude
• 2D speed
• 3D speed

In addition, nested in the GPS5 data, it occasionally includes two more pieces of information:

• "fix" - This seems to be the GNSS fix type (3 for 3D, 2 for 2D, etc.).
• "precision" - If I had to guess, I'd say this is position accuracy in cm.

That's not too bad. There are a couple of things missing compared to FlySight's data:

• Components of 3D velocity. In principle you can recover the vertical component from 3D speed and 2D speed, but there's no way to get north and east speed directly from this data. You would have to go through latitude and longitude, which will likely result in some additional error.
• Components of accuracy. FlySight includes horizontal and vertical position accuracy as well as speed accuracy.
• Number of satellites used in the fix. This can be a useful diagnostic, but there is arguably some overlap with the position accuracy figure reported in the GPMF data.

I suspect at 18 Hz this is GPS only, for the reasons given above, but it may be that if you drop down to 10 Hz the unit will automatically switch over to GPS + GLONASS. Here's the relevant table from the u-blox M8 datasheet:

Assuming their velocity is coming from the same place FlySight's is, I feel like the GoPro data would be just fine for most uses.

[jallison 8]

I figured I should make my own parser to output a CSV similar to that of a Flysight, so here goes : 

https://github.com/j-allison/gopro-to-flysight

 

Before (using data from the util cited above: https://tailorandwayne.com/gopro-telemetry-extractor/) : 

 

After using my parser, based on `gpmf-extract` and `gopro-telemetry` libraries: 

I'm feeling happier with those results; they seem to be way less "smoothed out". Still work in progress. 

(Is it outrageously wrong to calculate N/E velocity components by using lat or long difference over time difference from point A to point B ? )

Edited May 22, 2019 by jallison

[SethInMI 160]

On 5/22/2019 at 8:30 AM, jallison said:

Is it outrageously wrong to calculate N/E velocity components by using lat or long difference over time difference from point A to point B ?

No it makes sense to me. If I understand you correctly, you are using a position displacement vector direction to decompose your velocity scalar. And what is the use of the N/E velocity anyway? your graphs don't break it down, but I guess there are some flysight viewer screens that do?

[platypii 20]

Computing velocity from noisy position data can introduce a fair amount of error. Here is an example. Your true velocity might be constant and actually look like:

 

But GPS will have errors that might make the position look like any of the black dots here, and you can see how much error that can introduce to the velocity if computed using distance / time:

It's possible to smooth this out by adding a Kalman Filter. But a filter will introduce its own errors and create a lag time before it accurately estimates your true velocity.

However, as pointed out by @crwper, GPS actually has the ability to compute position directly, not using position and distance. Instead, many GPS chips can actually use doppler shift from the satellites to directly compute velocity. The accuracy and response time is much better.

It is not clear whether the GoPro uses doppler velocity to compute 2D and 3D speed, but its definitely NOT giving the individual velocity components (vN, vE, vD) which would be nice to have.

Edited May 24, 2019 by platypii

[crwper 7]

As @platypii points out, in general deriving velocity from changes in position is a bad idea. This is known as the method of "finite differences" and is a notoriously error-prone way to calculate derivatives.

That said, you may find this works better than expected with FlySight data (or GoPro data if they are using a similar chipset), since both the position and velocity are outputs of the same Kalman filter--so the smoothing @platypii refers to may already have been done inside the GNSS module.

[crwper 7]

On 5/23/2019 at 7:30 AM, SethInMI said:

And what is the use of the N/E velocity anyway? your graphs don't break it down, but I guess there are some flysight viewer screens that do?

Some of the advanced analysis features in FlySight Viewer use the full 3D velocity vector. For example, you can use this to estimate lift and drag forces. The N/E components are also used to determine wind speed/direction using data from the climb to altitude.

[jallison 8]

Thanks for you help, folks.

I've concluded that no matter the processing, the data will never be nearly as rich coming from a gopro as it is in a Flysight log. At least I tried!

I got myself a Flysight, and I am now very happy with my logs