Your SlideShare is downloading. ×

10 06-03 uva boone-technical report


Published on

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

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

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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 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 Team FREDNET. (n.d.). GLXP Requirements v3.0. TeamFrednetWiki. Wiki, . Retrieved December 7, 2009, from 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