Locomotion Logic
My earlier gait analysis research has provided the basis for controlling the gait cycle, identifying gait phases which can be used to structure all necessary behaviour:- Initial contact
- Double support
- Rear foot lift
- Single support/Swing
A constant vertical raycast a fixed distance ahead of the biped is used define the target location for the limb in 'swing' phase. When the rear foot enters the ‘rear foot lift’ phase, the curve is plotted using the foot’s current position as the initial control point, and the vertical raycast hit position as the final control point. The inner control points have a default position, proportional to the positions of the start and end control points, though if the trajectory intersects with a non-walkable surface they will be raised and expanded proportionately to ensure the limb motion will avoid the obstacle and first contact will be made with the final control point location.
As the rear foot breaks contact with the ground and enters ‘swing phase’ the other limb enters ‘support phase’. The limb in swing phase will follow the plotted Bézier curve with the IK solution ensuring realistic bending of the knee joint. The limb in support phase will simulate the action of an inverted pendulum by rotating the hips over the contact point of the foot in the direction of travel, walking the system forward.
When the limb in ‘swing phase’ reaches the final Bézier control point it will collide with the ground object, enter ‘swing phase’ and rotate the hips about it in the direction of travel. This keeps the system continuously walking forward, with the logic checks maintaining the order of the gait phases by ensuring the limbs remain at opposite points to one another in the cycle.
These stages will be used to affect the walking locomotion, pivoting the hips with an inverted pendulum, positioning the curve control points to give a collision free foot trajectory and maintaining the leg behaviour with my IK solution.
More stable behaviour
Initially I relied on Unity’s collision system to detect the initial collision, maintained contact and separation of the limbs from the ground surface. This often proved unreliable as the rotation of the end effector caused premature separation from the ground surface, disrupting the logic of the gait phases cycle.A more reliable approach was to raycast downward (in world space) from the end effector so that no matter it’s rotation the ground surface below can be detected.
To debug my solution, I drew the raycast to the scene view. However, found that the drawn line would frequently not reflect the actual raycast hit detection (drawn line would still appear to be in contact with the ground, when the logic of the system showed it to have already transitioned through ‘rear foot lift’ and into ‘swing phase’, despite the drawn ray and raycast being the same length.
To force the drawn ray and raycast to be the same magnitude, I found normalising the direction vector then multiplying by a common value has proven to be realiable in the scene view window.
This change was the greatest help in building the logic cycle and debugging all unexpected behaviours.
After some further polish, the combination of all functionality developed up to the point in the project produced the behaviour shown in figure 1.
Figure 1: Procedural 2D biped locomotion, produced from combination of all project functionality developed to this point |
The horizontal yellow stripes have been added as a background to better define the motion of the biped hip joint.
Next Objectives
Now I have implemented a 2D procedural biped walk, I will begin solving the 3D problem with a more complex biped model. To do this I will need to create a heuristic iterative search solution, capable of correcting joint angle postures in longer chains, in 3D.Many of the lessons learnt from implementing the existing behaviour are directly applicable to an iterative search and I believe the experience of creating the 2D walker will be extremely beneficial.
All of the other behaviours used to create the locomotion will need to be adapted to function in 3D though I expect many of the principles and some functionality to be persistent in both environments.
As my earlier IK solution research has shown, Cyclic Coordinate Descent (CCD) is now the most appropriate IK solution to enable the locomotion behaviour needed. I will begin implementing my CCD solution next week.