Freesteel Blog » Going nowhere with a geologger

Going nowhere with a geologger

Thursday, June 18th, 2015 at 9:31 am Written by:

Here’s one of those great two-hour go-nowhere flights I keep having in places like Llangollen on the days when people with some actual talent were scoring hundreds of miles.

nowhererawgps

The GPS gives a direction and velocity in degrees along with the position. If we calculate the average velocity observed in each degree of the compass, like so:

degreesums = [ [0, 0.0]  for i in range(360)]
for degree, velocity in gpsvelocities:
    if velocity > 1.5:
        ideg = int(degree + 0.5)
        degreesums[ideg][0] += 1
        degreesums[ideg][1] += v
degreehistogram = [ sumv/max(n,1)  for n, sumv in degreesums ]

… and graph it radially as the set of points

pts = [ (sin(radians(d))*r, cos(radians(d))*r)  for d, r in enumerate(degreehistogram) ]

you get the yellow circle which is offset from the centrepoint origin by the wind speed.
gpsdriftdirection

In this case, the deflection (wind vector) was has an inverse bearing of 322 degrees at 4.7m/s. The radius of the circle is 12.15m/s, which I guess is the average velocity of the hang-glider if you take away the wind.

To fit a circle (in cyan) to a series of points, I rely on scipy.optimize.minimize using the centrepoint as the parameter vector and the minimization function as the standard deviation of the distances of all the points from that parameter vector.

def fun(C):  
    cx, cy = C
    n = len(pts)
    dsqs = [ (cx - x)**2 + (cy - y)**2  for x, y in pts ]
    sumdls = sum(sqrt(dsq)  for dsq in dsqs)
    sumdsqs = sum(dsqs)
    return sqrt(max(0, sumdsqs*n - sumdls**2))/(n-1)
bestcirclecentre = scipy.optimize.minimize(fun=fun, x0=(0, 0)).x

Obviously if you are implementing this on an onboard flight computer you wouldn’t use this heavyweight algorithm to do it, but as we’re only analyzing data we should use whatever method gets the answer with the minimum of coding.

As you can see from the top diagram, a wind vector distorts arcs and circular motions. It would not be possible to model these without first subtracting the wind vector before trying to match the circles in terms of measuring their radii. This will not be a precise compensation, so it will add noise to an already noisy signal.

Straight line motions, however, do not get distorted by the wind displacement. So if I fly in a straight line according to the GPS ground track, then it will almost certainly be a straight line in the air mass, and these should correspond to a whole sequence of readings that are theoretically constant. The level of constancy will confirm or refute the theory and the accuracy of the sensors.

nowhererawgpsstraights
Here’s the picture of the same GPS trace, but with straight sections of the flight picked out by looking for the straightest (in 2D) 10 second flight intervals in increments of 1second.

nowhererawgpsveldir
If we overlay the GPS velocity vectors (available in a separate GPVTG record) onto a single GPS trace (direction of flight is from top right to bottom left) it appears that the GPS velocity is providing the average value over the previous few seconds when it was completing its turn to the left. Unfortunately there are no details of this in the datasheet.

What if we take the middle third of each 10 second trace and compare it to the GPS velocity? (This represents a lot of tedious code.)

nowhererawgpsdeflection
Here is the graph of deviations from the direction of the middle 3.3 seconds of 10 second straight flight compared to the same averaged GPS velocity, plotted in order of deviation. It looks like it’s a normal distribution with the vast majority between plus and minus 4 degrees and the average deflection overall of -0.72degrees. I don’t know whether this is significant or reproducible.

nowhererawgpsdeflection2
Actually, I can go through the whole rigmarole again for yet another go-nowhere flight on the following day to get this one with an average deflection of -1.17degrees.

I don’t have time to explore this discrepancy yet, and whether it would go away if I were to balance the number of leading-into-straight left turns vs right turns.

This is a single device that doesn’t depend on mounting or position, and people have done extensive calibrations and tests that I don’t believe there will be anything further interesting hee, apart from the fact that I shouldn’t rely on this GPS velocity value because of its filtering and delay. I should ignore them and just work with the positional values.

So far so not very interesting as I’m just doing stuff with the GPS, which is only special because it’s reading at 10 times a second.

How about tying in the orientation vector from my new BNO055 absolute orientation device?

At this point it’s very hard not to get distracted and work on something else that’s a lot easier. So that’s what I’m going to do because otherwise this post will never get out. But I’ve been putting off completing this work for over a week and it’s got to be done. There’s always just that little bit more circuitry and 3D printing to do, even though it doesn’t actually give you that much better quality data. But because the data would be a little bit better due to the sensor being mounted in a known orientation, it’s easy to put off this work.

And that is why people will always spend more time making their sensors beautiful and good to look at, and far too little time actually doing anything with the ugly and usually wrong data.

Leave a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <code> <em> <strong>