 I'm Gavin Phantom, and I'm here to talk to you about Whirly Blades of Death, which is one of the nicknames that's been given to this contraption. I can't remember, but it might well have been, right? It's not the only name this has been called, possibly the most surrealist to date. I brought this, I parked up in Redbridge and took the central line to come here, and carrying this on the tube was an interesting experience. I walked into Redbridge Station and within 30 seconds somebody walked past and said, Fuck me, it's a bomb! So, with that out of the way. I'm going to talk to you about how this came to be. This is a project that I started around 2010. This is not the original quad that I built, but it is very, very similar to it. There is a story that I may get to about why I have a second one. So I decided back in 2010 that I really liked the idea of building a quadrota. I've seen them on YouTube, mostly. They looked really cool. They were new, they were exciting. I could have gone out and bought an Arduino with the then very expensive shield for all of the inertial sensing and all the other stuff that you need. I could have just about bought an off-the-shelf frame at that time. They weren't as common as they are now, but they were still available. I thought, now, I'm much more interested in having a go at building it all myself. Electronic, software, frame, everything. Almost everything. I didn't really fancy winding motors. Well, I thought briefly about building the speed controllers and all the motor drivers. Yeah, that didn't really grab my interest either. I could have spent a whole number of years just on the speed controllers. I thought, okay, there's enough in this project and we'll leave it at that. So, where do we start? What was available at the time? Well, the core of a quadrot project like this is the inertial sensing. Now, we had in the previous talk a mention of inertial sensing and it's great. Android or iOS, they do it all for you. You just get one line and you say, what's my orientation? Job done. Yeah, I didn't use Android or iOS for this. I did my own thing. The first thing that you need is some sort of inertial sensing. That little white thing by the power supply is a WeMotion Plus. I don't know if you remember those. A little thing that plugs into the end of a WeMote and it contains a three-axis gyro. At the time starting to become available, three-axis gyros, things like that, but they were still not quite as readily available as they are now and they certainly weren't cheap. The WeMotion Plus was a really cheap way of getting hold of one. Some really nice person on the internet had already reverse engineered the protocol. So, great by a WeMotion Plus. Time to play with it. Well, it's got a nice squared C interface at 3.3 volts. Microcutrol, no, not yet. Parallel port on the PC because I still had a PC with a parallel port even in 2010. A bit of breadboard, a few transistors for a level shifter and bits and pieces later, and I had some software that would run on a PC. Now, what does a gyro give you? Well, these are rates gyros. They measure the rate of rotation. So that's great. You can say, okay, I am rotating at this rate or I am not rotating at all or whatever it might be. But how do you go from there to I am this way up or I am that way up or I am that way up? You have to integrate it. You have to take hundreds of samples per second and you have to integrate them. That gets you your orientation. Of course, it's a relative orientation to where you started off from. That's great. And because you're integrating, you get drift and that builds off over time. And you don't have an absolute reference. It is just relative to where you took off from. So after a while, you could be all over the place. And you can represent this by something like that, three-dimensional, well, three vectors and axis bases, whatever. Rotation matrix is what I used. There are other ways you can use quaternions. If you're an idiot, you can use Euler angles. There's one or two less common techniques as well. But I went for a rotation matrix from straight level to where I am now, DCM exactly, direction cosine matrix is another term for this. Right. So we've got this. We've had it sat on the ground for a while and it thinks it's doing that. Because we've got this drift over time. How do we compensate for that? So we need another sensor. In this case, a weenunchuck, which is just conveniently plugged into the back of a weemotion plus and it can pass it all through and give you some packets that contain all of the information. Great. Now, what is a weenunchuck? Well, it's two things. It's a little thumb control, which is irrelevant here. And it's a three-axis accelerometer. Now, can anyone tell me what an accelerometer measures? Acceleration. Right. Okay. So this gets interesting. Displacement would be what I would say. Displacement. Okay. Displacement usually due to a force or acceleration or something. Yeah. Of course. So if I've got an accelerometer sitting here on the desk, what does it read? Don't look it up. I want to know what you think it reads. In which direction? So 1g, okay, fair enough, and you've pointed up and you've pointed down. So let's settle this. Okay. Under what circumstances does an accelerometer read zero? Freeful with no air resistance. Yeah. Okay. And what do you have to do to that thing that's falling in freefall in order to make it stationary? Yeah, you have to push it up. So that's what it reads. It reads 1g upwards. It reads a force of 1g going that way. So it's an acceleration, rather, of 1g upwards. Okay. Didn't want to give that one away. We can make an assumption. We can assume that when you're flying a quadrata, the average acceleration is zero. Now, some of you might be feeling a little bit uncomfortable at this point. But let me assure you that it is sort of true. You start off not moving. You fly around, you end up not moving. Okay? That's an average acceleration of zero. Most of the time, you're either hovering or you're flying sort of more or less at a constant speed, unless you're doing very tight, coordinated turns that last a long time, which is the one case where that assumption is actually violated. But most of the time, your acceleration is zero, which means that if you take a long-term average, you've got that 1g pointing up. So that's your absolute reference. That's what stops you from thinking you're there when you're actually there. First time I powered my quad up outside, ready to actually fly and try and take off the first time, I had a bug in the startup sequence, which led it to take the first few readings of the gyro, which was zero before it had finished initialising, and take them as part of its zero reference. So, of course, by the time it had got this, it thought it was rotating at about this sort of rate. By the time I tried to power it up, it thought it was about there. When I powered it up, it tried to fix that. I managed to kill the power, I'd literally grab hold of it as it got to the vertical. Fortunately, no damage there, I went back inside and started debugging. OK. So, as somebody mentioned, you get a lot of noise on an accelerometer. I mean, I've had a measurement of something like 16g of noise on this. I'll get onto that in a bit if I have time. So, you have to do a bit of filtering, and I think the word sensor fusion was mentioned. There's a few common algorithms. I'm not going to go into them now because I really don't have time to spend the whole evening talking about the maths of these, but these are some algorithms. I did quite a lot of research on which algorithms I could understand and which I had a hope in hell of implementing, because I really wanted to understand every line of code that was going on in my quad so that, at least if it crashed, I could say definitely that was my fault. Right. So, once I had an algorithm in mind, here's really the second bit of hardware involved, the microcontroller. That's the red board. It's a voltage level converter thing that I borrowed from work at the time. On the bottom left, you can see the inside of the WeMotion+. So, there's a period of time that went, writing all the code from the very start of the execution all the way up to implementing the drivers for the I2C, reading all the gyro and accelerometer data, doing the sensor fusion, and eventually I had something that would output a matrix on the serial port and plug it into a PC, throw that matrix at OpenGL and rotate a cube on the screen, and then I knew that I had something that I could build a quadrature out of. This is about the point that Android and iOS get you to when they do the sensor fusion and then they just give you the values. So, what's next? We've got a little bit of hardware, electronics, at least. We need the other sort of hardware. This thing, metal frame, one meter length, aluminium box section from B&Q. I couldn't be bothered to cut it down, so that's why it's the size it is, and some aluminium sheeting. The rest is kind of interesting for me because it was an exercise in learning a little bit of basic metalwork, but I won't bore you with the details here today. Then, of course, you end up with all the bolts through it. This is actually the... This really is the first one. It's got slightly different electronics to this one. Not quite. This is a fairly substantial quad. It needs to be because of its size. That quad, when I finished it, including battery, weighed two and a half kilograms. You need a bit of power to get that off the ground. I have some fairly substantial motors on it and a hefty battery. I thought, okay, I'm going to do some tests. This is before I'd written anything that I trust to actually fly it. I want to make sure that the motors work and that I can control their speeds. I need to strap this thing down. What's the heaviest thing I could find that looked about the right shape? That's one plus. Now, this little thing here is a power metre. Obviously, the laptops on the serial interface, I can type commands at it, tell it to turn the motors on or off, fast, slow and all the rest of it. A power metre. I did a test where I turned on all four propellers, all four motors at full power at the same time. Who can tell me what the power metre read? No. I want you to guess the numbers. Shout out some numbers. 80 amps. Let's talk in watts. 600 watts, any advance on 600? 12-inch props. 1000 watts, any advance on 1000? Okay, so I actually measured one and a half kilowatts. Straight out of that battery. I don't remember the amps figure. It's nominal 14.8 volts. It's going to be a fair bit. The battery is rated at 100 amps continuous. So I guess it's in that ballpark, right? Let's present it a slight little problem. I don't know if you can see the corner of the Spark Station 1 Plus that's nearest to you. This is a test with three of the propellers running at full power and the one in the far corner not running. Do you see the gap between the bottom of the Spark Station and the floor? I also did a test with two motors running. I was too scared to hold a camera during that test. Obviously two on the same side. That was tilting quite a lot. But eventually we got the first version running. Now there's some slight differences here. It's got the Wemotion Plus right in the middle. It's got a great hunk of stuff that's gaffer-taped down. And the speed controllers are laid out differently. But the metal work, the feet are different. The feet on that were shit. They were very much an afterthought. And they fell off every time I landed, not quite perfectly. So my standard flying kit included a roll of gaffer-taped to put them back on. Right. So once we've got the hardware working on the control, I don't know if you're familiar with this principle, the motor spin in different directions so that you don't get an overall torque that's going wrong. And they all work in pairs. So if you make these two spin faster, it will tip that way. If you make these two spin faster, it will tip that way. And if you make a pair of them diagonally spin faster, it will turn one way or the other. And that's all the job of the flight controller, which looks more or less like this. We've talked about the sensor fusion, the gyro in the accelerometer. I haven't mentioned the radio. That was actually covered in the previous talk, even though it was coming from a phone in that case. But in this case, that's pretty much the signal you get from the radio. It's PWM. And we have these beautiful speed controllers which take a PWM signal and throw out the right things for the motors. So that's great. That's the easy bit. And once you get to this point, what are you going to do? You've got an input. You've got a desired input, which is the radio. You've got some actuators. You're going to throw some sort of control loop around it and obviously the simplest one that does the job is PID. I'm not going to go into the maths of that. However, I'm going to show you what it looks like when it's not tuned properly. Just before I'd figured out how to do PID tuning, the laundry basket is for safety. Obviously, I got it tuned after that. I actually gave up on the laundry basket principle and ended up holding it like this with one foot to set the throttle. It's not that safe. I hurt my arms in the process. You can't actually see the props when you're looking down on it so you don't know where the edges are. Your thing's saying two minutes. That's fine. So once we've got this tuned, I actually got this flying for the first time the day before EMF in 2012. EMF Electromagnetic Field is the UK's hacky camp. I spent most of that learning to fly. Before that, I'd spent about two minutes on a mate's helicopter in his front room. It's a little bit wobbly at this point. I got better. This was not his maiden flight. This was a few days afterwards, but it was still very much a new thing for me at the time. A year after that, I had an unfortunate accident. You write something like that, there's going to be bugs in it. One of the bugs was with the sensor fusion or possibly the sensors. I'm not sure. Something around that area. That caused it to have incorrect ideas about its attitude. I'd be flying around like this and all of a sudden it would think it was there and try and correct it. Or think it was there in this case and try and correct it. Then you push forwards on the stick and try to make it go back. Then you reach the edge of the control authority and you're still trying to figure out what the hell is going on. It's behind you. You've lost orientation. Oh crap, there's a body of water in the dock behind me. Oops. This version has a black box. Flight data recorder has a microSD card on it which probably makes it one of the only black boxes that is actually black as you might know. On real aircraft, the black box is usually orange so that they can find it after the crash. What debugging techniques have we got? Up until that point, observation was really the only one. I'm flying it along. I'm seeing it do something weird. I'm having to push the stick forwards and it's still going backwards. That's great information. Flight data recorder records every single iteration of the control loop, what the sensor values were every single time round, what the internal state was every single time round, what it sent to the speed controllers, what it got from the radio. You get way more on the flight data recorder than with telemetry and then you don't have to deal with radios and recording it at the other end. This will produce tens of kilobytes a second of data, which you can then analyse later on. The great thing about that is you can throw it at some sort of simulation. In this case, I took some real flight data and the one on the left is the attitude that the quadrator thought it had at the time that it was flying. The one on the right is a slightly different sensor fusion algorithm so it's tuned slightly differently. This is a comparison of the two things. You can see it over time. You don't get to see the whole flight, the whole 56 minutes of this, but over this short period you can already see that they're drifting apart. That made it a lot easier to debug the system, especially the sensor fusion part, because when you can take the real data, throw it at an algorithm and see what comes out and see how different it is to the existing algorithm, it just saves you so many flights and so many crashes. I built this for the visualisation primarily and then I just added another thing to the side of it to take the data from a slightly different place in order to model the new algorithm, the new code. You can see it's really different now. You need quite a lot of stick to correct that. We're here to talk about open source stuff as much as anything else. What about this project? The flight control software is open source. It's not particularly useful because it's tied to this hardware at the moment. The microcontroller itself is quite an old one. It's an ARM7 based microcontroller. It's quite small, 32K of flash, 8K of RAM. I'm still not quite sure how I managed to deal with an SD card with only 8K of RAM, but somehow I do miss bits because the buffering is not all that, but it does mostly work. Now the hardware is a different question because it's not exactly produced in a CAD package. The electronics on this one, it's a slightly different set of sensors. The gyrion accelerometer combined into one sensor, which is the MPU 6050, which is quite a common one. There are other ones that are more common now, but certainly when I rebuilt this around 2013, that one was easily available and it's a pretty good chip. I've got a couple of other things. I've got a barometric altimeter and I've got a magnetometer on it. They're not doing anything other than just logging their data to the flight data recorder, but I did have a go at getting my head around the maths of magnetic fields. I also made the mistake of putting the magnetometer near the speed controllers, which are switching 30 amlas each. That might not be the most accurate sensor in this configuration. The electronics really is a case of, this signal, this I2C device, needs to be connected to the I2C bus. This goes to the UART. The board really was just a case of his a bit of variable. Put these in roughly these places and just wire something up. There isn't really a design that I followed for that, apart from what needs to connect to what. It's a little bit hard to describe that in any sort of downloadable format. The best documentation I've got for this at the moment is photographs. If I crash this and need to recreate it, I will be looking at my photographs to try to figure out how I made it. Largely, the same goes for the frame. Last time I had to rebuild this after a crash, I did actually go and get a ruler out and measure where I'd put the holes and try and sort of write it up in a bit of a text file to jog my memory. Oh, yeah. The problem with something like this is if it crashes like that, all the force is going to bend this arm. When that happens, well, it's aluminium. You can't bend it back because it will just snap. I tried that. It didn't last. You really have to strip it all right back to the bare metal, make another arm, put it in, and put it all back together. It's quite a laborious process, and so I try really quite hard not to crash this. So there's sort of a text file that has some notes in it from which I could work out how to rebuild it, but I haven't written it up in a state that I think that other people would have a chance of following. So, you know, if it were in a downloadable format that would actually be useful, it would totally be open source, and if anybody actually wants that text file I might have to talk you through it, but feel free to ask for it. But, um, yeah, you can buy off the shelf frames and they're a lot better than this one. So this... So this is really only going to be if you want something this sort of size. Now, the great thing about this sort of size is that people find it scary, hence the name Whirlyblades of Death. And if you want to join me in the skies with something that looks as scary as that, be my guest. I'd love that. I am working on a new version of the flight controller hardware. I haven't finished it yet, partly because I had some open source restrictions when my previous company was taken over, so there was only so much I could do at that time. And partly because I've got some kind of hare-brained ideas for features that I'd really love to put on it. So I'm finally going to get round to doing it when I knock some of those ideas out of my head and decide that they're going to take me the next decade to do if I don't just get on with it. And my goal for this one is to make a PCB in a standard form factor, which I can then put into a smaller quad. I've actually got a smaller quad at the moment as well, which is mostly off-the-shelf components, including an off-the-shelf flight controller, mostly to make sure it all works. And my goal is to replace that flight controller with my own design at some point. This is a lot more accessible to me now than it was a couple of years ago because I now have a bit of experience with designing PCBs in KeyCAD. And I have a reflow oven and a controller for it that is part of my experience of building PCBs. So I can do surface mount assembly now as well. So, yeah, what's this space? We may well end up with a much smaller flight controller and you might see that online at some point. It's not going to be soon, but eventually. So I'm just going to give you a little video to play you out. And do we have time? Yeah. So if we have any questions, then I'm happy to take them while we play this down.