Changed sending best trajectory to a ros::Timer callback, Fixed bugs in path_modification
The best trajectory should be put in a Timer callback because that makes how often it is sent more accurate to the control cycle value. Before, it was almost always delayed due to waiting on processing in the loop in planner's go method. With a Timer, the best trajectory is sent at each control cycle and doesn't have to wait on anything else. A mutex value was also added for the population because we need to update the population during the control cycle (now on a Timer callback) and also need access to the population for the modification procedure.
This change didn't seem to have any effect on how the robot moves along a trajectory. I tested (not on the ground) 10 times and they were all normal tests. I did not have any tests that resulted in the infinite-slow-turning loop that we saw last week.
There were 2 bugs in path_modification.
  1) It was crashing when printing out the paths that it received, which made the path the srv request fail. This created problems for the planner because it was then trying to generate a trajectory for an empty path (because no path was sent back). The bug was actually just in the Utility::toString(ramp_msgs::Path) method when printing out a Configuration's Ranges.
  2) The Crossover operation was incorrect. If the knotpoint randomly selected for one path was larger than the size of the other path, the crossover method just pushed on the first part of one path, and then the goal. It SHOULD (and does not) push on the first part of the one path, and second part of second path, no matter the sizes of the paths.
This is no change to the code, but something to note - I ran roscore on my laptop as opposed to the laptop today. When I first started running tests today, the nodes were all moving very slowly. I couldn't do anything. So I changed the ROS variables on the robot and my laptop so that roscore would be on my laptop and this made everything run MUCH faster and more stable. This is probably due to 1) faster cpu speed and 2) the robot only having 1 core vs 4 cores on my laptop's cpu. So I think we should stop running roscore on the robot.