Project 2 — Hybrid Deliberative/Reactive Robotics using ROS and Gazebo

Due at 11:59 pm on Friday 16 October 2020

1. Motivation

To go beyond simple reactions to substantial intelligence appears to require deliberation. This assignment will build on Project 1 to give you experience with the deliberative aspect of robotics, and how to integrate deliberation with reaction.

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 tasks in a simple environment. Each task consists of moving from a starting point to an ending point. The environment is the same environment that you used in Project 1. The activities that your robot will carry out are task planning, path planning, navigation, and execution monitoring. 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 to control a simulated TurtleBot moving in a simulated room and adjacent hallway. The robot will receive a set of simple tasks from the user in the form of ordered pairs of points. The first point in each pair will be the starting point of that task and the second point in each pair will be the destination point of that task. Each ordered pair of points will be given on its own line and a blank line will indicate the end of the set of tasks and the start of task planning. For example 

    ((2, 3), (9, 8))
    ((12, 9), (4, 14))
shows two tasks, one with the starting point (2, 3) and the destination point (9, 8) and the other with the starting point (12, 9) and the destination point (4, 14).

The activities your robot will carry out are:

Task planning.
Task planning determines the order in which to carry out the tasks such as to minimize the predicted distance traveled. To keep things simple, your task planner should assume that there are no walls or other obstacles and that the robot is capable of moving in a straight line from each location to the next. Note that within each ordered pair, the starting point must be visited before the destination point, but that tasks may be interleaved. Thus, given the two tasks listed above, the orders in which the points may be visited include options such as in which each starting point precedes its corresponding destination point but would not include options such as in which a starting point is preceded by its corresponding destination point. Also note that in determining the overall estimated distance, the robot should include the distance from its own starting position when the tasks are assigned to the starting point of the selected task.
Path planning.
To keep things simple, path planning will simply be calculating the turn angle and straight-line distance necessary for the robot to move between the points in the order determined by the task planner. Your path planner could construct the entire path for all points after task planning has finished and before the robot begins to navigate, or it could plan each segment of the path one at a time as the robot reaches each point in the task plan. (Your documentation should make it clear which option you chose.)
Navigation.
Navigation involves attempting to follow the planned path while avoiding collisions. This should be relatively straightforward when the planned path does not pass through or near walls in your simulated environment, at least so long as the robot does not accumulate excessive error. However, because paths are planned assuming no walls or other obstacles, it is quite possible that substantial deviations from the planned path may be necessary to avoid collisions. In these cases, your navigator should stay as close to the planned path as possible while staying well clear of obstacles.
Execution monitoring.
While the robot moves, it should engage in execution monitoring to determine whether progress is being made toward the next point in the path plan. The monitor works as follows:

Your robot should use a standard Cartesian coordinate system with the lower left corner of the map from Project 1 at the origin (0, 0) and with the points in units of feet. So, for example, the upper right corner of the map is at (15, 20). You should provide your robot with its starting pos (location and orientation) when you start the simulation.

5. What to Turn In

You will turn in via Canvas 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 and any other files necessary for the TA to run your project.

5.2 Launch File Documentation

To explain the world and launch files, you will turn in a document describing it. Essentially, you need to translate the XML in this file into a textual description for a lay audience. This documentation should be from 3/4 to 1 page 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++ 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 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.