- Oct 2024
-
Local file Local file
-
LAB 1: SYSTEM ARCHITECTURE & JOINT SPACE CONTROL
I like the ideas of "to do" tables. I'd put them at the front instead though. Also maybe include fewer detail to de-densify the whole operation.
-
FOR LAB REPORT (not required for sign-off):1. Select a starting point and endpoint for the base joint and an interpolation time (at least 45degrees of motion and at least a couple of seconds). Repeat the motion at least 3 times. Includein your report a plot showing the 3 base joint movements on the same plot (they should bealmost identical but likely with small variations). There should be one plot window with threedifferent colored lines, each representing one motion. Analyze and describe what you see in themotion. Point out and try to explain any discrepancies.2. Repeat #1 above without an interpolation time. Have the robot’s base joint move from the samestart position to the same end position without interpolation at least 3 times. There should onceagain be one plot window with three different colored lines, each representing one motion.Describe what you see. How do these 3 profiles compare to each other? How about theinterpolated trajectory? Clearly, the time to get to the position will be different. What about theshape of the motion profile? When would you want to use the different motion commands?3. Include a plot of the timing histogram in milliseconds. If there are significant outliers, include asecond plot with outliers removed. Also report the mean, median, maximum, and minimumtime step for that motion.4. Pick four arbitrary poses that do not share joint values. For each pose, move the arm from thezero position to the pose using interpolate_jp and plot each joint value. You should have fourfigures, each with four subplots (one for each joint). Describe what you are showing andanything interesting observed. Include a photo of the arm in the four selected poses after therobot moves to them.5. Repeat step 4 using servo_jp and plot each movement on the same plot as the interpolatedmovement. You should have four more figures, each with four subplots (one for each joint),each with two curves (one interpolated, one uninterpolated). Comment on differences betweeninterpolation and noninterpolation.o Export the figure to a PNG. DO NOT USE SCREENSHOTS! Screenshots will result in adeduction of points.
Lab report requirements will be interlaced throughout the assignment, with a comprehensive check off table at the end.
-
4. Joint Reading & PlottingModify lab1.m or write a new MATLAB script that sends a motion command and continuously recordsall joint angles. Then, store these values into a csv file and plot the results.You should use your newly written methods from the previous step to:1. Send the robot to its Zero position2. Send the robot’s base angle from 0° to 45° (with an interpolation time of a few seconds)a. During the trajectory, continuously read the current joint positions and record theirtimestamps. Note: read as fast as possible. Only read position, not velocity.b. Store the joint positions in an nx4 array. Note: should be hundreds or more.c. Store the timestamps (in milliseconds) in an nx1 array3. Create a csv file, where each row stores a timestamp and its corresponding joint values. Includeall your csv files in your submission in Canvas.4. In your lab report, create a figure showing 4 subplots representing 4 joints (three should stayflat since we are only moving one axis). Be sure to always label all axes clearly with units andadd titles and legends to all plots as applicable.5. Create a histogram of the incremental timesteps between each reading. They should nominallybe in the couple ms range, though this will depend on your computer. If there are outliers andyou can not readily see the timing distribution, also make a second histogram plot showing a
CUT
Maybe we write the graphing for them or otherwise simplify this sign off, but this "do X task and plot it" style of sign off doesn't always serve a learning objective and generally takes a lot of time.
-
servo_jp()o Which takes a 1x4 array of joint values in degrees to be sent directly to the actuators andbypasses interpolation● interpolate_jp()o Which takes a 1x4 array of joint values and an interpolation time in ms to get there● measured_js()o Which takes two boolean values, named GETPOS and GETVEL. Only return the results forthe requested data, and set the rest to zero. This will be important because if we want tocollect position data very fast, we will not want to slow the system down by also acquiringunnecessary velocity data.o Which returns a 2x4 array that contains current joint positions in degrees (1st row) and/orcurrent joint velocities (2nd row).● setpoint_js()o Which returns a 1x4 array that contains current joint set point positions in degrees. Ifinterpolation is being used and you request this during motion, it will return the currentintermediate set point.● goal_js()o Which returns a 1x4 array that contains the end-of-motion joint setpoint positions indegrees. Note that this should be stored directly in your robot object (be sure to set it abovewhen making new setpoints), it does not need to be requested from the controller.
These would all be separated into their own code blocks with function requirements and demo instructions in text blocks above
-
Sign-off #3: Validate that your new code works fine with the robot. Show an SA the functions, themworking, and your Git log.
This sign off was a pain. It would have been easier to check if students made their robot do a little show.
Sign off 3: * Demonstrate servo_jp() by moving between two joint positions * Demonstrate interpolate_jp() by moving between the same two positions over 10 seconds * Interpolate between XXXX and YYYY over 20 seconds while printing out measured_js * Interpolate between YYYY and XXXX over 20 seconds while printing out setpoint_js * Interpolate between XXXX and YYYY over 20 seconds while printing out goal_js
-
Now, it’s time for you to collaborate with your team to develop new features by following these Gitworkflow instructions:1. Make an issue for each method (add appropriate labels)2. Assign issues to team members (each member must have at least one)3. Make a feature branch for each issue4. Develop the feature in Robot.m while committing regularly with meaningful comments5. Create a new script called lab1.m to use and test the above methods.6. Commit your final changes to your branch7. Make a pull request (PR) to the master brancha. The commit must contain “close #X” where X is the issue ID number8. Review the pull request and merge new changes into master (another member)a. On merge, all associated issues and pull requests should close9. Delete associated feature branch10. Modify or replace the .gitignore file in the repository to ignore specific file extensions, including.jpg, .png, .eps, .sav (MATLAB temporary autosave files), as well as .DS_Store file (for Macs) andanything inside the camera_calibration directory. Below is a sample .gitignore template forMATLAB. https://github.com/github/gitignore/blob/main/Global/MATLAB.gitignore11. If needed, pull new changes into your local repository
Completely out of place! This should come BEFORE the instructions on what functions to write. Students should be following these directions WHILE they write those functions. I'm moving this to sign-off 2 territory.
-
Sign-off #2: Demonstrate to an SA that your Git repository is set up properly and demonstrate that youcan use Git commands in a terminal.
This sign off needs to change a bit. I want this to become a "git practical".
Engagement marker: Student A: Add a comment to lab_1.mlx, and push it to a new branch
Students B&C: Pull student A's code, and show what happens to your file when you switch branches
-
Sign-off #1: Demonstrate to an SA that your system is configured properly and the MATLAB sample codein lab1_base.m works as expected (the command is sent to the arm and sensor data is received)
This sign off is perfect as is--maybe it's so simple it's not even necessary. Run the provided code, show me that your robot moves in an arc, that's all I need to see.
Honestly I don't even know if there are any comprehension questions I can add that align with the LOs of the course. This is just a logistical step.
-
Important: There are some classes (OM_X_arm.m and DX_XM430_W350.m) provided in therepository that the Robot class uses to work with the Dynamixel SDK. You should not need to modifythese classes for any of the labs or assignments (doing so may break things if you are not careful). Feelfree to have a look at them if you are interested, but they are not relevant to anything taught in thecourse or expected from the labs.
I might upgrade this "important" to a "warning: do NOT modify these files unless told". We're reworking the files to "accident-proof" the robots a bit, and we'd rather students not disable our protections.
-
You will start this lab with the assumption of completed Lab0.
Pre-labs are going to be a big part of at least one or two of these rewritten labs. Might be worth having a section dedicated to reminding students what they did (or should have done).
-
Procedure
Ok, this is where the procedure actually begins. Little bit deceiving that it's signified with some bold + underline 12pt text and not a proper heading.
-
The OpenManipulator-X is in its Zero Configuration, also known as “Home Configuraiton”, when all of itsrotational joint values are set to zero, as shown in Figure 2. Motors 1, 2, 3, and 4 are rotational actuatorsthat change the position and orientation of the end-effector. Gripper Motor only opens and closes thegripper and has no effect on the position and orientation of the end-effecto
Important information. I'd be more likely to read it if it were a figure caption
-
Note: The 'end-effector' refers to a point situated between the two jaws of the gripper. When aiming tograsp an object using the robot, it's crucial to ensure precise alignment of the end-effector with theobject's location. For instance, for a successful ball grasp, the end-effector must be accurately positionedat the center of the ball during the grasping operation
This paragraph is redundant and tautological
-
RBE 3001 - Lab 1 4Important
No, this is not important. If students are messing with the file these IDs are used in (even in the current version of the lab), they've seriously screwed up.
-
* The lab is a team assignment.
This lab talks a lot of talk about teamwork, but is absolutely toothless when it comes to measuring student achievement in it! Major alignment issue.
-
OBJECTIVES
I like this. The rewrite will have different objectives, but likely a similar objectives section.
-
In this lab, you will become familiar with the basic software and hardware architecture for theOpenManipulator-X. You will also use an object-oriented approach in MATLAB to write commands thatcontrol the arm and monitor its position in joint space, characterize the arm’s motion, and demonstrategood team programming practices through Git.
Good! This is how I'd introduce the lab.
In re: "Team programming": This LO needs to be HAMMERED wayyyyy harder than it's being treated by this lab doc. We need to introduce measurable objectives (e.g. commit quotas, branch requirements, reflections on who did what that reference commit IDs).
-
To meet our course objectives, the labs focus on the high-level programming in MATLAB to perform tasksrelated to the material covered in the course lectures, including joint space control, forward kinematics,inverse kinematics, trajectory generation, velocity-based control, force propagation, and vision-guidedmanipulation.
This is essentially a list of all course objectives. I agree that this should be presented in the first lab to give a roadmap, but this list doesn't provide me with much information about how these topics relate to one another and why they are in this course together.
-
INTRODUCTION
Overall comments: This section is all over the place. We bounce from "what we will be doing in this lab" to "specific robot details" to "litany of course objectives; most of which are not addressed in this lab"
-
In Lab 1, our aim is to gain a thorough understanding of the system architecture and communicationprotocols of the OpenManipulator-X robot arm. We will also be exploring its joint space control andvisualizing the output data. As set up during Lab 0, we will be using Ubuntu 20.04 LTS as the operatingsystem and MATLAB as the programming environment. The hardware relies on C/MATLAB software viathe Dynamixel SDK
This paragraph gives high level lab goals. Unfortunately, it fails to highlight any learning objective of the course! The rewrite will have a paragraph that serves the same purpose, but it will have a higher focus on LOs.
-
The OpenManipulator-X robot arm, shown in Figure 1, is a serial manipulator with four degrees-of-freedom (DoF). It consists of four DYNAMIXEL motors that rotate to control four rotational joints(providing four DoF), as well as a small gripper servo that only opens and closes the griper to allow forgrasping objects. The position of the can be modified by adjusting the positions of the four DYNAMIXELmotors. These motors are capable of position, velocity, and current control.The hardware communicates with your computer using a U2D2 board through USB serial communication.The Dynamixel SDK allows the low-level logic, between the USB port on your PC and the actuators,enabling you to easily send and receive joint-space control signals through MATLAB.
These two paragraphs introduce the robotic arm used in the class. A little more detail than is truly necessary.
-