Project 1 — Reactive Robotics using ROS and Gazebo

Due Tuesday, October 9, 2012

NOTE: The hardcopies of the parts of this assignment are due at the beginning of the class period. 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. Electronic copies are due by 5:00 pm 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

The basis of all of intelligent robotics is tying sensing to acting. To do that we need sensors, actuators, and some connections between them; these components comprise the robots. In this class, we'll build robots in teams. This assignment will introduce us to all of these aspects of robotics, which we'll make use of throughout the semester.

2. Goals

The goals of this assignment are:

3. Assignment Overview

You will design, program, and demonstrate a simulated autonomous robot that carries out a simple set of behaviors in an environment you will describe using XML. You will also turn in written material regarding the design and implementation of the robot software and environment.

4. Assignment Details

The behaviors your robot will carry out are as follows, ordered from highest priority to lowest:

  1. Turn away from collisions detected by bumpers. (This is the same behavior as "escape" from the Jones code.)
  2. Accept keyboard movement commands from a human user.
  3. Move around detected obstacles, keeping the obstacles to the robot’s right.
  4. Wander. (This should be similar to the wander behavior from Brook’s subsumption paper.)

While the robot is carrying out these behaviors, it should also be "mapping" the environment (that is, filling in an occupancy grid) as seen in the tutorial in Homework 3. Note that the robot does not need to navigate based on this map. Rather, it simply needs to construct this map as it wanders, circles, moves under keyboard command, or turns away from collisions.

When viewed from above, the obstacles in the environment should roughly model the interlocking OU logo and be sized such that the robot can easily move into the U or, if started inside the O, easily move down into either channel next to the U while still being small enough to circumnavigate in a moderate amount of time.

You have flexibility with respect to the particular reactive architecture that you choose. You may try to closely match the subsumption architecture of Brooks (as seen in Exercise 2 of the homework). You may try to follow schema theory instead (as seen in Exercise 4 of the homework). You might keep the pseudo-subsumption approach of the original code of Jones et al. You may follow another reactive approach from the literature or even invent your own.

Where you do NOT have flexibility is in determining the basic behaviors that you will encode. You need to encode the four basic behaviors given above, plus mapping. These behaviors do not need to correspond to particular objects or methods in your C++ code. For example, if you choose to implement a schema-based architecture, you'll want to split each of these into separate parts for the perceptual schema and motor schema. That is fine. However, the behaviors themselves need to be readily recognizable within your code.

Another place that you do NOT have flexibility is in whether or not to make your code object oriented. So, while a particular behavior does not need to correspond to a particular object, the overall code needs to be well structured, including making it object-oriented.

Thirdly, you do NOT have flexibility with regards to the overall shape and size of the obstacles in the environment but you do have flexibility within the limits given above.

Finally, you do NOT have flexibility with regards to the basic software or simulated hardware base on which you will build your code. You need to use ROS, Gazebo, and a simulated TurtleBot.

5. What to Turn In

You will turn in both a hard copy and an electronic copy of each of the following components.

5.1 ROS World File

You will turn in a copy of your ROS world and launch files, which define the robot and the objects. Note that during testing I may alter your world file. I will not alter your robot's physical construction, but I may change its initial location within the environment. I will not deprive your robot of its sensors, but I may slightly alter their configuration. I might change the size, shape, location, number, and orientation of the objects. How robust your robot and code are with respect to these manipulations will be counted in your grade.

5.2 World and Launch File Documentation

To explain the world and launch files, you will turn in a document describing these. Essentially, you need to translate the XML in these files into textual descriptions for a lay audience. This documentation should be from 1.5 to 2 pages in length (roughly 80 characters per line, 50 lines per page), not including any figures, which may be of any length. This document must also give explicit instructions listing all steps needed to launch and run your project on the CSN Linux boxes.

5.3 Robot Code

You will turn in the actual code you have written to control this robot. This will be written in C++. Your source code should be well structured and well commented. It should conform to good coding standards (e.g., no memory leaks). You are required to follow the ROS C++ Style Guide.

5.4 Robot Code Documentation

Besides the comments included with your code, you will turn in a document explaining the data structures and algorithms used in your code. This document will also describe which particular reactive architecture you chose to use, why you chose it, and what particular features of your code embody the elements or characteristics of this architectural style. This documentation should be from 1.5 to 2 pages in length (roughly 80 characters per line, 50 lines per page), not including any figures, which may be of any length.

6. 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 CSN Linux machines 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.