We know that any robot configuration is described uniquely by a point in its configuration space, or C-space. One of the key ideas in motion planning is to represent any obstacle in the robot's environment as a set of points in C-space where the robot is in collision with the obstacle. So we should become comfortable with the idea of transforming a real-world obstacle into a C-space obstacle.

Let's use the 2R robot as an example. It's C-space is represented by a square in the plane, where one axis corresponds to theta_1 and the other axis corresponds to theta_2. As we saw in Chapter 2, the topology of the C-space is actually a torus, so when we represent it as a square, we have to remember that the top and bottom edges are connected to each other, and the left and right edges are connected to each other.

We can represent a specific configuration of the robot as a point in the C-space. Here, theta_1 and theta_2 are both close to zero, so the point is in the bottom-left corner of the C-space. If there is an obstacle in the environment, the obstacle can be represented in C-space by the set of robot configurations where the robot would collide with the obstacle. Even though this C-space obstacle looks like three separate regions, if we remember the topology of the C-space, we see that it is just a single connected region. We can add two more obstacles and get the final picture of the robot's C-space. An example configuration in collision with obstacle A is shown here. Theta_1 is 45 degrees and theta_2 is 315 degrees. Next we see an example configuration in collision with obstacle B, and finally a configuration in collision with obstacle C. If the robot also had joint limits for joint 2, preventing link 2 from rotating over link 1, we would get another obstacle, this one due to the joint limits. In the rest of this video, we will assume no joint limits.

Now that we've constructed our C-space and its C-obstacles, we can perform all motion planning in the C-space, so let's focus on that for a moment. Notice that if the robot were in a configuration in this red region, there would be no way for it to escape being stuck between obstacles B and C. It could only move between configurations in this region. We call this region a connected component of the free space, and we label this connected component 1. In this example, there are three connected components of free space; this region labeled 2 is connected because the top and bottom edges of the square are connected, and this region labeled 3 is connected because the left and right edges and top and bottom edges are connected. For a path to exist between two configurations, they must lie in the same connected component of free space.

Now we would like to find a path between this start configuration and this goal configuration. Both configurations are in the same connected component, so we know a solution exists.

Remembering that the left and right edges of the square are connected, let's animate a solution path in both the real space and the C-space.
Planning collision-free paths for other robots is conceptually the same as for the 2R robot: we transform obstacles to C-space obstacles, then we plan a path for a point in the free portion of C-space. It's impractical to explicitly construct C-space obstacles due to their geometric complexity, however, especially for higher-dimensional C-spaces. For this reason, most motion planners simply assume the existence of a collision-detection routine that can check whether a given configuration, or path segment, is in free space. One way to check if a particular configuration is in collision is by checking for intersection of any of the polygons that represent the surfaces of the robot and the obstacle.

An even simpler way to check for collision between two objects is to approximate each by a set of spheres. Here is a lamp approximately represented as the union of spheres. Checking whether two objects collide is then as simple as checking the distance between the centers of the spheres of the two objects, which can be done very quickly. The actual object should be strictly inside its sphere approximation, to make sure that we don't declare a particular configuration to be free when it is actually in collision. If we use more spheres, we can represent the objects more precisely, as shown here. This makes collision detection less conservative, but increases the number of distance checks.