 So, to keep everything rolling, I'm just going to go ahead and get started. So I'm Tom Rondo. I used to be the project lead for Guinea Radio until about two years ago. Since then, I've been a program manager at DARPA. So for those of you who don't know, DARPA is an advanced and fundamental research organization agency as part of the U.S. Department of Defense. So, our role is to create breakthrough technologies for the U.S. government. And you probably have seen some of the output of those breakthroughs, such as the Internet's GPS, stealth, lasers. Most of that was originally funded or inspired through DARPA. And coming from the Guinea Radio and the open source community, then to that role, I really wanted to take a lot of inspiration from what we do here into creating these kind of breakthrough technologies. And so one of those things was to try to figure out how to pull in more people to solve some of the great challenges that we see in the future of technology and science and engineering, not let it be locked into the certain way of thinking and doing business that an organization where 60 years old, actually our 60th anniversary is on the 7th. So when you've been around for that period of time and you've been as successful, you can get into ruts. And we haven't because we keep trying to do new things. And this was one of those new things to do. So we've always done HackFest as part of Guinea Radio. The open source community has done this very successfully. HackFest or Hackathons, slightly different mentalities behind these. But I wanted to do it for software radio in general because I wanted to continue to the trend of making access to the electromagnetic spectrum an interesting, fun challenge and see where we can go from what we know how to do today. I mean, if you think about the history of electromagnetic spectrum, it's 150 years since Maxwell, 120 years since Hertz. We've come a huge way in understanding this concept. And now we have very accessible free software and fairly inexpensive hardware to do this stuff. And I wanted to see what else we could do with it. And I believe we have some interference. So to do that, I wanted to expand on what we normally did in Guinea Radio HackFest, which was really get the core developers together. Somewhere, usually either in the US or Europe, often before Fozdom, we try to get together, and we just hack on the projects. So I wanted to do it a little bit differently, expand the concept a little bit more, so I had this three-party event where I had the hacker space when that was just kind of like our normal HackFest. You just show up with your ideas, enthusiasm, community building, events of trying to just do stuff while you're there. Focus energy of people for a short burst of time and get something done. So we had that set up. I also like this idea of getting speakers together, getting ideas out there. A little bit more focused talks on some really interesting stuff. To continue the conversation, to inject new ideas into the conversation. And so every day I had two talks, so about an hour and a half worth of lectures, coming from some of the world-leading experts and voices in their respective fields. And so it was a mix of software radio, software find networking. And so we had a lot of people together from OpenNFU was there. Corey Doctro and Amy were there kind of giving a perspective on just technology in general, what it means to our lives. Chris Anderson from 3DR, PK's NASA, so kind of giving a drone perspective where we're going. Hackers, Joe Grand and Sammy. And then Linda and Pierre, two incredible thinkers kind of rounded out. So very cool stuff that I think led the conversation and made sure that it wasn't happening. But then, at the end, this mission's one. This is where I really tried to focus the actual technical energy of the Hackfest. So we put together, and we'll go over it, we put together a commercial drone, put a software radio on it. Nothing new there, but what we did instead was use the software radio as the communications link to control the drone. So most people put a SDR on a drone and use it as a sensor. We actually wanted to use it to control the drone. And the reason for that was, to me, software radio makes the electromagnetic spectrum programmable. Now you connect that to an unmanned vehicle, and now that is part of your programmable space. Now you have this programmable robotic system that you're manipulating over the electromagnetic spectrum. And that presents some really cool challenges, and I think some really cool technology to push that forward. I'm not going to dive into this. I just want to give you a sense of, you know, it was a five-day event. It took place at NASA Ames out in Mountain View, California. So different talks along the way, open working sessions. I had some brainstorming sessions to get people, like, again, just constantly trying to converse throughout the week. And then at the end of the week, we had this mission judging, and I just kind of brought all the teams together who were doing the actual focus on the drone, SDR mission together to, in front of a panel with me and four other DARPA program managers so that we could get a look at what could happen. What could people do in a week with this kind of technology and this kind of push? Can we get to the point where, have we gone to the point, it was kind of the question, have we gone to the point where the software radio world is so capable and the tools are so available that you can do something completely new in a very short amount of time. So when the team showed up, they didn't know what they were going to be asked to do. They just knew it was drones and software radio. And then I asked them, solve some certain questions and see how far you could get. And then we asked them to give us the answer on Friday. So I just give you a background on some of what I asked the teams to do called these missions. This wasn't a competition, really. It wasn't a challenge. If you're familiar with DARPA, you'll probably have heard of some of our grand challenges. You know, kind of kicked off the self-driving car revolution, the robotics grand challenge, cyber grand challenge. This is not a challenge. This was a mission. Like, let's see if we can together address some interesting problems. So the first one was you've got two UAVs and a ground control station and you're trying to control UAV-2 over there. But for whatever reason, your link is unreliable. It's too far away. There's some interference. There's some kind of a jamming scenario going on. What could you do to use another UAV to route your packets around there? So this is an ad hoc mesh network kind of concept. Not horribly new, but an important concept to get right when you're trying to move these flying unmanned vehicles. Mission two was handoff. So if you're controlling the drone, there's one ground station controlling UAV-1 and for whatever reason, maybe, because you want to have line of sight but you want to continue that drone, so you want to hand it off to the next person down the line or maybe you're just tired and you want to give it off to somebody else. This is kind of like a cellular handoff challenge. You've got a drone that's moving and you've got different base stations here. How would you effectively move control between those two stations? And then the third one was, again, the sensor. SDR is a sensor, but what if you put other sensors onto this thing? How do you integrate them quickly? Every time I saw somebody doing something with a sensor on a drone, it was the exact same long process to get it integrated into the system, integrate into the link as well. How do you actually get the data to and from that sensor platform over whatever link was established? So we're challenging that. And all of these, again, nothing new, really. This isn't the most innovative questions we could have asked, but the challenge was, can we produce technology that allows us to do it better and faster and can you actually solve these problems in five days? And that turned out to be a much greater challenge. Let's see, I don't need to go over the details here. Turned out to be a much greater challenge than what it looks like from the introduction slides there. So we'll go over that when I finish up here. So as part of this idea of trying to expand kind of the nature of what we were doing, of the hack fast to try and bring people in, I went around the country and I tried to motivate people to come and apply as a team. Get your mission team together and come out for it. And so I got eight teams, some classic, more government-oriented people, Aerospace Corporation is what's known as a federally funded Research and Development Center. And then BBN, Raytheon BBN, Classic DoD Contractors. BBN, I will point out, is famous for being the company that actually was the one that did the original TCPIP network stuff. So very talented but traditional. Southern Methodist University, UC, University of California, Irvine, along with University of Southern California, academic teams coming out to play with us. Parsons and Assured Information Security, small contractors. Actually, Parsons is fairly large. Small in my world is what they do. They're fairly large and expansive otherwise. And then these were cool, Hacker Dojo and Fat Cat Fab Lab. These were just hacker spaces that I visited. So Fat Cat is from New York and Hacker Dojo is from the Bay Area. And I just went there and I explained to them and they put together a team to come out and participate. So kind of all over the board, representation that Mark pointed this out, how they set up here, mixes, all sorts of people. We got a similar mix coming out for us, which is great because it just shows you the applicability of this technology throughout here. So if you want to know more, I won't dive into the real specifics here. If you want to know more, there's stuff online. I gave a talk at GRCon last year. There's a video of me going over the details of this. But just to give you a sense of what we put together here, every team got one of, you know, a platform of a UAV and a ground station so that, you know, they were giving the hardware to play with. So the hardware was a 3DR Solo. So 3DR Robotics, founded by Chris Anderson, no longer does drones. Well, sorry, they no longer make drones. They're still in drone business. They no longer make drones. But the Solo is a really cool platform. It's actually too bad that they couldn't make it a sustainable business because it's actually really capable, inexpensive platform. But they're out of it now. But we got a hold of quite a few of them. Put on there a Raspberry Pi 3 and a Usurp B200 Mini. And now the Raspberry Pi 3 was not my first choice. It's not the most, it's computationally limited in a lot of ways versus some of the other single board computers you can get. But I kind of wanted to make sure that, A, it was very easy to get your hands on whatever compute platform you chose. And, you know, we were in the Bay Area, so you could just go down the street to fries and pick up a Raspberry Pi if you wanted to. But also, it made sure that it was a constrained compute problem, that that was actually part of the challenge. Is all the software radio stuff that we do can be very compute heavy? How do you do it on a fairly limited platform? And then you got the B200 Mini for your comms or your actual RF connection. And then ground station, just a laptop and a B210. So everybody got one of those, kick off everything. And then what we did was, from my team, I put together a team within the government to build a framework for us to work off of. So again, this idea of controlling a drone over, you know, by manipulating the spectrum, what that means is you want to create a control signal, right? I want the drone to lift off. I want it to move up or down, left or right, accelerate, decelerate, whatever. So what you do is you want to build the information there. And so we were just using the Mavelink protocol, very well-known protocol that most of the, a lot of the flight controllers speak, including the one that we were using. So you build your Mavelink packet, and then you got to pass it through until from, you know, create that at the ground station and make sure that it gets your flight controller, in this case, a Pixhawk 2. And to do that, we put together this, you know, using tools that existed, we just kind of put them all together using Pi Mavelink to kind of manage the Mavelink packet. And then Gini Radio, we created Defy and a little bit of that Mac layer level there to be able to move that information from your ground station to your drone. Demodulate it, convert it back into the raw Mavelink packet, dump it into the flight controller, and now you've got some networks. Okay. This is published, I thought, oh yeah. If you go to the Defense Digital Services, they are a group within the Pentagon that is dedicated to helping get code, to manage code within the DOD, and to move more of this stuff open source. So working with them, we published our GRUAS link. Very simple flow graph. It was really like literally meant to, pun intended, get people off the ground as soon as possible. Also what I like to call the stupidest thing that can possibly work. This was not a robust link. This was not doing anything clever as far as coding or interference protection, you know, not too much filtering. It was really just let's make sure that on day one I can send a Mavelink packet from my ground station to the drone and let it fly. And then the real challenge that I wanted the teams to do is take that basic idea and run with it and evolve it and grow from there. So we actually released our UAS link two months ahead of the Hackfest. I released it at GRCon. We went over how to install it, how to build it and all that stuff. So really wanted to get that out there. Part of the reason for doing that was to change some of the conversation that we have within the software defined radio world, especially within GNU Radio. We often build tools to build tools. We work within the GNU Radio project and we just focus ourselves within there. I wanted to provide an application that I thought was going to be exciting and allow us to engage the spectrum and more than just receiving signals, looking at them at waterfall plots. InfoSec stuff has been great, but it's all to me seem fairly insular. So what I wanted to do is have this connection to the real world, have this ability to control something that's local and tangible and hopefully use that to excite people that this is a force that can be controlled and can do really cool stuff. So I wanted to produce that. I wanted to get that out there. It also shows a number of A capabilities of GNU Radio but also some significant issues involved. And we talked about this at our little birds of a feather yesterday. To get data into and out of GNU Radio, right? Eventually you want to stop with GNU Radio. It talks to an antenna and it talks to your computer, but it shouldn't do everything. It should talk to the computer and then you should build applications on top of that. But to get that data in and out can be cumbersome. And we've used every single possible technique within GRUAS link to get data in and out of GNU Radio. So if you look at it, it's probably going to be pretty ugly, but it proves a point and it does provide a capability. And so working with Oak Ridge National Labs to put this together, again we just wanted to create the basic concept here. This is just a control GUI that exercises that graph that I just showed you in the last slide here where you literally, if you press the takeoff, you would see a drone that was tied to this, you know, lift off and hover. And then you could just kind of move it forward, back, left, right, you know, just kind of move it around. We all show, oh yeah, here's the full link to the GitHub for DDS and the UAS link. Let's see, I think, yeah. So starting from there, starting from that UAS link availability, we also made sure that you'd actually didn't really need hardware to get started with this, to play with this. So we had a kind of software in the loop and let's see, do I have it up here? I think that's, I always forget, is that key ground control? Which one is that? Can't remember what's on my head. Yeah, from who though? What's the PI? It is part of PI Mavelink, I forget, but it's called something, there's a, yes, it is PI Mavelink simulator so that you can do software in the loop. So you can actually play with everything by just having a software. We also followed, and we produced information on how to do hardware in the loop. So if you just connected two SDRs, the one that would be on the drone and the one that would be on the ground station, you could do, start studying your RF link without ever having to fly something in real space. So you know, it's more convenient, safer, a good way to kick off. So provided that as a way to get into this idea of flying a drone, and then of course you could always connect up a real drone and go from there. So try to provide, or we did provide the fundamentals capabilities to get people started and get people doing what I think is something kind of new and pretty fun within the software radio world. Let's see, how much of I want to talk about this? We had, we had those three missions that I talked about and when teams showed up, I guess they didn't know what the missions were. Monday morning I went over the three missions and challenged the teams to mostly focus on one of the missions. Like look at one of them and just work on that. You know, choose your own adventure and see what you can do by the end of the week. And so we had, these teams were the ones that tackled mission one. This is kind of the hopping mission. And so a lot of people were trying to build, basically what I liked about it was this recognition that there's a lot of tools available already within the open source community to do networking, to do mesh networking. So instead of building your own, use that on top of Gini Radio or on top of whatever SDR platform you have and then you should be able to make a capability from there. So people tried that. Mission two, we had Aerospace worked on this one. Again, this was a kind of a classic handoff, cellular handoff challenge. And they were looking at this from a, from that, again, similar concept that it's really a mesh network. If you treat it as such, you can do that. And then how do you actually do it with any authentication or encryption, right? So if I'm going to hand off my control of the drone, I want to make sure that the person I'm handing off to is the right person. So they put in ideas of encryption and authentication into it. A lot of people did Mission three. This is a, you know, the classic use of a drone is to use it as a sensor platform. So we had some ideas here. Deep Edge was fun. They were an academic university. They used computer vision to track a face with a UAV. So they had a big poster of Khan from Wrath of Khan and the drone was supposed to identify and wherever the poster went, it would track it. So that's, they did that first and then they used a picture of me and had a drone track my face, which was A, cool, B, terrifying. But still some really interesting stuff there. Just to give you a sense that, like I said, I really was pushing this open source concept here and I asked the teams, all right, so given our release of the code and pushing on this, what did you use? And you can see here that there's a lot of different open source tools that were used and this is probably not complete. It's just what people thought when they were explicitly using these. And of course, behind the scenes, these are using many other open source projects. So really happy that we got to push on this. And then I think the thing that I want to leave everybody here with is this was fun. It was a heck of a week. Exhausting as hackfest weeks tend to be. People left excited. There's a lot of great conversation. But what I loved about it was it really showed that this is a very hard problem that we're dealing with here. There's two hard problems, in fact. There's the physics of moving a drone around and flying it. It all looks easy and, you know, DJI and 3DR and people like that have made the controls of this a little bit easier. But in reality, this is really, this is a hard physics challenge. Similarly in the RF space, these are still hard things to do. It is an unknown. It's not visible. It's kind of intangible. And so when you're not an RF engineer, but you're coming into software radio and we've made it fairly easy to access this space, you start to, I think you start to ignore the complexities and start to miss some of the issues that are involved here. And so without having the tools or understanding how to develop, you know, with debugging and performance monitoring and analysis tools, front of your mind is you're trying to develop these things. If you're just going to go after your solution and think it's going to work, you're going to miss the challenges that the real world presents. So I think a lot of people looked at my three missions and were like, oh, those are easy. And then when you actually try to take your theoretical idea of how to do this into a real flying machine and real RF, that's a very different challenge, a very different problem set. So we were inside of a big concrete structure and we were running a three gigahertz signal and so you had two things. You had the difference in the barometric pressure and the atmosphere inside there is different flying than it is outside. You had to account for that and as the doors were open or closed would change how things behaved. You had to compensate for that and then the RF would just bounce all over the place. So the multi-path issue was horrible but nobody really had the tools, nobody built like the way to look at that and try to understand it and so what they did, a classic problem and I don't really fault anybody for doing this, it's the first thought that you have is my link didn't work when I sent that lift off command it didn't get there, let me turn up the gain. That was probably the exact wrong thing to do because now you're just increasing your multi-path issue and you didn't have the right equalizers, you didn't throw the compute power at solving that problem and so now you've just actually made your link problem worse but there's no way to engage that and so this kind of agile development didn't really take into account certain issues like that. So I just want to leave with that, this is not meant to be a huge downer on everything, it's a reality check on this is really cool stuff, we've come a long way in our ability to manipulate this idea, this electromagnetic spectrum but we also have to respect the real challenges that it presents to us and maybe rethink how we would engage in this kind of world and all the tools that we've been building within the Gini radio, within the SDR community to leverage that and make that happen. So at the end of the day I think it was a fairly successful event, we learned a lot, we're going to see how we take this forward and push forward in the future. I think it was a great starting point for a lot of really cool conversations and I hope a lot of cool technology. So that maybe one or two questions if we have maybe two minutes. Oh, I think so, absolutely. From my perspective, anything that ran a PIXHawk would have done the exact same thing. Now of course then you might have to change the nature of when you send a command and what the physics of that suggests and I think that's a really interesting question is if I have a, we actually, I should step back for a second, we had the 3DR drone solo, we also had a turbo ace matrix S which is a much bigger platform, carbon fiber blades, terrifying if you're too close to it frankly but also ran with the PIXHawk and we did show that we could control both of those but both of them responded differently to the different, you know, the input so you wanted to accelerate, how it accelerates behaves differently. So the answer to your question is absolutely yes and then how would you account for the changes in the physical structures of those things? They do not use a PIXHawk, so I think you could modify one, but no, but I don't think a DJI would work in this way. DJI is a lot more proprietary and locked off. Can you start decompressing? Thank you, Tom. Thank you.