Tuesday, March 17th, 2015 at 8:39 am - - Hang-glide

Here I am at a climbing wall in Bristol, having balked at the price and instead sat in the cafe. They ought to have a discount rate for people don’t actually like climbing. Here’s what I enjoy instead. (I am so predictable):

pontwales

Brrr, it was cold in grimmest South Wales on a grim Saturday when all the colours are grey and the light makes everything flat. I enjoyed a sublime hour long flight above Pontlottyn, even though I didn’t go anywhere except soar up and down the ridge alone and then top land in a howling gale.

My box of tricks is in the 3D printed purple box on my left next to the airspeed indicator. I’ve not had the chance to do anything with the data except plot it and go: “that’s pretty noisy” at the accelerometer data. I have plans to extract consistent correlations, barometer vs altitude vs temperature, bar position vs wind speed, roll angle vs turning rate registered on the compass, and whether I keep diving out of turns because I don’t have enough speed and control.

Unlike my so far doomed attempts at manipulating house and fridge temperature data, this flight dynamical system is memory-free. The same temperature, pressure, windspeed, and wing angle at any time of the flight should result in exactly the same response. Deformations of the wing are brief and temporary. This is not the case for the fridge where every cycle begins with a different temperature distribution within the dense cabbagy foodstuffs and chemical pumping machinery.

Subject to instrumental noise and turbulence, all the data should be with me, and I can only hope this isn’t going to end up as just another one of my expensive failed software projects that looked plausible when I began, but then crash landed in the trees.

Wednesday, March 11th, 2015 at 3:35 pm - - Hang-glide

In spite of being up to lots of things, I’ve not been very interested in blogging of late.

I got my first flight of the year — a 3 minute top-to-bottom that began with a nil-wind terror swoop on take-off, followed by my almost forgetting to unzip the harness on landing due to being distracted by the sight of ducks paddling around in one corner of the water-logged field.

landingshadow

Here’s the data stream from the landing.
landingdata
Vertical lines at 5 second intervals. Yellow for barometer (air pressure rises as I descend), red for airspeed, cyan for GPS ground speed (seeming to correspond), white accelerometer pitch measurement, showing the pathetic flare coming into landing when all the speed drops off. The previous hump may correspond to the final approach turn (you have to push out to tighten the turn to a turning circle of about 35metres).

takeoffdata
Here’s the take-off sequence, with a slight push-out which was not held long enough, so I dropped very fast. The yellow for the barometer briefly goes below the starting value showing that at one time I got a bit of lift and could have been almost half a metre above take-off.

All in all, quite disappointing, but I’m glad to have some data to work with from my electronics device. I’m going to really appreciate the next flight when I stay up for a bit.

hgelectronics
Oh yeah, here’s a close-up of the one corner of my dog’s breakfast electronics project.

boxprinting
Luckily, 3D printers can print anything — including the abominable box I’ve “designed” in OpenSCAD to cram that electronics stuff into.

machtooldoes
Meanwhile, all this will probably be shelved due to this widget showing up in the hack-space this lunchtime. More later.

Tuesday, February 17th, 2015 at 11:15 am - - Machining

The green is the raw plot of the accelerometer vector which was aligned with the crossbar of my bike on the ride. The red is the altitude, the yellow is my speed — clearly slower going up hill than going down as time advances from left to right. We stopped for a bit at the top of the hill.
gyro1

This is smoothed with an exponential decay factor of 50/51 on a time sample rate of 0.1seconds, so a sort of 5 second time window.
gyro2
This is applying the exponential smoothing filter backwards as well, which is a trick I heard about a few days ago. I haven’t worked out of the maths of it yet, but it looks good.
gyro3
Here are some vertical lines showing periods of ascent and descent with the second white horizontal line denoting the overall average accelerometer reading that you can think of is approximating how much the bike cross bar is pointing up or pointing down from the horizontal. I can convince myself that it is negative on the uphills and positive on the downhills where it is tending to point more in the direction of gravity.
gyro4
Here’s a zoomed-in section of where we peddled down the hill and then heaved our way back up the other side. Because the rates of descent and ascent are about the same it means the slope down must have been shallower as I don’t peddle up hills very fast.
gyro5
Unfortunately I’m not competent enough to overlay this on a map to see these places on the contour lines, and I don’t have a bike wheel trip magnet to measure distance travelled properly.

Anyway, it’s not really for my bike; it’s for putting on my hang-glider. The bike is just a good way to test things till I can get out flying again.

Monday, February 16th, 2015 at 8:49 pm - - Machining

Quick report on the misery of trying to get any good data out of these fancy good-for-nothing data sensors.

I did a bike ride on Sunday around Yorkshire, from Barbon to Dent, up the valley, down to the very fine Cafe Nova in Sedburg and then back to Kirby Lonsdale via a bridge over the river Lune where Becka and I went kayaking in January and got scared (it looked a bit tame in these water levels). This was the day after the day before where I broke my caving famine and did a nine hour Easegill traverse from Pippikin to Top Sink while the hard people (incl Becka) did the reverse route and went out Bye George to celebrate Tom’s birthday. (This was the same Tom who drove out to Austria with me last May so I could go hang-gliding when Becka stood me up to go on a caving holiday.) Hint: for my birthday I will not be going caving.

So, anyway, you’d think something as simple as the GPS-altitude and barometric readings would be somewhat related.

This is what the plot looks like of barometric pressure along the X-axis (zeroed at 990Mb) vs altitude, which ranges from 102m to 305m. Yellow is the first hour, where we went over the hill, and blue is the second hour peddling up the valley from Dent.
baroalt1

Not a great correlation. Here’s the same picture zoomed in. The squiggles are predominantly left and right accounting for the noise of the barometer readings.
baroalt2

Suppose I take a rolling average of sequences of 7m and plot the same here without all the noise, getting the yellow line.
baroalt3
Still pretty wobbly. The cyan is the plot of the barometric forumla which is:

101325*(1 – 2.25577e-5 * altitude)5.25588

This is near as damnit a straight line of slope -0.08488715682448557. Applying simple linear regression to the slope gives -0.08992119168062143, which is not a great match.

Maybe I ought to work out a way to do this calculation in run-time on the device itself to give a measure of how rubbish the altitude-barometer agreement is during operation so I don’t have to bring it back here and run these complicated python programs on the data.

Then I could see if it’s responsive to the mode of travel, eg bike vs walking up and down the hill.

The next correlation to look at from this data is tilt of the bike frame registered from the accelerometer vs the slope climb according to the GPS. I’ve got very little hope this will work, so have put it off. I’m already sure that the temperature vs altitude signal is completely lost in the noise, probably due to the proximity to the ground on which the sun was shining.

I hope to see something better if I ever get this thing in the air. Right now I’m 3D printing enclosures to grip on to the base bar and am gathering a desk full of lots of bits of useless bits of plastic. Got to push on and not be distracted.

Wednesday, February 4th, 2015 at 11:14 pm - - Machining

So I had to bodge the wind sensor interrupt readings and filter out the glitches. Beyond that, there’s a heck of a lot of variation in the readings when in front of the fan (getting 12mph wind, according to the proper device), and even at the nozzle of the vacuum cleaner (where the wind speed was 42mph). Either there’s still turbulance or the sensor is wobbly. Not impressed.

fandrier
Next up, there’s the sudden-air-temperature-from-flying-into-a-thermal detector based on the analog TMP36 connected to a large capacitor to bring the voltage changes down to zero, and so they can be put through two op-amps (one for positive and one for negative changes).

I turned on and off the hair drier behind the fan that points at the dangling circuitry and got this trace.
fandrierplot
(more…)

Wednesday, January 28th, 2015 at 11:52 am - - Machining

As I suspected, this is where all my grand designs go completely wrong. Recall that I proudly got the wind speed probe to convert each passing of the fan blade into a square wave voltage spike earlier this month.

Well, the reading of this signal was to be done with the following code:
(more…)

Friday, January 23rd, 2015 at 11:25 pm - - Machining 1 Comment »

After spending a few days with all my bits and break-out boards in a bowl and stirring them around aimlessly, I got all the major SPI components lined up on a breadboard, like so:
breadversion

That’s an SD card writer, an OLED screen display, a bluetooth low energy and a GPS module.

The additional devices are on short 4-wire phone leads in plastic printed boxes of dubious design.

After a great deal of unplanned soldering and the use of header sockets so that none of the bits are permanently stuck in the wrong place, I’ve got a thing that looks like this:

breadversion2

There are issues. The barometer has a separate power supply and now doesn’t communicate, the wind-meter has a degree of noise in its signal, the I2C accelerometer is too complicated, the dallas temperature sensors can only be read one at a time, and all three SPI devices are incompatible with one another.
(more…)

Sunday, January 11th, 2015 at 9:10 pm - - Hang-glide 1 Comment »

By not including a datasheet with their airspeed probe, Brauninger/Flytek gave me the pleasure of two successful days of hacking involving an oscilloscope and much experimentation to work out its parameters and build a circuit to exploit them.

I bought this thing as an optional add-on to the Flytec 6030 (which I’ve never got to grips with) back when I had more money than sense. I wouldn’t have got it for the purpose of reverse engineering like this because I couldn’t do electronics then, and anyway I’d have rated the chances of success as quite low.

Nevertheless, by applying various voltages and different directions and blowing on the propeller to get a response, I established that if you apply a positive current on the tip of about 1Volt (and ground the other connection), the device exhibits a resistance of between 11200 Ohms and 12000 Ohms, depending on the position of the blade.

This was a job for a Wheatstone bridge:
wheatstonebr

You can actually see the voltage differences (in millivolts) over 1/12 of a turn of the propeller:
proplowvolt
prophighvolt
(more…)

Monday, January 5th, 2015 at 9:00 pm - - Machining 1 Comment »

It’s been a lot of work, and I need a break. This has now outperformed my target over New Year period moping around Bull Pot Farm while everyone else goes caving.

I am now able to make numerous slices on this impellor model made of 38474 triangles with an angle change tolerance between contour sample points of 18degrees in about 5 to 10 seconds per slice using Pypy (or 80 seconds in Python3). The code is at bitbucket.org/goatchurch/barmesh. Use it at your peril. It’s just beginning to work, and the next thing I will do is break it.

Here are some pictures of the results of slicing an impellor shape that’s 20mm in diameter with a sphere of radius 0.2 using the command:

pypy -O main.py –stl=stlsamples/impellor1.stl -v -tswapyz -r0.2 -n52

slicer02surf
Slices with ball radius 0.2 with the STL model shown

slicer02nosurf
Offset slices without the STL model so you can see all the internal contours from the ball rolling along the inside surfaces of the model. These internal contours will need to be detected by connectivity and deleted.
slicer02top
View down the top so you can see the inner and outer offset slices of the central cylindrical through-hole.

From my initial profiling, 99% of the time is spent in the two functions MakePointZoneRF() and CutbarRF(). This is fantastic news as this is where all the point-line-triangle distance/offset-intersection calculations are done. And it’s intended to be very GPU-friendly. (I don’t actually have any experience with GPUs yet, but it could happen now I’ve got a real world use case.)
(more…)

Tuesday, December 30th, 2014 at 2:27 pm - - Cave

This trip round the Lleyn followed on from last year’s Avoiding Nadilog by Walking in Wales. In retrospect nothing much happened. But it was exciting at the time due to the lack of planning and the risk of things going wrong.

whistlesands
Our white Xmas on Whistling Sands

Departure was delayed till the morning of the 24th because someone couldn’t possibly miss their 14th digging trip of the year in ODB. Anyway it was raining and we weren’t packed yet.

(more…)