the Hard Way, because we are talking about three robots, one each with their particularities. So I named this project Trust Robotic Router Platform at the beginning, and the leitmotif

was a low or nothing cost of embedded platforms, the Internet of Things, and they use whatever is lying around. And I don't like to recycle, don't recycle at all, simply reuse. So for

the first two robots, I decided to use a router. Some of you may know the Lynxys, it's a very

classic router. So like seven years ago, I decided to build my first robot, it's called Texas Ranger. So we are going to see why. The main reason is to use the Lynxys. Seven

years ago, there was no Raspberry Pi or maybe Arduino, but it was very new. So I decided to use a Lynxys and a homemade PIC board, homemade. So I loaded two Lynxys,

the Linux OpenWRT, and we got everything. And the second one was a drone. We are talking about all of them with the LaFonera 2201, a very old model indeed. So the round one

is the Robotic Ranger. You can Google it, and you will find a lot of stuff about this. But I would like to share with you this robot, but this was the first time

with a robot. So this robot has a Lynxys, two boards, an AP camera, and two guns. The two guns are made with plastic guns, turned backwards, and all the bullets

fall into the camera. So I only need a transistor to make work the gun from the PIC. The PIC

was connected directly to the Lynxys by serial port, and we have an interface. And the laser was used to estimate the distance between the robot and, for example, the wall,

by calculating the distance between the most bright light on the screen, the capture screen by IP camera, the router decompress the image, and then, well, it calculates, estimates

the distance between the robot and the wall. So the first one is the Texas Ranger, and

the Texas Ranger is the same technology at the beginning, because I still use OpenWRT, and I was to program the stabilization process inside the router, because I decided to program

my own stabilization program and avoid any kind of board, like a pilot or so on, just for fun and to learn how the stabilization process works, and I would like to share with you my insights.

So the telemetry and control, the first attempt was a success. It was by control by the web page of the router, by

K-Strux by Haberscript, but I found that was not very comfortable to pilot the drone, especially when the drone can kill you, because it's too big. So we all know the ABC

for quadcopters and drones, so we can skip this slide. I think that we all know we have four motors, two spinning clockwise and the other two spinning counterclockwise, so we have a complete control over all the axes. You want to turn to one side, we spin faster,

one motor and the other. Well, this is the architecture of the Atropos. This kind of slide is for troll you, so don't be afraid. We have a La Fonera in the front

with a background process, but at the beginning we have a client in a web page with an iframe

taking the camera. The first time it was an IP camera, and we have a control for this one. This is not an RC, it's a USB trainer, so it's like a remote control, like with PlayStation and

so on. La Fonera takes the commands through our Wi-Fi and tells to the main process all the commands from the pilot. That flight control runs inside the Linux box,

inside the Linux router, and it has to be some kind of special tweaks in order to achieve some kind of real-time execution. We know that Linux is not indeed

by default a real-time operating system, so we have a special policy scheduling policy to achieve this some sort of real-time response.

So we need to exit, we need to read sensors, make equations and send the command to the motors in a fixed time, in a specific fixed time. So we cannot make 100 calculations in a second

and 200 in another second, because you have to be very time constrained. We are talking about that later. So the inter-process communication is made by certain memory for fast response, and the sensors are the Wii Motion Plus and the Wii Nunchaku. It was taken from the

Nintendo Wii console, because like six or seven years ago, it was not so easy to buy a complete set of sensors, and the best choice was to go to the supermarket,

buy some Wii sensors, not having the Wii console, and connect it to the router lights. So the first step we need to identify in the router is, where are the lights?

Because the lights are GPUs. So if we have enough GPUs identified, we could make a virtual I2C bus by software. So I could identify four pins,

for example, the LED network activity or the Wi-Fi activity, we have several pins identified here.

So I could make two I2C buses to connect the Wii Motion and the Wii Nunchaku. Well, this is some kind of professional soldering. This is pretty awesome, I know.

So we have the GPUs, let's attach to that, and the serial port, that is useful too, as you know. And there are the steps to compile the model of the I2C.

You don't have a driver, because you don't have a specific hardware with I2C. Simply you create an I2C bus, but by software, it's not related to any specific hardware.

So we have to load these modules, and that's the commands, we tell to the kernel middle which pins of the CPU are related to clock and the data. So we will bus 0 and bus 1,

with the GPUs 4, 7, 3, and 1. So I leave this information, we load the module at the start, and we can throw the I2C detect command as normal. But this is the serial port

of the Funera, it's no real mystery here. And I would like to explain how it works a little, and why I need a Wii Motion Plus for the Atropos.

Well, Wii Motion Plus is a gyroscope, so we have a three axis, pitch roll and yap. But it gives me angular velocity. To take the real angle, we multiply angular velocity by time. But there is a problem, it drifts.

If you multiply over and over time, it will drift. And it's the same problem that if you are too drunk, and you turn around enough times, you can go to the ground.

So we need an accelerometer to cancel that drift, and the accelerometer is taken from the

drift, and takes only when the drift has to be cancelled. The other time is not necessary. And the magnetometer, this is not mandatory, because it only cancels the course angle,

so it's optional. Well, in order to read with the I2C, with a Linux program, one of the easiest ways to read it is including the I2C header of the Linux kernel,

and we rate it like a regular file. We can ask for the specific sensor that we want to read,

by sending an IOCTL command to read the gyroscope or the accelerometer. This is the funny part, because we have to mix these two sensors to obtain an attitude,

and the real motion of how the drone is moving, in order to react and send the proper commands

to keep the drone stabilized. All this is managed by the autopilot easily, you can put the autopilot and everything works fine. But if you want to make this by ourselves, we have to deal with this shit. But it's a pretty fun shit, because

the first approach that I made was the poor man Kalman filter. Do you know Kalman filter, please? How many? One? Well, it's fun. You? Okay, two.

It's pretty fun. The original paper was the balancer filter of the

approximation, the first approach was to take the angle of the gyroscope, multiply for delta time. Delta time is the time between reads. That is because it's important to keep reads

at the same time, because dt is fixed, it's a constant. So you can remove that from the equation if we have a fixed delta time. So, this is our first approximation,

so we have some kind of stabilization, because I'm taking into account very much the gyroscope, but too little the accelerometer. You have here the games, and we have some kind of

stabilization, but this is the funniest part, because what happens if the drones, this is the sensor, and the sensor takes into account this turn, this turn, and this, pitch,

roll, and yaw. Its axis is related to each axis of the sensor, but what happens is, I'm moving like this. The pitch is no longer the pitch, the yaw is no longer the yaw.

The yaw is not the last movement, it's not the same movement. Again, we have a yaw, and the yaw is like this, but the yaw now is not like this,

it's like this, but the related axis of the sensor remains the same. The yaw for the sensor still is that, but for the drone, no more. That pretty stuff is blown mine from the first time,

because we need a three plus three matrix transformation in order to transform the coordinates of the sensor to the coordinates of the drone. So we have a nine values

that is related to the x of the aircraft, is related to the x, well, you see that, okay. So we have to work, once we have the conversion between the axis of the drone at the axis of the

sensor, we have three things. Absolute angle, radiance, we have angular velocity, radiance per second from gyroscope, and the angular acceleration, radiance per second per second.

Okay, so don't go away, please. Once we have an attitude, we have to send a proper command to motor, but what command,

what quantity, what fucking shit of anything. So we have this algorithm that you can, it's taken from the Wikipedia, okay, this image, you can search for that. And we have three terms, okay. We have the proportional term that this, we have a zero, I have to say

at zero angle to say stability size, okay. My set point is zero, but I am at 10 degrees. My error is minus 10 degrees, so you have to, I have to take into account the error

that this is the difference between I am and where I am to, I want to stay. So I multiply the error by a number, which number? I have no idea. I have no fucking idea.

The first approximation is, okay, let's test, okay, and you test. You put the drone like a segue, fix it with only movement with one angle, and you test how its behavior. But it's not enough. You can't control a drone with a proportional

gain because it's not enough. You have to take into account the integral. Don't throw me things, please. The integral is,

it only takes into account how much time I am with the error, okay. It's like you take the mouse, and you naturally, your brain, are calculating the integral. Because if I can't lift the mouse, my brain without notice, I'm not noticing that, but my brain will send more

power to my hand to lift the mouse. That is the integral. I'm not on time with the error,

so I accumulate the error to correct. And the other one is the derivative. The derivative thing takes into account how much speed I'm approaching or leaving my set point, okay. So I have to take into account that returns, and I have to tune it by 3-line error, okay.

It's the best way, although you have the real model of your drone, almost all the variables, and you can calculate Laplace transform and so on, okay. But for poor men, you can

try to real an error. So this is an STP, because we applied a PD to angular velocity, but

over the roof, we apply a P controller. This is just for the record. So this is the Atropos with a professional grade mounting with all the stuff. And once we have calculated all the calculations, we have to send to the motors the signal. So

the signal is a PWM, a pulse width modulation, that it cannot be made inside the router,

because it's not in real time. We have a specific hardware. So I use a PIC, okay. This is the real-time scheduling from the process inside of the Linux box. This is only for if you want to investigate. I use the SKET priority library.

So in a policy of first in, first out, okay. So there is some process by default in the Linux

box that they are useless, okay, that's the what's wrong, because this is what happens if the router hangs with I'm flying my drone, okay. It makes no sense. Well, we see the

motors and so on. And this is how I control the drone throughout the web page. This was my first approximation with Ajax, but I had to tweak the

the web server, because too much, too fast Ajax petitions, queries, they are too much for the router. So I have to tune the web server, okay. That's the remote.

And this is only a joystick, okay. It's a regular joystick. And I would like to say some things about Android, because I was thinking about to

avoid a PC to control my drone. Okay, I'm going to put all my stuff, my piloted stuff to a tablet, okay. So I have to recompile the whole image only for a tiny and ridiculously

module of joidep.co. So, thank you. And the last one was in a talk in Spain, a guy sent to me the authentication package to the Wi-Fi of the drone. It was not so funny, okay.

So I decided to make my own protocol by Wi-Fi, but I explained in the talk before this, you can find it with the project interceptor, you can find the DEFCON

web page. This is my project interceptor. It's made with chopsticks, because if I make with a 3D printer, nobody believes me that this is my drone, okay. So, and I like this sheet.

I like to make things with my hands, okay. So I decided to make a much smaller drone than the Atropos, because Atropos can kill me, especially when I travel with it

with the airport. So I decided to make a hands-side drone. This time with our regular sensors, that you can buy in Chinese dealers and so on, but there are some things that

they have to take into account. First of all, that Chinese sensors, maybe they are not documented, okay. Maybe you can tune the filters and maybe your drone

has too much vibrations. If you look close enough, look at this.

What do you think that that could be? Well, there are the English term, thermo fusible, with this kind of pipes you take to protect wires with the solar.

Shrink to it, thank you. As a dampening, okay, to take into account the vibrations.

So it was enough, and I attached a 20 euro cent coin to make the sensor the perfect weight to absorb the vibrations, okay. I have to do this because I can't tweak the

filters of the sensor, but it has an advantage. That sensors make all the math stuff for me, or not all, but the first part, okay, the real estimation.

It's not bad yet, 40 dollars, no seriously, and it has hacking capabilities, and the ideas have to minimum size and weight. So it is based on the

tiniest, but it's like a router, it's like a regular router, but you only have the board,

okay. I have no commission for this, but you can see all the parts, that's the big core, and the interesting part is it has four pulse width modulation outputs, and that's because I

can't avoid an extra microcontroller for my setup. But there is a problem, when you build the big core, only two modules of the pulse width modulation are enabled.

The other two are for word debugging, okay, good job. So we have to disable UART and enable the other one. But I went to the forum of the big core, and a random guy asked,

how can I disable all four pulse width modulation pins, and the big core creator as well, huh, this is a hard way. You download the OpenWRT, you find the the

protocol, the DTS, the DTS is the pin definition of the big core, okay. DTS, your mobile has a DTS, the Raspberry Pi has a DTS, it defines how the pins are defined, okay.

So you have to understand the pin control section, and better take the circle. So then you can enable this module, and you will be a good Linux hacker, good job man, very helpful. So this is what you need to enable the four pulse width modulation

outputs, and disable the debugging UART. So we have to redefine the pins, but we have a pin name, but and a pin function. This can be tricky, because we have UART function

and UART name. If you can see that, we have the UART pins, but with the

not the word function, but the pulse width modulation function, okay. We redefine the and we have. This is only for the record, the data set, that you can, you have to take this

information, and this is my pretending that I'm knowing that I'm doing my work. The power stage of the interceptor drone is not performing with an

electronic speed controller as usual, because I choose a brushed motors, okay, brushed motors, doesn't need an entire electronic speed controller, it's only needed one MOSFET, a capacitor, and a SCOTY diode.

Why we need some kind of stuff, a part of the MOSFET? That is because the motors, when we power the motors, we are putting power on the circuit, okay, but we are not

powering the motors at maximum capacity, okay, we are modulating more or less the power. So, what happens when we turn on and off the switch of the motor? The motor generates

electricity, because it is spinning, it acts as a generator, so we have a standard electricity flowing as normal, but we turn off the motor, we have the

counter-electromotive force, okay, that this generates, puts a current in the circuit, not from the battery, but from the motors, and it could harm the

circuit, so we have to suppress it with the capacitor and the SCOTY diode.