Project 1 — Reactive Robotics using ROS and Gazebo

Due at 11:00 pm on Monday, 06 March 2017

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 work on 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 simple environment that you will design. You will also turn in written material regarding the design and implementation of the robot software and environment.

4. Assignment Details

You will use ROS and Gazebo to simulate a TurtleBot moving in a set of connected hallways and a room. There should be four hallways in total, each approximately 30m long and 3m wide, along with one room approximately 27m by 20m, connected as shown below.

Figure of Hallways

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

  1. Halt if collision(s) detected by bumper(s).
  2. Accept keyboard movement commands from a human user.
  3. Escape from (roughly) symmetric obstacles within 1m in front of the robot.
  4. Avoid asymmetric obstacles within 1m in front of the robot.
  5. Turn randomly (uniformly sampled within ±15°) after every 1m of forward movement.
  6. Drive forward.

For the escape behavior, the robot should turn so that it is roughly facing away from the detected obstacles (180±30°). Note that this is a fixed action pattern rather than a reflex, since the robot will continue to turn after the stimulus that triggered the behavior has ended/changed.

For the avoid behavior, the robot should reflexively turn away from the location of the detected obstacles. For example, if the robot detects an obstacle 0.7m ahead on its left and another 0.9m straight ahead, the robot should turn to the right (that is, away from the closer obstacle). Note that, as a reflex, this behavior should continue only so long as there are asymmetric obstacles within 1m in front of the robot.

While the robot is carrying out these behaviors, it should also be "mapping" the environment (that is, filling in an occupancy grid). Note that the robot does not need to navigate based on this map. Rather, it simply needs to construct this map as it moves.

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 from 2003). You may try to follow schema theory instead (as seen in Exercise 4 of the homework from 2003). You might try the pseudo-subsumption approach 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 basic behaviors given above, plus mapping. These behaviors do not need to correspond to particular objects or methods in your 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 halls and room in the environment.

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 via D2L an electronic copy of each of the following components.

5.1 ROS and Gazebo Files

You will turn in a copy of your ROS world and launch files, which define the robot and the environment. 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 halls and room. How robust your robot and code are with respect to these manipulations will be counted in your grade.

If you choose to construct your hallways by constructing a model by, for example, using the Building Editor in Gazebo, be sure to include your model files (e.g., model.config, model.sdf).

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 in FH 300.

5.3 Robot Code

You will turn in the actual code you have written to control this robot. This will be written in C++ or Python. 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 relevant ROS Style Guide (that is, either the ROS C++ Style Guide or the ROS Python Style Guide, as appropriate).

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 in FH 300 and must launch and run successfully on those machines by following the instructions you provide on doing so.