Mobile Manipulation Capstone 2021 - Revision history

Lynch: /* Introduction, and the CSV Mobile Manipulation youBot CoppeliaSim Scene */

2021-12-09T01:32:09Z

Introduction, and the CSV Mobile Manipulation youBot CoppeliaSim Scene

Lynch: /* Final Step: Completing the Project and Your Submission */

2021-12-06T19:32:30Z

Final Step: Completing the Project and Your Submission

Lynch: /* Final Step: Completing the Project and Your Submission */

2021-12-06T19:30:07Z

Final Step: Completing the Project and Your Submission

Lynch: /* Final Step: Completing the Project and Your Submission */

2021-12-06T19:27:51Z

Final Step: Completing the Project and Your Submission

Lynch: /* Final Step: Completing the Project and Your Submission */

2021-12-06T19:23:17Z

Final Step: Completing the Project and Your Submission

Lynch: /* Final Step: Completing the Project and Your Submission */

2021-12-06T19:22:54Z

Final Step: Completing the Project and Your Submission

Lynch: /* Rigid Bodies in Scene 6 */

2021-11-09T22:11:50Z

Rigid Bodies in Scene 6

Lynch: /* Final Step: Completing the Project and Your Submission */

2021-11-09T18:14:40Z

Final Step: Completing the Project and Your Submission

Lynch: /* Other Things to Try */

2021-11-09T18:02:43Z

Other Things to Try

Lynch: /* Final Step: Completing the Project and Your Submission */

2021-11-09T18:01:43Z

Final Step: Completing the Project and Your Submission

@@ Line 34: / Line 34: @@
 * the initial resting configuration of the cube object (which has a known geometry), represented by a frame attached to the center of the object
 * the desired final resting configuration of the cube object
-* the actual initial configuration of the youBot
+* the actual initial configuration of the youBot (given by a 13-vector as described above, for example)
-* the reference initial configuration of the youBot (which will generally be different from the actual initial configuration, to allow you to test feedback control)
+* the initial configuration <math>T_{se}</math> of the reference trajectory for the end-effector frame of the youBot (this will generally not coincide with the end-effector frame corresponding to the youBot's actual initial configuration, to allow you to test your feedback control)
 * optionally:  gains for your feedback controller (or these gains can be hard-coded in your program)

@@ Line 398: / Line 398: @@
 '''What to submit:''' You will submit a single .zip file of a directory with the following contents:
-# '''A file called README.txt or README.pdf.'''  This file should briefly explain your software and your results.  If you needed to follow a different approach to solve the problem than the one described above, explain why and explain your solution method.  If you encountered anything surprising, or if there is something you still don't understand, or if you think an important point is neglected in the description of the project on this page, explain it.  '''Extra credit (up to 10% of total points possible)''': If you implement joint limits to avoid self-collisions and singularities, as described above, explain your method in this README file.  Also, include more results in the three results directories described below, showing the results when using your enhancements vs. when you don't use your enhancements, to highlight the value of your enhancements.
+# '''A file called README.txt or README.pdf.'''  This file should briefly explain your software and your results.  If you needed to follow a different approach to solve the problem than the one described above, explain why and explain your solution method.  If you encountered anything surprising, or if there is something you still don't understand, or if you think an important point is neglected in the description of the project on this page, explain it.  '''Extra credit (up to 10% of total points possible)''': If you implement joint limits to avoid self-collisions and singularities, as described above, explain your method in this README file, including how you chose your joint limits and why they prevent the arm from colliding with itself or with the mobile base.  Also, include more results in the three results directories described below, showing the results when using your enhancements vs. when you don't use your enhancements, to highlight the value of your enhancements. For example, you should include at least one more video in at least one of the directories, showing the performance when self-collision joint limits are enforced and when they are not.
 # '''Your commented code in a directory called "code."''' Your code should be commented, so it is clear to the reader what the code is doing. Your code comments must include an example of how to use the code, and to make the code easy to run, each separate task you solve should have its own script, so by invoking the script, the code runs with all the appropriate inputs. (This makes it easy for others to test your code and modify it to run with other inputs.)  Apart from the scripts, only turn in functions that you wrote or modified; you don't need to turn in other MR functions that your code uses. If your code is in MATLAB or Python, just turn in the source files (text files) with your functions. If your code is in Mathematica, turn in (a) your .nb notebook file and (b) a .pdf printout of your code, so a reviewer can read your code without having to have the Mathematica software.
 # '''A directory called "results" with the results of your program.''' This directory should contain three directories:  one titled "best," one titled "overshoot," and one titled "newTask."  The directories "best" and "overshoot" both solve a pick-and-place task where the initial and final configurations of the cube are at the default locations in the capstone CoppeliaSim scene, i.e., the initial block configuration is at <math>(x,y,\theta) = (1~\text{m}, 0~\text{m}, 0~\text{rad})</math> and the final block configuration is at <math>(x,y,\theta) = (0~\text{m},-1~\text{m},-\pi/2~\text{rad})</math>.  The directory "newTask" should have different initial and final block configurations, which you are free to choose yourself. In all cases, the initial configuration of the end-effector should have at least 30 degrees of orientation error and 0.2 m of position error from the first configuration on the reference trajectory.  The directory "best" should contain results using a well-tuned controller, either feedforward-plus-P or feedforward-plus-PI.  The convergence exhibited by the controller does not necessarily have to be fast (in fact, it is more interesting if the convergence is not too fast, so the transient response is clearly visible), but the motion should be smooth, with no overshoot, and very little error by partway through trajectory segment 1.  The directory "overshoot" should contain the results using a less-well-tuned controller, one that exhibits overshoot and a bit of oscillation.  Nonetheless, the error should be eliminated before the end of trajectory segment 1.  Your controller for "overshoot" will likely be feedforward-plus-PI or just PI.  You can use any controller to solve the "newTask" task.  In each of the three directories, give:

@@ Line 398: / Line 398: @@
 '''What to submit:''' You will submit a single .zip file of a directory with the following contents:
-# '''A file called README.txt or README.pdf.'''  This file should briefly explain your software and your results.  If you needed to follow a different approach to solve the problem than the one described above, explain why and explain your solution method.  If you encountered anything surprising, or if there is something you still don't understand, or if you think an important point is neglected in the description of the project on this page, explain it.  '''Extra credit (up to 10% of total points possible)''': If you implement joint limits to avoid self-collisions and singularities, as described above, explain your method.  Also, include more results in the three results directories described below, showing the results when using your enhancements vs. when you don't use your enhancements, to highlight the value of your enhancements.
+# '''A file called README.txt or README.pdf.'''  This file should briefly explain your software and your results.  If you needed to follow a different approach to solve the problem than the one described above, explain why and explain your solution method.  If you encountered anything surprising, or if there is something you still don't understand, or if you think an important point is neglected in the description of the project on this page, explain it.  '''Extra credit (up to 10% of total points possible)''': If you implement joint limits to avoid self-collisions and singularities, as described above, explain your method in this README file.  Also, include more results in the three results directories described below, showing the results when using your enhancements vs. when you don't use your enhancements, to highlight the value of your enhancements.
 # '''Your commented code in a directory called "code."''' Your code should be commented, so it is clear to the reader what the code is doing. Your code comments must include an example of how to use the code, and to make the code easy to run, each separate task you solve should have its own script, so by invoking the script, the code runs with all the appropriate inputs. (This makes it easy for others to test your code and modify it to run with other inputs.)  Apart from the scripts, only turn in functions that you wrote or modified; you don't need to turn in other MR functions that your code uses. If your code is in MATLAB or Python, just turn in the source files (text files) with your functions. If your code is in Mathematica, turn in (a) your .nb notebook file and (b) a .pdf printout of your code, so a reviewer can read your code without having to have the Mathematica software.
 # '''A directory called "results" with the results of your program.''' This directory should contain three directories:  one titled "best," one titled "overshoot," and one titled "newTask."  The directories "best" and "overshoot" both solve a pick-and-place task where the initial and final configurations of the cube are at the default locations in the capstone CoppeliaSim scene, i.e., the initial block configuration is at <math>(x,y,\theta) = (1~\text{m}, 0~\text{m}, 0~\text{rad})</math> and the final block configuration is at <math>(x,y,\theta) = (0~\text{m},-1~\text{m},-\pi/2~\text{rad})</math>.  The directory "newTask" should have different initial and final block configurations, which you are free to choose yourself. In all cases, the initial configuration of the end-effector should have at least 30 degrees of orientation error and 0.2 m of position error from the first configuration on the reference trajectory.  The directory "best" should contain results using a well-tuned controller, either feedforward-plus-P or feedforward-plus-PI.  The convergence exhibited by the controller does not necessarily have to be fast (in fact, it is more interesting if the convergence is not too fast, so the transient response is clearly visible), but the motion should be smooth, with no overshoot, and very little error by partway through trajectory segment 1.  The directory "overshoot" should contain the results using a less-well-tuned controller, one that exhibits overshoot and a bit of oscillation.  Nonetheless, the error should be eliminated before the end of trajectory segment 1.  Your controller for "overshoot" will likely be feedforward-plus-PI or just PI.  You can use any controller to solve the "newTask" task.  In each of the three directories, give:
@@ Line 413: / Line 413: @@
  >>
 :::In this case, the file/function "runscript" contains the data for the program and actually invokes the program, and you should include the file "runscript".  It is recommended that your program provide some simple feedback to the user, like "Generating animation csv file.  Writing error plot data.  Done." or similar, but it is not strictly necessary.
-## If you do the extra credit, as described above, your README file should mention additional files in this directory (including at least one extra video file) that shows how your enhancements improve the performance of the system. For example, one video could show the result when you don't use self-collision avoidance, and the other video could show the result when you turn on self-collision avoidance.
 '''Project grading.'''  Your project will be graded on the clarity and correctness of your README files and your code.  Your "results" directories will be graded on their correctness, including the quality of your videos and whether your error plots show reasonable convergence to zero.

@@ Line 398: / Line 398: @@
 '''What to submit:''' You will submit a single .zip file of a directory with the following contents:
-# '''A file called README.txt or README.pdf.'''  This file should briefly explain your software and your results.  If you needed to follow a different approach to solve the problem than the one described above, explain why and explain your solution method.  If you encountered anything surprising, or if there is something you still don't understand, or if you think an important point is neglected in the description of the project on this page, explain it.  '''Extra credit (up to 10% of total points possible)''': If you implement joint limits to avoid self-collisions and singularities, explain your method.  Also, include more results in the three results directories described below, showing the results when using your enhancements vs. when you don't use your enhancements, to highlight the value of your enhancements.
+# '''A file called README.txt or README.pdf.'''  This file should briefly explain your software and your results.  If you needed to follow a different approach to solve the problem than the one described above, explain why and explain your solution method.  If you encountered anything surprising, or if there is something you still don't understand, or if you think an important point is neglected in the description of the project on this page, explain it.  '''Extra credit (up to 10% of total points possible)''': If you implement joint limits to avoid self-collisions and singularities, as described above, explain your method.  Also, include more results in the three results directories described below, showing the results when using your enhancements vs. when you don't use your enhancements, to highlight the value of your enhancements.
 # '''Your commented code in a directory called "code."''' Your code should be commented, so it is clear to the reader what the code is doing. Your code comments must include an example of how to use the code, and to make the code easy to run, each separate task you solve should have its own script, so by invoking the script, the code runs with all the appropriate inputs. (This makes it easy for others to test your code and modify it to run with other inputs.)  Apart from the scripts, only turn in functions that you wrote or modified; you don't need to turn in other MR functions that your code uses. If your code is in MATLAB or Python, just turn in the source files (text files) with your functions. If your code is in Mathematica, turn in (a) your .nb notebook file and (b) a .pdf printout of your code, so a reviewer can read your code without having to have the Mathematica software.
 # '''A directory called "results" with the results of your program.''' This directory should contain three directories:  one titled "best," one titled "overshoot," and one titled "newTask."  The directories "best" and "overshoot" both solve a pick-and-place task where the initial and final configurations of the cube are at the default locations in the capstone CoppeliaSim scene, i.e., the initial block configuration is at <math>(x,y,\theta) = (1~\text{m}, 0~\text{m}, 0~\text{rad})</math> and the final block configuration is at <math>(x,y,\theta) = (0~\text{m},-1~\text{m},-\pi/2~\text{rad})</math>.  The directory "newTask" should have different initial and final block configurations, which you are free to choose yourself. In all cases, the initial configuration of the end-effector should have at least 30 degrees of orientation error and 0.2 m of position error from the first configuration on the reference trajectory.  The directory "best" should contain results using a well-tuned controller, either feedforward-plus-P or feedforward-plus-PI.  The convergence exhibited by the controller does not necessarily have to be fast (in fact, it is more interesting if the convergence is not too fast, so the transient response is clearly visible), but the motion should be smooth, with no overshoot, and very little error by partway through trajectory segment 1.  The directory "overshoot" should contain the results using a less-well-tuned controller, one that exhibits overshoot and a bit of oscillation.  Nonetheless, the error should be eliminated before the end of trajectory segment 1.  Your controller for "overshoot" will likely be feedforward-plus-PI or just PI.  You can use any controller to solve the "newTask" task.  In each of the three directories, give:
@@ Line 413: / Line 413: @@
  >>
 :::In this case, the file/function "runscript" contains the data for the program and actually invokes the program, and you should include the file "runscript".  It is recommended that your program provide some simple feedback to the user, like "Generating animation csv file.  Writing error plot data.  Done." or similar, but it is not strictly necessary.
+## If you do the extra credit, as described above, your README file should mention additional files in this directory (including at least one extra video file) that shows how your enhancements improve the performance of the system. For example, one video could show the result when you don't use self-collision avoidance, and the other video could show the result when you turn on self-collision avoidance.
 '''Project grading.'''  Your project will be graded on the clarity and correctness of your README files and your code.  Your "results" directories will be graded on their correctness, including the quality of your videos and whether your error plots show reasonable convergence to zero.

@@ Line 398: / Line 398: @@
 '''What to submit:''' You will submit a single .zip file of a directory with the following contents:
-# '''A file called README.txt or README.pdf.'''  This file should briefly explain your software and your results.  If you needed to follow a different approach to solve the problem than the one described above, explain why and explain your solution method.  If you encountered anything surprising, or if there is something you still don't understand, or if you think an important point is neglected in the description of the project on this page, explain it.  '''Extra credit (up to 10% of total points possible''': If you implement joint limits to avoid self-collisions and singularities, explain your method.  Also, include more results in the three results directories described below, showing the results when using your enhancements vs. when you don't use your enhancements, to highlight the value of your enhancements.
+# '''A file called README.txt or README.pdf.'''  This file should briefly explain your software and your results.  If you needed to follow a different approach to solve the problem than the one described above, explain why and explain your solution method.  If you encountered anything surprising, or if there is something you still don't understand, or if you think an important point is neglected in the description of the project on this page, explain it.  '''Extra credit (up to 10% of total points possible)''': If you implement joint limits to avoid self-collisions and singularities, explain your method.  Also, include more results in the three results directories described below, showing the results when using your enhancements vs. when you don't use your enhancements, to highlight the value of your enhancements.
 # '''Your commented code in a directory called "code."''' Your code should be commented, so it is clear to the reader what the code is doing. Your code comments must include an example of how to use the code, and to make the code easy to run, each separate task you solve should have its own script, so by invoking the script, the code runs with all the appropriate inputs. (This makes it easy for others to test your code and modify it to run with other inputs.)  Apart from the scripts, only turn in functions that you wrote or modified; you don't need to turn in other MR functions that your code uses. If your code is in MATLAB or Python, just turn in the source files (text files) with your functions. If your code is in Mathematica, turn in (a) your .nb notebook file and (b) a .pdf printout of your code, so a reviewer can read your code without having to have the Mathematica software.
 # '''A directory called "results" with the results of your program.''' This directory should contain three directories:  one titled "best," one titled "overshoot," and one titled "newTask."  The directories "best" and "overshoot" both solve a pick-and-place task where the initial and final configurations of the cube are at the default locations in the capstone CoppeliaSim scene, i.e., the initial block configuration is at <math>(x,y,\theta) = (1~\text{m}, 0~\text{m}, 0~\text{rad})</math> and the final block configuration is at <math>(x,y,\theta) = (0~\text{m},-1~\text{m},-\pi/2~\text{rad})</math>.  The directory "newTask" should have different initial and final block configurations, which you are free to choose yourself. In all cases, the initial configuration of the end-effector should have at least 30 degrees of orientation error and 0.2 m of position error from the first configuration on the reference trajectory.  The directory "best" should contain results using a well-tuned controller, either feedforward-plus-P or feedforward-plus-PI.  The convergence exhibited by the controller does not necessarily have to be fast (in fact, it is more interesting if the convergence is not too fast, so the transient response is clearly visible), but the motion should be smooth, with no overshoot, and very little error by partway through trajectory segment 1.  The directory "overshoot" should contain the results using a less-well-tuned controller, one that exhibits overshoot and a bit of oscillation.  Nonetheless, the error should be eliminated before the end of trajectory segment 1.  Your controller for "overshoot" will likely be feedforward-plus-PI or just PI.  You can use any controller to solve the "newTask" task.  In each of the three directories, give:

@@ Line 141: / Line 141: @@
 * '''respondable''':  The body can make contact and collide with other bodies.
 * '''non-respondable''':  The body can pass through other bodies.
-Thus if a respondable body and a non-respondable body overlap, or if two non-respondable bodies overlap, there is no collision.  If two respondable bodies make contact, however, forces will keep them from penetrating each other.
+Thus if a respondable body and a non-respondable body overlap, or if two non-respondable bodies overlap, there is no collision.  If two respondable bodies make contact, however, forces will try to keep them from penetrating each other.
 '''In Scene 6, only the floor, the gripper fingers, and the cube are respondable.  All other bodies are non-respondable.''' This means, for example, that the robot can drive over the cube, and the cube will never move.  (The chassis and wheels do not interact with the cube.)  This also means that the youBot's arm can intersect the mobile base, or arm links can intersect each other.  This is unrealistic, of course, but we are focusing on the interaction of the cube with the gripper and the floor.

@@ Line 399: / Line 399: @@
 '''What to submit:''' You will submit a single .zip file of a directory with the following contents:
 # '''A file called README.txt or README.pdf.'''  This file should briefly explain your software and your results.  If you needed to follow a different approach to solve the problem than the one described above, explain why and explain your solution method.  If you encountered anything surprising, or if there is something you still don't understand, or if you think an important point is neglected in the description of the project on this page, explain it.  If you implemented singularity avoidance, joint limit avoidance, or any other enhancement over the basic project description given on this page, explain your method.  You may also wish to include more results in the three results directories described below, showing the results when using your enhancements vs. when you don't use your enhancements, to highlight the value of your enhancements.
-# '''Your commented code in a directory called "code."''' Your code should be commented, so it is clear to the reader what the code is doing. No need to go overboard with too many comments, but keep in mind your reviewer may not be fluent in your programming language. Your code comments must include an example of how to use the code, and to make the code easy to run, each separate task you solve should have its own script, so by invoking the script, the code runs with all the appropriate inputs. (This makes it easy for others to test your code and modify it to run with other inputs.)  Apart from the scripts, only turn in functions that you wrote or modified; you don't need to turn in other MR functions that your code uses. If your code is in MATLAB or Python, just turn in the source files (text files) with your functions. If your code is in Mathematica, turn in (a) your .nb notebook file and (b) a .pdf printout of your code, so a reviewer can read your code without having to have the Mathematica software.
+# '''Your commented code in a directory called "code."''' Your code should be commented, so it is clear to the reader what the code is doing. Your code comments must include an example of how to use the code, and to make the code easy to run, each separate task you solve should have its own script, so by invoking the script, the code runs with all the appropriate inputs. (This makes it easy for others to test your code and modify it to run with other inputs.)  Apart from the scripts, only turn in functions that you wrote or modified; you don't need to turn in other MR functions that your code uses. If your code is in MATLAB or Python, just turn in the source files (text files) with your functions. If your code is in Mathematica, turn in (a) your .nb notebook file and (b) a .pdf printout of your code, so a reviewer can read your code without having to have the Mathematica software.
 # '''A directory called "results" with the results of your program.''' This directory should contain three directories:  one titled "best," one titled "overshoot," and one titled "newTask."  The directories "best" and "overshoot" both solve a pick-and-place task where the initial and final configurations of the cube are at the default locations in the capstone CoppeliaSim scene, i.e., the initial block configuration is at <math>(x,y,\theta) = (1~\text{m}, 0~\text{m}, 0~\text{rad})</math> and the final block configuration is at <math>(x,y,\theta) = (0~\text{m},-1~\text{m},-\pi/2~\text{rad})</math>.  The directory "newTask" should have different initial and final block configurations, which you are free to choose yourself. In all cases, the initial configuration of the end-effector should have at least 30 degrees of orientation error and 0.2 m of position error from the first configuration on the reference trajectory.  The directory "best" should contain results using a well-tuned controller, either feedforward-plus-P or feedforward-plus-PI.  The convergence exhibited by the controller does not necessarily have to be fast (in fact, it is more interesting if the convergence is not too fast, so the transient response is clearly visible), but the motion should be smooth, with no overshoot, and very little error by partway through trajectory segment 1.  The directory "overshoot" should contain the results using a less-well-tuned controller, one that exhibits overshoot and a bit of oscillation.  Nonetheless, the error should be eliminated before the end of trajectory segment 1.  Your controller for "overshoot" will likely be feedforward-plus-PI or just PI.  You can use any controller to solve the "newTask" task.  In each of the three directories, give:
 ## A very brief README.txt or README.pdf file that indicates the type of controller, the feedback gains, and any other useful information about the results.  For the "newTask" directory, indicate the initial and goal configurations for the cube.

@@ Line 421: / Line 421: @@
 You could imagine other approaches to solving the mobile manipulator pick-and-place problem, instead of just planning a trajectory for the end-effector and using feedback control to track it.  For example, you could use an obstacle-avoiding motion planner to plan a reference trajectory for the entire robot, not just the end-effector.  You could incorporate joint limits for the robot arm.  You could use a weighted pseudoinverse, instead of the standard pseudoinverse, to indicate a preference to use wheel or joint motions.  You could actively avoid singularities of the arm.  You could decide to keep the mobile base stationary during trajectory segments 2, 4, 6, and 8.
-If you have other ideas on better ways to approach the mobile manipulation problem, feel free to mention them in a discussion prompt or your main README file.
 If you are interested, you could delve more deeply into CoppeliaSim, for example by changing the respondability or dynamic properties of rigid bodies.  If you make the youBot chassis respondable, the youBot's chassis can push the block around.

@@ Line 416: / Line 416: @@
 '''Project grading.'''  Your project will be graded on the clarity and correctness of your README files and your code.  Your "results" directories will be graded on their correctness, including the quality of your videos and whether your error plots show reasonable convergence to zero.
-'''If you succeed in this project, congratulations!'''  You have integrated concepts from all five previous Modern Robotics courses in a fairly sophisticated piece of software.
+'''If you succeed in this project, congratulations!'''  You have integrated concepts from Modern Robotics in a fairly sophisticated piece of software.
 == Other Things to Try ==