Project 1 — Reactive Robotics using Webots

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 9: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:

• to give you baseline experience with robotic sensing and acting on which you will build,
• to give you experience with the reactive paradigm in robotics,
• to familiarize you with the particular software environment that you will be using for the major project later in this course, and
• to work out a team structure and method of operation that you will use (perhaps with modifications) for the major project of the semester.

3. Assignment Overview

You will design, program, and demonstrate an autonomous robot that carries out a simple set of behaviors. Rather than having you start from scratch in designing your approach to this problem, you will start from a baseline set of code that you will modify and extend appropriately. You will also turn in written material regarding the design and implementation of the robot and its software.

4. Assignment Details

The code you will 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 the Webots simulation environment, and (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 Webots simulation environment.

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. Stop if the robot comes close to a red object. (Here "close" means within two times the length of the robot. This does not correspond to any of the behaviors from the Jones code.)
3. Arc away from imminent collisions ahead. (This is similar to the "avoid" behavior from the Jones code. Collisions are considered "imminent" if the object is within one length of the robot.)
4. Arc left if the robot comes close to a green object. (Again "close" means within two times the length of the robot. This does not correspond to any of the behaviors from the Jones code.)
5. Arc right if the robot comes close to a blue object. (Again "close" means within two times the length of the robot. This does not correspond to any of the behaviors from the Jones code.)
6. Move toward red objects. (This is similar to the "follow" behavior from Jones but is clearly different in that the taxis is toward red objects, rather than toward a light source.)
7. Move toward green objects. (As above.)
8. Move toward blue objects. (As above.)
9. Go forward. (This is the same behavior as "cruise" from the Jones code.)

Note that the sensors available to work with in Webots may not be exactly the same as those available with a typical Lego robot. For that reason, you are given flexibility with regard to selection of sensors. For example, sensing a red object might be most effectively done with a color camera. So, feel free to use a (simulated) color camera in Webots. 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. You need to encode the nine basic behaviors given above. 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.

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.

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 Webots World File

You will turn in a copy of your Webots world file, which defines 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 will not drastically alter the target, but I may change it slightly. (E.g., I might change the size or location of the red object you are seeking, but I would not replace it with a light source.) 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 File Documentation

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

• The robot base you have chosen to use. If this is an "off-the-shelf" base (e.g., provided with Webots), you need to say that and provide references to online documentation for that base. If this is a custom base that you have designed yourself, you need to describe it in enough detail to understand its basic mechanical design.
• The sensor suite you have chosen to use. For each sensor, you need to say whether it is an "off-the-shelf" sensor and, if it is, provide references to online documentation for it. If it is a custom sensor, you need to describe what "real world" sensory system it simulates and explain what data it gathers from the environment and how that is implemented in Webots. In addition, whether it is a custom or off-the-shelf sensor, you need to clearly indicate which sensor from Jones et al. your sensor replicates or replaces.
• The objects your robot will seek and those it will avoid. This should include a description of their color, size, shape, and number. If any additional files were used to generate the objects in question (e.g., through the terrain builder utility), these files should be included as well.

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 OU’s academic integrity website.