• Released on: 10/15
• Due on: 11/04 (by midnight)

There are three objectives for this project:

1. Become familiar with and implement an advanced path planning algorithm.
2. Become familiar with modelling for activity planning.
3. Understand the interplay between path and activity planning.

The code for 16.413 students is being kept on a separate branch of the repo used for the course (so as to not clutter the path of people in 16.410). Run the following commands to switch branches. Remember the default password (needed for sudo) is 'student'.

cd /etc/chef
sudo git fetch
sudo git checkout 16.413

After this, run sudo update_intro_to_autonomy as usual.

This project uses the command line heavily and we need to set up a Python virtualenv to use for this project. To do so, run the following commands. Note that the first command has two >s, not one!

echo "source /usr/share/virtualenvwrapper/virtualenvwrapper.sh" >> ~/.bashrc
# Close and then reopen any terminals you have open at this point.
mkvirtualenv proj1
workon proj1
pip install -i /home/student/jupyter/projects/project1/requirements.txt
# The previous step may take quite a bit of time.
add2virtualenv /home/student/jupyter/projects/project1/py

From now on, any time you open a terminal to work on this project, you need to make sure all the Python libraries are on your path by running:

workon proj1

In this project, you are working for a brand new company, Googazon, that is using quadrotors for deliveries. Googazon has a set of warehouses that stock cream and sugar, and a set of customers that want cream and/or sugar for their coffee. Your goal is to make all of the customers happy by delivering them the goods they want. You will do this by modelling the delivery problem for a generative planner and implementing a path planner to route the vehicle between different locations.

You will be using RMPL (reactive model-based programming language) as the modelling language for this project. RMPL is developed by the MERS group at MIT. It is an experimental language still under development, but the subset of the language you will be using for this project has been extensively tested.

First, let's look at how the code in this project is laid out. The project is located in the ~/jupyter/projects/project1/ folder. Most of the python code used is located in the py/ folder. bin/ contains executable scripts used for preprocessing, planning, and executing plans. rmpl/ is where RMPL scripts should be located. environments/ is where environment files should be located.

We may need to push out updates during this project. To make that process painless, we ask that you do not modify any existing files, except py/intro_to_autonomy/project1/path_planner.py and requirements.txt. Feel free to add new files as you see fit.

Now let's look at what RMPL files look like. Open the file rmpl/simple.rmpl. You can use a text editor of your choice, the Jupyter environment, or the (new) editor located at http://localhost/rmpl-editor to open the file. RMPL is an object-oriented language with a syntax inspired by Java.

One of the ways RMPL classes are different than Java classes is that every class has an implicit “mode” variable that can take on one of a set of predefined values (think Enums in Java). These values are declared using the value keyword.

Let's first look at how Booleans are represented.

class Boolean {
  value yes;
  value no;
}

This makes a class called Boolean whose mode variable can take on the values “yes” and “no”.

You'll also see a line:

#LOCATION_CLASS

This is a statement to the RMPL preprocessor that results in a class being inserted here called Location with values that match every feature in the environment you are using to preprocess the file (more on that later).

We can see Warehouses are defined by:

class Warehouse {
  Boolean has_sugar;
  Location location;
}

Meaning that every Warehouse can have sugar (or not) and has a location (it's located at one of the features in the environment). Customers are similar.

Next, we turn to Quadrotors. We can see that the Quadrotor state is currently defined by three things.

Boolean flying;
Location location;
Boolean has_sugar;

Additionally, a Quadrotor has “primitive methods” defined on it. Primitive methods are actions that are directly executable by the hardware being modelled. In this project, only the Quadrotor class should have primitive methods defined. Primitive methods may take arguments, have preconditions, and have effects that should be modelled so that the planner knows what will happen when that method is executed by the hardware. Let's look at pickup_sugar

primitive method pickup_sugar(Warehouse w)
  flying == no
  && w.location == location
  && w.has_sugar == yes
  => has_sugar == yes;

This primitive method is called pickup_sugar. It takes a Warehouse as an argument. It has three preconditions:

1. The quadrotor must not be in the air (technically, the mode variable of the flying field must have the value no).
2. The quadrotor must be located at the warehouse w (technically, the mode variable of w's location field must have the same value as the mode variable as the quadrotor's location field).
3. The warehouse must contain sugar (technically, the mode variable of w's has_sugar field must have the value yes).

It has one effect:

1. The quadrotor now has

1. Inheritance is not allowed in this version of RMPL.
2. Try to not to use variable names that are the same as a feature from your environment file. This can confuse the planner as the variable will shadow the feature name wherever the variable is accessible.
3. c and u are reserved keywords (for features you won't use in this project). Do not name any variables or values c or u.

Choose a path planning algorithm.

Implement the algorithm.

Remember that you can post questions in our Piazza Forum. Please do not post answers to the problems, though.