Lunar Bus Trajectory

From TeamFrednetWiki

^{Edit Lunar Bus Trajectory}

Contents 1 Overview 1.1 Direct Lunar Insertion 1.2 LEO Parking Orbit 1.3 GTO Parking Orbit 1.4 WSB Trajectory 2 Trajectory conclusion 3 Launch window 4 Trajectory examples 5 Moon2.0 Simulator 5.1 Moon2.0 Programmer Manual 5.1.1 Moon2.0 Landing algorithm 5.1.2 Moon2.0 Communication protocol 5.1.3 Moon2.0 Hardware-in-the-loop

Overview

By: Simon Krueger
The objective of the mission is to safely land a spacecraft on the surface of the Moon. In the following the orbital mechanics aspects of this goal will be described. This includes all parts of the mission which are the launch to an initial orbit, the insertion into a transfer orbit, the deceleration at the Moon to achieve a possible parking orbit around the Moon before landing and the final descent maneuver.

For the transfer from the Earth to the Moon a number of different ways exist. In Figure 37 a) – d) four are shown. The first transfer is a direct insertion into a translunar orbit. The second and third transfers start from a LEO- and GTO- parking orbit respectively. The last one is called a Weak Stability Boundary transfer.

a)

b)

c)

d)

To justify the selection of one transfer all four will be described in a little bit more detail.

Direct Lunar Insertion

The launch vehicle puts the spacecraft directly into a translunar orbit.

Pros

• Many launch possibilities
• Most fuel efficient mission can be flown

Cons

• Customized mission required
• No dual launch possible
• Limited launcher choice

LEO Parking Orbit

The s/c starts in a Low Earth orbit and puts itself with a boost of about 3 km/s to an elliptic orbit with an apogee somewhere near the Moon (400,000 km).

Pros

• Many available launcher
• Lower launch costs

Cons

• High launch mass
• Staging necessary

GTO Parking Orbit

The s/c gets separated from the upper stage of the launch vehicle in a geostationary transfer orbit with an apogee of 35,760 km and a RAAN of 180°.

Pros

• Higher initial energy than LEO
• Many available launcher
• Reliable standard mission

Cons

• Less launch possibilities
• Higher launch costs
• Orbit plane change may be required

WSB Trajectory

The weak stability boundary transfer uses the fact that the energy of a very high eccentric orbit (rapogee > 10^6 km) can be changed at the apogee with a small amount of delta V. If this is done by perturbations like the Sun’s perturbation the orbit of the s/c can be changed to one which passes the Moon without almost any propellant.

Pros

• Smallest amount of delta V required

Cons

• Mission is very sensitive to perturbations
• Long transfer time (4 month)

Trajectory conclusion

By: Simon Krueger

This trade study led to the conclusion that a LOI from a GTO parking orbit is the best choice for this mission because the required Delta V is much smaller than from a LEO orbit so that a single stage s/c is possible. The WSB is no option because the fuel savings are just marginal compared to the high Delta V during the descent (2 km/sec) and so the very long transfer time and complexity of the mission is not worth it. The problem with the direct launch into a LTO is that this limits the number of possible launchers and a customized mission has to be flown, i.e. a dual launch with another payload is probably impossible. This may also result in higher costs. Due to this reasons the GTO mission seems to be the best solution.

Team FREDNET Trade Study:
Lunar Bus trajectories

Concept	Direct Lunar Insertion	LEO Parking Orbit	GTO Parking Orbit	WSB Trajectory
Procedure	The launch vehicle puts the spacecraft directly into a translunar orbit.	Starting from LEO, puts itself in an elliptic orbit with apogee near the Moon.	Starting from GEO The upper stage of the launch vehicle in a geostationary transfer orbit with an apogee of 35,760 km and a RAAN of 180°.	The energy of a very high eccentric orbit (rapogee > 10^6 km) can be changed at the apogee with a small amount of delta V.
Time to arrival	2.5 days	3 days	4 days	4 months
PROS	Many launch possibilities Most fuel efficient mission can be flown	Many available launcher Lower launch costs	Higher initial energy than LEO Many available launcher Reliable standard mission	Smallest amount of delta V required
CONS	Customized mission required No dual launch possible Limited launcher choice	High launch mass Staging necessary	Less launch possibilities Higher launch costs Orbit plane change may be required	Mission is very sensitive to perturbations Long transfer time (4 month)

Launch window

By: Simon Krueger

The problem which arises if the GTO is selected as an initial orbit is the fact that the apsidal line lies in the equatorial plane the Moon's orbit however is inclined by 18 – 29° w.r.t. the Earth orbit. This problem can be avoided by a good timing of the mission. If the Moon is at its orbits nodes (when the Moons orbit crosses the Earth’s equatorial plane) a transfer orbit with an apsidal along this line of nodes hits the Moon without any plane changes.

This circumstance occurs when the Sun is along the line of nodes of the Moon's orbit, because the GTO’s apsidal line is subject to the Sun’s position (it is tangential to the projection of the earth-sun line on the equatorial plane).

These conditions take place twice a year for a period of about two month. If the Sun, Earth and Moon during this time are at exact the same line, and the Moon is between the Earth and the Sun the phenomenon of a solar eclipse takes place. That is why the 16th of November 2012 has been picked as a possible launch date, because at this date a solar eclipse happens and so the conditions for a transfer without plane change is possible.

Trajectory examples

By: Joshua Tristancho
The main purpose of this section is to introduce some concepts related to the Lunar Bus and Lunar Lander trajectory. Direct trajectories (without a parking orbit like LEO or GTO) are not so suitables for Team FREDNET if we will pay for a launcher because required a self builded launcher but it is a good starting point to understand this stuff. Following design is based on a home made launcher.

Imagine we have our launcher adapted to the very minimums requirements:

• The Lunar Rover will be a PicoRover of 500 grams based on non-rechargable Lithium batteries. No solar cells.
• The Lunar Lander will be a very light Hover of 2.5 kilograms including structure and propellant. Hover's thruster is based on liquid bi-propellant with a very powerful specific impulse (Isp=310 seconds in vaccum) with 44 Newtons of thrust and 120 seconds of burning time at this thrust.
• The Lunar Transfer Injection or Lunar Bus is the second stage of the launcher of 77 kilograms of solid propellant (APCP Isp=260 seconds in vaccum) but controlled by the Lunar Lander. This stage is mainly a thruster of 1.3 kilonewtons in vacuum and 165 seconds of burning time.
• The Launcher is composed by two stages, the first stage of 691 kilograms of solid propellant (APCP Isp=220 seconds at sea level) and also controlled by the Lunar Lander, and the second stage is the TLI it self. The first stage is mainly a thruster of 11.3 kilonewtons at sea level and 128 seconds of burning time.

Schedule:
Also see home made launcher schedule.

• 0 seconds; the lift-off is in the Equator at a longitude of 49 degrees West from a little island in the delta of the Amazonas river in Brazil.
• 128 secons later the Stage-1 is jettisoned reaching to the speed of 3,756 m/s (8,400 mph) and an altitude of 59.6 kilometers (195,500 ft). The maximum acceleration is reached near the burn-out about 13 G.
• 148 second; The Stage-2 (TLI) starts 20 second later because we want exit of the atmosphere as soon as possible. From an altitude of 76.3 to 125 km (from 250,000 to 410,000 ft) the Stage-2 burns for 165 seconds.
• 312 seconds (5 minutes 12 seconds) the Stage-2 burn-out occurs; reaching to the scape velocity of 11,000 m/s. The maximum acceleration is reached near the burn-out about 20 G.
• 189680 seconds (2 dais 4 hours 41 minutes 20 seconds) the lagrangian point L-1 is reached at the velocity of 1,172 m/s (2622 mph) and a distance of 37,470 kilometers to the Moon. This is the minimum velocity for the TLI in the path to the Moon. From this point and on, the Moon's gravity field will accelerate up to the braking altitude.
• 214471 seconds (2 days 11 hours 34 minutes 31 seconds) the TLI reaches the brake altitude in the Moon at 198.9 kilometers (652,400 ft) of altitude at the speed of 2,595 m/s (5,800 mph). The later the brake the high the efficiency of the propellant required to land.
• 214711 seconds (2 days 11 hours 38 minutes 31 seconds) the Hover is descending for 4 minutes until it lands on the Moon.

3D simulation:

NOTE: These 3D pictures were generated on Google Earth 5.0. Learn more about KML files.

Moon2.0 Simulator

Here you have the Moon2.0 (Code & Docs) simulator designed by me and programmed by Juan Martinez. This simulator is able to generate a KML file which can be visualized by GoogleEarth as shown before. Since this simulator starts to be useful and is a Team FREDNET product this article will be translated to other page very soon.

NOTICE: I have used this simulator to make some calculations about trajectories for the PicoRover case. The trajectory presented in the Moon2.0 simulator may change respect to the official Team FREDNET trajectory. --Tristancho 23:57, 21 December 2009 (UTC)

UPDATE: New version available with high resolution textures uploaded by Juan Martinez. Download it now! My best, --Tristancho 11:04, 28 December 2009 (UTC)

Moon2.0 Programmer Manual

Here you have some instructions in order to implement your own landing source in our Moon2.0 simulator. This information is useful for one who will implement any Lunar Lander source so you can keep this section as a programmer manual.

Nowadays, Boone Adkins (from UVa university) and Andres Petilo (from UPC university) are parallel working in this area. Juan Martinez is the programmer of this simulator and Joshua Tristancho validates the simulator.

Moon2.0 Landing algorithm

Landing algorithm is programed in Visual Basic. There is a set of variables (see the end of this section) useful to implement your PID or whatever landing algorithm you need. It have a Cartesian 3D matrix for position, speed, attitude, etc. There is a description of this in the reference manual. There are two parts related to the landing phase:

1. First is an algorithm that decides when to start the engine,
2. Second is an algorithm that points to the Moon and controls the thrust.

You have a source example later; in fact is the current landing algorithm in the function called Nav (module Moon.bas), in the Select Case number 3 and 4. Case 3 decides the altitude to start the engine:

 If Dm < VAm * VAm * M / Fe / 2 Then ...

If it occurs, it starts engines and then goes to the Case 4. Case 4 controls the thrust in the R variable from 0=stopped to 1=Full:

 If Dm > 100 Then Gt = 2 Else Gt = 1  '1=smooth 2=hard
 R = VAm * VAm * M / Fe / Gt / Dm  'Brake dist. E=V^2/A/2 A=F/M
 If R > 1 Then R = 1  'Thrust limited to 100%

There are three ways to control the Lunar Lander when is in landing phase: Software-in-the-loop, Hardware-in-the-loop, Network-in-the-loop.

Boone Adkins (from UVa university) and Andres Petilo (from UPC university) may need to control the Lunar Lander attitude in order to test new devices or web scripts. Three options are designed to do so (some options are pending):

1. First is changing the source. This is the faster option and is called software-in-the-loop. The user can change the simulation speed in this phase. Current status: Implemented and validated.
2. Second is using the RS-232 serial port and through a small protocol. This is a high speed option and is called hardware-in-the-loop. Any device can connect to Moon2.0 and when are in the Landing phase, Moon2.0 simulator adapts the simulation speed to the port speed (Max. 115200 bps) and uses the values from the device instead of the software-in-the-loop algorithm. The user can't change the simulation speed in this phase. If connection is lost, for safety reasons, Moon2.0 change the mode to the first option software-in-the-loop. Current status: Not yet implemented.
3. Third is using a UDP socket and through a small protocol. This is a very delayed low speed option, allows remote control and is called network-in-the-loop. Any socket can connect to Moon2.0 and when are in the Landing phase, Moon2.0 simulator adapts the simulation speed to the port speed (Max. 115200 bps) and uses the values from the device instead of the software-in-the-loop algorithm. The user can't change the simulation speed in this phase. If connection is lost, for safety reasons, Moon2.0 change the mode to the first option software-in-the-loop. Current status: NOTE: Not yet implemented.

The default algorithm (software-in-the-loop) is always pointing to the center of the Moon changing variables U, V and W which is the attitude vector:

 U = -VXAm / VAm: V = -VYAm / VAm: W = -VZAm / VAm  'Moon behind

Moon2.0 Communication protocol

Either serial connection or socket connection uses ASCII text. The protocol is the same in both options and are coma separated numbers ('Double' type) where decimal character is '.', negative values character is '-', optional positive values character is '+', exponential simbol is 'e' or 'E' and not a number characters are 'NaN'. The sequence ends with a zero code to be compatible with C++.

Each block starts with a code of four characters: INIT, DATA and CTRL.

INIT. This block is sent went T=0 and could be used by the black-box as a reset. Configuration variables from the Moon2.0 simulator are 'Double' type and are:

INIT,TimeStep,Date,Time,Lat,Lon,Alt,Speed,Heading,StartAngle,EndAngle,StartAlt,EndAlt,Abort,TotalMass,Stages,StageNMass,StageNDry,StageNThrust,StageNDelay,PayloadMass
TimeStep Time step of simulation loop in seconds. Incremento de tiempo del bucle del simulador en segundos.
Date, Time Date and hour since the launch in format YYYY-MM-DD, HH:MM:SS. Fecha y hora del lanzamiento en formato UTC: YYYY-MM-DD y HH:MM:SS respectivamente.
Lat, Lon, Alt Launch geo-coordinates using the WGS84 system in degrees and altitude in meters respect to average sea level. Coordenadas del lugar de lanzamiento en grados y en metros respectivamente.
Speed Relative initial speed respect to the planet without planet's rotation in m/s. Velocidad inicial de lanzamiento relativa al centro del planeta en metros por segundo (siempre hacia el Este y ya incluye la velocidad de rotación del planeta).
Heading Clockwise launch direction where Northing is 0 degrees. Orientación de la trayectoria en grados (0=Norte, 90=Este).
StartAngle, EndAngle Start and final angle of the launch trajectory where vertical (azimuth) is 0 degrees. Ángulos inicial y final de la trayectoria en grados (0=vertical hacia arriba, 90=horizontal).
StartAlt, EndAlt Start and final altitude check point of the launch trajectory in kilometers. Altitud incial y final con respecto al nivel del mar para los ángulos de la trayectoria en metros.
Abort Number of stages before abort. Número de etapa en la que se aborta la secuencia (si no hay 'abort' es un número mayor que el total de etapas).
TotalMass Wet launcher mass in kilograms. Masa total del cohete en kilogramos.
Stages Number of stages without the hover and the payload. Número de etapas sin contar el hover ni la carga útil. Los parámetros 'StageN' están repetidos para cada etapa.
StageNMass Wet mass of stage N in kilograms. Masa de la etapa en kilogramos.
StageNDry Dry mass of stage N in kilograms. Masa de la etapa vacía de combustible en kilogramos.
StageNThrust Vacuum thrust of stage N in Newtons. Empuje de la etapa en el vacío y en Newtons.
StageNDelay Delay after stage N in seconds. Pausa entre etapa y etapa en segundos.
PayloadMass Payload mass in kilograms. Masa de la carga útil en kilogramos.

DATA. This block is sent each simulation loop. Input variables for the black-box are Double type

DATA,T,M,Mt,Mf,F,Te,eG,eH,eX,eY,eZ,eA,eR,eVR,eVRX,eVRY,eVRZ,eVA,eVAX,eVAY,eVAZ
T Time since the launch in seconds. Tiempo de simulación, en segundos. El tiempo transcurrido desde inicio de la simulación.
M Current launcher wet mass in kilograms. Masa actual del cohete en kilogramos. Baja al gastar combustible o al deshacerse de una etapa vacía.
Mt Launcher wet mass without burned stages in kilograms. Masa del cohete (descontando las etapas usadas) lleno de combustible en kilogramos.
Mf Launcher dry mass without burned stages in kilograms. Masa del cohete (descontando las etapas usadas) vacío de combustible en kilogramos.
F Current thrust in Newtons. Changes as a function of the thrust curve and the atmospheric pressure. Empuje actual del motor en Newtons. Cambia en función de la curva de potencia y de la presión atmosférica.
Te Current propellant consumption in kg/s. Consumo actual de combustible a máxima potencia en kilogramos por segundo.
eG Current planet's gravity in m/s2. Gravedad del planeta en metros por segundo al cuadrado.
eH, eX, eY, eZ Current altitude respect to the planet's center in meters and its components. Altitud con respecto al centro del planeta en metros y sus componentes X, Y, Z.
eA Current altitude respect to the sea level in meters. Altitud con respecto al nivel del mar en metros.
eR Current height respect to the ground in meters; the option terrain should be active. Altitud con respecto al suelo en metros. Solo es válida cuando estas cerca de un planeta (a menos de un radio de altura) y tiene que estar activado el 'terrain' en el simulador.
eVR, eVRX, eVRY, eVRZ Current relative speed respect to the planet's center in m/s and its components. Velocidad relativa al centro del planeta en metros por segundo y sus componentes X, Y, Z.
eVA, eVAX, eVAY, eVAZ Current relative speed respect to the planet's atmosphere in m/s and its components. Velocidad relativa a la atmósfera del planeta en metros por segundo y sus componentes X, Y, Z.

CTRL. This block is expected by Moon2.0 during a 'timeout' then it goes to PAUSE. Output variables from the blackbox for attitude control are 'Double' type and are:

CTRL,Tt,St,Nt,Rt,Ut,Vt,Wt
Tt Time since the launch in seconds to check the correct packet. Tiempo de simulación en segundos. Este por ahora lo ignoraré porque si me cambias el 'T' a mitad de la simulación se me podría colgar (supongo que lo has puesto por aquello de la 'interpolación' de datos en el modo asíncrono).
St Current mission stage. NOT YET IMPLEMENTED. Fase de vuelo (solo se usa 'TakeOff', así que por ahora la ignoraré): Crashed=-2, Landed=-1, Aborted=0, Launch=1, TakeOff=2, Transfer=3, Landing=4, Revert=5, Satellite=6, StandBy=7
Nt Current stage. NOT YET IMPLEMENTED. Número de etapa activa (1, 2, .. N). Por ahora la ignoraré porque esa parte no está implementada.
Rt Thrust control from 0=stopped to 1=full. NOT YET IMPLEMENTED. Control de la potencia: 0=parado y 1=a tope, pero como usamos APCP en las 2 etapas, en principio no se puede regular y por ahora lo ignoraré.
Ut, Vt, Wt Attitude control. It is a normalized vector in the simulator reference system that is the ecliptic plane (the plane XY where the Earth turns around the Sun). Control de dirección: La orientación del cohete con respecto al eje de coordenadas del simulador. Debe ser un vector 3D normalizado (U·U+V·V+W·W=1). El eje de coordenadas del simulador está orientado con el plano eclíptico, es decir, el plano de órbita de la Tierra alrededor del Sol, que se corresponde con el plano X,Y o U,V. Esto es así porque las coordenadas de la posición inicial de los planetas me vienen con ese sistema y es el que usa el simulador. Puedes ver los ejes en el simulador con 'Tools->Axes'.

Moon2.0 Hardware-in-the-loop

Bueno, ya está más o menos hecho lo básico. Lo he probado con el 'VirtualNullModem' y va bastante más rápido de lo que esperaba. He podido bajar el 'Timeout' hasta 30ms y va a '30x' con 50ms de 'time step'. Pero claro, yo uso un puerto 'virtual' y además no he tenido que procesar los datos como lo hará la 'caja negra', así que hay que ser prudentes. Si más adelante vemos que se viene abajo, habrá que plantearse reducir el número de variables o usar el modo 'binario' en lugar del modo 'texto' para los datos. A veces se cuelga la conexión, pero podría ser culpa del 'VirtualNullModem'.

Los bloques de datos serán por ahora de 512 bytes y de longitud fija, para simplificar el proceso de lectura y escritura. Si necesitas cambiarlos de longitud o hacerlos de longitud variable, dímelo y lo cambiaré. El bloque es una cadena de texto que comienza con una 'etiqueta' de 4 carácteres y una coma, seguido de los parámetros en coma flotante de doble precisión (64bits), en notación científica si es necesario (el 0 a la izquierda del punto decimal se omite), separados por comas (y un espacio delante de los números positivos) y acabada con un código 0 (por si usas las funciones de cadenas de texto de C++). Hay 3 tipos de bloque: INIT, DATA y CTRL.

1. El bloque INIT te lo envía el simulador antes del primer bucle de la simulación, es decir, cuando T=0 y te puede servir como orden de reinicio, la sintaxis es:

2. El bloque DATA te lo envía el simulador cada bucle de la simulación, la sintaxis es:

3. El bloque CTRL se lo envía el dispositivo al simulador como respuesta al bloque DATA y debe hacerlo antes de que pase el tiempo especificado en 'Timeout', si no el simulador se pone en pausa. La sintaxis es:

El procedimiento para usarlo es este:

Primero tienes que iniciar el dispositivo o el programa que tengas conectado al otro lado del RS-232 para que empieze a recibir los datos del simulador. Luego inicias el Moon2.0, le das a F9 para mostrar el panel Link y luego al botón de la flecha para sacar el menú y seleccionas 'RS-232' y también 'Launch trajectory' para activar el control del dispositivo externo sobre la trayectoria de despegue. En cuanto le das al 'START' en la simulación, el simulador abre el puerto serie y envía un paquete 'INIT' y luego un paquete 'DATA' para cada paso del bucle de la simulación. Si en el tiempo que has puesto en 'Timeout' el dispositivo externo no responde, como funciona en modo 'síncrono', el simulador se pone en pausa y no avanza. Si le das a 'PLAY' vuelve a repetir el último paso y así hasta que le responda el dispositivo externo y entonces continúa con la simulación. En el 'Log' del panel Link te va saliendo todo lo que va pasando con el puerto RS-232. Con el botón '·' reinicias la conexión con el puerto serie y con el botón 'x' borras el 'Log' por si se llena.

Lo del 'Flow control' del RS-232 no sé muy bien cómo implementarlo. En la configuración del puerto serie en la API hay varios parámetros relacionados con el 'Flow control': - 2 'flags' de 1 bit que son 'CTS output flow control' y 'DSR output flow control' - 2 'flags' de 1 bit que son 'XON/XOFF out flow control' y 'XON/XOFF in flow control' - 2 parámetros de 2 bits cada uno que son 'DTR flow control type' y 'RTS flow control' Si entiendes el protocolo de los RS-232, dime qué opciones tengo que poner en la caja de texto de 'Flow' y a qué 'flags' corresponde cada una. De todas formas al configurar el puerto solo cambio las opciones que entiendo, las otras las dejo como vienen por defecto.

Los parámetros de inicio 'INIT' son una versión reducida del 'preset', porque si pongo todos sería mucha información para empezar. Para ser exactos, tendría que mandarte las curvas de potencia de las etapas e incluso la curva de la presión atmosférica, las del CD en función del Mach o el 'tocho' del 'terrain'. Pero eso sería para hacer una versión del 'Moon2.0 for Satellites' que ejecutara la CPU de tu satélite y creo que no es esa la intención de todo esto.

En cuanto a los parámetros de 'DATA', más de lo mismo. Lo lógico sería que te pasara solo los datos que te pasaría la madre naturaleza (o el padre) como ocurrirá en la misión real, es decir, la aceleración del empuje menos la del rozamiento del aire que te dan los inerciales y la posición XYZ que te da el GPS (si tienes uno). Todo lo demás debería calcularlo el satélite internamente.