 Welcome to another edition of RCE. Again, this is Brock Palin. You can find us online at rce-cast.com. You can find link to iTunes, an RSS feed, link to all of our Twitter and blog accounts, as well as the entire back catalog. I have again with me Jeff Squires, one of the authors of OpenMPI. Jeff, thanks a lot for your time. Hey, Brock. Yeah, we should ask people to leave us comments on iTunes, too. It always helps keep us up in the ratings and make sure that Apple doesn't kick us off their podcasting catalog and things like that, right? Yes, yes. Definitely keep us up there as one of the more informal podcasts in this category. Yes, indeed. So a couple of interesting things going on in the HPC world. Actually, by the time this podcast goes up, these will probably be over. But as we're recording the EuroMPI Japan conference, it's kind of contradicted in terms, but that's what's happening, is going on this week. It will be the MPI forum meeting. I'm actually not there, but I sent other people from Cisco there, so that was all good. But those are key things going on that kind of shape our world as you and I know it. Also, in about two months, we're going to be at Supercomputing, and I just got my confirmation, so I will be there. And Jeff, I know you're going to be there, right? I'll be there with the OpenMPI State of the Union BOF, as usual. And I'll be in the Cisco booth. And actually, U of M is the University of Michigan is going to have a booth this year also. Last week was our inaugural booth. We split it with Michigan State University, so we had two schools and one booth. And we're doing it again this year, so we will have a booth, but I will be floating around for the most part. Cool. So if you see me, say hi. All right. And I guess I have to mention this here that Cisco is sponsoring a team in the student cluster competition this year, too. So I'm quite sure that we are the only Ethernet-based entry in the field of team, so this will be good stuff. Okay, but let's get into our topic for today. A little bit of background. The topic today actually involves a student employee who works with me at the Cain High Performance Computing Center at the University of Michigan. He's actually our Hadoop MapReduce Big Data Expert, but he's going to be talking today about their autonomous aerial vehicle. So Alec and Jose, why don't you go ahead and introduce yourselves? All right. I'm Alec. Yeah, our team is Michigan Autonomous Aerial Vehicles. I've been on it for about a year and a half now. I think I've been the lead of software development for about, I don't know, half a year. And yeah, we do a lot of different stuff, navigation, path planning, computer vision, SLAM, lasers. We do it all. And I'm Jose Gomez. I am a senior at the University of Michigan. I'm doing aerospace engineering. I've been on MAP for three years now, and I've been the structure team lead for two years. So a really big portion of my life has gone to this project, but I don't know. I also like to do stand-up comedy on the side. So there's a fun fact, I guess. So yeah, that's kind of me in a nutshell, I suppose. That is definitely a fun fact. Alec, why don't you say what year you are also in? Give your full name. Oh yeah. I'm Alec Tanaramsil. I'm a junior in the computer engineering program at the University of Michigan. Okay. So give us a quick overview. What exactly is MAV, as you call it? Yeah. MAV is Michigan's autonomous aerial vehicles team. We've got an official spiel, but I think the more sweet version is we just build flying vehicles that fly themselves. So everything we do is from scratch. So we've got four subteams. There's structures, navigation, controls, and electrical. And if you put those four together, stir well, bake for a little while, you get an autonomous aerial vehicle on the other side. And right now we compete in the international aerial robotics competition, which is a competition that evolves over time. So the takeaway there is that they try to drive innovation by making a new impossible challenge until that's completed. So right now we're in mission seven, and that's our main design constraint is trying to compete in that competition. So mission seven, what does that mean? Are there seven competitions a year? No. So there's seven since 1980 something, I believe. So every time they come up with a mission, it's ongoing until a team completes it, and then they re-iterate. So right now that's been done six times so far, and this is the seventh time it's been done. I see. Yeah, they've just rewritten the rules seven times. Gotcha. So what is your mission this time? So the mission this time, there is a completely open arena with no GPS, and then one side of the square arena is designated as the goal line. They put 10 Roombas all facing random directions, every five seconds they turn a random amount, and every 20 seconds they pull a 180, and you have to herd them over the goal line by tapping them on the head with a magnet. And every time you tap them on the head with a magnet they turn 45 degrees clockwise. So yeah, just while they're going you have to figure out where they are and then herd them all over the goal line. And then there are also a few running around with pillars on top of them, just kind of moving obstacles that you have to avoid. And I think if you even bump one of those you're eliminated from that run. Interesting. You said no GPS, what does that mean? They block GPS signals so you're supposed to figure it out just from local vision or something? Oh yeah, it's indoors so there's actually no GPS at all. And really they put down white tape on the floor like there's a one meter grid on the floor so you know what the arena looks like. So the goal right now is to do a little bit more than optical flow which is kind of an emerging localization technology using computer vision. You also go just a little bit beyond that and actually do complete localization using that. I think one of the nice things about the competition is that it's open-ended. So they tell you what you can't do but they don't tell you how to do things. So the reason I like this competition is that you know it's up to you to figure out how to solve it. And there's only a few viable routes to take but they don't hold your hand or even have an idea how to do it themselves. So it really is up to the team to figure it out. Okay, so that was the most ridiculous, crazy, as convoluted competition I've actually ever heard of. It could be Alex's description. So if you bump into something it turns randomly, it turns on a schedule and you have to basically sort of figure out what you've heard, Roombas that have gone crazy. I think a really simple way to think about it. You just have a square. It's just a 20 meter by 20 meter square with a bunch of little Roombas running around. And it's just like a bunch of toddlers, they're going to do whatever they want. And so as the parent or the quadrotor you just need to say hey, stop running that way by tapping them on the head and saying go this way instead. So all you want to do is take these people that are just doing really random things and get them across the goal line before they run out of bounds basically. And then a little bit extra is to avoid obstacles while you do it. So just really generally that's kind of the overview I think. Okay and so like in the news, we've been seeing all these things about drones and stuff but a lot of times those are remote controlled. They're actually just remote controlled things. This is actually autonomous. It's doing everything. You basically tell it to go and at that point it's completely on its own hurting all these things around, flying around. Yep. It'd be hard for a person to do this. Yeah. It's absolutely very difficult for a person to do it actually. We've tried. Okay. So you said a quadrotor. So this is like one of those quadcopter things. It's not like a full-size airplane. So you can kind of hover around and do things like that. Yeah. Oh yeah. Okay. Now how big is that? Well, because our specifically is like probably half a meter by half a meter. Something about that. It's a square because it's a quadrotor. So we did that so the math works out a little bit nicer and it ends up being about a half meter by half meter by probably 20 centimeter square. Yeah. Yeah. It's pretty small actually. It's pretty compact. Now do you have to do a quadrotor or did you guys choose that? No. So the competition likes to keep as much possible open-ended. So vehicle structure is also open-ended and we chose what to go with a quadrotor just because the math works out nicer. In terms of the controls algorithms because we've been trying to, we write our own controls algorithms as much as we can. So in the past that's worked out a little bit nicer for us, but there are teams who have hexcopters and like just weird number of factors. Yeah. All right. So tell us a little more about the vehicle itself. So it's a quadrotor. It's a square. What kind of processing is on there? How much does it weigh? What do you fuel it with? All this kind of stuff. Okay. So and the structure side of things. Yeah. On the structure side of things, we've got four rotors. It's lipo battery powered and it could run for about 10 minutes with pretty aggressive maneuvering in that 10 minutes. It's a custom carbon fiber composite airframe. So a lot of the skeleton is carbon fiber. And a lot of that is bought, but we also do some custom layup processes for more unique geometry that we have. We also, and then we've got like our own custom circuit board. But then in terms of computing and stuff like that. Oh yeah. In terms of computing power that we got on there right now, we only have, we got a small Intel atom board provided by, I can't remember, but it's way smaller than even many ITX. It's only like three by four inches. It's got a dual core atom on it. And we're looking at finding, I guess, co-processors or whatever the official term is to do all the vision work that's required. That's not going process looking for those. So we also have a laser on board, a few cameras and 10 inch propellers. And then when all of that's packaged together, it comes out to about 2.2 kilograms right now. So actually, some people say that's really heavy and some people say it's really light. We think it's really light, but that's because we are struggling to make it any lighter. So that's how we look at it. So that's all packaged on it. So is that like tethered and flying around with like a tether hanging off of the back to a table with all these batteries and stuff? No, that's actually not allowed by the rules of the competition. Your maximum in-flight dimension can only be 1.25 meters, I think. Yeah, so a tether would go over that if it were useful at all. So yeah, all that's on board. You are allowed to outsource computing. So in the past we've done this. We'll have the computers talking over Wi-Fi to a ground station to do some of the heavier lifting computing-wise. But this year, this iteration, we're trying to do everything self-contained. So no awkward processing or anything. So why do you want to do that? Oh, this year, the last competition, the main focus was on SLAM using lasers. And that's not really super data intensive. This year, though, it's all vision-based. And we would like to have, I mean, we need a lot of cameras to be able to see that and streaming all that video over Wi-Fi, it's not going to work. Gotcha, that makes sense. What's SLAM? Simultaneous Localization and Mapping. Is that what it is? Yeah, yeah, it stands for Simultaneous Localization and Mapping. And it's a way... I was the one that wrote the implementation that we used, but it's a way to create a map and update it and know your position all at the same time. Yeah, by comparing scans from your laser. So we had a laser on board, a LiDAR system. And so just by looking at different snapshots, you can get a lot of information about your heading and your surroundings by comparing pictures, basically. Gotcha. And so somebody did that, and that was Mission 6, and this is now Mission 7? So part of Mission 6 was heavily emphasizing just indoor... So, okay, we mentioned there's no GPS. That was kind of the big hurdle of the last competition, was GPS localization was kind of understood at the time that it was written. So they wanted somebody to implement indoor localization without that. And so it was up to the team to develop that system however they wanted. We went with the LiDAR approach, partially because it allowed us to collaborate with different labs at U of M and also because laser scanners are pretty convenient in a lot of ways. And they're just absolutely perfect. Yeah, they're tremendously accurate and just really good in a lot of ways. Yeah, I think the laser that we have is like millimeter accuracy. Yeah, in like a 30 meter range and just like crazy stuff like that. So it was just perfect for what we were trying to do. So was this like a mini version of like those architectural scanners? It's just like spinning a prism and it's just kind of like drawing dots and you're kind of interpolating a surface? Yeah, yeah, we did all of the... I mean, our software did all of the interpolation and stuff like that, but yeah, that's really all. It was just a spinning prism. I don't know about the architectural versions or anything like that, but we had a little, I mean, pretty small thing. It definitely fit in the palm of your hand. I think it was like 700 grams or something, probably less than that. I don't remember that number. Yeah, I don't know, but it was really small and it was pretty cool. And it's pretty low power, which is a really big deal when you're running on batteries. You can tell you guys are flight people, because every piece of equipment you're like, yeah, it's 700 grams. You know exactly how much it weighs down to the ground. There was a really strict mass budget in the last competition. We had to be like under 1.5 kilograms. So it equated to just drill holes and everything. Yeah, when we actually got the atom at first, it has this massive heat sink on it. When we were running, we were packing to go to competition. We were leaving in like one hour. Yeah. And one of the guys on the team just took the heat sink and went to the drill press and just drilled out as much as possible. Yeah, and just took it to the mill and just like took a bunch off. We shrunk the mass of that heat sink by a lot. It was good. Okay, so what's the new one you said you're no longer, are you no longer allowed to use LiDAR? Are you choosing not to? Yeah, so you're kind of unofficially banned from it for localization. It's still indoors. Okay, so in the past, it's been an obstacle course, but now it's just a gymnasium. And so you're pretty much not allowed to use LiDAR. You could cheat and definitely find the walls if you had a high part, if you had a big enough range on your laser rangefinder, which we do, but they really don't want you to do that and we don't want to do that. So you're pretty much banned. That was a really long way to say that, I apologize. Okay, so how does this competition work? Do a bunch of teams come together in a common facility at a certain day or when you're ready, do you call the judges and they come and set up a, how does it work? Oh, that would be awesome. So how it works is every day, it's always in August, as far as I know, but right now the current, every time they change the rules, they also change the location. But right now it's at Georgia Tech. It runs for three days, like in the first week of August. I think this year was like the third to the sixth or something like that. But yeah, everybody, all the schools that participate just go down there. And then the first day is just kind of you do presentations and get inspected, make sure your safety stuff works. And then the second day is competition. Yeah, there's some formal deadlines you have to meet. They actually require formal technical paper as well. So there's static judging and then there's the actual performance in the competition itself. But everybody convenes in one common location for the event. How many schools competed? So I guess the last one was just about a month ago. So I mean, how many competed there? I think it was about five or six. Okay, so there were about five or six, but it gets up to about 10, I think by the end of it. There's a registration fee and that can really burden a lot of teams. So because it's so early, these are expected to go multiple years because it's supposed to be really difficult to do, which it is. So a lot of teams knew strategically that there's no way they could do it this year. So they just decided not to come. So that number should go up. But at this most recent one, there were five teams. And as more people get closer and closer, we expect to see an increase in the number of people present. Did you guys have an entry or did you just go scout? We had an entry this year was heavily focused on redesigning the structure side of things. And then a lot of effort went into organizing the actual team itself. We're still really young. So problems like turnover are being handled as they come up. This was the first year that we didn't have any charter members. Yeah. So in terms of our entry, though, we did compete. We just weren't autonomous. So when I mentioned earlier that we while I alluded to this, we did try the competition manually. We manually flew it. We had a pilot at the competition itself. And the rationale was we'd get the least points at the competition and wouldn't win first this year. But that's kind of a moot title anyway. If you can't win the whole thing, it doesn't really matter. So we had a human pilot just kind of forfeited our chances of winning at all because we knew we couldn't. And we had a human pilot fly it and simulate the competition so that we could get really good flight data. So that when we do write these algorithms, we have good data to feed in and see what kind of output you get under realistic conditions. That was a little bit long winded. No, that was perfect. So did anybody at the competition manage to pull this off? Or is that why you're still working on it? Yeah. They did not. And that's why we're still on it. Yeah. Yeah. So I think there were two teams that flew autonomously. One just kind of like instantly crashed and burned. Yeah. The other one just slowly drifted until they were going to hit a wall. Yeah. I think if we had, if we had a done autonomous flight, it would not have been, it would have been just going around in a box or something like that. Yeah. It wouldn't have actually been that great. So that's why we went with the manual route so we could actually get some useful data. The unfortunate aspect about this kind of competition is that until you're totally done, your system was really stupid. And so when we talk about how other teams, when they were flying autonomously, achieving anything autonomously is in and of itself like an accomplishment. Yeah, definitely. So we should trivialize what other people have done. It just sucks that to an outside observer, especially one that's not real up on these things, your system looks absolutely stupid until it actually does the whole thing. So it's kind of a curse of the trade, I suppose. So it's hard to judge how sophisticated these systems were just from our viewpoint because... Oh, yeah. Even just going in a straight line autonomously is ridiculous. Yeah. Like unless you can look at their code and figure out how far they are, it's hard to guess to me how close these guys were. But there were attempts to do some things autonomously this year. Now, just to go back one more thing on the logistics. What are the allowable age or school year experience? Who's allowed to compete? Yeah. There's no... Okay, so I think as long as... You don't know the rules. No. Do you actually know the actual answer? Yeah. You just say it then. I was going to guess. Oh, no, no, no. Okay, so the actual... Let's see, according to the rules, at least half of your team needs to be university students. I was going to say that. Oh, you were? Yeah, that is what I was going to say. It's other than that, and it doesn't matter what level, just somewhere in the college. So you can also... I mean, we have a couple... We had two high school students over the summer, I think, that were one of them software and the other did structural stuff. But you can partner with industry and stuff like that as long as at least half of your team is university, college students. Interesting. So Jose, you said you're a senior this year, so assuming that you're going to graduate, are you going to be able to see the end of this? As long as the people that I know on the team are still on the team, I'll keep tabs, and even after I graduate, I probably will. In terms of... I mean, there's still a chance that in grad school, I am way less planned out than I should be at this point in my life. But if I go to grad school here, I keep telling myself, I'm going to drop it and enjoy life a little bit more. I can't pull myself away from it, it seems. So we'll see. I think my next year, we're going to have a system that's really competitive. I really want us to be very close. And we came super close to finishing the last one, so it'd be heartbreaking to not win this one. But I don't know, it's up in the air whether or not I'll actually see the end of it. So what would you say is actually the biggest challenge? Getting something that actually flies software, hardware construction inside your package and flight limitations? What's the skill set needed? Yeah. The biggest challenge by far, that I can see is there's two big software problems that have to be solved. The first one is like localization. Actually, I guess there's three big software problems. The first one is localization in the arena. You need to know your position really well. That hasn't really been done before using cameras at all. And then there's the second big software challenge is kind of figuring out which Roomba you actually should go to and make a changes direction. That's going to be pretty hard. Prioritizing which targets next. Trying to prioritize which one's next. The third one is the controls problem because 20 meters by 20 meters doesn't really seem that big, but it's actually really large. And having something, our pilot was pulling really aggressive maneuvers just to even attempt to do that stuff like that. So having really aggressive, autonomous control software is also going to be really hard. Yeah. In terms of the structural design, as much pride as we take in doing things ourselves, it's kind of just to feel good as long as we get the software there. We could put it on any system. Doing everything yourself gives you the advantage of not being black boxed out of anything. You know how everything's working, the physics of it a little bit better. But technically speaking, a lot of teams will just buy an AR drone and then just try to put their software on it, which comes with its own challenges. But the point is that as fun as the structure stuff is, it's not really necessary, I guess in some ways. So not to invalidate myself, I'm going to go ahead and invalidate myself a little bit. Yeah. Then we're also, oh, we have a great circuit guy. Well, we had a great circuit guy. He's kind of done now. Yeah, he graduated. So I guess I don't know how bad it would be if we bought just, I don't know, all of our power distribution and everything like that is handled by this guy. So I don't know how much it's going to not be fun to have him around. Have him not be around. Yeah. But I mean, absolutely the biggest challenges are in the software side of things. The intention of the competition. Well, that's good because I'm a software guy. So let me ask you a little about that. Sure. How, what language do you write in? Do you write C code or something else? We used to use Java and then I took over and then now we use C++. Turns out Alec is the largest, just snap about people. He's just like, I don't know, lead us about everything he does. That is 100% accurate. Okay. So actually here's something that typically galvanizes computer scientists. What version control do you use? Oh, well that's, I mean, we use Git, honestly. Okay. Actually for the software we use Git, we all see a subversion for CAD and other stuff like that. That's for the dumb structures folk who don't know how to use computers so good. Yeah. They have pretty torus SVN and everything like that. Alec looks down on us rightfully so. Okay. So are you the only guy working on the software? Because I heard three major sections of code there that are fairly autonomous and orthogonal from each other. Is it just you or are there more people working on the software? Oh man. Over the summer it was pretty much just me and then that. It's misleading. Okay. Because he's also including control. So first, We should let you know that we differentiate controls and navigation. So controls is lower level. How do I navigate my environment at all? If I want to be there, how do I get there with my motors? And then navigation is higher level. Why do I exist as a quad rotor kind of stuff? What's my purpose? So Alec was the only one working the higher level navigation stuff. Yeah. Yeah. So out of the three things I mentioned, all of the control stuff, there were three or four guys working on that over the summer whatever, which is good because that's a lot of math. Yeah. I'm not that great at math. So, yeah. But then on higher level navigation stuff like I said, I was pretty much the only person working on that this summer. Besides the one high school. Except, yeah. There was one high schooler. He did some laser work because we still have one to detect obstacles and that was actually, that's actually really nice. Yeah. That helped a lot. That helped a lot. Yeah. So we're at least manned in the most complex side of the problems. Yes. Which is unfortunate. It is unfortunate. So you're flying this thing. Of course, gravity is always wanting you to fall down. And if you're going in a direction, you kind of keep going in that direction. So you got to be updating your decision of I'm going to move or change something pretty rapidly here. What do you, like, do you kind of have a time constraint? Like I really need to be updating myself every five milliseconds or something like that. Otherwise we're going to get off course. Boy, I guess we haven't. So it's more for the controls guys, right? Yeah. No, it is really rapid. And I forget the number, but it's pretty sensitive to the updates. They run at like 400 hertz. Yeah. And so it's not so much for just staying on course. It's also just for staying in the air at all. So if you get confused, you'll pay for it really quickly. And the biggest issue comes from like bad sensor data. Because no matter what, you're going to get anomalies and stuff like that. So a lot of those problems go away with a good filter. And so we use common filtering to get away from, you know, because your sensor is only talking to you so rapidly. And sometimes it's not as quickly as you need it to be. So you can use some math and stuff like that to kind of extrapolate where your position should be at this time step to fill in the blanks. And if like you have to throw a signal away, you can rely on your math to at least have an educated guess of where you are at any given moment. So you do have to update really pretty quickly to stay in the air. And if your sensor kind of poops out on you, you can deadwreck it for a little bit and do all right. Barely. Yeah. You will at least not fall out of the sky. Hopefully. You mentioned earlier that you're using an Intel Atom processor, but you said that the control guys are running at 400 megahertz. Is that the same Atom, or do you actually have multiple CPUs? Oh, yeah. How do you handle that? Oh, okay. So just a little bit of correction. It's only 400 hertz, not 400 megahertz. That would be awesome. But no, so they, oh, what is it they use? They use a Tiva microcontroller. It's a little arm thing from Texas Instruments. So they do all this fancy interrupt driven stuff or whatever. They do stuff really fast. Yeah. And the past has been done on a gum sticks too. Oh, yeah. We used to use a gum sticks. We pitched that as soon as we got an opportunity. Yeah. So controls algorithms are usually running on a dedicated embedded system. Okay. And so you got a message back and forth with them. Yeah. Yeah. What kind of protocols do you do for that? How is that messaging handled? We just do serial over the wire. That's actually, it's not super data intensive. Every once in a while, we just send them a waypoint. Not even that often, probably once every half a second. So, and occasionally they send us back some data about where we are. That's really about it though. It's just, it's just the high level telling the low level what to do. It's the, it's like, I like to explain this. You know, the fun metaphor that I like, the high level stuff is like, if you, if you wake up in the middle of the night and you're really hungry, then you're going to decide to go to the fridge. Like that's your current goal. That's the high level stuff that Alec is doing. And then to get to the fridge, you know, you have to move your left leg and then your right leg and then your left leg. So that's like the low level stuff that is on the embedded system. And so the communication that takes place is mostly Alec, the brain, talking to the legs, the controls and saying, this is where we're going now. Get me there. I don't know how I know, but I know that you know how. So get me to this point in space. So that's the kind of communication that happens between the two. That's a great example. Yeah. I don't really understand it all very well. So I have to relate it to layman's terms for my own self. Okay. So earlier on you said that, you know, everything's got to be camera based now. It's a lot more bandwidth and stuff like that. And so that's all internal to your, the autonomous system, right? Yeah. Yep. So we kind of, we keep the controls and the navigation systems pretty much completely separate. They each only connect to the sensors that they need. And that's, yeah, having, we want to have as many cameras as possible, right? We ran with two in this competition and that wasn't really nearly enough camera real estate, I guess. So another, another one of the issues is just, we can't connect them all to that atom just because the USB bus can't even support pulling from as many cameras as we need to. So that's another part of the challenge. There's multiple bandwidth challenges that like every single level, which is why we need to have a lot of co-processor support and stuff like that. So. Okay. So expand on that. What is your thought about going down this alley? Are you going to make a third system that just handles video and sends like a condensed version of that to the atom? Yeah. That's actually what we're planning on. What we were, we tried to use Raspberry Pis and those are ridiculously slow. We're kind of, we're testing some other stuff out right now, but the idea is to have each camera or each pair of cameras get processed at one thing. And the only information we need from the images is whether or not there's a Roomba in the frame and where the lines are. And that's pretty, that information can be done quite a bit, right? If you say, oh, here's a Roomba and here's the location in the camera frame. I mean, that's just a couple of floating point numbers and then something to tell you that it's a Roomba. And same thing with a line. You just need to transmit the endpoints of the line and the color is important because that's how you differentiate what's a goal line and what's not. So that's really the only information we need. So bandwidth from whatever's processing the camera to the atom, the central navigation system is actually not really that big of a deal. We don't really need that much information. Now, how do you test all this software? Because obviously, you know, you're developing the package and the mechanical flying platform in tandem with your software. So it's got to be long periods of time where you don't have anything you can fly around. Plus, you know, if you have a seg fall in the middle, you don't want to crash the copter and break it. So do you simulate? What do you do? That's not a great question. So that's kind of another reason for the completely separate systems is that navigation will, I mean, probably do a lot of crazy stuff a lot of the time. So control is completely separate for that reason. Just so that when we mess up on the navigation side, it doesn't fall out of the sky. But what do we do for testing? I guess just we started doing a lot of unit testing. We unit test basically everything that we can. Just make sure that the things work the way that you think they will when you check it manually. Yeah, and then for, yeah, the vision stuff is a little bit more kind of, we actually just look at what's happening on the screen. Yeah, you can just like turn the camera on and see if it actually detects what it's supposed to write because it's, you give it a few lines and see if it can find them. So you can actually check that real time. But also flight, like actual flight data is like the most valuable stuff in the world just because the cameras vibrate, things do really weird stuff that you wouldn't expect. So at the end of the day, that was a, in the past we haven't had this, but we've added the ability to RC control it. So having a manual like pilot option is actually really valuable because even if your autonomous algorithms aren't quite where they need to be, you can just still fly the thing and see how your higher level algorithms are going to operate with real flight data instead of, oh, I'm gently holding a camera in front of some lines I drew. So simulating as much manually as you can is also super valuable and a good way to check. Again, one question from one software guy to another. What is your overall model? Is this an event-based program or is it multi-threaded or what's your overall model? Oh man, I don't know. I just so far it's just multi-threaded. Yeah, I don't know. I'm not super familiar with event-based programming. There's, oh yeah, I guess we could switch to that, but I think threaded is just probably what we're going to stick with for now. So what do you do then? You basically turn it on and crank it up as, you know, until you peg the processor so that you're just updating as fast as you can? Yeah, more or less. Once we get, so there'll be a couple of threads, right? One thread is just kind of the planner thread and we'll just look at the map and figure out which Roomba to attack and then just keep planning over and over and over as fast as we can and then the other thread or multiple threads will be updating the map with information from the cameras. Now, do you get interrupts to, you know, guarantee the servicing of that data? That is a great question. We're not quite to that level yet with the communication between whatever is doing the cameras and whatever is running on the atom. We have not quite got there yet. Okay, because I'm actually not super familiar with the atom but I would assume it's a single core and just a single thread or does it actually even have a hyper thread? Oh, it's actually dual core? I can't remember if it has hyper threading. It is pretty new, so I don't know if the atoms support hyper threading at all but it is 64 bit if that means anything and we have four gigs of RAM. Oh, so you have a ton of space. Yeah, yeah, it's a, I mean, the board that we get, it's like a little, I mean, it's a laptop basically. A little notebook. Okay, so if you've got a dual core application there, again, I'm not super familiar with the atoms. Do they have shared caches or exclusive caches? I mean, do you have to deal with NUMA effects in your code? Yeah, I think it's because it's an atom. I think it's just kind of the typical where they each have their own separate L1 and L2 caches and they have a shared L3 cache is what I would assume. So I think what we'll probably do though is just keep the map. The map is also not, doesn't have a lot of information in it so keeping it in shared memory is really not that big of a deal as far as I know, right? Because we know exactly what the map looks like and we only have to track 14 objects within it so it's not even going to take up that much memory. It's not going to take up maybe a meg of memory so updating it and controlling access to it with just a single mutex isn't even a problem unless we really need to go fast, which I can't foresee needing to go insanely fast on the navigation side. So what would you say the applications of this would be for, you know, a commercial world? So, yeah, the competition always sounds a little bit contrived and so it's always actually a pretty common question. The applications of autonomous vehicles, it kind of depends, I think one of the more immediate goals or one of the more immediate low hanging fruits would be like commercial inspection, stuff like that. Kind of anywhere it's difficult to put a person, you could put a quad rotor or something similar instead so that you just kind of remove the person element which could make like bridge inspections cheaper like sewer inspections, stuff like that, a little bit cheaper and more accessible. And then more long term, I guess I'm not the, I don't have my pulse, ironically enough, I don't quite have the pulse of the UAV industry as much as others so it's hard for me to say. I don't think anybody has the pulse of the UAV industry. Yeah, it's tricky but I mean there's the Amazon thing which, you know, honestly, that's not even hard to do. Technically speaking, that's like a solved problem. It's just how do you not kill kids with that is I think the issue they're trying to attack. How do you insure it and all that stuff? Yeah, so there's, I mean there's a lot of applications for being able to explore with these kinds of things and I like that, you know, we kind of prove that you don't just need autonomous air vehicles to kill people. You know, they're not just militaristic in nature and I'm not a business guy so it's hard for me to say what the commercial applications are but I know there's a startup that is doing like civil inspection and stuff like that. People like this kind of technology for, since it's like the handy scanner and stuff like that it's just a mobile handy scanner which is like you can use the laser to get the, you can use the point cloud to make like a pretty good interior model or something like you could put one of these inside of a ship and then just let it go and scan the whole ship and now you just have like an effortless convert to CAD kind of file thing, right? I think people have reached out with us about doing the same thing for exteriors flying around an object and generating a point cloud and making a CAD model out of it. So there's a lot of different applications depending on how creative you are. Those are just some of the few that I know of though. Yeah and I think for this competition with the whole like detecting moving rumbos on the ground I think I've heard, I'm not really sure, I know there's other competitions that focus with tracking humans. I think something that they want to do is more like an automated, like automate the search part of search and rescue. Or maybe even be able to kind of direct people that are like lost in the woods or whatever. You can kind of direct them to an area where they could be airlifted or something. Or even for the military, kind of, I don't know, being able to direct troops with them somehow. I think those are some of the more goals of this competition. We actually almost got involved with another competition, Halec and I, for the World Wildlife, or Wildlife Conservation UAV Challenge. It was basically design a drone that can patrol the wildlife reserves in Africa from poaching and like detect poachers and stuff like that. Yeah and then scare them away. It was actually something really fun. So there's a lot of different cool stuff you can do. So you said that someone has actually reached out to you once about scanning something. Has any of the team members like started companies or have you guys kind of consulted or anything like that? Yeah. So we get approached with commercial offers. Basically people are looking for volunteer work and they know that we're pretty good at stuff. So they'll ask us if we can consult with them. But we're not sure on the logistics legally speaking, so we usually reject the collightly decline. But we do refer them to the startup that came out of this. So one of the, I guess, three of the charter members of the team went on to start a company, Skyspecs, LLC. And they're trying to get into commercializing these drones for things like, I was talking about earlier, civil inspection, windmill inspection, bridge inspection, sewer inspection. They get really weird requests. Some people want to take them on their fishing boats and launch them at sea to look for whatever they're trying to fish and stuff like that. They get pretty weird offers actually. So there is one company that came out of this team. But also I did mention we're young. So this is our fifth year and so there's only really been one very large turnover. So there haven't been a lot of alumni to come out of this yet. But the three that did started a company, so far it's like 100% company ratio. Well, this is a good lead-in. Could you tell us who the members of your team are and who's your PI and who are your sponsors and all that kind of stuff? So there's 10 people on the team right now. Okay, so it's an ongoing thing. This summer there were 10 people working their hearts off especially considering that we all had full-time jobs basically. So there's 10 undergraduate or there's 10 students, nine of which are undergraduates. One's a master's student. Yeah, one was master's. We've got a few faculty advisors. Professor Ella Atkins is our official advisor. She does UAP research actually in terms of safety analysis of how these things fail. Professor Ed Olson at the University of Michigan he's in computer science. He's helped us in the past and we've collaborated with his lab to write some of our software. And then there's also a professor Peter Washbaugh who's in aerospace and he's been really supportive. He's provided a lot of facilities to us in terms of access to 3D printers, laser scanners, a router. And then in terms of sponsors we've got corporate sponsors. Northrop Grumman is our title sponsor. Lockheed Martin provides us with a lot of support. We have the College of Engineering supports us and we have each of the departments. So the computer science department, the aerospace department and the electrical engineering department all give us support as well. So we've got a lot of fans I guess and a lot of support on the university end which is really helpful. And then we have professors that are really interested in helping us achieve success I suppose. Kelly Olson also. She's like the team mom. She provides us with food and love and support. So she's also very sweet and give to us. Oh yeah, she's very nice. Okay so say I'm a student at a school listening to this and I want to get a team started at my school. How does someone go about doing that? Oh boy. That's a good question. Especially because we didn't start our own team. We joined the team. I think the most important thing is that we have a similar interest. You know, we're actually a pretty small team and I think a lot of our work's been done with four or five people. So find four or five diehards like you that are interested in it and then just look at what other people are doing, reach out, see how the problem is being approached to date or even if you're not talking about this specific problem, find something to exist for. So if you just like quadroters people won't find you to just build quadroters so much that you can be a competition and commit to that and just make sure you represent yourself well. A lot of engineering students especially undervalue technical communication how to present yourself. I think a lot of our success comes from the fact that we take all of our presentations very seriously. We have very formal documents that we present to sponsors. So once you have a plan and you have something that you want to try to achieve next you need to be able to communicate how you plan to approach it and why people should take you seriously. So I think those are pretty important steps. Yeah, let me just say coming from the industry perspective here I work with engineers across many different disciplines and many different organizations because I do a lot of open source work for Cisco and boy you really just hit the nail on the head there. The communication is tremendously important. You need to be able to address what you're doing, why you're doing it and be able to work with other engineers and other funding sponsors and things like that. So I think it's tremendous that you have recognized that at such a young age so good job. Okay guys, well thank you very much for your time. You guys have like a website or something where people can find more information? Yeah, um, oh yeah, it's Mavumich.org M-A-A-V-U-M-I-C-H Yep, oh yeah. Yeah, thank you.