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:

• to give you experience with designing robot software to accomplish a particular mission, building on your knowledge of the deliberative, reactive, and hybrid robot software architectures,
• to give you experience with implementing robot software in simulation and on real robots, building on and integrating with existing robot software libraries,
• to give you experience with testing robot software in simulation and on real robots, and
• to give you experience with reporting on projects, including interim and final reports, both written and oral (with appropriate supporting materials).

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.

Room:

Felgar Hall 300, west half. I may add "interior walls" using cardboard, marker board, and/or sheet rock.

Furnishings:

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

Flooring:

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

"Debris":

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:

• Title Self explanatory.

• Author Self explanatory.

• Abstract The abstract gives an overview of the entire work. It should state the purpose or central question of the project, state why it is important, give a brief statement of what was done, a brief statement of what was found, and a brief statement of what was concluded. It should be understandable without the reader needing to read the entire report. One good structure is to have five sentences, covering the following:

  1. The problem or question addressed.
  2. The reason(s) the problem or question is interesting and/or worth studying.
  3. The approach taken.
  4. The solution to the problem or answer to the question that you found.
  5. Conclusions that follow from what was found.

• Introduction The introduction covers the motivation, nature, and scope of the report. It also introduces the approach in broad terms, gives a broad overview of the results, and outlines key conclusions. It should include discussion of pertinent literature to help readers understand these elements. (How is your research similar to and different from other research in motivation, nature, scope, results, etc.?)

  Note that the introduction only introduces related work, your approach, your results, and your conclusions. You should cover these topics in greater depth later in your report.

• Approach/Methods

You need to clearly state your approach starting broadly and then filling in details until your entire methodology becomes clear. This may include text, equations, figures, pseudo-code, or some combination of all of these. The level of detail should be sufficient for another researchers to reproduce your results and carry out your analyses without needing to look at or make use of your actual code. (Note that you will be submitting both electronic and paper copies of your code. However, the code itself does not belong in the approach/methodology section of your report. It should be included as an appendix, which would mean that you would not need to turn in a separate paper copy of the code.)

• Results You need to summarize results from testing your software in your report. These should be thorough, so that your readers can analyze them and come to their own conclusions based on them. At the same time, these results should not be exhaustive. That is, they should not be the raw data but appropriate summaries of that data, such as means, standard deviations, and results of statistical hypothesis tests run on the data. Tables and graphs are often appropriate ways to present summarized data but other summaries, such as text descriptions, may also be appropriate. Raw data may be included in an appendix.

• Discussion You need to discuss the results you have found. This includes comparing your data sets to one another and commenting on likely reasons for similarities and differences found.

• Conclusions You need to decide what is reasonable to conclude from your results and clearly state all such conclusions and the bases on which they rest.

• Future Work You need to suggest appropriate ways that your work could be built upon (by you or others). This could be anything from more experiments to help validate the conclusions to radical changes in approach.

• Bibliography You need to present a full set of citations for all works cited in your report. Do not include other related work that is not discussed in your report.

• Appendices If there is important information that you would like to include in your report that would impede the normal flow of the report if included elsewhere, it may be included in one or more appendices. In particular, your full source code, ROS launch and world files, and ROS launch and world file documentation (as described for Project 1), should be included as appendices. You should also include an appendix that lists the contributions of each team member to each part of this project (design, implementation, testing, and reporting).

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:

• Monday, December 3, 8:30 am to 5:30 pm.
• Tuesday, December 4, 8:30 am to 1:00 pm and 3:00 pm to 6:00 pm.
• Wednesday, December 5, 8:30 am to 5:30 pm.
• Thursday, December 6, 8:30 am to 1:00 pm and 3:00 pm to 6:00 pm.
• Friday, December 7, 8:30 am to noon.

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:

Item	Points
Original Contributions to Robot Performance Software Quality Status Report Written Report Poster Code Adoption	30 20 5 30 15 20 (bonus)

• "Original Contributions to Robot Performance" will be based on a combination of how well the robot performs the mission during your team’s demonstration period and how much of that performance is deemed to be the result of your own contributions to the software. That is, because you are allowed to use freely available code and encouraged to share your code with others, it would be possible for a team to simply copy another team’s well performing software in its entirety and likewise have a well performing robot. However, because the copying team’s contribution to that software would be deemed to be zero, the copying team would receive zero of the 30 points available for "Original Contributions to Robot Performance." Similarly, a team that created all of its own code but the resulting code failed to make the robot perform any part of the mission would also receive zero points for "Original Contributions to Robot Performance." On the other hand, a team that built on the code of others by substantially adding to and/or revising that code in ways that significantly improve robot performance could receive up to the maximum points available in this category.


• "Software Quality" will be based not on the demonstration but on careful review of the code itself. I will be looking for code that is well organized following object-oriented principles, well documented internally (including naming and commenting), elegant, refined, and straightforward.


• "Status Report," "Written Report," and "Poster" will be graded based on the descriptions of these items given above.


• "Code Adoption" will be based on how much of your software is used by other teams and how significantly it aids in the performance of their software.

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.