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!

Reaction Wheel Friction Models

Reaction wheels are used in many spacecraft for attitude control. A reaction wheel is a momentum exchange device because it controls the spacecraft by exchanging momentum with the rest of the spacecraft. Momentum is exchanged via a motor that is fixed to the spacecraft. As with all rotating parts it is subject to friction. Friction needs to be modeled as part of the design process.

The standard way to model friction is with three terms. One is damping which is proportional to wheel speed. The faster the wheel spins the more friction torque is produced. Ultimately, this limits the net control torque. At some speed the motor is just balancing the friction torque. The second component is Coulomb friction that is constant but flips signs when the wheel speed changes sign. the third is static friction. It is like Coulomb friction but only exists at zero speed.

An alternative friction model is known as the bristle friction model. This models friction as bristles that bend. It also has the same friction components described above but they are applied though the bristle state.

Both models can be made to produce similar results as shown in the following figure.

FrictionComparison

The static friction is clearly seen. The wheel speeds are nearly the same. The middle plot is of the bristle state. The problem with these models is when the torque is low and the wheel speed passes through zero. We then get limit cycling as shown below.

LimitCycle

This is due to numerical error.

We can eliminate the limit cycling by using a very small integration time step with the bristle friction model. An alternative approach is to use the first model and multiply the sum of the static and Coulomb friction with a sigmoid, or s function.

Friction

The coefficient of the sigmoid function is beta. Very small betas remove the static friction, and all Coulomb friction, near zero speed. The large betas retain the form of the friction and eliminate the limit cycling!

HighBeta

These models can be found in the Spacecraft Control Toolbox 2015.1 . This particular script will be available in 2015.2 which will be released in July.

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.

Elements for a 2000 satellite constellation? No problem!

A customer recently asked if we had any constellation design tools in the toolbox, which at that point we did not. This customer had been tasked with simulating a constellation of nearly 2000 CubeSats, and had available only a GUI-based tool that required him to enter each satellite’s elements individually. He was able to clone them, but still had to open up each one to edit the elements. This means he first had to make a table of the elements he wanted, then painstakingly enter them. In the Spacecraft Control Toolbox, creating these elements and simulating or visualizing the satellites is as easy as writing a for loop.

Our workflow using the SCT is mostly programmatic, using functions and scripts. Functions such as El2RV make it easy to go from Kepler elements to a Cartesian state for initializing a simulation. In just a few hours, I was able to write a function to generate elements for a Walker-Delta constellation of any size, and plot the results; to examples are shown below.

The WalkerConstellation.m function will be in our 2015.1 release, due out in a week. It can generate elements for a classic rosette or a polar star. If there is sufficient customer interest we may expand the constellation design tools available in the toolbox!

%-------------------------------------------------------------------
%   Form:
%   elements = WalkerConstellation( t, p, f, inc, sma, doStar )
%-------------------------------------------------------------------
WalkerConstellation( 720, 24, 2, 65*pi/180, 6800 )

 

WalkerDelta

% Create a polar star similar to Iridium
WalkerConstellation( 66, 6, f, 86.4*pi/180, 7150, true );

PolarStar

 

Full function header:
%--------------------------------------------------------------------
%   Compute orbital elements for a Walker constellation.
%
%   Generates a delta constellation be default, also called a rosette. For
%   a star geometry, pass in true for the optional doStar parameter. The
%   notation is i:n/p/f; f, the relative spacing, is an integer which can
%   take any value from 0 to (p-1).
%
%   Real-life examples include the Galileo, a delta geometry, and Iridium,
%   a star geometry.
%
%   Since version 2015.1
%--------------------------------------------------------------------
%   Form:
%   elements = WalkerConstellation( t, p, f, inc, sma, doStar )
%--------------------------------------------------------------------
%   -----
%   Input
%   -----
%   t         (1,1)    Total number of satellites
%   p         (1,1)    Number of orbital planes
%   f         (1,1)    Relative spacing between satellites in adjacent planes
%   inc       (1,1)    Inclination (rad)
%   sma       (1,1)    Semi-major axis (km)
%   raan      (1,1)    RAAN spread, optional. The default is 2*pi.
%
%   ------
%   Output
%   ------
%   elements   (6,t)    Kepler elements
%
%--------------------------------------------------------------------
%  Reference: Larson and Wertz, Space Mission Analysis and Design, second
%  edition (1996), "Constellation Patterns", p. 191
%--------------------------------------------------------------------

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.

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.

Spacecraft CAD Design in the Spacecraft Control Toolbox

AutoDesk Inventor and SolidWorks are powerful software packages for the computer-aided design of spacecraft. Ultimately you need to use one of those packages for the mechanical design of your satellite, but what about the preliminary design phase when you are still determining what components you even need? The CAD software in the Spacecraft Control Toolbox can provide you with a valuable tool to do your conceptual layouts and early trade studies, and the same model can be used as the basis for disturbance analysis in later design phases.

A CAD model in SCT is built in a script which allows you to build your models algorithmically. You can call design functions, use for loops and revision-control your source code. For example, within the script you can do an eclipse analysis and compute the battery capacity. This number can generate the volume of your batteries which you can then use to size your spacecraft.

The function BuildCADModel provides the model-building interface. The CreateComponent function is used to generate the individual components using parameter pairs as arguments. Components are grouped into bodies to allow for rotation and articulation. A GUI displays your finished model and allows you to visualize it in 3D. You then store your finished models as mat-files. Our disturbance model uses every triangle in your model for disturbance analysis.

The example figure shows a solar sail design, with the spacecraft bus in the middle. BuildCADModel allows you to group components into subsystems as on the left-hand side, which can then be highlighted using transparency.

The figure below shows the BuildCADModel GUI which allows you to verify the body and component properties.

There are many examples of spacecraft models in the SCT to help you get started, and a lengthy chapter in the User’s Guide discussing the finer points of component location, orientation, and physical properties such as drag and optical coefficients. Your CAD model essentially functions as a database for your entire spacecraft model!

Simulating Magnetic Hysteresis Damping

CubeSats have caused a renewed interest in magnetic control of satellites, and passive hysteresis damping in particular. Modeling actual hysteresis rods on a satellite is not trivial, and generally requires empirical data on the properties of the rods selected. Our newest CubeSat simulation demonstrates damping using rods in LEO. A permanent magnet is modeled using a constant dipole moment, and we expect the satellite to align with the magnetic field and damp. We evaluate the results by plotting the angle between the dipole and the Earth’s magnetic field and the body rates.

First, let’s verify the magnetic hysteresis model in the toolbox using the bulk material properties in orbit. We use a dipole model of the Earth’s magnetic field. The nice hysteresis curves below confirms that we are computing the derivatives of the magnetic field correctly in the body frame, which requires careful accounting of rotating coordinates. Also we stay within the saturation limits which means our magnetic flux derivatives are correct too.

Hysteresis curves from simulating magnetic hysteresis in orbit

Hysteresis curves from simulating magnetic hysteresis in orbit

We will assume the rods are 1 mm radius and 95 mm length, with rods placed perpendicular to each other and the permanent magnet. Three rods are used per axis. The apparent rod parameters are taken from the literature. The actual rods will not reach saturation while in orbit, so we will see a minor loop.

Minor loops from damping rods

Minor loops from damping rods using apparent properties

The rods produce only a small amount of damping per orbit, so we have to run for many orbits or days to see significant damping – in some passive satellites, the total time allotted for stabilization is two months! In this case we test the rods’ ability to damp the torque induced by turning on a torque rod with a dipole of 1 AM2 and allowing the CubeSat to align itself with the magnetic field, starting from LVLH pointing.

Damping in LEO using hysteresis rods

Damping in LEO using hysteresis rods

Simulating the rods is time-intensive, with a timestep of about 4 seconds required – which makes a simulation of several days on orbit take several minutes of computation. Once performance of the rods has been verified, a simple damping factor can be substituted.

This new simulation along with the functions for hysteresis rod dynamics will be in the new version of our CubeSat Toolbox, due for release in June!

References:

  1. F. Santoni and M. Zelli, “Passive magnetic attitude stabilization of the UNISAT-4 micro satellite”, Acta Astronautica,65 (2009) pp. 792-803
  2. J. Tellinen, “A Simple Scalar Model for Magnetic Hysteresis”, IEEE Transactions on Magnetics, Vol. 34, No. 4, July 1998
  3. T. Flatley and D. Henretty, “A Magnetic Hysteresis Model”, N95-27801 (NASA Technical Repoets Server), 1995

Adaptive Cruise Control

The automotive industry continues to incorporate advanced technology and control systems design into new vehicles. Features such as adaptive cruise control, lane keep assist, autonomous park assist, and adaptive lights are becoming more common in the automotive market. These exciting technologies greatly increase vehicle safety!

Adaptive cruise controls measure the distance and speed of nearby vehicles and adjust the speed of the vehicle with the cruise control to maintain safe following distances. Typically a system will use a radar that measures range, range rate and azimuth to vehicles in its field of view.

A typical situation is shown below. The car with adaptive cruise control is traveling near three additional vehicles. Two cars have been tracked for awhile but a third is passing and plans to insert itself into the space between the tracking car and one of the tracked cars. How does the cruise control keep the three cars straight?

MHTAuto

Every measurement has uncertainty. The following drawing shows the uncertainty ellipsoids for the three vehicles. As you can see they overlap so a measurement could be associated with more than one car.

UncertaintyEllipsoids

The Princeton Satellite Systems Target Tracking Module for MATLAB implements track oriented Multiple Hypothesis Testing (MHT). MHT is a Bayesian method for reliably associating measurements with tracks. The system is shown below:

MHTSystemSimplified

The system includes a powerful track pruning algorithm that eliminates the need for ad-hoc track pruning. Without track pruning the number of tracks maintained would grow exponentially. The system generates hypotheses that are collections of tracks that are consistent, that is the tracks do not share any measurements. Measurements are incorporated into tracks and tracks are propagated using Kalman Filters. The MHT system also can handle multiple sensors for automobiles with cameras and radar.

Check out what all our MATLAB toolboxes have to offer!
Core Control Toolbox
Aircraft Control Toolbox
CubeSat Toolbox
Spacecraft Control Toolbox