Richard Kelley Motion Planning on a GPU

Last Time Nvidia’s white paper Productive discussion

Today An application in geometric/physical computing Motion Planning But really, we’re going to talk about the components of the system Probably more useful this way. In particular, the random sampling part. Because it’s easier and more widely applicable. Because of time constraints. We’ll also look at the paper’s results.

Some Motivation: Motion Planning

Motion Planning Goal Move a rigid body from point A to point B. Assumptions In continuous space (otherwise it’s just graph theory) Though it eventually becomes graph theory. In the “real” world – robots, obstacles, physics, etc. Controllable objects may have to follow constraints. Typically this stuff is studied in simulation. Typically, we use mathematical tricks to reduce the problem to finding a path between points in some topological space.

Types of Planning Discrete planning This is the graph theory Single query You have a start state and a goal state in some space. Find a path. Multiple query You have a space. Find a path between several pairs of start and end states over time. Optimization variants Do the above, but with a twist Minimize energy, minimize time of travel, maximize coverage of the space, etc.

Sampling-Based Planning Even “simple” robots result in complicated spaces Humanoids are the worst – 25+ dimensional spaces on the lower end. To find paths in these spaces, we use sampling, typically random. Build graphs by Sampling a point in the space Making sure it isn’t in collision. Connecting it to other points that are “nearby.” Then we can query the graph to get paths between points.

Sampling Based Planning: PRM

The Paper Implements sampling-based planning (PRM) on a GPU. Not very helpful Unless you’ve read their other papers and are comfortable with motion planning basics. Several helpful GPU algorithms PRNG Collision Testing kNN Lazy-evaluation parallel graph search

For Completeness…

Random Number Generators Don’t typically parallelize well. So we use a cryptographic hash functions. In particular, MD5… Operates on 128-bit state, broken into 32-bit words A, B, C, D. Message is processed in 512 bit blocks at a time. Each round is composed of 16 operations based on a nonlinear function, modular addition, and rotation. Lots of “magic” numbers.

MD5

Goal: Avalanche Effect Small changes in input lead to large changes in output. Result looks “random.”

Avalanche Effect

MD5 for PRNG The paper, by Stanley Tzeng and Li-Yi Wei Parallel White Noise Generation on a GPU via Cryptographic Hash

The Idea Take some input data Compute the cryptographic hash of the input. Exploit the “randomness” properties of the result of the hash. But there’s a lot of “cheating” in the paper. This may be exceptionally bad…

For Example

Collision Testing Basic Idea: Each thread handles its own collision. Some ideas for parallel generation of boundary-volume hierarchies.

Nearest Neighbors Given a (typically finite) metric space and a point in that space. Goal: find the k nearest points in the space.

Nearest Neighbors

Parallelizable via… Clever hashing tricks. In one of the referenced papers.

Results: The Problems

Results: Data (vs. Kostas’s System)

Questions from the Field What about higher-dimensional spaces? Paper only talks about 3- and 6-DOF systems. (Question I always ask) What about real robots? What about dynamic environments? What about non-holonomic systems? Cars, planes, boats, etc. These are all opportunities for future research. Probably a lot of low-hanging fruit…

Questions from “the Rest of the World” Can I use this? Kinda a “is motion planning useful?” question. Answer is probably yes. What about this randomness stuff? Does it really work? How will it work for application X? Probably a lot of room for future research… What about the geometry? Probably useful, but you won’t get anything from this paper…

Questions?