Virtual GPS
Overview
Among Phoenix's various sensors are its GPS module. Phoenix will both continuously write its GPS coordinates to its black box and transmit its position via radio to the ground station to assist with tracking and recovery efforts. Due to GPS rate limits, dependency on a receiver, and refresh rates, the GPS is not considered reliable for deploying the recovery system. However, the GPS is still important for knowing the final location where the rocket touched down.
RPL-Sim's PhoenixPositionProvider simulates the trajectory of the craft while in-flight. It represents the position of the vehicle using a (x,y,z) vector where the origin is the launch site.
Our goal here is to produce a "Virtual GPS" sensor that presents the flight computer with GPS coordinates (latitude, longitude, elevation) based on its internally simulated (x,y,z) position. For example, if the rocket was on the launchpad, its position should roughly match the latitude, longitude, and elevation of the launch site. If the rocket is flying, its latitude and longitude should differ by somewhere between 0.001-0.1 degrees (this represents an average linear distance of 100m to 10km) relative to the launch site.
We also want to simulate the capabilities (and drawbacks of) the GPS subsystem. This includes:
- GPS is not continuous; it has a max refresh rate that depends on factors like line-of-sight to satellites and hardware capabilities. 1 Hz is a good estimate.
- GPS has an error of somewhere between 4-20m. We should simulate this error.
Requirements
- This subsystem should be its own class.
- In the constructor, pass in the:
- Launch site latitude, longitude, elevation
- How much error, in meters, the GPS will have
- The refresh rate
- A seed for random number generation
- The class should have a public function
Vector3 process(Vector3 rocketPosition, double deltaTime). This function simulates the virtual GPS every "frame" of the simulation. The deltaTime parameter is the amount of time that has passed since last frame, in seconds. The function should return the reported GPS location as a Vector3 (latitude, longitude, elevation.)
- While the
process function will be called many times per second, the virtual GPS should reflect the sampling rate of an actual GPS system. Create an internal timer that only updates the returned value every [sample rate] hz, where [sample rate] is passed into the constructor
- For example, if my sample rate is 1 Hz, and I call
process(0.01) 101 times in a row, I should only get two unique positions.
- The GPS position returned should differ by a random error amount that was passed into the constructor. For example, if our error is 20 meters, then we should add a random vector with a magnitude on the interval [0, 20] to the position before turning that position into a GPS coordinate.
- While there is some randomness involved in the error calculation, the error should be deterministic between runs. Use a fixed seed for random number generation.
Testing
This subsystem should be independently unit tested. The test cases are probably not too complicated, but make sure you are exhaustive.
Virtual GPS
Overview
Among Phoenix's various sensors are its GPS module. Phoenix will both continuously write its GPS coordinates to its black box and transmit its position via radio to the ground station to assist with tracking and recovery efforts. Due to GPS rate limits, dependency on a receiver, and refresh rates, the GPS is not considered reliable for deploying the recovery system. However, the GPS is still important for knowing the final location where the rocket touched down.
RPL-Sim's PhoenixPositionProvider simulates the trajectory of the craft while in-flight. It represents the position of the vehicle using a (x,y,z) vector where the origin is the launch site.
Our goal here is to produce a "Virtual GPS" sensor that presents the flight computer with GPS coordinates (latitude, longitude, elevation) based on its internally simulated (x,y,z) position. For example, if the rocket was on the launchpad, its position should roughly match the latitude, longitude, and elevation of the launch site. If the rocket is flying, its latitude and longitude should differ by somewhere between 0.001-0.1 degrees (this represents an average linear distance of 100m to 10km) relative to the launch site.
We also want to simulate the capabilities (and drawbacks of) the GPS subsystem. This includes:
Requirements
Vector3 process(Vector3 rocketPosition, double deltaTime). This function simulates the virtual GPS every "frame" of the simulation. ThedeltaTimeparameter is the amount of time that has passed since last frame, in seconds. The function should return the reported GPS location as a Vector3 (latitude, longitude, elevation.)processfunction will be called many times per second, the virtual GPS should reflect the sampling rate of an actual GPS system. Create an internal timer that only updates the returned value every [sample rate] hz, where [sample rate] is passed into the constructorprocess(0.01)101 times in a row, I should only get two unique positions.Testing
This subsystem should be independently unit tested. The test cases are probably not too complicated, but make sure you are exhaustive.