Description

The goal of this project is to give you practice implementing a particle filter used to localize a robotic glider that does not have access to terrestrial based GPS satellites. The glider is released from a spacecraft over the surface of mars, and receives a distance to ground measurement from a downward facing radar, as well as an altitude estimate from a barometric pressure sensor.

Your glider has an on-board map of the area it is being dropped into. The map covers an area 10 km on a side (100 sq km), and the robot is supposed to be dropped somewhere near (0,0). The map was generated by radar from the mars surveyor satellite mission, and has a 1×1 meter resolution. Dimensions in the map range from -5,000m to 5,000m.

Your glider will exit the reentry craft somewhere within the mapped area hopefully near (0,0), but possibly as far off as +/- 250m in both X and Y. It will eject out of the reentry craft approximately 5,000 meters (+/- 50m) above “sea level”.

The orbit of the re-entry craft is designed so that it will enter the Martian atmosphere with a heading of zero radians (due east) with respect to your map, but due to atmospheric turbulence, the actual heading of your glider upon release may deviate from this planned heading based upon a Gaussian distribution with mu=0 and sigma= pi/4.

As mars has a thin atmosphere, your glide ratio is 5:1, which means that the glider moves forward 5 meters for every meter it falls. It moves 5m/sec, and falls 1m/s. This means that you have at least 950 seconds to localize the glider before it potentially goes “off-map” and is lost.

You also have at least 4,500 seconds of “glide time” before the glider risks hitting the surface, but would need to steer the glider to keep it within the boundaries of your known map.

Note that your software solution is limited to 10 seconds of “real” CPU time, which is different from the simulated “glider time”. Unless your localization and control algorithm is VERY efficient, you will probably not go “off-map” or hit the ground before you run into the CPU timeout. If it takes your localization system more than 100-200 glider timesteps to determine the glider location, you may need to improve your localization algorithm.

Note that the radar sensor [sense function] gives you a (noisy) distance to

“ground”, and not “sea level” (on mars, “sea level” is defined as the mean ground height). The barometric sensor [get_height function] gives you the gliders distance above “sea level”, +/- some Gaussian noise.

The glider.py file (which you should not modify, but may examine or import) implements the simulated glider. The opensimplex.py file (which you can safely treat as a black box and should not modify) is used when generating the map function.

The marsglider.py file contains two functions that you must implement, and is the only file you should submit to Canvas->GradeScope.

Part A

The first function is called estimate_next_pos, and must determine the next location of the glider given its atmospheric height and the radar distance to the ground. If your estimate is less than 5 meters from the target glider’s actual (x,y) position, you will succeed and the test case will end.

Note that each time your function is called, you will receive one additional data point, and it is likely you will need to integrate the information from multiple calls to the function before you will be able to correctly estimate your glider’s position. The “OTHER” variable is passed into your function and can be used to store data which you would like to have returned back to your function the next time it is called (at the gliders next timestep). Note that in part A you are not able to modify the gliders path, so it will be gliding in a (relatively) straight line.

Part B

The second function is called next_angle. The goal of this function is to set the turn angle of the glider (via the rudder) so that the glider returns to the center of its map (0,0) as it glides down to the ground. The test will end once you have navigated the glider to within 10m of the (0,0) target.

Your two functions will have the same input (barometric altitude and RADAR distance to ground), but the next_angle function will return a turning angle in radians (zero for no turn) instead of a predicted location.

The goal in part B is to return your glider as close to (0,0) as possible in X and Y. Note that you only need to return the glider to (0,0) once as the z (height) decreases to be successful, and the actual z value when this occurs does not matter as long as you have not hit the ground yet, so you may take multiple passes to return the glider to (0,0).

The Map Function

In both parts, your function is provided with a function (called the mapFunc) as an input. You may call this function with a specific (X,Y) location and it will return the elevation of the ground above “sea level” at that location on the map of the Martian surface. (We are using functional programming and the OpenSimplex noise model so that we do not need to maintain and pass around a large data structure that contains all of the map data. You can safely ignore how the map works, and just make use of it.)