I'm an applied statistician who is interested in the arduino for data collection. So I know pretty much nothing about hardware, writing apps, etc. Does anybody have experience turning an arduino into a glorified sensor for an android/iProduct (ipad, iphone or ipod touch)? If I can pull data from an arduino into an app, then use a couple of APIs to analyze and vizualize the data, it would be useful. Small form factor, big api exposure...
Just thinking out loud- I know it's possible in theory, but has anybody done it? I imagine it has to do with the SDK of the devices and the types of input they support? I know that there are microphones, sd card readers and more that plug into the input slots of existing iProducts...
I know it's kind of cheating the arduino by using very little of its potential, but I'm sure you could put custom buttons/wheels/potentiometers/motion sensors, etc on there as well.
As far as Android phones are concerned, I know there is one guy out there who has made an application that connects (I believe) to the microphone input (via a special mini-b extended USB plug; probably something you have to custom mod yourself from a headset) to give you an "audio oscilloscope" (it doesn't work with digital signals). This is close to what you are asking, albeit only a single channel.
As far as what you are asking, this is the problem: both devices are (currently) USB slaves. I believe that in API discussions, though, there have been talks about allowing the API for Android to use the USB port as a master, but I don't know what work has gone on there (I don't follow it that closely). I think, though, that it has been an issue of the API and access, more than any device limitations of the various Android phones.
There is also the possibility of using bluetooth; I know that they recently (?) released the API for bluetooth capabilities on the Android SDK - so (in theory?) you could set up BT on the Arduino, and communicate wirelessly with it using the API.
My main interest has been the idea of creating a (likely) low-speed multi-channel digital signal analyzer (likely a single port of 6 bits) and use the Android SDK for the logging and GUI; the opening up of using BT makes it even more attractive, since you could monitor something wirelessly (say a circuit on a mobile robot). Regardless of the application, though, what is ultimately needed is some way to get a high speed serial link with the phone; once that is done, you could plug anything you wanted into the Arduino, and monitor it (with appropriate software, etc on both ends).
Lastly - there is also the idea of communicating over 802.11x (would make the Arduino end a tad expensive)...
As far as the iPhone or other smartphones are concerned, I don't know what the capabilities are there, but I would think things would be nearly the same (or perhaps more advanced; I have heard that the iPhone's SDK audio processing capabilities are far better than the Android SDK - mainly less latency, from what I have read - given the head start of the iPhone and its maturity, other interfaces might be more easily worked with)...
I know that iPhone released support for the USB relatively recently (but I hate O2 with every fibre of my being), and I'd prefer to support nearer to Open Source anyway.
Friends are doing Android phone development, but they haven't dug into hardware interfaces yet. They did point out that I could build a new kernel image, and put whatever I wanted in, but it isn't clear that Android phones can support USB host or USB OTG. (I assume cr0sh is correct and current crop are USB slaves).
I might be willing to go none-Arduino to get USB OTG.
Also, I am waiting for iPad (friend should have one next week).
I assume Bluetooth is feasible as well as USB, and Bluetooth would let me develop and test on laptop too. Downside is Arduino BT seem to be silly prices.
Anyway, I'll keep watching this thread for info & pointers.
Well - once you start messing with kernel rebuilding and such, you probably can do anything; like I said, I haven't been following this too closely.
One thing to keep in mind - if you "root" your phone to install your own custom kernel (or even to do such development), you have to take care of your own security updates and such (you can't get the ones that are pushed out without going back to the official kernel).
Personally, for myself, while I am pretty sure I could do such a thing (if I even had the time to do it!) - given that my first linux install was Turbo Linux 2.0 on a 486 laptop with 8 meg of RAM back in 1995 or so - I still would avoid it, considering I paid full price for my G1 from TMobile not too long ago (it was cheaper to go this route for the plan I wanted). I am wary of bricking the phone, I am also wary of losing stuff...
But if I could do it under a "user mode application" (ie, a regular app) using the regular/standard SDK/API for java, that would be more my style (once again, if I only had the time).
@cr0sh I hear you. I started with debian 2.0 on a 486 with 24 Mb of ram around 2000... There's something to be said for experimenting, and there's something to be said for having your phone work when you need it.
Using the default SDK would be really, well, convenient. Time...
... could build a new kernel image, and put whatever I wanted in ...
if it is very useful, it usually gets done within a few months, so don't assume you have to DIY a kernel
(I have a 'theory' about Google doing the complement to advertising, ('opportunitising' ?) where Google detects common needs based on searches, and pushes relevant ideas towards folks who may be able to exploit opportunities, but lets ignore that for now :))
... but it isn't clear that Android phones can support USB host or USB OTG
AFAIK, USB OTG is a different socket, so if the phone doesn't have it, it doesn't matter what the software does
So if Blair C wants to use USB, it may need a USB intermediary to integrate two slaves.
An android based tablet... That's the kind of setup I'd love to have (android tablet for the UI + arduino, with any kind of bluetooth/wifi/usb connection)....
Interesting find. An Android Pad would be interesting for a guy I know who wants something much bigger than a phone.
I stumbled across this description of the Drioid USB OTG hack http://www.tombom.co.uk/blog/?p=124. One picture looks the same, but there is also a close up of the plug.
I imagine google has pretty sophisticated searches for stuff they are developing. So the more interest in Android USB OTG, the more it's page rank rises, and the higher the priority on including the feature
But the niftiest device for data logging and UI device might be the Archos 5, which has USB 2.0 host, and Linux.
Specs for the Archos 5 says that it can run the Opera web browser so you could probably use it to display you analysis and graphics. It is less clear that the software develoment kit is available from Archos (see bullet 15 at the bottom of the page), but AFAIK it runs Android, and there is an Open Source tool chain for the ARM processor used in Archos 5, so it might be feasible to do almost anything.
Thx for the update there. I can't wait to see what products/touch screen products/etc will be on the market at the end of the summer. Christmas is only 8 months away.... I'm going to have a decision to make...
The archos 5 is a nice piece of hardware. Too many choices...
The idea is simple (when it's genial it's always simple): create a universal language for sensors and their networks. The Sensor will join the network, it will present itself (my name is, my range is and so on) and all the data are sent to a central processing unit (a lightserver). There's a nice presentation on their website: http://www.quadraspace.org/
Looks like it's in planning/ pre-planning phase...
That's interesting. I hadn't spotted that before, thanks.
If you are interested in flexible wireless sensor networks, have a look at TinyOS.
Folks are building 'motes' (small intelligent sensors) which form into ad-hoc wireless networks. This has been running for several years. TinyOS 2.0 came out in 2006.
It runs on a range of hardware including Atmel microcontrollers.
It uses a special programming language, nesC, so that the compiler can build tiny executables. TinyOS has a mesh wireless network stack.
AFAIK, a major problem is the hardware is expensive ($300+). (I think there is some military or government funding, and they probably don't think $300+ is expensive for a wireless sensor 'mote')
I've sometimes toyed with the idea of making motes using an Arduino and a cheap 2.4GHz radio.