Android based GCS with Bluetooth <-> XBee bridge

Hello all,

When I started with my copter, I thought of making a Linux based GCS, as I don't run Windows. However, I decided that trying to duplicate all the work on the Windows GCS was counter productive. On top of that, my laptop is dying, so in the field it would be less than useful anyway.

I recently got an Android phone, in part for its programmability. Linking it up to a quad (or hexa etc.) seemed like it would be useful. Therefore, I've been working on an Android based GCS, and although by no means done, I thought I would share and maybe get some feedback on desired features.

The phone really only has WIFI and Bluetooth for connectivity, and my quad has neither of those as options. Finding a 802.11 link for on the quad proved tough, and the range on Bluetooth is not good enough for what I am looking for. To solve that I made a Bluetooth <-> XBee link: its small and just stays in my gear case while letting me use the phone at long range from the quad. When using my laptop, I can just use it's bluetooth connection and still use the standard configurator.

I needed a place for code, so if interested, its hosted at Copter-GCS Wiki. There are screenshots there showing features, but in a nutshell:

-Configure PIDs
-Calibrate Offsets and Transmitter
-Sensor graph for current outputs
-Map the quad GPS position, as well as the phone's

Like I said, its not done, and has some things to work out. Once I do I will make the code available (if there is interest). There are a bunch of things I want to try with this, like GPS following etc, but this seemed useful for in the field calibration/testing. When Arducopter 2.0 comes out, I will update so that the MAVLink protocol is compatible.

Cheers,
Bart

@Yiangos: When I work out the remaining bugs, I can certainly see about grouping certain sections together. Part of the reason for the current division of functions is that it mirrors the protocol. Streaming telemetry is relatively fast, but if I need data from various areas, then I need to start and stop each stream, which is much slower. That is partly due to having to ensure old data is gone before requesting new data, as the current protocol does not indicate the source of the data (its just a stream of characters, without any packaging). I suspect that the MAVlink protocol will be better, and plan on focusing on it once the ACM code comes out.

@Mister Ligi: Looks very good. I had a look around when I started this, but didn't find any past projects. Clearly I overlooked some. I'm not sure about the SDP, I simply got a module that was reported to work with android. After that I just crossed my fingers :)

Thanks for all the comments, I appreciate the feedback. I'll update when I add the links for the code.

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

Join diydrones

Comments

Bart May 2, 2011 at 8:57pm

@Yiangos: When I work out the remaining bugs, I can certainly see about grouping certain sections together. Part of the reason for the current division of functions is that it mirrors the protocol. Streaming telemetry is relatively fast, but if I need data from various areas, then I need to start and stop each stream, which is much slower. That is partly due to having to ensure old data is gone before requesting new data, as the current protocol does not indicate the source of the data (its just a stream of characters, without any packaging). I suspect that the MAVlink protocol will be better, and plan on focusing on it once the ACM code comes out.

@Mister Ligi: Looks very good. I had a look around when I started this, but didn't find any past projects. Clearly I overlooked some. I'm not sure about the SDP, I simply got a module that was reported to work with android. After that I just crossed my fingers :)

Thanks for all the comments, I appreciate the feedback. I'll update when I add the links for the code.
mister ligi May 2, 2011 at 5:11pm

one link was not link-i-fyed - here again to be clickable: link to my range extender from 2009

DUBwise Range Extender

Finally i had some time for a Project which was in my mind a long time - the DUBwise Range extender. The Bluetooth Modules in Mobile Pho...
mister ligi May 2, 2011 at 5:06pm

Just wanted to add that is a very good way to solve the problem - also after long-term testing - I run the same setup since more than 2 years: http://ligi-tec.blogspot.com/2009/02/dubwise-range-extender.html and still like the approach.
@BArt: Does your Bluetooth-Module does SDP? That is the only drawback with the ones I tested - they do not do SDP and so some Android Phones/Tablets do not work ..
http://code.google.com/p/android/issues/detail?id=5427

DUBwise Range Extender

Finally i had some time for a Project which was in my mind a long time - the DUBwise Range extender. The Bluetooth Modules in Mobile Pho...
Scott Plunkett May 2, 2011 at 11:55am

Hey Bart, so I never posted anything about it, and never even put it up for sale. It was pretty straight forward - I took a 2000mAh battery from Sparkfun, combined it with a Mini-USB connector and MCP73831/2 charge controller {first design used the MAX 1555, but charged at only 300ma} (no data pass through, but that could be designed in) and then used the same RovingNetworks Bluetooth module you did and a couple of 10-pin connectors for the XBee...a case from Polycase and voila. It is pretty clean and a really small board. Self-contained battery powered XBee to Bluetooth Bridge. There are also a power switch, and a few leds for the xbee, charging, etc. Drop me an email and we can get together on it / refine it further, and go from there. I have an HTC HD2 running a hacked ROM from a DesireHD, and a G1 we could use for testing as well.
simonl May 2, 2011 at 2:03am

Darn it; another project idea I've been beaten to. #justtooslow

Well done Bart. I'll be downloading your code for sure.
Agustin Monteverdi May 1, 2011 at 7:36pm

im extremly intersted in this :)

linux android fan!
Bart May 1, 2011 at 3:52pm

@Scotty

I haven't measured any delay (when I have time I might code a quick ping timer), but there is no noticeable increase so far. I've got them both set to 57600, and that works well. Even without the Bluetooth, my XBee link didn't want to play nice at 115k.
Bart May 1, 2011 at 3:48pm

@Scott

Yeah, I think there might be some interest in a nicely packaged unit. Just connecting them straight as I did is pretty cheap though, so it would have to be pretty cheap and carry any Xbee. If it can be shrunk to a nice package, that would be great. Do you have a link for the BlueBee? I did a quick search, but didn't find it.

@Andrew

The code will be available, but at the moment I am still debugging things a bit, making sure that there aren't any major issues. Once its working well and is cleaned up, I will put the svn link back on. I've only tested it on my phone (Nexus S) so far, so I will need to test a few other screens in the simulator. No worries, it'll come.
Developer

Andrew Tridgell May 1, 2011 at 3:17pm

nice work! Is the code available somewhere? I don't see a svn/git URL on the site. I have an android phone that I'd like to try this on.
d-creator May 1, 2011 at 3:06pm

great job! now i can try to use galaxy tab.

of 3

This reply was deleted.