CS4 Project: Lunar Lander

UPDATE: Download this new, improved version of SimplexSearch.java and use it to replace the version that came with the project.

Overview

Welcome to your final project. You and your partner have been hired to build a flight simulator for the next lunar landing. (Please make sure you have a partner; don't do the project alone.)

You have four weeks to complete a very large program that will simulate landing on the moon, but in the context of a computer game. The coin-op video game Lunar Lander was one of the hits of 1979. We have broken it up into four weekly checkoffs. It is crucial that you do not fall behind—please visit us if you need help. The project is worth 10% (40/400 points) of your final grade.

Calendar

Here is how the rest of the semester looks. There is a project-related due date every Thursday lab.

Monday Tuesday Wednesday Thursday
Week 11
2006-04-03 – 2006-04-07
Lecture & lab
Lecture
Final project is released.
Week 12
2006-04-10 – 2006-04-14
Lecture & lab
Lecture
Checkoff 1 due & verified in lab.
Week 13
2006-04-17 – 2004-04-21
Lecture & lab
Lecture
Checkoff 2 due & verified in lab.
Week 14
2006-04-24 – 2006-04-28
Lecture & lab
Lecture
Checkoff 3 due & verified in lab.
Week 15
2006-05-01 – 2006-05-05
Lecture & lab
Lecture
Lab
Week 16
2006-05-08 – 2006-05-12
Lecture & lab
FINAL PROJECT DUE

Checkoff 1: Put in the 1D physics

A rocket accelerates by expelling fuel at high velocities. By the law of conservation of momentum, the downward thrust of the fuel must be matched by an equal increase in the upward momentum of the rocket. However, because the rocket expels fuel, the lunar lander is always getting lighter, until the fuel runs out. You will encode the relevant equations of motion (including how forces, masses, positions, velocities and accelerations affect each other) so that the lander simulation behaves correctly.

However, to simplify the problem, for this checkoff (which you must demonstrate to the staff by Thursday, April 13) you will only need to solve a 1D problem. The lander is oriented directly above a landing pad. All you have to do is encode the 1D equations of up-and-down motion for gravity, thrust, etc. Once you've done this, you can play the game (the up and down arrows control the thrust) and try to get the best score by landing as softly as possible with as much leftover fuel as possible. Your score is based on a complicated formula involving both of these numbers; see the Scoring section below. If the lunar lander hits the ground with a velocity of greater than 4 m/s, it will crash.

Technical details

Download the Lunar Lander project file here and import it into Eclipse as usual. You will see several classes that contain over 3,000 lines of code (around 400 of these lines will be written by you).

For the simulation, all of your code will go into the LunarLander class which, as you've already guessed, represents a lunar lander. Open LunarLander.java and take a look at what's already been written. Because we are only working in 1D, we will only be concerned with the following instance variables.

```    // Rate-of-change variables
private Vect2D position;  // Position of the center of the lander
private Vect2D momentum;  // Mass * velocity of lander
private double totalMass; // Mass of lander and fuel

// Other state variables
private double throttle;  // Percent engine boost to use
private int status;       // Lander's status (flying, crashed, etc.)
```

The position, momentum, and totalMass variables are our variables that you must calculate at each timestep by integrating the appropriate differential equations. Note that totalMass includes the weight of the lander itself (stored in the constant LANDER_MASS) and the weight of the remaining fuel. The initial amount of fuel the lander has is stored in the constant MAX_FUEL. You must update these variables every timestep.

The throttle is a number between 0.0 and 1.0 (a percentage), and it represents what percentage of the maximum fuel burn rate (stored in the constant FUEL_BURN_RATE) we are using. For example, if our engine can burn at most 100 kg of fuel per second and our throttle is set to .25, then the lunar lander is currently burning 25 kg of fuel per second.

The status variable tells us whether our lunar lander is flying, has crashed, or has landed. It always has one of the following values.

```    // Status constants
public static final int STATUS_FLYING = 0;  // Lander is currently flying
public static final int STATUS_LANDED = 1;  // Lander has safely landed
public static final int STATUS_CRASHED = 2; // Lander has crashed
```

Your job is to fill in the body of the step() method. This method takes in a single argument, the timestep dt, and updates all the rate-of-change variables, as well as the status of the lander (if the lander has crashed or landed safely). The momentum is affected both by gravity and by rocket burn. Make sure to look at the constants defined at the bottom of LunarLander.java, such as EXHAUST_VELOCITY; these will prove helpful.

You should also make sure that you have enough fuel to perform the rocket boost. If there's no fuel left, then the rocket can't thrust.

To complete the step() method, you will need to make use of two other classes. The LunarLanderGame class contains the main() method. You will run this class when you want to play the game. It also contains a static variable called moon (you access it as LunarLanderGame.moon), which contains the Moon object.

The Moon class represents the moon you are trying to land on. It contains information about the terrain and gravity of the moon. For this part of the project, you will need to know the constant acceleration due to gravity and whether the lander is above a landing pad. If you browse through the Moon class, you will find an indispensible method: getGravity(). This is how you know what the gravity is.

In the step method, you also need to check whether you've collided with the terrain yet. The LunarLander class has two convenient methods to help you—isTouchingGround and landedSafely. If your lunar lander landed safely, set its status to STATUS_LANDED. If it didn't land safely but is touching the ground, set its status to STATUS_CRASHED.

After you have finished writing the step() method, go ahead and run the game. Run the LunarLanderGame class with the following command-line arguments: -vx 0 -terrain flat -turbo 2. These arguments tell the game to start your lunar lander with 0 horizontal velocity (we're only working in 1D right now), to generate a completely flat landscape, and to run the simulation at 2x speed.

Checkoff 2 - Put in the 2D physics

The world isn't 1D, it's 2D! No, wait, it's 3D but we will pretend it's 2D for this entire project. That means you have to now handle rotation and horizontal velocity. Rotation can be thought of as an instantaneous single burst of fuel from a side booster, which generates a constant rotational velocity. You do this through the interface by pushing on the left and right arrow keys and holding them down. When you release them, the spaceship stops rotating by generating the same burst of fuel, but this time in the opposite side which stops your rotation. To simplify, we will assume that the amount of fuel used to rotate the craft is proportional to the angle you rotate the craft.

Note that now that you can rotate, you can move out of your confining 1D world! You simply rotate (arrow keys) and then thrust (up and down arrows), yielding an arbitrary 2D position and velocity. As before, your job is to land on any one of the landing pads the softest with the most fuel. However, now there are landing pads with different point multipliers (1x and 2x) which multiply your entire score. Also, you have to land with the legs directly below you and an angle of 0 (you must be straight up-and-down). You are allowed to have a horizontal "sliding" velocity of 2 m/s but as you see from the Scoring section below, that also affects your score.

Technical details

Modify the step() method to handle rotation. We will need to deal with two new instance variables of the LunarLander class:

```    private double angle;        // Current angle
private double desiredAngle; // Target angle
```

angle is the current angle of the lunar lander. An angle of 0 means the lunar lander is straight upright. A positive angle rotates the lander counter-clockwise (its booster would begin facing towards the right and its nose to the left). desiredAngle is the angle that the pilot wants the lander to rotate to. Because the lander can only rotate at a maximum angular velocity of TURN_RATE radians per second, the actual angle of the lunar lander may be different then the angle the pilot desires.

Rotating the craft burns up fuel. The amount of fuel burned per radian is stored in the constant ROTATIONAL_FUEL_BURN_RATE. Just like in the 1D problem, you need to make sure that you have enough fuel before rotating the craft. Since both the main booster and rotation uses up fuel, you should first use fuel for the main booster, and then use any remaining fuel to rotate the lander.

Another complication arises in 2D. The moon is spherical, so our world must wrap horizontally (that is, if your lander's x position is 0 and you move left, your lander's position should wrap around instead of being negative). You can access the "width" of the world by using the getWorldWidth() method in the Moon class. Make sure your step() method wraps your lunar lander's position correctly!

To keep everything simple and consistent, we also want to wrap our lunar lander's angle so that the angle and desiredAngle instance variables always lie in the range between -PI and PI. Make sure you step() method does this.

When you've finished adding rotation, run the LunarLanderGame class without any arguments (or use -turbo 3 to speed up the simulation if it is too slow). This time, a random terrain will be generated, and there will be multiple landing spots of different sizes. Test out your lander and see if you can land it safely!

Checkoff 3 - Create a 1D autopilot

Your job for this checkoff is to write an autopilot lander which will perform a 1D automated landing. This is engaged when you align your spaceship directly over a landing strip. Optimizations of this sort typically are computed offline, and it is unusual to compute an optimal landing during the middle of flight. You are to write the code that figures out how much thrust to apply (ie what throttle settings you should use) so that your lander lands safely. Assume that you are directly over a landing pad, and as soon as you engage the autopilot, the autopilot will set the throttle to some value, and keep it at that value until you land safely or crash violently.

Technical details

The first step to writing the 1D autopilot is to devise a mathematical function that takes one input (a throttle) value and returns a number. We want the function value to be small if the input (throttle) value causes the lander to land gently, and large if the throttle value causes the lander to hit the ground hard. After devising the function, we can use the SimplexSearch optimizer to find the minimum of the function. The input corresponding to that minimum must be a throttle value that causes the lunar lander to land gently. Given a throttle value, how can we determine how hard the lander hits the ground (ie how large is the vertical velocity when the lander hits the ground)? Hint: make a copy of the LunarLander, set its throttle, and run the simulation!

Write a class called VerticalAutopilotFunction which implements the OptFunction interface, just as you've done in lab. This class will be the function you optimize to determine what throttle setting is safe.

After writing the VerticalAutopilotFunction, fill in the skeleton for the VerticalAutopilot class. This class has an engageVerticalAutopilot() method, which gets called when the user presses the space bar. This method should engage the autopilot (ie run the optimizer to determine the throttle setting). The class also contains an updateLanderInputs() method. Once the autopilot is engaged, the game will call this updateLanderInputs() method every time step, and the method should then update the throttle of the lunar lander (in this case, however, we have a constant throttle).

Test out your 1D autopilot! You can first run the game with the -terrain flat option to test out your autopilot on a flat terrain. Later, try playing with a random terrain. Center your lander above a landing pad and hit spacebar to see your autopilot in action.

Project deadline: Create a 2D autopilot; write a final report

As you could guess now your job will be to drive a generalized 2D autopilot landing. Your lander will have an initial position, velocity and rotation, and your job is to "right" your craft, position it over a landing pad, and then perform a 1D vertical landing, thus reducing the problem to one previously solved! So here your job is simply to move your lander directly over a landing spot with no rotation or horizontal motion, and then call the optimizer you just wrote last week!

You have the option of adding a single interesting feature to the project. Feel free to use your creativity here -- this could be as simple as figuring out how to draw "CAL" on the side of the lander, to color-coding the landing "smoke dots" based on velocity, to animating an explosion and crater if the lander lands too hard. Improvements can be internal too, such as improving the autopilot to use less fuel. Again, this is an optional feature; don't feel as if you have to do this.

Technical details

This is perhaps the hardest part of the whole project, but we can break it into manageable pieces. The first step is to write an autopilot which will stop (bring the horizontal velocity to 0) the lander right above a landing site. We can assume that the lander starts with a sufficiently high horizontal velocity and that the lander is rotated so that it can fire it's main booster to slow down. Note that this is almost the exact same problem as the vertical autopilot problem! In the vertical optimization problem, we had a landing height and velocity we wanted to reach. In this horizontal optimization problem, we have an x-position and a horizontal velocity that we want to reach.

First, write a class called HorizontalAutopilotFunction which implements the OptFunction interface and is completely analogous to the VerticalAutopilotFunction, just in the horizontal direction! You will need to first find a suitable landing spot to land on. Look through the Moon class to see if any of the provided methods will help you do this.

After completing the HorizontalAutopilotFunction class, write the Autopilot class. This class is similar in structure to the VerticalAutopilot class you wrote during week 3. However, this class will act as a full 2D autopilot. That is, you can assume you have some horizontal velocity. Your autopilot should rotate the lander so that it can slow down, determine the throttle needed to hover above a landing pad (by optimizing your HorizontalAutopilotFunction class), set the throttle to bring the lander above the landing pad, rotate to straighten out the craft, and then engage the vertical autopilot you developed in week 3.

You can now test your autopilot by running the game with the -auto on option. If all goes well, your autopilot will successfully land your lunar lander.

Your autopilot will not need to work for all possible scenarios. For full credit, you may assume that it will always be possible to land on the nearest landing pad in the direction that you are traveling. You will get extra credit if your autopilot also works when it's not possible to land on that nearest landing pad. We list the scenarios that we will be testing your autopilot with below. To launch a scenario, simply include the noted command line arguments.

```EASY:
-terrain t1.ter -vx 25  (easy to land on 1x to immediate right)
-terrain t2.ter -vx 25  (easy to land on 2x to immediate right)
-terrain t3.ter -vx 15  (easy to land on 2x to immediate right)
-terrain t4.ter -vx -25  (easy to land on 2x to immediate left)

MEDIUM:
-terrain t5.ter -vx 25  (easy to land on 2x to immediate right, but passes world's wrapping point)
-terrain t6.ter -vx -25  (same to immediate left, and passes world's wrapping point)

HARD (these count for extra credit):
-terrain t3.ter -vx 35  (too fast to land on 2x to immediate right)
-terrain t4.ter -vx -40  (too fast to land on 2x to immediate left)
```

Note that the -terrain command line argument allows you to load in a specific terrain file (instead of just a flat or randomly-generated one). Inside the parentheses, we recommend the landing pad that your autopilot will probably find easiest to land on. However, it's okay if your autopilot chooses a different pad, as long as it lands on one. You will get full credit for the autopilot section if it can land in the EASY and MEDIUM scenarios. If not, the easier ones weigh more points than the harder ones. Your autopilot doesn't have to work for the HARD scenarios, but you'll get extra credit if it does.

Tips:

• You'll find it useful to read the public methods for a lot of the other classes. In particular, you should read the public methods for Moon and TerrainSegment. These provide methods that you'll probably want to use in your autopilot.
• In your Autopilot.java method, you should turn your lander to some angle, use SimplexSearch and HorizontalAutopilotFunction to find a thrust that lets you end up over a landing pad with almost no horizontal velocity, actually use that throttle until your lander arrives over that landing pad, turn your lander straight up again, use SimplexSearch and VerticalAutopilotFunction to find what throttle to use to land safely, and then use that throttle. Note that finding what throttle to use with the optimizer is not the same as actually using that throttle! All of this magic should happen in the updateLander method of Autopilot.java.
• When you're testing your autopilot, you'll probably want to use a horizontal velocity that's greater than the default 10, since that's usually not high enough to make sure you can safely get to a landing pad. Something like 25 is more suitable.
• When you're testing the horizontal part, just forget about the vertical part. Once you're done executing the horizontal component, just set throttle to 0 and see if you'll fall straight down onto a landing pad. This should save you some time, since the vertical autopilot takes forever to run, and you don't want to waste time running something that you already know works. After you know the horizontal part works, then add the vertical part (which should look almost identical to what you did for part 3).
• It's really tricky debugging your HorizontalAutopilotFunction. One thing that helps: inside your performance measure or success condition methods, print out useful information to the screen (like what throttle the optimizer is trying, and what score it got) so that you can keep track of what the optimizer is doing, and guess what's wrong. In fact, you'll find it useful to print a lot of stuff to the screen. It's the best way to debug this part.

FINAL REPORT: Your final report will rely on the data recorder component you write for your lunar lander. The final report will be a document that has plots of time versus x-position, y-position, x-velocity, y-velocity, throttle and angle for BOTH a successful manual landing AND a successful autopilot landing. That's 12 plots total (6 for manual, 6 for autopilot)! The plots, as in the lab, should be done in Matlab. You can just copy and paste the plots into a Word document. You should also describe any extra features you implemented for extra credit, what each feature does and how you implemented it. Email the final report to ryanc@cs.

Export your project as a "Zip file"—not as a "Gild Archive"! The Gild Archive option does not export settings.txt or the terrain (.ter) files. Mail the file to ryanc@cs, and include both your partner's name and your name in the email.

Playing

To play the game, run the main() method in the LunarLanderGame. There are three buttons at the bottom of the screen: Start Over, Generate Random Terrain, and Save Flight Data. The 'Start Over' button restarts the game, but the terrain stays the same. The 'Generate Random Terrain' button generates a random lunar landscape and then restarts the game. The 'Save Flight Data' button is only available after a game ends. Press this button to save data such as positions, velocities, remaining fuel, etc. to a comma-separated file.

In the game, use the up and down arrows to increase and decrease the throttle of your engine. Use the left and right arrows to rotate the lander.

The goal of the game is to land your lunar lander onto a landing pad. The lunar lander must be upright and gently touch down onto the landing pad to successfully land.

You can run LunarLanderGame with several command-line arguments to change the behavior of the game. Run LunarLanderGame with the -h option to get a list of command-line options for the game.

Scoring

The equation for your score is determined by your landing velocity and the amount of fuel remaining. In addition, you score is double if you land on a narrow landing pad. The full equation is:

```Score multiplier *
([40000 * (Percentage of fuel remaining - 50%)] +
[30000 * (|Vertical velocity| / Maximum vertical velocity for a safe landing)^2] +
[30000 * (|horizontal velocity| / Maximum horizontal velocity for a safe landing)^2])
```

Terrain

You can imagine that we generated the terrain by orbiting the lunar surface a few times and doing high-resolution range scans. So from your point of view, assume that we know the surface of the moon completely. We encode the terrain as a list of terrain segment. Each segment is a line, so each segment is defined by two end points.