 Let's get started. What is this about, why from scratch? Then we're going to see what we want to do, what we want to have, what is going to work against us, how we can overcome these constraints, and the details of what choices we're going to make, and eventually what would be nice to do in the future. A couple of years ago, there was a huge craze about drones at ELC, and I was like, well, why don't I try it myself? Nowadays, it's so inexpensive to give it a shot that I didn't feel particularly bad in case I would just buy a bunch of equipment and then give it up. But it didn't go like that. For me, it was also a sort of challenge to myself of, OK, everyone seems to be able to do it with a huge course on it. Can I do it, starting from the other end? Back in the days when I started working, I used to work on microcontrollers for automotive dashboards, and there you had 8-bit microcontrollers. So for me, the idea was, can I try to use that experience and bring it to a drone? My other thing is, can I make something which looks like a toy but can be a sort of educational tool for my children? Why not also for somebody else? In these cases, you don't want to give to a child something particularly expensive, because you know it will break eventually. Away from scratch, there are a bunch of reasons. One was, well, it didn't seem fair to reuse existing frameworks because that would have not really been a full learning exercise. I have nothing against what is already available. I'm sure it's far better than what I did. But for me, the idea was to really learn about the ropes about it. And second, most of these frameworks they tend to assume that you have a certain hardware configuration, a certain minimal amount of resources, RAM, and so on, which was going against the grain of the goal I set myself on. And the really idea was, how much can I squeeze out of this really low end hardware? I decided to start humble, so four wheel drive drone. Flying drones are cool. The problem is that when you have a software crash, you can end up also with hardware crash, physical crash. I wasn't ready for that yet. I still am not. Also, if you like my main source of material is eBay and you find a bunch of things about that there. That's a lot of components or kits that are really cheap for wheel drive drones. I wanted to make it so that it would be possible to plug in and out new components, experiments. So that required also a certain level of modularity, which kind of goes fine with low cost, because usually what you find are cheap components which do one single function, and that's OK. The main problem with flying drones is weight. You have to be very careful about your payload. On car drones, it goes a bit easier on you because you have a floor which supports it. So the only thing you have to care about is just to move the motors and inertia. And this modularity was also the idea that it would support the ease of debug, like unit debug. What I set myself as requirements were to be able to control the speed, the steering, and to have some means of controlling remotely. Obstacle detection, avoidance, camera string were nice to have goals. And for the sake of not disappointing anybody, later on I haven't managed to reach them yet. I have some work in progress on some of these items. Long term, remote computer vision, onboard computer vision, but these, they kind of go against the fact that I'm really trying to keep the bill of material cheap. Since I said this is a sort of hobby project, I didn't have much time to put in it. And really the idea was that this would be a kind of toy, and therefore I really wanted to keep it low cost. Nor I wanted to start depending on some custom made PCB. Some of these projects I've seen, they do that, but then I have nothing against it. I mean, if you're making a real commercial product, you want to leverage all the weapons you have in your arsenal. But this was not the case. Although I've seen that some companies offer fairly inexpensive creation of PCBs, but there's still kind of one level of magnitude, more complex than what they wanted to keep too. But this is just more details about what they wanted to achieve with the system design. So, okay, one more point is power efficiency. It's true that this is a car, but still there are ways to waste power even there. And I am gonna try to explain what is best and what is not so good. As I said, weight per se is not an issue because you don't have to keep it flying, but still you have inertia. So that affects how different or how complex is your steering model between the ideal case where you just say turn and it turns and the real case where it can even skid. So there is also a goal to keep the mass low. In this case, not so much for the weight, but for the inertia that it can gather when it's moving. Then finally, sometimes we make mistakes. You connect the wrong wire. So the idea was avoid to fry the most expensive components. So try to have some sort of buffer between the high power part and the more expensive control logic. This is a preliminary thought I had and at least these are my conclusions. If you think otherwise, feel free to stop me and we can talk about it. But basically, this is a comparison between two main options that are available. Nowadays, you can buy basically single board computers which have a bunch of GPIO, a bunch of PWM, ADC, plus kinda high end logic. On the other hand, you can have one such thing or similar which is kind of the brain of your system plus one or more microcontrollers which implement some low level functionality. As you can see from the amount of green, my conclusion was that it's preferable to go down this path because while it might be less convenient for flying drones where as I said, weight is an issue, here it's easier to compartmentalize functionality and debug it. Also, sometimes you want to have, if not real time, close to real time responsiveness. This is easy to achieve if you have even a 8-bit microcontroller which is doing one or two functions only possibly through some hardware IP block. If you start to put all the possible functionality on one single PC-like core, even if it has multiple cores, you still have a problem that you have to guarantee a certain set of time constraints. What some more advanced SOCs do is they have a sort of companion core inside the SOC to which they can offload some of this functionality. But then the problem is you end up tying yourself to some sort of proprietary solution. One example is the Intel Edison. If you look at the specific schematics of Intel Edison, there's an additional Pentium core inside it apart from the Atom core. And this Pentium core is the one which generates PWMs, controls, GPIOs, attacks, for example, as a interrupt controller. But then you end up having to develop for that. And for example, in the new version of mobile platform, this microcontroller has disappeared. So if you had put your time on that, you now have to start again from scratch. While if you select your own microcontroller, you are the one who decides what stays and what goes. Some considerations, again, I'm not gonna claim that what I've decided to be good is one solution that fits everything, but it was okay for my needs. If you are trying to do something different, you might find that what I have done is not appropriate or not adequate for your needs. It's true. Again, about the multi-board approach. There are, for example, still about the real-time responsiveness. There are, there is a set of patches which make Linux become a real-time OS. They are from Thomas Klexner, and over the years, and it's more like, more than a decade, he has managed to massage most of them into the Linux kernel, but still there's a delta. So if you want to turn your single core machine into a real-time machine, you have to, for example, start patching and maintaining the kernel, which is not necessarily a bad thing, but it's additional work. On the other hand, if you have a set of microcontrollers, you can choose for each of them the real-time OS you want to run on them, and there you go. This is a very simplified view of the system. The backbone of it is the I2C bus. Let me see, okay, this is another option. So in option A, there's a sort of main board which can be interacted with over WiFi or some other radio, but it's kind of high-end implementation. The other view is if I put just a simple microcontroller which acts as a bridge between radio connection and the other microcontrollers, and they have a transmitter, this is a sort of remote control car variant, so it's as dumb as it gets, almost. There's a bit of assistance in the control of the motors, but this might also be a nice toy. Yes, one word about the power distribution battery, so maybe some of you are already familiar with it, I wasn't. I noticed that sometimes when I was giving full, I was giving command for full power, the system would just shut down, and this is the type of power distribution I was using. I had DC motors attached to a nine-volt voltage regulator and the control logic attached to a five-volt control regulator, and both of the regulators were attached to the main battery. It turns out that DC motors can drain quite a bit of a current when they are accelerating, and the typical cases of acceleration are from steel to full power, or even worse if you try to reverse the direction of the spinning, and this was causing a voltage drop across the battery. So in some cases that I found, some people even go as far as deploying two batteries, one for the logic and one for the actuators. This is the safest way because you really cannot influence one with the other. The other alternative is to limit the current that can go into the motor so that it never brings the battery to have a voltage drop. And this is the way it changed. So I replaced the normal voltage regulator for the motor drivers with another one which can also limit the current. This way it reduces a bit the maximum torque that the DC motors can provide, but on the other hand they wouldn't manage to do much because eventually the battery would just not provide all the current that they try to draw. Now I already mentioned that I'm using DC motors, but how did they come to this choice? Mostly in this case when you're driving wheels you have two options, and you can see them in various type of robots or cars that people are playing with. DC motors are fast, they are cheap, they are robust. They're not precise or rather they are in open loop so when you give some comment that you don't know exactly what the output will be. In other cases for low speed robots something which requires precision movement people use servo motors. If you know for example the Mindstorm kit from Lego they do have servo motors for that. That allows the main brake to just issue a command or position command and that's it. In real life there are various issues with the servo motors if you try to use them in high speed cases. For example they can vibrate, they need to be modified and they are also going against the constraint I set myself to try to keep the bill of material low. They are indeed more expensive. So I went for DC motors. This is an example of what you can find on eBay or Amazon. What you can see is the DC motor here, it spins fast and then here there's a gearbox which reduces the overall speed of the wheel. The option I choose has on the other end optical encoder. It's basically, if you are familiar with all the ball mice for computer they had the same stuff so the ball was making two of those rotate. The way they work is you have optical coupler which is LED and the photo transistor and the small windows that are in the optical encoder they pass between the pair. So sometimes the light can pass and sometimes it cannot and this generates a train of square waves and the frequency of the square wave is proportional to the rotation speed of the optical encoder. So this allows us to measure the rotation speed by just counting the number of transitions that are happening on the optical coupler. This is an example of optical coupler that I'm using. They are quite common in the wrap up world because that's what they use as end of line. So when the head of the 3D printer is moving they need to detect where it has reached the farthest position and this is how they do it. The platform I chose it even had the holes that were exactly shaped for this so I suppose that's what was meant to be used. You only need to basically power it and read the output and to read the output the way I did it is to put it on a GPIO configured as input and count the number of interrupts I was getting on this GPIO. It's the safest way. Sampling is not a good choice because in order to sample one should do constant reading at the frequency which is at least twice the maximum frequency of the train of square waves in input. So that would waste a lot of computational power just for reading mostly nothing. Interrupts is the way to go because you get to handle only the real events when there's a transition. This is how DC motors are driven. So what you see here is a H bridge and basically the way it works is opposite pairs of switches are closed to make the motor spin either one direction or the other. So for example, S1 and S4 if closed would make the current flow like this and for example make the motor spin clockwise while closing S3 and S2 would make the current flow like this and make the motor spin counterclockwise. This comes in a nice package like this and this is where for example I found out the hard way. First I tried the wrong one. There are two major options. Nobody usually tells anything about it but the one on the left is such that it can significantly affect the power you can deliver to the motor. So the efficiency is not so high and you can end up losing 20, 30% of power on the motor's driver. One hint is this one has a huge heat sink attached and that's because it needs to dissipate all that power that is not going to the motors. This one on the right instead is much smaller, doesn't have a heat sink and it's way more efficient and therefore it doesn't need to dissipate any heat. The price is not that high, maybe it's like 50% more but we are talking about a few dollars. The way they work is the following. You have two lines going to the motor driver, that's what we see here, these two and in input you give three comments, three lines, this PWM in one and in two. There's written A and B because each of these can actually drive two motors. So each of these can drive two motors and it means that you have twice the amount of input and twice the amount of output. Basically with two control lines, two binary control lines, you have four possible combinations and these are, make it rotate freely, which is sometimes useful. I haven't been able to figure out when I would like to use it but it's there. Make it rotate clockwise and make it rotate counterclockwise and the other way is to just lock the motor so it holds it in place. The PWM is there because we haven't still discussed about how to control the speed of the rotation. So the speed of the rotation is done by generating a PWM signal with a variable duty cycle and the DC motor acts as a low pass filter. So in practice the DC motor is integrating the PWM signal that it receives and it is driven by the integral of this PWM signal. So if you go from a fully saturated PWM signal, in this case the PWM signal is controlled or has 256 levels, it's 8 bits so you can go from zero duty cycle to 100%. And this is what I'm using to generate all of that and read the interrupts. If you are familiar with Arduino Uno, this is just a variant of it. It's much smaller, it's about this large and you can find it for about two dollars. For each motor what I can do is drive the status, meaning set it to spin clockwise or counterclockwise. I have a hardware PWM generator which is used to control the speed and I can read the output from the optical encoder, meaning that I can measure what is the actual speed which means that I can have a fully closed loop. And it's kinda nice because this is done for each motor individually, so four times, two dollars. I wish this stuff was available 20 years ago. They make nice toys nowadays. Okay, this is what I already said earlier. One more thing that I'm using is a proximity sensor. So the proximity sensor, I haven't fully integrated it but basically what it does is sort of a sonar. So you have to, it has two pins, you have to give a strobe on one pin. This strobe needs to be about 10 milliseconds and that will cause the sensor to generate eight pulses and after that it will start listening for the Ecos. The output is a gate signal on the Ecoline which has duration which is proportional to the time from the last of the pin and the reception of the Ecol. That's the maximum time after which the Ecol is considered to be lost but basically what you have to do is measure the time that goes between these two transitions and that gives an idea of the distance of the object that you have in front. I'm using eight proximity sensors. You might have seen some installations where there is one and it's mounted on a motor so that basically the motor is made to make it swipe nightrider like if you want. That has a set of problems which are, first of all, stability. When you are moving, you cannot reliably detect Ecos so you have to wait a bit so it's not a continuous swipe but rather a set of movement. I don't know, I think the typical stepping is maybe five, 10 degrees and then you have to wait for a little bit and then you have to generate the ping and listen to it. That kills the idea of having high resolution scanning because if you are on board of something which is moving, it's difficult to keep the correlation between the movement of the Ecol and the movement of the vehicle. So the solution I choose is to have them fixed but to have many. Other problem is since these devices, they are roughly identical so they all work on the same frequencies, in the same audio range. You do not want to generate interferences meaning that if two are active simultaneously in the same direction, one might pick up the Ecol of obstacle detected by the other one. My solution is to drive them from the opposite sides of the vehicle. So I mark here in pairs those which can be active simultaneously. So for example, front left and bottom right because anyway there's the current between so I know that the Ecol shouldn't. There might be some type of reflection but that should be so attenuated that it shouldn't be noticeable. What I have not tried yet is to see if I can use them in double pairs. So for example, all those at the corners simultaneously and then the front back and the sides on another round. This would increase or double the time resolution but that part I still need to try. Now coming to the microcontroller itself. If you are familiar with Arduino, typically what you get is that there's a main loop and you can configure some interrupts but that's it. If you go for 8-bit real-time operating system you have much more available. You can have again interrupt handlers but you can have also task scheduling. You can have more complex structures like a semaphore, mailboxes and that's what I decided to do. Other thing is at least at the time when I started looking to it, Arduino was a bit of a problem because libraries were usually written for a single case scenario. Example, there were libraries which would detect the interrupts but they might conflict in terms of what resources they were using with the library driving the PWM because in general people don't run multiple use cases on the same microcontroller. So in that sense I had to rewrite a bit of the BSP that I was using. When I was looking for the real-time operating system I narrowed the option down to these two. FreeRTOS is probably the, or it's definitely the best known one because it's available for a variety of devices from 832-bit microcontrollers. The problem is that I couldn't find a port for the specific microcontroller which I was using which I found kind of strange but maybe there isn't so much interest. There were a few people who had done their own port but they were all kind of all the attempts and they didn't seem to be particularly successful. Also another thing that I found was that many people who were using FreeRTOS were complaining about the memory footprint. I haven't verified it myself but I found quite a bit of people saying that with a few tasks they had already run out of memory. On the other hand the one I choose, Chibio S has a much smaller footprint and it has actively maintained the BSP for the microcontroller I'm using and therefore I decided to go with that. Then comes the part about I2C development and debugging. I will not say much about this because I had a talk about how to create a I2C device six months ago in San Diego. I've put a link to it. Basically what this is about is, okay, I have, if I have this sort of architecture and this is the I2C bus I need to have a way to create something, in this case these microcontroller slaves which can be proper citizens on the bus. Why am I doing this is for doing this sort of activity there are a certain number of ready made boards that can do motor control for example but they're not exactly matching my needs. Also those boards they tend to come with limited amount of addresses while if I'm creating my own I2C slave I can have as many as I want of each type. Usually you do not get many variants of I2C slaves in terms of addresses so it means that on the same bus you can have only one or two, four at most in general. So just as a quick summary, the tools I've been using are AVR Dragon which is a tool made by Atmel and not only it can be used to flush the microcontroller but it also supports hardware debugging, hardware stepping which is kind of hard to do otherwise. If you're not familiar with it, the way it works is through the hardware reset line, it implements a protocol for AVR microcontrollers and every time you step through one instruction to the next it rewrites part of the memory so that it will stop at the next instruction. It's quite aggressive on the memory consumption, sorry, on the memory ware but it can make the difference when debugging because you do not have to rely anymore on a printf or equivalent, you can just see the content of registers. Then to analyze the bus protocol, basically to monitor that the slave was writing that what the slave was writing would be as expected, I use the bus part. This is a, there's a couple of versions. The one I have is based on FPGA which does sampling of the bus and it can interpret and decode the various protocols, I2C, SPI, you can also use it to generate messages on these buses themselves. Then I use a cheap 8-bit logic analyzer plus CROC and policy view. This basically turns your PC into a digital scope and for the analog part I use the Hantec scope plus Open Hantec. All of this I'm talking about is done with Linux so you do not need to resort to Windows for this. One thing that I had not accounted for but eventually turned out I had to do was develop my own high level protocol debugger. What you see here is just a screenshot of a tool I whipped together in a Python plus a TCK which uses the bus pirate to send and receive messages over the bus but allows me to do control of high level functionalities like calibrate, set a certain wheel to a certain speed, start it, stop it. I just realized at some point that it was not feasible for me to enter manually all the low level commands which would yield some high level functionalities so I had to basically put them together. And now we come to the selection of a main board for the case which is not just a remote control car. My conclusions are that this is what is needed. Of course, master and Linux, it's kind of my requirement but I wanted to keep a development environment that I was familiar with. Low power consumption, this is relative in the sense that most of the power goes anyway to the motors so it should be so that the power consumption of this board is negligible compared to the motors for the duration of the operations. It needs to be at least capable of behaving as a master on the S2C bus. Wi-Fi, mostly because when I work with it I set my Android phone in access point mode and I make the board appear with my phone. Other types of radio would be qualifying. I just found out this to be easy because I can SSH directly into the device from my phone. A small form factor because the car itself is not that large and USB on the go master, this is a requirement for future functionalities. My intention is to not use any, or my intention is to use, for example, USB webcams for taking images. At least for a monoscopic view this should be sufficient. I do not know if it will be enough for a stereoscopic view but that's what I'm planning to try. I put here the option I contemplated. This is a bit biased by the fact that working for Intel I actually have access to some of these boards at my office. The one I've chosen at least temporarily is the first one, the Intel Edison. This is a bit old and it's not that cheap. So it goes a bit against the grain of my initial requirements but it's the only one that I could get to work reliably. What I'm planning to do next is to use the chip. I don't know if you're familiar with it. It was presented six months ago at ELC. It's advertised at $9 computer so it definitely fits the bill of being part of a low cost drone. The only problem is that it has been delayed so I haven't been able to use one yet. I hope it will arrive by the end of the month. And then finally the Intel Joule. Actually I do have one of these on my desk. The problem is first of all it's more expensive than Edison because you're getting basically a real computer in it. So it might be interesting to use it for computer vision test but not for what I'm trying right now. And furthermore the board I have for it requires 12 volts so it's not compatible with what I have. I've seen that there's a tool called Gepetto which is a sort of helper for generating PCBs but even there the price goes high quite fast in the range of hundreds of dollars when one tries to get a board for this. So it's probably good for a high-end drone but not for this one. What I'm planning to do in the future is this. I don't know exactly in which order. I guess the major change is eventually it should work or so as a quadcopter I just need to get enough intelligence on board to be able to manage the stabilization. And that part I don't know if I can still keep the price low but it's minus score. Is there any question about this presentation? Thank you for listening. Thank you.