CS 7638 - Robotics AI Techniques - Meteorites Project
CS 7638 - Robotics: AI Techniques - Meteorites Project
Table of Contents
•Introduction –Submitting Your Assignment •Academic Integrity •Project Description –Environment •Estimation –Estimation Part (a) –Estimation Part (b) •Defense •Testing Everything •Generating New Test Cases •Frequently Asked Questions
Introduction
In this project, Earth is threatened by a shower of meteorites falling in your location. It is your task to receive sensor readings of the locations of these meteorites, predict where each of the meteorites will be one tenth of a second later using Kalman Filters (KFs), and finally, destroy each meteorite threating Earth before it hits the ground by firing your laser turret at it.
This project consists of two parts: 1.Estimation: Estimate where meteorites will be one timestep into the future a.Estimation of a small number of meteorites’ positions with no noise in the observations—5% of grade b.Estimation of the positions of many meteorites given noisy measurements—75% of grade 2.Defense: Aim and fire your laser turret at incoming meteorites before they hit the ground—20% of grade
Submitting Your Assignment
Your submission will consist of ONLY the turret.py file, which you will upload to Gradescope.
Academic Integrity
You must write the code for this project alone. While you may make limited usage of outside resources, keep in mind that you must cite any such resources you use in your work (for example, you should use comments to denote a snippet of code obtained from StackOverflow, lecture videos, etc). For an example of this, note how the author of this project’s code cited the source for the clampfunction in runner.py .
You must not use anybody else’s code for this project in your work. We will use code-similarity detection software to identify suspicious code, and we will refer any potential incidents to the Office of Student Integrity for investigation. Moreover, you must not post your work on a publicly accessible repository; this could also result in an Honor Code violation [if another student turns in your code]. (Consider using the GT-provided Github server for your repository, or a git server such as Bitbucket that does not default to public sharing.)
Project Description
The motion model of the meteorites takes the form x(t) =cposx+cvelxt+1/2Sacccacct2
for the meteorite’s x-position, and y(t) =cposy+cvelyt+1/2cacct2 for its y-position. Sacc=1/3 is a constant.
Time is delimited in discrete steps (t = 0.0, 0.1, 0.2, ...). Each timestep is dt= 0.1seconds in duration. Each meteorite’s motion can be modeled using x,y,dx,dy,a .ais acceleration; note that, due to how the acceleration term is defined, the x- and y-components of a meteorite’s motion are correlated! In most parts of this project, your turret’s observations of the meteorites’ positions are noisy, so you will leverage the uncertainty-handling properties of Kalman Filters to predict their positions more precisely.
Environment:
In this project, your world is a 3-by-2 rectangle, with the X-range [-1, 1] and Y-range [-1, 2]; (-1, -1) is the lower left corner, and your turret is located at (0, -1), with y = -1 being the ground. This coordinate system is used throughout this project to define all entity locations. The laser turret’s aim angle is 0.0 rad when the laser is pointed along the ground to the right, and πrad when the laser points along the ground to the left. HINT: On line 21 of turtle_display.py , ensure the DEBUG_DISPLAY variable is set to Trueto show meteorite IDs and the (x, y) coordinates of the corners of the world in the GUI.
Estimation
Estimation Part (a)
In this part of the project, you are predicting the location of a small number of meteorites one timestep into the future given the meteorites’ current true positions. That is, the measurement information (meteorite_observations ) provided to the predict_from_observations function in Part (a) of the Estimation part of this project is NOTnoisy.
Inputs: The predict_from_observations function takes in a tuple of tuples of meteorite ID numbers, x-coordinate observations, and y-coordinate observations; that is, the meteorite_observations argument has the form ((0, -0.83, 0.46), (1, 0.44, 0.8), (3, -0.72, -0.3), ... (1003, 0.34, 0.1))
Note that the meteorites in meteorite_observations are not guaranteed to be sorted in any sort of order, so do not expect the ID numbers to be sequential—nor should you even expect them to start from 0 or any particular value.
Outputs: The output of the predict_from_observations function should be a tuple of tuples of estimated meteorite locations one timestep into the future (i.e. the inputs are for measurements taken at time t, and you return where the meteorites will be at time t+1). This output should be provided in the same format as the input, meteorite_observations . Note that the ordering of the components in each meteorite’s tuple should be(meteorite ID, x-coordinate, y-coordinate) . Goal:To get full credit for this part of the estimation part of the project, your predict_from_observations function will need to provide “close enough” (within 0.01 units of distance of each meteorite’s true position) predictions of the meteorites’ positions for 75 consecutive timesteps before 400 timesteps have elapsed.
The meteorites in case0.json are not subject to acceleration, whereas the meteorites in case1.json are subject to acceleration.
Due to the lack of noise on the meteorite observations in this part of the project, it is possible to pass this part of the project using only the prediction step of the Kalman Filter and ignoring the measurement update step. As for why this could cause problems in the remainder of the project, please see the Why bother implementing a Kalman Filter for the non-noisy Estimation part of the project? question in the FAQ.
NOTE:Due to the ordering of steps of the simulation in runner.py, when considering the Prediction and Observation steps of the KF, for this project, perform the Observation step before you perform the Prediction step.
How To Test Your Part (a) Estimation Code To test your code on an estimation case and see a visualization of the simulation, run the following in your Python environment (the caseargument may be 0 or 1; the command to run case 0 is shown here): python test_one.py --case 0 --display turtle kf_nonoise This will run a simulation with a visualization similar to that shown in “How To Test Your Part (b) Estimation Code.” A similar command lets you run the test with only text output (no visualization). This text-only mode is what test_all.py uses. (see “Testing Everything” below) python test_one.py --case 0 --display text kf_nonoise As before, the caseargument may be 0 or 1.
Notes on testing your Part (a) Estimation Code This part of the project is meant to help you verify that your KF works correctly in simple scenarios before applying it to more complex scenarios. Passing this part of the project does not guarantee that your KF is set up correctly, but case0.json and case1.json are small enough test cases that you can work through a timestep or two for one or more meteorites by hand while stepping through your code with a debugger to verify that your KF implementation is consistent with your hand calculations. If your code passes these no-noise cases but cannot pass the noisy cases in Estimation Part (b), we recommend verifying your KF implementation by changing the noise_sigma_x andnoise_sigma_y in your local case0.json and case1.json test cases and working through a timestep or two of the simulation by hand to identify where your KF’s handling of noise may be incorrect.
Estimation Part (b)
In this part of the project, you will be estimating the location of each meteorite visible on the screen one timestep in the future given noisymeasurements of meteorite locations you have for the current timestep (meteorite_observations ).
Inputs: Same as in Estimation Part (a), but this time, the x- and y-components of the measurements provided in the meteorite_observations argument are noisy.
Outputs: Same as in Estimation Part (a).
Goal:To get full credit for this part of the project, your predict_from_observations function will need to provide “close enough” (within 0.02 units of distance of the true position) position predictions of at least 90% of the meteorites within the 3-by-2 box for five (5) consecutive timesteps. This must be accomplished within 400 timesteps (40 seconds) (and on Gradescope or when using test_all.py , within 10 real-world “wall-time” seconds). Passing back predictions for non-existent meteorites (e.g. meteorites that have hit the ground and have an ID of -1) will not affect your score.
NOTE:Due to the ordering of steps of the simulation in runner.py, when considering the Prediction and Observation steps of the KF, for this project, perform the Observation step before you perform the Prediction step.
How To Test Your Part (b) Estimation Code To test your code on an estimation case and see a visualization of the simulation, run the following in your Python environment (the caseargument may be 2-17; the command to run case 2 is shown here): python test_one.py --case 2 --display turtle estimate
When you run a case with the turtlevisualization option, you should see something like what is shown in the image below. The gray circles represent the actual locations of meteorites. A red dot indicates a prediction that is too far from the meteorite’s actual location to count as correct, and a green dot indicates an estimate close enough to be counted as correct.
Figure 1: Estimation visualization
A similar command lets you run the test with only text output (no visualization). This text-only mode is what test_all.py uses. (see “Testing Everything” below) python test_one.py --case 2 --display text estimate As before, the caseargument may be 2-17.
Defense
For the defense part of the project, you will be devising a simple algorithm to aim and fire your laser turret at falling meteorites. The defense part of the project makes use of the predictions of the meteorite locations computed by predict_from_observations in the Estimation Part (a) portion of the project. (HINT: Don’t over-think your strategy here; perhaps simply aiming at the lowest meteorite above some minimum threshold is sufficient!) A meteorite is destroyed with probability 0.75 if the laser line comes within a small distance (the value denoted as min_dist in the relevant case file) of it. When the laser fires at time t, the shot hits the meteorite at time t+1. The laser line itself is 1.1 units of length long, measured from the turret. The laser can only fire a limited number of shots before it runs out of power; the number of shots remaining are displayed in the GUI or command line output. The turret’s position is fixed at an x-position of 0 and a y-position of -1; the turret may rotate, but not change its x-y position. Each meteorite’s ID number is unique as long as the meteorite has not been destroyed. When a meteorite is destroyed, its ID number is set to -1. This ID number change is handled by the simulation. Keep in mind that you may want your turret to check that it does not try to aim at a meteorite with an ID of -1! Inputs: This function takes in a float corresponding to the laser turret’s current aim angle, in radians. Outputs: The output of this function is a tuple containing two values: •Float: The change in aim angle (in radians) you want the laser to execute; if the magnitude of this value is greater than max_angle_change (0.0873 rad; approximately 5 degrees), it will be lowered to max_angle_change rad, but with the sign of the angle you outputted. •Boolean: True if the laser should fire the next timestep; False, otherwise. Thus, the laser turret can both rotate and fire in the same timestep, if desired. Note that the float should be returned first and the Boolean second (and that enclosing parentheses are optional when returning a tuple from a function). Also note that trying to move the laser’s aim outside of the [0, π] range will result in its aim being clamped to 0 orπ, respectively. The laser’s aim angle does NOT wrap around—if you output an angle change that would set the laser’s current aim to, say, 3.3 rad, the laser’s aim will stay πrad until you change the laser’s aim back to within the [0, π] range. Goal: Your goal in the defense part of the project is to make sure your laser turret survives for 400 timesteps. Your laser turret starts with a specific number of health points (HP), which are shown below the turret in turtle simulation mode and printed to the command line in textmode. Each time a meteorite hits the turret or the ground (y = -1), the turret loses one HP. Credit is given for a case if the turret’s HP is 1 or greater by the end of the 400-timestep but (on Gradescope and in test_all.py , there is also a 45-second wall-time time limit); no credit is given if the turret’s HP drops to 0 within that time limit.
How To Test Your Defense Code
To test your code on a defense case and see a visualization of the simulation, run the following in your Python environment (the caseargument may be 2-17): python test_one.py --case 2 --display turtle defense When you run the above command, you should see something like the image below. A similar command lets you run the test with only text output (no visualization); this is the mode that test_all.py uses to run all test cases. (See “Testing Everything” below) As before, the caseargument may be 2-17.
Figure 2: Defense visualization python test_one.py --case 2 --display text defense
Testing Everything
To test all of the local estimate and defense cases using the textdisplay option, use the command python test_all.py This is the testing mode used by Gradescope.
Generating New Test Cases
The cases used for grading on Gradescope are similar to those provided to you, but not the same. You can usegenerate_test_case.py to generate additional test cases to more rigorously test your code, To see all of the command line arguments for the generate_test_case.py script, run the following in your Python environment: python generate_test_case.py --help
To create a new case, run as follows: python generate_test_case.py my_case [additional arguments here] To use this new test case, pass the filename to test_one.py using the --caseargument: python test_one.py --case my_case --display turtle defense Note: The new case files are not included in the cases executed by test_all.py .
