Final Project

A wide range of projects is possible, so it is up to your team to come up with an idea. 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, but may not repeat a project from the last 3 years: there must be a substantive difference between what a previous team did and what you intend to do.

The project proposal shall contain the following:

• 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 That Will Be Used.
  • The default choice is the Franka Arm.
• List of any additional equipment required that you may need.
  • You have access to all the items in the MSR lab and also the MSR ordering sheet.
  • Items that you purchase should have a short lead time.
  • You may discuss purchases of important equipment before the proposal is due so we can order it sooner.
• High level overview of your approach to the project
  • Your project should be divided into several subsystems
  • Include a block diagram illustrating the interaction between these subsystems
  • List some 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!)
  • Identify 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 software 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
     • Ensures that code is integrated together frequently using the simple git workflow
     • Responsible for ensuring that all team-members agree and understand the overall system design
  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 and helps decide what needs to be tested.
     • All tests should pass
  3. DevOps Engineer:
     • Makes sure that the system can is easy to run with (ideally) a single launchfile.
     • Ensures that the package builds cleanly with colcon and that dependencies can easily be installed via rosdep and vcstool
     • Ensures that the README.md provides enough information so that one of your classmates can run the demonstration.
  4. Code Hygienist:
     • Ensures that all code is properly commented (everyone should contribute to the comments).
     • Ensures that API documentation is properly generated with rosdoc2
     • Can configure flake8 tests for custom formatting rules.
     • Ensures there is no commented out testing/debugging code left in the final version
• Total proposal length should be under 3 pages 8.5" x 11" paper size, in a reasonable font size with reasonable spacing
  • Do not feel compelled to fill 3 pages.
  • Your team will lose a half-grade point on the project for each page over 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

• Each team must use git to develop the project.
  • The main git repository will be hosted on GitHub classrooms
  • Group members are encouraged to maintain their own fork to have the project under their own github usernames.
• The project can consist of one or more ROS packages but should everything 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.
  • Use the simple git workflow
• You should have automated tests (both unit and integration) for your code.

• 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. Title of the project
  2. Authors, listing the author names
  3. Brief project overview
  4. Quickstart guide providing the exact commands needed to run the project
  5. List of all nodes and launchfiles and what they do.
  6. A discussion of the overall system architecture and high level concepts
  7. Any other information, as appropriate (for example: algorithms used, lessons learned, future work)
• The audience for the README.md is people who know ROS but not your particular project (such as your classmates).
• Videos
• You should produce a video showing your demonstration working.
• The video should be hosted online and embedded in the README.md in a way that it plays when viewing the repository on Github
• The video should include views of the robot itself and screencasts of rviz and other software visualization
• The video can also be hosted on youtube.
• 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