The AutoRob course provide an introduction to core topics in the modeling and control of autonomous robots. AutoRob has two sections: an undergraduate section offered as Introduction to Autonomous Robotics (EECS 398) and a graduate section offered as Robot Kinematics and Dynamics (ME/EECS 567 or ROB 510) with expanded advanced material. The AutoRob course can be thought of as the foundation to build "brains for robots". That is, given a robot as a machine with sensing, actuation, and computation, how do we build computational models, algorithms, and program that allow the robot to function autonomously? Such computation involves functions for robots to perceive the world, make decisions towards achieving a given objective, and transforming decided actions into motor commands. These functions are essential for modern robotics, especially for mobile manipulators such as the pictured Fetch and PR2 robots.
The AutoRob course focuses on the issues of modeling and control for autonomous robots with an emphasis on manipulation and mobility. Successful completion of AutoRob will result in code modules for "mobile pick-and-place". That is, given a robot and perception of the robot's environment, resulting code modules can enable the robot to pick up an object at an arbitrary location and place the object in a new location.
You will use an actual robot (at least once)!
KinEval allows for your code to work with any robot that supports the rosbridge protocol, which includes any robot running ROS. Given a URDF description, the code your produce for AutoRob will allow you to view and control the motion of any mobile manipulation robot with rigid links. Your code will also be able to access the sensors and other software services of the robot for your continued work as a roboticist.
AutoRob is a computing-friendly pathway into robotics, but does not cover the whole of robotics. The scope of AutoRob is robot modeling and control, which is well-suited as preparation for a Major Design Experience in EECS 467 (Autonomous Robotics Laboratory). EECS 467 and ROB 550 (Robotics Systems Laboratory) provides more extensive hands-on experience with a small set of real robotic platforms. In contrast, AutoRob emphasizes the creation of a generalized modeling and control software stack in simulation, with interfaces to work with a diversity of real robots.
AutoRob provides a computation-focused version of ME 567 (Robot Kinematics and Dynamics). The common ME 567 is a more in-depth mathematical analysis of dynamics and control with extensive use of Denavit-Hartenberg parameters for kinematics. AutoRob spends more coverage on path and motion planning with use of quaternions and matrix stacks for kinematics.
AutoRob is also a complement to courses covering perception (EECS 568 Mobile Robotics, EECS 442 Computer Vision), robot building (EECS 498 Hands-on Robotics, ME 552 Mechatronics), robot simulation (ME 543 Analytical and Computational Dynamics), controls systems (EECS 460 Control Systems Analysis and Design, EECS 461 Embedded Control Systems), and artificial intelligence (EECS 492 Introduction to Artificial Intelligence), as well as general graduate courses in robotics (ROB 501 Math for Robotics, ROB 550 Robotic Systems Laboratory).
Commitment to equal opportunity
As indicated in the General Standards of Conduct for Engineering Students, this course is committed to a policy of equal opportunity for all persons and do not discriminate on the basis of race, color, national origin, age, marital status, sex, sexual orientation, gender identity, gender expression, disability, religion, height, weight, or veteran status. Please feel free to contact the course staff with any problem, concern, or suggestion. We ask that all students treat each other with respect.
Accommodations for Students with Disabilities
If you believe an accommodation is needed for a disability, please let the course instructor know at your earliest convenience. Some aspects of this course, the assignments, the in-class activities, and the way the course is usually taught may be modified to facilitate your participation and progress. As soon as you make us aware of your needs, the course staff can work with the Services for Students with Disabilities (SSD, 734-763-3000) office to help us determine appropriate academic accommodations. SSD typically recommends accommodations through a Verified Individualized Services and Accommodations (VISA) form. Any information you provide is private and confidential and will be treated as such. For special accommodations for any academic evaluation (exam, quiz, project), the course staff will need to receive the necessary paperwork issued by the SSD office by September 29, 2018.
Student mental health and well being
The University of Michigan is committed to advancing the mental health and wellbeing of its students. If you or someone you know is feeling overwhelmed, depressed, and/or in need of support, services are available. For help, please contact Counseling and Psychological Services (CAPS) by phone at 734-764-8312, during and after hours, on weekends and holidays, or through its counselors physically located in schools on both North and Central Campus. You may also consult University Health Service (UHS, 734-764-8320) as well as its services for alcohol or drug concerns. There is also a more comprehensive listing of mental health resources available on and off campus.
ocj addrsign umich
Office: Beyster 3644
Office Hours: Monday 3-5pm, Tuesday 1-3pm
Graduate Student Instructor
maithili addrsign umich
Office Hours (Beyster 1637): Tuesday 1-3pm, Wednesday 3-4:30pm
Monday, Wednesday 1:30-2:40 MMT (Michigan Mean Time)
Note: General course discussion and administrivia will be addressed in the #general channel. Each assignment will have its own discussion channel. Random items of general interest to the course and larger field of robotics will appear in the #random channel. Actively engaging in course discussions is a great way to become a better roboticist.
This course has recommended prerequisites for "Linear Algebra" and "Data Structures and Algorithms", or permission from the instructor.
Programming proficiency: EECS 281 (Data Structures and Algorithms), EECS 402 (Programming for Scientists and Engineers), or proficiency in data structures and algorithms should provide an adequate programming background for the projects in this course. Interested students should consult with the course instructor if they have not taken EECS 281, EECS 402, or its equivalent, but have some other notable programming experience.
Mathematical proficiency: Math 214, 217, 417, 419 or proficiency in linear algebra should provide an adequate mathematical background for the projects in this course. Interested students should consult with the course instructor if they have not taken one of the listed courses or their equivalent, but have some other strong background with linear algebra.
Recommended optional proficiency: Differential equations, Computer graphics, Computer vision, Artificial intelligence
The instructor will do their best to cover the necessary prerequisite material, but no guarantees. Linear algebra will be used extensively in relation to 3D geometric transforms and systems of linear equations. Computer graphics is helpful for under-the-hood understanding of threejs. Computer vision and AI share common concepts with this course. Differential equations are used to cover modeling of motion dynamics and inverse kinematics, but not explicitly required.
The AutoRob course is compatible with both the Spong et al. and Corke textbooks (listed below), although only one of these books is needed. Depending on individual styles of learning, one textbook may be preferrable over the other. Spong et al. is the listed required textbook for AutoRob (as well as ME 567) and is supplemented with additional handouts. The Corke textbook provides broader coverage with an emphasis on intuitive explanation. A pointer to the Lynch and Park textbook is provided for an alternative perspective on robot kinematics that goes deeper into spatial transforms in exponential coordinates. Lynch and Park also provides some discussion and context for using ROS. This semester, AutoRob will not officially support the Lynch and Park book, but will make every effort to work with students interested in using this text.
Robotics, Vision and Control: Fundamental Algorithms in MATLAB
Modern Robotics: Mechanics, Planning, and Control
Kevin M. Lynch, Frank C. Park
Cambridge University Press, 2017
O'Reilly Media / Yahoo Press, 2008
Principles of Robot Motion
Howie Choset, Kevin M. Lynch, Seth Hutchinson, George A. Kantor, Wolfram Burgard, Lydia E. Kavraki, and Sebastian Thrun
MIT Press, 2005
Projects and Grading
The AutoRob course will assign 7 projects (6 programming, 1 oral) and 5 quizzes. Each project has been decomposed into a collection of features, each of which is worth a specified number of points. AutoRob project features are graded as “checked” (completed) or “due” (incomplete). Prior to being assigned, upcoming projects will have the status of "pending." In terms of workload, each project is expected to take approximately 4 hours of work on average (as a rough estimate). Each quiz will consist of 4 short questions that will be within the scope of previously graded projects. In other words, each quiz question should be readily answerable given knowledge from correctly completing projects on time.
Individual final grades are assigned based on the sum of points earned from coursework (detailed in subsections below). The timing and due dates for course projects and quizzes will be announced on an ongoing basis. All project work must be checked by the end of classes.
EECS 398: Introduction to Autonomous Robotics
In the undergraduate section, each fully completed project is weighted as 12 points and each correctly answered quiz question is weighted as 1 point. Based on this sum of points from coursework, an overall grade for the course is earned as follows: An "A" grade in the course is earned if graded coursework sums to 93 points or above; A "B" grade in the course is earned if graded coursework sums to 83 points or above; a "C" grade in the course is earned if graded coursework sums to 73 points or above. The instructor reserves the option to assign appropriate course grades with plus or minus modifiers.
ME 567 | EECS 567 | ROB 510: Robot Kinematics and Dynamics
In the graduate section, each fully completed project is weighted as 18 points, each correctly answered quiz question is weighted as 1 point. Students in this section have the opportunity to earn 4 additional points through an advanced extension of a course project. Examples of advanced extensions include implementation of an LU solver for linear systems of equations, inverse kinematics by Cyclic Coordinate Descent, one additional motion planning algorithm, point cloud segmentation, and a review of a current research publication in robotics. Based on this sum of points from coursework, an overall grade for the course is earned as follows: An "A" grade in the course is earned if graded coursework sums to 135 points or above; A "B" grade in the course is earned if graded coursework sums to 120 points or above; a "C" grade in the course is earned if graded coursework sums to 105 points or above. The instructor reserves the option to assign appropriate course grades with plus or minus modifiers.
Project Rubric (tenative and subject to change)
The following project features are planned for AutoRob this semester. Students enrolled in ME/EECS 567 will complete all features. Students in the undergraduate section are not expected to implement features for the graduate section.
|Assignment 1: 2D Path Planning|
|Assignment 2: Pendularm|
|4||All||Velocity Verlet integrator|
|Assignment 3: Forward Kinematics|
|2||All||Core matrix routines|
|2||Grad||Base offset transform|
|4||Grad||Fetch DH table|
|Assignment 4: Dance Controller|
|6||All||Quaternion joint rotation|
|2||All||Interactive base control|
|2||All||Pose setpoint controller|
|2||Grad||Fetch rosbridge interface|
|Assignment 5: Inverse Kinematics|
|3||All||Gradient descent with Jacobian transpose|
|6||Grad||Euler angle conversion|
|Assignment 6: Motion Planning|
|6||All||Configuration space RRT-Connect|
Project Submission and Regrading
Git repositories will be used for project implementation, version control, and submission. The implementation of an individual project is submitted through an update to the master branch of your designated repository. Updates to the master branch must be committed and pushed prior to the due date for each assignment for any consideration of full credit. Your implementation will be checked out and executed by the course staff. Through your repository, you will be notified by the course staff whether your implementation of assignment features is sufficient to receive credit.
Do not submit assignments late. The course staff reserves the right to not grade late submissions. The course instructor reserves the right to decline to grade late submissions and adjust partial credit on regraded assignments. If granted by the course instructor, late submissions can be graded for partial credit, with a guideline as follows. Submissions pushed within two weeks past the project deadline will be graded for 80% credit. Submissions pushed within four weeks of the project deadline will be graded for 60% credit. Submissions pushed at any time before the semester project submission deadline (December 14, 2018) will be considered for 50% credit. The course instructor reserves the right to decline to grade late submissions and adjust partial credit on regraded assignments.
The regrading policy allows for submission and regrading of projects up through the final grading of projects, which will be December 18 for the Fall 2018 Semester. This regrading policy will grant full credit for project submissions pushed to your repository before the corresponding project deadline. If a feature of graded project is returned as not completed (or "DUE"), your code can updated for consideration at 80% credit. This code update must be pushed to your repository within two weeks from when the originally graded project was returned. Regrades of projects updated beyond this two week window can receive at most 60% credit.
All grading will be finalized on December 14, 2018. Regrading of specific assignments can be done upon request during office hours. No regrading will be done after grades are finalized.
You are expected to provide a private git repository for your work in this course with the course instructor added as a read/write collaborator. If needed, the course staff can assist in the setup of an online git repository through providers such as github or bitbucket, or internally through the EECS gitlab server.
There are many different tutorials for learning how to use git repositories. The AutoRob course site has its own basic quick start tutorial. The EECS gitlab server has a basic quick start tutorial. The Pro Git book provides an in-depth introduction to git and version control. As different people often learn through different styles, the Git Magic tutorial has also proved quite useful when a different perspective is needed. git: the simple guide has often been a great and accessible quick start resource.
We expect students to use these repositories for collaborative development as well as project submission. It is the responsibility of each student group to ensure their repository adheres to the Collaboration Policy and submission standards for each assignment. Submission standards and examples will be described for each assignment as needed.
This collaboration policy covers all course material and assignments unless otherwise stated. All submitted assignments for this course must adhere to the Michigan Honor License (the 3-Clause BSD License plus two academic integrity clauses).
Course material, concepts, and documentation may be discussed with anyone. Discussion during and examination or quiz is not allowed with anyone other than a member of the course staff. Assignments may be discussed with the other students at the conceptual level. Discussions may make use of a whiteboard or paper. Discussions with others (or people outside of your assigned group) cannot include writing or debugging code on a computer or collaborative analysis of source code that is not your own. You may take notes away from these discussions, provided these notes do not include any source code.
The code for your implementation may not be shown to anyone outside of your group, including granting access to repositories or careless lack of protection. You do not need to hide the screen from anyone, but you should not attempt to show anyone your code. When you are done using any robot device such that another group may use it, you must remove all code you have put onto the device. You may not share your code with others outside of your group. At any time, you may show others the implemented program running on a device or simulator, but you may not discuss specific debugging details about your code while doing so.
This policy applies not only applies to collaboration during the current semester, but also any past or future instantiations of this course. Although course concepts are intended for general use, your implementation for this course must remain private after the completion of the course. It is expressly prohibited to share any code previously written and graded for this course with students currently enrolled in this course. Similarly, it is expressly prohibited for any students currently enrolled in this course to refer to any code previously written and graded for this course.
To acknowledge compliance with this collaboration policy, append your name the file "LICENSE" in the main directory of your repository with the following text. This appending action is your attestation of your compliance with the Michigan Honor License and the Michigan Honor Code statement:
"I have neither given nor received unauthorized aid on this course project implementation, nor have I concealed any violations of the Honor Code."
This attestation of the honor code will be considered updated with the current date and time of each commit to your repository. Repository commits that do not attestation of the honor code not be graded as the discretion of the course instructor.
Should you fail to abide by this collaboration policy, you will receive no credit for this course. The University of Michigan reserves the right to pursue any means necessary to ensure compliance. This includes, but is not limited to prosecution through The College of Engineering Honor Council, which can result in your suspension or expulsion from the University of Michigan. Please refer to the Engineering Honor Council for additional information.
Course Schedule (tentative and subject to change)Note: Assignment descriptions will have updated assignment due dates. Assignment due dates listed in the schedule are merely a guide.
Course overview, Robotics roadmap, Path planning quick start
|Setup git repository|
What is a robot?:
Brief history and definitions for robotics
Path Planning: DFS, BFS, A-star, Greedy best first
Addendum: DFS example
|Wikipedia||Out: Path Planning|
Addendum: coding workflow
Pendulum Simulation and Numerical Integration: Lagrangian equation(s) of motion, Initial value problem, Explicit integrators: Euler, Verlet, and Runge-Kutta 4
Spong Ch.7 | Corke Ch.9
Witkin&Baraff 1998: Dynamics
Witkin&Baraff 1998: Integrators
Motion Control: Cartesian vs. generalized coordinates, open-loop vs. closed-loop control, PID control; Rigid body dynamics
Linear Algebra Refresher: Systems of linear equations, vector spaces and operations, least squares approximations
|Sep 24||Course meeting cancelled - off-site meeting||Due: Path Planning
|Sep 26||Quiz 1|
Forward Kinematics: Kinematic chains, URDF, homogeneous transforms, matrix stack traversal, D-H convention
|Oct 3||Axis-angle Rotation and Quaternions: Motors, Euler angles, gimbal lock, Rodrigues rotation, rotation in complex spaces, Dual quaternions and screw coordinates||
Reactive Controllers: Reactive and Deliberative Decision Making, Finite State Machines, Subsumption Architecture
||Brooks 1986||Due: Pendularm
Out: Forward Kinematics
|Oct 10||Quiz 2||IK robot game|
|Oct 15||No course meeting - Fall Study Break|
Inverse Kinematics 1 - Closed-form: Joint vs. Endeffector control, Planar 2-link arm, Closed form solutions, Cyclic Coordinate Descent
|Oct 22||Course meeting cancelled - off-site meeting||Due: Forward Kinematics
Out: Dance Contest
|Oct 24||Inverse Kinematics 2 - Iterative: Gradient descent, Manipulator Jacobian, Jacobian transpose, pseudoinverse||Spong Ch. 4, Wang, Chen 1991, Buss 2009
Corke Ch. 8
Robot Middleware: Hardware Abstraction, ROS, LCM, Publish-subscribe messaging, rosbridge, Client-server messaging
||Quigley 2009, Huang 2010, Toris 2015|
|Oct 31||Bug Algorithms: Reaction vs. Deliberation revisted, Bug[0-2], Tangent Bug||Corke Ch. 5|
|Nov 5||Configuration Spaces: Curse of dimensionality, Configuration space vs. Workspace, Minkowski planning, Costmaps, Holonomicity||Due: Dance Contest
Out: Inverse Kinematics
|Nov 7||Quiz 3|
|Nov 12||Sample-based Planning: Probabilistic roadmaps, RRT-based motion planning||Kavraki et al. 1996, Kuffner, LaValle 1999|
|Potential fields: Gradient descent revisited, local search, downhill simplex, Wavefront planning||Khatib 1986, Jarvis 1993, Zelinsky 1992|
|Nov 14||Collision Detection: 3D Triangle-Triangle Testing, Oriented Bounding Boxes, Axis-Aligned Bounding Boxes, Separating Axis Theorem||Gottschalk et al. 1996, Moller 1997|
|Nov 19||Quiz 4||Due: Inverse Kinematics
Out: Motion Planning
|Nov 21||Course meeting cancelled - Thanksgiving Recess|
|Nov 26||ROS/catkin tutorial session||Example tutorial result|
|Nov 28||3D Point Cloud Segmentation: Point cloud segmentation, Principal Components Analysis, Connected components||
Rusu 2008 (Sec 4.2)
|Dec 3||Localization and Mapping Overview: Bayes rule, Bayesian filtering, Monte Carlo Localization, Factor Graphs, SGD-SLAM, Scene estimation||Dellaert 1999
|Dec 5||Quiz 5||Due: Motion Planning|
|Dec 10||Due: Best Use of Robotics|
|Dec 14||Grading finalized|
Slides from this course borrow from and are indebted to many sources from around the web. These sources include a number of excellent robotics courses at various universities.
Assignment 1: Path Planning
Due 1:20pm, Monday, September 24, 2018
For this assignment, you will implement the planning part of autonomous navigation as an A-star graph search algorithm. A-star infers the shortest path from a start to a goal location in an arbitrary 2D world with a known map (or collision geometry). This A-star implementation will consider locations in a uniformly space grid. You will implement a heap data structure as a priority queue for visiting these locations.
If properly implemented, the A-star algorithm should produce the following path (or path of similar length) using the provided code stencil:
Cloning the Stencil Repository
The first step for completing this project (and all projects for AutoRob) is to clone the KinEval stencil repository. The appended git quick start below is provided those unfamiliar with git to perform this clone operation, as well as commiting and pushing updates for project submission. IMPORTANT: the stencil repository should be cloned and not forked.
Throughout the KinEval code stencil, there are markers with the string "STENCIL" for code that needs to be completed for course projects.
Heap Sort Tutorial
Opening "heapsort.html" will show the result of running the incomplete heap sort implementation provided by the code stencil:
To complete the heap sort implementation, complete the heap implementation in heap.js at the locations marked "STENCIL". In addition, the inclusion of heap.js in the execution of the heap sort will require modification of heapsort.html.
A successful heap sort implementation will show the following result for a randomly generated set of numbers:
Graph Search Stencil
There are five planning scenes that have been provided within this code stencil: "empty", "misc", "narrow1", "narrow2", and "three_sections". The choice of planning_scene can be specified from the URL given to the browser, described in the usage in the file. For example, the URL "search_canvas.html?planning_scene=narrow2" will bring up the "narrow2" planning world. Other execution parameters, such as start and goal location, can also be specified through the document URL.
This code stencil is implemented to perform graph search iterations interactively in the browser. The core of the search implementation is performed by the function iterateGraphSearch(). This function performs a graph search iteration for a single location in the A-star execution. The browser implementation cannot use a while loop over search iterations, as in the common A-star implementation. Such a while loop would keep control within the search function, and cause the browser to become non-responsive. Instead, the iterateGraphSearch() gives control back to the main animate() function, which is responsible for updating the display and user interaction.
Within the code stencil, you will complete the functions initSearchGraph() and iterateGraphSearch() as well as add functions for heap operations. Locations in "search_canvas.html" where code should be added are labeled with the "STENCIL" string. In initSearchGraph() creates a 2D array over locations to be searched. Each element of this array contains various information computed by the search algorithm for a particular location. iterateGraphSearch() should use three of the provided functions to perform a search iteration. testCollision() returns a boolean of whether a given 2D location, as a two-element vector, is in collision with the planning scene. draw_2D_configuration() draws a square at a given location in the planning world to indicate that location has been explored. Once the search is complete, drawHighlightedPathGraph() will render the path produced by the search algorithm between a given location and the start location. The global variable search_iterate should be set to false to end animation loop.
Graduate Section Requirement
In addition to the A-star algorithm, students in the graduate section of AutoRob must additionally implement path planning by Depth-first search, Breadth-first search, and Greedy best-first search. An additional report, as file "report.html", is required that: 1) shows results from executing every search algorithm with every planning world for various start and goal configurations and 2) synthesizes these results into coherent findings about these experiments.
Advanced extensions can be submitted anytime before the final grading is complete. Concepts for several of these extensions will not be covered until later in the semester.
Of the 4 possible advanced extension points, two additional points for this assignment can be earned by implementing the Bug0, Bug1, Bug2, and TangentBug navigation algorithms. This bug algorithm implementation should be contained within the file "search_canvas.html" under the "project_pathplan" directory.
Of the 4 possible advanced extension points, two additional points for this assignment can be earned by implementing navigation by potential fields and navigation using the Wavefront algorithm. This potential-based navigation implementation should be contained within the file "search_canvas.html" under the "project_pathplan" directory.
Of the 4 possible advanced extension points, one additional point for this assignment can be earned by implementing a navigation algorithm using a probabilistic roadmap. This roadmap algorithm implementation should be contained within the file "search_canvas.html" under the "project_pathplan" directory.
Of the 4 possible advanced extension points, one additional point for this assignment can be earned by implementing costmap functionality using morphological operators. Based on the computed costmap, the navigation routine would provide path cost in addition path length for a successful search.
For turning in your assignment, ensure your completed project code has been committed and pushed to the master branch of your repository.
To ensure proper submission of your assignments, please do the following:
confirm with the course instructor (ocj addrsign umich) with your name, email address, and pointer to your repository,
ensure the instructor (id:ohseejay) has push/admin access to your repository, which can be confirmed/addressed through email or office hours (or by seeing that the instructor has committed the file "grading.txt")
You are encouraged to update your repository often using branching. The master branch should be used for the working (or stable) version of your code. For development, you can create an Assignment-1 branch can be created for your work on this project as it in development and experimentation. Similarly, an Assignment-2 branch can be created for the next project as it develops. Once you complete an assignment, the code from this branch can then be merged into the master branch for grading. This configuration allows your work to be continually updated and build upon such that versions are tracked and interruptions due to grading are minimized.
Material beyond this point has not been assigned. The descriptions below are unofficial and tentative.
Assignment 2: Pendularm
Due 1:20pm, Monday, October 8, 2018
Physical simulation is widely used across robotics to test robot controllers. Testing in simulation has many benefits, such as avoiding the risk of damaging a (likely expensive) robot and faster development of controllers. Simulation also allows for consideration of environments not readily available for testing, such as interplanetary exploration (as in the example below for the NASA Space Robotics Challenge). We will now model and control our first robot, the Pendularm, to achieve an arbitrary desired setpoint state.
As an introduction to building your own robot simulator, your task is to implement a physical dynamics and servo controller for a simple 1 degree-of-freedom robot system. This system is 1 DOF robot arm as a frictionless simple pendulum with a rigid massless rod and idealized motor. A visualization of the Pendularm system is shown below. Students in the graduate section will extend this system into a 2-link 2-DOF robot arm, as an actuated double pendulum.
Assignment 3: Forward KinematicsDue 1:20pm, Monday, October 22, 2018
Forward kinematics (FK) forms the core of our ability to purposefully control the motion of a robot arm. FK will provide us general formulation for controlling any robot arm to reach a desired configuration, and execute a desired trajectory. Specifically, FK allows us to predict the spatial layout of the robot our 3D world given a configuration of its joints. For the purposes of grasping and dexterous tasks, FK gives us the critical ability to predict the location of the robot's hand (i.e., endeffector). As shown in our IROS 2017 video below, such manipulation assumes a robot has already perceived its environment as scene estimate of objects and their position and orientation. Given this scene estimate, a robot controller uses FK to evaluate and execute viable endeffector trajectories for grasping and manipulating an object.
In this assignment, you will render the forward kinematics of an arbitrary robot, given an arbitrary kinematic specification. A collection of specifications for various robots is provided in the "robots" subdirectory of the KinEval code stencil. These robots include the Rethink Robotics' Baxter and Sawyer robots, the Fetch mobile manipulator, and a variety of example test robots, as shown below. To render the robot properly, you will compute matrix coordinate frame transforms for each link and joint of the robot based on the parameters of its hierarchy configuration. The computation of the matrix transform for each joint and link will allow KinEval's rendering support routines to properly display the full robot. We will assume the joints will remain in their zero position, saving joint motion for the next assignment.
The "robots/robot_crawler.js" example should produce the following (shown with joint axes highlighted):
A proper implementation for fetch.urdf.js description should produce the following (shown with joint axes highlighted):
Assignment 4: Robot FSM Dance ContestDue 1:20pm, Monday, November 5, 2018
Executing choreographed motion is the most common use of current robots. Robot choreography is predominantly expressed as a sequence of setpoints (or desired states) for the robot to achieve in its motion execution. This form of robot control can be found among a variety of scenarios, such as robot dancing (video below), GPS navigation of autonomous drones, and automated manufacturing. General to these robot choreography scenarios is a given setpoint controller (such as our PID controller from Pendularm) and a sequence controller (which we will now create).
For this assignment, you will build your own robot choreography system. This choreography system enable a robot to execute a dance routine by adding motor rotation to its joints and creating a Finite State Machine (FSM) controller over pose setpoints. Your FK implementation will be extended to consider angular rotation about each joint axis using quaternions for axis-angle rotation. The positioning of each joint with respect to a given pose setpoint will be controlled by an simple P servo implementation (based on the Pendularm assignment). You will implement an FSM controller to update the current pose setpoint based on the robot's current state and predetermined sequence of setpoints. For a single robot, you will choreograph a dance for the robot by creating an FSM with your design of pose setpoints and an execution sequence.
This controller for the "mr2" example robot was a poor attempt at robot Saturday Night Fever (please do better):
This updated dance controller for the Fetch robot is a bit better, but still very far from optimal:
Assignment 5: Inverse Kinematics
Due 1:20pm, Monday, November 19, 2018
Although effective, robot choreography in configuration space is super tedious and inefficient. This difficulty is primarily due to posing each joint of the robot at each setpoint. Further, changing one joint often requires updating several other joints due to the nature of kinematic dependencies. Inverse kinematics (IK) offers a much easier and efficient alternative. With IK implemented, we only need to pose the endeffector in a common workspace, and the states of the joints in configuration space automatically inferred. IK is also important when we are about the "tool tip" of an instrument being used by a robot. One such example is a robot using marker to draw a picture, such as in the PR2 Portrait Bot Project below:
For this assignment, you will now control your robot to reach to a given point in space through inverse kinematics for position control of the robot endeffector. Inverse kinematics will be implemented through gradient descent optimization with both the Jacobian Transpose and Jacobian Pseudoinverse methods, although only one will be invoked at run-time.
As shown in the video below, if successful, your robot will be able to continually place its endeffector (indicated by the blue cube) exactly on the reachable target location (indicated by the green cube), regardless of the robot's specific configuration:
Assignment 6: Motion Planning
Due 11:59pm, Friday, December 7, 2018
Our last project for AutoRob returns to search algorithms for generating navigation setpoints, but now for a high-dimensional robot arm. The A-star graph search algorithm in Project 1 is a good fit for path planning given the space to explore is limited to two degrees-of-freedom for a robot base. However, as the number of degree-of-freedom of our robot increases, our search complexity will grow exponentially towards intractability. For such high-dimensional search problems, we now look to sampling-based search algorithms. These sampling-based algorithms trade off the guarantees and optimality of exhaustive graph search for viably tractable planning in complex environments. The example below shows one example of sample-based planning navigating to move a rod through a narrow passageway:
and such planning is also used in simple tabletop scenarios:
For this assignment, you will now implement a collision-free motion planner to enable your robot to navigate from a random configuration in the world to its home configuration (or "zero configuration"). This home configuration is where every robot DOF has a zero value. For planning, configuration space includes the state of each joint and the global orientation and position of the robot base. Thus, the robot must move to its original state at the origin of the world. Motion planning will be implemented through the RRT-Connect algorithm (described by Kuffner and LaValle).
The graduate section will additionally implement the RRT-Star motion planner of Karaman et al. (ICRA 2011).
Even before your planner is implemented, you can use the collision system interactively with your robot. The provided kineval.robotIsCollision() function will test the current configuration of the robot. When the robot is detected to be in collision, one of the colliding links will be highlighted with a red wireframe. There could be many links in collision, but only one will be highlighted.
Assignment 7: The best use of robotics?
Slides due 11:59pm, Friday, December 7, 2018
Presentation due 1:30pm, Monday, December 10, 2018
Scenario: An investor is considering giving you 20 million dollars (cold hard USD cash, figuratively). This investor has been impressed by your work with KinEval and other accomplishments while at the University of Michigan. They are convinced you have the technical ability to make a compelling robot technology... but, they are unsure how this technology could produce something useful. Your task is to make a convincing pitch for a robotics project that would yield a high return on investment, as measured by some metric (financial profit, good for society, creation of new knowledge, etc.).
The pitch judged to be the most convincing will get first dibs.
Appendix: Git-ing Started with Git
Using version control effectively is an essential skill for both the AutoRob course and, more generally, contributing to advanced projects in robotics research and development. git is arguably the most widely used version control system at current. Examples of the many robotics projects using git include: Lightweight Communications and Marshalling, the Robot Operating System, Robot Web Tools, Fetch Robotics, the NASA Robonaut 2, and the Rethink Baxter. To help you use git effectively, the course staff has added the tutorials below for getting started with git. This is meant to be a starting guide to using git version control and the bash command shell. For a more complete list of commands and features of git, you can refer to the following guides: The Git Pro book or The Basic git command line reference for windows users. An interactive tutorial for git is available at LearnGitBranching.
The AutoRob course assumes git is used from an command line terminal to work with a git hosting service, such as GitHub or Bitbucket. Such terminal environments are readily available in Linux and Mac OSX through their respective terminal programs. For MS Windows, we are recommending Git Bash, which can be downloaded from the Git for Windows project. Several other viable alternatives git clients exist, such as the GUI-based GitKraken.
git can be installed on Linux through a common package managment system, based on your distribution, with one of the following commands:
sudo yum install git-all
sudo apt-get install git-all
If you have a command line terminal running, you should see a shell environment that looks something like this (screenshot from an older version of Git Bash):
If you have git installed, you should should be able to enter the "git" command and see the following usage information printed (screenshot from OSX):
Cloning your repository
The most common thing that you will need to do is pull and push files from and to your git hosting service. Upon opening Git Bash, you will need to go to the location of both your GitHub/Bitbucket repository on the web and your git workspace on your local computer. Our first main step is to clone your remote repository onto your local computer. Towards this end, the next step is to open your terminal application and determine your current directory, assuming you will use this directory to create a workspace. For Linux and OSX, the terminal should start in your home directory, often "/home/username" or "/Users/username". For Git Bash on Windows, the default home directory location could be the Documents in your user directory, or the general user folder within "C:\Users".
From your current directory, you can use Bash commands to view and modify the contents of directories and files. You can see a list of the files and folders that can be accessed using ls (list) and change the folder using the command cd (change directory) as shown below. If you believe that the directory has files in addition to folders, but would like a list of just the folders, then the command ls –d */ can be used instead of ls. Below is a quick summary of relevant Bash commands:
- "ls" prints a listing of files in the current directory
- "pwd" prints the location of the current directory in the filesystem
- "cd [NameFolder]" moves the terminal to a new directory in the filesystem
- "ls [Expression]" prints a listing of files in the current directory matching the given Expression; ls r* prints all files starting with the character 'r'
- "mkdir [NameFolder]" creates a folder within the current directory. If the folder name has spaces, then NameFolder will need to be in double quotes.
- "rmdir [NameFolder]" removes a specified empty folder. If it is not empty, the folder will not be removed.
- "rm –rf [NameFolder]" removes a specified folder and all the contents
- "touch [FileName]" creates a single empty text file
- "touch [FIleName1.txt] [FileName2.txt]..." creates multiple empty text files
- "rm [FileName]" removes a specific file from the current directory
- "rm –i
"rm –v [FileName]" removes the file and reports in console
You are now ready to clone a copy of your remote repository and populate it with files for AutoRob projects. It assumed that you have already created a repository on your git hosting service, given the course staff access to this repository, and provided a link of your repository to the course staff. This repository link (in the form of "https://github.com/user_name/repository_name.git") will now be used to clone a copy of your remote repository onto your local machine using the following git command below. This command will clone the repository contents to a subdirectory labeled with the name of the repository:
git clone [repository URL link]
This directory should be listed and inspected to ensure it has been cloned with the contents of the repository, matching the remote repository from your git hosting service. If this is a new repository, it is not problem for this directory to be empty:
You can also check for differences between the files on your computer and the remote repository using git status as shown below. If you receive the message shown in the example below, then there are no differences. If there are differences, then it will have the number of files which are different highlighted in red.
$ git status On branch master Your branch is up-to-date with 'origin/master'. nothing to commit, working directory clean
Important: workspace is not the same as repository
You should now have a local copy of your repository with a workspace in a subdirectory. It is critical to note that your local repository is different than the subdirectory with your current workspace. Your workspace is not automatically tracked by the version control system and considered ephemeral. Any changes made to your workspace must be committed back into the local repository to be recognized by the version control system. Further, any changes committed to your local repository must also be pushed remotely to be recognized by your git hosting service. Thus, any changes made to your workspace can be lost if not committed and pushed, which will be discussed more in later sections.
Populating your repository with project stencil code
In a separate directory, clone the kineval-stencil repository to a subdirectory on your local machine:
cd [home_directory] git clone firstname.lastname@example.org:autorob/kineval-stencil.git
Inspect this directory to ensure it has been cloned with the contents of the repository:
cd kineval-stencil ls
and open "home.html" from this directory in a web browser and ensure you see the starting point picture below:
If your browser throws an error when loading "home.html", one potential cause is that this browser disallows loading of local files. In such cases, the browser will typically report a security error in the console. This security issue is avoided by serving the KinEval files from an HTTP server. Such a HTTP server is commonly available within distributions for modern operating systems. Assuming Python is installed on your computer, you can start a HTTP with the following command from your workspace directory, and then view the page at localhost:8000:
python -m SimpleHTTPServer
Alternatively, if you have nodejs installed, you can install and start a HTTP with the following command from your workspace directory, and then view the page at localhost:3000:
npm install simple-server node simple-server
Once you are able to load and view "home.html", the next step is to copy the kineval-stencil files to the directory with your workspace
cd [home directory] cp -r kineval-stencil/* [repository_name]/
IMPORANT: ensure that this copy from kineval-stencil to your repository does not include the ".git" subdirectory. The ".git" subdirectory is the actual git repository on your local computer, where as the directory itself is your (ephemeral) workspace outside of git.
As these copied files are new to your working repository, they need to be added to the repository to ensure they are tracked for version control. These files are added with the following commands:
cd [repository name] git add *
Below is a more detailed summary of git commands for adding files from your workspace to your repository:
- "git add" adds changed files to the next commit. There are several different options which can follow this command.
- "git add –A: adds all new files and changes to the next commit including deletions
- "git add ." adds all new files and changes to the next commit without deletions
- "git add –u" adds all changes to the next commit without new files
Commit and push to update your repository
Whenever you make any significant changes to your repository, these changes should be committed to your local repository and pushed to your remote repository. Such changes can involve adding new files or modifying existing files in your local workspace. For such changes, you will first commit changes from your workspace to your local repository using the git commit command:
git commit -a -m "message describing changes"
and then pushing these changes from your local repository to a synced repository on your git hosting service:
This commit will occur to the "master" branch of your repository.
Note: the change files must be located in the correct repository folder on your local computer and these commands should be performed in the local workspace directory. Below is a more detailed summary of git commands for adding files from your workspace to your repository:
- "git commit" commits files with changes. There are several options that can follow this. The message text is required and is good practice to list changes that you have made. GitHub is good at tracking changes.
- "git commit [FileName] -m 'Message'" commits changes to a specific file
- "git commit –a “Message'" commits all files changed since last commit
- "git commit –a –m “Message'" commits all files changed since last commit but not new files
- "git push" pushes the committed changes to remote repository
Once you have committed and pushed, your local workspace becomes redundant as your changes have been stored and tracked remotely. The local workspace can now be deleted without concern. This local workspace can also be updated with changes to the remote repository by pulling.
Pulling remote changes
Changes be made to your remote repository, potentially by other collaborators, without being tracked by your local repository. This can lead to potential versioning conflicts when committed changes contradict each other. For the AutoRob course, versioning conflicts should not be a problem because commits to your repository should be yours alone. That said, one good practice is to ensure your workspace, local repository, and remote repository are synced before making any changes. A brute force method for doing this is to re-clone your repository each time you begin to make changes. Another option is to pull remote changes into your local repository and workspace using the git pull command (or git fetch command):
cd [repository_name] git pull
Below is a more detailed summary of git commands for pulling and fetching:
- "git pull [RemoteName]" is used for retrieving commits and merging the files to what is already on the computer. This may make changes to the files that are already there; effectively, this is a fetch followed by a merge. If you need to pull directly from the repository which already exists and has been accessed through the change directory command, then you do not list a [RemoteName].
- "git fetch
" used for retrieving commits from a repository that does not already exist on the user’s computer. This creates an exact copy of the files to your local repository and not to the workspace.
Branching is an effective mechanism for work in a repository to be done in parallel with changes merged at a later point. A branch essentially creates a copy of your work at a particular version. Branches are independently tracked by the version controller and can be merged together when requested (which collaboratively results in a "pull request"). The larger story for branching and merging is outside the scope of AutoRob.
The working version of your code, which you submit for grading, is expected to be in the "master" branch of your repository. When working on a new assignment, it is recommend that you create a branch for this new work. This allows your stable code in the master branch to be undisturbed while you continue to modify your code. Once your work for this assignment is done, you can then update your master by merging in your assignment branch. Stylistically, it is helpful to use the name Assignment-X for your assignment branch for Project number X.
The simplest means for branching in this context is to use the branching feature from the webpage of your remote repository. From GitHub, simply select the master branch from the "Branch: " button and enter the name of the branch to be created. From Bitbucket, select the "Branches" icon from the left hand toolbar and follow the instructions for branch creation. If successful, you should see a list of branches that can each be inspected for their respective contents. Branches can also be deleted from this interface.
A branch can also be created from the command line by the following, which will create a copy of the current branch:
git branch [branch_name]
You can switch between branches with the following command:
git checkout [branch_name]
as well as clone a specific branch from a repository:
git clone -b [branch_name] [repository URL link]
Good luck and happy hacking!