Project 1 — Reactive Robotics using Player and Gazebo

Due Wednesday, February 25, 2009

NOTE: All 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. For hardcopies, do this by submitting them to me during office hours or by sliding them under my office door. For electronic copies, 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 an autonomous robot that carries out the following task: Follow another robot without bumping into it or to other objects in the environment. Rather than having you start from scratch in designing your approach to this problem, you may start from a baseline set of code and modify and extend it appropriately. You will turn in written material regarding the design and implementation of the robot and its software.

4. Assignment Details

The code you may choose to start from is the (modified) code of Jones, et al. discussed in class and its extensions and modifications that were created as a homework assignment in 2003. This code will need to be extensively rewritten because (1) it is written in Interactive C, whereas your code will be written in Java, (2) it was written for execution on a HandyBoard on a simple Lego robot, whereas your code will be written to interact with Player for a simulated robot in the Gazebo simulation environment, (3) it is written for use with simple sensors (such as photoresistors and IR proximity sensors) which may not be readily available to you in the Gazebo simulation environment, and (4) the task for your robot is slightly different from the task that was carried out by the robot of Jones, et al.

Note that the task description given the in overview is rather vague. This is partly because there are differences between the task of this assignment and the task Jones et al., and also because the sensors available to work with in Gazebo may not be exactly the same as those available with a typical Lego robot. For the sample code you are starting with, the assumption was that the robot would move towards areas of greater light (positive phototaxis). However, your robot must follow another robot. For that reason, you will need to develop the other robot as well. The leader robot will simply wander aimlessly while trying to avoid collisions but you have the flexibility to choose parameters relating to its wandering (such as its speed and how erracticly it turns) as well as the robot itself (such as its size and color).

In addition to having flexibility with regard to the task, you have flexibility with regard to selection of sensors. For example, sensing a red robot might be most effectively done with a color camera. So, feel free to use a (simulated) color camera in Gazebo, rather than a simulated photoresistor, if that will work better for you. As a second example, for sensing objects at a distance you may choose to use sonar sensors, rather than IR proximity sensors.

You also 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 reactive behaviors that you will encode for your follower robot. You need to encode the four basic behaviors listed below:

  1. wander — move randomly
  2. follow — positive taxis towards the other robot
  3. swerve — turn while moving forward (to avoid collisions while continuing to make progress)
  4. escape — move away from collisions after they happen

Similarly, for the leader robot you must encode the following three basic behaviors:

  1. wander — move randomly
  2. swerve — turn while moving forward (to avoid collisions while continuing to make progress)
  3. escape — move away from collisions after they happen
These behaviors do not need to correspond to particular objects or methods in your Java 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.

5. What to Turn In

You will turn in both a hard copy and an electronic copy of each of the following components. For the electronic copies, please do not provide these in MS Office 2007 format (e.g., .docx for MS Word). I would prefer something like ps or pdf for documents but MS Office 97/2000/XP formats will probably be good enough.

5.1 Gazebo World File

You will turn in a copy of your Gazebo world file, which defines both robots, and the objects to avoid. 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 will not drastically alter the leader robot or its behavior, but I may change it slightly. (E.g., I might slightly change the size or the speed of the leader robot, but I would not change its color or replace it with a light source.) I might change the size, shape, location, number, and orientation of the objects to avoid. How robust your robot and code are with respect to these manipulations will be counted in your grade.

5.2 World File Documentation

To explain the world file, you will turn in a document describing it. In particular, you need to describe:

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.

5.3 Robot Code

You will turn in the actual code you have written to control this robot. This will be written in Java. 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 Java coding conventions for this class which includes using Javadoc style comments, written according to Sun's guidelines.

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 the Provost's web pages on academic integrity.