UP | HOME

Final Project (Fall 2021)

Important Dates

  1. Proposal Due: November 9th, before class
  2. Final Presentation: December 6 from 3pm-5pm.
  3. Final Submission (all code and documentation on github): December 7th 12pm

Overview

Each team will develop a ROS package that enables a robot to perform an activity that they describe in their proposal. The project is open-ended, but will be judged on difficulty and reliability.

Team assignments are posted on Canvas.

Requirements

The Robot

  1. Robots available include Franka and the Adroit robot.

The Robot's Tasks

  1. The robot must interact with and change the state of something in it's environment.
  2. The robot must operate under its own power with some degree of autonomy. However, it can also take direction from a human operator.
  3. The robot must use at least one sensor to respond to an external stimulus.
  4. A human user should be able to do something to change what the robot does (without needing to program).
    • The interaction can be while the robot is running (e.g., moving a piece on a chessboard) or can be part of the setup phase (e.g., arranging puzzle pieces).
  5. Exceptions to these rules will be made at my discretion on a case-by-case basis
    • Basically, if you have a cool idea that does not satisfy all of the above let me know

The Students' Tasks

  1. Project Proposal
    • Group Name
    • Brief (1-3 sentence) description of the project.
    • Goals
      • Core goal: what does a completely working project look like?
      • Fallback goal: what is the bare-minimum proof-of-concept?
        • How can the problem be constrained to make the core goal easier?
        • What structure can you add to the environment to make tasks easier (for example using April Tags rather than computer vision)?
      • Stretch goal: if everything goes right, what do you hope to accomplish
        • What happens if you relax some assumptions to make the project more difficult?
        • Are there any features to add?
    • Robot Preference (Franka, Adroit, Either)
    • List of any external equipment required that may need to be purchased.
      • You may ask me about this before submitting your proposal so you don't write a proposal around an unobtainable item.
    • High level overview of your approach to the project
      • Third party packages to use or explore
      • Concepts that are currently unfamiliar and must be learned
      • Anything that needs to be built?
        • Some light 3D printing or laser cutting is permissible, but there is no time for significant mechanical design or fabrication.
    • Description of the proposed role for each team member
      • Every team member must have a significant software contribution and be primarily responsible for at least one subsystem
      • Every team member should also have one secondary role. This can be as a contributor to additional subsystems or some general purpose role, such as the suggestions below. The needs of each team will be slightly different: the idea is to roughly divide the work evenly.
        1. Systems Integrator: Responsible for making sure that everybody's subsystems work together, and that git workflow is followed.
        2. Reliability Engineer: Implements additional infrastructure needed to isolate and test the various subsystems.
          • Everybody on the team should contribute to testing, but this role takes the lead on testing
        3. Usability Engineer: Makes sure that the system can is easy to run with (ideally) a single launchfile. Also takes the lead on the groups' documentation
          • Everybody contributes to documentation, including with docstrings in their own code and portions of the readme. This role makes sure it all comes together and that API documentation is generated
    • Total proposal length should be under 2 pages.
    • The project proposal will be uploaded to Canvas as a PDF
    • Feel free to ask questions about the proposal on the discussion board and office hours
  2. Source Code
    • Each team must use git to develop the project.
      • The main git repository will be hosted on github classrooms, but each member is encouraged to maintain their own fork
    • The project can consist of one or more ROS packages but should be in one git repository.
    • If you rely on compiling external packages, provide a rosinstall file generated using vcs export in your main repository.
    • The project must have multiple custom nodes, launch files, topics, and services.
    • The project should have at least one python library in addition to the nodes that you need
    • Each student should work in their own branches in git. Working code should be merged into the main branch.
      • You may use any git workflow that works for your team, I suggest my simple git workflow
      • This workflow also can be used with pull-requests on github, or all users can have write access to the central repository
    • You should have automated tests using rostest and unittest for your code.
  3. Documentation
    • All source code must be documented, with a docstring at the top describing the ROS API and docstrings for each function and class
    • There should be a single README.md describing the project, which can link to other documents as needed
      • Documentation can be done as a README.md that renders nicely on github or using github pages.
    • The README.md must include:
      1. Brief project overview
      2. Quickstart guide providing the exact commands
      3. List of all nodes and launchfiles and what they do
      4. A discussion of the overall system architecture and high level concepts
      5. Any other information, as appropriate (for example: algorithms used, lessons learned, future work)
    • Setup Sphinx to autogenerate your html API documentation for your python package
      • You may include more detailed documentation in sphinx rather than README.md and simply have The README.md link to sphinx documentation hosted on github.io for example, if you wish.
      • Details about how to do this are here
  4. Videos
    • You should produce a video showing your demonstration working.
    • The video should be hosted online and embedded in your README.md
  5. Final Presentation
    • Each group member should be responsible for an approximately equal part of the presentation.
    • Presentation is 15 minutes long and should cover
      • Overview of the project
      • Discuss each subsystem
      • Challenges faced and future work
      • A live demonstration

Grading

  1. The proposal
    • Did you hand it in on time?
    • Does it concisely describe the goals of the project?
    • Does it clearly articulate the core, fallback, and stretch goals?
    • Does each student have a clear role?
  2. Group Grade: All students receive the same grade based on:
    • How well the robot worked (weighed against the complexity of the task)
    • The documentation and tests.
    • The quality of the python code and how well your package conforms to ROS standards.
    • How well git was used
  3. Grade adjustments:
    • I will get confidential feedback from each of you about your group members effort grades.
    • I will also look at the git history to see how much each individual contributed.
    • Grades may be adjusted up or down based on how your effort is perceived by your peers and demonstrated in the git history.

Inspiration

A wide range of projects is possible. While there is no theme there are often good projects in the fields of sports, games, medicine, manufacturing, fabrication, construction. You may also take inspiration from previous projects.

Potentially useful ROS Packages and Libraries

Tags

  • April Tags: Used for 3D pose estimation of a tag in space
  • AR Tags: An older form of 3D pose estimation with tags. Don't use these
  • Visual Servoing Uses vision to determine location of objects in space

Perception

Motion

Simulation

  • Franka and Adroit both have gazebo support. See their respective documentation

State Machines

  • SMACH Provides a method for creating higher level state machines. This is a useful way to organize/switch between the higher level tasks in your robot.

Additional Hardware

Virtually any hardware in the lab can be used in this project. If it is requested in your proposal we may be able to purchase additional items. If your project hinges on a purchase, please talk to me before committing to it.

Author: Matthew Elwin.