Univ. or Virginia Senior Thesis on flight computer for TFN.

1. System and Network Architecture Design
for an Open Source Lunar Lander
A Technical Report
in STS 4020
Presented to
The Faculty of the
School of Engineering and Applied Science
University of Virginia
In Partial Fulfillment
of the Requirements for the Degree
Bachelor of Science in Computer Science Engineering
by
Boone Adkins
&
Cameron A. Eshgh
May 10, 2010
On my honor as a University student, on this assignment, I have neither given nor received
unauthorized aid as defined by the Honor Guidelines for the Undergraduate Thesis.
___________________________________________ ________________
Boone J. Adkins Date
Approved by:
___________________________________________ ________________
John Knight, Ph.D., Computer Science Engineering Date

2. Abstract
This paper serves to outline the efforts undertaken by the group of students at the
University of Virginia in conjunction with Team FREDNET, an international organization
competing in the Google Lunar X Prize competition to be the first to land a privately funded
lander and rover on the moon. Under the careful supervision of Professor John Knight
(Computer Science), the team sought to address the software specification needs of the lunar
lander system, which at the project’s commencement were in need of revision and
augmentation. The team over the next several months built several software packages each
designed to address a specific need of the system, such as gathering sensor data, controlling
the engines, etc. Utilizing an event-driven synchronous approach, the system has taken the
road toward processing data in real time. This approach has helped to ensure data integrity as
well as ensuring that real time is attainable for the system. The packages were created in such
a way that they could run independently, but had the ability to be run in conjunction with one
another, thus creating a larger simulation package. This package has been used to test and
further refine software specifications and over time has been developed into a viable
demonstration system. Once the system was integrated with the Orbiter Spaceflight Simulator,
the system was then able to provide a visual testing and simulation harness to make the
underlying system more tangible and easier to interpret. Finally, this paper goes into the
successes of the project, the simulation capabilities being one, as well as citing areas for future
improvement.

3. Project Overview
This project was undertaken as a part of the Google Lunar X Prize competition. The
competition involves landing a privately funded robot on the moon’s surface and then returning
pictures and HD video back to earth. The prize for the first such successful mission is $20
million. Several teams are currently participating and vary greatly in their flight experience.
One such competitor is Team FREDNET. FREDNET is devoted to creating an open
source, open collaboration solution to the competition. This model proves very friendly to
students, as it is very open to adding team members and inviting contribution. The software
requirements, when this project began, were very rudimentary and in need of work. Up to that
point, FREDNET had not spent as much time focusing on this aspect as it had working on models
of lunar landers and rovers for the mission. In response to this need, several software packages
were built. This was primarily for the purpose of simulation in order to reevaluate the
specifications that were in place at the time, adding or changing as it was seen fit. This set of
packages quickly became a plausible and viable demonstration system that has also continued
to serve as the primary system simulation and testing method.
Providing guidance and insight into the project was John Knight. Professor Knight is at
the Computer Science Department at the University of Virginia. He served as a faculty advisor
who was there whenever a wall was hit or an obstacle was encountered that seemed notably
difficult. Given his background in safety critical software, especially that which is used onboard
commercial airplanes, there was never a problem encountered that did not have an answer

4. soon thereafter. Many of the issues faced in this project were problems that arise typically in
flight software; therefore there was never a real problem during development.
Purpose
From the beginning of the project, there was a well defined purpose, which was to build
a functioning mock-up of Team FREDNET’s lunar lander system. This mock-up needed to first
take into account the computer systems that will be onboard the lander. The object for this
component was to make as few assumptions about it as possible, therefore making the mock-
up unassuming and versatile. The second aspect the system needed to take into account were
the external systems, those elements such as sensors and the ground station on earth which
are not part of the computer system itself, but do interact with it. Once again, few assumptions
could be made, but this provided the challenge of even more adverse scenarios than the
computer system did.
The decided upon criterion for the computer systems were that it had to be
synchronous, distributed and utilize a data bus. The system had to be synchronous so that
communication could be guaranteed throughout the system at all times. Also, a synchronous
system was the only way that real-time computing onboard could be achieved. The system had
to be distributed in the sense that different components of the system could be run on
different computers to better emulate the real passing of information over the resulting
computer system. To accomplish this, all elements needed to guarantee isolation in that no
one subsystem relied on direct interaction with another subsystem, but that interaction was
accomplished through intermediary sockets. The data bus was decided upon as that is exactly

5. what the end system will use. A time-triggered (where access to the bus is decided based on
clock cycles) bus was used to help ensure the system remained synchronous as well as to
improve system reliability.
The four external systems were the ground control, sensors, actuators and spacecraft
dynamics. The ground control is an early model of what someone guiding the mission would
need to see as well as a way to input commands sent to the lander during the mission. These
commands typically will be to alter engine thrust in order to either adjust trajectory, orientation
or velocity. Sensors are how the computer system gets its input; therefore they are critical
within the system. All external data will be processed by the sensors which will pass this along
to the computer system. The actuators will be what help direction the engine, so the computer
system will certainly need to interact with these entities. It is understood that most likely an
engine will have an advanced programming interface (API) for such tasks; however in the spirit
of versatility, it was decided to treat this ambiguously. The spacecraft dynamics are how the
spacecraft interacts physically to the stimuli affecting it. This is everything from time dilation to
gravity to the spacecraft’s own engines. In order to make the project useful in the least, a good
approximation of these pieces was absolutely necessary.
The purpose of the mock-up itself was simply to make it easier to test a specification for
errors and especially omissions (Heninger, 1980). The model system was designed to provide a
useful debugging tool that would be helpful because of its ability to visually expose operation of
the various components. It also needed to have a separation of each of the subsystems to
ensure the system was easy to replace certain simulations with real components later on in

6. development. Practically, it should also be able to evolve into the final, real system that will be
used in the lunar lander. The system was supposed to create a means for simulation of the
existing model and verify specifications, altering when necessary. Finally, the mock-up was for
pedagogical purposes as it is easier to understand a system when it is tangible. This system
could potentially be used in such application as another spacecraft, an automobile, aircraft or
even a robot.
Design Overview
This section is devoted to the design decisions made by the group. The first of these
decisions was what programming language to use based on the requirements for the system.
After this development, the decision was made to make the system modular. Also, there was
the decision to utilize sockets as the method for passing data between subsystems. Finally, it

7. was agreed that the system needed to be clocked, but it needed to be determined how to go
about that task.
The project chiefly utilizes Java in as many instances as possible. This decision was
made mostly based on the comfort with Java of the programmers involved in the project.
Having taken more than one class where Java was the focal language, there was a good level of
familiarity with this language. This also allowed for the focus to be placed on functionality
rather than syntax and other programming subtleties. Another benefit of Java is its portability
as it can run on any machine with little difference so long as a virtual machine is there to
interpret the code into machine language. The performance of Java was also a plus as it is
independent of operating system and runs at a speed comparable to other programming
languages. If speed does become an issue, there are compilers that can help to optimize the
code allowing the simulation to run faster if it is necessary. For this application, a good
estimate of system performance was suitable, even more valuable at this stage than a real
performance evaluation. Inheritance is made simple in Java which made for less time and
effort spent writing code and more time available for testing and verification. This was most
utilized in the clocking of the system, implementing the various modules, as well as the
networking which used threads to help keep all of the socket connections from interfering with
one another.
It was imperative that the system be modular so that various physical components could
indeed replace the simulated parts, making the system truly useful. In order to do this, each of
the components needed to be useful individually. This was achieved through rigorously

8. ensuring that both data and functional dependencies were avoided always. For instance, a
class was created to control the time within Orbiter Spaceflight Simulator, which helped to
provide a more intuitive and tangible simulation environment for the system. This class, while a
part of Orbiter, can easily be removed from the simulator to help provide a more realistic
environment. All graphical user interfaces (GUIs) were implemented in such a way that the
program can be run with or without them without any problems whatsoever. Sockets helped
to keep subsystems separate, so that all communication between them could be completed
whether they were on the same machine, machines across the room or even the globe. This
means that any component can be replaced with a physical model and the system will not be
rendered useless. This modularity also helped significantly in enabling unit testing of various
components. It was far easier to test because there were no dependencies that slowed down
test creation or hindered debugging analysis.
The sockets themselves were a large design decision for the group. They are easy to
work with and have a very well defined API especially in the Java programming language. The
functionality and behavior of sockets is relatively well understood which was another benefit of
this decision. As mentioned, they also helped significantly in keeping the system modular. The
sockets are an important reason why this model is believed to be able to evolve into the final
system that will be aboard the lunar lander. Sockets also give the ability to run multiple
processes as such, all as one or on different computers, but whatever the choice, they enable
versatility.

9. Implementing a synchronous system was delegated to a clocking class. The class
generates clock “ticks” after a specified interval. On each tick, the class broadcasts clock pulses
to connected system components over a set of sockets (dedicated to clocking). Receiving
components generate a Java ActionEvent that executes the clockedAction() method. Clocked
objects and those that inherit from them (such as Modules) can override clockedAction() to
enable synchronous functionality. The clock gives the system its sense of time.
The user has runtime control the clock. Using the method setPeriod(), the system can
be slowed down as much as needed or run as fast as the CPU can handle. The clock can be
paused and unpaused, aiding in debugging. In future versions, the clock will be able to step a
single pulse, a feature common in software engineering debugging tools. A GUI has been
provided for easy access to this control. See the GUI section for more details.
The clock, or more accurately a child class of it, has been linked to Orbiter, through our plugin
TimeLord. This connection uses a special socket. Rather than broadcasting pulses over it, the
clock sends time accelerations and pause/unpause commands to keep the computer simulation
synched with Orbiter. See the Orbiter Spaceflight Simulator section for a full explanation.
Network
In an attempt to ensure a high level of similarity to a physical system, the networking
was meant to be as passive and minimal as possible while maintaining functionality. The
network component of the system is comprised of a class which represents a data bus and a
network interface (NIC) class. The data bus class, NetSim, simply listens for messages to enter
the bus and then passes the message on to all other modules that are connected by the bus.

10. The NIC class, NicSim, acts as an intermediary between each individual module in the system
and the NetSim.
The network was meant to simulate a time-triggered bus. This means that the system
operates synchronously from a clock that is connected to every individual component. Each
module is allotted a time slot based on this time-triggered system helping to ensure the
network is not overrun with data rendering it useless. The bus utilizes a round-robin approach
to time slots, where a certain component can be granted more frequent access to send data on
the bus based on its criticality to the mission. Not only does this decision help to ensure
functionality of the system, but it also helps implement versatility based on the scheduling
freedom. As mentioned earlier, the bus is passive and does nothing more than “listen” on a
socket for data to be sent to it from the NICs connected at the other end and then broadcast it
to all the other sockets which act as broadcast channels in this case.
The way messages are passed over the sockets is through the use of ObjectInputStreams
and ObjectOutputStreams. This decision allows for a much simpler passing of data through the
system. There is no need to break messages down into parts and then reconstitute them once
they have reached their intended recipients. The send command is reduced from roughly ten
to one line of code. The ObjectInputStreams and ObjectOutputStreams are also helpful as they
are blocking which helps to ensure the messages do indeed get passed through the system in a
reliable fashion. While the imitation of the end system may be slightly further than an
implementation that passes smaller amounts of information across the network at a time, it

11. was decided that at this time, ObjectInputStreams and ObjectOutputStreams were a close
enough approximation at this stage.
The NICs, while slightly more active than the network, were also made to be as passive
as possible while still imitating realistic functionality. The only real initiative taken by the NIC
occurs when a message is received from the network over the connecting socket, where the
NIC forwards the message to its corresponding module component. Otherwise, action is
spurred by the module calling on the NIC to send its message onto the network. Since a real
NIC is rather integrally connected to a module, the system was implemented without sockets
connecting the NIC to the module and instead, publicly addressable methods are used. Given
the nature of a physical NIC, it seemed necessary to give the simulation some agency in the
system as a means of becoming more realistic, unlike the implementation of the network bus.
Modules
The abstract class Module represents a generic computer application connected to the
clock and the data bus. All Modules are connected by the data bus, and communicate by
reading and writing from their NICs (more on that in the networking section). To implement
synchronous functionality, a developer just needs to overwrite a single abstract method,
clockedAction(). The developer doesn’t have to write a single line of networking code. A
Module represents a unit of functionality - whether it is a process on a computer, a dedicated
computer, or an integrated circuit. A Module’s vague physical definition reflects a design
principle we have followed throughout the project. The term we use, functional transparency

12. means that the system modeler can test functionality without having to define implementation
details.
Our current model has five Modules. Three of them – Data Acquisition (DAQ),
Guidance, and Engine Control – form the control loop that includes the spacecraft simulation in
Orbiter. Another two modules – the Telecommand Uplink and Telemetry Downlink – handle
communication with a mock ground station (signal directions are from the ground station’s
point of view). The Modules currently implement bare bones functionality… they demonstrate
the potential of the system, rather than a supremely accurate model.
As currently written, the Data Acquisition Module is simply a relay. It reads state data
(position, velocity, orientation, angular velocity) from Orbiter (through the TestEnv proxy) and
passes it to TelemetryDownlink and Guidance. Developers have the options of receiving data
synchronously (by using clockedAction()) or asynchronously (by using an event trigger or
threads). Future versions of the DAQ will perform state and attitude determination from mock
sensor data (e.g. radar readings, star positions) generated by Orbiter or the Test Environment.
The Test Environment proxy has two purposes. First, it splits the two way socket coming
from Orbiter into two separate sockets going to DAQ and from Engine Control. Second, and
more importantly, it gives simulation builders the option to simulate realistic sensor behavior,
such as sensor noise or sensor failure, without having to implement them at the spacecraft
level. The spacecraft code can focus on gathering perfectly accurate data straight from the
simulation.

13. The Guidance Module controls the spacecraft. It currently uses very simple proportional
control to determine thrust levels. The reference signal is generated from DAQ data; more on
that in the Orbiter section. The Guidance module can also perform rudimentary attitude
control – stopping firing thrusters to stop a spin. However translational control and orientation
control have yet to be implemented. The Engine control Module currently acts as a relay,
passing thrust commands from Guidance to Orbiter (through Test Environment). In the future,
control could be split between Guidance and Engine Control – the Guidance performs high level
control (what thrust, what orientation), and engine control turns that into exact engine
commands – thrust levels and possibly gimbal angles. Alternatively, the control algorithms may
be tightly integrated and all be performed in the Guidance Module. By implementing
EngineControl as a separate Module, both options are open to simulation builders.
The Telemetry Downlink Module receives numbers from the DAQ and passes them
down to the ground station. Numbers currently sent are position, velocity, orientation, and
angular velocity. Future telemetry could also include state of spacecraft systems, e.g.
temperatures, fuel levels, and even high bandwidth data such as images and video. It is up to
the system designers whether high bandwidth data transmission should be implemented in a
different Module (and in the real system, with a different antenna)! Currently, the Telemetry
Downlink does not follow any protocol. Future version of the system could follow a standard
space protocol and could closely model data transfer rates. The Telecommand Uplink receives
commands from the mock ground station and passes them to other modules. The first field is
an integer that corresponds to the MID of the destination module. Future versions would likely

14. not differ much in functionality – they would serve as relays for commands from ground.
However, it too would also follow a standard space protocol.
The TLDL and TCUL Modules pass TCMessage objects, an approach that supports
functional transparency. These objects contain Java containers that can hold any Java Object
type, in any order. Grouping data into Objects is similar to the packets used by most computer
communications, but it also shields the modeler from having to worry about protocol details,
such as what byte means what or where one message ends and another begins.
Ground
One of the later pieces incorporated into development of the system was the ground
station which will be monitoring the spaceship’s system and providing commands throughout
its mission. This was begun later as it does not provide core functionality to the simulation or
the lunar lander system. This subsystem is comprised of a link to the spaceship which includes
a time delay to simulate that experienced in space missions as well as a class that is linked to a
Data Interface which displays flight data and can be used to send commands to the spaceship.
The link is a simple Java socket connecting to the Telemetry Downlink and
Telecommand Uplink modules. There is a sleep command that is implemented in the link which
can be adjusted later on to more accurately reflect values experienced continuously throughout
spaceflight. The thread that the socket is running on pauses for a certain count and then allows
the message passage to its intended recipient.

15. The Data Interface is a straightforward display that shows such values as longitude,
latitude, lander state, orbiter parameters and other important values. It is meant both as a
window into the operation of the lunar lander as well as a command input interface. The
values on the screen can be used by the controller to signal that the lunar lander getting off
course for instance, which the controller can correct immediately with a simple engine
command.
User Interfaces
There are three graphical user interfaces included in the system. The first of which is
dedicated to the manipulation of the clock which dictates the simulation’s execution speed.
The second of which is devoted to displaying the values of each of the modules. The last of
which is for the ground station.
There is one specific user interface solely devoted to operating the simulation clock.
This interface allows the user to pause and resume clock functionality in order to take a closer
look at internal system values. Also, the user from this interface can change the period, or the
time that passes in between clock pulses being sent out to the rest of the system to prompt
further action. The clock window has two arrow buttons to assist with simple increasing or
decreasing of the clock period. Also, there is a text box that allows the user to see the current
clocking period, but the user can also change that from here as well.
The second interface serves to give the user a real look under the hood of the simulation
structure. All output messages from the modules are redirected here. Therefore, at any
moment, the user can view all the inputs for each of the modules and compare the spacecraft

16. performance against the predicted effects of the external system. The interface also captures
all messages that are sent to or leaving each module, so the user can ensure that the data being
passed through the system is consistent.
The last interface is devoted to the ground system. This interface provides a limited
version of the second interface as it displays the values for each of the modules. It also displays
the data received from the spacecraft’s Telemetry Downlink. From this window, the user can
also send commands to the spacecraft via a command line, though it is not as intuitive as a
more visual interface would be.
Orbiter Spaceflight Simulator
Orbiter is a free spaceflight simulator that was modified for use as our test environment.
Orbiter was written singlehandedly by Martin Schweiger, an English university professor. While
closed source, it has an extensive API and is very plugin friendly. There is a thriving online
community surrounding the application, including users and developers of all sorts. Most of
the latest Orbiter functionality has come from third party additions. (Schweiger, 2004)
Orbiter’s capabilities made it attractive as a test environment. It simulates Newtonian
mechanics and rigid-body dynamics in real time. Orbiter supports time acceleration ranging
from 1000x down to 0.1x. It uses several techniques for time propagation, depending on the
rate of time acceleration. Its Runge-Kutta numerical integration is well suited to the timescales
of a lunar landing; its stable orbit propagation under time acceleration is well suited for lunar
transfer. It can model atmospheric, suborbital, and orbital flight. Orbiter spacecraft are fuel
limited. Its gravitational model accurately depicts gravitational torque and gravity from non-

17. spherical sources. Finally, Orbiter is visually attractive, rendering lit and shaded 3D models of
both planets and spacecraft. It supports spacecraft animations (e.g. opening hatches,
extending an antenna) and visible exhaust plumes. The third party add-on Orulex adds support
for 3D planetary surfaces, based on real geological data. (Litvinovich, 2008)
Orbiter’s limitations make it a less than ideal model, but still a useful one. It handles
collisions poorly – spacecraft can fly through mountains, and crashing spacecraft bounce
comically upon impact! It also has a very basic rocket engine model – all Orbiter engines
completely throttleable, and produce thrust instantaneously (rather than following a thrust
curve). However, both of these issues both be rectified by the spacecraft programmer. A more
refined thrust model could easily wrap Orbiter’s crude model, and the spacecraft model could
be destroyed if it reached zero elevation at a high velocity or a poor orientation. However,
since our system’s main purpose is to simulate a computer system, Orbiter’s limitations are of
limited concern.
We built two plugins to connect Orbiter to our computer system simulation. We
isolated their functionalities to make them possibly useful to the Orbiter community. The first
add-on, TimeLord, is a general purpose add-on that enables remote control of Orbiter’s time
propagation. By sending doubles over a TCP socket, users can pause and unpause the
simulation and set its time acceleration. To maximize its adaptability, more complex
functionality is left to the external application.
In our case, an extension of our Clock uses these simple commands to sync its time with
Orbiter’s time. Our extended clock can still receive its pause, unpause, and set period

18. commands asynchronously. However it executes them synchronously, letting Orbiter run until
the end of a clock period (i.e. right before the next clock pulse is broadcast). On the next clock
tick, the clock signals Orbiter and performs its own housekeeping, changing the period of its
internal timer or stopping it altogether.
Before signaling Orbiter after a period change, the clock calculates the appropriate time
acceleration to match elapsed computer simulation time with elapsed flight simulation time.
This calculation is based on the real period and the simulation period (how much simulation
time passes with each clock tick). Since computer system time is fast (synchronized on the
order of 10-100ms per clock tick), Orbiter’s minimum time acceleration of 0.1x is not fully
adequate. To compensate for this, our clock runs Orbiter at 0.1x and then pauses it for the rest
of each clock cycle, resuming simulation on the next clock tick (or not, if the clock was paused in
that time period.)
Our second plugin, currently unnamed, provides two way communications with an
Orbiter spacecraft. Intended for developers, it is a C++ class that makes it easy to receive
commands and send telemetry by reading and writing doubles. It is up to the developer to
decide what protocol to use. In our simulation, the first three doubles fire the vernier engines,
the fourth the main retro engine, and the remaining six the attitude control groups. Our
telemetry is encoded as three doubles each for position, velocity, orientation, and angular
velocity (in that order). The possibilities also exist for simulating non-flight related telemetry
and commands, such as for onboard cameras, or deploying the rover.

19. Our current lunar lander and demonstration mission is closely based on the Surveyor
robots which NASA landed on the moon in the early days of the space race. It has two attitude
jets on each of its three legs, three vernier engines, one of which can be gimbaled slightly, and a
large, solid retro engine. Approaching at a steep angle, it ignites the solid engine at ~80km. It
follows a descent profile of velocity equal to square root of attitude. In the final stages, it
descends at constant velocity before cutting engines and dropping to surface.
Team FREDNET’s design is still in its early stages, so it is difficult to obtain accurate
parameters. It shares Surveyor’s triangular symmetry. However, instead of three vernier
engines, it will have a single large main engine and six small vernier engines for descent and a
collection of attitude control jets. Our current impression is that the mission will be a direct
descent, however Team FREDNET may yet switch to a descent from lunar orbit.
Lessons Learned
It is ironic that, though our project was designed to help determine requirements, we
still struggled with ill-defined requirements. Early on, FREDNET did not provide us with
adequate requirements to build a system. So we designed our own system that we believed
would satisfy their mission requirements (which ARE well defined by the Google Lunar X Prize).
We learned valuable lessons about group dynamics as well. While we were busy
building the skeleton of the system (the networking, the clocking, etc…), the aerospace
engineering in the group were given nothing to do. Their expertise was not needed to design a
point particle simulation. Rather, we should have built that simple system ourselves, and set

20. the aerospace majors on designing the mechanical properties of the final system – one with
rigid body dynamics, realistic engine response, simulated sensors, and full attitude control.
This was an object lesson in the importance of identifying and planning around bottlenecks in
project flow, which in turn requires an understanding of the capabilities of teammates in
different disciplines. Instead of making teammates wait for each other, having the software
engineers work in parallel with the aerospace engineers would have been more efficient.
Another import group dynamics lesson was to keep the initial design group small.
Trying to incorporate too many opinions led to a bloated, disorganized design.
Future Work
This project was designed to have a long term future. The components were designed
to individually accomplish simple tasks, opening wide possibilities for applications. To that end,
we have three packages to publish – Java classes and two Orbiter plugins. To publish them, we
need to build a simple web site. We need to clean up the code enough to be useful open
sourced. And we need to provide extensive documentation. In addition, we must maintain the
demonstration system that we deliver to FREDNET, helping them make additions to it and
instructing their coders.
The demonstration system could be made more realistic. Support for simulating
asynchronous data bus would open a variety of other bus protocols. The physical model could
be improved by more realistic engine response, following thrust curves (implemented in the
Orbiter spacecraft, or possibly even an extension of Orbiter’s existing thrusters). Sensor data

21. could be simulated to test attitude and state determination systems, and noise and sensor
failure could be added to test robustness. The system, which is a simplified model based on
Surveyor, could be made to better mirror Team FREDNET lander specifications and mission
profile, as they become available. The system’s scope could be expanded to cover more of the
mission, ranging from lunar injection and transfer to rover debarkation (which could easily be
done with the Universal Car for Orbiter modification).
Conclusion
Though not completely meeting our initial lofty goals, the project was a success. The
final system represents nearly every component of the real system in some rudimentary form
or another. The system is flexible enough that it can simulate specifications without regards to
implementation detail, or to slowly evolve into the real system. We have three distributable
software packages: a Java package with bases classes for our simulation system and two Orbiter
plugins, one to control time, and one to control a spacecraft. Through Orbiter we have an
aesthetically pleasing and interactive (as far as zoom and camera angle are concerned)
representation of the lunar landing, and potentially, the entire mission. We also provide a
wealth of information and control over the simulation, including what would be available in the
real system (e.g. ground control, telemetry) and debugging capabilities (e.g. the Module
display, controlling the flow of time) that are only available in the simulation. As for human
resources, we have Sam Li to continue the effort and recruit a new team, and Professor John
Knight to continue as its advisor.

22. Sources
Cheng, R. K. (1964). Surveyor Terminal Guidance (No. NASA-CR-57550). NASA Jet Propulsion
Laboratory.
Cheng, R. K., Conrad, D. A., & Meredith, C. M. (1966). Design Considerations for Surveyor
Guidance. Journal of spacecraft and rockets, 3(11), 1569.
Citron, S. J., Dunin, S. E., & Meissinger, H. F. (1964). A Terminal Guidance Technique for Lunar
Landing. AIAA Journal, 2(3).
Dunn, J. C., & Sobierajski, F. (n.d.). An Explicit Closed-Loop Controller for Gravity Turn Landing
Maneuvers. AIAA Journal, 6(12), 2424-2426.
Feng, T. Y., & Wasynczuk, C. A. (1968). Terminal Guidance for Soft and Accurate Lunar Landing
for Unmanned Spacecraft. Journal of Spacecraft and Rockets, 5(6).
Henninger, K. L. (Jan 1980) Specifying Software Requirements for Complex Systems: New
Techniques and their Application. IEEE Transactions on Software Engineering, Vol. SE-6,
No. 1.
Litvinovich, Artyom. (2008). Orbiter Ultimate Experience: Orulex 1.2.x. Landscape Generation
for Orbiter Spaceflight Simulator. Retrieved from http://orbides.1gb.ru/
Loucks, M., Carrico, J., Carrico, T., & Deiterich, C. (2005). A Comparison of Lunar Landing
Trajectory Strategies Using Numerical Simulations. Presented at the International Lunar
Conference, Toronto, CA.
Schweiger M, Orbiter: A free spacecraft simulation tool, 2nd ESA Workshop on Astrodynamics
Tools and Techniques, ESTEC, Noordwijk, 13-15 September 2004. Retrieved May 8, 2010
from http://www.docstoc.com/docs/34565595/downloadorbitm6netnewsorbiter/
Team FREDNET. (n.d.). GLXP Requirements v3.0. TeamFrednetWiki. Wiki, . Retrieved December
7, 2009, from http://wiki.xprize.frednet.org/index.php/GLXP_Requirements_v3.0
Thruman, S. W (Feb 2004). Surveyor Spacecraft Automatic Landing System. American
Astronautical Society. 27th Annual AAS Guidance and Control Conference.
X Prize Foundation. (n.d.). About the Prize. Google Lunar X PRIZE. Retrieved December 7, 2009,
from http://www.googlelunarxprize.org/lunar/about-the-prize