New DIY Drones product preview: the PhoneDrone board for Android!

I hinted that the DIY Drones team had been working with Google on an Android-compatible RC interface board. Now that I/O is over, I can give the details. We're calling it the "PhoneDrone board for Android", and it's a way to connect any Android device (2.3.4 or higher) to the world of RC and UAVs.The board has 8 channels of RC in and out, with PWM-to-PPM conversion and multiplexing between RC and Android control. You just plug the Android's phone USB connector into the board and you have two-way communications with RC gear and any other board, such as APM.

That means that you can switch between RC control and Android control or mix the two. An example would be "fly/drive by wire". You steer your vehicle via RC, but an Android phone does the actual control using its onboard IMU. On a car, that would allow every turn to be a high-speed controlled drift, for instance (we may show something like that at Maker Faire).

Or, with a UAV, you might have the Android phone doing high-level image processing and object tracking, sending mission commands to an autopilot board such as APM. You might also want to use the phone's long-distance wireless instead of an Xbee for two-way telemetry.

This can either replace APM if you've got equivalent code running on Android, or compliment it with the Android device doing image processing or long-distance wireless comms.

Note that the pictures here are of an early prototype and some branding has been photoshopped out, pending final silkscreen approval.

Specs:

8 Input&output PWMs
Native USB host master (MAX3421)
Native USB slave (Atmega32-au)
Arduino Compatible
Atmega2560 as main controller
Atmega32-u2 as FTDI substitute and PPM encoder
Three spare serial ports to communicate with other boards (including APM)
Build-in 5V-2A switched power regulator (input range 6V - 36V)
Build-in 3.3V LDO power regulator
Android TM compatible...
All Atmega2560 pins exposed.
High quality PCB is ROHS/lead free, Gold immersed.
Dimensions: 4" x 1.6"...

It will be available in limited quantities next weekend at Maker Faire at the DIY Drones/GeekDad booth, and then available at the DIY Drones store afterwards. Target price: $99.

More pics:

Top:

Bottom:

Great board guys, although the $99 price tag seems a bit excessive. You can buy an Ardupilot for $25 and one of Oleg's USB mini shields for $20. Granted, you'll need a bit of extra wiring, and you might need the extra pins on the mega. You could get an ardupilot mega for $60 and still come out ahead $20. It would seem that integrating components should save us money, not cost us more?

As for the comparison with IOIO, note that there are two issues that need to be taken into account separately. First is hardware, pic24 versus Arduino in this case. Personally I don't really care what you use here, although you probably want some PWM pins, input capture pins to decode an incoming PPM signal, some ADC's, I^2, etc.

Second is the protocol used to talk to the phone. IOIO and my project, MicroBridge, have been using the ADB protocol (Android Debug Bridge), which is available on pretty much any Android device since version 1.5. It does everything ADK does and more, but is perhaps a little less elegant in the way it does it. What makes IOIO so cool is that it provides a rich Java API that allows you to manipulate the IO pins on the pic24 directly from Java, much like firmata for Arduino. This is ideal if all you want to do is extend your Android device with some IO.

Google's new ADK protocol is a bit of a wart imho, especially the non-standard handshaking on the USB bus is, well, creative. Either way it's a standard now so we're stuck with it. It has the advantage of having Google's backing and an API on the Java side. Downside is that it doesn't work on devices running versions other than 2.3.4 or 3.1.

According to the spec, an Android device in accessory mode (ADK mode) can still support ADB, so it's possible to use both protocols at the same time.

So the bottom line is this: first, any hardware that does ADB can do ADK and vice-versa. All we're talking about here is a microcontroller board that has USB host support.I expect IOIO to support ADK in the future and it will continue to be popular due to its great Java API. Second, use ADB if you don't have a 2.3.4 device.

I have recently ported MicroBridge to C++ and released it as an Arduino library. This allows you to use ADB on Arduino, Google's reference board, and also this new UAV board. Well, of course I don't have this board so I can can't test that claim, so if anyone is willing to give it a go let me know.

http://romfont.com/2011/05/15/microbridge-adb-support-for-arduino/

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

Join diydrones

Comments

Jeffrey Torella May 16, 2011 at 7:06pm

hey is there a similar board for the ipod/iphone other than the A.R.Drone one

or have i just missed it??
3D Robotics

Chris Anderson May 16, 2011 at 4:42pm

Michael: yes, we caught that error and fixed it in the final boards. We'll update the Eagle files when the product goes on sale.
Michael May 16, 2011 at 12:10pm

In looking at the eagle files for the Phone Drone, I was wondering, what is the purpose for T1 and the associated circuitry? The ADK reference design shows that the USBVCC is switched when the USB slave port is plugged in. In the phone drone it looks like USBVCC is floating and not connected to anything. So, when the slave USB is plugged in the Phone Drone board won't be powered?
Natalius Kiedro May 16, 2011 at 7:03am

I see the attraction of replacing the RC-link by 2 phones - years ago (2004/2005) I did this in a project I called "CellRC". The problem was GSM-CSD latency in the order of about half a second. Latency could be compensated by AP functionality, transmitting GPS waypoints just pointing to the screen where it should go.. Well 2005..

I see of course that Android will enable things like optical flow and further biomimetic tech - for an exellent compilation see Dario Floreano et al. "Flying Insects and Robots", Springer, 2009 (still actual). But for IMU (even optical flow) alone I'm a bit hesitating to buy another "cellphone". Atmel's new Xplained stuff is definetely less pricey. Perhaps I miss something, if so please help.
Inopia May 15, 2011 at 9:52am

Great board guys, although the $99 price tag seems a bit excessive. You can buy an Ardupilot for $25 and one of Oleg's USB mini shields for $20. Granted, you'll need a bit of extra wiring, and you might need the extra pins on the mega. You could get an ardupilot mega for $60 and still come out ahead $20. It would seem that integrating components should save us money, not cost us more?

As for the comparison with IOIO, note that there are two issues that need to be taken into account separately. First is hardware, pic24 versus Arduino in this case. Personally I don't really care what you use here, although you probably want some PWM pins, input capture pins to decode an incoming PPM signal, some ADC's, I^2, etc.

Second is the protocol used to talk to the phone. IOIO and my project, MicroBridge, have been using the ADB protocol (Android Debug Bridge), which is available on pretty much any Android device since version 1.5. It does everything ADK does and more, but is perhaps a little less elegant in the way it does it. What makes IOIO so cool is that it provides a rich Java API that allows you to manipulate the IO pins on the pic24 directly from Java, much like firmata for Arduino. This is ideal if all you want to do is extend your Android device with some IO.

Google's new ADK protocol is a bit of a wart imho, especially the non-standard handshaking on the USB bus is, well, creative. Either way it's a standard now so we're stuck with it. It has the advantage of having Google's backing and an API on the Java side. Downside is that it doesn't work on devices running versions other than 2.3.4 or 3.1.

According to the spec, an Android device in accessory mode (ADK mode) can still support ADB, so it's possible to use both protocols at the same time.

So the bottom line is this: first, any hardware that does ADB can do ADK and vice-versa. All we're talking about here is a microcontroller board that has USB host support.I expect IOIO to support ADK in the future and it will continue to be popular due to its great Java API. Second, use ADB if you don't have a 2.3.4 device.

I have recently ported MicroBridge to C++ and released it as an Arduino library. This allows you to use ADB on Arduino, Google's reference board, and also this new UAV board. Well, of course I don't have this board so I can can't test that claim, so if anyone is willing to give it a go let me know.

http://romfont.com/2011/05/15/microbridge-adb-support-for-arduino/
3D Robotics

Chris Anderson May 15, 2011 at 8:49am

Chris Appleton: as others have pointed out, you're confusing the board with the phone. In the scenario I was describing, the autopilot would be running on an autopilot board, not the phone. (The phone would presumably be used for higher-level functions). That's why you'd want to do the PWM->PPM conversion at the RC board, which in that case is the PhoneDrone.

I suggest you buy an IOIO board. If you don't know why you would want a PhoneDrone board, then it isn't for you.
Developer

Sandro Benigno May 15, 2011 at 5:05am

Hello Chris Appeton,

DIYDrones is a community about DIY with a lot of people with different expectations and thoughts. You are talking about your own vision. Every point of view provides many views... but they are views from just a single point. So, lets make a point cloud together.

Let's say you wanna control a QuadCopter by a normal RC and use the Android Phone camera running a software to the altitude control. Or maybe to achieve an optical position-hold when you wanna go with your hands off. Oh yes... you'll need it. Let's say the drone could follow a path automatically while you could pointing your camera to a target and take pictures comfortably by using your RC.

The great thing about this board is the number of possibilities. I'm pretty sure that you will see all that stuff working in many ways that you cannot imagine just by yourself and right now. IOIO is a great start point as well as the PhoneDrone board, what changes the equation is "who" and "how". So, we could make different choices and both still being happy! ;)

Best,
SB
Developer

John Arne Birkeland May 15, 2011 at 4:09am

Ok, let's simplify this.

IOIO - Single PIC chip based I/O interface board designed to work with Android. No Arduino compatibility.

PhoneDrone - Dual chip (ATmega32-u2 & ATmega2560) with built in 3.3 and 5v power management, hardware driven PPM input and 8 channel servo inputs and outputs. Arduino compatible, Android compatible and APM compatible (with some minor changes to the APM code?).
Chris Appleton May 15, 2011 at 3:26am

I must be confused. You said that the phone would not be a good platform for the autopilot code which I would generally agree with. But then you say that you include PPM input because autopilot software running on the phone would need it?

Just two more points. The debug functionality that IOIO uses is part of the android spec. There has been no mention of it ever going away, and I would be very very surprised if it ever did. As for going dead during operations, almost every single phone can go a full day on a single charge. Unless you are running a platform capable of 20+ hour flights, I don't see that as an issue.
3D Robotics

Chris Anderson May 14, 2011 at 10:16pm

Chris, I think the discussion of RTOS has really come down to semantics. APM doesn't use an OS as such at all. The code handles its own timing and system calls. If you want to say that we have built our own RTOS, I guess you can. We just don't think of it that way.

As for the PPM input, that's what most autopilots require. If your application doesn't, then you don't need our board. As for compatibility, we'll see. Google is only going to support accessories that conform to its ADK standard. I would not necessarily expect that debug feature the IOIO board uses to appear in future versions of Android.

As for charging the Android battery, I can't imagine why anyone would want a board that didn't at least maintain the charge of an Android device. Otherwise, you're at risk of it going dead during operations, no? At any rate, power management of the Android device is part of the ADK standard. Avoid it at your risk.

of 5

This reply was deleted.