Motion Planning for Physically-based Deformable Objects



Introduction and Motivation

Motion planning has become an important tool in many applications; including problems such as character animation and even more computational biochemistry problems. Much of the motion planning algorithms up to this point rely mainly on geometric techniques. In general, they work by breaking down the space of all possible configurations and then finding a way to navigate between them. In the case of rigid and articulated bodies, this space is finite but can be extremely large. For example, a protein can have several hundred degrees of freedom, each of which greatly increase the complexity. Therefore, trying to breakdown this space becomes a very problematic task. In the case of deformable objects, the configuation space can be infinitely large, making these methods very difficult. Some work has been done (and will be described in the previous works section) that reduces this space into a finite one by adding some constraints to the object. But, this does not always lead to the best and most physically accurate results. We propose a solution to this which places a simulation framework on top of the planner. The simulation takes care of the deformations of the object in a physically realistic way, which allows the planner to be very simple and thus very quick.

Previous work

A great deal of work has been done in regards to modeling of deformable objects that have physically-based characteristics. For instance, S. Gibson and B. Mirtich (1997) give a good overview of modelling deformable objects with physically-based constraints. With respect to this project, we currently use a simple spring-mass system but have set it up in such a way that any type of deformable object will fit nicely into the planning framework. For other ideas, we considered some work done by Y. Zhuang and J. Canny (2000) and S. Capell et al (2002).

Motion planning for this type of model has been proposed by a couple of groups. Bayazit et al (2002) give a Probabilistic Roadmap Method for general deformable objects. It essentially computes a roadmap weighted by obstacle clearance and then moves the object in this direction. However, partly for computational reasons, this paper uses only geometric deformations. Other PRM-based papers, such as  E. Anshelevich et al (2000) impose constraints on the types of deformations which reduces the complexity of the problem. While this does provide for a good planner, it does not work on general deformable objects. We hope to expand upon each of these, by having a planner that is quick and works for general deformable objects. We've also looked into using RRT-based methods (based on S. LaValle (1998)). This looks like a very promising approach since it takes the ways the object can move into consideration and seems pretty simple to implement especially with the solvers already implemented for the deformable object. We've also considered various geometric solvers such as a Voronoi or Medial-Axis solver (M. Garber and M. Lin (2002) and S. Wilmarth et al (1999), respectively). But, due to it's simplicity, We've decided to use a PRM-based method for now.

Details for this work

- Physically-based Deformable Object

For this project, we use a simple phsyically based spring-mass system for the simulator. In particular, it is based on a "Pressure Soft-Body" (M. Matyka et al (2003)) with some slight changes to accomodate our problem and to add some functionality to it. This body simulates a soft deformable object with an internal pressure, governed by the ideal gas law. For a quick overview, the force due to pressure on a surface is defined as Fp = P*Area*nhat, where Area is the area of the surface and nhat is the normal for that surface.  We determine P through the ideal gas law, or PV = nRT, where P is the pressure, V is the volume, n is the number of moles of the gas, R is a constant, and T is the temperature in Kelvins of the gas. Since we wish to apply this to a spring-mass system, we must find the force due to pressure at each mass in the system. Since pressure is applied in a direction normal to the surface, we average the forces for each adjacent face to each spring and add the force accordinly. We do this as follows:

1. Find the volume of the object
    - For sake of simplicity, we currently find the volume of the bounding ellipsoid for the object. For works well for more sphereical objects, but not great for others. A much more accurate solution would be to use Green's Theorem to determine the volume, since we're assuming it's a closed surface (or else in reality the pressure wouldn't stay in the object anyway!).

2. Compute the pressure, P= (nRT)/V

3. For each face
       3.1 Find the outward facing face normal, n
           - This can be done as a simple cross product between two edges of the triangle and checking if it faces toward or away from the center of the object. We have set up our files such that all triangles are given in a counter-clockwise manner, allowing us to easily compute outward facing normals without the direction check.
       3.2.Find the area of the triangle, Area
            - Since we have the position of each of the vertices (from each mass), compute the area of the triangle. It is important to note that it is very possible to have long, needle-like triangles at some point in the simulation. Therefore, simply using Heron's formula for area computation may not always work. We have implemented a stable version of Heron's formula to take care of this.
       3.3 Compute the pressure force based on P, n, and Area.
       3.4 For each vertex of the triangle, add the pressure force to the forces for the associated mass scaled by the number of faces incident to that vertex.
             - Note it is pretty simple to precompute and store the number of faces incident to each vertex, as we can assume the geometry of the input object will not change during simulation.

This can be placed in the "accumulate forces" phase of the simulation. Matyka proposed only checking bounding volumes for collision determination, but we felt this would not be sufficient for our purposes. We used a more exact collision detection scheme instead of basing it on bounding volumes and have started adding an edge-edge collision detection scheme. This should help the object respond better to being stretched out in regards to how it reacts to the other objects in the scene. These features do slow down the simulation during collisions, but not significantly.

Object Results:

Here are some screen shots of the object in motion

This is an image of the deformable object with low internal pressure. Note that because of the insufficient pressure, the surface is slightly compressing in on itself.
In contrast to the last image, this object has very high internal pressure. It is pushing the sides out greatly.

This shows the object in collision with the plane at the bottom.



Analysis

This test was run on a laptop with a 1.5GHz Intel Pentium-M processor with 512 MB of main memory and a 64-MB ATI Radeon Mobility.

A note about the speed: During the presentation, I incorrectly stated some information about timings. The timings I mentioned for larger spring-mass systems were for rendering speed only while the simulation was not running. It was the speed at which my computer could grab all the position data from the deformable object and display it. The timings below are the average framerate while the simulation is running





From these graphs, we can see there is a point where the frame rate starts to suffer greatly. This could due to the overhead necessary to look up data in a vector as opposed to a direct lookup from an array, but also probaly has to do with the great number of springs in the larger models. In the smaller numbers, the overhead for rendering is probably than for simulation where in the great numbers, the simulation requires much more time than rendering. Much of the rendering code and data structures are not optimized at this point in time. To check this point, I ran a test to check how much time is spent rendering and how much time is spent in the simulation phase.





As confirmed by this data, as the number of faces increased, the time spent in computing the next smulation step greatly increased. But, at the same time, even though display time increased, it did so at a much slower rate than the time for a single step.

- Point-robot Probabilistic Roadmap (PRM)

We implemented a simple point-based PRM for the planner portion of the project. Our implemention creates a simple roadmap in 3D. Like the earlier PRM algorithms, it ensures during the roadmap creation stage that every link and milestone is in a valid position. Other algorithms, such as the Lazy PRM, do not ensure this property. They allow all links to be valid for quicker roadmap generation and then prune away invalid links during the query stage to get the path. By ensuring that our milestones and links are valid, our query stage primarily reduces to a simply connecting the start and stop positions to the roadmap and performing a graph search from the start to the stop positions. We have implemented Dijkstra's shortest path algorithm to find the path in our roadmap.

Results:

Here are a couple screen shots from trials of the path planning algorithm.

In search of a path in a roadmap. The green spheres are milestones and the lines represent links that connect milestones.

Horray! We find a path in all that jumble.



- Path Following

One of the challenges in this project was to find a good way to have the object follow the path found by the planne. More specifically, we need a way to move the object along each segment of the path in order in a way that keeps the object from straying too far from the path. We tested a couple of different options.

- Object Dragging

       We select a single mass on the objects surface and drag it along the path. Since the object is deformable, it deforms by stretching and is pulled by that mass.

       Pros: This ensures that the object follows the correct path and has the added advantage that it will work regardless of outside forces, assuming that the system remains stable and the bodies material properties are sufficently strong.
       Cons: The stretching is a down side to this approach. To ensure that the bulk of the object is not stuck too far behind the object, we must have sufficiently strong spring constants and pressure forces. These high forces will result in the stiffness problem and the resulting system is less likely to be stable. The other solution is to move the mass a lot slower but this too is undesireable is it could end up taking a very long time to reach the goal.

- Soft Constraint-like force

       We create a soft constraint type of force for each segment of the path. This tries to correct the position of the particles to be somewhat near the path. A similar kind of constraint tries to move the object to the next milestone.
 
       Pros: This does not require any kind of pulling of a single mass, so the object does not greatly stretch at any time.
       Cons: Using this method, the path the object actually follows tended to drift and oscillate around the specified path. At times the object got pretty far from the path before being pulled back. A stronger constraint may be better suited to this application, but this may be hard to find since the constraint must take possible deformations into consideration.

- Attraction

      We simulate the path as a sequence of attractors. The attractor has a fixed attraction force that pulls the object toward that node. As the object gets within some radius of a milestone, the next milestone activates and starts pulling the object to it.

      Pros: Like the previous, this did not require any type of pulling or dragging. And, it benefits from not oscillating around the path, but instead finds a pretty smooth path between the nodes.
      Cons: The main limitation of this technique is setting the magnitude of the attraction force. Lower forces help the object stay closer to the path, but at the same time are very slow and are susceptible to a local minima type problem if many external forces are in the scene. Higher forces move the object significantly far off the path and cause a spiraling effect around the attractor until it is sufficently close. And, when the object completely encompasses an attractor, the effect is a slight implosion of the object.

Other path options are available and it would be a good idea to explore these some more as they could be important especially for moving the object between more complex start and stop configurations. One option may be a more intelligent hybrid between the latter two options. The attraction would help keep the path smooth and move the object toward the goal and the constraint-like force could pull it back toward the path for higher attraction. In addition, the attractor itself could be implemented to change its attraction force based upon quantities such as distance from previous node, the object's distance from the attractor, or the objects current velocity. The last option may be a way to avoid local minima or help the object push or pull through difficult spaces.

Results:

Here are a couple of screen shots from various path following trials.

This image shows the concept of dragging. The green sphere is dragging the rest of the deformable object behind it. Note that the object is getting stretched out, and that close to the green sphere a couple of springs are getting stretched too much.

This image shows the attraction type force. Note that the object kind of compressed at this joint because the attractor is inside the object.



- PRM for Deformables

By allowing a simulator handle geometry and deformations, we can greatly simplify the work done by the planner. For instance, we can reduce the planning problem to that of moving a point from start to stop and allow the simulator to respond to any collisions along the way. Or, if we wish to not allow collisions, we only need to have the obstacles generate from repulsion force. Although the latter sounds a lot like potential field planners, it is slightly different in that by making a good choice for path following, we will not end up in a local minima prior to reaching the endpoint. Also, for sake of speed, we have attached a uniform grid to the environment to help prune which obstacles should be checked. A more complete solution would bin not only the objects and milestones, but also the invididual triangles of obstacles.

 In general, our algorithm is fairly similar to that of Bayazit et al. We combine all of the previous details into one algorithm. Given an environment with obstacles, a deformable object with various constraints, and a start and stop position, we do the following.

Preprocessing stage:
    Given a set of fixed obstacles and a bounding box for the environment, we build the roadmap as follows. For a set number of iterations, pick a random position, p, within the problem instance. Find the k nearest milestones to p. For each of the k nearest neighbors, determine if there is a straight line path from between p and that milestone. The point-robot PRM handles all of this in our final version.

Query stage:
    Once we have enough milestones, determine if there is a path from the start to the stop position. If not, we need to add more milestones to the roadmap. Again, the path finding is done by the PRM an dis based on Dijkstra's shortest path algorithm. Once we have the path, we setup the simulation to use this path in one of the manners described above. As the deformable object traverses the path, we check the state of the deformable object in the simulation to ensure that none of the material constraints have been broken. If any material constraint has, we remove the segment which broke the constraint and have the robot return to its last valid milestone. From here, we recompute the path to the stop from this point. If no path is found, it is reported and the user can either add more milestones or conclude that there is no safe path. Otherwise, we end the simulation when it is reported that the object is sufficiently close to the object (This could be defined as any part of the object reaches the stop position or the center of mass is sufficently close to the milestone, or any number of other ending conditions).

Note: In the currently available implementation, no material constraints have been added to the object. Therefore, no links are removed. However, this will be a feature in the very near future once a few other issues are worked out.

Results:

Just a couple of screen shots:

This is a close up of the deformable object prior to starting the simulation. The large yellow sphere is a point on a valid path from start to finish.

In order to test an application of PRM for deformables, we placed our object in an space a rigid body would not fit. This deformable has a rest that is greater than the distance between the planes. Therefore, it had to fill out a little bit on the sides to accomdate the model.



- Overall conclusions

By breaking the problem into these segments, this framework allows the path planner to be a mostly seperate entity from the object. Therefore, it would be easy to swap in other types of planners and deformable objects. This holds true as long as the deformable object does not have differential constraints, as PRMs are not good at handling them. But, one could easily replace the PRM by an RRT planner which will take care of this. Aside from that, this planner does a good job at moving the object from a start to end position and provides a foundation for improvement.

The current choice of deformable object seems promising for now. It runs pretty quickly and looks decently realistic. Most important, it reacts to external forces in a realistic manner and the physics governing it work in a well-defined way. This allows the addition of many other forces in an easy and well defined fashion.

The runtime complexity of this is largely dictated by the query stage of the planning algorithm. In this stage, almost all the work we do is in the simulation. Therefore, the speed of the simulation is essentially the speed of the algorithm.

A handful of things need to be noted that did not work too well with this system. First off, trying to determine the best parameters for the simulation was an almost painful task. As far as realism goes, the object benefits greatly from higher pressure settings and higher spring coeffients. However, at the same time, the higher we set these the more likely the system will get to an unstable state. Trying to find a good combination of these with a sufficiently large timestep so that the simulation was encredibly slow was not always a simple thing. With the current type of deformable object, we are not able to represent complex objects, particularly those with sharp features. One can solve this problem by adding various angular springs or additional constraints, but each of these will increase the computational complexity of the system. Also, many of the other existing planners make the beginning and final state of the object a parameter in the simulation, including it's orientation. Our planner currently does not do this. But, it may be a possible addition if we define our path traversing to include certain constraints which for the object into that final position. And, it currently only works for static scenes with non-deforming obstacles. But again, dynamic scenes could be accomplished if the roadmap is dense enough to find a good path through with possibly quickly changing connectivity and deforming obstacles could also be added.

- Contributions

This framework allows for motion planning of a generic physically-based deformable object. It also allows the easy addition of other types of planners and objects. In the introduction of a simulation of a deformable object into the planning algorithm may be a valuable method as much research has been done in this field.

- Future work

There are many things that can be done to improve this. From a standpoint of the code given below, many optimizations can be made, especially in regards to performing link queries. Aside from this, qiucker collision detection would be a great benefit and better collision response techniques would also be helpful. As I mentioned earlier, the volume computation is non-exact and would not work well for non-convex objects. So, a better and more exact method would be benefical as well. The addition of angular springs could allow for objects of greatly complexity to be represented. If we stray away from our deformable object, better and more realistic models can be put in its place. Similarly, either better variations of PRMs or other path planners may be very useful. In particular RRTs seem like a good fit since they also allow differential constraints for planning and use an ODE solver much like our simulation does. Some path smoothing will help make the paths be nicer as well. And, with the recent improvements in video card technology, it would be interesting to see if this be done on GPU.

A project presentation can be found here.

The source code can be obtained here.

Here is a small organizational chart. It shows the parimly relationships between the most important components of the system. In many cases, other dependencies do exist but this should be the minimum. Most of the code is self explanatory, and the more complex sections should have comments explaining what to do. The demo files are all based on a demo1.cpp. They are all variants of that file. So, to create new situations, it only invovles making changes to the setup and rendering routines. But, more control can be added by changing the rest of it.

Note: A lot of the code can be better written in many ways. This version was just the simplest at the time without much additional overhead. In addition, right now all the files which run a different demo are built under the same visual studio solution. Therefore, to run a different demo either copy the one you want into the project or comment out the other ones.