Major Project — The Robot Tour Guide

1. Motivation

A primary reason to build intelligent robots is to accomplish missions. For this project, the mission is to give tours. This project will 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 and report on robot software to control one of the OU TurtleBots as it carries out the mission of acting as a robot tour guide, similar to what was described in Homework 1.

4. Assignment Details

4.1 Robot Hardware

The software you design should be able to run on an OU TurtleBot without physical modification. Hardware modifications to the OU TurtleBots, including changing the sensor suite, 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 must provide a system that is autonomous other than taking in requests for guide services and making requests for minor assistance as described in Homework 1.

4.4. Test Environment

The test environment will conform to the description below. During development, you may move the furnishings and flooring (other than the carpet). I will rearrange these items before my testing and evaluation of your software.

Room:

Felgar Hall 300. I may add "interior walls" using cardboard, marker board, plywood, 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.

5. Deliverables

5.1 Progress Report

On Thursday, 14 April 2016, each team will give a brief progress 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.

• Authors 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.

• 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 submit an electronic copy of your report through D2L.

Draft Report Due: 11:00 pm, Tuesday, April 26.

Final Report Due: 11:00 pm, Thursday, May 5.

5.3 Robot Demo

Each team will give a demonstration of their robot software on an OU Turtlebot sometime during the week of May 2 through May 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 perform. 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 TBD.

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): 11:00 pm, Monday, May 2.

Final Poster Due (both electronic and printed copy): 11:00 am, Friday, May 6.

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.