# CS148 Assignment Subsumption

## Introduction

\item Assignment 5 project demonstrations in class: Friday, December 4, 2009 \item Assignment 5 handin due: Friday, December 4, 2009 (10 pm) \end{itemize}

## Important Dates

Assigned: Sunday, October 24, 2010

Inter-group soccer competition: Friday, November 5, 2010

Project reports due: Sunday, November 7, 2010 (5:00 pm)

A video of Lisa Miller's implementation of this assignment from Spring Semester 2009.

A video of "Hefty's wicked spin" (by Nicholas and Odean) during Fall 2007 path planning match play.

\noindent Your previous soccer-playing robots required some notion of state, such as robot pose, a map, ball location, etc., in order to function. State information, stored explicitly in variables, gave your controller a sense of context and immediate history about the robot's current situation. Robot decision making at any moment in time is informed by state information in order to deliberate and plan into the future or take immediate action towards some future benefit. State variables allow our robots to adapt in the face of unexpected changes in the environment and new scenarios\footnote{Learning aims to provide a greater level of adaptability such that the robot has long-term context and history towards learning from experience. It could roughly be thought of as never making the same mistake twice.}. However, estimation of such variables comes at the cost of requiring greater computation, latency in decision making, and overall price tag for the robot.

Consider the case where you want to commercialize a soccer playing robot for a mass market\footnote{Because we are in Rhode Island, let's say you are making a robot for Hasbro.}. Such a robot should not cost too much money to purchase, on the order of the \$150 Roomba Red or \$250 Nintendo Wii. Further, every additional component added to the robot, such as memory, processing, sensing, and actuators, increasingly cuts into your profit margin. In such scenarios, reliance upon state variables costs you money\footnote{Money in this case can be generalized to cost that limits practical implementation. So, even if you are not fiscally motivated, such costs limit your ability realizing your technical visions.}, thus you might be inclined to minimize the number of these variables.

Using reactive control, your robot controller in this assignment will rely upon no state variables and simply react to what is sensed at the current instance of time. In contrast to the deliberate intentionality of planning, reactive approaches rely upon {\bf emergent behavior} where the intelligence of the robot results from its decision making, the properties of the environment, and the dynamics of controller-environment interaction. The Subsumption Architecture is one approach to reactive control that uses multiple robot controllers with a priority scheme. In particular, each robot controller is capable of independently producing some robot behavior (such as wandering or obstacle avoidance) given certain applicability conditions (or preconditions) are met (such as whether an obstacle is present). When their preconditions are met, higher priority controllers subsume lower priority controllers, whose decisions are then ignored.

\section{Control Objectives}

In the current assignment, you will implement a robot soccer controller that uses only the robot's on-board immediate sensing and perception. Specifically, you are only allowed to use the information provided in the {\bf current time instant} by Player's bumper, infrared (IR), and blobfinding proxies. Timers, odometry, and variables that require history are not allowed in your client. Timing-based operations in the Create Open Interface also cannot be used by your client. With this information, you are tasked with implementing a Subsumption architecture. Towards this end, you must:

\begin{enumerate} \item determine and implement an appropriate set of control behaviors for soccer \item apply appropriate preconditions for each control behavior \item determine and implement a priority scheme to coordinate the behaviors \end{enumerate}

Your robot will need to stay within the general field of play as given by the physical walls of the Roomba Lab and virtual walls placed around the pitch. Additionally, your robot should make reasonable attempts to avoid collisions with other robots, which will be marked with 14.5 x 10 x 10 cm pink rectangular tubes placed on top of the robot. We will definitely call player pushing penalties for this assignment!

Virtual walls (pictured to the right) are devices that emit infrared (IR) light that can be received by the iRobot Create and Roomba platforms. The distribution of space covered by the emitted IR forms a beam that can extend up to 8 feet. These beams form an invisible barrier around the field that your robot should respect. Your control client will have access to the SmURV's IR sensing through the IR proxy. Note that the width of the virtual wall's beam also increases as its length increases, creating a cone-shaped area from the IR wall. It is best to set the range slider to the middle option: 4-7 feet. However, if you find the width of the beam emitted from the IR wall is interfering with your robot too much, the 0-3 feet range may be more appropriate.

\subsection{Sensing a Virtual Wall} To sense a virtual wall using libplayerc++, create an IR proxy object\footnote{See \url{http://playerstage.sourceforge.net/doc/Player-cvs/player/classPlayerCc_1_1IrProxy.html} for C++ clients} in your robot client. The state of the IR can be accessed through the boolean flag wall hit by calling the function GetRange(5); the 5 indicates the index of the virtual wall sensor.

Make sure to configure the Player server to provide IR data. In the Player configuration file, the \texttt{create} driver must have the ir:0 device specified in the \texttt{provides} line, as in the following example:

\begin{verbatim} driver (

   name "create"
provides ["position2d:0" "bumper:0" "power:0" "ir:0"]
port "/dev/ttyUSB0"
alwayson 1


) \end{verbatim}

\subsection{Behaviors and Prioritization}

You will be asked to demonstrate (either through a demo or in your report) that each control behavior functions independently and properly. In addition, your independent behaviors will need to function together (without code modification) using a subsumption priority for coordination. You will also be asked to randomly (based on the opinion of the course staff) reprioritize your behaviors to evaluate emergent behavior properties.

\section{Soccer Skills Challenges and Competition}

The goal scoring challenges and inter-group soccer competition from Assignment 3 (Path Planning) will be used for this competition in addition to a modified navigation challenge. The navigation challenge will have the same format as Assignment 3 except that obstacles will be pink fiducials and the field boundaries will be given by the physical and virtual walls. Both the Goal Scoring and Collision-free Navigation tasks must be completed within 120 seconds.

\vspace{1cm} \begin{tabular}{|l|l||l|l|} \hline {\large \bf Project Implementation} & \\ \hline \hline - Individual Behaviors & 15\% \\ $\rightarrow$ Does each of your behaviors properly function? & \\ $\rightarrow$ Is each of your behaviors completely reactive, without state variables? & \\ $\rightarrow$ Do your control behaviors allow for modularity and transparent reprioritization? & \\ \hline - Behavior Choices & 15\% \\ $\rightarrow$ Do you have a sufficient set of behaviors for playing soccer? & \\ $\rightarrow$ Does your robot respect the environment (field of play) and avoid pushing other players? & \\ $\rightarrow$ Can your robot manipulate the ball and score goals? & \\ \hline - Subsumption Priority & 10\% \\ $\rightarrow$ Does your robot properly prioritize its individual control behaviors? & \\ $\rightarrow$ Does each of your behaviors have appropriate preconditions to allow for coordination? & \\ \hline - Soccer Proficiency & 5\% \\ $\rightarrow$ How well does your robot player soccer in the given environment? & \\ \hline - Controller Robustness & 5\% \\ $\rightarrow$ Does your controller run without interruption? & \\ \hline %\vspace{0.1cm} \\ \hline {\large \bf Written Report} & \\ \hline \hline - Introduction and Problem Statement & 7\% \\ $\rightarrow$ What is your problem? & \\ $\rightarrow$ Why is it interesting? & \\ \hline - Approach and Methods & 15\% \\ $\rightarrow$ What is your approach to the problem? & \\ $\rightarrow$ How did you implement your approach and algorithms? & \\ $\rightarrow$ Could someone reproduce your algorithms? & \\ \hline - Experiments and Results & 20\% \\ $\rightarrow$ How did you validate your methods? & \\ $\rightarrow$ Describe your variables, controls, specific tests, and results from these test. & \\ $\rightarrow$ Could someone reproduce your results? & \\ \hline - Conclusion and Discussion & 8\% \\ $\rightarrow$ What conclusions can be reached about your problem and approach? & \\ $\rightarrow$ What are the strengths of your approach? & \\ $\rightarrow$ What are the shortcomings of your approach? & \\ \hline \end{tabular}