Project Z

Overview and purpose

Logistics

Your task

• The obstacles will all be circles in the plane, in locations that are known to the robot.
• To know where the obstacles are, your program should accept a string parameter that describes a set of circles. You can choose the appropriate format for this string, but it should support an arbitrary number of circle obstacles, each defined by its radius and the $(x,y)$ coordinates of its center.
• Your program must publish a
  MarkerArray
  showing the obstacles. This will be helpful for debugging. It will also be essential for demonstrating in video form that your solution is correct. (See submission instructions below.) You are welcome to include other markers in the visualization, but the obstacles themselves must be clearly visible.
• You will want to design several different obstacles configurations to effectively test your program and demonstrate its correctness.

• To know its goal, your program should subscribe to the topic
  /goal_pose
  with message type
  geometry_msgs/msg/PoseStamped
  . When a message is published on this topic, your robot should discard its previous goal (if any), and then form and execute a new plan to navigate to the given goal pose without colliding with any obstacles.
• One convenient way to publish goals with the correct data type and topic is to use the 2D Goal Pose feature in
  rviz
  . First click the “2D Goal Pose” button, then click on the goal position and drag from there to set the goal orientation. (If you cannot see the “2D Goal Pose” button, you may need to enable the Tools panel using the
  rviz
  main menu.)

• The robot should travel in a reasonably direct manner to the goal, but need not necessarily adhere to the absolute shortest path. You should aim for paths that are within about 10% of the optimal path length.
• You may use algorithm you like to generate the plans, as long as it is correct and reasonably efficient.
• If the given goal represents an unreachable configuration (i.e. within an obstacle or in a part of the free space that cannot be reached), the robot should ignore the request.
• Note that
  sim1
  does NOT check for collisions between the robot and the obstacles. It doesn't even know about the obstacles! Your should nevertheless ensure that the entire robot avoids the obstacles.

What to submit

1. A PDF report including:
   1. A concise description of how the system works. This should be a couple of paragraphs, describing your overall approach at a conceptual level. Some questions to consider: What choices did you make in designing the program, and why?
   2. A short answer to these questions: Did the results meet your expectations? Why or why not?
2. The source code for your system, including executable code, launch files, and other supporting files. Be sure to consult the source code style guide.
3. One video showing
   rviz
   visualizations of the behavior of your system executed in at least three different environments, reaching at least three different goals in each environment.
   • The visualization must include at least the robot model, the
     sim_markers
     published by
     sim1
     , and the obstacle markers published by your new program.
   • Other displays may be included at your discretion, as long as the robot's movement among the obstacles can be seen clearly.
   The paths executed in the video must show:
   • At least one goal where the shortest path requires 2 or more turns to navigate around the obstacles.
   • At least one goal that is unreachable.
   • At least one goal where the straight line path from start to goal is unobstructed.
   • Other goals that fully illustrate your robot's ability to navigate safely and reliably in a variety of circumstances.
   The length of this video must be at most 3 minutes.