 So this talk is on the Experimental Robot Project and let's start with a simple introduction and then the talk will be divided in two main parts. In the first part I will cover simulation and discuss what needs to be done theoretically to build a walking robot. And then in the second part, which is not so well developed, I will discuss what we are doing to make this a reality. But let's first start with the goals of our project. So the idea is to build a roughly life-size humanoid robot. But first we are going to focus on the problem of walking. So initially we are not going to have arms as walking is difficult enough that it is. Life-size may mean not human size, but teen size. So right now we are aiming at a meter or something, but this is subject to change. And I will discuss later why it is this difficult and why one might want to make it smaller. Now there are obviously several projects which attempt this, but we try to... The goal of the project is to be fully free. So we are going to make open-source software and open hardware and document everything. We try to have a state-of-the-art software, but obviously the hardware needs to be optimized for cost. Otherwise it's just no one is going to be able to copy it unless you have $100,000 or something. So why would one want to build a humanoid robot at all? Well, it turns out that wheels are fairly ideal if you're on the street. You can't really beat a car on your feet. But if you're in the jungle or something or in a building that has collapsed, then the situation is reversed, then the wheels are fairly useless. If you've ever been forced to use a wheelchair, you can attest to this. Even, I don't know, there are probably decades of regulation and it's still extremely annoying if you're in a wheelchair and try to get into just about any public building. The other thing is that human flats or places where people live are not necessarily designed for wheels. And so a service robot that works in a household may need to climb stairs and that's very difficult to do with wheels and so on. And if you've seen the DARPA Grand Challenge, then you probably know that disaster recovery is also an important reason. So buildings that have collapsed, as I just said. But of course, the real reason for us is that this is cool stuff. Basically, we're building this because we think this is cool. Everyone wants to have their own Mr. Data. Well, we can't do the artificial intelligence part yet, but maybe we can do the walking part. That's at least the start. Let's see where this leads. As I said earlier, the progress on human rights definitely seems to be heating up. There were two very successful companies, Boston Dynamics and Shaft. Boston Dynamics is probably best remembered for the quadruped big dog, but they're now working, they have made successful bipeds as well. Shaft is possibly less well known, but they did very well in this Grand Challenge from DARPA. And those are now owned by Google. No one really knows what Google wants to do with these companies, but I don't know. In any case, they are extremely secretive. They publish YouTube videos, and that's about it. They don't publish scientific papers or anything. They are university projects, and they are somewhat more open in the sense that they produce papers, but they still don't usually publish source code or card drawings or stuff like this. Also, the university-based projects produce, of course, at least $100,000 because they use extremely expensive parts. On a completely different note, there's a whole graph where they have a branch in computer animation where the goal is to use physics to animate characters. And this is actually a hot topic, and people are doing extremely impressive things. How well this would transfer to a real robot is questionable, and I'm going to say a few words about that as well. So the first part, as I said, is going to be on simulation. The idea is to make a simplified model of physics and simulate the robot. And we're doing this for three reasons. The first is to develop the controller, which is actually a big part of the project. The second goal is to evaluate what kinds of requirements we're going to have, and, of course, also to inform design choices. So at some point, we need to decide what kind of design we're going to run with. The whole set of the simulation will help us to do this. We are using a dedicated dynamics toolkit, which we have written for the purpose, plus an open source physics engine, ODE, which is often used in games. The idea is to use an external engine to avoid the possibility of making it easier by exploiting bugs in our own implementation. So basically, we're using a stock unmodified physics engine, and if the controller can get the robot to work, then it's still not going to work in reality, but at least we've made some progress. So how would one assimilate a robot? This is rigid body dynamics, and this is actually the most popular method used in game physics. The assumption is that there is this thing called a rigid body, which is a body which is completely non-deformable, so it can't vibrate or flex or anything. And this causes the physics to simplify a lot. In fact, the whole body is described by 10 mass-like parameters. And apart from that, the details of the mass distribution completely don't matter. So it doesn't matter if it's a rod or anything. Just these 10 parameters describe everything that one needs to know about the mass distribution. And it has six degrees of freedom. As you may know, it can translate in three directions, and it can rotate around three axes. If I wanted to go one step further in realism, then there's the so-called soft body, where suddenly the complete details of the mass distribution and the stiffness distribution and the material that it's made of, this all start to matter. It also turns out to have infinitely many degrees of freedom. And if one wants to simulate something like this, then obviously one can't simulate infinitely many. So one breaks this down to some discretization, then it has finite, but still very many degrees of freedom. This is called the finite element method. This is used a lot in engineering, but hardly in games, because it's fairly time consuming. It's hard to do this in real time, although it's becoming possible. So this is our robot model. So you can see it consists of torso and two legs. And each leg has six degrees of freedom. There are three degrees of freedom. Can you see my mouse cursor? Yes, you can. There are three degrees of freedom in the hip, one in the knee, and two in the ankle. And these six degrees of freedom are sufficient to position the foot in any desired way. So we can actually move the foot in three directions and rotate it around three axes, subject of course to constraints with the leg length. So the leg can't overextend. But as long as the knee is bent, and we can position the feet in an arbitrary way. And this is going to be used by the controller a lot. So why is walking even a hard problem? On the left, you see an industrial robot. On the right, you see a biped robot. And actually for industrial robots, the problem of motion is mostly solved. But it's fairly easy to make an industrial robot track a given trajectory. Why can't we do the same thing in walking? And the answer is highlighted here. The industrial robot is actually bolted to the ground. And as you can see in the photo, it's attached to a fairly huge steel plate. And all this steel plate does are still prevented from falling over. The humanoid, on the other hand, can't do this. The feet can't lock to the ground. So essentially the industrial robot can follow any trajectory with unreasonable limits and doesn't really need to worry about reaction forces. On the other hand, for the biped, you can't control the internal joint degrees of freedom, but you can't control the reaction forces. And this makes the problem much more difficult because suddenly the intrinsic dynamics begin to matter. And it turns out that the joint space trajectories need to be controlled very carefully to achieve stable walking. Let's see this in a small demo. In the first demo, you're going to see I've cheated by assuming magnetic boots. So the boots can essentially lock to the ground. And then I can just track a trajectory like so. And as you can see, it looks fairly crude, but it works. Now the problem about this, if I switch on physical contact, the same demo, the same trajectories, but physical contact, and this happens. And it just falls over, and then the engine blows up. This demonstrates that contact is failing. And if you just try to design these trajectories by hand, you find that it's very difficult to do. So what we really need is a mathematical criterion that will tell us if the contact between foot and ground will hold if we need it to hold. Now contact turns out to be a fairly complicated microscopic phenomenon, but there is one thing that is fairly universally true, namely that contacts are usually non-sticky, which is a simple way of saying that the normal component of the contact force must be greater or equal in zero. And this is shown in the cartoon below. So if I place some object on the ground, then usually the contact force will just compensate the weight and it will just stay in rest. If I pull on it a little, then the contact force will just compensate the remaining force difference and it will stay in rest. But if I pull on it a lot, then the resulting force is suddenly non-zero and I can lift it up. And the same applies to the feet, obviously. If I have multiple contacts, I can define the so-called center of pressure where I take all the contact points and take the weighted average where I weight by the relative normal part of the respective contact force. Now, this would seem to be useless because it seems to depend on the microscopic details of contact. But it turns out that I can calculate the center of pressure from only knowing the total contact force and torque. So what I can now do as shown here is I take the, I assume that if the sense foot is to remain stationary, then the contact forces must compensate the reaction from the rest of the robot. On this, I can calculate the center of pressure and it must lie inside the foot rectangle. Also, the normal component of the total contact force must obviously be positive or zero. Turns out that this is only a necessary condition, but if I have Coulomb friction with mu equal infinity, which just means that it can't slip, it can only lift off, then it's a sufficient. And it turns out to be sufficient in practice, usually. Unless you're walking extremely fast. And now we can actually see mathematically why the demonstration failed. What you see here is the center of pressure calculated from the reaction force of the robot. And the dotted, the dashed lines show the limits of the foot. As you can see, the center of pressure moves far outside the foot rectangle. And therefore it fell over already here. So it fell over instantly, just as you saw in the demo. So the goal would be to get this inside the dashed lines. How can we do this? Well, it's clear that the control strategy needs to focus on contact forces. And one idea is that we got the center of pressure as given and designed the motion around this constraint. We found this in a PhD thesis from T. O. M. Unich. But it's possibly older, I don't know. So here's how this byte looked like. The blue line gives you the center of pressure, which is given. And then the green line shows the motion of the center of mass of the robot. They're just compatible with it. Now there's one obvious problem. And that just gives us a second order differential equation, but we have three boundary constraints. So initially the robot initially starts with a given position and a given velocity, but we also need to fix the end, at least the position at the end. What we need to do then is to modify the COP trajectory to fulfill all the boundary conditions. So basically if you parameterize a COP modification and choose this parameter, such that we can fulfill all three boundary conditions. And the problem is then of course, that the modification might violate the COP constraint because I can't control how large it will have to be. And all that this really means is that the controller doesn't know how to take side steps. Sometimes if you're pushed, you need to take a side step to recover balance and the controller can't do that. The controller only knows about fixed foot positions. Now there's one remaining problem. Emulated to swing leg can't move as the center of pressure would like it to move, but it must be moving in controlled way. And the solution is just to treat the reaction force from the swing leg as a disturbance and compensate for it. And then there's a technical problem that the inverse kinematics couples the two. So we need to do iterative solution. I can't go into details here. And the last step then, once we know the center of mass motion, so use inverse dynamics to just track the required contact forces and make the center of mass move in the desired way. Turns out that there are two cases. In one case, we have one leg on the ground, in which case we need to control the contact force plus the swing leg acceleration, which is given in global coordinates and the inverse dynamics takes care of that. Or if you have two legs on the ground, we can actually distribute the contact force between them and we need to control that. In each case, we have 12 equations and from this we can calculate 12 accelerations in joint space. Now let's see a few demos. The first demo is just walking on flat ground. And this is now with real physical contact. As you can see, it can walk. And it actually walks relatively fast. This is now a simulated speed of three kilometers per hour with a leg length of one meter, which is not human level, but still fairly decent. I will say later how this is limited. Yeah, it takes 60 centimeter steps and takes 700 milliseconds to do them. What we can also do is to just make the terrain slightly uneven and not tell the controller about it. It looks like this. It's where it copes. And if you look very, very closely, you can see that it doesn't actually expect the ground to be curved. And then only when the foot is on the ground, it pushes itself into position. But the controller can deal with this just fine. The controller assumes that the ground is still flat. And again, this is with physical contact and with some version of physics. Now, in the next step, we can also tell the controller about the terrain. So the controller knows how the terrain looks like and can place its feet accordingly and plan its motion around this. For this demo, we have reduced the step length to 40 centimeters, which reduces the speed to two kilometers per hour. But in return, we can deal with fairly uneven terrain. This works. Please, simulation. You might notice that it always places its foot on these rectangles and this is due to a weird bug in the physics engine that blows up if it steps on the edges. Don't exactly know why that happens. We're going to try bullet and see if that improves things. Yeah, and then the last demo, we can actually use the fact that we can place the feet in any way we want to climb stairs. And these are fairly normal stairs with 20 centimeter step height and 30 centimeter depth. And again, let's see this last demo. And we start with 50 centimeter steps. And then it climbs the stairs and also managed to go down again. You can see that the stairs hit its feet and the controller deals with that as well. So much for the demos. These are the curves that come out of the first walking demo. Basically, you'll see joint angles, joint velocities, joint torques and the power in the joints. If you can't read them, I'm going to summarize what you can see in these curves in just a minute. So let's summarize the first part. We have a control strategy based on contact force management. The good thing about it is that it seems to offer fairly reasonable performance. A thing about this is that the foot positions are fixed in advance, which is good because it can be used by a higher level controller, e.g. for climbing stairs, as you have just seen. It's also negative because it limits options for push recovery. So this controller cannot take side steps. Also, here's a problem that the leg length constraints are not taken into account. As you have seen, it moved in a fairly weird way and this is because the controller assumes that the leg, that it can always move the feet in all six positions. And once that constraints violated, the controller fails hard. And so this will also need to be fixed if you want to go faster. That's one, yeah, that's good. So basically, I told you about this physics engine. Well, if you have a general purpose physics engine like ODE, this does forward dynamics only. So your input torques, you get out joint angles. We also want to do the inverse problem called inverse dynamics, obviously. And if I wanted to do this as a general purpose physics engine in some way numerically, this would be highly inefficient. But we've done, we've implemented dynamics algorithms especially for our robot model. And then we can do all these things. We can do analytical inverse kinematics for our six degree of freedom legs. We can do forward dynamics. We can do inverse dynamics. We can also predict and manage the contact forces on the feet. This code is open source and it's going to be released really soon now, soon as I get to clean it up. Well, all these algorithms are described in the book shown here. It seems to be just standard reference on this kind of algorithm. A long-term prospect would be to move towards a large-scale non-linear optimization. This lets us use the still increasing computing power. And as I mentioned in the beginning, there are many interesting results from this, especially in computer animation. And it looks really impressive, far more impressive than the stuff we are able to do. But there are very few results that people are using this on physical robots. I don't really know why, but this seems to be heating up as well. So it seems to be that people are using these kinds of optimization-based approaches now on physical robots as well. So much for simulation. And now we try to move to reality and there's a whole bunch of problems that appear. First of all, we don't really know the dynamics parameters in a long game. In fact, the bodies aren't even rigid, particularly as you have to build a robot very lightweight. Also, our motors now have finite maximum torque, finite bandwidth, gears have backlash, there are external disturbances and so on. And really, the only way to find out how these affect us is to do experiments. Let's start with the actuation requirements. So these are basically the numbers you saw in the graphs before. You're going to need the torque of around 100 newton meters, the velocity of around 20 radians per second, and the power of about 250 watts per degree of freedom. Turns out that if you make the robot smaller, the torque requirements go down, obviously. At the moment, we're aiming for around 120 centimeters and 30 kilo, but this is very much subject to change. Now, if you try to use RC servos, they have about one newton meter. So these are the high power ones. This is way too low. So we can really forget about RC servos. But how about RC brushless motors? Like this one, for example. This is obviously intended to power like a car or a plane and not as a servo. Still, if you can combine this with a gear reduction ratio of about 1 to 50, then it would meet the requirements. Because the torque would then be on the order of 150 newton meters, and the velocity would also be somewhat OK. It also weighs half a kilo. So it seems reasonable to build a robot with it. Of course, we still have the gear and everything, but it might work. The problem is that standard RC brushless controllers are not really intended for servo applications at all. All they can do is to make the motor turn and possibly control the velocity. So we ended up developing our own Brushless DC controller. It has an encoder on the motor axis so that it knows exactly how the motor is turned. It does what is called space vector modulation. What we just mean is that it generates as we face AC current for the motor. And this face, this current is face locked to the motor rotation. And we communicate with it via eyes 485. For the power stage, we actually use the power stage from a 120 ampere Brushless DC controller because it seemed difficult to make it, actually, due to the magic of China. The cold controller costs less than the parts to make the power stage on our own. What we also need is current sensors. We use these very nice Hall effect-based sensors. Basically, the current goes through and the sensor measures the magnetic field, which means that they can go fairly high up to at least 100 amperes. This already kind of works. In this slide, I show you the controller being used for position control. The green line is the desired position. As you can see, it goes to the desired position and stays there with fairly little ripple. It's not ideal for various reasons, but it's quite OK. If it's going to be OK for the actual robot, it remains to be seen. But it's a start. Then we are also going to combine everything into this nice Brushless motor because this is an outrunner, which makes it difficult to mount. And also, of course, it's designed to sit in an airflow by a propeller or something, so we need fairly large amounts of cooling. This is the power stage. You may recognize it. And this is the encoder. This is also a Hall-based. So here's the magnet. And the encoder measures the magnetic field and can tell how the magnet rotates relative to the encoder. For the axis encoders, we also use Hall-based sensors from OCR microsystems, which are fairly nice devices. We have one absolute sensor, which gives us a 12-bit absolute position. And there's a relative sensor, which has 128 pole ring and interpolates between it. If we combine both, we get, in theory at least, a 17-bit absolute sensor for about $10 per chip and $5 per magnet. Of course, these 17 bits, these are precision, but these are accuracy, whatever. There's the problem with non-linearity. They are precise and not accurate or something like this. So yeah, I'm a bit confused about this time. Anyway, so the big problem is that this interpolation is obviously non-linear. So we don't really get 17 bits, but it's still very useful to measure velocities. One technical issue is that you can't control when this sensor samples, which makes velocity measurement difficult. There's a new version, and it hopefully fixes this kind of problem. Now, the big question at the moment is how to get the gears. So we're going to need some gears that can produce up to 100 newton meters with a reduction of 1 to 50 and transmit fairly large amounts of power, which rules out warm gears. So where do we have the big boys or use harmonic drives? The problem is that they're extremely expensive. Even if you source them from China, it costs about $1,000 each, which is way outside our budget. The other option is planetary gears. In theory, I mean, you could try to recover them from quadruple screwdrivers. They are going to be of fairly low quality, but they're also extremely cheap. If that works, it remains to be seen. But if it did work, we would have a fairly cheap option and probably get below $100 per degree of freedom. Yeah, to test this, we have a motor test bed with weight of a configurable up to 10 kilograms, which gives you a maximum static torque of 100 newton meters. This thing is one meter long, and you can attach various motors and see how they do. This motor turned out to be much too weak. Now the idea is this is a brushed motor. Now the idea is to attach the brushless DC motor to this gearbox, which will probably break the gearbox. And then we go on. Yeah, that's it. So the current status of the project is we are in a preparatory phase. We did some work on simulation. We studied existing designs. We are working at Dingfau Bay Cologne, the workshop there is now mostly set up. So we have a nice milling machine, a conventional milling machine, which manufactured most of the parts you saw. You have a small CNC lathe, and we have a fairly complete electronics lab. As I said, the biggest problem at the moment is the actuation concept, in particular the gears. Once we have solved that, we can decide on what size of robot to build, how to build it, and then eventually start the construction. So with this, thank you for your attention. And if you have further questions, you can either ask them now or ask me later, or go to this website, which is our blog on the project. Thank you. OK, so we're through this and have now quite some time for Q&A. So if there are any questions you'd like to ask, how are you sensing contact force? The idea is to use a load cell from a bathroom scale and have on the feed four sensors, which would allow us to sense the normal component plus the center of pressure, but not the tangential component. And the idea is that the tangential component doesn't matter so much because you don't know you precisely anyway. But this is not even a prototype of that yet. It's just an idea. Any more questions? You may also ask in German, of course I'm coming. Why are you starting or simulating such a big thing and not start way smaller? Well, for the simulation, it doesn't matter because I can't make the robot as big or as small as I want. I mean, the algorithms don't really change if I make the simulated robot smaller. Another question is why would one not build a 10 centimeter robot? And one possible answer to that is that if you make the robot very small, you can either make a toy with disproportionately large feet and basically preprogrammed trajectories, or if you want to make it dynamic, your servers need to be very fast. And then it, again, becomes difficult to find motors that can be as fast as you need. If you take a cat, for example, being the holy grail of dynamic movement, I guess, there are no servers that would make a leg on an artificial cat move in the way that a cat does. They're just not fast enough. And then you have exotic. Then you need to think about exotic motors and exotic gears again so that there is probably some golden ground where the torque is not too high and the velocity requirements are also not too high, and we're trying to find that. But for simulation, it doesn't matter, I guess. It can just make the motor stronger and not spend a penny on that. More questions? I see none. Oh, another one. Would it be an option to use pneumatic actuation rather than local motors? In theory, perhaps. Although I think that if one wanted to go that route, then hydraulics may be the better option. Hydraulics has the problem that you need the pump. Although it's difficult to control. So you need these linear valves. You can't just switch it on and off. And hydraulics, I think, is fairly difficult to control. Motors are more complicated from the gear side, but easier to control. Pneumatics would add the additional advantage and disadvantage that it's compliant, which is good because it's impact resistant and bad because it makes control even harder. Also, I think that pneumatic actuators of the required force would be fairly large or require extremely large pressure. Well, well above 10 bars because you can't attach them too far from the joint. And then 100 newton meters become one kilonewt roundabout. All right. So I see all questions answered. Then, Anna, again, please applause to Norbert for this great talk.