Android <---> Arduino Communication

[dweiseth]

Robot Team:

I would like to revisit this now that Robothon is completed, we made the necessary decisions in light of the impending deadline for Robothon, but I want ask, is this a settled matter? This framework is a crucial building block for the architecture and I am not sure the socket option was the best decision if we consider that now more time is available.

It surprises me the ADK is weak in this fundamental area.

I am planning some other projects using the phone & arduino board that will rely on this interaction beyond Asimo and I need expert opinions.

Thank you.

[Paul Danset]

I also want to revisit this as well.

Many man hours went into designing the Open Accessory protocol that ADK uses, but in the interest of time we decided to abandon it.  We invented our own (using the TCP forwarding feature of the ADB protocol).  That's usually not good long term.

The Open Accessory protocol is more featureful and has much higher bandwidth than what's available from ADB.  However, the ADB protocol works on any Android device, not just 2.3.4 and later, and is simpler to work with.

Personally I'm OK with the idea of not supporting anything below 2.3.4.  It accounts for 25% (and dropping) of the Android phones out there and are usually the older less supported phones which may have a hard time keeping up with computer vision apps anyway:

http://developer.android.com/resources/dashboard/platform-versions.html

However it's not black and white.  Google has not shown any further work on ADK after its code drop at Google IO last year.  They just dropped a tar ball and that was it.   They made a bunch of announcements last year (e.g. Android@Home, Tungsten), but we have heard nothing since then.  

Meanwhile, the Arduino folks keep on improving the USB shield code (that the original ADK was based on in part).   Someone also created Microbridge to support phones running older Android OSes that don't work with ADK.  There are boards that come with firmware that support both ADK and Microbridge out of the box:

http://www.seeedstudio.com/depot/seeeduino-adk-main-board-p-846.html?cPath=132_206

Google's silence can mean one of two things:  [1] they've abandoned ADK, or [2] they are feverishly working on something using ADK like the Android@Home devices.

I bet we'll find out either way at the next Google IO, which is at the end of the month.   I'm not going this year, but the local GTUG (Google Tech User Group) will probably host an IO party with live video feeds either at Google Fremont or Google Kirkland. 

If Google continues on with ADK, I personally plan to use it for my own future projects. If they don't talk about ADK anymore, time to just use ADB or Microbridge.

-- You received this message because you are subscribed to the Google Groups Robo-Magellan Project  group.

Check out our project page: http://www.jigsawrenaissance.org/donation/robo-magellan-project/

To post to this group, send email to robo-magel...@googlegroups.com.
To unsubscribe from this group, send email to robo-magellan-pr...@googlegroups.com.
For more options, visit this group at https://groups.google.com/d/forum/robo-magellan-project?hl=en

[Pat Tressel]

David --

I would like to revisit this now that Robothon is completed, we made the necessary decisions in light of the impending deadline for Robothon, but I want ask, is this a settled matter?  This framework is a crucial building block for the architecture and I am not sure the socket option was the best decision if we consider that now more time is available.

It surprises me the ADK is weak in this fundamental area.

Right.  It's clear that the "open accessory" framework works to some extent -- DemoKit, which uses it, does run, at least when intact, with all its frou frou to slow it down.  It seemed to me that DemoKit itself was not thread-safe.  But that's the application using the framework, not the framework itself.  I did not get Arduino -> Android communication to work when the communication was the only thing happening.  Initialization succeeded, but no chars got to the other end.  Communication the other direction worked, IIRC.  Obviously the failure may be due to a bug in my code.

The alternative, which did work, was the older ADB.  Sockets is just one of the several ways it offers to set up the link, and it's actually cleaner than the ADK's setup.  I don't know if it's actually packetizing the traffic and doing handshakes a la TCP -- it does use that term the option name, but under the covers, if the OS knows it's talking over a dedicated serial line like USB, it may take some shortcuts.  I'm guessing it is at least packetizing.  We could check this.  It's not known if open accessory has lower overhead, or if the other ADB options do.

Pros & cons other than just working or not, since that may be (my) user error:

One advantage to ADB is that it works on older phones -- works on anything at Android 1.5 and later, and doesn't need special libraries.  It does not use the USB Host Shield library.  Sockets have been the standard *ix communication since the Dawn of Time, or at least, 1970.  They're presumably stable and well-implemented, at least on the Android / Linux side.

An advantage of open accessory is that one can get the app launched when the accessory connects.  That part worked fine.  That reduces, but doesn't entirely eliminate, issues with which end starts first.

I am planning some other projects using the phone & arduino board that will rely on this interaction beyond Asimo and I need expert opinions.

Sorry, that was an amateur opinion.  ;-)

I bet you need your Arduino back too, right?  ;-)

We didn't try the queuing communication tool.  I'm going to take out LinkedBlockingDeque and LinkedBlockingQueue and replace them with simpler classes that work the same way Android's Message class does.  That will remove the remaining overhead of object creation and garbage collection.  If you're interested, we could try that with your projects.  The queuing is agnostic re. the form of Arduino <--> Android communication -- that's isolated in the startup, and could be further split out into a class w/ two subclasses, chosen by options.

-- Pat

[Pat Tressel]

The Open Accessory protocol is more featureful and has much higher bandwidth than what's available from ADB.

Aha, so there is info on this...  Gots pointer?  Does it say what's different?
 

However, the ADB protocol works on any Android device, not just 2.3.4 and later, and is simpler to work with.

Also ADB is heavily "tested" -- it's what we're all using for development, for instance.
 

Personally I'm OK with the idea of not supporting anything below 2.3.4.  

Have we tried the ADK with a phone actually running 3.x or above, so we don't have to build the app at API level 10, i.e. 2.3.3 with the backport libraries from Google APIs?  If we haven't, that would be the obvious thing to try before bailing on ADK.
 

It accounts for 25% (and dropping) of the Android phones out there and are usually the older less supported phones which may have a hard time keeping up with computer vision apps anyway:

http://developer.android.com/resources/dashboard/platform-versions.html

However it's not black and white.  Google has not shown any further work on ADK after its code drop at Google IO last year.  They just dropped a tar ball and that was it.   They made a bunch of announcements last year (e.g. Android@Home, Tungsten), but we have heard nothing since then.  

Meanwhile, the Arduino folks keep on improving the USB shield code (that the original ADK was based on in part).   Someone also created Microbridge to support phones running older Android OSes that don't work with ADK.

And we were using Microbridge.
 

There are boards that come with firmware that support both ADK and Microbridge out of the box:

http://www.seeedstudio.com/depot/seeeduino-adk-main-board-p-846.html?cPath=132_206

Google's silence can mean one of two things:  [1] they've abandoned ADK, or [2] they are feverishly working on something using ADK like the Android@Home devices.

Have you come across any usage examples that don't derive from DemoKit?

[Paul Danset]

Beyond the docs at developer.android.com, the Google IO 2011 video on ADK goes into additional detail.  I sent the links to the group a few weeks back.

I've had Android 2 / 3 / 4 phones and tablets working using ADK on my Google IO board.  So I don't understand why we had so much problem with our Android <-> Arduino communication.  You mention thread safety.  Have we tried just running ADK on the main thread first?  Have we tried modifying DemoKit slightly to meet our needs?  I like taking baby steps first.  Worry about the fancier stuff later.

I plan on playing with ADK again, depending on what's announced at Google IO in 3 weeks.

AFAIK, Google has not released any ADK code other than the original tar ball (which includes DemoKit) from a year ago.

-- You received this message because you are subscribed to the Google Groups Robo-Magellan Project group.

[dweiseth]

All good comments Paul & Pat, thank you, some beyond my expertise, but I appreciate the discussion.

I bought a book on android and the arduino, it has code, simple code, hopefully tested and working code at least, but maybe too rudimentary for where you two are, but, I can send some sample code if it seems helpful.

Too bad we do not have someone on the inside at Google to know if the ADK is dead or a work in process w/ better libraries to come, surprises me they would abandon that, but Oracle maybe put the fear in them and shifted resources, smart devices are a very hot area IMHO, can't imagine Google misses that, but they are focused on the social technologies now with the new internal mandates.

My interest is more on the higher brain functions of the A.I. But it is pretty worthless when you can not touch the outside world via the arduino, so getting the spinal cord working gets our robot aspirations walking.

Thanks

[Pat Tressel]

Paul --

I've had Android 2 / 3 / 4 phones and tablets working using ADK on my Google IO board.  So I don't understand why we had so much problem with our Android <-> Arduino communication.  You mention thread safety.  Have we tried just running ADK on the main thread first?  Have we tried modifying DemoKit slightly to meet our needs?  

Yes, that's where I was stuck trying to get the phone to receive chars from the board.  I took out all the frou frou and collapsed it down to 3 classes -- one launcher for the accessory connect broadcast, one for launching via the app's icon, and one class to do all the work.  It uses a separate thread, but so did DemoKit.  It has a corresponding sketch in a sketches directory in the app.  Don't be fooled by the name -- it's not at all the same as the DemoKit sketch, so it could be where the problem is.  I haven't tried it recently, since removing a bunch of unused png files.  It's on Github at:

https://github.com/ptressel/DemoKitMin

-- Pat

[Pat Tressel]

David --

I bought a book on android and the arduino, it has code, simple code, hopefully tested and working code at least ... but, I can send some sample code if it seems helpful.

Sure.  Does it use ADK?  (Keeping fingers crossed...)  Would be nice to have something that's not DemoKit as an example.

Or we could go read the docs.  ;-)  (Working from examples w/o docs is not what I normally do...)
 

Too bad we do not have someone on the inside at Google to know if the ADK is dead or a work in process w/ better libraries to come, surprises me they would abandon that, but Oracle maybe put the fear in them and shifted resources

I missed something...what's Oracle doing that would shift Google's emphasis off mobile to social?
 

smart devices are a very hot area IMHO, can't imagine Google misses that, but they are focused on the social technologies now with the new internal mandates.

And they're getting scooped anyway.  Bing Social is actually a nice idea.

My interest is more on the higher brain functions of the A.I. But it is pretty worthless when you can not touch the outside world via the arduino, so getting the spinal cord working gets our robot aspirations walking.

Communication using ADB TCP works.  Unless we're hitting performance problems, we can keep using that until we get ADK working.

Hmm, do they have UDP for ADB?

-- Pat