This is my rendition of a small indoor quadcopter, strongly inspired by Jose Julio's work
My frame design pretty much follows Jose's approach, except that I only have one square base plate in the center (it looks rather unfinished on the bottom because of this ;-)), and I did not get the correct size stand-offs to use as motor mounts, so I machined my own out of Delrin plastic.
The electronics are completely home-built, with no direct relation to the Arducopter project (probably not hard to tell from the rats-nest of wires in the picture). The main board is basically a 2x2 inch proto board with a socket for an Atmega328 and a few supporting components (voltage regulator, 20Mhz crystal and a number of pin headers to plug in ESCs and other sensors and power distribution). The IMU sensor is the red stick seen on top of the Atmega328, a 9DOF (Acc, Gyro and Mag) Sparkfun I2C sensor stick. Other sensors present are an MTK GPS receiver from DIYDrones, a BMP085 barometric pressure sensor and (underneath, not visible in the picture) a Mabotix sonar.There is also voltage monitoring of the main battery.
The custom software is an Atmega fork of my other quad project, it currently squeezes the (quaternion-based) IMU code, RC decoder (for regular RC receivers, currently not used, see below), telemetry downlink, on-the-fly adjustable parameters, navigation (currently only position-hold, really) and general control code into ~30K of flash. The inner loop runs at ~350Hz (keep in mind that the Atmega is clocked at 20Mhz, though) and the ESCs are updated at 400Hz.
The most interesting part (to me at this point, anyways) is the small silver component to the bottom left of the GPS receiver: this is a Sparkfun RN-41 class 1 bluetooth module used to communicate with and control the quadcopter. The actual control/remote control software is also home-built and runs as an app on my Android phone:
In the picture above you can see the main flight controls: the two red circles react to touch and basically mimic the functionality of the two sticks of a mode-2 remote control. There is an alternative 'accelerometer' or tilt-mode in which the user only controls the left, throttle and yaw stick while the right stick (pitch and roll) is controlled by tilting the phone (I suppose this is similar to the way a Parrot drone is controlled). In the very first picture, you can also see that the app displays a (admittedly very crude) 3D wire-frame model of the copter that moves like the actual copter (via downlink telemetry data). GPS coordinates, altitude and battery voltage are also displayed (probably not in the most ergonomic manner at this point). When the controls are touched, the 3D model fades into the background, which is why it harder to see on the second picture.
It is also possible to adjust various parameters stored in EEPROM on the quadcopter within the app:
How does it fly with these controls? It is actually quite flyable, but the restoring-force of the springs on a proper remote control are definitely missing, making it hard not to over-correct. I implemented a pretty shallow throttle curve in the hover-region of throttle-output which helps quite a bit. In general, it seems easier to fly in 'tilt-mode' than when controlling pitch and roll via the touch-interface.
The way I use the bluetooth connection is basically as a serial connection over which I sent a custom (almost human-readable, not MAV-link, though) protocol. It is therefore almost trivial to hook up a simulator remote (or joystick) to a bluetooth-enabled laptop and use a few lines of Perl (or any other language of choice) to control the quad via that.
Another consideration with bluetooth is range, of course. The module on the quadcopter itself is a class 1 device, which supposedly gives it ~330feet range - but I am not sure about the module on the cell-phone side. One could use a pair of longer-range XBees (plus the laptop-remote/joystick solution) to get an increased range. I have not yet investigated whether the XBee might present latency issues (I did configure the quad-side bluetooth module to work in a low-latency mode).
Anyways, it is mostly a proof-of-concept at this stage, but I figured people might find an alternative control concept interesting...