MultiWii quad driven by on-board Raspberry Pi (originally 486 bifferboard) with Wifi, webcam, GPS and 3G.
Communicating with custom Ground Control Station, showing quad location on map using GPS, webcam output, and showing the many stats, such as the battery voltage, current, and total Ah. The GCS also supports changing PID parameters, activation of calibration modes (accelerometer, magnetometer), changes to accelerometer trim and camera position.
Buttons on the GCS enable GPS and webcam.
Side features:
Total flight weight: 1.2 Kg, Motor-motor diameter: 45 cm, Hover current: 12 Amps (3mAh per second)
Battery: 2.4 Ah 4S Lipo, 40C, weighing 250 grams. Static thrust: 3.2 Kg
Flights: 9, Blood lost: some.
The Arduino takes all commands via the serial port, including stick positions. The MultiWii source has been modified to read stick positions (like the bluetooth extension that went into V2.0) with serial packets, and output accelerometer, gyro, magnetometer, voltage, current with small serial packets, at around 15 per second. Lots of other numbers, as received by MultiWiiConf's M serial command, are also sent and graphed at around 3 per second.
The primary role of the software on the Pi (previously 486, Dual USB port Bifferboard) is to interface the Wifi and 3G to the serial port. The Wifi is setup in AdHoc mode and broadcasts UDP packets representing Arduino status data, which are picked up by the Ground Control Station. The GCS then records and graphs the received data. The GCS reads the stick positions and sends them over wifi using UDP packets to the on-board Pi, which are then sent as serial commands to the Arduino.
The Arduino configuration is fairly standard, using the i2c bus for the gyro, accelerometer, magnetometer, barometer. The Arduino also directly drives the webcam gimbal and MOSFET power supplies for toggling Wifi and GPS power - just in-case either becomes unreliable. As a quirk work-around, the Arduino also drives the ENABLE pin of the GPS, as the Bifferboard serial console is reused for GPS serial output but the bifferboard can't tolerate random serial data during bootup.
The prop balancing code uses an additional add-on optical sensor to sense motor position during each revolution, this uses a spare Arduino input pin.
The Bifferboard has 2 USB ports and a 100 meg ethernet port. One USB port is dedicated to the camera (Logitech 9000 Pro, capable of 1600x1200 uncompressed at 6fps, but Bifferboard can only handle 800x600 pre-compressed jpeg). The other USB port goes to a 4 port hub, which then drives the wifi stick, 3G stick, and a USB-serial dongle [http://] for communicating with the Arduino.
EMI from the Bifferboard is enough to swamp GPS signals, so it is useful to prime the GPS by connecting it to 5V for a few minutes before the rest of the electronics is powered. In practice, around 10cm height between wifi/bifferboard/3G hardware and the GPS module was enough to keep a good lock once it already had a lock. The early images show a gap of around 1cm, which is too little and the GPS will loose lock even with a clear sky. Ideally the hardware "stack" of (bottom to top) battery, quad frame, sensors, USB hub, Bifferboard and GPS should be rearranged. It would be better to separate the dense electronics from the GPS, such as rotating the quad upside down and putting the GPS on the new top, ie (bottom to top): bifferboard, USB hub, quad frame, sensors, battery, GPS. To reduce vibration noise on the sensors, it seems a good idea to mount the sensors on the battery - as it is the largest single lump of mass.
The graphs are fairly minimal to avoid over cluttering the screen, you mouse over them to get more information. Most list the current numeric value, with some text saying what it should ideally be. The Amps graph instead pops up a large graph of the same data. The above is not taken from during flying, I'm too occupied to be taking screen shots, it is when static and unarmed - though I've put a flying image in for better effect. Bottom left shows what is basically the AUX1 control, setup to always enable the magnetomer, then enable the accelerometer, then enable the barometer. FEMode refers to what the cursor keys currently change. This example means they change AUX1. Other options are to change accelerometer trim, camera gimbal and pid parameters (which can also be done with the mouse). On the top right is the satellite count and GPS enable button, and under that, C is the camera enable button. Camera enable means tell the Quad to enable its camera, the GCS video reception processes must already be running. The GPS location is pin-pointed on the map (above is a mock-up from openstreetmap.org, the actual map images are from a copyrighted source, so I can't show them here).
MultiWii V2 quadcopter source
Arduino Pro Mini 328 - 5V/16MHz (13 quid @ PP)
ITG-3200 gyro (37 quit @ PP) gyro
BMA180 (20 quid @ PP) accel
HMC5883 (10 quid @ CC) or HMC5843 (16 quid @ PP, 34 quid @ CC) mag
BMP085 (12 quid @ PP, the cheaper version) barom
FTDI Basic Breakout - 5V (11 quid @ PP) programmer/USB-serial
Logic Level Converter (1 quid @ PP)
Maplin N68CA used for 3.3V source.
Hobbywing 3amp UBEC (6 quid @ GC)
XYH 28-30 750Kv 10A Brushless Outrunner (8 quid @ GC)
Hobbywing Brushless Motor 25amp esc speed controller (12 quid @ GC)
XYH 28-XX series Spare accessory pack (1 quid @ GC)
1045R Slow Fly Counter-Rotating Propeller (1 quid @ GC)
1045 Slow Fly Non Counter-Rotating Propeller (1 quid @ GC)
2.4Ah 4S 40C Lipo (x @ EF)
GC - giantcod.co.uk, now giantshark.co.uk, CC - Cool ComponentsPP - proto-pic.co.uk/, EF - Electraflight.co.uk
Wifi on Quad - Ralink rt73 chipset.
3G - T-Mobile pay per day, as much as you can eat.
Wifi on laptop - TPLink xxx (Atheros 9-htc chipset)
USB hub - xxxx
Camera - Logitech 9000 Pro (UVC driver) replaced with Logitech C920
Frame consists of 2 interlocking sticks. Each stick consists of two 10mm x 5mm beach strips, laminated either side of a 10mm x 5mm balsa strip. At the center of the quad the balsa is missing to allow the beach to continue all the way though. A brace is used to support the camera gimbal but doesn't otherwise seem to be required.
Laptop with 1333x768 display. In my case a 1.4 GHz dual core Intel machine.
IO to read sticks - using a serial-USB converter in this case.
Sticks, as used by RC flight sims. Serial output.
Development of this project was started with MultiWii V1.8, the changes were then merged into V2.0.
A 386 Debian environment is used for the Bifferboard. Bifferboard is running OpenWRT
but this project instead using statically linked 486 executables. Each compiles
to around 600k but there aren't many of them. Daemons consist of:
readquad
uvccapture
nonblock
The bifferboard was replaced with a Pi running standard Raspian. The Pi is setup to configure the wifi, the ethernet and the 3G, then run readquad.
readquad is the main Ardunio serial<->Wifi UDP go-between software. It could eventually be used to interpret the GPS output and command the Arduino itself.
uvccapture is a modified version of the standard uvccapture. It has been changed to output to stdout a continuous stream of jpegs (compressed by the camera), prefixed with arbitrary frame number and size of jpeg in bytes. uvccapture also has some built-in controls to turn off auto exposure, and use manual exposure set for daylight. Without this any movement tends to make the images blurry.
nonblock reads the uvccapture stream and calls netcat to open a TCP connection to the GCS (in reality, a separate bash loop that feeds mencoder and mplayer). nonblock monitors the size of the TCP output buffer, and if too much data backs up, it kills the connection and starts another at a frame boundary. It also uses the overly full send buffer events in a feedback loop that skips more and more frames, to try to match frame rate to wifi bandwidth.
bifferboard doesn't have the CPU power for real-time MPEG compression, and the 3G stick doesn't have the bandwidth to send real-time JPEG streaming. The best compromise is to send images as quickly as possible, which means a separate loop to ftp the most recent image over 3G to a named site, at around 0.5 to 1 fps. The camera was upgraded to a Logitech C920, which does on-board H.264 compression, lightening the load the computer and making live video over 3G practical.
Two way comms over 3G, requiring a solution to the latency problems and possibly a TCP connection.
Better camera gimbal control than cursor keys, maybe a few preset attitudes.
Barometer altitude displayed on front end, it appears to be more accurate than GPS altitude.
Track down why magnetometer calibration does not usually work since MultiWii V2 (maybe V1.8?)
Tidy up scripts, convert video receiver bash loop to something more appropriate (ie. faster).
Related, integrate video window and laptop wifi initialisation into GCS user interface.
Separate sending of sticks from the GCS, so when GCS is thinking hard it doesn't stop sending stick positions.
Rearrange quad hardware to give GPS a better signal.
Camera is setup for fixed exposure as auto is too blurry, but it can white out in bright sun. Needs feedback from GCS.
FPS counter on video.
Other stats on video screen, maybe option to replace GPS map background with fullscreen camera.
False horizon and front/back marker on video.
Correct the various X,Y instead of Y,X graph orientation and log file errors.
Add an extra level of arming to the motors. When doing this much testing, premature arming is bad.
All images can be seen in the image gallery. A flight during winter can be found here.
Source code is available here.
Note: It is not designed for public consumption. Rough edges are everywhere.This project has been built up over two years, with sections tested (such as the camera to bifferboard to wifi to laptop pipeline) before the quad was built, which was all before the GCS was written - though the GCS itself was modified from an in-car GPS system written in 2002 (with a Celeron 400 driving it, which really dates it).