The applet was developed by first implementing the simulation in C++ using the same requirements as for the CS102 student project number one. Once the C++ version was built, optimized, and tested, the code was ported to Java to provide a GUI. The applet was later enhanced to include an autopilot feature (that was first developed in the C++ version). The resulting applet is embedded here below:
Feedback shall be provided on user input so the user knows his commands are received, and the landing velocity shall be presented to the user so that he knows the result of the simulation. Some criteria for success for a "soft" landing shall be utilized and the success state shall be output after each landing.
The simulation is performed in a while() loop that runs when the user clicks the "Start" button. The loop runs while the altitude is greater than zero. The landing speed is defined as the speed at the time slice prior to the altitude becoming zero or less. The time slice is set as an applet private member value, and was optimized by trial and error. Because of the graphical overhead, a rather coarse time slice of 0.5 second was used in the final version of the applet. This is simulated time, not system realtime. The simulation runs in a thread that wakes up every 50 milliseconds to compute the next time slice. Running the simulation in a thread allows the program to receive user input in the applet foreground thread while the simulation is running.
A "soft landing" speed of less than 2 m/s was arbitrarily chosen because tests with the C++ prototype showed it was easily achievable with a constant throttle and an appropriate time slice, and because 2 m/s seems a reasonable speed for a safe landing based on common experience with lander-sized objects such as automobiles.
// Autopilot feature:
if (_bAutoPilot)
{
if (_sfAltitude > 0)
{
if (_sfVerticalSpeed < -0.7 * Math.sqrt(_sfAltitude)) // Lucky hack.
{
_sfThrottle += sfThrottleAdjustment;
if (_sfThrottle > 1) _sfThrottle = 1;
}
else
{
_sfThrottle -= sfThrottleAdjustment;
if (_sfThrottle < 0) _sfThrottle = 0;
}
}
}
The _bAutoPilot variable is a lander private boolean member that is set to
true when the user inputs the "a" key.
The 0.7 factor was arrived at by trial and error. The sfThrottleAdjustment single precision floating point variable is local to the update() function set to 0.2 (also arrived at by trial and error). The square root function was also arrived at by trial and error. It was found to provide better autopilot performance than a linear function. It's labeled a "lucky hack" because, while some insight into a desired lander velocity profile was utilized, it was not derived by a rigorous analysis.
The lander polygon outline has 28 vertices. This number was chosen as a good compromise between performance complexity and graphic realism. The simulated rocket flame polygon has seven vertices. The lander was first sketched on a quad-ruled tablet in pencil and then coordinates were assigned to vertices for hard coding into the lander constructor function.
GUI buttons were chosen for the start and reset function activation because of their ease of use. Keystrokes were chosen (up and down arrow keys) for throttle control because of the naturalness of this type of gamelike interface. The autopilot feature was also enabled with a keystroke because it did not seem worth adding another button for a relatively minor feature. That is, users tend to give equal emphasis to features that have equal prominence in the GUI. The autopilot feature always gives the same lander simulation result and will be little used, while the manual simulation is somewhat challenging to the users and will likely be used much more often. Therefore, the start and reset buttons have much more importance, from the user's viewpoint, than the autopilot activation feature.
The simulated flame varies in length with the throttle setting to give added realism. The flame varies in length from zero to 54 pixels.
The prototype simulation algorithm was programmed in Visual C++ in about two hours including optimization and testing. The key parts of the simulation code were then ported to Java and extended with a GUI. This took about four hours, including optimization and testing. The autopilot feature took an additional two hours to implement, including optimization.