UP | HOME

Final Project (Fall 2023)

Important Dates

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

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. Each team will use a Franka Robot
  2. There is a possibility to use the Adroit Robot
    • Adroit does not have a ROS 2 interface, therefore part of your team will be converting the ROS 1 interface to ROS
    • Adroit weighs less than the Franka but has a larger payload

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 and Number
    • 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)?
        • Ideally working on the fallback goal and completing it successfully should set your team up to accomplish the core goal.
      • 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 or Adroit
    • List of any external equipment required that may need to be purchased.
      • You have access to all the items in the MSR lab and also the ordering sheet
    • High level overview of your approach to the project
      • Include a block diagram illustrating the interaction of the various components and subsystems
      • Third party packages to use or explore (do some research, can include moving a ROS 1 package to ROS 2 or a different ROS version!)
      • 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 role 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 divide the work evenly and have clear areas of responsibility.
        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 3 pages 8.5" x 11" paper size (this limit is strict).
      • Do not feel compelled to fill 3 pages.
    • The project proposal will be uploaded to Canvas as a PDF, one per group.
    • 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 so that they can have the project under their own github name. It is important, however, that the README credits all group members.
    • 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 .repos 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
      • This library should reside in a python file without an entry point and should be unit tested
    • 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 (both unit and integration) 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
      • The ROS API includes the publishers, subscribers, service clients/servers, action clients/servers, and parameters
    • 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)
      6. Setup Sphinx to autogenerate your html API documentation for your python package and post it on github pages.
      7. List of all group members
    • The audience for the README.md is people who know ROS but not your particular project (such as your classmates).
  4. Videos
    • You should produce a video showing your demonstration working.
    • The video should be hosted online and embedded in the README.md
    • The video can also be hosted on youtube.
  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

These still link to the ROS 1 versions…

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