Fission Powered Lunar Lander

Settlements on the moon, for mining and scientific research, will require routine travel between lunar orbit and the lunar surface. One idea is to use a lunar shuttle with a nuclear fission rocket engine. The hydrogen fuel would come from water on the moon. Fission rockets have twice the specific impulse of the best chemical rockets leading to low fuel consumption. In addition, they would leave the oxygen from the electrolysis of water available for the lunar settlements.

Stanley Borowski of NASA/GRC is co-author of a paper giving the status of nuclear fission rockets:

NTR Technology Development and Key Activities Supporting a Human Mars Mission in the Early-2030 Timeframe

Fission rockets were developed in the 1970’s but the technology was never tested in flight. We used his paper to create a fission rocket. A 3D model based on a drawing the paper is shown below:

NTP

We built the launch vehicle using a single script in the Spacecraft Control Toolbox for MATLAB:

Spacecraft Control Toolbox 2015.1

The script uses a bilinear tangent steering law to estimate the required two way delta-v. The lander flies to 12 km where it meets a freighter. The crew is housed in an Orion spacecraft. The vehicle is shown below:

FissionNL

The landing legs are based on the Apollo Lunar Module. The liquid hydrogen is stored in the 4 spherical tanks. The nuclear thermal engine is hidden by the box to which the legs are attached. The lander lifts the Orion spacecraft and 6000 kg more of payload which would include helium-3 mined on the moon.

The Orion model was created by Amazing3DGraphics. Amazing3D is really good at creating low polygon count models that are useful for simulation and disturbance modeling.

The script and new supporting functions will be available as part of SCT Release v2015.2.

Comparing disturbance models

A customer recently asked us for help comparing the disturbance analysis available in the CubeSat Toolbox with the full model in SCT Professional, for a 3U CubeSat. That is, to compare CubeSatDisturbanceAnalysis to Disturbances. The CubeSat Toolbox uses a simplified model of the spacecraft geometry as a single set of fixed areas, nominally for a rectangular prism. The full model in SCT Pro allows for articulated and rotating bodies built of individual components. The CubeSat Toolbox has a subset of the environment and disturbance functions in Pro but includes drag and optical disturbances in Earth orbit. Given enough options for the two models it should be possible to get the exact same results. We will sketch out our process and discoveries in this post.

Creating a model of a 3U CubeSat in Pro was the easy part, as it is just a single box component, and verifying that the areas match those from CubeSatFaces is accomplished by a trivial command-line printout. Comparing the results of the optical and drag analysis is much more complex as there are so many variables:

  • Atmosphere model: exponential, scale height, J70
  • Solar flux model
  • Earth albedo model
  • Earth radiation model
  • Satellite optical properties (specular, diffuse, absorptive)
  • Attitude pointing (LVLH vs. ECI)

In order to compare the results, we had to call both disturbance models in a script and generate plots overlaying the resulting forces and torques. Here is the code defining the model for SCT Pro.

m = CreateComponent( 'make', 'box', 'x', 0.1, 'y', 0.1, 'z', 0.3,...
'name', 'Core', 'body', 1, 'mass', mass, ...
'faceColor', 'gold foil', 'emissivity', thermal.emissivity,...
'absorptivity', thermal.absorptivity, 'sigmaT', optical.sigmaT,...
'sigmaA', optical.sigmaA, 'sigmaD', optical.sigmaD, 'sigmaS', optical.sigmaS,...
'inside', 0);
BuildCADModel( 'add component', m );

You can see the thermal and optical properties that must be specified as well as the mass and dimensions. The spacecraft is inertially fixed and put into an equatorial orbit, so we would expect zero drag along the z axis and the x/y forces to oscillate at orbit rate. Then to call the disturbance model we generate a low Earth orbit, get the Earth environment and run the analysis, like so:

[r,v] = RVOrbGen(el,t);
e = EarthEnvironment( r, v, jD, d );
hD = Disturbances( 'init', g, e );
[fD,tD] = Disturbances( 'run', g, e, hD );

The EarthEnvironment function is where the guts of the space environment modeling occurs. This includes specifying albedo and radiation constants, calculating the atmospheric density over the orbit, computing the sun vector and solar flux magnitude, checking for eclipses, computing the Earth magnetic field, and correcting the inertial velocity for the rotation of the atmosphere for drag calculations. In the CubeSat toolbox, this data is computed inside the dynamical model, RHSCubeSat. The same steps of creating the model and calling the disturbance function are shown below.

c = RHSCubeSat;
c.mass = 3;
c.inertia = InertiaCubeSat( '3U', c.mass );
[a,n,rho] = CubeSatFaces('3U',1);
c.surfData.nFace = n;
c.surfData.area = a;
c.surfData.rFace = rho;
for k = 1:6
% Radiation coefficients [absorbed; specular; diffuse]
c.surfData.sigma(:,k) = [optical.sigmaA;optical.sigmaS;optical.sigmaD];
end
c.atm = [];
q = QZero*ones(1,size(r,2));
[tC, fC, h, hECI, fr, tq] = CubeSatDisturbanceAnalysis( c, q, r, v, jD );

Let’s look at drag first, as it proved to be the easiest to verify. The primary difference between the CubeSat model and full disturbance model for drag initially was the atmosphere model itself: CubeSat uses the Jacchia 1970 model by default, while EarthEnvironment specifies a scale height atmosphere. The Jacchia 1970 model accounts for changes in density with the time of day, resulting in an orbit rate periodicity; however it is computationally more intensive and not needed in preliminary analysis. The scale heights model depends only on altitude and is very quick. The CubeSat dynamic model already had an option to switch to the scale height atmosphere if desired, so we added that same option to the CubeSat disturbance analysis function. This promptly resulted in a close result between the models for the drag force.

Comparison of the drag force between the CubeSat and full disturbance models for a 3U CubeSat

Comparison of the drag force between the CubeSat Toolbox and SCT Pro disturbance models for a 3U CubeSat

A slight variation remains due to a difference in the transformation between the inertial frame and Earth-fixed frame between the two models. This transformation is used to account for the rotation of Earth’s atmosphere, as drag depends on the relative velocity between the surface and the air. CubeSat uses a fast almanac function, ECIToEF, to compute this matrix for a given Julian date. This model accounts for nutation but not as accurately as TruEarth does in Pro. The EarthEnvironment function in Pro, however, uses a simpler transformation using Earth’s rotational rate about the inertial z-axis, ignoring nutation. This accounts for the nonzero Z force in the CubeSat output, which can be seen to be four orders of magnitude less than the X/Y forces. Both approaches are valid for a preliminary analysis so we accept this small remaining difference.

Producing an equally close comparison for the optical forces unearthed a few bugs in the CubeSat version as well as differences in fidelity that are intentional. First, recall that there are three main contributions to optical forces in Earth orbit: solar flux; Earth albedo – that is, reflected flux; and Earth infrared radiation. The fluxes can be modeled simply as constants, or at higher fidelity by accounting for distance from the radiating body. The full disturbance model accounts for the change in solar flux over the year as the Earth moves in its orbit, which amounts to about 100 W/m2 or 7% of the average flux. The CubeSat environment model was not doing this, but since it was already calling the sun vector function which calculates the needed data, we decided to add it. The sun vector itself can be modeled a number of ways, with CubeSat providing a low fidelity almanac version and Pro a higher fidelity almanac option as well as an option for JPL ephemerides.

Making a temporary change in CubeSat to use the higher fidelity sun almanac provided closer results, but there were still differences in the optical forces. A check on the optical coefficients revealed that Disturbances assumed 100% diffuse reflection for planetary infrared radiation while the CubeSat version assumed 100% absorption. This was result of a misunderstanding of the model when the CubeSat version was created. The intention of the model is to assume 100% absorption, but the radiation has to be reemitted or the temperature of the body would increase to infinity. Hence the diffuse coefficient in the Pro model. So, the CubeSat version’s coefficients were corrected to match. This improved the agreement between the models but still not completely.

Further investigation uncovered a bug in the calculation of the planetary radiation flux and Earth albedo flux. We call this a copy/paste bug, as the distance scaling factor was in the code, but applied to the wrong variable when the CubeSat version was created from the Pro version – so the scaling was unitized out. Correctly applying the scale factor to the flux input (and not its unit vector) to the base solar force function, SolarF, resulted in exact agreement between the two models. The figure below shows the final differences with the CubeSat sun almanac function restored to its default value.

Optical force comparison

Comparison of the optical force between the simplified and full disturbance models for a 3U CubeSat

To summarize, we identified the following subtleties in making a direct comparison between these two disturbance models:

  • Selecting the same atmosphere model, AtmDens2, for both cases
  • Understanding the sun vector model in each case (SunV1 vs. SunV2)
  • Adding the solar flux scaling with the Earth’s distance from the sun to the CubeSat model (1 line)
  • Updating the optical coefficients for planetary radiation in the CubeSat model (to be diffuse)
  • Correcting a bug in the scaling of the Earth albedo and radiation fluxes with altitude in CubeSat
  • Accounting for Earth’s nutation in transforming velocity to the Earth-fixed frame

This provides a great illustration of how careful one needs to be in performing any disturbance analysis, as there are so many subleties in even simple models that must be recorded if results are to be replicated. Every constant, every scale factor, every coefficient, every source of ephemeris needs to be understood.

We were happy to provide the results of our analysis to our customer so that he could decide which models he wants to use in his analysis. This is an example of the technical support we can provide to all our SCT customers; if you have a question, just ask!

Two Stage to Orbit with the Launch Vehicle Toolbox

The Launch Vehicle Toolbox (LVT) combines the Spacecraft Control Toolbox, the Aircraft Control Toolbox and additional libraries of launch vehicle functions and scripts. We’ve used it internally to support a number of contracts.

We have studied two stage to orbit vehicles for a number of years. Our design, known as Space Rapid Transit, uses an aircraft first stage (the Ferry) with a turbo-ramjet engine to take the launch vehicle to 40 km and Mach 6.5. The turbo-ramjet engine is dual fuel using jet fuel for the turbofan and hydrogen for the ramjet. The turbofan core would be based on an existing modern jet engine. A hydrogen fueled turbo-ramjet was tested by MBB for their Sanger launch vehicle. Hydrogen fueled ramjets have been tested by NASA. The SR-71 engine was an early operational turbo-ramjet.

The Orbiter uses a cryogenic hydrogen/oxygen engine to enter the transfer ellipse and then circularize the orbit. The Ferry engine can operate in pure turbofan mode for efficient low-speed operations such as moving the Orbiter between airfields.

TSTODemo.m is a LVT script that models the trajectory from takeoff through circular orbit insertion. The TSTO stack starts on the runway in takeoff mode. When it is moving at the takeoff speed it pulls up and climbs. It transitions from turbofan to ramjet and climbs to the separation altitude and velocity. The simulation works with flight path and heading angles. You can try flying the vehicle in a variety of trajectories. The following figure shows the trajectory up to Ferry/Orbiter separation.

SRTTrajectory

The Space Rapid Transit vehicle is documented in this paper:

Paluszek, M. and J. Mueller, Space Rapid Transit – A Two Stage to Orbit
Fully Reusable Launch Vehicle, IAC-14,C4,6.2, International Astronautical Congress, Toronto, Ontario Canada, October 2014.

The Orbiter starts at the termination condition. The script computes a transfer orbit and the necessary velocity changes to get the Orbiter into an ISS altitude orbit. Part of the delta-V is the drag loss. The Orbiter trajectory is not simulated. The architecture of LVT makes it easy to build these kind of analysis and simulation scripts. Your aren’t locked into a specific design path as can happen with GUI based tools.

For more information go to Launch Vehicle Toolbox for MATLAB.

SolidWorks Interface in SCT 2015.1

Version 2015.1 will have a new DXF file format exporter to export CAD models built in the Spacecraft Control Toolbox into SolidWorks. The following figure shows the Lunar Lander model in the Spacecraft Control Toolbox CAD window.

LunarLander

Exporting requires just two lines of code:

g = BuildCADModel( 'get model' );
ExportDXF(g,'LunarLander');

Rodger Stephens of Prism Engineering provided SolidWorks models from the DXF file. The file opened in SolidWorks with 7 parts creating an assembly called LunarLander-1.

SolidWorks1

Each part contains planes, sketches, and surfaces.

SolidWorks2

The Spacecraft Control Toolbox has always had DXF import capability but now it can export in a format that is supported by most CAD packages. This will speed the process of going from conceptual designs in the Spacecraft Control Toolbox to detailed designs in SolidWorks and other CAD packages.

Patched Conics

Patched conics are a useful approximation when dealing with orbits that are under the influence of multiple planets or moons. The idea is that only one planet’s or moon’s gravitational field is active at any one time. For example, at the start of a mission from Earth orbit to the Moon, we assume that only the Earth’s gravity acts on the spacecraft. For each planet or moon we define a sphere of influence where that body’s gravity is greater than all other sources. In the Earth/Moon system the Moon’s sphere of influence extends to about 66,000 km from the moon.

A new function in the Spacecraft Control Toolbox Release 2015.1 is PatchedConicPlanner.m. It allows you to explore trajectories in a two-body system. The following figure shows the trajectory of the spacecraft and the orbit of the Moon in the Earth-centered frame. The trajectories assume that the spacecraft is only under the influence of the Earth. The spacecraft is in an elliptical orbit designed to have its apogee just behind the Moon.

PCC1

The next figure shows the spacecraft in the Moon centered frame. The blue line is the trajectory of the spacecraft assuming that the Moon was not there. The green line is the hyperbolic trajectory of the spacecraft starting from the patch point computed assuming the Earth’s gravity had no influence on the trajectory. Notice the sharp turn due to the Moon’s gravity. The function returns the Moon-centered orbital elements along with other useful quantities.

PCC2

The following shows a closeup of the trajectory. The miss distance, as expected, is less for the hyperbolic trajectory. The plot clearly shows a good place for a delta-v maneuver to put the spacecraft into lunar orbit.

PCC3

This function allows you quickly explore the effect of different patch points and to try different spacecraft transfer orbits. While a “high-fidelity” analysis requires numerical orbit propagation that includes the Moon, Sun and Earth’s gravitational fields, PatchedConicPlanner.m, let’s you generate good starting trajectories for mission planning.

Heading to the Moon

We have transitioned our lunar lander work from the Spacecraft Control Toolbox to VisualCommander. Here is a simulation of the lander heading to the moon on the elliptical transfer orbit designed in our Landing on the Moon blog post.

Lunar Transfer

The model was discussed in our Moon Lander Design blog post. We exported it from the Spacecraft Control Toolbox as a Wavefront obj file. The textures were applied by Amazing3D Graphics. Amazing 3D Graphics builds very high quality models with low polygon counts that are ideal for simulation and games.

The attitude control system is our Precision ACS system. In the next few weeks we’ll be adding software to perform mid-course corrections, lunar orbit insertion and lunar landing. Say tuned!

Moon Lander Design

Our last post showed the mission planning script for our lunar lander. The next step was to layout the lander. We did this using the BuildCADModel function in the Spacecraft Control Toolbox. The propulsion system is designed to meet the requirements of the mission plan. We use six 1 N HPGP thrusters for attitude control and one 220 N thruster for orbit maneuvers and landing. We have two HPGP tanks for the fuel. There are two cameras. One is used as a star camera for attitude determination and navigation and the second, which is articulated, is used for optical navigation, descent navigation and science. The IMU and C&DH box can bee seen in the drawing.

LunarCAD

The solar array has two degrees-of-freedom articulation. The high gain antenna is also articulated. We adapted the landing legs from the Apollo Lunar Module. The thruster layout is shown in the following figure and is done using the ThrusterLayout function in the toolbox.

LunarThruster

We get full 6 degree-of-freedom attitude control and z-axis velocity change control. We use the 220 N engine as the primary engine for landing but can also use four of the 1 N thrusters for fine terminal control.

We are working on the science payload for the mission. One experiment will be to mine helium-3 from the surface. Helium-3 would be a fuel for advanced nuclear fusion power plants and nuclear fusion propulsion systems.

Landing on the Moon

There is a lot of interest in lunar landing missions for both scientific exploration and commercial purposes. Commercial applications might include mining helium-3 for future nuclear fusion power plants on earth and mining water for rocket fuel.

The Spacecraft Control Toolbox makes it easy to do preliminary planning for lunar missions. In this blog we present a single MATLAB script that takes a spacecraft from a low Earth parking orbit to the lunar surface! Here is the final segment, the descent to the moon.

MoonMission_03

We ended up with a 30 kg dry mass for a spacecraft that can use an ECAPS 220 N HPGP thruster for delta-v.

The published script can be found here:

Lunar Mission Planning as a published MATLAB script

You can also send us an email to find out more about our Lunar Mission Design Tools.

2014 International Astronautical Congress

From the movie “2001: A Space Odyssey”, 1968. Dr. Heywood Floyd is talking with Elena, a colleague from Russia:

Elena, “Well, I hope that you and your wife can come to the I.A.C conference in June.”
Floyd, “We’re trying to get there. I hope we can.”

I was able to attend the IAC conference in 2014 in Toronto, Ontario, Canada. I presented two papers:

“Direct Fusion Drive for a Human Mars Orbital Mission”

DFDMTV

“Space Rapid Transit – A Two Stage to Orbit Fully Reusable Launch Vehicle”.

SRT

2001: A Space Odyssey was the “theme” for my two papers. I had a photo of the Discovery II spacecraft in my DFD talk and an image from an online simulator of the full Orion III launch vehicle in my SRT talk. Both papers were well received. I got a good question from an engineer from Reaction Engines Limited about separation. We have done some separation simulations but have not testing our separation control mode in depth. He noted that the D-21 program, and example of high speed separation I gave, was not really successful.

When I wasn’t in my sessions, I spent my time in the exhibits hall talking with the representatives at the booths, handing out business cards and flyers about Princeton Satellite Systems. Some of our customers, including KARI from Korea and the Canadian Space Agency, had exhibits.

I spoke at length with Astrobotics, a company that plans to land a rover on the moon. They were founded by a professor from Carnegie Mellon. I suggested that our flight control experience could be of value to them. Their work shows the feasibility of helium-3 mining on the moon. We would need helium-3 mining if we were ever to use DFD for base load terrestrial power generation.

I chatted with the Aerospace Corporation. I worked with them on GPS IIR while at GE Astro Space. I explained that they might be interested in working with us on DFD particularly in applying it to Air Force applications like space based radar.

SpaceX had the crew chairs and displays from their Dragon Capsule in their exhibit. It was the coolest exhibit in the hall! I had a nice chat with their marketing person on DFD. SpaceX and Boeing recently were awarded contracts to develop the Commercial Crew vehicle.

Lockheed Martin had a huge exhibit. They had a 3D printer running

IMG_0953

I talked with them about A2100, a comsat under design at GE Astro Space when I left. I also talked about ControlPlan applications for MUOS, a satellite Lockheed Martin is building for the Navy. We developed antenna beam optimization for MUOS using our ControlPlan multi-objective optimization package.

I spoke with Surrey about their new comsat program and suggested that we could help as we have extensive comsat experience. Surrey now has a U.S. branch. I spoke with the Canadian Armed Forces about their satellite programs. They were interested in our Kestrel Eye work.

The CN Tower is in the middle of the convention center:

IMG_0956

On the way home I ate at the Apropos restaurant in the Air Canada terminal. It is really cool! You order through an iPad and pay using a credit card terminal next to the iPad. Besides being high tech, the food was really good! The restaurant can be seen in the following picture.

Apropos

Attitude Maneuvers with the CubeSat Control System

The CubeSat control system is designed to work with either thrusters or reaction wheels. It has a number of handy built in maneuver modes such as pointing at the sun, nadir pointing or pointing at a specific latitude and longitude on the ground. Here is the spacecraft shown in the VisualCommander interface.

CSCS

The movie in the link below shows attitude maneuvers in the VisualCommander interface. The interface has pages for the various subsystems and attitude control system functions. We start by seeing the spacecraft in a polar orbit on the Summary page. The solar arrays are reorienting themselves so that their cell faces are pointed at the sun. We switch the 3D display to look along the boresight of the telescope. We then go to the ACS page and select a sun pointing maneuver. We go back to the Summary page and see that the sun appears in the display. We then return to the ACS page and command nadir pointing. The remainder of the movie shows the reorientation maneuver to nadir pointing.

CSCS Reorientation Movie

For more information on our simulation frameworks including our real-time control system framework, ControlDeck, go to Simulation Framework page.

For more information on VisualCommander go to VisualCommander page.

You can also send us an email to find out more about our CubeSatControl System. All of these products are available now.