Monday, July 13th, 2015 at 8:34 am - Hang-glide
I didn’t get very far up the Drau valley from Greifenburg, but the flight was sooo satisfying.
Anna Schutz is a bitch, if her Haus is anything to go by.
That’s the strange name for the sharp ridge on the north of Lienz marking the turning point where you can go around Kreuzeck range. It was my self-set task for the day because it’s described in a bit of detail in the Burkhard Martens Cross-Country Flying book.
Picture 8.5.17 Flanks over the Anna-Schutz house. A racetrack up high and a dangerous lee down below.
After a very difficult start of flight trying to get up from deep in the ravine between Emberger Alm and Gaugen, and then scoring 3000m altitude to get that hunger out of my system, I headed over to the red cliffs of Scharnik.
Here I had the usual nightmare with the rigid wing Atos gliders, who are always above you like mosquitoes because they glide more efficiently. However, they don’t thermal so well in turbulent air when a normal hang-glider can make progress by really throwing it around in the air currents, and inevitably you come face to face with them on the level. They think they own the thermal because they started out above you. And they fly differently so you can’t circle with them. And if your glider is easily recognizable like mine, they can give you a bollocking in the landing field as you’re derigging. They all look the same to me, these Atos gliders, so I have no idea when that was. It could have been two days before.
I do always keep out of their way, to the extent of making bad decisions and losing thermals. So I followed the back ridge from Scharnik to Damerkopf, lost all my height, went back to the rocks at Scharnik and did it all again this time without the distraction of the other glider threatening to bite me. I then crossed directly to Damerkopf, hopped over onto Anna-Schutz’s spine-back house perfectly lined up to take advantage of the thermal highway as advertized.
Far below on the southern flanks I could see gliders returning low from a competition task and having a hard time staying up. I’m glad I’m not down there, I thought to myself.
Five minutes later I was down there where it was as rough as a pair of long-johns flapping in a sea breeze. You couldn’t see anywhere to land except for a few green cornfields far in the distant valley that probably had three rows of power lines through them, so it was best not to bail out. Sometimes your shadow was so close you could almost touch it. Then you’d have a heart attack when you saw another shadow coming directly at it and you’d have to rapidly dart your head about like a chicken’s to see where the other glider was camouflaged against the boulders and scree.
Thursday, July 9th, 2015 at 1:45 pm - Machining
Little to report from Austria. Shoddy internet over the road that cuts out after 2 minutes. Eight minute flight straight down (with cavers watching, wondering what’s the point). Days of rain when I worked on my electronic logging devices, all of which were broken in various ways, from short circuits (caught in time before the Teensy boiled its plastic off), broken I2C connections, a completely bricked BNO055 orientation sensor, and a slightly folded micro-USB card probably from when I accidentally drop-kicked the device on my way out the door which was causing of the short circuit. I debugged for six straight hours like a machine, and still it wasn’t enough.
There’s something making the microcontroller crash after eight minutes whenever the Serial1 connection to the GPS is opened, but it doesn’t happen when you run a program that just listens to the GPS only.
I’ve also done two carries up to top camp of rope and metalwork and my soles are now sore. Now I’m worried that I’m coming down with the lurgi just before I strike camp and head for better air at Greifenburg.
I think I’d better go jump in the river to chill everything out while it’s still hot.
Wednesday, July 1st, 2015 at 5:17 pm - Machining
Over the last few months, well, since December, I’ve been producing an awful lot of plastic scrap from the UP! 3d printer we have here.
We had better find a way of recycling this soon. I’ve got my eye on the plastic injection moulding machine as a potential consumer.
Here’s the work bench of chaotic iterations of circuitry and boxes to contain the circuits.
To be clear, none of it does anything, except get data and log data to an SD card.
Occasionally it gets a short-circuit which crashes the microcontroller.
I now have two data logging devices. I am busy printing off further legs and hooks to glue onto the second black one on the right so it can be strapped onto another hang-glider, or to my hang-glider beside the primary device, which will mean that I have two sensor boxes measuring the same factors and coming up with wildly different results, thus proving that this kit isn’t as great as it appears.
Building stuff is a great way of putting off actually doing anything with the data. But once I am in Austria in a campsitte and away from DoESLiverpool and its tempting 3D printers, I won’t have the option to put it off anymore.
Wednesday, July 1st, 2015 at 3:26 pm - Hang-glide
Last Saturday we skipped MakeFest in the Liverpool Central Library to take advantage of some sunny weather.
I had a nice flight off the Long Mynd, caught one thermal up off the hill, and then drifted over the back and totally lost my sense of direction on the way down, blundered through one thermal on Wenlock Edge and was quickly down in a grassy field as I deserved to be.
I walked most of the way back to Church Stretton by the time Becka arrived with the van after her midday cycle ride up and down the Mynd holding up all the cars. We set up in the camp-site nearest to my landing field, had a late lunch, and then pushed off onto a bridleway along the top of the Edge which quickly degenerated into a tree-rooty footpath through a series of wheat fields.
When we eventually got back onto the tarmac, Becka sped off downhill along the country lanes until she came unstuck at a T-junction with a lot of loose chippings at the centre.
This is day 3 of the recovery period.
No caving for you!
Friday, June 26th, 2015 at 12:59 pm - Kayak Dive
I took a break from my treadmill of unpaid unproductive work for a day on Cosmo’s boat with a couple of dives with Becka. We left the slip at 7am, having forgotten to have my morning tea. I wondered if my addiction was the cause of the headache most of the afternoon.
Aside from that, it was very calm out there.
We dived on the wreck of the Alarm (a light ship), which was pretty deep at 30metres, but clear enough to see and swim round.
There was a bit of a drama with the SMB reel which stops paying out if you squeeze the trigger too hard, doesn’t it?
Becka’s suit flooded completely. Luckily the water was 12degreesC, so it was like being in a cave. We pressure-tested it after the second dive with soapy water and only just detected the problem on the neck seal which had peeled off at the front and remained joined by a thick film of glue.
The second dive was on the Lelia in stirred up clouds of terrible visibility. (Here is a video from last time when it was clearer, which was also the last time I bothered taking a still-shot camera underwater.) Headcam video does the necessary job of aiding my memories.
We got off the wreck as soon as we’d dealt with the anchor, not wanting any repeat of our getting trapped inside experience from our last trip out (which, fortunately, was not our last and final trip).
Thursday, June 18th, 2015 at 9:31 am - Hang-glide
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.
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] += 1 degreesums[ideg] += 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.
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.
Monday, June 15th, 2015 at 6:07 pm - Weekends
Last weekend Becka got drafted to play in the the massive canoe polo gala on the docks.
They didn’t score many points, and the game is quite different to the no-rules murderball we play on Thursday nights in the dark over the winter.
Meanwhile, a great deal of faffing has been going on with this machine.
Yesterday I went on a very long bike ride into Wales to check out Penycloddiau East having missed out on numerous flying days so far. I’m just not getting my act in gear. This is an official site. Some folks have been flying at unofficial sites and making people very very angry.
We did at least go over the Flint Bridge
…and see the 29mph speed limit sign.
…as well as a board outside another heavy industrial establishment that implemented the XKCD sign reset widget.
Tuesday, June 9th, 2015 at 11:09 am - Hang-glide
I got a bit depressed with my performance when I look at the GPS track and noticed that I’d inexplicably missed out a complete turn when I was flying. This track is going from west to east downwind.
With the power of pyclick() I could plot locations on the GPS against a graph of the barometer values, so the positions of the red vertical pointers correspond to the vertical yellow lines on the barometer graph (in red):
So that explains it. The vario stopped climbing (air pressure ceased declining with altitude) briefly, and I flew downwind briefly to pick it up again.
So that’s not so bad then. I need more confidence that I’m doing it right in a thermal, because I can’t tell the difference between doing badly on an easy thermal and doing well on a difficult one.
Here’s the snipped from the flight video with the positions marked.
The a second curve in the graph above, the one in cyan that wiggles up and down, is the graph of air temperature according to a dallas one wire probe that reads every 0.75seconds. My other temperature devices are generating noise, and the infrared wing thermometer got lost when I broke an upright on Wether Fell.
Let’s look at a similar graph from later on in the flight where I did well and got to cloud-base.
The temperature graph is here, declining smoothly without any changes in direction with each turn. (The really wiggly line is the airspeed, which I’ve not worked out how to process yet, although I believe there is a correlation between sudden changes in speed and variations in altitude regarding the trade between speed and height.)
So what’s going on here? Am I dropping in and out of the first thermal with every turn, but managing to remain entirely within the updraft on the second?
Or does the sensor box on the left of the base bar enter and exit the shadow of the wing with every turn in the first thermal, and this doesn’t happen when I’m higher up in the shadow of the cloud?
That seems like a better explanation.
Recommendation: Always point a video camera at your experimental sensor instrumentation so you can get to the truth of any interesting effects that it might be picking up. It could be the sunlight, people walking past, a visiting cat, or other devices switching on or off in the vicinity.
Friday, June 5th, 2015 at 3:39 pm - Machining
This BNO055 absolute orientation sensor is just the thing I’ve been after for logging the hang-glider direction and heading. It combines the compass and accelerometer sensors into a single package with its own co-processor running proprietary sensor fusion software, so I don’t need to get into the business of decoding making sense of this sensor data.
The theory for calculating absolute orientation is as follows.
Absolute orientation is represented by three degrees of freedom: horizontal heading, roll and pitch. At rest (held within a particular orientation), there are two absolute vectors which can be sensed: the gravitational force (downwards) and the earth’s magnetic flux (about 23degrees off the down vector towards the north, if you are in the UK).
Knowing an absolute unit vector relative to your oriented frame constrains two degrees of freedom. Think of this as a fixed pin passing through your object like it’s a beetle on a specimen tray: the bug can only spin its body around the pin. Two such pins could nail down four degrees of freedom, but there’s only three, so the extra information is redundant and can be used to estimate the accuracy of the measurement.
Each of the sensors on the BNO055 device requires calibration, according to the datasheet:
3.10 Though the sensor fusion software runs the calibration algorithm of all the three sensors (accelerometer, gyroscope and magnetometer) in the background to remove the offsets, some preliminary steps had to be ensured for this automatic calibration to take place. The accelerometer and the gyroscope are relatively less susceptible to external disturbances, as a result of which the offset is negligible. Whereas the magnetometer is susceptible to external magnetic field and therefore to ensure proper heading accuracy, the calibration steps described below have to be taken.
I’ve been logging the quaternion heading from this sensor and then trying to relate it to the motions I was making. Unfortunately, sometimes there was a complete sudden reversal of the orientation mid-flow, even though I wasn’t making any sudden motions:
Here’s the log from this moment that occurred at the timestamp=61350
tstamp qw qx qy qz mag calibration status 61050 15158 336 41 6208 1 61150 15419 431 103 5522 1 61250 15664 510 164 4774 1 61350 722 234 -654 -16353 2 61450 244 -530 777 16355 2 61550 1460 -929 852 16270 2 61650 2277 -1019 921 16167 2 61750 3023 -1249 1137 16014 2 61850 3509 -1358 1335 15890 2 61950 4023 -1386 1477 15753 2
Funnily enough, for such a complicated packaged system, there are absolutely no configuration settings at all — except for one option known as NDOF_FMC_OFF, which is “the same as NDOF mode, but with the Fast Magnetometer Calibration turned OFF”. (NDOF stands for “9 Degrees of Freedom”, which I guess refers to the fusion of 3 magnetic flux axes, 3 accelerometer axes, 3 gyro axes into a single measurement.)
The fact that you can turn off the so-called “Fast Magnetometer Calibration” mode suggests there is something special about it: ie it might be buggy.
Anyway, I don’t have time to check out what this does otherwise. I’ve wasted enough on this already. I should go look at something else.
Which of course means I’m just putting this off till I have some logged flight data. Which might be complete junk.
Wednesday, June 3rd, 2015 at 12:33 pm - Machining
Origin at O with y-axis along Y being the side of the table, because we want to solve this by fixing the job to be machined in the fixed coordinate frame and pretend that the machine and tool are swinging all around it.
The blue lines represent the triangular main frame (with three approximately known lengths of about 745mm), the green lines the arm (with two lengths and an angle). This carries the cutter at point P and its triangle pivots at the movable point A1 due to changes in the length of J1 representing the linear position of the ballscrew.
The entire blue triangular frame pivots around the fixed point A0 due to changes in the length of J0. The absolute offsets on J0 and J1 from their connection to the common vertex are also unknown, which means we have a total of 2+3+3+1=9 dimensions which we can vary in our calculation to calibrate. (That last dimension is the length of the fixed edge between O and A0.)
def abanglefromtriangleabc(a, b, c): return acos((a*a + b*b - c*c)/(2*a*b)) a = 743.5035783400 # sides of mainframe triangle b = 754.8024952389 c = 745.4991150306 d = 697.7062405262 # length of O->A0 e = 695.5193939239 # length A0->"arm" f = 583.6487506837 # length A0->P ah = 0.0764480526 # angle in arm tblx = 525.4558306022 # offset in j0 armx = 396.1544040232 # offset in j1 ab = abanglefromtriangleabc(a, b, c) ac = abanglefromtriangleabc(a, c, b) def convertJ0J1toXY(j0, j1): tbl = j0 + tblx arm = j1 + armx aTBL = abanglefromtriangleabc(b, d, tbl) aARM = abanglefromtriangleabc(c, e, arm) avec = ab - aTBL; pvec = avec + ac - aARM + ah return (0 - a*sin(avec) + f*sin(pvec), d - a*cos(avec) + f*cos(pvec))
The game we’ve been playing for the last few weeks is to probe a perfectly circular disk mounted on the table with a known diameter, read out a series of joint values J0 and J1 from about 60 different positions, write a function that uses the 9 unknowns to project these measurements into cartesian space relative to O and the axis Y and provide a value of how close we are to having the right circle, and then use scipy.optimize.minimize to pick the values which minimizes this geometric constraint.
Unfortunately, this doesn’t seem to constrain it well enough, for we are getting good fitting solutions where the lengths of the main frame triangle are far from 745mm.
So that’s where we are at this week. I think we’re going to sod the calibration for a little while and just machine some stuff anyway, even if it isn’t perfectly right.