Some Bluetooth and Android sillyness...

3689430345?profile=originalAbove 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:

3689430397?profile=originalThis 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:

3689430435?profile=originalIn 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:

3689430512?profile=original3689430462?profile=originalHow 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

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Mavlink Documentation can be found here: http://qgroundcontrol.org/mavlink/start

  • Hi Joseph,

    I am using my own, custom-built hardware based on an Atmega328 with my own homebrew firmware (IMU, flight controls and navigation are all handled on the same microcontroller). Therefore the software has no relation to Arducopter and its software - I cooked up my own (very simple ;-)) telemetry and control protocol for this.

    That being said, I believe that the APM folks use a protocol called "Mavlink" (sp?) which is also used by other projects, so I would imagine this to be well documented somewhere... 

    Hope this helps and good luck,

    Marko

  • @marko: Good day marko, I have the same project as you have, but the difference is that I'm using Google app inventor for android in programming my application. But my problem is that, I don't know if there are protocols used in the "APM 2.0" or the "ArduIMU+ V3" for Navigation and Setting. My setup would be "ArduIMU+ V3" on Arduino Mega 2560. Are there any protocols that will be used, for navigation and PID tuning in ArduPilot Mega 2.0 or the ArduIMU. Please help and share your project and knowledge. This is for my thesis by the way. =)

  • @marko: Always interested in how people are coding Android stuff for uav ;)
  • I will have to do some more systematic range-testing. So far, I have probably gone out about 50 feet without issues, but nothing beyond that.

    When people are asking for code, I am assuming they are asking for the android app code, not the Atmega code?

    @ThomasB: This is my first foray into Android programming, so I don't know whether it is any good as an example. I wasn't going to publish it at the moment, but it is certainly not secret either - I can send it to you (or put up a link somewhere if more people are interested) if you would like...

    Marko

  • Distributor

    Want to see a video!

     

    nice job! 

  • "330 feet range" are very near to 100 m  ;)

    The 'problem' is the unkown phone range

  • Bluetooth Class 1 has a range of ~100m.

  • Looking forward to have a go once source is out, was considering doing something similar with ioio ( now has Bluetooth ) :)
  • Nice! More details and open "sourceness" please.

This reply was deleted.