I am interested in biped locomotion since 14 years. After lots of physics, mechanics, internship in Delft Biorobotic Laboratory, listening courses about underactuated robotics and conception of my own biped robot, I made a first draft for a method to make a biped robot. I think it can be useful to sum up this method here. Poppy is the robot the most compatible with this method.
The aim of this method is different since the objective is to make the robot walk and then standstill (by absorption of mechanical energy). The method is divided in four parts:
understand limit cycle method and biped geometry
definition of necessary conditions to have a stable walk
tuning the 5 protections of the walking robot
exploring all the possible gaits inside the protections
1
The biped robot can be seen as a very heavy beam (the upper body) linked with two others light beams (legs) with a variable length (thanks to knees). During walking, one leg is on the ground (the stance leg) and the other is free (the swing leg). Even if this model seems simple, it helps to understand all physics here.
We can say a system is in a limit cycle when its behaviour has an event which is recurrent. All the angles, angle rates, lengths… named state of the system can be taken like a photo at this event. if X is the state of the system, we can measure this state when the event occurs X[n], X[n+1]… A limit cycle is said stable if after a while, X[n+1]=X[n].
For a biped robot, the event is the state just after heel strike. Imagine a camera which make a photo at each hell strike. If the photos are the same, the gait is stable.
So the question is what happens between two photos so that X[n+1] is different from X[n] and make the system unstable ? It depends on the physics of the system. For a biped robot, I think there are 5 physical phenomenons which lead to fall:
Falling forward stability : the swing leg of the robot is not fast enough to prevent falling forward
Stumble stability : the swing leg touches the ground when it goes forward
Falling backward stability : the upper body has not enough kinetic energy to go above the stance leg
Falling sideward stability : the lateral kinetic is too high to be damped by the heel strike
Twist stability : the swing leg gives an inertia moment on the stance foot. If the stance foot slides, the robot falls
The necessary conditions are the mechanical, electronic and software parameters to get the five index of stability
To be followed…
Very interesting topic, do you think you will able to make it work using simulator ?
While you have not access to a Poppy, we could iterate between your work on simulator and the real platform in our lab.
Yes indeed, the simulation is still a work in progress but you can start to use it (don’t hesitate if you have any question, there are still several problems).
@Matthieu : Before the simulator, I think the most difficult and the first think to do is to have the “perfect” foot to guarantee most of stability issues. I think contact between foot and ground should require a finite element simulator or “good idea simulator”. I think the fun is in the second since the cost is not so expensive. For simulation, I think the simple compass simulator is a good start to have the first ideas. That is why I made my own robot to go further.
Just for information, I edited the first post with a figure so that it is more… sexy.
Let’s go on with the main part of the method : a way to understand longitudinal biped walking.
Let’s make some simplifications:
upper body is only a point
mass of foot is very small with respect to upper body (agility condition)
Do not take into account lateral issues (for the moment)
The leg length can be variable but L1d is much lower than V=thetad*L1
Therefore, the swing leg can be neglected and the model is simplified:
The model becomes a “simple” inverted pendulum. To make a step you must be sure the mass passes above the foot. That is to say the upper body has enough kinetic energy to be transformed in potential energy.
Kinetic energy is
0.5M(L1*thetad)²
Potential energy is
MgL1(1-cos(theta))
The condition to pass above the foot is then the BIG EQUATION:
thetad>sqrt(2g(1-cos(theta)/L1)
A very good way to visualize such a dynamic system is to see the phase plane thetad=f(theta). If you want to know how to use phase plane, see the MIT course about underactuated robotics (by Russ Tedrake).
You can see this red limit is very important to take decisions before falling. The first decision to control the swing leg so that the robot does not fall. The fisrt approach is to say:
below the red limit, the swing leg shall stay backward (not enough energy to make another step)
above the red limit, the swing leg can go forward because the upper body will reach the pass
A first stability margin can be defined as the distance between robot state and the red limit.
Notice a number is important : sqrt(g/L) named the Froude number. If thetad reaches this value, the vertical acceleration of the upper body is +1g that is to say it compensates gravity… The robot flies (runs).
sqrt(2)*Froude number is the Thetad required to reach the pass is the robot is horizontal. (to make a back flip…)
This is a very analytic way to see dynamic walking but for control we can see the first necessary conditions:
upper body has to be largely heavier than the legs
swing leg tight actuator has to be as fast as possible
theta and thetad must be measured (which sensor? at which place?)
heelstrike must be detected to know which is the swing leg, which is the stance leg (which sensor?)
Control must be reactive control = f(theta,thetad) like a map (learning algorithm?)
stance foot shall be compliant
Now the stability is OK, I will talk about all the ways to give mechanical energy to the robot.
Another way the fall forward is that the swing leg hurts the ground during the stride. To avoid this, take care that L2 is lower than L1 when alpha is next to zero. (anti-stumble protection)
Applying the algorithm above will result in a robot which stops. It stops with the two feets on ground (with a final alpha value which is not always zero). If the robot is launched with an initial mechanical energy, this energy will be dissipated little by little. How? by friction in the actuator, aerodynamic force but mainly by impact. When the robot hurts the ground the kinetic energy of the foot gets instantaneously to zero (fortunately to avoid foot bounce). This heel strike is mainly the issue of the passive robots. Not predictable, produces sound, excites the flexible modes of the robot structure, fatigues the materials…
But this energy loss is largely below the actuator Joule effect (to be quantified…).
To compensate this energy loss there are several ways:
The swing leg can be thrown forward by the robot to cross the red limit.
The swing leg can push the gravity center when it is still on ground using the lever arm of the foot (named the “push-off”)
The stance leg length can be reduced to change the red limit slope
The foot of stance leg can produce a torque on the stance leg to control precisely theta when thetad is small or absorb kinetic energy
All these actions can be f(theta,thetad).
Here are the rules. The challenge is to find all this f(theta,thetad) to get the natural walking and to explore all the different gaits available (knocked gait, slippy gait, autoritary gait, backward gait, moonwalk gait, happy gait, sad gait, natural influence on arms…)
But before this, I will talk about the lateral issues which have unfortunately an influence on longitudinal design.
Yes I tried to implement but there are some limits. First of all, the main component is to have the orientation of the robot with respect to the gravity. To have this, the idea is to include a IMU. I tried to put an IMU (the RAZOR) on the pelvis of the robot and this sensor is very good but…
The second issue is the mechanical game. even if you have the pelvic orientation, due to the game, the relative position of the pelvis with respect to foot contact is not precise (there is a 10cm incertainty…)
The solution should be to cancel the mechanical game using a better mechanical structure (more expensive) but I am convinced we can do without this.
The solution is to add an IMU for each part of the robot. Doing this, you can compensate the game and improve the precision and above all know the relative position of the center of mass with respect to the ankle. (it is possible to make data fusion with position sensors of the servomotors)
The last thing I am looking for is time and money to test this solution
What do you think about this ? do you agree ? did you try or imagine other things ?
Well I have almost no idea how to go about achieving this. I discovered the concept of inverse kinetic yesterday and Poppy seems so fragile and flexible that this tach seems (to me) complicated.
Do you think it will be possible to get a “primitive” for the Poppy Humanoid walk?
If you have a primitive to copy a move, you can do it by imitation. But for now, there is no walking primitive where Poppy walks by himself… big subject
There is/was a you tube videos getting a robot to walk using standard hobby rc servos and plug n play gyros for hobby servos. If I remember correctly the walking gait was achieved using a triangular step pattern. Granted not fluid and completely humanesque but it was stable and worked as a base for +1 -1 AI algorithm inprovements. +1 = more efficient -1 =fall or less efficient. I believe 5 gyros were use one in the head 1 in each foot and 1 at each hip. I’ll check when I get home to see if I can find the videos and link. Pop star is all I can remember for the name of the robot off hand and something xrobot.com or .UK for the website
I’ve been having some success with the unity game engine for programming arduino based robotics. My poppy has been shelved due to personal time constraints but I have had decent results with other biped projects. It’s a fairly simple learning environment and whit the stl files available building a virtual poppy or other robot is fairly simple. The added bonus is you can add the electronics your using and at least for the arduino it writes the code for you once your happy with the simulations. I haven’t yet played with higher functions of algorithms and ai controls but this route seems to be fairly simple. I’m sure it will work with rpi derivitives and dynamixel servos and other various electronics. I’m enjoying just the “real world” simulation aspect of the game engine and “cheating” using pre-existing algorithm and code to see what my creations will do before I even build them.
I tried different methods to make Poppy walk, all based on reinforcement learning. It was a failure ! I am currently trying to adapt the deepmimic code on the Poppy robot. The principle is quite simple, instead of having unsupervised learning, deepmimic uses motion capture files to establish a policy. Learning therefore becomes supervised and easier. I’m currently stuck on Poppy skeleton compatibility. Mocap files usually have a skeleton with xyz joints, poppy does not.
Has anyone ever tried this type of method? Do you think it could work?
Hi @Yoann , just some questions, are you testing poppy walk on simulator or on real robot ? if on real robot, did you add some sensors (IMU and pressure sensor below the feet) or only an open loop control ?
just consider the real robot is tall and the game on each axis can give a big uncertainty of joint position. A parametric approach about walking with poppy is too much sensitive according to me.
Hi @Thot, I have not tested with a real robot. Can we qualify the uncertainty of the position of a motor? 1%, 5%? I tried different approaches, without success. The parameters given to the AI ​​are: the velocity, the torque and the position of each motor, as well as an acceleration sensor at the level of the torso. I also tried to add the contact of the foot to the ground. In simulation, the robot took 2 steps and then fell. The advantage of the deepmimic algorithm lies in the abstraction of the goal to be achieved. The fact that it is supervised makes it necessary to find a motor angle situation respecting the position of each member of the model at each instant in an environment. Another advantage of this type of algorithm is that it needs a limited number of parameters over time. I imagine that the transition from simulation to reality must be chaotic.
If you work only with simulation, it is OK you can get rid of motor uncertainty which cannot be quantified in percent. The error is function of the torque applied on the motor like a spring.
Considering the simulation, I think you have all the data necessary for learning.
If your robot falls during simulation, what kind of fall ?
forward fall (the foot cannot go forward to prevent falling
backward fall (the body has not enough energy to pass through the other leg)
side ward fall (the side energy is too high)
twist fall (the adherence of the foot on the ground is not well modelised, or the robot is too light)
I had some luck using a reverse kinematics on another biped robot I was working on. Unfortunately I didn’t write the coding myself. I also made use of a line of code that smoothed the transitions from one servo movement to the other which made a really big difference in the gate walking properly. Was able to get 4 steps prior to falling over due to final foot/center of gravity issues. I shelved my robotics projects when my coder went off to university. I’ll look through my files and see if I can find any notes on the kinematics equations and such. You may possibly find them with a Google search much faster. Again I’m using regular standard servos of approx kg/cm ratings and “hard coding” for movement choices. Preprogrammed gate etc.