Marko Kleine Berkenbusch's Posts

Some Bluetooth and Android sillyness...

Posted by Marko Kleine Berkenbusch on October 27, 2011 at 9:13pm

Above you can see a screenshot of my latest hack: a remote control app for an Android phone controlling my mini quadcopter via bluetooth. What is it controlling? This:

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

Marko

Slightly better mouse sensor position hold video

Posted by Marko Kleine Berkenbusch on October 10, 2010 at 11:08am

After some more PID tuning, here is another video of my quadcopter trying to hold its position via the hacked mouse sensor (plus an ultrasound range finder for altitude control).
This was shot about 2 hours before sunset and the sensor already started having some trouble on my dark and fairly featureless driveway in the shadow - that's why I tried to make it hover over a sandy spot that stuck out...

Quad position hold with mouse sensor - some details

Posted by Marko Kleine Berkenbusch on October 4, 2010 at 6:00pm

Hi,

Some people asked for a few more details on the mouse sensor position hold I am experimenting with on my quad (originial post here), so here we go:
As I mentioned in the original post, the sensor is an ADNS 2610 made by Avago. This is a fairly ubiquitous sensors found in many cheap mice - the reason I chose this one is two-fold: there is good documentation available for it (e.g. the datasheet, or just google for it, there are plenty of people who hacked it), and it provides a mode in which the 'raw' 18x18 pixel image can be read out of it, significantly simplifying the setup of appropriate optics.
I ended up not finding a mouse with that particular sensor, so I ordered the raw sensor on Digikey instead. According to the datasheet, 3 caps and 1 oscillator are required in a minimal circuit - all of these are cheaply available at digikey.
Above is an image of my prototype circuit: on the right you see a lens with a screw-type lens barrel from a cheap (around $10 at Walmart, I think) keychain camera, in the center you can see a raw ADNS 2610 and on the right is the circuit itself. The lens I ended up using is not this exact one, but one from a different camera which looks very similar - either one would have worked.

On the second image you can see the sensor again (this time upright), as well as the bottom of the pcb (never mind the sloppy soldering). In the prototype, I basically hot-glued the lens barrel lined up to the bottom of the board and used the screw-mechanism to adjust the focal length (more on that below). My final design looks very similar, except that I used a single-piece perforated circuit board and drilled a 1/4" hole in the center for the sensor aperture - I did not include a picture because it is wrapped in a small, hot-glued foam box and mounted on the quad at the moment, and I am too lazy to take everything apart.

The image above shows the raw image data output of the mouse sensor with the optics adjusted. You can see my hand in front of a bright wall, making the hand itself appear dark. The distance sensor-hand is approximately 0.5 meters (give or take). The image is read out from the sensor via an Atmega which passes it on to a Perl/Tk script via serial. The serial protocol used by the ADNS 2610 is documented in the datasheet and fairly easy to emulate on a microcontroller. Since I knew that the keychain camera lens must have a focal length of a few millimeters, I basically determined the correct focal length by trial-and-error (I pointed it at a dark shelve on a bright wall and adjusted until it was clearly visible). Because the focal length is short compared to the object distance (~5mm versus something of the order of 1m), this setup does a reasonable job at focusing anything further away than 0.5-1m. On the actual quad, I do not look at the raw image data, but let the optical flow implementation on the mouse sensor to the hard work for me and just read x- and y- displacements.
I use the altitude data from the sonar range finder together with tilt information from the IMU to get an absolute position reference.

The mouse sensor rigged in this way appears to work quite well in daylight conditions outside, I have not tried to use it indoors yet (I would imagine one needs a reasonably well-lit environment). I did notice once that the quad seemed to get slightly confused by its own shadow in bright sunlight around noon, but I have not systematically tested this. You can see a screenshot of my GCS during a typical flight above. The window on the left just shows the attitude and other assorted information about the quad (the software is written in Perl/Tk - I mostly use Linux). The window on the right shows the ground-track in position-hold mode as detected by the quad. The blue bar indicates one meter, the trace starts in the center of the cross-hair. It did a reasonable job holding its position, it was a tad windy that day, I think. I am sure with some patience one could fine-tune the PID parameters to tighten the position-hold considerably.
Hope this was interesting,
Marko

Quad with optical flow position hold (sort of...)

Posted by Marko Kleine Berkenbusch on September 11, 2010 at 8:30pm

Hi,

I have been following this site for a while now, I guess it is time to post something myself.
Above is a picture of my latest scratch-built quadcopter running an STM32 ARM processor board with home-brew software. This is my second quad, on the first one (you can sort of see it in my profile picture) I used a home-mode, dual Atmega 328 board.
So far, the quad features the following setup:

Aluminium frame "Home-Depot" style
Alpha 370 size motors (HobbyPartz)
Salvaged 6dof sensor board from a Walkera XUFO 5 (4?)
2-axis magnetometer (I know, 3 axes would make my life a little easier)
Maxbotix sonar range finder for low-altitude hold
Mediatek LS20031 GPS
Modified ADNS2610 optical mouse sensor for low-altitude position-hold
Custom software, using ChibiOS RT OS (http://chibios.sourceforge.net)
72Mhz RC gear (Futaba TX, generic RX)
XBee telemetry downlink
Onboard data logging to SD/MMC card
Oh, yes: taped on keychain-camera for onboard video ;-)

Here is picture of the (rather untidy) electronics setup (the Xbee is normally mounted on the inside of the canopy, the mouse sensor and ultrasound sensor are underneath the copter for obvious reasons):

The software features working so far are:

Quaternion based attitude representation - tried Kalman filters at first, switched to a more DCM-like approach later
Attitude-hold and aerobatic flight modes (can be switched in flight)
GPS position hold (activated by channel 6 switch on TX)
OR alternatively at the moment: Optical flow position hold via a downward-facing, modified optical mouse sensor with custom optics (NOTE: both GPS position hold and mouse sensor position hold work, but only on a good day - definitely requires more tweaking/PID tuning)
Data logging to SD card (not very reliable atm - I do not really use this much since I have telemetry via Xbee)
"Ground station software" for data logging and displaying the state of the quad in various graphical ways

The software is written pretty much in straight C, making use of ChibiOS' multithreading. The ground software is a collection of Perl/Tk scripts - all my development happens on Linux.
Below is a video of the quad in "mouse sensor" position hold mode in my driveway - apologies for the terrible video, I will try and shoot a better one soon...

If somebody finds any of this useful or interesting, I am glad to share some more details...
Best,
Marko