Assignment 5: Behavior ("closing the loop")

The goal of this assignment is to familiarize you with the process of creating high-level behaviors for the robots, starting from the lower-level skills we have built up in previous assignments. This process is often referred to as "closing the loop." You will also learn about our team's framework for keeping track of the robot's current behaviors and the transitions between behaviors. We usually refer to this framework as the "task hierarchy"; it is similar to a finite state machine (FSM) in certain ways, but more extensible and better suited to the types of behaviors we need for robot soccer.

The assignment is divided into two parts. In Part I, you will create a behavior for a single robot that finds the ball and kicks it toward the goal. In Part II, you will build on this to create a behavior for two robots working together to score on the goal. You must work in groups of at least two on this assignment.

Part I - Closing the loop for one robot

Your task in this part is to create a behavior for one robot that can kick the ball into the goal. At a bare minimum, your behavior should be able to score a goal when the ball is placed 1-2 feet from the goal and centered in front of it, and the robot is placed anywhere on the same half of the field. If you want to take the assignment further, try to make your robot able to score from more locations on the field. Some are quite tricky!

Take the following steps to get started.

• Copy the contents of /robosoccer/assignments/prog5/ to someplace in your home directory. (This is the current UT Austin Villa team code, minus some behavior code.) To compile, type "make install". You can use the loadstick shell script in the prog5 directory to load the code to the memstick, if you like. (Usage: loadstick <IPnumber>) The code currently executes a simple task of standing in place and following the ball with the head.
• The main files of interest to you will be PrimitiveTasks.h and CompositeTasks.h, both in the Brain/FSM/TaskFSM/ subdirectory. These contain all the behaviors available to you for this assignment. At the bottom of CompositeTasks.h is a very simple task called ScoreTask which is currently specified as the root task (primary task executed by the robot). The easiest way for you to complete Part I is to fill in the contents of this task.
• You may also find several WorldState variables and functions quite useful. For an idea of what sorts of functions are available, look at other tasks or at Brain/WorldState.h. Some especially useful WorldState variables include ws->ballInVision, ws->ballDistance, ws->bodyPos, ws->bodyAng. One especially useful WorldState function is ws->HeadingToOppGoal().
• The task hierarchy paradigm takes a little getting used to, and the easiest way to get comfortable with it is probably just playing around with it and using the existing tasks as examples. The basic idea is that the robot is working toward goals at several levels most of the time, so it makes sense to arrange its tasks in a tree-like structure, with one big task at the top (the root task) and intermedate tasks below that. For example, your robot will be working toward one big task from the moment you turn it on: getting the ball into the goal. But in order to accomplish that, it will have to switch between some other intermediate tasks in the process (such as searching for the ball or walking toward the ball). Each of those intermediate tasks, in turn, is accomplished by some even lower-level tasks (for example, searching for the ball involves moving the head sometimes, or maybe walking around sometimes). This tree of subtasks extends down to the PrimitiveTasks, which you can think of as the leaves of the tree. PrimitiveTasks are the tasks which actually specify motion commands to the OPEN-R object which controls the robot's motions.

• Both CompositeTasks.h and PrimitiveTasks.h have skeletons of task definitions at the top and a little explanation of what various parts of them do. There is another type of task not illustrated here, called a ParallelTask, which allows multiple subtasks to execute in parallel rather than serially. The most common use of a parallel task is to allow the head and legs to do different things at the same time. There are several examples of this type of task among the provided behaviors, if you want to see how to build such a task.
• You will probably find it useful to write several intermediate tasks that combine the provided tasks in useful ways, rather than trying to fit everything into ScoreTask.
• The color cube in this code is calibrated for all lights on, as in the vision assignment.
• Here are some examples you might find useful:
  • Example of how to send parameters to a task: MoveHeadToPosn (in PrimitiveTasks.h)
  • Example of a simple parallel task: StopHeadCircleTask (in CompositeTasks.h)
  • Example of a simple serial task, and also of how to use WorldState information: LookForBallTask (in CompositeTasks.h)
  • Examples of how to use GetTime() to see how long a task has been executing: TurnByAngleTask (in CompositeTasks.h) and KickTask (in PrimitiveTasks.h)

Part II - Coordinating two robots

Your task in this part is to write behaviors for two robots that work together to score a goal. One way you can accomplish this is by writing a "do-nothing" behavior that you load up on one robot, and then loading up your behavior from Part I on the other robot -- but we hope you'll be a little more creative than that. (We will at least test that each robot can take control when the ball is right next to it). Ideally, two robots should be better at accomplishing this task than one, but it will take a little thought to make that happen -- note that if you just load up the single-robot behavior on two robots, they'll bunch around the ball like little kids playing soccer and just get in each other's way (try it).

The robots are already set up to communicate a lot of information that you may find useful. For example, a robot can find out if any of its teammates see the ball by looking at the teammateState[i]->seesball WorldState variable for each of its teammates (i∈[0,NUM_TEAM_MEMBERS), i≠M_ID). They are also set up to communicate variables called goToBall and strategyGoToBall, which are shortcuts to our team's (rather complicated) strategy for coordination. DO NOT USE THESE TWO VARIABLES IN YOUR SOLUTION! That would be cheating unless you had a deep understanding of what goes on in Strategy.cc to drive these variables -- and trust us, gaining that understanding is way more work than just using the other available WorldState info to write your own solution. (=

• Robots with IPs 10-40 will communicate with each other, and robots with IPs 50-80 will communicate with each other. This has two consequences:
  • if you want your robots to communicate, make sure they both have IPs in the same range, and
  • if you DON'T want robots to communicate (like, say, your robots and some other group's robots), make sure they DON'T have IPs in the same range.
• If a robot is communicating with some other robot, the little blue light in the center of the back of the head will be blinking.
• You can find the full set of things that are communicated between teammates by looking near the top of the file Brain/WorldState.h in the struct TeammateState. Not all of these things will be useful to you; some won't have the values they claim to in the comments, because their values are typically maintained by code in our behavior tasks (an example of this is the variable haveBall, which you will have to set explicitly if you want to use it -- ask Peggy if you want guidance on this). Here are a few that should do what they claim to, though, and may be useful:
  • seesBall -- whether this robot is pretty sure it sees the ball
  • BallDist -- ball distance (in millimeters) as estimated by this robot
  • consecutiveNotBall -- vision frames (increments of 1/25 sec) since this robot has seen the ball
• Adding things to be communicated between robots is a bit tricky, so you'll probably want to just use the provided things if possible. But, if there's something you really want to add, talk to Dan, Peggy, or someone else in the lab, and we'll help get you started.

Deliverables