Physical Robot Walk

Steven Jian (cs184-an) and Peter Lau (cs184-ao)

Overview:
-Physics Engine
-Physical Representation of Biped Walk
-Voxel representation of terrain
-Easy to create new worlds and robots

How to Run:
Run our Slide.exe and open robot.slf in the same folder
Note: if it crashes, try agian :( sorry.

Instructions:
W - Walk forward
S - Stop walking
A and D - Turning
Z, X, C, V, B, N - Different camera angles

Geometry

In this project, the main character, the robot, was made in Maya. We wrote a converter to convert from VRML (a Maya exported file) to SLF format. Each part of the robot was made seperately. Some pieces are mirrors of another piece (right arm, left arm, etc.) and we found that mirrored geometry flips the normals. So we wrote a converter that took the geometry we wanted to flip and flipped the order of verticies, which then flipped the normal back to the correct way again.

The world was made by hand in the SLF file. It could also be made in Maya, but we decided to create it by hand because the geometry is relatively simple.

Physics Engine

To define a "physical object" (something which is affected by the physics of the scene), there are a couple relatively simple steps to take. First, it must have PHYSICAL in its name. So, for an object named "arm" you would want to name it PHYSICALarm. An easy way to give an object such a name is to create a new group called PHYSCALwhatever and instance the geometry under it.

The second step is to put an entry in the "physical.txt" file. "physical.txt" holds all the relative physics data for each object. If an object is labeled PHYSICALsomething and does not have a corresponding entry, the program will fail. The format in the file is this:

PHYSICALname

mass = 10000
endPt1 = 0 0 0
endPt2 = 0 -.1 0
pinnedPoints = 0 -.1 0 [, 0 0 0...] done
[not]pinned =
pinnedTo = waist 1 [or: multi parent1 1 parent2 1] [or: space x y z]
lock[X/Y/Z] =
constrain[X/Y/Z] = 0 90

END

- mass: Defines the mass of the object. Not really based on any unit system, but changes to the mass will change how an object acts.
-endPt1: This is the initial axis of rotation. This is also where the object will be pinned to a pin constraint if it is pinned.
-endPt2: Basically Center Of Mass * 2. This is the "end" of the object, where collision calculations and rotational torques will be applied.
-pinnedPoints: This is a list of points that other objects can pin on to. You can specify any number of points and other objects reference them in the order they are listed here. The first number triple is index 1, the next is 2, etc. seperated by commas and ended with "done"
-[not]pinned: If its pinned, you need a pinnedTo entry. If not, it will fall and bounce.
-pinnedTo: If an object is pinned, it will need an entry here. The most common pin is to a single object where the format is: Objectname PinIndex (index is discussed above). If multiple parents are desired, the format is multi ObjectName1 PinIndex1 ObjectName2 PinIndex2 ... done . An object can also be pinned to space, in which case the syntax is space x y z
-lock[X/Y/Z]: Any entry of lockX, lockY, or lockZ will lock these axis of rotation completely.
-constrain[X/Y/Z]: Similar to above but allows minimum and maximum angles to be specified (relative to parent). Not recommened as it is not as robust as lock.

As you can see, most of the physics above are geared towards rotational physics. This is because we built our robot out of a collection of these physical items chained to eachother with constraints and such. With these physical objects you can create complex things such as a 12 piece whip of chained together blocks. Or a robot.

The order of declaring things in physical.txt is not important. But the order of declaring instances of your PHYSICAL object in the SLF file is. The parent must be instanced before the child. Besides that, there are no other restrictions.

From within the code, it is easy to apply forces, take them away, and do other physical related stuff to the objects.

Terrain Handling (voxel grid)

We wanted to create a terrain handling system that would be easy to use. Thus we decided to do as much processing on the program side as possible and not have the user do much work. So, to create terrain, a user simply has to declare an object with PHYSICALTERRAIN in its name. E.X. PHYSICALTERRAINfloor. A corresponding entry is required in the physical.txt file, but it can be left empty.

The program will take care of the rest of it. Upon running, the program will preprocess all the physical terrain objects into a voxel grid. This grid is of definable resolution and size, representing the world that the physics resides in. The higher the resolution, the more accurate the collision detection, but also, the more memory it will take.

To fill this 3d array, we combined ideas from the DDA pixel filling algorithm and the bilinear interpolation from Gourand shading. Each element of the array would represent a voxel in SLIDE's world space, which could be specified by a few parameters in the C code. To fill this array, we would bilinearly interpolate the variable which had the greatest amount of change to avoid having gaps in our voxel grid, similar to how the DDA algorithm calculates the variable which has a faster rate of change. However, due to time constraints, we were not able to implement forces into this voxel grid. If we did, we could represent some physical phenomenon – for example, wind would be a vector field occupying a certain space of this voxel grid.

The Robot

The robot we reconstructed from its parts in the SLF file and the physical.txt file. When a certain amount of parts with the correct names are defined, the robot is ready to be used.

It needs: larm, rarm, head, body, waist, luleg (left upper leg), ruleg, llleg (left lower leg), rlleg, lfank (left foot ankle), rfank, lftoes, rftoes, testPoint

All of these are physical parts of the robot except the last one. testPoint is where the robot looks ahead to determine how to lift his leg when walking. You can think of it as how far he's looking ahead. A relatively close testPoint is essential or else the robot will get confused. (raising leg high for stairs that are 10 steps away)

Walking the robot

When the robot is constructed as mentioned above, he will walk. Press W and he will walk forward. A and D turn him. S stops his walking. The robot will walk up anything that isn't too steep. So that means slopes, stairs, whatever. He uses the voxel grid to determine how high to step and to collision detect his feet.

The main goal of this project was to try and represent a bipedal walk with more physics than straightforward keyframing. In our case, our robot is made of a collection of connected physical objects. We manipulate him and simulate muscles by applying forces at various parts of the body. The walk itself is all event based. Something like "if my right leg hits the ground, raise my left leg and lean forward. Then if my left leg hits the ground, raise my right leg... etc.". This allows for a more flexible model to be walking around. Different behaviors can be chosen and easily applied on the fly.

For example, if this robot sees that the ground he's about to step on is higher than halfway up his lower leg, he will raise his leg higher when he steps, simulating humans when they raise their legs higher to take steps up and take relatively low steps for normal straight walking.

NOTE: for our robot, do not turn too hard while taking steps up multiple step heights. (i.e. 90 degree turn on one leg on the corner of one of our staircases). The robot is looking ahead and by turning so hard, he will expect a different height of land than there is and the robot will get confused (and possibly break :( ).

Our Terrain

For our example file, we first created four stairways that were sort of like that optical illusion where the stairs loop infinitely. But, we can't break the laws of space like that, so it rises to a point. Then we duplicated that square of stairs a few times to make a nice looking pattern. The general theme is metal and space.

Example found online of Escher perpetual stairs:

Camera

There are a few cameras in this scene. There are four attached to the robot: behind his head, in front of him, in his head, and to his right. There are also a couple birds-eye-view cameras.

Ease of Use

As far as creating things in this physics/robot engine, it is very simple. A user can create complex behaviors and linkages without ever touching code or math equations. He can also create a complex world and it will be interpreted into the scene without any extra work. What we are trying to stress here is that this is approaching the useability of an engine. The user simply defines things with properties and the program takes care of the rest. No preprogrammed paths with math equations etc required.

Creators: Peter, Steven