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.