Capstone Dev - Revision history

Lynch: Replaced content with "See Mobile Manipulation Capstone."

2018-06-18T19:37:14Z

Replaced content with "See Mobile Manipulation Capstone."

Lynch: /* Introduction, and the CSV Mobile Manipulation youBot V-REP scene */

2018-06-18T19:19:26Z

Introduction, and the CSV Mobile Manipulation youBot V-REP scene

← Older revision		Revision as of 14:19, 18 June 2018
Line 17:		Line 17:
	[[V-REP_Introduction#Scene_6:_CSV_Mobile_Manipulation_youBot\|'''This project uses Scene 6 (CSV Mobile Manipulation youBot) from the V-REP Introduction wiki page''']]. You should download it and test it with its sample csv file, to see what a solution looks like. (Even if you have downloaded it before, download it again before you begin your project, to make sure you have the most up-to-date version of this scene.) Leave the block's initial and goal configurations as the default. The default 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>.		[[V-REP_Introduction#Scene_6:_CSV_Mobile_Manipulation_youBot\|'''This project uses Scene 6 (CSV Mobile Manipulation youBot) from the V-REP Introduction wiki page''']]. You should download it and test it with its sample csv file, to see what a solution looks like. (Even if you have downloaded it before, download it again before you begin your project, to make sure you have the most up-to-date version of this scene.) Leave the block's initial and goal configurations as the default. The default 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>.

	Unlike previous projects, where we used V-REP to simply animate the robot's motion, in this project V-REP will use a physics simulator to simulate the interaction of the youBot with the block. In other words, if the gripper closes on the block in the wrong position or orientation, the block may simply slide out of the grasp. The interaction between the robot and the block is governed by a physics simulator, often called a "physics engine," which approximately accounts for friction, mass, inertial, and other properties. V-REP has different physics engines which you can select, including Bullet and ODE.		Unlike previous projects, where we used V-REP to simply animate the robot's motion, in this project V-REP will use a physics simulator to simulate the interaction of the youBot with the block. In other words, if the gripper closes on the block in the wrong position or orientation, the block may simply slide out of the grasp. The interaction between the robot and the block is governed by a physics simulator, often called a "physics engine," which approximately accounts for friction, mass, inertial, and other properties. V-REP has different physics engines which you can select, including Bullet and ODE, but ODE is the default for Scene 6.

	'''The time between each successive configuration in your csv file is 0.01 seconds (10 milliseconds).''' This is an important bit of information, since, unlike the previous visualization scenes which simply animated a csv file with no particular notion of time, the notion of time is critical in a dynamic simulation.		'''The time between each successive configuration in your csv file is 0.01 seconds (10 milliseconds).''' This is an important bit of information, since, unlike the previous visualization scenes which simply animated a csv file with no particular notion of time, the notion of time is critical in a dynamic simulation.

Lynch: /* Milestone 3: Feedforward Control */

2018-06-18T19:00:55Z

Milestone 3: Feedforward Control

← Older revision		Revision as of 14:00, 18 June 2018
Line 232:		Line 232:
	Do not move on with the project until your feedforward control works as you expect. Otherwise the effects of PI feedback control will only further confuse the situation.		Do not move on with the project until your feedforward control works as you expect. Otherwise the effects of PI feedback control will only further confuse the situation.

	'''The physics engine in V-REP:''' By default, Scene 6 (the capstone mobile manipulation scene) uses a simulation timestep of dt = 10 ms and the physics engine ODE. You should keep the timestep at 10 ms for simulated time to be correct, and we have found ODE to yield more easily understood results than Bullet for Scene 6. But you are welcome to try different physics engines if you'd like. Keep in mind that simulation of bodies in contact is computationally intensive, and approximate solution methods could lead to unexpected behavior, like the block slipping in the grasp. We don't have a suggested "fix" for this; if you want to learn about how simulators work, and the various approximations they make, you are encouraged to consult the documentation for [http://www.ode.org/ ODE] and [http://bulletphysics.org/wordpress/ Bullet].		'''The physics engine in V-REP:''' By default, Scene 6 (the capstone mobile manipulation scene) uses a simulation timestep of dt = 10 ms and the physics engine ODE. You should keep the timestep at 10 ms for simulated time to be correct, and we have found ODE to yield more easily understood results than Bullet for Scene 6. But you are welcome to try different physics engines if you'd like; specify your choice in the V-REP interface. Keep in mind that simulation of bodies in contact is computationally intensive, and approximate solution methods could lead to unexpected behavior, like the block slipping in the grasp. We don't have a suggested "fix" for this; if you want to learn about how simulators work, and the various approximations they make, you are encouraged to consult the documentation for [http://www.ode.org/ ODE] and [http://bulletphysics.org/wordpress/ Bullet].

	=== Final Step: Completing the Project and Your Submission ===		=== Final Step: Completing the Project and Your Submission ===

Lynch: /* Milestone 3: Feedforward Control */

2018-06-18T19:00:13Z

Milestone 3: Feedforward Control

← Older revision		Revision as of 14:00, 18 June 2018
Line 232:		Line 232:
	Do not move on with the project until your feedforward control works as you expect. Otherwise the effects of PI feedback control will only further confuse the situation.		Do not move on with the project until your feedforward control works as you expect. Otherwise the effects of PI feedback control will only further confuse the situation.

	'''The physics engine in V-REP:''' By default, Scene 6 (the capstone mobile manipulation scene) uses a simulation timestep of dt = 10 ms and the physics engine ODE. You should keep the timestep at 10 ms for simulated time to be correct, and we have found ODE to yield more ~~reasonable~~ results than Bullet. But you are welcome to try different physics engines if you'd like. Keep in mind that simulation of bodies in contact is computationally intensive, and approximate solution methods could lead to unexpected behavior, like the block slipping in the grasp. We don't have a suggested "fix" for this; if you want to learn about how simulators work, and the various approximations they make, you are encouraged to consult the documentation for [http://www.ode.org/ ODE] and [http://bulletphysics.org/wordpress/ Bullet].		'''The physics engine in V-REP:''' By default, Scene 6 (the capstone mobile manipulation scene) uses a simulation timestep of dt = 10 ms and the physics engine ODE. You should keep the timestep at 10 ms for simulated time to be correct, and we have found ODE to yield more easily understood results than Bullet for Scene 6. But you are welcome to try different physics engines if you'd like. Keep in mind that simulation of bodies in contact is computationally intensive, and approximate solution methods could lead to unexpected behavior, like the block slipping in the grasp. We don't have a suggested "fix" for this; if you want to learn about how simulators work, and the various approximations they make, you are encouraged to consult the documentation for [http://www.ode.org/ ODE] and [http://bulletphysics.org/wordpress/ Bullet].

	=== Final Step: Completing the Project and Your Submission ===		=== Final Step: Completing the Project and Your Submission ===

Lynch: /* Milestone 3: Feedforward Control */

2018-06-18T18:59:19Z

Milestone 3: Feedforward Control

← Older revision		Revision as of 13:59, 18 June 2018
Line 226:		Line 226:
	Once the program has completed all iterations of the loop, it should write out the csv file of configurations. If the total time of motion of the youBot is 15 seconds, your csv file should have 1500 lines (or 1501 lines), corresponding to 0.01 seconds between each configuration. Load the csv file into the CSV Mobile Manipulation youBot scene to see the results. Your program should also generate a file with the log of the <math>X_{\text{err}}</math> 6-vector as a function of time, suitable for plotting by your favorite plotting software.		Once the program has completed all iterations of the loop, it should write out the csv file of configurations. If the total time of motion of the youBot is 15 seconds, your csv file should have 1500 lines (or 1501 lines), corresponding to 0.01 seconds between each configuration. Load the csv file into the CSV Mobile Manipulation youBot scene to see the results. Your program should also generate a file with the log of the <math>X_{\text{err}}</math> 6-vector as a function of time, suitable for plotting by your favorite plotting software.

	'''Testing feedforward control:''' You should make sure feedforward control works as you expect before testing feedback control. Choose an initial configuration of the robot that puts the end-effector exactly at the configuration at the beginning of the reference trajectory. Run your program with <math>K_p = K_i = 0</math>, i.e., feedforward control only. This should result in a csv file which, when played through the V-REP capstone scene, drives the robot to pick up the block and put it down at the desired configuration. (Or at least it should come close to doing so!) If not, time to start debugging! Your end-effector reference trajectory must be correct, if you already tested Milestone 2. So now you have to figure out why the wheel and arm controls your feedforward controller and Jacobian pseudoinverse are generating do not drive the end-effector along the reference trajectory.		'''Testing feedforward control:''' You should make sure feedforward control works as you expect before testing feedback control. Choose an initial configuration of the robot that puts the end-effector exactly at the configuration at the beginning of the reference trajectory. Run your program with <math>K_p = K_i = 0</math>, i.e., feedforward control only. This should result in a csv file which, when played through the V-REP capstone scene, drives the robot to pick up the block and put it down at the desired configuration. (Or at least it should come very close to doing so! Small numerical error in the integration will be fixed when you add a feedback controller.) If not, time to start debugging! Your end-effector reference trajectory must be correct, if you already tested Milestone 2. So now you have to figure out why the wheel and arm controls your feedforward controller and Jacobian pseudoinverse are generating do not drive the end-effector along the reference trajectory.

	You should also try starting the end-effector with some initial error from the reference trajectory. See how the end-effector moves under these circumstances. Does it make sense to you?		You should also try starting the end-effector with some initial error from the reference trajectory. See how the end-effector moves under these circumstances. Does it make sense to you?

	Do not move on with the project until your feedforward control works as you expect. Otherwise the effects of PI feedback control will only further confuse the situation.		Do not move on with the project until your feedforward control works as you expect. Otherwise the effects of PI feedback control will only further confuse the situation.

			'''The physics engine in V-REP:''' By default, Scene 6 (the capstone mobile manipulation scene) uses a simulation timestep of dt = 10 ms and the physics engine ODE. You should keep the timestep at 10 ms for simulated time to be correct, and we have found ODE to yield more reasonable results than Bullet. But you are welcome to try different physics engines if you'd like. Keep in mind that simulation of bodies in contact is computationally intensive, and approximate solution methods could lead to unexpected behavior, like the block slipping in the grasp. We don't have a suggested "fix" for this; if you want to learn about how simulators work, and the various approximations they make, you are encouraged to consult the documentation for [http://www.ode.org/ ODE] and [http://bulletphysics.org/wordpress/ Bullet].

	=== Final Step: Completing the Project and Your Submission ===		=== Final Step: Completing the Project and Your Submission ===

Lynch: /* Milestone 1: youBot Kinematics Simulator and csv Output */

2018-06-18T18:48:40Z

Milestone 1: youBot Kinematics Simulator and csv Output

← Older revision		Revision as of 13:48, 18 June 2018
Line 144:		Line 144:
	To test your <tt>NextState</tt> function, you should embed it in a program that takes an initial configuration of the youBot and simulates constant controls for one second. For example, you can set <math>\Delta t</math> to 0.01 seconds and run a loop that calls <tt>NextState</tt> 100 times with constant controls <math>(u,\dot{\theta})</math>. Your program should write a csv file, where each line has 13 values separated by commas (the 12-vector consisting of 3 chassis configuration variables, the 5 arm joint angles, and the 4 wheel angles, plus a "0" for "gripper open") representing the robot's configuration after each integration step. Then you should load the csv file into the CSV Mobile Manipulation youBot V-REP scene and watch the animation of the constant controls to see if your <tt>NextState</tt> function is working properly (and to check your ability to produce a csv file).		To test your <tt>NextState</tt> function, you should embed it in a program that takes an initial configuration of the youBot and simulates constant controls for one second. For example, you can set <math>\Delta t</math> to 0.01 seconds and run a loop that calls <tt>NextState</tt> 100 times with constant controls <math>(u,\dot{\theta})</math>. Your program should write a csv file, where each line has 13 values separated by commas (the 12-vector consisting of 3 chassis configuration variables, the 5 arm joint angles, and the 4 wheel angles, plus a "0" for "gripper open") representing the robot's configuration after each integration step. Then you should load the csv file into the CSV Mobile Manipulation youBot V-REP scene and watch the animation of the constant controls to see if your <tt>NextState</tt> function is working properly (and to check your ability to produce a csv file).

	'''Sample controls to try:''' Simulate the following controls for 1 second and watch the results in the V-REP scene. The controls below are only for the wheels; you can choose the arm joint speeds as you wish.		'''Sample controls to try:''' Simulate the following controls for 1 second and watch the results in the V-REP capstone scene (Scene 6). The controls below are only for the wheels; you can choose the arm joint speeds as you wish.
	# <math>u = (10,10,10,10)</math>. The robot chassis should drive forward (in the <math>+\hat{\text{x}}_{\text{b}}</math> direction) by 0.475 meters.		# <math>u = (10,10,10,10)</math>. The robot chassis should drive forward (in the <math>+\hat{\text{x}}_{\text{b}}</math> direction) by 0.475 meters.
	# <math>u = (-10,10,-10,10)</math>. The robot chassis should slide in the <math>+\hat{\text{y}}_{\text{b}}</math> direction by 0.475 meters.		# <math>u = (-10,10,-10,10)</math>. The robot chassis should slide in the <math>+\hat{\text{y}}_{\text{b}}</math> direction by 0.475 meters.

Lynch: /* Milestone 2: Reference Trajectory Generation */

2018-06-18T18:47:05Z

Milestone 2: Reference Trajectory Generation

← Older revision		Revision as of 13:47, 18 June 2018
Line 182:		Line 182:
	Your <tt>TrajectoryGenerator</tt> function is likely to use either <tt>ScrewTrajectory</tt> or <tt>CartesianTrajectory</tt>, from the Modern Robotics code library, to generate the individual trajectory segments.		Your <tt>TrajectoryGenerator</tt> function is likely to use either <tt>ScrewTrajectory</tt> or <tt>CartesianTrajectory</tt>, from the Modern Robotics code library, to generate the individual trajectory segments.

	'''Testing your function:''' We have created a [[V-REP_Introduction\|'''V-REP scene (~~scene~~ 8)''']] to help you test your <tt>TrajectoryGenerator</tt> function. This scene reads in your csv file and animates it, showing how the end-effector frame moves as a function of time. You should verify that your <tt>TrajectoryGenerator</tt> works as you expect before moving on with the project. [https://youtu.be/8d_cYwV58lI '''This video shows an example of a typical output of your trajectory generator function, as animated by V-REP ~~scene~~ 8'''].		'''Testing your function:''' We have created a [[V-REP_Introduction\|'''V-REP scene (Scene 8)''']] to help you test your <tt>TrajectoryGenerator</tt> function. This scene reads in your csv file and animates it, showing how the end-effector frame moves as a function of time. You should verify that your <tt>TrajectoryGenerator</tt> works as you expect before moving on with the project. [https://youtu.be/8d_cYwV58lI '''This video shows an example of a typical output of your trajectory generator function, as animated by V-REP Scene 8'''].

	=== Milestone 3: Feedforward Control ===		=== Milestone 3: Feedforward Control ===

Lynch: /* Alternative Solution Methods */

2018-06-18T17:41:43Z

Alternative Solution Methods

← Older revision		Revision as of 12:41, 18 June 2018
Line 271:		Line 271:
	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.		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 ~~the~~ discussion prompt or your main README file.		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.

	'''For fun:''' See if you can plan and execute a trajectory for the robot arm that causes the gripper to throw the block to a desired landing point!		'''For fun:''' See if you can plan and execute a trajectory for the robot arm that causes the gripper to throw the block to a desired landing point!

Lynch at 17:38, 18 June 2018

2018-06-18T17:38:12Z

← Older revision		Revision as of 12:38, 18 June 2018
Line 68:		Line 68:
	# A trajectory to move the gripper back to the "standoff" configuration.		# A trajectory to move the gripper back to the "standoff" configuration.

	Segments 3 and 7 each keep the end-effector fixed in space but, at the beginning of the segment, change the state of the gripper from 0 to 1 or 1 to 0, waiting ~~one second~~ for the gripper closing to complete. In other words, each of these segments would consist of ~~100~~ identical lines of the csv file (~~corresponding to~~ ~~one~~ ~~second~~), where the first line has a gripper state different from the previous line in the csv file, to initiate the opening or closing.		Segments 3 and 7 each keep the end-effector fixed in space but, at the beginning of the segment, change the state of the gripper from 0 to 1 or 1 to 0, waiting for the gripper closing to complete. In other words, each of these segments would consist of at least 63 identical lines of the csv file (as described above), where the first line has a gripper state different from the previous line in the csv file, to initiate the opening or closing.

	Segments 2, 4, 6, and 8 are simple up or down translations of the gripper of a fixed distance. Good trajectory segments would be cubic or quintic polynomials taking a reasonable amount of time (e.g., one second).		Segments 2, 4, 6, and 8 are simple up or down translations of the gripper of a fixed distance. Good trajectory segments would be cubic or quintic polynomials taking a reasonable amount of time (e.g., one second).
Line 75:		Line 75:

	Once the entire gripper reference trajectory has been pieced together from the 8 segments, the actual trajectory of the youBot is obtained by using a Jacobian pseudoinverse position controller as described in Chapter 13.5. Starting from the actual initial robot configuration (which has some error from the beginning of reference segment 1), your controller drives the gripper to converge to the reference trajectory. Your feedback controller should eliminate initial error before the gripper attempts to grasp the block, to avoid failure.		Once the entire gripper reference trajectory has been pieced together from the 8 segments, the actual trajectory of the youBot is obtained by using a Jacobian pseudoinverse position controller as described in Chapter 13.5. Starting from the actual initial robot configuration (which has some error from the beginning of reference segment 1), your controller drives the gripper to converge to the reference trajectory. Your feedback controller should eliminate initial error before the gripper attempts to grasp the block, to avoid failure.

	You are welcome to adopt a different approach to solving the pick-and-place problem, provided your approach takes the same inputs specified above, produces an error data file and a csv file that successfully achieves the task, and is fully automatic (i.e., it works for different initial and final configurations of the block, different initial and reference configurations for the youBot, and requires no human intervention).

	To simulate the effect of feedback control, you must write your own motion simulator. For each timestep, you take the initial configuration of the robot and the wheel and joint speeds calculated by your controller and numerically integrate the effect of these speeds over a timestep to get the new robot configuration. To calculate the new configuration of the chassis due to the wheel motions, you must implement an odometry step (Chapter 13.4).		To simulate the effect of feedback control, you must write your own motion simulator. For each timestep, you take the initial configuration of the robot and the wheel and joint speeds calculated by your controller and numerically integrate the effect of these speeds over a timestep to get the new robot configuration. To calculate the new configuration of the chassis due to the wheel motions, you must implement an odometry step (Chapter 13.4).

Lynch at 17:32, 18 June 2018

2018-06-18T17:32:56Z

← Older revision		Revision as of 12:32, 18 June 2018
Line 19:		Line 19:
	Unlike previous projects, where we used V-REP to simply animate the robot's motion, in this project V-REP will use a physics simulator to simulate the interaction of the youBot with the block. In other words, if the gripper closes on the block in the wrong position or orientation, the block may simply slide out of the grasp. The interaction between the robot and the block is governed by a physics simulator, often called a "physics engine," which approximately accounts for friction, mass, inertial, and other properties. V-REP has different physics engines which you can select, including Bullet and ODE.		Unlike previous projects, where we used V-REP to simply animate the robot's motion, in this project V-REP will use a physics simulator to simulate the interaction of the youBot with the block. In other words, if the gripper closes on the block in the wrong position or orientation, the block may simply slide out of the grasp. The interaction between the robot and the block is governed by a physics simulator, often called a "physics engine," which approximately accounts for friction, mass, inertial, and other properties. V-REP has different physics engines which you can select, including Bullet and ODE.

	The time between each successive configuration in your csv file is 0.01 seconds (10 milliseconds). A ~~typical~~ ~~line~~ of ~~your~~ csv file ~~would~~ be ~~something~~ ~~like~~		'''The time between each successive configuration in your csv file is 0.01 seconds (10 milliseconds).''' This is an important bit of information, since, unlike the previous visualization scenes which simply animated a csv file with no particular notion of time, the notion of time is critical in a dynamic simulation.

			A typical line of your csv file would be something like

	-0.75959, -0.47352, 0.058167, 0.80405, -0.91639, -0.011436, 0.054333, 0.00535, 1.506, -1.3338, 1.5582, 1.6136, 0		-0.75959, -0.47352, 0.058167, 0.80405, -0.91639, -0.011436, 0.054333, 0.00535, 1.506, -1.3338, 1.5582, 1.6136, 0
Line 31:		Line 33:
	[[image:youbot-top-view.png\|right\|x150px]]		[[image:youbot-top-view.png\|right\|x150px]]

	Wheels 1 to 4 are numbered as shown in the image to the right. The ten angles (phi for the chassis, five arm joint angles, and four wheel angles) are in radians and the two chassis position coordinates (x,y) are in meters. A gripper state of 0 indicates that you want the gripper to be open, and a gripper state of 1 indicates that you want the gripper to be closed. In practice, the transition from open to closed (or from closed to open) takes up to ~~one~~ ~~second~~, so any transition from 0 to 1, or 1 to 0, on successive lines in your csv file initiates an action (opening or closing) that will take some time to complete.		Wheels 1 to 4 are numbered as shown in the image to the right. The ten angles (phi for the chassis, five arm joint angles, and four wheel angles) are in radians and the two chassis position coordinates (x,y) are in meters. A gripper state of 0 indicates that you want the gripper to be open, and a gripper state of 1 indicates that you want the gripper to be closed. In practice, the transition from open to closed (or from closed to open) takes up to 0.625 seconds, so any transition from 0 to 1, or 1 to 0, on successive lines in your csv file initiates an action (opening or closing) that will take some time to complete. You should keep the gripper state at the same value for 63 consecutive lines if you want to ensure that the opening/closing operation completes. An opening/closing operation terminates when a force limit is reached (e.g., an object is grasped) or the gripper has fully opened or closed.

	Your program will take as input:		Your program will take as input: