 Okay. Welcome to the next talk. Today we have Pete DeVyre talking about building a six-legged robot named Zebro. Welcome, Pete. Well, thank you. So my name is Pete, and two months ago I received my Bachelor in Electrical Engineering from Delft University of Technology in the Netherlands. And for my Bachelor graduation project, I worked with a team of students that dedicates their time to building six-legged robots. And during this talk, I will do two things. First, I will look at why do we build six-legged robots. And secondly, we will look at some of the mistakes that my project team and I made while we were building one of these robots and look at how you can prevent of making the same mistakes. So why do we build these robots? To answer that question, it's useful to first look at what computer scientists have been doing for years. So they found out that if you look at the behavior of animals in nature, and then you model that behavior and change the model a little bit to suit your needs, then you can actually use this behavior to solve complex problems that you could perhaps otherwise not solve at all. And a great example of this is the traveling sales and algorithm that is based on the way that animals find the shortest parts between their nests and foods. And you can actually use that to solve the traveling salesman problem, a problem that is unsolvable by conventional algorithmics. So if you can do this with software, why wouldn't you also be able to do it with hardware? In fact, if you look at an ant, then you see that it's actually a really simple animal. It's much simpler than we are or pretty much all other animals are, but still it's able to traverse all kinds of terrains. So if you would build a robot and model it like an animal, like the robot on the right of the slides, would that robot also be able to traverse these terrains? Well, as you can see here, it actually can. So as you can see, some of these obstacles would be virtually impossible to pass with a robot of that size with wheels. And yet this robot just crawls right over it. So clearly doing this has a number of advantages, and therefore we have been experimenting with building this robot in different sizes. You have the one that we just saw in the video, which is about this big. And then we currently have two other models. We have the really big one that I've been working on for my bachelor graduation project that we'll talk about a little bit in this presentation. And then we have a very small one, this microphone. Thank you, that I have actually brought with me. And this one is actually small enough that you could easily let the child play with it. While the other really big one, I wouldn't dare to stand one meter close to it. And you see that it does. And you can see that it actually behaves in exactly the same way, and that it also works. So that this idea is in fact scalable. And yeah, so I will just leave that one on the table there. And I am probably going to regret saying this, but it has an unsecured Bluetooth interface. So have some fun. So now we found out why we want to build this thing. So now let's look at what problems you actually encounter with building these robots. And in fact, what problems you actually encounter when building something in more general. So the first problem that we had, and we have had this problem for a long time in the team, is that we were not using abstraction. And what I mean with that is that every time that a new student group would begin, we would ask them to build an entire robot. But building a robot is a large and complicated task. And students that join our team are typically only active for two to three months there for their graduation projects. And what would happen time and time again is that they would start building a robot. They would finish it up. Well, they would only finish half of it. And then they would go away. And then the next year, new students come in, and they look at the design plans. And they say, this is crap, we're going to build something new. And it's actually so bad that the beginning of my bachelor thesis was a list of five robots that every time it said, okay, so we started building this robot, but we didn't have enough time. And therefore, some other group started building a new robot. So what we decided to do instead was not asking students to build robots, but asking them to build a module. Because if you look at software design, you see that we've been using this approach all along. You build software libraries that then other people can use, or you build a class that is encapsulated and that can exist on its own. So why not do that with hardware and make a modular design with properly specified interface and good documentation? So that was problem one. Then problem two, having single points of failure. When you look at this, and you're a software or hardware engineer, you probably think, but it's actually more complex than that. It's not only about the engineering part, it's also about the logistical part. In our example, we ordered three different kinds of motors to build a robot, one from China, one from England, and one from Germany. And we ordered them three to four weeks before the actual start time of a project, because these things typically have some lead time. And one week before the start of the project, the Chinese motors arrived. One day before the start of the project, the English motors arrived. And two weeks after the start of the project, we still had not received any German motors. And at that two week mark, we got a call from them saying, okay, so we just received your motors, but you haven't paid the pro forma invoice yet. And we were like, what? But no, we have paid it a month and a half ago. And they said, no, you haven't. So I called up our finance department and I asked them, hey, could you please look up that invoice from one and a half months ago? And they responded with, what invoice? So it turns out that someone had forgotten to send an email with the invoice to the right person in the finance department. So I asked them, okay, well, this is a pro forma invoice and we have a short project. So we really need this part, could you please pay it as fast as possible? And they answered, yes, okay. But we only make payments on Tuesdays. So I answered, well, that's great because today is a Monday. And they answered, no, because this is actually a part from a new supplier. So we have to make a new entry in the system and we can only do that on Thursday nights. And then it takes a night before it actually gets updated. And then so on Thursday, I called them again and they say, okay, so we have made a new entry in the system but the person who actually has to approve this invoice is on a leave. And I asked them, who is their replacement? And they give me the name of the replacement and then turns out that the replacement is also on a pregnancy leave. And then I called the replacement of that replacement and they say, well, yes, okay, I can do it. But they have only changed the system today and it needs another night to become updated. In the end, I ended up calling the finance department for two weeks until someone at the front desk literally turned crazy and then finally they paid the invoice. So that was that. But in the meantime, we actually also had problems with the Chinese motors because when we started testing them, we found out that when they reached a certain temperature, they would use a lot of current for a very short amount of time and then use no current at all anymore and just stop working. So our mechanical engineers opened one of the motors up and what they found was this. And it is that the Chinese had used plastic gears in the last stage of the gearbox and when the motors would warm up, then the gears would slightly deform and would get destroyed by the metal gears. So this shows that if we would have only bought one or even two of the motors and we would have picked the wrong ones, then we would have had a serious problem because we only have 10 weeks for the project. So do not have single points of failure. Problem three. Okay. The red part is supposed to say debugging and the blue part is supposed to say coding or designing. So this is actually another good one. Test everything in advance. Never trust Microsoft Office. And what you would typically do is you would say, okay, when you plan a project, you say, okay, I will use 90% of time for planning and 10% of time for debugging. But then you do the project and you end up doing this. You spend 90% of your time debugging and 10% of your time programming. And these debugging moments will appear at the weirdest moments when you least expect them. For example, in our robot, we have a brush DC motor that is controlled by a custom PCB with a microcontroller on it that we make. And it has a number of sensor inputs. It has a current sensor. It has a temperature sensor that's connected to the motor. It has a voltage sensor. And when we tested everything separately, it all worked. So we said, okay, let's throw it all together. We hooked everything up. We started it. And it also worked for 30 seconds. And then we started it and it worked again for three minutes. And when we kept doing this, it would actually keep doing this. It would randomly work for somewhere between 10 seconds and one hour. And, in fact, the microcontroller would completely hang or debug interfaces would not respond anymore. So we had no way of seeing what was going on. Does anyone care to take a guess about what was going on? Yeah, maybe? No. What was actually happening is that the motors that we're using were making so much electromagnetic interference that the i-squared sea bus was picking up weird signals which caused the controller and the microcontroller to do something that we would have never imagined possible. And just keep generating interrupts which caused the microcontroller to just keep handling that interrupt time or that interrupt routine and having no time to react to what we wanted. So does anybody want to take a guess at how long it took us to find this out? No, luckily not. But it did take us two and a half days and a weekend. And when you only have a 10-week project, that's a lot of time. And this is not the only case where this has happened. So that was problem three. Problem four, not having a decent test setup. When you're building a project like this, your desk will unavoidably end up looking like this. And it is very tempting to just throw away a quick debug setup because you think that testing will only take five minutes and then you're done with it. It will not. So when you're building a debug setup, you really have to take great care at both hardware and software. For hardware, you can do simple things. For example, when you're connecting two pieces of or two PCBs, make a proper cable. Don't just duct tape it together because when you do duct tape it and it doesn't work, you will have no way of knowing whether it's the cable that broke or gave a bad contact or whether something is actually genuinely wrong. And for the software, especially when you're programming microcontrollers, you have no printf statements, unfortunately. So you have to roll your own solution. And when you do that, you have to do it as thoroughly as possible because one hour of writing a debug tool will save you a week of debug time. For example, you see that we have a graphical application here that will actually show live output data of the debug data coming from the microcontroller. And before we had it, we had this. We had been spending a couple of days trying to debug data that was coming from magnetic field sensors that we were using to determine the position of the robot legs. And we just kept having bugs. And then the weekend came along and I wrote this application and by Monday at noon the problem was fixed. So make decent debug tools. It will pay off. So number five, only having a plan A. When we look at this robot that's on the table, then the way that we get feedback from the position of the robot is we have a magnetic field sensor here and we have a magnet in the wheels or in the legs. And every time you make a rotation, you can detect a peak and see, okay, now I know where the leg is. So we thought, okay, if we can do that on this robot, we can also do it on our big one. And we actually used tree hull sensors and eight magnets. So we had 24 positions. But when we tried to make it walk like that, it did this. That is not the direction it is supposed to go. So we were lucky because we had actually factored in that this might happen. And on the PCB that you see on the right, there's actually a port for industry standard rotational encoders on the primary axis. But if it would have not have done this, then that would have meant that we would have to roll a new PCB, that we would have to order a new PCB, that we would have to solder a new PCB and that we would have to debug a new PCB. All of this would take you at least two to three weeks and cost you hundreds of dollars. While when you're designing this PCB, it's maybe half an hour of extra work to just connect a couple of more pins to the microcontroller and put it on some external pins. And what we also learned by this is that there's actually a reason that rotational encoders are an industry standard. So, yeah. So these were five problems that we encountered. I'll sum them up again. Not using abstraction, having a single point of failure, bad planning, not having a decent debug setup, and only having a plan A. And if you want to avoid those, you should do the following. Build a module, not a robot, prevent single points of failures, factor in debugging, make proper debug tools, and have a plan B. Thank you. Thanks very much, Pete. I think we've got a couple of minutes for some questions. Are you up for some questions? So anyone have any questions? Yes. Hi. So you mentioned all the problems that you had trying to, like technical problems you had to overcome. Did that cause any problems between you and the other people in your project that you also had to overcome? Could you repeat the question, please? So did the technical problems you run into cause a bit of friction and make it more difficult to work with the people that you're working with? Yes, actually it does, because when, for example, a person has been debugging on a problem for a couple of days, then you really start to develop this tunnel vision. And all you can think about is this problem. And it has happened sometimes that someone else comes along, take a look at the problem, or makes a new system parallel to it, and gets it to work in a couple of hours. So that can be quite confronting, but I think it's important that as a team that you manage to deal with this, because in the end you all want the same thing. And the way that you get there should not really matter, and it should not be about personal pride. Any other questions? All right, doesn't look like there's any other questions. So I'm sure you can probably come up and have a look at the robot, probably outside if you've got a space to put it out there somewhere that people can come and have a look. Can you join me in thanking Pete for his great talk?