SIMULATION OF A BIPED
Eakta Jain and Mark Desnoyer
This projects simulates the planar walker shown in Figure 1, whose parameters are specified in Table 1.
Figure 1: A model of the walker we are simulating with
heights listed from the ankle. Note that it Is a planar walker so that the two legs are actually
coincident.
|
Link |
Mass (kg) |
Moment of Inertia (kg m^2) |
|
Calf |
6.8952 |
0.1535 |
|
Thigh |
5.676 |
0.09592 |
|
Torso |
50 |
1.5 |
Table 1: Dynamic parameters of the
simulated walker
Our
actual simulation is performed using ODE. In ODE, we create a separate body for
each of the calves, thighs and torso. Then, we attach adjacent bodies using the
built-in hinge joints. This creates a total of 6 different joints. For
collision detection, with the ground, we use ODE’s
built-in collision detection facilities and create contact joints when a body
hits the ground. To simplify the problem, we set the contact friction to be
infinite. To actuate the model, we apply torques at each of the joints
separately. The ankle torques are limited to +-74N,
but we did not limit the torques on the other joints because it would be
superfluous as any applied torque will get transfered
down to the ankle on the ground anyway.
Dynamics of the
system
Goal: In order to
design an LQR controller, we need to find the matrix K such that 
where x is the state of the system and u is the control signal.
The state of the system is described by the joint angles of the ankle, knee and hip for the left side and the right side of the body. The control signal comprises the control torques at the six joints. We assume that the left side of the body is identical to, and independent of the right side of the body.
Pipeline:
Dynamics of the system → Linearize
these to get 
→ Use A and B to get the K matrix
The first two parts were done using Mathematica and the third part was done using Matlab.
The Mathematica files are attached here.
Deriving the dynamics
equations:
The basic idea behind deriving the dynamics equations is as follows:
We can write equations of the form 
for each link of the system. (We separate the biped into two
identical three-link systems, each consisting of an ankle, a knee and a hip.
The torso is effectively divided into half.)
Mathematica issues: For some
reason, the numeric coefficients were all complex. We could remove the ones
that were effectively zero , that is 
by using Simplify, however the same strategy did not work for
complex coefficients that had a non-zero real part. As a result, our equations were very daunting to look at.
The matrix A can be found by taking the derivative of the coefficients of the accelerations (that is, elements of the matrix M) with respect to each state variable.
The matrix B can be found by taking the derivative with respect to the control variables, of the product of the inverse of M with the matrix that made up the coriolis and gravity terms.
Since we assumed that the left and right sides of the body were identical, we repeated the entries for the second side of the body by copying values at appropriate positions in the array. We then evaluated the A and B matrices with the numeric values given to us.
Getting the K matrix:
We used Matlab functions to get the K matrix once we had evaluated the A and B matrices. The command c2d was used to convert the continuous dynamics to discrete system dynamics and the command dlqr was then used to obtain the K matrix.
Overview of the
system
The key block in this flowchart is the ‘Get torques’ block. It is here that we implement a variety of controllers and experiment with them.
(i)
Standing
To design a standing controller, we used four
different approaches:
Analytical LQR Controller
We used Mathematica to derive the K matrix for the LQR controller. The details are given above, but the resulting controller was not able to cause the biped to remain standing even with the smallest of disturbances. Looking at the resulting K matrix, the gains were significantly smaller compared to those we manually chose in the PD controller. This indicates that our analysis was probably inconsistent with our actual simulation. In particular, our analysis assumes that the left and right sides of the biped do not affect each other. Also, the analytical kinematics will be slightly different compared to ODE because ODE is a more complex model, especially when dealing with ground forces and whether a foot is touching the ground.
Genetic Algorithm Designed LQR Controller
Since our analytical model did not work as expected, we tried running a genetic algorithm to determine the values of the K matrix. The K matrix was vectorized to create a 6x12=72 element genome. Our fitness function was evaluated at the end of a simulation and was equal to:
Where:
t = time that the biped remained standing
p = position
v = velocity
The genetic algorithm was run with an initial population of 1000 genomes and allowed to evolve for 200 generations. Unfortunately, the resulting K matrix was not able to keep the biped standing, most likely because the search space in this formulation was too large.
Manually Designed PD Controller
We also used a PD controller on the angular displacement of each joint, which, for the standing biped, had a target angle of 90 degrees for the ankles and 0 degrees for the other joints. Through some trial and error, we found a successful controller by setting the gains for every joint with Kp = 1000 and Kc = 100.
The resulting system can take an impulse of up to 20,000N for 1ms without falling, however, its settling time is very large. This was our most successful controller, however, it is not ideal because it is a purely local controller that doesn’t consider the coupling between links.
Genetic Algorithm Designed PD Controller
To see if would could find a better solution for the PD control, we applied the same genetic algorithm as for the LQR controller to determine our PD gains. The gains were encoded as a sequence of 6 floating point numbers defining the Kp and Kd gains for each of the ankle, knee and hip joints. The same gains were used for each of the legs.
The genetic algorithm was successful in finding a controller that could handle a significant disturbance, however, it was not as efficient as the manually designed solution because the applied torques were much higher. This is most likely due to our fitness function, which doesn’t take into account the magnitude of the forces applied.
(ii) Walking
To come up with a good walking controller, we added some extra complexity to the control space by allowing cycling between many different low level controllers. This is inspired by the fact that a gait will have distinct stages in its cycle and no single linear or PD controller will be able to express those stages. This controller switch is shown in the block diagram as the “Change Controller?” and can be triggered by either an amount of time elapsing, or a foot hitting the ground.
In this new control space, we tried three different approaches to design a walking controller.:
Genetic Algorithm Designed Linear Controller
We tried to use a genetic algorithm to find a three-stage linear controller where the torques at any given time is described as:
In the genome, we encoded three different K matrices along with the times to transfer to the next control stage. This results in a genome that is over 200 elements long, so, unsurprisingly, this approach did not find a controller that could even take a single step. In fact, the best controller found only used a single K matrix to start a step and then promptly fell over.
Our fitness function was:
d = Distance traveled at the end of the simulation
stepCount = Number of steps taken
p = Position
omega = angular velocity
Genetic Algorithm Designed PD Controller
We
also tried to design a controller by using a genetic algorithm to find a three
stage PD controller. The genome was encoded with three sets of gains, target
angular positions and the time until the next transition. The gains can be
expressed as trying to find A and B such that
.
We used the same fitness function as we did for the linear controller. This controller was a little more successful, but it was still not able to take more than one step. The best solution is shown in the flipper.avi movie. Note that for this movie, the ankle torques are not limited.
This approach was unsuccessful primarily because setting an instantaneous target state for a PD controller, tends, at the very best, to create a very oscillatory system, and at the worst an unstable system. This makes it very difficult to design a controller that can smoothly walk the biped.
Manually Designed PD Controller With Trajectories
After abandoning the GA approach in favor of a more manual solution, we tried to develop a PD controller by setting the target locations and gains manually. However, this was almost impossible until we adapted the controller to move the target locations along a trajectory. For simplicity, we used a linear trajectory between the current position and the new desired position over some manually defined time period. This caused the walker’s motions to become much more stable and smooth.
After a significant amount of trial and error, we developed a series of trajectories that allows the biped to walk 10 steps and stop. This is shown in the walker.avi video. The basic approach was to cause the walker to balance on one leg while lifting the other. Then, the walker would fall onto its outstretched leg. Once on the other leg, it would bring forward its rear leg and come to an equilibrium balance before taking another step.
In theory, using this method, it should have been possible to define exactly one step. However, our standing PD controller found earlier oscillates so much that the walker cannot come to a perfect stop after each step. This meant that for every step, we had to manually tweak some parameters to achieve the next step.
Appendix
Videos: standing.avi is the manually designed standing controller, walking.avi is the manually designed walker, flipper.avi is the best solution that the genetic algorithm came up with.
Our thanks to Pyry, Garratt and Andrew for Mathematica tips, tricks and the crucial book chapter.