 So, when we have Android and we're trying to do things that are kind of out of the norm, now I'm going to be on one of the panel, I'll be one of the panel members for tomorrow mornings is Android the next embedded Linux. And you'll kind of get the feeling from my particular perspective on that when we talk about the ADK. So we're doing a quick look at Android with respect to USB, we'll look at this thing called an Arduino, how you interface Android to the Arduino as well as other products as it turns out and then interacting with the ADK, terminating here with a demo. So unfortunately we only have so much time here so I'm going to have to make some assumptions that you understand things like intents, broadcast receivers and things of that sort. So as we go through some of this discussion we'll kind of blaze through some of that. This was originally part of a half day tutorial that as I started looking at it's like well I only have 50 minutes so there's no way I'm going to be able to cover all this stuff. So let's see what we can do about cutting it back into something manageable in the time and then if you're interested please send me an email and I will send you the whole presentation that has everything in it including the Java source code and the Android source code and how you make the two things connect with each other. So we will have a couple of things that will be showing you both in C++ and in Java so I hope that at least you have some sort of passing familiarity with those two languages. Now in 2011 Google introduced something at Google I.O. called the Open Accessory Development Kit which they referred to as the ADK. Now this was part of a much larger kind of ecosystem that Google is working on called the Android at Home Framework Initiative. And the basics between Android at Home are you would walk into your house with your Android phone enabled and because you were now within the confines of the house sensors would have detected that you entered the house, automatically turned on the lights, automatically turned the TV on and tuned it to the channel that you like to watch when you come home from work, start the coffee pot, do whatever it is it's supposed to do, automatically turn on the air conditioner or the furnace depending on what time of year it was and would have already gotten the house ready for your arrival before you even got there. That's the idea behind Android at Home. And what we're seeing now of course is a big push to eliminate IR remote controls. The consumer electronics industry is pushing to do that moving over to an RF based type of controller so your Android phone would then also be enabled with that type of radio so that you could then from your Android device basically control everything inside of the house. Now that's the goal and it's really Android enablement of the Internet of Things. So this means however when we talk about the Internet of Things we talk about sensors that go beyond what we find in the typical phone. We'll find in the typical phone we'll find accelerometers, gyroscopes in some cases we will find but we will not find barometric pressure sensors for the most part. We won't find pulse width modulation control techniques. We won't find analog inputs. We won't find analog to digital converters. There's a lot of things that are sensors that in the embedded space we would love to have but are not typically equipped on an Android phone. So the goal for the ADK is to be able to extend the Android environment with something that easily supports all of those other interfaces, I squared C, SPI, TWI, etc., etc., etc. So originally when this was introduced in 2011 they had one primary platform and that was the Arduino Mega 2560. Now we'll show you some pictures of some of this stuff here in just a moment but the Arduino Mega 2560 is a completely open-source piece of hardware and because it's completely open-source the parts are available from Atmel. It turns out there are tons of clones of this kind of hardware. I have even seen one Arduino literally made on a piece of paper. They just soldered a couple of wires, it's called a paper dweeno. You literally solder a couple of wires and the dip part onto the piece of paper and you've got a working computer. These things are really easy to make because they're all open-source, basically you have nothing that would be a barrier to entry and even though we're using kind of a commercial off the shelf board for the demonstration, you don't have to use COTS parts. You can build everything you want into one component. They subsequently expanded that. Then the first release they said, hey, it's going to be Arduino 2560 and then the folks from Microchip Inc said, well, wait a minute, what about PIC? What about PIC 24 or PIC 32s? And they go, oh, well really the accessory development kit is a specification for a protocol. As long as your device speaks the protocol then there's no reason why you couldn't have any arbitrary part talking to Android. Now there is some base information for the ADK that can be found there at that particular web link. It does get into some details about which devices are supported and how you go about hooking them up. So with 2012, in June of 2012, Android had their Google IO 2012 here in San Francisco and they introduced an update to the ADK protocol, protocol version two. With protocol version two they added support for the ARM Cortex M3. Now for those of you who aren't familiar with microprocessors, the ARM Cortex M3 is almost capable of running Linux in the sense that if it had a memory management unit you could run Linux on it. Now they do have UC Linux which is the microcontroller version of Linux. That does run on the Cortex M3 but that's not what it was originally targeted for. It's built as a microcontroller and it's built as one of these things that's going to be kind of the seminal piece of the Internet of Things as that starts to really gain some speed over the next few years. With the introduction of ADK protocol two they added support for the Bluetooth serial profile and they added support for audio dock capabilities. They brought out a new platform that's now Cortex M3 running at 84 megahertz as opposed to the Arduinos which are running at 16 megahertz. Now when we talk about the ADK, there's the new logo for the ADK by the way, Google has been unfortunately rather moot about the whole plan that they have for continuing to support the ADK. So we're starting to see it in a large number of different vendors. For instance you may have seen the Tour de France bicycle, it's a stationary bicycle where you actually ride the Tour de France path and the bicycle tilts up or tilts back whether you're going uphill or downhill and becomes harder to pedal when you're going uphill and becomes really easy to pedal when you're going downhill. The controller for that is an Android device. So you see the map, you interact with an Android device. But Android does not have all of the sensors to make the bicycle harder to pedal, easier to pedal, tilt it up, tilt it back, all the controls that are associated with actually physically controlling that bike. So those are all being done using the ADK and a separate microcontroller. And we actually see that probably the biggest penetration of the ADK so far has been in the exercise business where you're seeing these things where you're running through the park and you're actually seeing the park scenery and it's tracking your progress through the park. Those typically are using some sort of Android front end and a microcontroller that's then actually doing all the sensor measurements. So with the addition of Bluetooth to the ADK that becomes a fairly significant feature because virtually all Android phones do support Bluetooth. Now, as we see with external devices, we have two primary modes when we're running with the ADK. One is to use USB as the interface. The other is to use Bluetooth. Now, the Bluetooth piece of it, there was actually, before Bluetooth, there were some plans in Google IO 11. They talked about using 802.15.4, which is a mesh network. And this mesh network is ZigBee, Z-Wave, those kinds of things, all set on top of 802.15.4. We're also starting to see six low pan, which is IPv6 over low performance, wide area networks. That is also coming for 802.15.4. But the reality is that most Android devices aren't equipped with that interface yet. So even though they showed a demo that used that interface, that really hasn't come into any significant deployment at this point. So right now, the primary focus for the ADK is Bluetooth and USB connectivity. Well, USB connectivity represents a bit of a problem for Android. Since 1.5, we've had USB support for Android. But that has largely been Android as a device rather than Android as a host. So you can plug Android into your PC. Your PC would detect it as a mass storage device or a media player, what have you. It would then automatically load the drivers and everything would all be taken care of. And Android isn't driving the boat there. The PC is driving the boat. So in the case of the ADK, we saw a circumstance where we actually started to see some devices in the Android ecosystem that were enabled as USB hosts. For instance, the NVIDIA Tegra based ASUS transformer tablets did have USB host capability. But USB host capability is not universal across all Android devices. Even today with ICS and Jelly Bean, it's still not universally accepted. So we can't make the assumption that any arbitrary Android device is capable of being a USB host. This means that we have to make assumptions about what we plug into the Android device to make sure that the thing that gets plugged into the device is in fact a USB host. And we operate in the mode that all Android devices are capable of. And that is USB target or USB device. So some interesting problems associated with that because it means that the accessory kit has to run in an accessory mode as far as Android is concerned. So that was supported natively in Honeycomb and later. There was actually a back port that was done to Gingerbread. And so certain devices like the Google Nexus One did in fact have support for this accessory mode. And when you plug a device in an accessory mode, the operating system automatically detects the device. And when it detects the device, it pops up a dialogue that says, hey, you just plugged in an accessory. What do you want me to do with this? You want me to go ahead and launch the application? Or do you want me to go find an application for this thing? So the idea is you plug in the device and as soon as you make the connection, Android automatically detects it, loads the software and starts the application running. That's the goal. And they've done that reasonably well, if you take a look at how the protocol's been implemented. But our issue is, how do you have USB host and USB devices? In general in host mode, we have power coming from the USB host. Going to the USB device. So if we're running, say, a Honeycomb platform or an ICS platform, and we plug in a keyboard into the tablet and it detects the keyboard. Well, that's because the tablet is powering the keyboard. The tablet in that case is the host and the keyboard is the device. But unfortunately, since most Android platforms don't support that mode, it means that when you plug the device in, the device has to supply power to the Android device, to the phone or the tablet. Which means technically that when you plug in your little bitty card, your card is technically charging the Android device. And the card becomes the host, and the Android device becomes the device, the target. So it's a little backwards when you think of this little bitty microcontroller 8-bit microcontroller is really running the show for a quad-core ARM processor. That's a little backwards, but that's what they had to do in order to make it compatible across the Android product line. So with the 2012 ADK release, they also added another capability which was simultaneous ADB and accessory mode support. In the first release of the protocol, you could run ADB across the USB, or you could run the accessory mode across the USB. You couldn't run both. With the 2012 release, the protocol version two, they've added the capability of being able to run simultaneous ADB session and accessory mode. Which means we can reach in with our debuggers from Eclipse and debug the application that's running on the Android device as it interacts with the physical devices that we're controlling, servo motors, controllers, and that kind of thing. So there was also another connection that was added, which was a TCP connection. So if you had Bluetooth or Wi-Fi enabled on your microcontroller, you could actually talk to it through Bluetooth or Wi-Fi. So another capability. So it's just trying to give us more options for being able to do communications. We know the USB connector. We know how all that works, but there are other opportunities. We don't, for instance, in hard real-time control, we don't want to be putting a lot of control traffic over the same network as our data traffic. So we want to be able to separate the debugging traffic from the actual thing that we're controlling. So in those kinds of cases, it's good to have additional facilities, and that gives us the ability to do an ADB logcat. All the rest of the tools that we're used to using in Android should just work over the network connection. So the thing that we're communicating with is this thing called an Arduino. Now, I'm going to focus on the Arduino. As I said, there's the Yo-Yo board from Spark Fund, which is a PIC24-based. There is now the Arduino Due, which is a 32-bit ARM Cortex-M3. All of those are available. We'll talk a little bit more about them as we get further into the material here. But the idea was, with the Arduino, it was actually developed at the Institute of Design in Iverea, Italy. And they were building this as an adjunct to another project called the Wiring Platform. The idea was, at the Institute of Design, they are primarily artists. But they're artists who want to have LEDs, and they want to have little controller motors, and they want to be able to do kinetic sculptures, and they want to be able to do all this cool stuff that requires actuators and controllers and LEDs and circuits. And they aren't electrical engineers. So how do you enable someone who does not understand electrical engineering or software development for that matter? How do you give them the ability to use microcontrollers and electrical components like LEDs and transistors and servo motors? How do you enable that? Well, what they did was they came up with an open-source concept called the Wiring Platform. And with the Wiring Platform, it gives you the necessary understanding through a set of Lego-like building blocks to be able to construct very complex devices from very simple building blocks without being an electrical engineer. And I find that a lot of computer scientists typically like the Arduinos because it's something that we can easily work with. Many of us, even though we've got a degree in computer science, we didn't pay much attention into those electrical engineering classes if we took them at all. And so, unless you're a ham radio operator or somebody who's forced to work with the electronics, most computer scientists don't know anything about LEDs and resistors and which end of the LED is the cathode and which end is the anode. We don't know that. So this environment gives us all of the ecosystem that we need to have to be successful in creating relatively complex circuits. So because it's trying to make things easily accessible to artists and designers, they really focused on trying to make this dirt-dumb simple. And that's one of the significant reasons why Google picked this environment in order to try and focus the ADK. Now, the thing we have to keep in mind is that the standard AVR processor that's on the Arduino is an 8-bit microprocessor. I mean, we're talking going back to the 1970s here and not having a whole lot of memory, not having a whole lot of program storage to work with. So this is not something you're gonna be running Java on. The language that they use on the Arduinos is a derivative of C++. It is basically C with classes. Now, as it turns out, the compiler that they use for this environment is the GNU compiler. It's the GNU AVR compiler. So we don't have to learn whole new tool chains in order to work with it. We just have to realize that we need to deal inside the constraints of the device. How much memory I have, how much flash I have, et cetera. And that's the problem. When we talk about a 2560, 18 mega, we have 256 kilobits of flash. We have a kilobytes, rather. Kilobytes worth of flash. We have 4K of EEPROM and 8K bytes of SRAM. Now, that's 8K bytes of RAM. The device actually runs out of flash. So when we deal with these devices, we have to make sure that all of our program fits in the 256K bytes worth of flash that we have available to us. That's not a lot of flash. We're not talking megabytes. We're not talking gigabytes. We're talking kilobytes, teeny tiny. So that means that for many of us who are used to programming in Java, where we instantiate classes all over the place and it just consumes memory space like it's going out of style, that typical programming approach is not going to work in this environment. You will run out of space really fast. And the 8K bytes of SRAM is for your scratch pad. That's all your variables. Everything that could change during execution has to fit in that 8K bytes. So we're not talking about lots and lots of memory space here. But you can do a lot with it because this has got 54 direct IO, GPIO-compatible pins, 14 of which can do pulse code modulation, pulse with, excuse me, pulse with modulation. We got 16 analog inputs, four UArts, and a JTAG interface. It also has support for I squared C, SPI, and TWI. So we see that accelerometers, magnetometers, compasses, gyroscopes, a lot of these devices all have either I squared C or SPI bus interfaces on them. Try to get an I squared C interface out of your Android phone. There's no place to plug I squared C in in the Android phone, nor SPI, nor TWI, or any of these other interfaces. So this gives us a capability that we just don't have in the Android environment. It does have a 16 megahertz clock and a USB interface. Now, one of the really imaginative things that have happened with this particular environment is that all of the Arduinos have a standard footprint, a pin layout footprint. And this footprint has become so popular that a lot of non-Arduino processors have actually adopted it. And it's called the shield format. And what we see here are some examples of some shields. There are about 250 different shields that are currently being manufactured for the Arduinos. And they range anywhere from, you see that, this is an LED LCD panel up here. They have power line modems. They have motor controllers. They have Bluetooth, XB, 802.154 interfaces out the wazoo, joysticks, you name it, SD card interfaces, GPS interfaces. All of these things have been built into these Arduino shield form factors. And as long as the shields don't conflict with each other over which pins they use, you can stack shields on top of each other. So this little device here that you see, which has got, I don't know, five or six shields stacked on top of it, is an actual working device. Now, clearly that's not something you would ship. This is a prototyping environment. But the advantage is that you get the schematics for every single one of these things. So if you wanna build a more complex device, you prototype it with the Arduinos and using the commercial off the shields. And then the Arduino community actually has several different board fab houses that they work with that you can send an Eagle CAD layout to these board fab places and they'll spend you a couple of three boards overnight. And you can get some PCBs back and then start populating the PCB, either surface mount or dip type of PCBs. So with the extensive open source infrastructure that we have here, that's really its strongest asset. Now, this is the traditional ADK board. This one you can buy at Radio Shack. They actually sell them at Radio Shack. Not that I'm saying you should go buy it at Radio Shack, but certainly the fact that it exists at Radio Shack means it must be fairly common. We have here two different USB interfaces. One is the USB interface for the actual Android device. The other is the USB interface that then plugs into the thing where you get power. So into the PC or, and they usually also have a power connector right here so that you can power it separately. These things, by the way, will run quite nicely. They'll run a couple of months off of a couple of AA batteries. So these things run a long time. They're very power frugal. They do have interrupt support. In the case of this particular board, it has six separate interrupts that come into it. And you can trigger on rising edge, falling edge, changing edge, all kinds of options for being able to drive things with these arduinos. There is no operating system, by the way, on the Arduino. It's an executive. So there's no OS. We do have libraries that we call, but it's a very, very simple environment, as you might guess, when you're only running on eight K bytes worth of RAM. Of course, microchip came out with their version as well. That's either PIC-24 or PIC-32 based. They do have a kit. This is actually the little kit and it has a little interface that goes along with it. So you can punch buttons and have LEDs light up and things of that sort on the Android device. So definitely another alternative if you happen to like the microchip parts. It turns out arduinos, the IDE is free. For microchip, the IDE costs you money. So guess what? A lot of people don't use the microchips that use arduinos. All right, so with the 2012 hardware, they brought out this guy and it's an Atmel SAM 3X based ARM Cortex M3. Runs at 84 megahertz, 96 kilobytes worth of SRAM and 512 KB worth of program flash. So it's a much larger processor. This is the same pinout as the Arduino Mega. So all the shields that work on top of the Mega work on this as well. The difference is that this is 3.3 volts instead of five volts like the Mega is. So there is a slight voltage difference. Yeah, Bill, that's right. So as long as you have a shield that is compatible with the Mega, then you should be able to use it on this one as well. This is by the way, this is called the Arduino Due. DUE, which unfortunately is also due in English. So when you look for it in your favorite search engine, it says Arduino Due, when? No, no, it's the Arduino Due, which is Arduino 2 in Italian. So all these things, everything that has the official Arduino name was made in Italy. And there are, but there are tons of clones of these things. There's C-duinos and Free-duinos and Board-duinos and Net-duinos, all these things. If it's Inzen-Wino, then it's a clone of this architecture. And because it's completely open source, that's legal. There's no problem with that. You just have to realize that who are you sourcing it from? Are you sourcing it from the Italians? Are you sourcing it from somebody else? These things are carried by SparkFun, Adafruit, DX, all of your, pick your favorite distributor, Mouser, Newark, Digikey, all those guys carry this stuff. And so it's available right off the shelf for the most part. By the way, the cost of the Due is about 60 bucks. The cost of the Arduino Megas is in the 48, $50 range. And then the lower end units, the Unos and those class machines, they run usually anywhere in the 20 to $30 range, depending on what kind of features. Obviously, if you want one that has Ethernet on it, it's gonna cost you more. So the hardware for the 2012 release was this rather interesting looking clock. Inside the clock, they had colorimeter, something that could detect color. So if you wanted the clock numbers to be a particular color, what you did was you held the color up to the sensor and then all the LEDs would switch to that color, which was kind of a cool thing. And we have, of course, a capacity touch interface that had near field communications, that had NFC, that had Bluetooth, it had Bluetooth audio, a magnetometer, I squared C, spy and several others. The weird thing is that Google made this and then handed it out to all the people who were able to attend at Google IO 2012. And then these boards never went on sale, these little clocks. And a lot of that had to do with FCC certification. They didn't wanna have to go through the trouble of getting it actually FCC certified. So they made a prototype run which fell under the auspices of some FCC certification kind of loopholes. And then if they actually tried to make it commercially, they'd have to get an FCC cert for it, which they didn't wanna go through. You know, it basically it's all magnetic and just kind of folds apart. I have seen these things on sale for eBay, on eBay. They sell anywhere from 300 to $450 for a clock. It's like, really? I don't think so. But nonetheless, everything that they have in there was based on open source parts. So they'll tell you the list of the parts and you can build one yourself if you're really interested. But the cool thing is that it did give people an opportunity to see exactly what the platform was capable of doing. So when we program the Arduino, we program in terms of C++, it is using the GNU compiler. There are proprietary compilers available. If you wanna use Kyle or you wanna use one of those compilers, you can certainly do that. But the reality is that most of us in the Arduino community just use the GNU compiler because it's bundled in with the Arduino IDE. Now, the IDE is really simple. It's not Eclipse, which some of you will say, yay, and others of you go, oh. But it is based in Java, very easy to work with. It does run on Windows, Linux, and OS X. So you can basically, on any platform, you can develop code for this particular type of environment. Because of its designer heritage, they don't call these programs because they figured that artists would be kinda nervous about having to write a program for a computer. Instead, they refer to them as sketches. And so, oh, a sketch, well, a sketch is easy. I do that on the back of a napkin. I'm not intimidated by a sketch, so they call these things sketches. All right, whatever they wanna call it, whatever, however they make them happy. So here we see the IDE. And it turns out that they're right now, there are two different IDEs. One for the original 2560 platform, the AVR-8 processors, and a different one for the Cortex-M3 processors. I do have a beta of a unified IDE, 153 just came out, and that beta gives me the possibility. What happens is inside of this dialogue here, you can tell it what board you have. And by the pull down, you can specify, is it an Arduino mega, is it an Uno, is it a Dewey, and then it will pick the right compiler. So this comes with the compilers installed. So you don't have to worry about compilers or anything like that. If you download and extract out the IDE for Arduino, you have the compilers, the link environments, everything is there. And most of it is all source code. So if you wanna see how they do something, you can download the sources. And I mean, the sources are there, you can just poke around through them and take a look. So the Arduino, as I said, is a very simple programming approach. We have two required pieces of the Arduino code. We have a setup program that then tells the pins on the device, whether they're an input or an output, whether they're PWM or digital IOs, whether they're analog, whatever. It describes which directions the IO happens on the pins. And then you drop into a loop. And the loop's just a grand executive. It just sits there and runs forever. You can have interrupt service routines, that it supports. But basically anything of any interest that you want the platform to do, you just put it in the loop section. And this loop section just runs forever. No RTOS, no operating system per se. It's an executive that knows how to call functions out of libraries. And that's the model that it uses. So it's very old school from that perspective. To install the Arduino IDE, we go out to Arduino.cc and go to the homepage. And then it says, oh, you're running Windows. You wanna download this version. You're running Mac OS. If you do have the Dewey, then you can pull down the latest and greatest, which is the 153 IDE release. That supports both environments. I've just started testing with it, so I can't tell you how reliable it is. But certainly the one that came out with the Google IO 2012 release, the official one, it seems to be pretty reliable. And again, it just uses the GNU compiler in the background. So when we're working with the ADK, we have to think in terms of writing two pieces of code. We have the C and C++ piece of code that sits on the board. And then we have the Java piece of code that runs on the Android device. Now, of course, you can write the Android code in Java, or you can use C and C++ with the NDK. So if you have something that is really high speed and you can't afford the overhead of the Java framework, then by all means, drop into the NDK, and the NDK is also enabled with the same protocol. So we can do everything completely in C++ on both the Android device and the Arduino if necessary. Unfortunately, we don't have a whole lot of time to look into that, but if you send me email, I'll be happy to send you the full blown presentation. So for the most part, especially for gingerbread and honeycomb type devices, you go into the Android device, you go to settings, applications, development, and enable USB debugging. This turns on the USB and activates the accessory mode. That is not required for ICS and later. ICS and later, it automatically knows that you plugged in an accessory. So honeycomb and gingerbread, you had to turn on USB debugging because that was the first implementation. That was the 2011 protocol one implementation. Now we're talking with protocol two implementation with ICS and Jelly Bean. That's not necessarily required anymore. But of course, if you wanna run ADB and the accessory at the same time through a hub, now you do have to turn on the ADB debugging there. Of course, you gotta make sure you get the right cable. And that of course is in and of itself kind of an interesting challenge because these cables, we have USB on the go, you have USB type A, type B, micro B, mini Bs, and each one of the individual implementations might be slightly different. So it just so happens that some manufacturers may have used a USB B type connector and others may use a USB micro. You just have to look at the board and go, oh okay, I know what kind of cables I need to get in order to make this successful. So the general flow, we plug in the device and the device then waits to detect a connect. So when it gets a connection request from the Android side, there is an interchange. It says this is my identification, this is my user ID, well not my user ID, but my device ID, my product number, my version number, that gets transmitted to the Android device. The Android device then uses that to be able to look up to see whether it has a broadcast receiver that has registered itself to be able to receive this request. If it does, then it will automatically dispatch the application that's supposed to control it. Otherwise it will say, hey, you've just plugged in an accessory, what application do you want me to run in order to talk to this accessory? And then you may have to go out to the Play Store to download something or, oh I've got something, I just loaded it from my own ADB connection. So we then, once we figure out that the device is there, that the Android device supports accessory mode, then we may be in a situation where the Android device supports accessory mode but it's not turned on yet. So there's an interchange that can happen there. There's actually a certain handshake protocol that you send a message across, you ask it what ADB protocol, I mean what ADK protocol it supports. If it returns one, then that's the original Google 2011 code. If it returns two, that's the 2012 code. If it returns zero, it doesn't support accessory mode at all. So there's an interchange that has to happen there. And then once we're connected, we basically have the application on the Android side able to talk across the protocol to the Arduino side and control whatever happens to be on the Arduino side of the connection. So why bother with all of this? I mean certainly sounds like there's wires and cables and applications being written for Android and Arduinos and I gotta learn the Arduino side and I got all these shields. Why go to all that trouble? Well the answer is certainly you could argue that Android has got support for GPIOs and I2C in the Linux kernel. But the reality is that none of those things are easy to get to. If you've ever tried to do GPIO control bit banging under Linux, you know there's no standard interface. If you wanna get access to the I2C in Linux, you know there is a standard interface, but it's not easy to get to. And when we talk about doing things like pulse with modulation to control servo motors and those kinds of things, there's no standard mechanism for doing that inside of Linux. Each manufacturer, each board support package is a little bit different, a little slightly different approach and that means that you have to adapt the Linux kernel to be able to talk to whatever device you're trying to control. Also, for those of you who've actually worked with the AOSP source code, if you have ever tried to manipulate libcensors.so in source, you know why this exists. Libcensors is non-trivial and trying to get a new sensor added to Android can be a real pain in the butt if you can do it at all. I mean, there's a lot of moving parts that you have to make sure you get right in order to get the AOSP. And then you have to rebuild the AOSP source code. And then that's gonna work for one platform. That's not necessarily gonna work for all platforms because you would have to then extend your sensor into all of the platforms that you wanted to support. That's not trivial to do. So the ADK doesn't require any modification of the AOSP source code. So I don't need to mess with libcensors. I don't need to mess with the kernel. I don't need to do any of that stuff. I just simply write the application on the Java side for Android. I write the application for the Arduino. I plug them together. It automatically detects, fires off the application and I'm good to go. You do not need to root your Android device which is another distinct advantage of this. So this should work with just about any Android device you wanna plug in. Arduino of course supplies analog to digital converters, digital analog converters, and all the rest of the interfaces that we've talked about up to this point. In the case of the standard Arduino, it's a 10-bit ADC. So it does 10-bit resolution. In the case of the Arduino Duets, they're 12-bit ADCs. So 12-bit ADCs and DACs. So you've got both digital to analog and analog to digital. So the advantage of course, the real advantage that we have for something like this is because the Arduino hardware is open source, if we start thinking in terms of Android as an embedded operating system, then we have to think in terms of all of the interfaces that we need to communicate with. Whether we're in industrial, we're in automotive, all of these environments have got external interface requirements that Linux could do, Android could do, if I was willing to go in and modify the AOSP source code. And again, that's not a trivial thing to do. If you've ever tried it, you know what I mean. So there's unfortunately a lot about Arduinos that we haven't been able to cover. There are tons of books. I mean, if you go out to Amazon, you'll find probably 30 different books on Arduinos ranging from 50 projects for the Arduino Evil Scientist. I mean, there's just tons of books, lots of boards. It really is an environment that lends itself to being able to experiment. And that's really its key thing. Arduino is a prototyping environment. You don't actually ship commercial Arduino boards in your product. You take what you've done with the Arduino prototype and then you make a new PCB that actually incorporates that. As a matter of fact, I've seen plans for a Raspberry Pi that has Raspberry Pi and an 18 mega chip on the same motherboard. So we're gonna start seeing a lot of those kinds of things because the Arduino environment is so easy to work with and has been so well debug by the community that it just makes a lot of sense to be able to plug in and just run. So of course, with the new Bluetooth capability, they have Bluetooth 4 and Bluetooth Low Energy profiles. So that's gonna be another distinct advantage that we'll end up with being able to embed microcontrollers and things and then run them through Bluetooth Low Energy. So for the internet of things, where we're talking about distributed thermostats, light controllers and things of that sort, you'll be able to then reach out and control all of those from your Android device using Bluetooth Low Energy. So now that we've got just a couple of minutes left here, let me go ahead and do a demonstration. Of course, as I said, you make an offering to the demo gods in the morning and hopefully they will smile upon you and the demo will actually work. What I have here is an Arduino Mega and on this is the actual demonstration board from Google I.O. from 2011. This board has buttons, it has LEDs, it has a temperature sensor, it has two relays, it has three servo inputs, it has on the relays, you can switch two amps or something along those lines on the relays, fairly significant relays. And with that, I have it plugged into my Google Nexus 7, and hopefully that will sit there and I don't know if you can actually see it or not. We have it plugged into my Google Nexus 7 and I'm running Jelly Bean on the Nexus 7 and with any luck, the application is actually going to work for me. Hopefully you can see that. For instance, if I, and these LEDs by the way are all pulsed with modulated, so they're not just on or off. I can then turn on red, there's red. If I want to then make it, I don't like red, let's make it purple. There's purple. I can do that for several of the LEDs here. I can turn on relays, this is, you have to be real careful and maybe you can hear it if I do this for clicking. Those are relays being energized. I also have a servo, it's up in my room. I don't have the servo with me here obviously. And so this little application, when I plugged it in, it automatically popped up a dialogue that said you've just plugged in an accessory, is this the application you want to launch? And so it makes an association inside of Android between that accessory and a particular application. And with that association, it then asks the user, is this the thing you want to launch every time this application or this particular accessory is plugged in? So you ask the user for permission and then every time that accessory is plugged in it automatically launches the application and pops up and starts running. So this one also, I can tell you that it is currently about 22 degrees centigrade in this room. It has a little temperature sensor here. And if I hold my finger on the temperature sensor there it just jumped up to 24. So it gets a little, it starts getting warmer. And I can also tell you that the light sensor is indicating about 5% of light in this room and when they just opened that door it went up a little bit there, just jumped up to about six. So I mean, these are the kinds of sensors that you can do with Android through the ADK that didn't require me to write anything other than an Android application to be able to talk to the device on the other side of the ADK. No lib sensors, no changes to the kernel, nothing like that. And you plug it in and it just works. So there we have it. My time.