Major Project — The Teapot Tone Scenario

NOTE: The hardcopies of the parts of this assignment are due at the beginning of the class period, with the exception of the final poster which is due by 1:30 on the due date. This means that if you are even a minute late, you lose 20%. If you are worried about potentially being late, turn in your assignments ahead of time. Do this by submitting them to me during office hours or by sliding them under my office door. For the final poster, bring it to the Devon Hall Atrium between 12:30 and 1:30 on the due date and ensure that it is mounted and ready for presentation by 1:30. Electronic copies are due by 5:00 pm on the due date, with the exception of the final poster which is due by noon on the due date. Submit them through D2L before the time they are due. Do not send assignments to me through email or leave them in my departmental mail box.

1. Motivation

A primary reason to build intelligent robots is to accomplish missions. For this project, the mission is simple and unimportant but it is related to more complex and important missions, as detailed below. The key is to give you experience designing, implementing, testing, and reporting on robot software to carry out missions.

2. Goals

The goals of this assignment are:

3. Assignment Overview

You will design, implement, test, and report on robot software to control one of the OU Turtlebots as it carries out the mission of locating and turning off a (physical simulation of a) whistling tea pot. This scenario is similar to the one described in Homework 1. This mission was invented as a safe analogue of the DARPA Robotics Challenge mission of finding and turning off a valve near a leaking (steam) pipe as part of a disaster response scenario.

4. Assignment Details

4.1 Robot Hardware

Your software will be evaluated by testing it on an OU Turtlebot in the test environment described below. It should not be necessary for you to modify the Turtlebot in any way. However, if you believe that if would be more effective to add a small, fixed appendage to a Turtlebot to facilitate pushing the button to turn off the teapot, I will consider letting you affix such an appendage. However, you must contact me with specific details and obtain prior approval before any such appendage is attached to an OU Turtlebot. Other modifications to the OU Turtlebots will not be allowed.

4.2 Robot Software Compatibility

Your software must be compatible with ROS. You are encouraged to develop and test your software using Gazebo as well but this is not mandatory.

4.3 Robot Software Paradigm

Your software may be developed using any of the paradigms we have covered in class (deliberative, reactive, and hybrid). In addition, your software need not be fully autonomous — you may incorporate various forms of shared autonomy, mixed-mode autonomy, etc. — however, additional points will be given as greater autonomy is demonstrated. Moreover, any human input to the system must come from an operator located in the east half of FH 300 who has no visual contact with the test environment other than via the robot’s cameras. Note also that I may introduce communication delays or losses into the link between the human operator and the robot.

4.4. Test Environment

The test environment will conform to the description below. During development, you may move the furnishings, flooring (other than the carpet), "debris," and teapot. I will rearrange these items before my testing and evaluation of your software.
Felgar Hall 300, west half. I may add "interior walls" using cardboard, marker board, and/or sheet rock.

Various office furnishings, such as chairs, tables, and desks.

Carpet, cardboard, marker board (face up or down), and duct tape.

Office supplies such as (simulated) books, papers, pens, etc.

(Physical Simulation of) Whistling Teapot:
Handyboard emitting tone and with visual fiducials. (This may change if the tone is found to be too quiet to be of use.)

5. Deliverables

5.1 Status Report

On Tuesday, November 20, each team will give a brief status report. This report will describe the basic approach your team is taking with your software, including which robotics paradigm your software follows, your plans regarding autonomy and human operation, the sensors you are planning to use and how you plan to use them, and any software you have discovered or developed that you believe will be of interest to other teams and how you believe they could make use of that software.

5.2 Written Report

Each team will submit a draft and final written report on their project. Both the draft report and the final report have the same required contents. The draft report will be graded on a ✓+ / ✓ / ✓– (check-plus/check/check-minus) scheme only and is intended primarily to allow me to provide you with feedback that you can use to improve the quality of your final report. The final report will be point graded.

Your report will be modeled on a technical report that might be published by a laboratory. This will have the same basic structure as a conference paper or journal article but without the fancy formatting or severe page limits. Your report will have the following components:

Note that while all of the components above must be included in your report, they do not necessarily need to be organized into sections this same way. For example, if your approach combines ideas from multiple prior approaches, you might describe the approach in a single section with multiple subsections or, alternately, in multiple sections. As a second example, you might choose to combine your discussion and conclusions into one section or to combine your conclusions and future work into one section. However, deviations from the expected order and division of the document should be justifiable, not gratuitous.

You should double space this document, so that I have room to write comments/corrections on it. To conserve paper, you should print all of your documents for this class on both sides of each sheet of paper when practical and should make an extra effort to do so with this large document.

You should submit an electronic copy of your report before class through D2L and turn in a printed copy at the start of class.

Draft Report Due: Tuesday, November 27.

Final Report Due: Thursday, December 6.

5.3 Robot Demo

Each team will give a demonstration of their robot software on an OU Turtlebot sometime during the week of December 3 through December 6. Each demonstration period will be half an hour long, which includes up to 10 minutes of setup and 20 minutes for the robot to locate and turn off the tea pot. Teams must schedule at least one demonstration and may schedule two. If a team chooses to give two demonstrations, the greater performance of the two will be used to score robot performance. Available times for demonstrations are:

When requesting a demonstration time, please indicate whether you wish to have one demonstration or two and please give at least two alternatives for each demonstration requested. I will try to honor all requests but if there are scheduling conflicts between teams, I will resolve these in a first-come, first-served manner and the later requesting team may need to determine an alternate time for a demonstration.

5.4 Project Poster

Each team will submit a draft and final poster on their project. Both the draft and the final poster have the same required contents. The draft poster will be graded on a ✓+ / ✓ / ✓– (check-plus/check/check-minus) scheme only and is intended primarily to allow me to provide you with feedback that you can use to improve the quality of your final poster. The final poster will be point graded.

Your poster will be modeled on a technical poster that a researcher might present at a conference. As such, it will have the same components as the report. However, the poster is not meant to be a self-contained document like the report. Instead, like slides for a presentation, the poster is meant to be supporting material that you may refer to while explaining your work to people standing before you. As such, you will want to keep the words to a minimum, using phrases or bullet points rather than long paragraphs of text and include diagrams, graphs, and other figures that are difficult to convey through spoken words.

Draft Poster Due (electronic copy only): Thursday, November 29.

Poster Registration Due (using the CS Poster Session wiki): Friday, November 30 by noon. Note that you need to be registered with the wiki before you can register your poster. Since wiki registration requires manual approval, you should register with the wiki well in advance of this due date.

Final Poster Due (both electronic and printed copy): Friday, December 7.

6. Grading

This project will be graded as follows:

Original Contributions to Robot Performance
Software Quality
Status Report
Written Report
Code Adoption
20 (bonus)
Grading notes:

7. Notes on this Assignment

You may write your program from scratch or may start from programs for which the source code is freely available (such as on the web or from friends or student organizations). If you do not start from scratch, you must give a complete and accurate accounting of where all of your code came from and indicate which parts are original or changed, and which you got from which other source. Similarly, for the written components of this assignment you may follow the format or content of other written works but you must give a complete and accurate accounting of who deserves credit for all parts of your documents. Failure to give credit where credit is due is academic fraud and will be dealt with accordingly. Please see OU’s academic integrity website.

You may use whatever computing resources you have access to for the development and testing of your world and launch files and your control code. However, your control code must compile on the OU Turtlebots using g++ or make (if you provide a make file) and must launch and run successfully on those machines by following the instructions you provide on doing so.