Designing my first Netduino/Arduino Shield for the Quadcopter


Of the many design challenges for the quadcopter project I’m currently working on, figuring out how to enable the Netduino to control up to nine PWM outputs (for servo control) was certainly one of them. Fortunately, the smart folks at Polulu have created a handy micro-sized board to do just the job. One drawback is that servos tend to pull a lot of current, and I’d already fried my first Pololu control board due to a bit of over-zealous wiring.

The trouble is, standard servo wire plugs combined power, ground and signal all into one neat package. This is great, if you are using your servos in a ‘normal’ way. However, mine are being driven under quite a lot of demand and through a Pololu servo control board, not an RX. In addition, as the power supply on the quadcopter is pretty punchy (60A!) and a little susceptible to temporary voltage drops or current peaks, I wanted to be able to provide a smooth, regulated supply to the Pololu itself, as well as the servos to which it is connected.


  • Futaba-style 3-pin servo connectors provide power, gnd and signal in a single connector:FutabaWire
  • The servo control board has 3-pin connectors, intended for providing power, ground and signal to each servo:


  • I want to split the three-pin output from the servo control board (the right-hand side of the image) so that a dedicated, high-current power supply can provide the power to each servo, yet enabling the signal to be driven by the control board.


I’ve come up with what I believe to be a neat solution to this problem, as well as one that I haven’t yet blogged about: the need to create a power distribution board and sensor input board for each of the quadcopter’s many on-board sensors. My solution is based on the production of a custom-built Netduino shield, which combines two regulated power supplies and a ‘splitter array’ for separating power and signal from the servo cable, as well as space to mount the Pololu controller.

In this way, the Pololu control board will be connected to the three-pin array in the centre of my shield. The signal pin will for each corresponding servo will then be connected to just the appropriate signal pin on the Pololu control board. Thus, a separate power supply for the servos is possible without any cable ‘hackery’.

My first draft design is below:

Quadcopter autopilot board_pcb

In this first revision, I have simply exposed the Netduino’s pins through the pin-compatible holes at the top and bottom of the board. It also features separate pins for D0+1 (COM1) and D2+3 (COM2), and solder pads for the high current power supply. 4600uF electrolytic capacitors are used to reduce noise and further stabilise the supply beyond the regulators as demand from the servos is likely to change very rapidly. In addition, a 5V separate power supply is provided next to the splitter array to power the Pololu board.

Jobs left to do!

This board still needs quite a bit of work. Firstly, the silkscreen layer for the bottom row of pins hasn’t yet been added, and I may also actually breakout the pins into screw terminals to make it easier to hook up my various sensors to the board. If I go down this route, I’ll need to change the board layout considerably as I’ll need to preserve a 3cmx3cm area for the Pololu control board. I’ll also need to add screwholes (for my board as well as the Pololu, so that it can be mounted securely) and then finally, I’ll need to make one and check that it works as planned!

I plan to release the part to the Fritzing gallery once I’m happy with it, so that others may use it.


Autonomous Immersive Quadcopter – Build Log


It’s been a while since my last post back in December (all about Windows Azure, you can read about that here) and a lot has been going on in the interim. I’ve mainly been focused (as always) on work, but in my down time, I’ve been working on somethin’ a little special.

I’ve always been fascinated by things that fly: aeroplanes, helicopters, birds, bees, even hot air balloons and solar wings. Flight gives us an opportunity to view things from a different perspective; it opens a new world to explore.

The trouble is, as a human, I was born without the (native) ability to fly. And that’s always made me a little, well, sad.

A couple of years ago, I started toying with a model aeroplane and my goal at that point was to turn that into a UAV, like so many of the projects I’d seen online. I ended up dismissing the idea, for a couple of reasons: planes are pretty limited (manoeuvrability-wise), and unless you can fly yours incredibly high and incredibly fast, you’re a little limited to the types of cool things you can do. Plus, the open-source autopilots that are currently available are mainly all built using non-Microsoft technologies, and, being a “Microsoft guy”, I wanted to do something about that (let’s say it’s just for selfish purposes: I’m much more productive using Microsoft technologies than I am with something like C on the Arduino platform, and I have very limited time for this project).

So I’ve been working on building a custom quadcopter since January, and I’m very pleased with the results so far. It flies, and in this video you’ll see the first test flight. Toward the end, just before the ‘aerobatics’, I disable the automatic flight stabilisation remotely, which causes even more aerobatics. Anyway, the quadcopter was fun to build, and was a huge learning curve for me: and I really enjoyed the challenge of having to figure out all the flight dynamics, propeller equations, lift calculations and of course, the designing and building of the frame, electrical and radio systems.

But it’s not awesome enough yet, not anywhere near it! In fact, check out some of the plans:

  1. I’m currently building a three-axis motorised gimbal that will fit underneath the main airframe. It is going to be connected to an Oculus Rift virtual reality stereoscopic headset, which will relay movements of the wearer’s head to the servos on the gimbal; thus enabling you to ‘sit’ and experience flight from within the virtual cockpit. My colleague, Rob G, is currently building the most awesome piece of software to power the Oculus’ dual stereoscopic displays, while I finish designing and building the mount and video transmission system.
  2. Cloud Powered AutoPilot and Flight Command. That’s right: using Windows Azure, I will provide command and control functionality using Service Bus and sophisticated sensor logging through Azure Mobile Services. Flight data and video will be recorded and shared real-time with authenticated users. Why? There’s nothing cooler than Windows Azure, except maybe something that flies around actually in the clouds, powered by the Cloud!

I don’t know where this project will end up taking me, but so far it’s taken me on some very interesting journeys. I’ve had to learn much more about:

  • Circuit design
  • Fluid dynamics
  • Thrust and vector calculations
  • Power system design
  • Radio-control systems (on various frequencies: 5.8GHz, 2.4GHz, 433MHz and 968MHz) and the joys of trying to tame RF energy using antennae
  • Soldering

… The list goes on!

Current Activity

I’m already in the progress of building a sensor network on the quadcopter. This comprises of:

  • 5 x Ultrasonic range finders (four mounted on each of the motor arms, one downward-facing)
  • 1 x Barometric pressure (for altitude and airspeed sensing, using pitot tubes)
  • 1 x 66-satellite GPS tracking module
  • 1 x Triple-axis accelerometer
  • 1 x Triple-axis gyroscope

The current plan is to use a Netduino to interface directly with the sensors, and transform all of the sensor data into a proprietary messaging standard, which will be emitted via the I2C interface using a message bus architecture. In this way, the Netduino is able to create ‘virtual’ sensors, too, such as:

  • Altitude (based on either the downward-facing ultrasonic sensor, or the barometric pressure sensor; whenever the quad moves out of range of the ultrasonic sensor)
  • Bearing
  • Velocity (allowing selection of air/ground speed)

The Netduino is an amazing device, however it doesn’t have sufficient capacity or processing power on-board to interface with the radio control receiver (which receives pitch, roll, yaw, throttle and other inputs from my handheld transmitter). For this activity, I’m going to use a Raspberry Pi (running Mono!). The RPi apparently features the ability to turn GPIO pins into PWM-capable pins (either generating, or interpreting), which is exactly what I need.  The Netduino will output the sensor data to the RPi, which will be running the ‘autopilot’ system (more on the planned autopilot modes in a later post).

It’ll be the job of the Raspberry Pi to interpret sensor data, listen to commands it has received from the handheld transmitter on the ground, and decide what action to take, based on the requested input and the sensor data, and the currently-selected autopilot mode. Sounds simple, but it’s anything but!

If you’re not interested in the technical details, you can follow this project on Thanks for reading.

TokenMail is now available on Nuget!


Back in January this year, I wrote a neat little utility library for sending template emails. Tonight, it caught the attention of fellow developer Benjamin Howarth, famous for (among other things) his Umbraco mastery.

After a quick discussion, Ben decided to join me in maintaining the library and christened his membership in the project by adding a new ‘load from URL’ feature. And, a short while later, a package was available on Nuget. Not bad for around an hour’s work I thought!

To download and install the package easily via Nuget, bring up the Package Manager window within Visual Studio and type:

I created the initial version of the library with simplicity in mind: it’s not fancy, or complex. It was designed purely to provide a solution to developers who have to send templated emails in their projects.

Perhaps my favourite ‘feature’ of this library though isn’t really a feature at all, so much as it is actually a by-product of the way it has been designed: because it picks up template files from disk (or from a remote URL), you can easily allow your end-users to modify their own templates using your favourite rich-text editor. Pretty neat.

Please feed back!

I think it would be cool if we could get a little community of users together who could help drive the project forward with further suggestions. Head on over to the project hub at Codeplex to get involved, or download the latest version. And, if you decide to use the library, please, please, please – do rate it on Codeplex and/or drop me a note to let me know how you’re using it. It’s not a requirement, of course, but since we do this stuff for free in our spare time, we love to read feedback.


UAV Flight Training, Round 1


A few months ago, I mentioned that my friend and I were going to start building a UAV. It’s taken us a little while, but I’m pleased to report that over the previous bank holiday weekend we were able to take it out for our first test flight.

This test flight was the first step in our move towards building a fully automated UAV platform using a Netduino. This flight, however, is 100% manual, with no auto-pilot assistance. The objective is to get to grips with manual flight as we need to be able to launch and land the aircraft and take over in the event of an autopilot failure.

Now, bearing in mind that neither of us have any flight experience whatsoever, below is a video clip of some of the flights during the day. There are, as you might expect, several crashes and some very unsettling flight patterns, but don’t worry, as neither I nor anybody else involved have any aspirations to become a commercial pilot. 🙂

Lessons learned

As the pilot, I gleaned some useful insight into the flight characteristics of the platform. Here are my initial thoughts:

  • The stock rudder is way too small to have any authority, particularly with the upgraded brushless motor. It has a control surface of just 2.5cm x 10cm (approx.). In light wind, it was pretty much uncontrollable and at speed, no chance. We later modified the rudder to 6cm x 15cm and are looking forward to testing that out next weekend.
  • After the first crash, the tail completely detached from the body. It was way too brittle and broke in the only place we hadn’t reinforced with glass tape. After fixing, we ended up with a plane that was, well, a bit ‘warped’. That’s fine for our trainer, but in a future version before we integrate the UAV electronics we’ll probably need to embed some carbon-fibre rods throughout the body to improve the rigidity.
  • Ailerons would make the model much more responsive, so we’ve added those too (I’ll probably blog about the modifications in a separate post) and these will be tested next weekend.
  • We should have taken time to balance the centre of gravity properly. This might account for some of the more ‘wild’ elevator action seen in some of the clips.
  • Even when flying into a headwind, very little motor input is required in order to maintain stable flight. I think I only used 100% throttle maybe once, just to see how it reacted.

UAV Online! (For real!)


Those of you who have played Call of Duty: Black Ops, will join me in rejoicing the sound of a friendly yelling “UAV online!”, and likewise the sinking feeling you get in your stomach upon hearing the doomsday announcement of”Enemy UAV online!”.

I’ve always had somewhat of a fascination when it comes to anything that flies. I’ve had four model helicopters (I can’t fly any of them particularly well) but for me the joy was in building these things first, or taking them to bits when they (inevitably) crashed.

Multiplex EasyStar - our airframe

So it ought not to come as any surprise then that, while playing Black Ops a few weeks ago, my friend and I had a rare moment of mental synchronicity when we both declared: “let’s build one for real!”, and to hell with the fact neither of us had any real clue where to start. But that’s what teh interwebs are for!

Black Ops aside, there are a few distinct angles to this project which make for a really fun time:

  • Building the model: learning how to build a model plane and all necessary mini-skills that go with it
  • Hooking up the avionics: speed controllers, batteries and radio
  • Adding a micro controller and accompanying sensors for autopilot functionality
  • Building a wireless telemetry system and making the “ground station”: mixing physical computing with software systems to build a truly mobile

Project Goal

The plan is to build a radio-controlled model aeroplane that can autonomously navigate several way points and take detailed aerial imagery along the way, purely for recreational purposes. We’ll no doubt figure some way of making some sort of game, too. As a bonus, when we’ve figured out how to do that we’d like to add a live first-person video element to the project so that it’s possible to get a “in cockpit” view in real-time.

As with all crazy ideas, the key to success is planning and there’s been no shortage of that over the Christmas period. The UAV plan will be split into two phases:

  1. Build an aircraft, learn to fly it manually
  2. Equip the plane with an autopilot, build the ground station and voila.

Given that neither of us have any fixed-wing flying experience, we figured it necessary to enlist with a local flying club once we’ve built the plane so we learn the basics from the pro’s and join the British Model Flying Association (which also provide insurance!).

Kit List

After extensive forum research and oogling over product specifications, the final kit list is currently still in development but most of it is currently listed on our Wishpot wishlist. This list gets updated all the time as we substitute parts or buy each item. When the aircraft is finally built I will post the final kit list here.

Airframe and basic electronics

To build a successful aerial imaging platform, the key is having a stable airframe and a large cargo capacity. This therefore requires an aircraft which produces a lot of lift and is built more like a glider than a traditional plane: high-wing designs are in and we’re shooting for reliability over performance.

To this end, we settled on the Multiplex EasyStar Kit which was about £47. The kit includes the basic airframe, a standard motor and all moving parts (prop, servo linkages) but doesn’t include a speed controller, radio TX or RX or any servos.

Following forum advice, we won’t be flying the stock motor or propeller. Instead, we opted for a brushless motor upgrade kit (£79.99) which provides us with an Overlander battery, 30A electronic speed controller and a much more powerful motor with a slightly larger propeller.


For manual flying (and later, switching between manual/autopilot), we opted for a slightly more professional Futaba 6 channel system operating on 2.4GHz. It’s super light weight receiver (9.8 grams) is perfect, and being on the 2.4GHz spectrum means we won’t have to deal with pesky ‘crystals’ or interferrance from other modellers: it’s digital frequency control means our controller will always control our plane.


On board power will be provided by 1 x Overlander Lithium-Polymer 2200mAh 3 cell battery, putting out 11.1V. This will be split between the ESC and the radio gear, though in time we might investigate running the radio off a dedicated smaller battery.

The fun part: telemtry and autopilot

Making anything do anything by itself isn’t exactly easy, especially if you want it to do it well. For the auto pilot, we’ve chosen to use the open-source Ardupilot project which is essentially a set of hardware shields for use with an Arduino, together with some open-source software.

What I’d like to look into doing though is porting the Arduino version of the software to C#, for running on the Netduino (an Arduino ‘clone’ running the .NET Micro Framework).

Essentially, the Ardupilot requires themorpiles and an inertial measurement unit (or, IMU, for short) and a GPS. Data from these sensors can optionally be transmitted via a separate on-board radio system to a ‘ground station’.

Our model’s sensors include:

  • XY+Z IR Horizon Sensors
  • An EM406 GPS module
  • Airspeed sensors
  • Barometric pressure sensor

Our telemetry system will beam data back to the ground station via long-range Xbee modules. More precisely, 2 x XBee Pro 50mW modules (Series 2.5 with RPSMA antennas) and a couple of interface boards. These modules have an approximate line-of-sight range of 1 mile in ideal conditions, more than enough for our purposes.

Where are we now?

At this time, the basic airframe has been constructed and most of the equipment needed to build a normal manual flyer aeroplane has arrived and been assembled, with exception to the radio at this point.

Next steps are to complete the installation of the radio and servos, construct the final power distribution harness and then go join the model flying club to learn how to fly. In the mean time, there’ll be some tinkering to do in my spare time to actually construct the Ardupilot autopilot and start adding the sensors. More on that lot to follow in future posts…

Have a great new year!

Hacking an external antenna on to a Thomson SpeedTouch TG585 v7 router


In this post, I will show you how to dismantle your Thomson SpeedTouch TG585 v7 router to allow connection of an external WiFi antenna. This is a very simple process requiring the removal of only four screws.

What you will need

  • 1 x Mini PCI U.FL to RP-SMA Pigtail Cable (~£1.50 each, I bought mine off eBay from this seller).
  • Set of needle-nose pliers
  • Set of mini Philips screwdrivers
  • … The external antenna you want to use! (I purchased this one for £13.99 from Maplin as it has a magnetic base, useful in my particular installation).

Step by step

1. Disconnect the power to your router, and unplug the power adapter from the mains supply.

2. Flip your router over, and remove the four plastic feet/pads from each of the four corners of the router.

3. Underneath the feet are four screws (one underneath each of the pads). Unscrew each one.

4. Lift the router off the table and gently give the base a tap – the grey top section should fall off. That’s the ‘lid’. If it doesn’t come off easily, gently prise it off with a flat head screwdriver; the operative word being gently. It’s not glued or wedged, it just might be a little tight.

5. Turn the unit over so you can see the main board.

Taking special care not to touch any of the solder points or components (especially any capacitors), ground yourself and then remove the antenna wire which is connected to the main board (connector circle below):


You might find a pair of needle nose pliers may help – but the clip is not particular tight or difficult to remove so just be wary of applying excessive force.

6. Now, unclip the existing ‘non-replaceable’ antenna by pinching the inside of the clip with pliers, while pulling the antenna. This will release the antenna and it should pull-out through the exterior of the case as follows:


7. Now, thread your new antenna pigtail cable through the case (where the old antenna used to go) so that the tiny clip is on the inside and the antenna connector (the larger connector) is on the outside. Connect the small end to the main board of the router in the same place you disconnected the old one from.

8. Pop the lid back in to place, turn the unit over and put the screws back in, followed by the sticky feet.

9. Now connect up your external antenna, and you’re all set.

Open-source FTP-to-Azure blob storage: multiple users, one blob storage account


A little while ago, I came across an excellent article by Maarten Balliauw in which he described a project he was working on to support FTP directly to Azure’s blob storage. I discovered it while doing some research on a similar concept I was working on. At the time of writing this post though, Maarten wasn’t  sharing his source code and even if he did decide to at some point soon, his project appears to focus on permitting access to the entire blob storage account. This wasn’t really what I was looking for but it was very similar…

My goal: FTP to Azure blobs, many users: one blob storage account with ‘home directories’

I wanted a solution to enable multiple users to access the same storage account, but to have their own unique portion of it – thereby mimicking an actual FTP server. A bit like giving authenticated user’s their own ‘home folder’ on your Azure Blob storage account.

This would ultimately give your Azure application the ability to accept incoming FTP connections and store files directly into blob storage via any popular FTP client – mimicking a file and folder structure and permitting access only to regions of the blob storage account you determine. There are many potential uses for this kind of implementation, especially when you consider that blob storage can feed into the Microsoft CDN…


  • Deploy within a worker-role
  • Support for most common FTP commands
  • Custom authentication API: because you determine the authentication and authorisation APIs, you control who has access to what, quickly and easily
  • Written in C#

How it works

In my implementation, I wanted the ability to literally ‘fake’ a proper FTP server to any popular FTP client: the server component to be running on Windows Azure. I wanted to have some external web service do my authentication (you could host yours on Windows Azure, too) and then only allow each user access to their own tiny portion of my Azure Blob Storage account.

It turns out, Azure’s containers did exactly what I wanted, more or less. All I had to do was to come up with a way of authenticating clients via FTP and returning which container they have access to (the easy bit), and write an FTP to Azure ‘bridge’ (adapting and extending a project by Mohammed Habeeb to run in Azure as a worker role).

Here’s how my first implementation works:

A quick note on authentication

When an FTP client authenticates, I grab the username and password sent by the client, pass that into my web service for authentication, and if successful, I return a container name specific to that customer. In this way, the remote user can only work with blobs within that container. In essence, it is their own ‘home directory’ on my master Azure Blob Storage account.

The FTP server code will deny authentication for any user who does not have a container name associated with them, so just return null to the login procedure if you’re not going to give them access (I’m assuming you don’t want to return a different error code for ‘bad password’ vs. ‘bad username’ – which is a good thing).

Your authentication API could easily be adapted to permit access to the same container by multiple users, too.

Simulating a regular file system from blob storage

Azure Blob Storage doesn’t work like a traditional disk-based system in that it doesn’t actually have a hierarchical directory structure – but the FTP service simulates one so that FTP clients can work in the traditional way. Mohammed’s initial C# FTP server code was superb: he wrote it so that the file system could be replaced back in 2007 – to my knowledge, before Azure existed, but it’s like he meant for it to be used this way (that is to say, it was so painless to adapt it one could be forgiven for thinking this. Mohammed, thanks!).

Now I have my FTP server, modified and adapted to work for Azure, there are many ways in which this project can be expanded…

Over to you (and the rest of the open source community)

It’s my first open source project and I actively encourage you to help me improve it. When I started out, most of this was ‘proof of concept’ for a similar idea I was working on. As I look back over the past few weekends of work, there are many things I’d change but I figured there’s enough here to make a start.

If you decide to use it “as is” (something I don’t advise at this stage), do remember that it’s not going to be perfect and you’ll need to do a little leg work – it’s a work in progress and it wasn’t written (at least initially) to be an open-source project. Drop me a note to let me know how you’re using it though, it’s always fun to see where these things end up once you’ve released them into the wild.

Where to get it

Head on over to the FTP to Azure Blob Storage Bridge project on CodePlex.

It’s free for you to use however you want. It carries all the usual caveats and warnings as other ‘free open-source’ software: use it at your own risk.

If you do use it and it works well for you, drop me an email and it’ll make me happy. 🙂