 We are ready for our next talk, which is about a very interesting project called Go-Bot, which combines Go with the world of IoT. I've already seen on the internet, I haven't tried it myself, some very interesting projects like a Go-Powered Barbecue, and it's such a project, you can all probably imagine something that you can do with this. Ron Evans, the floor is yours. Thank you. So whenever I go home and see my family, my question that always comes up at these important meals is, are the robots going to take our jobs? And so I try to explain to them the real state of robotics. This is a video from last year's DARPA challenge. And try to explain to them that general purpose robotics has a long way to go, and they specialize things, may be able to do very specific purpose applications, but just in general, there's nothing to be afraid of. And this is all they hear the whole time I'm talking. That's all they hear. So Roy Amara, the former head of the Institute for the Future at Stanford University, said that we have the tendency to overestimate the effect of a technology in the short term and underestimate the effect over the long term. Good morning. Buenos dias, buen dia, guten tag, bonjour. So I'm Ron Evans, known as Dead Program on the Internets, all the important places, GitHub, Twitter, et cetera. I'm the ringleader of the hybrid group. We're a software consultancy based in Los Angeles and in Spain. Some of our clients include Intel. Thank you very much for sponsoring my trip, by the way. Sphere, we did a lot of work on this little robot with two letters and a number used in this movie about wars and the stars. That's all I'm allowed to say. And we've done a lot of open source projects, including this little project called GoBot. So why and you should use Golang for programming hardware? Well, there's three main reasons. There's lots more, but rule of threes. So the first one is concurrency. It's really, really easy to write concurrent code in Golang. And when you're dealing with different hardware devices that can do whatever they're going to do whenever they end up doing it, concurrency is really, really important. Another is portability. When you're trying to develop software that needs to be deployed to different kinds of devices, maybe entirely different platforms, different flavors of operating system. The cross compilation and the static linking of Go is really the best thing out there. And then performance. So Go is well known for being extremely performance. The new Go 1.8, which is just about to come out in about two weeks. They re, as, who here actually uses Go? Sweet. The rest of you just, you should be doing it right now. So Go 1.8 adds to the garbage collector inside of Go. The slowest possible stop the world garbage collection is 100 microseconds, not milliseconds, microseconds. So why do you program in C++ to do real time applications anymore? Well, the answer is you shouldn't. So we've all heard about the C10K, having concurrent 10,000 connections. Well, we're moving towards what I like to call 10M IoT, which is 10 million IoT devices simultaneously pumping data. These are not like over the world. This is the ones that are reporting to your company that you have to monitor. So, Go Bot is a framework. We've come out of the closet. We are a framework. I know some people think frameworks are bad and some people think bad frameworks are bad and good ones are good. So, we like to think of it as a software factory for doing hardware-oriented development, or full-stack robotics. But that's kind of long, if you want to talk about that more later. So, we have three ways that you can use Go Bot now. One of them is what we call classic Go Bot, and it's when you're having just a single device that you want to control. Here's just a quick little diagram. The main concept is the robot. Robots have both adapters and drivers. Adapters actually talk to the hardware and then the adapters provide the interfaces that drivers can then talk to. So, adapters let you talk to things like Arduino's, Beaglebone Black's, Intel Edison's. Drivers let you control things like LEDs, buttons, digital accelerometers. This way, you can have the same LED that knows how to blink regardless of what kind of hardware it's connected to. The last thing that's important is we have events. We have an event channel that is created for each one of the drivers and then the robot can subscribe to those events, and that way, we can get all of Go's wonderful concurrency. You can also use Master Go Bot. Master Go Bot adds, if you want to control multiple robots at the same time, you have the master, or we sometimes call it the MCP. If you're a Tron fan, you thought that was funny. That's how we expose Go Bot's own API. It's external-facing API. So, it consumes APIs and then it produces them, and we have one that's already built in for a REST API. And then, Metal Go Bot. Metal Go Bot is if you want to just call the packages for the adapters and the drivers directly yourself. You can do that now, starting with Go Bot 1.0. So, if you really want to go hardcore metal, we got you. All right, so let's get right to the demos because time is short. So, the hello world of things is a blinking LED. So, I'm going to start with an Arduino 101, which is your basic Arduino. Who here actually has an Arduino? Yeah, exactly. Who here has an Arduino in a drawer that's covered over by a bunch of other electronics? All right, so we're just going to do a very simple little blink. So, here's the code. So, we have our package main. We import the Go Bot packages, Go Bot itself, the GPIO drivers, which is how we control LEDs and buttons and things, and then the Formata platform, which is how we're going to communicate with the microcontroller. The microcontroller is not running Go. Can't run Go on microcontrollers yet. But, we can run a program on there called Formata, which allows us to use microcontrollers as peripherals that can then communicate with different low-level hardware devices. I mean, who says that the brain and the body have to be in the same chassis? That's a human problem, right? All right, so our main function, we have our adapter. So, we call the Formata package NewAdapter and we pass in the port, which is how we're going to communicate with it. Our LED with our new LED driver on pin 13 to use that adapter and then the work that we're going to do. The work is every one second, LED.toggle. So, it's off, turn it on, if it's on, turn it off. Then, we construct our robot. We say our new robot named BlinkBot and it has one connection, which is the adapter, one driver, which is the LED, and then the work that we're going to have it do and then start it off. We do this so that we can make sure, by the time your work gets started, that all of your connections have already connected and all of your devices have already started. That way, when your work that you're supposed to be performing, because, again, we're trying to take the patterns that you're going to need consistently when developing physical applications and then utilize them easily. All right, so let's see if the demo gods favor me today. Let's see, am I in the right directory? Oh, demo, that's right. That's how you know it's real. So, we're running the code and our blinking LED. Thank you, good night, no. All right, so now let's get into some basic IO. We said hello world, but we need kind of a ping of things. We need to know that both in output and output are working. So, we're going to use that same device, but we're going to plug a few things onto it here. So, I'm going to take this and I'm going to connect to it a Grove shield, which lets me plug things in without actually worrying about where everything's set in the breadboard, because who has time for that when you're giving a talk. So then, let's look at the program that we're going to run here. So, it's almost, it's very, very similar. Okay, we're still using the GPIO package, still using the Firmata package. We still initialize the Firmata adapter, the talk to the Arduino, but now we have two devices. We have the LED, this time in pin digital two, and we have a button, which is in pin digital three. And the work that we're going to do is we're going to say button.on, GPIO.buttonpush, and then we have a function, a go function. So, when that gets called go led.toggle. So, what this is actually doing is a really, really major improvement to go about 1.0. This is actually creating an event channel, subscribing to it off of the button, making sure that the events come through are selected only for the button push, and then calls your Lambo with the data that's been passed into it, only when it's appropriate. And then it takes that go routine and puts it to sleep. So, basically, you get all of this concurrency that you're going to need, because this pattern you're going to use over and over and over again, every single type of hardware device you want to connect to. And then, same initialization of the robot, the only difference is now we have two devices, the LED and the button. And then, so let's plug in, let's see, it was the LED and two, and then the button in three, as I recall. All right. So, let's see, what did I call it, button? Hopefully, yes. So, if we go here, when we push the button, the LED lights up. And when we push it again, it turns off, because remember, we use toggle. Toggle, toggle. Yes, input and output. All right, what time does this end? 11, 10? I just want to see if I have time for the, beautiful. All right, so let's show a complete app. So, we actually do this for a living. We're really, really lucky human beings that we write software for hardware companies for a living. And so, but we often can't talk about it, and I can't talk about it today. However, I have, through the miracles of modern open source technology, simulated the key features of an application that we've been working on for an energy company. It's called Mini Luminado, which is Spanish for, you know, little lit up. And it's a solar power monitoring system. So, it has sensor stations, it has a base station, and it has a repair system for when the solar production energy systems are not working as expected. So, here's a little diagram. So, for the solar monitoring, we're going to use an Intel Edison. For the base station, we're going to use Arduino 101, and then for the repair system, oh, we're going to fly a repair drone from Parrot. All right. And then, we're going to use MQTT, which is a machine-to-machine messaging protocol standard originally created by IBM, but currently maintained by the Eclipse Foundation. And so, we're going to be using MQTT to handle all of the machine-to-machine communication taking place between these three different running programs. All right, sensor station. So, we got the Intel Edison, the sensors, and MQTT. All right. So, let's see here. Make sure I'm not running this. Good. All right. So, let's unplug this. So, here's my Intel Edison. Actually, this is the Edison here. It's just this little tiny board. This is an Arduino-compatible breakout board. And this is the battery because I'm running this off the battery. Right now, it is connected to my gateway. I have here an Intel Nook, which is a little network utility computer. It's running a Wind River Linux, which is a carrier-grade Linux. So, I know this looks like a bunch of toys, but it's really serious stuff. So, this is running the MQTT server as well. I'm sorry, what was my closing ending time? 11-10? Yes. Okay, beautiful. All right. So, let's plug in... Well, let's see. What are we showing first? Oh, we're going right into it. All right. So, I'm going to take my shield from before, and I'm gonna plug it in here. Wait, if I plug it in the right way. There we go. The other left. That looks good. And so, what we need here is we need our sensor, which is a... Well, let's look at the code real quick here. So, we're gonna go over this kind of fast. So, we have a bunch of packages. Go by it again. This time, we're using the AIO drivers, which is for analog input and output. We're using the I2C or I square C is the serious gray beards call it. Gray hairs, beards and hairs. So, I square C is a communication protocol used for inter-chip communication right on the board itself. So, then we have the Intel Edison platform. That's how we're gonna provide the interface to the low level IO. And then the MQTT platform. So, all of these things together. So, let's look at the code. We initialize our Edison adapter. We turn on our light sensor and our screen. Then we have our second adapter, which is the server, which is communicating with our MQTT server. And then the work that we're gonna do. So, the first thing is when our light sensor has data, we're gonna set our variable equal to that data. That way, most of the time, sensors provide data a lot faster and physical things can respond. Cervals can't move as quickly as you can read data. So, we wanna separate those things. Another area where it goes concurrency is quite helpful. So, then every 500 milliseconds, we're going to send the data for that, the current light meeting, reading to our MQTT server. We're gonna server.publish to this topic. MQTT topics are a little bit like URLs. And then we're gonna send the data. And then every 250 milliseconds, we're going to clear the screen, write the data onto the screen, and then based on that data, change the color of the backlit LCD. And then the work that we're gonna do is simply, or sorry, the robot itself is simply add the two connections, add the device and start. All right. So, let's see if I have a connection to my Edison. Yes. And let's plug in our sensors. So, let's see. The light sensor was in zero, as I recall. And the display is an I square C peripheral. So, we plug it in here. All right. So far, so good. All right. So, here we have our light sensor. And then when I cover it over, you see, oh, sorry. Here I have my light sensor. And when I cover it over, you can see the screen is changing. All right. So, this is wireless. It's not super well connected. So, but I'm gonna pass it around so you guys can check it out. And please don't drop it. We need this for the rest of the demo too. If you wanna see it work, just cover over the photo transistor, photo resistor, excuse me. All right. So, while you pass that around, pass it quick. Pass it, man. All right, the base station. All right, for the base station, we're gonna use an Arduino 101. We're gonna use LEDs. And we're gonna use the MQTT server. All right. So, it's the second part of our little system. So, I'm gonna use my Arduino 101 again. And this time, I'm gonna plug it into the gateway because it's gonna be easier for me with all of these cables to do that. Supposedly, easier. And so, I'm gonna use a different shield. This is a shield that I made. It's in order to control the RGB LEDs of this strip. It's a 12-volt device. And since microcontrollers are usually five or 3.3 volts, we need some way to control it. So, I built this little board that's got three TP120s. You shouldn't use these, by the way, according to the internets. Yes, anyway, as I was saying, so let's plug this in. All right, so far so good. And then, I'm going to plug in two more things. The first one is I'm gonna plug in the actual strip, hopefully, if I don't bend a pin. All right, so far so good. And then, the power. We need power. All right, since we need power to control the LEDs. All right, so we'll, and so, here's the code for the base station. So, we're using the Formata platform again. We're using GPIO again, and we're using MQTT again. This time, we're actually declaring our board and our different adapters and devices separately as pointers because we're gonna write some functions later that they're gonna use those. That way, we don't have to put everything into this giant work routine. We can have some better encapsulation, proper architecture of modern software. Yes. So, our main function here, we're gonna use the GoBot API just to see it. We're gonna literally look at it for one second. The board is connected as it was before. We have the RGB LED driver for this strip. We have our base station, which is gonna get data from the light and from the drone. Oh, whoops, that's the third part. And then, the work that we're gonna do, when we get light data, we're going to translate that light data. And then, based on it, we're gonna display the light level. This is an information radiator. You ever built a Travis build modifier that shows a red light? If you haven't, you should. You put it up in the office, giant red light. Works great. So, when the drone data is sent, depending on the flight status, if it's flying or not, if it's flying, we're gonna blink the LEDs. Otherwise, we're gonna stop. And then, we have a couple of those functions. When we display the light level, we look at the light level, and depending on how bright it is, we either display green, the system is working correctly, blue, not so good or red. Kind of the same color you see on the system, which might make it back to the back by the end of the talk. You can't blame them. It's really fun. All right. So, let's go and run the code, hopefully, on the gateway. I don't see any light. Why no light? There we go. Helps to plug things in. All right. So, we're actually seeing the colors, only the person who's playing where they can see, but you've got the people next to them. So, if you cover over the little photo resistor. Ooh. No hands. All right. We haven't even gotten to the good part. All right. So, we're gonna just kind of keep that running. All right. Robo. So, we actually have this API built in. I don't have time to show you everything about it, but it's built in React, and you can actually, through the magic of binary compilation, you can actually create all of your static assets and package them all up right into your Go application so that you have a single file that you deploy to production. Did you get that? Oh, man. So, let's take a look at it. So, this is Robo, and it's running on the gateway, and it shows we have a single device running, or robot, which is our base station, and we see that we have Formata and the two MPTT connections for our virtual devices. Literally, that's all I have time to show you, but it's in there, so you can check it out. Robo.io. So, now how do I get rid of this? Oh, wrong one. Oh, wait, no right one. Oh, phew. All right, so we saw all that. Cool. All right, the repair system. How we doing? Oh, plenty of time. The repair system uses our parent mini drone, DS3 controller. I'm kind of an Xbox gamer, but I like PlayStation controllers for flight. It's weird. And then MQTT, which is gonna coordinate this all. So, I'm gonna run this program. So, remember, right now we have two programs running. One on the Edison, one on the Gateway, and now I'm gonna run the third one on my computer because I don't have time to set up any more gear. All right, and so this is the final phase of the mini illuminado system. It's the repair system. So, when things go wrong out in the field, well, naturally this is the modern era you said to repair drone with the replacement part. Of course. So, to fill in for a more serious drone, since I know some people are kind of scared of drones because there's very bad drones. So, I'm gonna use this parent mini drone, which is a toy drone. I've got my little worker here on the front. That's Kelsey Hightower. He's helped us make GoFly more than once. All right, so this is actually a complete Linux machine. Believe it or not, it's got an ARM processor and it's running a busy box distro and we're gonna call, it's got a Bluetooth low energy wireless interface and that's how we're gonna control it. We're not running Go on it yet. Give me a few more weeks. All right, so let's turn it on. Put it here in the headquarters. Well, let's see my cables. Hopefully this will all work. This is my, I don't even use a name brand. That's what open source brings us to. If Intel only made controllers. All right, and then let's take a look at the code real fast. So we're using the GoBot BLE adapter, Bluetooth low energy adapter, which is still in a relatively new state. The joystick platform, MQTT, and then the mini drone itself. So we've got take off and landing commands. So the main work we're gonna do here is we're going to, first we're gonna load up the joystick. Whoops, it's well past it. We're gonna load the joystick configuration. That way we know which kind. We support PlayStation three, four, and Xbox 360. Your pull request awaits the next one. That's just what I have. So then we initialize our drone based on the BLE adapter, okay, which we're passing in the name of the device. And our MQTT server. So we actually have three different simultaneous types of platforms we're communicating with in one program. So then the work we're gonna do, let's see, the important parts. When I press triangle, we're gonna take off and then we're gonna send a message that says we're taking off, okay, so far so good. And then when I press X, we're land, so let's see. Triangle take off X, land. That's all that matters. Then I got a bunch of commands to handle the joysticks. And then if you recall, physical things can't respond as quickly. You can move the joystick a lot faster than your drone can respond, which will mean it will crash. So we have this go routine, which every 10 milliseconds is going to send commands to the drone. That way we don't, or I don't accidentally crash it into one of you fine people. And then same thing that we see before. We initialize our robot. This time we have three connections. We have two devices and let's make it work. Hopefully. Somewhere in here I have the, wait, yeah, that looks like it. All right, let's make sure my drone is still on. Yeah, it's still on. Button is pushed. I have to run this under sudo because be able to communicate with the BLE interface requires being in user space, or in a kernel space. That's what I was mentioning with the, oh, okay, good. All right, so now if all goes well, do you notice how it's not flashing? Because remember we sent a message that when it's in flight. So I'm gonna prove that that works by coming for a landing. All right, so now we go off and, so where is the station that's bad? We need a little more altitude to get all the way back there, huh? So we go over to where the problem is and then we simulate the repair by doing a flip. And then we got way too close. And you guys didn't, you know, you guys in the back, you really got gypped. You got ripped off because you didn't even get to see the cool parts. Whoa, lower, lower, lower. All right, that's enough of this. Back to headquarters for a beer. So we've come back to headquarters. We've been drinking at lunch. Voila! All right, so, was that fun? It's also a really exciting era. We invite you to join the robot evolution just because revolutions have really bad downsides, but evolution is constant. This is all free open source Apache 2.0 so you can use it to build your little empire or big empire or just do fun stuff on your own. You know, we're not prejudiced, we're not gonna judge you from the size of your project. GoBot.io is where we have all of our source available. We have a really good documentation site, all of the platforms and stuff and packages that you've seen. Some of these are part of an upcoming GoBot 1.2 release which is going to be out in two weeks concurrent with the release of GoLine 1.8. You can follow us on Twitter at gobot.io and I thank you. Questions, anybody who still has time for some questions? What we have time for questions as long as I kind of ignore you while I move everything out of the way for the next speaker. We have 10 minutes before I'm officially supposed to stop and then five minutes before they're supposed to start. So anyway, yes please. Yes. How many actuators and sensors do you actually support? Like a lot or do you need to make them custom? The question was how many different kinds of sensors do you support? And then the second half was and can you make custom sensor implementations? So the first one is right now I think we have about, we have 25 platforms. I think we have 20 or so different GPIO devices and I think 14 or 15 I square C devices. We've had a lot of contributions lately from people who are working on drones and other devices. I could tell because they have accelerometers and barometers. Barometers are used for altitude calculations usually when flying unless you're really close to the ground. It's very easy to add new ones which is why we've been getting all of these. So your pull request would be greatly appreciated. More? Oh wait, important thing I almost forgot. I have a bunch of go box stickers. The important parts. So feel free to mob the stage. It makes me feel nice. But otherwise I'll be around. I'm not going anywhere fast. Any other questions? No? Thank you very much. Thanks. Does it work? Okay, please be seated. Our next talk is about GoGit which is a Git implementation made in Go by Santiago.