more information on motion planning and robot movement

docs/Robot_Movement.rst

@@ -1,7 +1,6 @@
 Robot Motion
 ===============================
 
-We used the default motion planner in Movit, which uses the OMPL, an open-source motion planning library that primarily implements randomized motion planners.
 A separate python script was created which contained the robot class with methods related to its motion. This enabled us to keep the main python script clean and legible. The following in a breakdown of the methods within this Connect4Robot class.
 
 
@@ -307,5 +306,6 @@ The code for closing the gripper is as follows
 
 
 
-
-Note that we have a separate function that broadcasts the gripper position to ROS. This is to ensure Gazebo sees the movement and displays accordingly. We create a ``gripper_publisher`` that publishes the new gripper position to the ``/franka/gripper_position_controller/command`` topic so that Gazebo can be updated.
+.. note::
+
+    we have a separate function that broadcasts the gripper position to ROS. This is to ensure Gazebo sees the movement and displays accordingly. We create a ``gripper_publisher`` that publishes the new gripper position to the ``/franka/gripper_position_controller/command`` topic so that Gazebo can be updated.

docs/motion_planning.rst

@@ -11,17 +11,35 @@ Collision Avoidance
 --------------------------
 The primary obstacle in the robot's workspace was the Connect 4 board. We had to tell Movit, the motion planner, to avoid getting any part of the robot to collide with the board. 
 
-Two accurate models were required for collision detection. I 3D model of the robot, including all its links and of the connect 4 board.
+Two 3D models were required for collision detection. The 3D model of the robot, including all its links and of the connect 4 board.
 
+The 3D models of the model was supplied by the robot manufacturer in the form of .dae mesh files. These files can be found in ``RoboticsProject\catkin_ws\src\franka_gazebo\meshes\visual`` .
 
-In order to simplify computation, we defined the obstacle solely by a bounding box, a box that completely encompassed the volume of the connect 4 board.
 
+.. note::
 
+	The .dae mesh files are a lower resolution polygon mesh file compared to the .stl files supplied for visualisation. This is done to reduce computation load for collision detection.
+
+
+In order to simplify computation, we defined the connect 4 board obstacle solely by a bounding box, a box that completely encompassed the volume of the connect 4 board.
+
+
+.. figure:: _static/Rviz_obstacle.png
+    :align: center
+    :figclass: align-center
+
+
+For a comparison between the 3D models for visualisation collision detection, here is a photo of the 3D models of the connect 4 board. On the left is the bounding box obstacle used for collsion detection(rendered with Rviz) while on the right is the higher resolution model of the connect four board(rendered in Gazebo).
+
+.. figure:: _static/Gazebo_and_Rviz_side_by_side.png
+    :align: center
+    :figclass: align-center
+
+We could define the dimension, position and orientation of the obstacle with a few lines of code in the intial part of the main script running the game code. We define the position, orientation and dimensions of the box and pass that into the ``scene.add_box(obstacle_name, pose, dimensions)`` function that tells the motion planner the obstacle information.
 
 .. code-block:: python
 
 	p = geometry_msgs.msg.PoseStamped()
-	#p = PoseStamped()
 	p.header.frame_id = robot.get_planning_frame()
 	p.pose.position.x = 0.4
 	p.pose.position.y = -0.301298
@@ -30,16 +48,12 @@ In order to simplify computation, we defined the obstacle solely by a bounding b
 	p.pose.orientation.y = 0
 	p.pose.orientation.z = 0.0
 	p.pose.orientation.w = 0.4440158
-	#scene.add_mesh("Connect4", p,"connect4.STL")
-	scene.add_box("table", p, (0.5, 1.5, 0.6))
+	scene.add_box("box", p, (0.5, 1.5, 0.6))
 	rospy.sleep(2)
 
-Throughout the project , collision detection has been implemented by placing the obstacle geometry directly into the moveit scene.
-The reason for this is that by placing it into the Moveit scene it connects directly to the motion planning. 
-Originally an simplified stl model of the board was placed inside the environment.
-This was replaced with just a large cuboid over the area that would be taken up by the grid, as it significantly reduced the computation time for motion planning.
 
-.. figure:: _static/Rviz_obstacle.png
-    :align: center
-    :figclass: align-center
+.. note::
+
+	When you run the script to insert the box, you will notice that the obstacle(in green) does not immediately appear in the Rviz workspace GUI. The add_box method adds the object asynchronously so that RViz is not notified. The way to visualise this is to REMOVE the ``motion planning`` branch from the ``display`` tree in Rviz and add it back. Then the obstacle will appear. Note that you must make sure you have run scene.add_box method earlier. More information can be found in this question_
+.. _question: https://answers.ros.org/question/209030/moveit-planningsceneinterface-addbox-not-showing-in-rviz/