gSwoop 2.0

[raymod2 1]

I've been doing a lot of work on gSwoop during the off season and starting with version 2.0 (now available at gswoop.com) there is a GUI interface for both Windows and Mac OS. Now you can simply drag-and-drop your swoop GPS file into the application window and your metrics and plots will be instantly displayed. You can also select your gate and launch Google Earth (to get a 3D view of your swoop) directly from the GUI.

The console version is still present and it works the same as before for those of you who are more comfortable at the command line.

[raymod2 1]

Here is the gate location for meet #2 of the FLCPA in Z-Hills (March 13, 2015).

[michalm21 0]

Just wanted to say that this looks fantastic. Once I get my flysight, I will buy it!

[raymod2 1]

One of the coolest features of gSwoop is automatic detection of speed carve runs and measurement of your speed carve times. These times can be very accurate (within 2% to 3% error) but gSwoop needs a good gate location to achieve that accuracy.

Gate location is performed by walking counterclockwise around the swoop pond and stopping at five points:

A = in front of the entry gate (standing in distance course)
B = left of the entry gate
C = behind the entry gate (looking through gate at distance course)
D = right of the entry gate
A = in front of the entry gate (standing in distance course)

gSwoop determines the position of the entry gate very precisely by finding the intersection of line AC with line BD. The orientation of the entry gate (which direction it faces) is a little harder to determine. The problem is that lines AC and BD are not necessarily perpendicular. In Z-Hills, for example, they are off by about 4.5 degrees.

For distance runs you want to use line AC to determine gate orientation and that is the default behavior of gSwoop.

For speed runs the default option will not get you the best results. The reason is that gSwoop uses the position and orientation of the entry gate to mathematically determine the positions and orientations of all other gates (most importantly, the exit gate). But a small error in the orientation of the entry gate will result in a large error in the calculated position of the exit gate!

To address this problem gSwoop uses one of two approaches. They both require the user to specify a carving course (by checking the box for "carving course" in the GUI or passing the -c option when processing the gate file in the CLI).

The first approach is to use line BD to determine the orientation of the entry gate. This works pretty well because it is the line that was probably used when setting up the speed course. However, it is vulnerable to small errors when locating points B and D. For instance, a common source of error here is when the gate markers (which are floating in the water) get pushed around by the wind.

The second approach (new in gSwoop v2.03) is to check for an additional point in the gate location file that will be present if the user walks to point E (the center of the exit gate) before turning off the GPS (the user locates points A,B,C,D,A,E in that order). This works best because it gets the location of the exit gate directly. Using Z-Hills as an example, the error in the exit gate location was decreased from 5.2 meters to 0.2 meters using this method.

Below are some comparisons of speed carve times measured by GPS versus electronic gate sensors. All data was collected from competition rounds during the 2015 FLCPA meet #2 in Z-Hills. The gate location attached to the previous post was used with the "carving course" option in gSwoop v2.03.

example 1: gps = 4.19, sensor = 4.25, error = -0.06 (1.4%)
example 2: gps = 3.44, sensor = 3.44, error = 0.00 (0.0%)
example 3: gps = 5.13, sensor = 5.01, error = 0.12 (2.4%)
example 4: gps = 3.04, sensor = 3.13, error = -0.09 (2.9%)

[raymod2 1]

gSwoop 2.04 is up on the website. This includes a major rewrite of the plotting code. I'm no longer using gnuplot and coded everything using the Cairo library. This results in a significant performance improvement. I measured a 2X speedup in the CLI and the GUI is noticeably faster. As a bonus the package size is down about 25% since I was able to remove some dependencies.

More things to come!

[raymod2 1]

gSwoop 2.05 has been released. The biggest change is the addition of zoom controls for the plots. Use CTRL-plus and CTRL-minus or open the View menu and select the zoom level there.

[raymod2 1]

gSwoop 2.06 is now available on the website. Major changes are:

1) The "carving course" and "reverse gate" options have been removed because gSwoop now determines these options automatically based on analysis of the swoop.

2) You can now open multiple swoop files simultaneously and scroll between them in the UI.

3) You can now overlay plots from multiple swoops to more easily compare them.

4) The acceleration plot has been removed (it did not provide meaningful data due to filtering in the GPS). It has been replaced with a plot of GPS accuracy.

The ability to overlay plots is an incredibly useful feature when comparing swoops. Attached is an example from an overhead plot.

[tomireland 0]

Hi,

On this kind of overview are you able to show if any were a vertical bust, e.g these show in red?

thanks

[raymod2 1]

Do you mean a vertical extension on the entry gate? The GPS data isn't accurate enough to determine that. Under the best conditions with a properly calibrated Flysight and a good gate location you can still expect a few feet of error. Also, keep in mind that the GPS is usually mounted on your helmet but a vertical extension is judged by the lowest part of your body. However, if you look at the side view plot you can get a good idea about how close you were to missing the entry gate.

When overlaying multiple plots in the overhead view the red line is the currently selected swoop and the grey lines are the overlays (chosen using the checkbox to the left of each swoop filename).

[tomireland 0]

yeh that was what i meant.

Not a problem, its a good looking bit of kit!

[raymod2 1]

Attached are my competition distance runs from the 2014 Nationals in Z-Hills last year. I scored two runs (plotted in grey) which means I touched water before passing the entry gate. The third run (plotted in red) I did not score. I got the default result which means I did not touch water but I did fly below the 5 foot entry gate (barely).

As you can see from the side view plots you can get a good idea whether you scored the gate but if it is close it is hard to tell.

[raymod2 1]

gSwoop 2.07 is now available at gswoop.com. The newest feature is a time scale (enabled via "View->Time scale"). When using the time scale synchronized markers will be drawn on every plot. When you move one marker all the other markers will move with it. The time scale also enables real-time playback of the swoop. This works with overlays so that you can compare two or more swoops during playback.

There have also been improvements to the heading plot. The plot no longer wraps at 0 and 360 degrees (which made it difficult to interpret). Interpolated regions (during snaps) are drawn with dashed lines to make them easier to identify.

[raymod2 1]

Here are the distance/accuracy and speed gates in Raeford, NC for use with gSwoop.

[danielcroft 2]

Command+Q | gSwoop application menu and "Quit gSwoop" | right clicking the application icon and clicking "Quit"

None of these close the application.

[raymod2 1]

1) The keyboard accelerator to quit the application is Ctrl+Q, not Cmd+Q. The accelerator is displayed next to the "Exit" option in the "File" menu.

2) The gSwoop GUI is not currently aware of the application menu on OS X (that is the menu at the top of the screen that corresponds to whichever window is in focus). I'll look into what it would take to handle actions from there.

3) I'm guessing this causes an event to be sent to the application and I will just need to add the logic to handle it. This should be pretty easy to fix.

Thanks for the bug report.

[danielcroft 2]

Yep, been a computer guy for ~20 years. I figured it out but just wanted to let you know.
Happy to help out.

[raymod2 1]

I've identified a fix that handles all three scenarios. I'll include it in the next release.

[raymod2 1]

Here are some more speed time comparisons taken during FLCPA meet #3 in Raeford over the weekend. The times calculated by gSwoop have been compared to the official scores generated by the gate sensors.

gps = 2.65,  sensor = 2.64,  error =  0.01 (0.4%)

gps = 2.46,  sensor = 2.46,  error =  0.00 (0.0%)

gps = 2.39,  sensor = 2.40,  error = -0.01 (0.4%)

gps = 2.67,  sensor = 2.59,  error =  0.08 (3.1%)

gps = 2.66,  sensor = 2.63,  error =  0.03 (1.1%)

[raymod2 1]

gSwoop 2.08 has been uploaded to the website. Changes include the following:

- improved gate location
- support for older OS X versions (back to 10.7 "Lion")
- fix for OS X issues mentioned above
- fix for bug triggered by German locale
- miscellaneous improvements

[raymod2 1]

gSwoop 2.09 has been uploaded to the website. This is a minor update and includes improvements to the File Chooser Dialog:

- directory icons are fixed and directories are placed at the top of listings
- Recent bookmark is fixed
- Downloads bookmark is fixed on OSX
- default location is the directory of the last file opened

[danielcroft 2]

Thanks for your continued work. :-)

[raymod2 1]

One of the metrics that canopy pilots have been using to evaluate their swoops is the time it takes to transition from vertical flight to horizontal flight (the rollout phase). This can be measured with a video camera but there are advantages to using GPS:

1) ease of use - A video camera requires you to use a stopwatch or to manually step through frames. Your GPS can measure the rollout automatically.

2) accuracy - Determining the start and end of the rollout is not as trivial as it might seem. Using a camera you would typically wait until the canopy is on final heading before starting the stopwatch. But the rollout sometimes starts before that. With GPS you can look at vertical deceleration to more reliably detect the start of the rollout.

3) repeatability - Using a camera there are several sources of human error when measuring the rollout time. With GPS you can use a well defined algorithm that makes comparisons more meaningful.

Starting with gSwoop 2.10 (released yesterday) there have been improvements to the algorithm used to detect the start and end of the rollout. The start is defined as the point where vertical speed begins to monotonically decrease (which occurs near the time of your final snap). The end is defined as 1 meter above where level flight is achieved. The 1 meter offset is necessary to isolate the rollout from the slightly sinking phase that can go on for quite some time even after successfully scoring the entry gate. It is a somewhat arbitrary offset but when applied consistently it is possible to make meaningful comparisons between swoops.

Here is an example from my first round of speed at Nationals this year:

exited airplane:      6396 ft AGL

initiated turn:       1600 ft AGL,  810 ft back, -382 ft offset

max vertical speed:    383 ft AGL,  264 ft back,  192 ft offset (96.3 mph)

started rollout:       315 ft AGL,  270 ft back,  179 ft offset (91.7 mph)

finished rollout:       13 ft AGL,   40 ft back,   23 ft offset

max total speed:       723 ft AGL,  297 ft back,  116 ft offset (100.4 mph)

max horizontal speed:   30 ft AGL,  101 ft back,   44 ft offset (80.2 mph)


degrees of rotation:       652 deg (right-hand)

time to execute turn:    13.90 sec

time during rollout:      3.35 sec

time aloft during swoop:  7.65 sec


entry gate speed:      73.7 mph

distance to stop:      270 ft

touchdown estimate:    270 ft (2.0 mph)

speed carve time:      2.56 sec (47.8 mph)

During this run I started my rollout at 315 feet AGL and it took 3.35 seconds to complete. I was 270 feet behind the gate at the start of the rollout (324 feet away when you consider the offset) and 40 feet back at the finish. You can see a video of this run here (thanks to Keith Creedy for the footage):

https://www.dropbox.com/sh/ecqp7ywqqa9ve2d/AAAxrlUUavJIN7mw6udaC4tKa/Speed%20Round%201/Speed_Rd_1_Shot16_kc.mp4?dl=0

[danielcroft 2]

Other than "swoop better", is there something I can do about the "could not detect pattern entry" error?

[raymod2 1]

Hi, Daniel. The error message "could not detect pattern entry" means that gSwoop could not detect a point in the GPS track that is above 2500 feet. If you see this error it usually means that you did not get a good GPS track. Did you turn on the GPS at least 30 seconds before boarding the plane?

By the way, if you processed the GPS file from the command line it will leave a kml file in the current directory when it encounters an error like this. You can look at the kml file in Google Earth to see if the swoop was captured by the GPS. You can also send me your CSV file and I can take a look.

[danielcroft 2]

Thanks for the response mate, appreciate it. What happened is that I turned the flysight on at about 10k (which is what I've been doing and it's been fine, I do terminal jumps btw), this time I was Chicago as opposed to SoCal so it probably took longer to get a solid lock and didn't get above 2.5k. I'll look up how to process on the command line, didn't realize that was an alternative.
I'm happy to send the file if you want to see it anyway?

edit: actually, looking at the KML output, it seems as though the readings are all a little low since I totally didn't end my swoop where it thinks I did. Also, flysightviewer says the track started at 2480 so... close but no cigar.