 I'm here to talk to you about embedded Linux. Imagine that at a conference like this. There's something of a dream come true to me, to be able to speak at a conference like this. So I'm very excited about this and a little terrified. So we'll see how this goes. Start off and talk a little bit about me, what makes me think I can come here and talk to you. I spent 20 years developing communication systems for some for DoD, some for commercial. I worked on cell phone base stations. I worked on the body wire, the digital version of the body wire that an undercover agent might wear on a drug bust. Did underwater acoustic communications. Along the way, one of my jobs, I worked on the seeker, a board that would go in the seeker of an anti-missile missile. And so that qualifies me to say that I am a rocket scientist. So I can get up here. After 20 years of doing that, I left that. I went to work with a research group at MIT that was developing a retinal implant to restore sight to people with certain forms of blindness. Very exciting work and very diverse work. I could be sitting at my desk one day developing the ASIC that was going in our next generation device and the next day be in an animal surgical trial and have the surgeon say to me, Patrick, can you put on some gloves and help me with this? So the retina is an extension of brain tissue to the outside world. So since I did that, I can claim to be a brain surgeon. I left that. We ran out of funding. I went to work for a small start-up company that was developing robots for agricultural commercial nursery industry. I spent the last five years or so playing with robots. First at Harvest Automation and then now at iRobot so I can claim to be a roboticist. Still working on Dr. Lawyer, Indian Chief. I don't know that I'll get all of those in. But the other thing, the main thing I'm here, qualifies me to be here, is I'm a Linux enthusiast. I have been running Linux in some form or another since 1995. There might be a few of you out here who weren't even born in 1995. If you go and look on the Internet, you can find Linus' original email talking about here is this thing I've been playing with called Linux from 1991. So I've been playing with it for a long time, thrilled the last several years to actually get paid to play with it. Over the years, I really wish those of you who contribute to and maintain open source packages on a regular basis, thank you. I appreciate all the work you put into this. I've done bits and pieces over the years. I use a tool, if I find a problem or want a feature, I add to it. So I've got some patches in Octave from very early on. More recently, I've got patches in Icarus Verilog. I have a one-line patch in the kernel, in the mainline kernel. So that's my claim to why I can stand up here and talk to you. Any of you could be standing up here talking to me, and I've learned from all of you over this past week. So again, thank you. But I don't really want to talk to you about me. I want to talk to you about robots, not these robots, these droids, or as they call them, the kids call them, but real robots and how we're running embedded Linux on them. It's really hard to sell, I found out at Harvest Automation. It's really hard to sell robots to a generation that's been raised on Hollywood droids. You know, they watch a robot going around. They say, why is that robot so stupid? Didn't it see that? You know, why did it do that that way? It's hard. They're not Hollywood robots. So doing things a little backwards, and I'll get into a gen, I'm going to talk about embedded Linux di-robot then. We used to do lots of DoD robots on x86 processors, mostly running open embedded. And now, where we're, or almost now, where we're running embedded Linux on consumer robots with ARM processors. Here's where I have to admit to being a little bit of a fraud. I was not here for any of the then. I joined iRobot about a year and a half ago, and you'll find out that we're going back all the way to 1999 is when iRobot has been started doing embedded Linux on robots. I'm also a little bit of a fraud now because we're not actually shipping anything at the moment running embedded Linux. The most they'll let me say is soon. You know, we will be shipping something soon. So going back to the then, we developed a product, started a product in 1999 as a DARPA-funded research product called PacBot. PacBot was a mobile, tactical mobile robot. It was running on a Pentium III x86 processor with BlueCat Linux. Never heard of it, but I went back and interviewed some of the veterans at iRobot and learned a bunch of this. Never heard of BlueCat. I'm told that it came up pretty easily. One of the guys there even remembers the big port to get it on to Linux 2.0. There were some core problems and these will show up a couple of times in my talk. Real-time characteristics were hard. The Wi-Fi support was terrible, especially when they were trying to do the ad hoc networking. But they built this robot, we built this robot. In 2001, it went to ground zero to look for survivors in New York City. In the early 2000s, it went to Afghanistan to clear out caves, to look in caves. 2011, this, or one of its successors, went to Fukushima in Japan to... If you remember the tsunami that hit the nuclear reactor there, we were able to send embedded Linux on robots into harm's way and protect people. I'm very excited about that. iRobot has sold off that. Division will talk a little more about that, but I'm still proud to be a part of a company that did that sort of work. And those of you who've worked on embedded Linux have contributed to that. Again, thank you. We developed several more products over 2007 to 2010. First look is a little handheld robot. We can toss. It'll ride itself and go scurrying around to look in for first responders or for bad guy going into a bigger brother for the pack bot. It's called Sugbee, a bigger, bigger brother, warrior or cobra. We had to support multiple hardware platforms with these. We had x86 ARM, PowerPC. We... At that time, kernel support was on separate branches and we were trying to sort through, trying to pull all these together. Some of them... We need the latest kernel for this, but the Wi-Fi driver only works on that. How do we backport that? How do we forwardport that? These are, again, I'm something of a historian here, just reporting some of the problems we ran into. Somewhere along the line, somebody said, gee, we really need an embedded Linux distribution to put this all under one common OS and we'll put an iRobot layer on top of that common OS and have board support packages for our various different products and a common build system. All of this sounds familiar. All of this is stuff that we're running into now. This is stuff that we were learning over, 1999 to 2010. We started with open embedded classic, eventually migrated to Yachto open embedded for these products. Open embedded classic, if you know the history of it, it got to be too successful. It had way too much all funneling into it. They forked off or snapped the line and said, okay, we're gonna go forward with open embedded. iRobot had to do similar things there. Common problems we had with these. In the early days, compiler support was terrible. There were no scripts. Nowadays, you can go find a script, you can just go to Lunaro, grab a compiler. There was no build route. In some cases, we even had to buy cross-compilers and then how do we fold that into our build system? Over and over again, as I talked to folks at iRobot, well, tell me about this product or what do you remember about it? Over and over again, I heard back porting is hard. Drivers are hard. And we had to have this version of Linux for this device driver and that version for that device driver. And boot time took minutes. Okay, you're in the field with this robot. You're gonna go send it into a cave, turn it on, and, okay, let's go have some coffee and wait while the boots, again, people was not going well for them with that for the military applications. Power management, wake-up support was hard. So, again, going back, 1999, 2010, these are some of the issues and problems we ran into with these military robots we were developing. Moving forward a little bit, we've started developing a remote presence robot, 2011, 2015, called Ava. It's the name of our robot. It was designed to be, you know, drive the robot around and have some personality, present the person, present the doctor to a patient. It ran a X86 comic express module, running Ubuntu 1204, bumping up later to 14.04. You know, if you thought bringing up Lucat Linux on the Pentium 3 was easy, this was trivial. It just came out of the box running that. We had a iRobot custom ROS-like robotics layer running on top of all of this. It wasn't ROS. It actually, the development of it, predated ROS. But same idea in concept and approach. We used a LiDAR to map out the area to see where the robot was, where it's going. It was connected to the CPU via Ethernet. And we had a mobility processor that just drove it around. We connected via a UART. So then what? We had the defense group, remote products, or remote presence group. They were 100% Linux. Everything they did was Linux. We had a consumer robotics home group. It was 100% not Linux. Consumer products are hard. We got a Penny's Matter. So the systems we built had minimal flash, minimal RAM, minimal processing power. Try to get the maximum we could for the minimum cost. Defense products, they're not as price sensitive. The remote presence product, some would argue was not as price sensitive. I wonder why we weren't selling it. Anyway. But consumer products were very, very cost sensitive. All right. 2015. What happened in 2015? We released a new product called the Roomba 980. I'm sorry, I'll be a walking advertisement here, but I'll just tell you a little bit about it. It was our first product with vision-based mapping. We had a camera on this. We have a camera on this. We used that to map the home. It had an LPC3250, which is an ARM9 SOC from NXP. We had a whopping 2 megabytes of flash on this and 16 megabytes of SD RAM. And it's our first Wi-Fi connected robot. We are now, iRobot has now entered the world of IoT. And we're selling this now. It's not running Linux, but this is our first product. The other thing that happened in 2015, that's when I joined iRobot. When I practiced this at iRobot, everybody applauded then. You guys aren't heckling me nearly as much as they were either, so I'm okay with this. I walked in the door and was handed a board that had a SAM A5 processor from then-atmel, now microchip on it. I said, here, Patrick, I want you to take this and get our cleaning application up and running on this. And they said, well, tell me what's on it. Well, it's got a Cortex A5 CPU. It's got 16 megabytes of flash. It's got 128 megabytes of SD RAM and Wi-Fi connected directly, words. They said, oh, great. You guys are running Linux on this, aren't you? And they said, well, no, that's Defense and Remote Presence Group. We're home products. We don't do Linux. I said, well, why not? And, well, Chris tried three and a half years ago to convince folks to run Linux and nothing happened. And then Mark tried a year ago and nothing happened. But if you want to try, you can try. So I said, well, I really think we should be running Linux on this, guys. And I got all my arguments together about portability, about how the kernel has been looked at by so many more eyes than we could ever put on here. The 980 has a custom scheduler on it, a custom OS that has been looked at by a dozen people in the lifetime. Imagine taking our core code and putting on an OS that's been looked at by millions of eyes. Let's find all the bugs in that instead of having a dozen eyes looking at it. So I put all my arguments together, got together in a room with six or eight upper management folks and said, I think we should run Linux on this and everybody around the table said, sure. Well, don't you want to hear my arguments? No, no, we think it's a good idea. All right. Golly. Okay. So over the course, I said, give it a try, Patrick. And the board designer was coming out with a new board sometime in March, so he handed me a board. I looked at my notes on March 3rd. On March 11th, I had a prompt on that board. That was, okay, I've got Linux up and running on this. Sorry, getting ahead of myself on my slides. To get there, I had to go in and customize the bootstrap. Again, Atmel, Microchip supplied bootstrap code. I had to go customize that for our board, tell what peripherals are there, tell about the SD RAM and the Flash, which of course are different than the development board. But I had to go put some custom tweaks to U-boot. And for the kernel, nothing. I just dropped it on and it ran. I'm lying a little bit. I had to tweak the device tree to tell the device. But the core kernel, I didn't have to do anything for. And there were some minor tweaks and patches. You know, okay, a camera driver, we need to adjust this. Or my one line patch to the kernel, I can tell you, dot a line eight. I still remember it. Submitted that to Atmel. They pushed it upstream. I got the email saying, hey. Again, very excited to be part of this and very excited to do this. I went away on vacation over the summer for a week and a half. Came back, I had two days in the office and then was off. I think I was chaperone for a mission trip for our church or something, but I had two days in the office and when I came in, board designer said, oh, here's a new board for you. And two days later, I said, here you go, start testing it. Again, it was just a flash change on that, which really wasn't that big of a change. But this is why I love embedded Linux. I take a, well, our board designer is especially talented. But I take working hardware from Boris. I take working software from Atmel, from the Linux community, from all of you. Put them together, they work, and everybody at iRobot thinks I'm a genius, so you could be doing this too. Wi-Fi took a little bit longer to bring up. There were issues trying to get that. Gee, that kind of sounds like 1999. Wi-Fi is always kind of hard. And there was also some, I didn't realize it at the time. We were running on pre-production silicon. What I do remember is being at Embedded Linux last year in San Francisco, San Diego, and having one of those boards with me and banging my head saying, well, when I tried to clock it up to full speed and it always crashes at this point and got back from ELC and found out, oh, yeah, the new RevB, the new boards all have the RevB processors on. Oh, and it has been running fine since then. Talk a little bit about the application development model that I like to follow that, again, set me up for success in this. Because it wasn't enough just to have Linux up and running on the board. We want to have our vacuum cleaning application, our mapping application running on top of Linux. Are there any managers in the audience? Can you just plug your ears for a second? Well, the secret behind Embedded Linux is that it's no different than desktop Linux. But don't tell your managers that because we should still command a premium for our expertise here. So my approach to developing applications in Embedded Linux is I get them working on the desktop first. I use the same Video for Linux driver, the same USB stack, the same network stack. Get it all working there. Show that it basically works. You know, there might be things with spy or I squared C that I can't really prototype on the desktop. I don't have a spy port on my laptop. But I can stub those out, work around those, but get the basic functionality up and running. Show that that works. What I've done a couple of times, you can do this with Beaglebone or with a Raspberry Pi. I did it with an Invidia Tegra board. If I have a target running a Ubuntu or something, I can just compile and run it on the target. Again, if I have something already running a Ubuntu or a Debian on it, here I'll recite some more code for you. git clone dot slash configure make. And my application was running natively on the target. You need some pieces there, but it works. Then you can figure out the I squared C and the spy bus that you need there. If you've got the luxury to do that, you don't always have the luxury to do that. So you can just go to cross-compiling for the target. There you've got, you know, Buildroot, Yachto, Lenaro, 2016, 2017 now. There's a lot more in place to make this easy and to make you successful. Debugging, you know, I debug on my desktop. I've got my full GDB, whatever GUI interface I want to use for that on the target. All right, I'll just fire it up in GDB server. Although hopefully by then, I'm not trying to step through code anymore. I've got it all worked working, but I can use that. If you want a network tier, you can use USB to network tier device. I've even used PPP and Slip, connected over a serial port to my laptop and got my, you know, on a device I was doing once that had no network connectivity. One of the things I'm finding, you know, one of the things that makes us look, you know, able to run Linux on these embedded processors is the whole cell phone market and how much that's driving down prices. Cell phones don't tend to need a whole lot of UArts, which starts to give me a little angst as I look at, okay, we need to hook up our mobility board. We need to hook up our special telemetry sensor. We also need to hook up Bluetooth. We need to hook up the...how many UArts? Well, we're gonna have to give up on the boot console. No! I get all panicky. Again, some devices are better supported. They have more UArts, but, you know, we'll see. I fight with the hardware designers. I may not have a choice in winning that battle right now, and I'll look to you out here if you have any suggestions. I'm looking a little bit at Android Debug Bridge. Maybe I can get away with just, again, okay, it's networking over USB. Maybe I get enough of a console with that. I'll find out. Here, I keep mentioning Atmel and my microchip, but I do want to publicly praise them for their support for the SAM A5, their support for Linux. I will not mention other manufacturers that I'm grumpy about, but I will publicly call out Atmel and microchip, but all the manufacturers maintain Linux kernels for their devices and Yachto distributions as well. Microchip works hard to get their changes back into the mainline. Microchip works hard to get their Yachto build. You know, just go check out your standard Yachto distribution and compile it for your chip. Buildroot just worked out of the box with them for them. I have worked with a couple of devices, you know, the last year where the board support package that came with it said, go download our version of Yachto and build it. Okay, that's nice. I can get something up and running, but I want to be able to plug into my iRobot version. So any chip manufacturers out there just asking, can you get your stuff mainlined, please? It benefits us, you know, customers. It benefits the embedded development community, but it'll also benefit you two years from now, three years, five years from now. So go ahead and get it mainlined. Going forward, where are we going with all of this? More cores, more memory, more flash, more SD RAM. Why? Because we're going to be putting more and more off-the-shelf software on the robots. I don't know what that is yet. You know, maybe... And I don't know where all robots, home robotics is going, but imagine somebody saying someday, golly, wouldn't it be nice if when somebody got home, you know, somebody releases a home butler robot that greets you as you get home and somebody at iRobot says, golly, we could have our vacuum cleaners do that. All we need to do is put open CV on there and have it do facial recognition and play a hello, Patrick, when you walk in the door. Maybe somebody will want that. Maybe we'll want to put Amazon Echo or Android Things. All of these, all of these... I just went to a talk, actually, Android Things. You know, they went to a talk this morning. They said, oh, yeah, we only need 500 megabytes to deploy Android Things. Okay, I started off with 16 megabytes. Well, I started off with two and we went to 16 and now our hardware designer is grumpy when the folks come to him and say, oh, well, now we need 128 or 256 megabytes. But, you know, the thing that's made us successful so far at iRobot and where we're going with embedded Linux is use as much off the shelf as we can and a lot of these off-the-shelf stacks just require more memory, more flash. I'm not sure why I ended up with this part on the slide, but I do want to talk to this about this. What happens when an NDA meets a GPL? You know, I had a problem issue. We have a sensor from OmniVision on our robot that I have a datasheet that I can only review, that I received under NDA. And I want to go modify the OmniVision driver in the kernel because we want to support QVGA and the one that's in there only supports VGA. How do I deal with that? And I'll tell you what I did. And after the talk, if you have any suggestions for better ways to handle it, I'll tell you what I wanted to do. I'll start with that. I wanted to go to OmniVision and say, I want to release these changes to support QVGA back to the open-source community. Can you please give me permission to do that? I could not find anybody to talk to at OmniVision who could answer that. Give me a yes, you can do that. So what I did instead is I put together a patch set that said, well, if you happen to have register settings from some place to configure it, and if you happen to know how to configure this device for QVGA, then you can use those settings however you got them. That, I feel, I can publish. I submitted to App Mail. They came back and said, go clean it up. It's on my list to go clean up. But that sort of thing can be published. And if you happen to use an OmniVision sensor, go find your local rep and say, oh, can you tell me how to configure this for QVGA if you happen to want QVGA? I'm open to other ideas if other folks have ideas of how to handle that. It is going to continue to be an issue going forward. I am passionate about open-source. I'm passionate about the GPL. If we use it, we should be contributing back. So, and I push for that. And I don't actually get any pushback at all that I robot, but it is something that I keep in the forefront of my mind. We're here at IoT. Keep one of the three most important things about IoT, security, security, security. How can I deploy my vacuum cleaner-based robot and keep it secure enough to prevent competitors from cloning it? There are three things that I worry about. How do I keep competitors from cloning it? How do I keep it from being used as a platform to launch an October 2016 DDoS attack? I don't want... Imagine we sell, I hope we sell, millions of these robots running embedded Linux. I don't want them used to launch a DDoS attack or any other attack. And I don't want them to be used. I don't want somebody to be able to break in and compromise our cloud connection from those robots. So, these are things that I think about. I worry about how do we protect... I'm not alone at iRobot doing this where I am. And I'm not alone here, but my dent is a little bit different. How do I do protect all of that and still enable our robots to be used for STEM activities? iRobot is passionate about STEM, science, technology, engineering, and math. We have two full-time employees dedicated to STEM outreach at iRobot. All employees there have two days a year that we are encouraged, given two days a year, to use for STEM activities. Our robots are available for STEM activities. If I lock down this robot so much that I can't use it for a STEM activity that goes against the iRobot, one of our core values at the company, but I also look out at all of you. If you go out there, and I hope you all do, spend $1,000 by one of our robots, please, and bring it home. If you're like me, the first thing you want to do is say, oh, I want to run my own software on this. And I want to enable that while still protecting against cloning, while still protecting against launching attacks. If you do that, if you take it home and put your own Linux on it, I want you to be able to do that. Okay, you'll void the warranty. You have to understand that. You'll give up your access to the cloud if you do that, or maybe not. How do we sort through that? But I still want to enable that, and then I want you to take that and bring it to your high schools and show it off and say, hey, look what you guys can be doing. So I, yeah. Sorry, I just realized I've been standing on a soapbox. I should climb back down. But STEM is something I'm passionate about. I love the talk yesterday. I don't know where he is if he's here or not, but I did a fabulous job talking about STEM and robotics here at using Linux for STEM and robotics in high school. Fabulous job. Thank you. I had my gratuitous Star Wars reference. Now I'm going to give you a gratuitous robot video to see if I can start this from here. So that was not my house. My house doesn't look anywhere near that clean. Even after the Roombas run around. I wish I could say Embedded Linux was used to do all of that. That's with our existing product or existing non-Linux base. The map you saw getting created, that was Linux tools being run to that. The data, the telemetry we got off the robot was from a gum stick. So there was some Embedded Linux used in that, but the product itself. But I can tell you where we're going is products going forward will have some form of Embedded Linux in them. And I've been excited to have been a part of that. You know, somehow, again, Chris joined five years ago, said we should do this, nobody, and then Mark joined, we should do this, no, and then I came in and I think enough, there was enough of an avalanche that things got going. But that's about it for my talk. If you have any questions, I do want to thank you all for being here. We've got about 15 minutes. I put this talk together. I submitted this idea for this talk and I said, I thought it would be a good idea for a talk and the organizers apparently thought so too and they said it was accepted. And then I sat down and put my slides together and I said, oh dear, how am I going to get this to stretch out to 50 minutes? So please ask questions or if not, then we'll get our break earlier. Yes, Mike. The question is have we changed the random search mechanism that the Roombas used to use? The answer is with our camera-enabled high-end robots, yes, we have. By creating the map, the robots now know where they have been and can go back and clean up, you know, do a systematic cleaning of a room. Those of you who don't have Roombas or haven't watched them run, the original Roomba, the lower-end models do just bounce around randomly for, and we have a fancy I-Adapt-2 algorithm. We tell all the marketing folks who run, but it really is, just bounce around randomly. If you do that long enough, you'll hit all of the floor. But with the newer camera-enabled robots, we can clean systematically. So, yes, we have changed that. Go out and buy one, please. Or, yeah, I shouldn't say this, but wait until we develop one with embedded Linux and then buy it. Yes, so this is a two-part question. One is when can we expect to see a Linux-based robot released and part two is when it is released, can we get to a shell prompt on it? The answer they will allow me to say for part one is soon. I can't give you any other dates than that. And the answer for part two is it will not be easy to get to a shell prompt, but what is it you want to do with that? If you've had a Roomba before and you've strapped a Raspberry Pi on top and you click the UART from there into the little SCI port, serial communications port on the top, and we're saying, well, now new robots coming out are going to have effectively that Raspberry Pi embedded in them. What you really want to do is get to that, perhaps via Wi-Fi. So, the two things I'm pushing for and working on, I want you to be able to buy that. I want you to spend $1,000 on that robot, bring it home, and put your own Linux on it. We'll see how close we come to that dream, but I do want to be able to do that. But even not, if you can speak to it over MQTT and command it to do things, for our commitment to STEM, we want robots that fourth graders can use to drive around using Scratch, all the way up to robots that colleges can use for research to drive around. So, there's a wide range of ways we can solve that problem. My own personal bent is, yeah, I want you to be able to put your own Linux on it. Getting to the console port is always going to be tough. Just trying the space, how do you even get something in there, special connector? But if you can get to it over Wi-Fi and SSH into it, if you can put your own Linux on there and SSH, maybe that's good enough if you can speak MQTT to it from your phone, if you can speak BLE. So, that's the best answer I can give right now. It is something I'm passionate about and want to be able to promote, though. Yes. I believe the question was, has my robot ever harmed a human being or allowed a human being to come to harm? Our newer robots, we were putting into them a safety micro. And I said, really, for vacuum clean, I can understand for something like a drone, but why would you need a safety micro? And if the answer is, I'm running around on the second floor of a building and I come to a ledge, I want to be able to stop that robot before it goes off the ledge and falls on somebody. I'm not sure how Asimov would have prevented one of his robots from falling off the edge of a building and landing on somebody. We do the best we could do. Yes. So the question is, has iRobot considered indirect harm to humans and the privacy implications of having a robot with a camera running around? The answer is categorically yes. We have thought about that and thought about that internally and argued back and forth. I can say we've thought about it. Some of the arguments are, well, people are buying cameras and putting them in their baby's rooms anyways. I'm not sure... If you're buying one of these, if I looked at a box, does the box even say... I hope the box has a camera. I use a camera on it. I know for the 980s we're selling right now, we made it extremely difficult even for ourselves to get images off of them, which as a developer is something of a pain. But yes, we have thought about that. And his comment was, one of the things that Dell has looked at for enabling people to put their own Linux on their devices is to follow the Chromebook example. I will certainly look at that. Some of the things I've thought about... Our kernel, again, our kernel is largely untouched and the small number of patches that are into it, I'm working to get upstreamed. So in terms of satisfying the legality of GPL, I don't have problems with that. But I want the spirit of STEM and maker community to be able to allow you to be able to put your own Linux on there. Some of the things we've looked at is, well, if we boot up and we find an iRobot signed authenticated image, then we will make the encrypted partitions containing our certificates and whatever else we need available. If we don't find a signed authenticated image, we'll still boot it. You just don't have access to the authentication credentials you need in order to get into the cloud. For me, I want to prevent... I don't want you to be able to deploy your own Linux on it wirelessly. I don't want you to deploy anything on it wirelessly. But if you spent the money on the robot and you have physical access to it, I want to make sure there's a way that you can plug into it and put your own code onto it. Again, while protecting against our competitors from cloning the device, it's a thorny problem, but how do we... These are things I like to think about when I'm commuting back and forth and argue about once I get to work. Yes. Yes. Oh, sorry. The question was, is iRobot exploring any other use cases for this technology, particularly the mapping algorithm, and the answer they will allow me to say is yes. I can't go into much more than that, but iRobot has a commitment. We divested ourselves of the defense business. We shut down the remote presence business. We are solely focused on consumer robotics as a company. This is our laser focus now. And that's more than just vacuum cleaners. The question is, how many cats can ride on a Roomba? I have to direct you to the internet for that one. I have not conducted a study myself. I know that we have three cats at home, none of them are interested in riding on my Roomba. I don't understand that. So the question is, do we have a poop detector on our vacuum cleaners? The answer is, I actually don't know what we do about it. I've heard about that problem before. I can tell you the group I work with at iRobot is an advanced forward-looking group that we're looking at exploring sensors for particular things. If you have an idea on that, we'd love to take your technology and incorporate it into our robots because it will give us a competitive advantage. Come talk to me afterwards if you have a solution, please. Alright, I think we're done. I managed to stretch this out almost 45 minutes, which is 15 minutes longer than I thought I would. Thank you very much for your time. I'm happy to chat. This is exciting stuff. Thank you for the efforts that all of you have put into embedded Linux.