Designing my first Netduino/Arduino Shield for the Quadcopter

Standard

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.

Problem

  • 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:

    0J48_200

  • 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.

Solution

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.

Advertisements

Autonomous Immersive Quadcopter – Build Log

Standard

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 hoverboard.io. Thanks for reading.

UAV Flight Training, Round 1

Standard

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!)

Standard

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.

Radio

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.

Power

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!