Small can be beautiful

[FilmBuff]

Does the flight controller include a GPS sensor?

[Biggles' Elder Brother - Moderator]

No, you will have to buy a GPS unit such as the Crius CN-06 which will set you back the outrageous amount of £12 or so!

You can have a look at someone fitting a GPS to a MicroWii in the video below. Notice this guys MicroWii is the model of about 18 months ago and so is slightly different from the one we are using here. He also talks about updating to version 2.2 of the software, whereas we are on version 2.4 now. The modern board makes things a bit easier, as the one I'm using here has a FTDI interface on board already and so shouldn't need the little intermediate translation board to link to I2C that he is using (as far as I can see - but I haven't tried this yet!)

If you take a look at the GUI screen I posted yesterday you will see (in the bottom right hand corner) that everything is set up ready for GPS, so that once we get it on board we can implement all the usual GPS goodies like RTH and loiter etc.

BEB

[Biggles' Elder Brother - Moderator]

OK - onward and upward, time to start connecting everything together. First we need to examine the geography of the MultiWii, via a pin out diagram:

This diagram is supposed to come with your MultiWii but mine didn't have one (HK please note ) but no big issue, there are plenty of copies on the internet - and there is one more now!

We are going to start by connecting the Rx to the FC - take a look at the upper right hand corner of the board and you can see this is pretty straight forward. Just connect the appropriate channel of your Rx to the right set of pins and they are labelled on the board as well - very very small!

So when you have done that it will look something like this:

Now the next step is to connect the ESC's to the FC. This is just a tad more tricky. Have a look at the pinout diagram and you can see that the 4 motor connections are along the bottom face, shaded red, and labelled; D9, D10, D3 and D11. But which motor is which? You have to get this right or the FC will try to speed up, say the lower left motor to correct and will actually speed up some other motor!

Not to worry - help is at hand. Go back and take a look at the GUI, particularly have a close look at the little moving icon of the quadcopter, here it is in close up:

You can see the arrow indicating the front and numbers on each of the rotors. This tells you what motor you need to connect to which pin on the board. So, the front right motor goes to pin D10 and the back left motor goes to pin D11 and so on. Be careful doing this - you must get it right.

So, making all those connections we get something like this:

And from above the two sets of connections look like this:

One of my out of focus ones - but I'm not tall enough to get the camera far enough away! Anyway - hopefully you can see the general idea.

So, that's all the connections made. Time to bench test it all out!

BEB

[Biggles' Elder Brother - Moderator]

Right, we now need to check that everything is talking to everything else.

First thing to emphasise here is that the motors are not connected to the ESC's. The ESC's are connected to the FC but not the motors. This is because while we think we have done everything correctly, we can't be absolutely certain, so better safe than sorry for this first control test.

So with the quad connected to the computer via the USB and the GUI running, we turn on the Tx and then connect a flight battery to the quad....its all in the video below....

So in that test we established several things:

1. That the radio link was good.

2. That the Rx is talking to the FC

3. That we now know the range of pulse widths the FC is seeing on each channel.

Why is it important to know the range of pulse widths? Well when you plug in the flight battery in any MR the ESC's do not automatically arm, as they would on most aeroplanes. Arming is a specific operation with multi-rotors. This is a basic safety feature. The video below shows me testing that this quad will arm and disarm the ESC's...

If your Tx cannot get the pulse width down to to at least lower than 1100 and up to at least over 1900 then the system will not arm. The MicroWii only recognises values outside that range as min or max for arming purposes. The first video shows that the values form my Taranis are well below 1100 and above 1900 - so I have no problems arming the system.

What should you do if your values don't pass this range test and the board won't arm the ESC's? That depends on what Tx you have. On the Taranis its very easy because we have a "servo" tab in the OpenTx Companion software and you can specify exactly what min and max pulse widths you want - so you can type in 1000 and 2000 and all will be well. If you are using a different Tx - one that is more "standard" then basically you going to have to adjust end-points "blind". Move the end point, look at the GUI, read the value; if it is still not low, or high, enough then move the end point again and so on. A bit laborious but you will get there in the end. You could try just dropping the throttle trim a bit - but that definitely is a bit "hit and miss"!

Well, its time to connect those motors up.

BEB

[Nev]

This is the simple version right ?

Actually BEB the explanations are very good but a bit daunting when you haven't any parts to play with yet.

Nev.

[Biggles' Elder Brother - Moderator]

So we connect up the four motors and arm the system - still no props on of course. This board, unlike many others, actually spools up the motors to "idle" on start-up. This is OK for day-to-day operation, in fact its quite handy, but its a bit of a pain if your trying to check if the motors are spinning in the right direction!

I did the old track of sticking a small piece of tape on the end of each shaft to make it easier to see the direction. So how do we know the right direction? Easy - back to the icon of quad in the GUI

As you can see there are little red arrows indicating which direction the rotor has to go. Actually it doesn't matter if they are all reversed (as long as they are all reversed). What does matter is that they have to alternate directions so as to ensure the reaction torque cancels out. Quads yaw by deliberately accelerating one pair rotating in the same direction and so creating a net torque.

If some of the motors are going the wrong way its just the usual business of swapping any two of the three leads.

Next we have to fit the props - remembering to respect the direction of rotation of course. I ordered a few spare sets as the reviews suggest this quad is fond of breaking props and took the opportunity to get some nice contrasting ones - aiding orientation. We'll add a few more orientation features later as well. So, here it is, props fitted and motor cables tidied. All dressed up and ready to go...

BEB

[Biggles' Elder Brother - Moderator]

You're spot on Nev - it really is much simpler actually doing it than reading a description! In fact it takes longer to do the posts than the building! I can only say, have a go, you'll be surprised how straight forward it is once you make a start.

I couldn't wait - I just had to have a little fly! So I sneaked it into the garden and we had a short hovering session. It went quite well and established that everything seems to be working fine. But it was very unstable - real handful to fly! This wasn't unexpected - the feedback gains are "as out of the box" on the GUI and pay no heed to this particular MR and its characteristics. I haven't altered them at all! So the next stage will involve us getting to grips with a bit of control engineering!

BEB

Edited By Biggles' Elder Brother - Moderator on 12/05/2015 22:13:14

[Biggles' Elder Brother - Moderator]

Someone has asked for a clearer version of the "overhead shot" so here it is - taken outside in better light with me standing over it!

BEB

[Biggles' Elder Brother - Moderator]

Hi everyone,

so we know it flies - but its not sufficiently stable to fly comfortably - even by the normal standards of an MR in manual flight mode. Frankly its a bit of a "tiger by the tail". So how are going to improve matters? Well we have to tune the control system to suit the mass and power characteristics of this particular quad. Have a look at the image of the GUI below:

At the top, just to the left of centre you can see the letters P, I & D these are the control parameters. The control algorithm used in this board (like most others) is a what is known as a PID Controller. Now if you are familiar with PID controllers you can skip this bit - if you're not then what follows is a just a simple description of what a PID controller is and what it does.

What are we trying to do here? Well imagine our quad is flying and we take our hands off the sticks, we'd like it to make a decent stab at staying level and reasonably under control. Now if there was absolutely no wind, or any other disturbance at all it, might manage that. But those ideal conditions never exist. In reality there will always be a disturbance: a puff of wind, one motor has a tiny speed "wobble", there as a stream of warm air (Ha! we should be so lucky!). You get the idea.

So the quad reacts to this disturbance, maybe it tilts a bit to one side. Now the quad "looks" at where you have the sticks, they are still in the middle, so the quad thinks "I should be level", but then it "looks" at the data from the accelerometers and gyros - and they are saying "You're tilted" - er,...but I should be level!

So now there are two "states" - the state the sticks say should be the case (i.e. level) and the real state which the sensors are reporting on (i.e. tilted). There is a discrepancy - an error - between the desired state and the real state. The function of the quad's control algorithm is to try to eliminate this error and automatically put quad back where it should be.

How can it do that? Well, that's the next post!

BEB

 

Edited By Biggles' Elder Brother - Moderator on 13/05/2015 20:43:45

[Biggles' Elder Brother - Moderator]

It's helpful to view these two states we have on a diagram. So let's look at the diagram below:

 

--------------------------X-----------Y-------------

 

In this diagram the line is all the possible states. 'X' is the state we want - in the case we were talking about above its a level quad. 'Y' is the actual state the quad is in - i.e. tilted, which the quad knows because the gyros and accs are telling it that. The distance represents the difference, or error, between these to states. Note - the distance doesn't imply the quad is out of position, we have no GPS yet so the quad can't understand the idea of being out of position, it just understands being level (via the gyros) and being pointed in the right direction (via the magnetic compass). The distance on the diagram just represents the fact that state 'Y' is not the desired state 'X' in some way by some degree indicated by the distance between the points. So big tilt, big distance etc.

So, if we can eliminate the error between 'X' and 'Y' we will bring the quad back level or pointed in the right direction. So how might we do that?

Well we could apply a force on the quad at 'Y' in the direction of 'X' that was proportional to the size of the error between 'X' and 'Y' - big error, big force; small error, small force. This sounds a good plan - and it is. But there is one fly in our ointment. The quad has mass and so it has inertia. This means that it can't start or stop moving instantaneously - it has to build up speed and slow down again over some time period. The consequence of this is that if we apply a correction force, which is proportional to the error, things will only change gradually at first. By the time things really do start to change it really gets a lick on! So much so, that when it reaches 'X' - and the system zeros the correction force - it's too late! The quad goes straight through 'X' and out the other side! So now we have this:

 

--------------Y-------X-------------------------

Things are better (hopfully!) but still not good, there is still an error only now it in the other direction and maybe a bit smaller. So the whole thing starts again. But again we shoot through 'X' and out the other side - maybe, if we are lucky by not so far - but even so. The result is the system will get to 'X', eventually, but via a series of oscillations. Not good - we'll have a wobbly quad!

How can we solve this? Well we could smooth things out if instead of just taking a single proportional value to calculate the correction force, we based the calculation on an average of, say, the last ten values of the error. Remember, the MicroWii is measuring this error several hundred times per second. Will this help? Yes it will - but it gives us another problem. The correction is now quite fast when the error is large - but it will take a long time to eliminate the error completely. This is good - but sluggish. There is another problem, the correction is based on the average (or integration) of the last ten measurements of the error - so its mainly based on the past - only the tenth and last reading is an up-to-date one and that is outnumbered nine to one! Wouldn't it be better if we could calculate a correction based on where the quad will be in the near future?

Well, we can! We can work out the rate at which the error is changing and so predict the future! We do this by differencing sequential measurements of the error - to work out how fast the error is changing. This differentiation gives us an estimate of what the quad's state will be a fraction of a second later. Sounds great eh? But there is a problem - there is always a problem. Working out these differences has the effect of massively amplifying any noise in the data, and there is always noise in the data. So, for example, if the quad has a little glitch and twitches this spike will show up as a massive difference and the system will inject a very big, and totality unnecessary, correction force!

So, all this doesn't sound so good, proportional control has its problems, so does integrative (averaging) control and so does differential control - or can we save the situation? Let's see how we can use this in the next post.

BEB

Edited By Biggles' Elder Brother - Moderator on 13/05/2015 20:48:42

[Biggles' Elder Brother - Moderator]

So, a PID controller, which is what our quad uses, mixes these three mechanisms. Trying to get a nicely behaved system by using the good points of proportional, integrative and differential control by blending them together; a teaspoon of proportional to get a nice quick response, a pinch of integrative to smooth things out and a smidgin of differential to avoid overshooting!

OK, its a bit of a simplified explanation, but hopefully it will give you some idea of what is going on.

The numbers under P, I & D in the screen below determine the balance between the different control strategies and the absolute strength of the correction. As you can see we can have different recipie (set of numbers) for roll, pitch, yaw etc. This is because the dynamics of the quad (how it reacts to changes) are very different in pitch/roll than they are in yaw.

So, what numbers shall we put in there, at least as starting values? Well for that you'll have to wait until the next episode!

(Oooooh, it's cliff hanger!)

BEB

Edited By Biggles' Elder Brother - Moderator on 13/05/2015 20:50:43

[Biggles' Elder Brother - Moderator]

So, to selecting the PID values! But before we do, we have to set up a couple of things.

First the quad has to be running like a well-oiled sewing machine! As little vibration as possible. Vibration will be picked up by the accelerometers and manifest itself as noise on the signals. With that present we'll never get the PID's set up. So tighten everything up and balance the props etc and make sure your happy she is running nicely.

Next we have to calibrate the accelerometers so they will give the correct values. This is very easy. Just place the quad still and dead level on the bench, connect it to the computer and fire up the GUI. Then press the 'CALIB_ACC' button and wait until the numbers in the bottom left hand corner of the GUI stop flashing and changing. And that's it, done.

Now we can calibrate the magnetometer - magnetic compass to you and me! We don't need this for the PID set-up, but we might as well do it now while we are fiddling around. With the quad connected to the GUI again, press 'CALIB_MAG'. We now have 30 seconds to rotate the quad about all three axes: end-over-end, side-over-side then finally a pirouette!. Once all the flashing stops - we're done.

Now at this point I hit a snag. I'm no master navigator, but I do know which way north is from my shed! So I plonked the quad down on the bench, pointed roughly north,....and the

Edited By Biggles' Elder Brother - Moderator on 15/05/2015 00:10:32

[Biggles' Elder Brother - Moderator]

compass said 'west'?????

Much head scratching and a bit research later I realised that this is a bit of a MicroWii "feature"! But not to worry - there is a fix!

We have to add a line to the code. So open up the Arduino IDE and go to the config header tab as before and add the line:

#define MAG_ORIENTATION(X,Y,Z){magADC[ROLL] = -Y; magADC[PITCH] = X; magADC[YAW] = Z;}

Save the code, set the COM port (as before) then Upload the code to the board. And, hey presto, the compass is fixed! North is north again.

Phew!

We now need to calibrate the ESC's. These days on a single engine plane I find that you rarely have to calibrate the ESC for your Tx's throttle. But with four ESC's all linked to the same throttle - and your balance intimately linked to the fact that all your motors are working exactly together - you'll find its much more common with quads that you need to do the calibration. To tell the truth I should have done this before flying it the other day - but I'm lazy and impatient!

So, how do we do this?

Well there are two ways. the old fashioned way involves disconnecting each ESC from the flight controller and connecting it directly to the Rx. Then we calibrate as we would in a plane - Tx on, wide-open-throttle, connect the quad to the battery, bleep, bleep bleep, then drop the throttle and job done.

This works - but it is very time consuming and boring! Luckly the MicroWii has a trick up its sleeve! If we uncomment this line in the code:

#define ESC_CALIB_CANNOT_FLY

then save and upload. Now doing the same as above, you can calibrate all four ESC's in one go! Make sure the props are off when you do this!

You MUST now re-comment the line above - you must not leave it in place. Again save and upload - in effect putting the code back how it was - but now of course with calibrated ESC's!

[Biggles' Elder Brother - Moderator]

Now, we can finally get to the PID! Quads are symmetrical so in all of what follows we will do the same for ROLL and PITCH. We'll also do it the same for YAW, although eventually we will change that.

The most important and influential of these is the 'P' value and for quads in this weight bracket a value of between 3 and 4.5 is generally good. So, to start set P=3.0, I=0, D=0 and fly it. Just a quick take off and 30 sec hover is all that is needed. How did it feel - OK? In that case, land and up the P value to 3.2, then hover again. Still OK? Then wind up it to 3.4 and hover again.

Keep doing this until when you take off the quad goes into a shimmy - a rocking oscillation. P is now too big. So set it back to last non-oscillating value. And that's the first stab at P done.

Now we move on to I. Again for small quads like this it will be somewhere around 0.03 to 0.045. The bigger I is the smoother the quad will be, but the less responsive it will be as well. By trial and error I found I liked 0.035 Again this will do us as "first shot" at the value.

Finally D, well we can't really set D until we have the level-lock flight mode set up. This is because the best test for D is to move the stick full throw and then let it snap back. If D is right the quad will quickly snap back level without wobbling unduly. But setiing flight modes is the next thing we'll do. To be honest you could leave D=0, but we might as well take a pot at it. It will typically be in the range 10 to 20, so I set it at 15, the mid point.

Once you have this in the quad, connect a battery and hold the quad at the bottom. Take a very firm grip! And be very careful - we are going to fire this up while we are holding it - keep your fingers and your forearm well out of the way!

Arm the quad and lift the throttle to about half way. You should feel the quad go "light" in your hand as its close to hovering thrust level. Now gently rotate the quad a little to dip and return the front right arm. The quad should resist you by speeding up the front right rotor. This resistance should be very strong. Don't try to hold the arm down - the quad will start to really fight back if you do that. Just dip and return and feel resistance.

If the resistance is very strong - that's excellent.

Now - go fly it! I found it was much better now than last time. Smoother and more controllable. Its a bit too sensitive on the controls for my taste, but we'll discuss how to change that soon.

Out of curiosity I went back to see how much I had changed PID from where they were yesterday, the answer is very little. Now its true that small changes can make a big difference, but I think the calibration of the accelerometers and the ESC's in particular played a big part in improving things too.

Now for Tx-prograrmming jockeys (read Taranis owners!) there are stick movement sequences for changing P, I and D without using the GUI, so it should be possible, with a little Taranis magic, to set up the Tx so that these values can be altered in the air for fine tuning. And we will need to fine tune - these settings are just a good starting point really. As you get to know the quad you will make small changes.

Next we want to use some of the pre-programmed flight modes of the MicroWii - so I explain what they are and how to do that. I'll also explain how to make the controls a bit less sensitive.

BEB

[Biggles' Elder Brother - Moderator]

Its time to set-up the flight modes and then we'll be able to fully test the PID values. I think the easiest way to explain this is in a video and actually show it. So, here goes,...

Once 'Angle' is selectable you can do the 'tilt-test' for the PID's that I explained in the previous post and you should get that stiff resistance.

I gave the quad a flight test after making these adjustments, and I can report that its very stable indeed - a real pussycat. For me 0.3 on the rates is a bit low - so I'll reset that to around 0.6 for the next flight which I hope will be just nice - reactive and agile without being too sensitive. But I'd definitely recommend 0.3 or thereabouts if you are new quads as a starting value. It keeps things nice and calm and means you will be able to experiment with full manual mode at an earlier stage in your personal learning curve.

Note that if you want to use AUX2 you do have a make a few changes elsewhere to activate it - but I'll go through those another time - having AUX2 will be necessary once we have the GPS on board.

I've just ordered a GPS module for this quad. I've gone for the well known Crius CN-06. Currently this is on EBay here at £12.90 and delivery is promised for next week - let's see! Needless to say I have no connection with this seller - he just happens to have the module and be in the UK.

So far then, in round figures, the basic quad was £63, the MultiWii Flight Controller was £18 and the GPS module £13. I make that £94 in total. Not at all bad for a quad of this level of ability and sophistication.

We'll take a short break now while we wait for the GPS to arrive and then I'll go through fitting that and setting it up with more flight modes. In the meantime if anyone does have any questions/comments or observations please feel free to add them!

BEB

[Chris Bott - Moderator]

Hi BEB - just thought I'd say - we're still watching, just not sure how to contribute.

Hopefully I can chip in when my parts arrive.

Meanwhile, just keep it coming, it's fascinating stuff

[Nev]

I've spent the last couple of nights resurrecting an old laptop and downloading the programs, if I can find a mini usb cable instead of the micro cable I ordered and get the drivers installed I might be able to get the board connected tonight.

This is very much new territory for me but it's a good challenge and something to think about, cheers BEB. When I get some life in the board I'll start building.

Nev.

[Nev]

Well I fell at the first, laptop ( windows 7 ) couldn't find / install the driver. Board lights up and flashes when you move it but no driver no connection to the laptop.

Just been reading the arduino forum it seems a common problem. I'll try and find / install the driver again tomorrow but I don't really know where to go now.

[Biggles' Elder Brother - Moderator]

First of all try this just to double check the method Nev:

BEB

[Biggles' Elder Brother - Moderator]

Here is the actual driver if you have to do this manually - its a bit of a faff. Mine went in automatically (albeit very slowly) so I haven't done it this way myself.

BEB

[Nev]

OK I think we're are back on the horse, thanks for the encouragement there BEB. It didn't work first time, looked promising and went through the searching, installing boxes but failed at the end. Every time I plugged it in after that the PC just didn't recognise it. I'm no expert but I looked in control panel under device and searched for the ft232 but it came up driver not installed code 28 ?
Anyway after a bit of messing I happened upon "apply fix" box and clicked on that. This time it installed properly ( probably took 15 mins ) and assigned Com 3.
So now I can start up my GUI, click Com3, click start and away it goes. Hurrah.
Now I have to put the toys away and do gardening or something.

[Biggles' Elder Brother - Moderator]

I'm afraid that's how it is with this stuff. If you buy a top end commercial drone from someone like Parrot or DJI everything will be PNP. No problems. But they come with a £800 plus price tag, say for a Phantom, and if you look at something like an Inspire well be prepared to spend over £2,500!

The thing here is we will build a drone that can do most of what these expensive ones can do - but at a fraction of the cost. Also we will have the advantage that its not a 'black box', we put it together, we know how it works. This is the quad equivalent of building from plans!

The price we pay is that we have to fiddle about and be prepared (as Nev has done) to preserve a bit. The main challenge is that the documentation is not all in the box! It is in reality spread all over the internet and you have to be prepared to go looking for it! There is plenty of it - so if you look you'll always find what you want - in the end! But there is no doubt this is a bit more of a challenge.

Personally I find the "fun of the chase" a plus point! And with a group of us working on this board we can of course help each other, so that will speed progress.

Anyway - glad you got it going Nev, the fun starts now!

BEB

[Biggles' Elder Brother - Moderator]

While we are waiting for stuff to arrive I'd like to share my ideas on exactly how I think we are going to connect a GPS system to this quad. I have to emphasise that I haven't used this particular board before so what I'm saying here is how I understand we'll do it, at the moment!

First we take the GPS receiver itself. As I've said the one on order is a Crius CN-06 (cost £12) and it looks a bit like this:

As you can see it has four connecting wires these are basically: a data send, a data receive, a positive power feed and a ground. This unit outputs its data in a serial format at 115200 baud according to a protocol called 'ublox'.

The slight catch is that our flight controller can't handle ublox! So we need a translator to sit between the GPS and FC. This is not unusual. The translator I plan to use is one of these:

This is a tiny board. It has another 328P processor on it (just like the one on the flight controller itself) and its job is simply to translate the output from the GPS in ublox to another serial format called I2C which the flight controller can understand. So this goes between the GPS unit and the flight controller and you can see that the two connectors on it are labelled 'GPS' and 'FC' accordingly. This board costs £3.29 and you can get one off EBay - although you can't seem to get one from a UK supplier at present - you will have to order it from China. It comes with two leads, one for each end, and a pin array. I'll explain what the pin array is for next.

So now we need to connect this to the Multiwii. If you look in the top left hand corner of the Multiwii board you will see some pin-holes labelled 'A4' and 'A5'....

This row of four pin-holes is a I2C interface and it is to here we will coonect the lead from the translation board. As you can see we will have to solder the pins in for the connector - and those are pins provided with the translator board I mentioned above.

So, when we put it all together I envisage it will look like this,...

In that picture it is not the same flight controller board as is being used here - but I believe that the general arrangement will be the same.

We will almost certainly need one more bit of kit - an FTDI adapter. The Multiwii we are using here as a built in FTDI - this is the USB interface at the side of the board we are using (shown in the top centre of the board diagram above). But neither the translator board nor the GPS unit itself have one of these fitted.

Why do we need it? Well we will most probably have to make some very small changes to the firmware on both the translator board and the GPS. The sorts of things I mean are:

1. Setting the baud rates the same

2. Setting the GPS to use Ublox and not some other protocol.

These are simple changes - again they will involve just commenting out and uncommenting some lines from header files - but to do them we have to be able to connect the units to the computer - and for that we will need an FTDI adapter like this:

Again we can buy this on EBay - it also costs £3.29 (why do all these things cost £3.29?). Our mini-USB plug from the computer goes in one end and the connector from either the GPS or the translator board (depending on what we are reflashing) goes in the other. Piece of cake! (Who am I kidding? Seriously - it won't be too difficult. Fiddly yes, difficult it shouldn't be ).

So, that's the plan as it stands in my head at the moment. Let's see if it all works!

BEB

[Nev]

Any other little nuggets you think we might need to buy coming up. I don't have a problem buying from China especially for less than the cost of normal postage and now I know my board works.

I've had a drink tonight so haven't tried altering the program, I'll have a go at that tomorrow when the soaps are on but looking at flight modes. I have a basic 6EX with 2 x 2 position switches, so I'm thinking, as a beginner, go for your "angle" and "stable" modes as a starting point on switch 1 and I assume all I can do with switch 2 is switch in a gps hold. Or can you have it hold on position 1 ( when you let go of the sticks ) and return to sender on position 2.

Sorry if I'm jumping the gun a bit here but I'm quite enjoying this, something different to think about.
Nev.

[Chris Bott - Moderator]

Hi Nev

Other things I can think of are the double ended servo cables to connect between Rx and Multiwii, they didn't come with my controller. Then just for completeness, there's the connector to suit your LiPos and of course LiPos.

Bu that's about it as far as I can see. BEB may have other ideas of course.