UAV, reading sensor data Part II

In our previous adventure, Matt and I defeated the dragon and rescued a fake princess who turned into a giant spider  managed to get some meaningful data from both the gyrometer and the accelerometer. We also made some pretty graphs.

The next step is for us to compare the outputs from the Gyro and the Accelerometer. This is currently impossible, given that the Accelerometer is transformed into meaningul readings (degrees) already, and the gyro is just a load of “rate of change” readings.

We can get the orientation readings from the Gyro like this:

  //Create variables for outputs
  float xGyroRate, yGyroRate, zGyroRate, xGyroRate2, yGyroRate2, zGyroRate2;
  long Time;
  //Read the x,y and z output rates from the gyroscope & correct for some innacuracy; convert to seconds
  xGyroRate = (gyroReadX())/57.5;
  yGyroRate = (gyroReadY())/57.5;
  zGyroRate = (gyroReadZ())/57.5;
  //Determine how long it's been moving at this 'rate', in seconds
  Time = (millis()-previousMillis);
  //Multiply rates by duration
  xGyroRate2 = -(xGyroRate/Time)/4;
  yGyroRate2 = -(yGyroRate/Time)/4;
  zGyroRate2 = -(zGyroRate/Time)/4;
  //Add to cumulative figure
  if (((xGyroRate2)>(gyroLPF))||((xGyroRate2)<(-gyroLPF)))   CumulatGyroX += (xGyroRate2);   if (yGyroRate2>gyroLPF||yGyroRate2<-gyroLPF)   CumulatGyroY += (yGyroRate2);   if (zGyroRate2>gyroLPF||zGyroRate2<-gyroLPF)
  CumulatGyroZ += (zGyroRate2);

Now that we’ve done this, we can measure an axis from both the Gyro and the Accelerometer at the same time, and overlay them on top of one another in gnu plot.

Like so:

Yeah, that didn't really work.

Yeah, that didn’t really work.

Ok, so there was something wrong with that. We tweaked the code some more, and got something a bit better:

No, that's worse.

Much worse.

Finally, we figure out where we went wrong with the code. We don’t have the old versions, so we can’t show you our idiotic mistakes. After fixing it, we get something much closer to what we were expecting:

Roll measurement from Gyro and Accelerometer

Roll measurement from Gyro and Accelerometer

We can see from this graph that both sensors are outputting more or less the same thing. However the gyro measurements are actually off by a bit at the start, and are slowly producing a more noticeably incorrect orientation. If we used just the gyro, we’d end up with the plane downside up. There are also “spikes” in the accelerometer readings, at 700 and 1300 – these are probably noisy readings from the sensor.

To get an idea of how much the gyro readings drift, we turned on all the gyro sensors and then left the board still for a few seconds:

Gyro drift in three axes.

Gyro drift in three axes.

This is obviously not going to work long term – we can’t be certain of either sensor. We need a way to combine the readings from both sensors, or face the consequences.

Introducing… the Bormatec Vamp


After careful consideration, I’ve decided to invest in a Bormatec Vamp as a flying UAV-Testbed. It’s got a 1.8m wingspan, and an all-up maximum weight of 2.5kg; plenty of room for around a kilogram of payload. After doing a little math, it’d cost me about 3x as much as this to purchase the equipment to manufacture an airframe to the standards that I’d like.

At a cost of about £130 delivered to the UK from it’s German manufacturers, it’ll arrive as a kit of parts; assembly will be documented herein.


More pictures and information as soon as it arrives!

For more information on the Vamp, please refer to it’s manufacturer website, listed below- also the source of the included image.

UAV, Finally

Above are a few pictures of things as they stand at present.

This project, as previously stated, is largely an experiment to improve skills, and produce something tangible. The aim is to produce an autonomous aerial vehicle; capable of flying to a destination co-ordinate, performing a task, and returning to base. (Likely, taking a picture or dropping a tennis ball to wind up Iain’s dogs).

The arduino control board was knocked together quickly to make it more robust than having a proto-board with all the components plugged into it.

In essence, the small red stick visible on the board to the right of the picture is a 9-DOF (Degrees of Freedom) sensor stick, incorporating an accelerometer, a  gyro, and a magnetometer. They communicate with the control board (the blue Arduino Pro Mini) via a two-wire protocol known as I2C; these in turn communicate with a base computer using two XRF modules.

Left to it’s own devices, at present the little ‘Duino will talk to the Accelerometer and, working with a little clever 3-D math, ascertains the direction ‘down’. From this, it then outputs ‘pitch’ and ‘roll’ calculated values over a serial data bus, which is transmitted through the XRF daughterboard, up to a range of 2km, back to the PC via the second XRF, to the left of the picture. Note the little yellow and green LED’s; these flash to show data transmission and reception on each of the boards- Though I have forgotten which is which… it’s in the schematic somewhere if it becomes an issue.

It’s yet to be seen how well this responds to the G-forces generated during flight- Some thought as to an appropriate solution is required. Ideas, on a postcard…

The magnetometer and gyro are currently unused. The magnetometer will eventually determine the direction of the board relative to magnetic north; ‘yaw’. It will also use the gyro to increase the accuracy of the calculated P, Y, R angles.

I have also been working on a fuselage mould; Having discovered that none of the filler types I have access to will adhere reliably to expanded polystyrene, I have decided to change contsruction method for the fuselage of this drone; Likely at this point I will make use of vacuum moulding of ABS plastic, or a moulding made of fibreglass. Wings are to be made of extruded polystyrene- think foam fast food containers, but denser. A CNC machine will be made to produce wing sections.


That’s all for now; More as soon as my student loan allows!

(Please ignore the deliberate PCB error of filed down LED’s; I made the footprint wrong, and was too impatient to wait for more to be cut!)

We’re going to build a UAV

My friend and I want to build an unmanned aerial vehicle. Unlike the predator drones, it will not be armed with missiles.

This is an educational project for us; I’ve never done any proper “bare metal” coding before, or even very much hardware based stuff. Matt, however, is great at the hands on, practical side, but his coding is lacking.

Between us, we should have enough knowledge to fuck up in new and interesting ways.

I’m going to let Matt explain what kit we’ve got, what each bit of it is for, and how he’s fitting it together. I’m going to cover the coding side, and the maths, and how we’re going to get it to fly itself. Or Matt will probably cover that last part; he is doing an engineering degree. I’ll be taking the theory he gives me, and implementing it :).

To start with, we’ll be doing some “basic” stabilisation stuff. We’ll get the plane to try and stay as level as possible, automatically correcting itself except when recieving input from the remote.

Oh – and we don’t have a plane yet.