The two robots can now avoid one another at real-time using the code from this update. There were many changes to the packages.

Trajectory Generation:
The goal orientation of a segment is only considered for the last segment of a trajectory. Prior to the last segment, we do not rotate the robot to satisfy the goal orientation of a segment because we gain nothing from it currently. This may be added in the future if there are advantages to satisfying the goal orientation of each segment (may be useful with mobile manipulator).
Some basic geometrical methods were added to the Utility class, such as displaceAngle, findAngleFromAToB, and findDistancebetweenAngles. The methods are all similar, but each is slightly different. They help solve all the geometrical issues when finding the angle the robot must be oriented at to drive to the goal locations. For instance, the findDistanceBetweenAngles method will consider that adding or subtracting two angles may be result in orientations that do not lie in the [-PI, PI] range.
If a trajectory has the same start and goal, a trajectory of 1 point will be returned, rather than a blank trajectory.

Sensing
The object_list topic now contains Obstacle messages rather than ObstacleLists. Sending a vector of size 1 each time was more than necessary. So it was changed to an Obstacle message. In the future when we implement multiple obstacles, this will be changed back.
The sensing messages were being published too quickly to the object list topic. In the evaluation package, the odometry messages from the Obstacle msgs contained the same values. So the velocity was always predicted to be zero, which led to the evaluation package not predicting the obstacle trajectories accurately. The rate at which these messages are published was reduced from 100Hz to 10Hz.

Evaluation
Feasible and Infeasible trajectories are now evaluated differently. Infeasible trajectories are given a penalty for being infeasible. The penalty is 10,000 / Time_until_first_collision. This ensures that 1) infeasible trajectories will always be worse than feasible ones and 2) that infeasible trajectories that have collision earlier than other infeasible trajectories will be less fit than their peers.
Localizing the robots was a big problem. It wasn't being done at all. For the obstacle robot, we receive the positions relative to where the robots begin. So we can assign a frame to that configuration and transform the odometry positions to world coordinates. For the "active" robot (the one that is planning), we receive the positions in world coordinates so no transformation is necessary.
The collision detection is done with circle intersection. The robot's reference point is the left wheel. The center is 0.1524m less than the reference point in both the x and y directions. For the obstacle robot, we obtain the center by subtracting 0.1524 from the x,y location before transforming the position into world coordinates. For the active robot, we take the x,y location and add rcos( -3PI/4 + orientation ) for the x value and sin for the y.
The predicted trajectories for the obstacles are now obtained through querying the trajectory_generator package. The Collision Detection class was given a trajectory_request_handler member and moved outside of the Evaluate class.

Planner
The Configuration class has been adjusted to "add" a configuration to another. This is actually not fully complete. It works, but the method names need to be changed and documented better.
The population size was increased to 10. This was changed because it seemed like the whole population was converging towards a path and could not produce any feasible trajectory.

Path Modification
This package just had some print statements removed.
Merge branch 'master' of https://github.com/sterlingm/ramp