In 2015, astronomers from Caltech determined that a giant ninth planet may be orbiting the Sun. It was called Planet X and then Planet 9. The discovery was based on perturbations in the orbits of TNOs, trans Neptunian Objects. The planet has about the mass of Neptune and is in a 10,000 to 20,000 year solar orbit. Jakub Scholtz of Durham University and James Unwin of University of Illinois at Chicago hypothesize that Planet 9 might be a black hole. The orbit of Planet 9 looks something like this.
We used a semi-major axis of 700 AU, an inclination of 30 degrees and an eccentricity of 0.6. The plot shows the full orbit of Planet 9, but the simulation only shows 150 years of the other planets.
It would be very interesting to visit Planet 9. One way is to use a solar sail. The sail would start on a trajectory aiming at perigee very close to the sun and then accelerate at high speed. Another approach is to use a spacecraft propelled by Direct Fusion Drive, a fusion propulsion system we’ve been working on for several years. A 26000 kg spacecraft with a 12 MW engine and 2000 kg of payload could rendezvous with Planet 9 (based on the above orbit) in just 11 years. This is the spacecraft trajectory
Today, I will discuss two functions in release 2020.1 of the Spacecraft Control Toolbox (SCT) which can be used to get your spacecraft into a lunar orbit. They are LunarTargeting.m and LunarMissionControl.m. They are demonstrated together in the script LunarMission.m.
LunarTargeting.m produces a transfer orbit that starts at a Low Earth Orbit (LEO) altitude and ends up passing by the Moon with a specified perilune (periapsis of the Moon) and lunar orbital inclination. Its novel approach to the patched-conic-sections model of multibody orbital transfers uses the solution to Lambert’s problem to target a point on the gravitational boundary between the Earth and the Moon. Then it numerically optimizes over points on that surface until the initial velocity of the transfer is minimized. LunarTargeting.m requires the MATLAB optimization toolbox.
LunarMissionControl.m implements a control system which enables a spacecraft to propulsively enter lunar orbit. Like the other control systems implemented in the SCT, it stores its active state and degrees of freedom in a data structure, and accepts a list of commands as arguments. The commands we’ll see used here are ‘initialize,’ ‘lunar orbit insertion prepare,’ ‘align for lunar insertion,’ and ‘start main engine.’
LunarMission.m ties them both together and simulates a spacecraft, down to the attitude-control level. The simulation includes power and thermal models. The spacecraft can be controlled by reaction wheels or thrusters. Forces from the Sun, Earth, and Moon are included. The spacecraft starts on the trajectory returned by LunarTargeting.m, then acts in accordance to commands to LunarMissionControl.m. It takes the spacecraft 4.5 days to get to perilune, at which point it inserts itself into lunar orbit. Let’s take a look!
Take a look at the above figure. This is the entire mission trajectory in the Earth-Centered Inertial (ECI) frame. We can see the initial transfer orbit as the red line. Then it approaches the blue line (the Moon’s orbit), and begins corkscrewing around it after orbital insertion. Let’s look at that insertion in close-up:
The above figure shows the final part of the trajectory in Moon-centered coordinates. The red line starts as the spacecraft passes the imaginary gravitational boundary between the Earth and the Moon. It falls closer to the Moon, and at its closest point, fires its engines to reduce its velocity. You can’t see it in this figure, but that process is actually resolved on a 2 second timescale. The spacecraft is commanded to point retrograde using a PID controller, waits until it has pointed correctly, then fires its engines for a prescribed duration. If you look closely, you will see that moon has a 3 dimension surface courtesy of the Clementine mission.
Let’s finish this post off with some technical details:
On the far left, you can see the reaction wheel rates. They stay at zero for 4.5 days, as the spacecraft coasts. Then, when the craft is commanded to point retrograde for its orbital insertion, you can see wheels 2 and 3 spin up. Wheel 1 stays near zero; its vertical scale is 10^-16. Then in the center, you can see fuel use. The only fuel use is the insertion burn, so fuel stays constant until 4.5 days in. Less than 2 kg of fuel is used for this example, as the spacecraft is a 6U cubesat. On the right, the components of the body quaternion are displayed. Again, they are constant until 4.5 days in, when the craft is commanded to point retrograde.
I hope you’ve enjoyed this demonstration of how to simulate a lunar mission with the SCT! For more information on our toolboxes check out our Spacecraft Control Toolbox for MATLAB. You can contact us directly by email if you have any questions.
Not all the new functions in 2020.1 are specific to spacecraft. We have also been hard at work adding new functionality to the core toolbox. Here, I’d like to give an example of one of our new functions for performing a Wavelet analysis.
But what is a Wavelet analysis? Well, you plot the Wavelet transform of a signal when you want to visualize how the frequency spectrum changes in time. The Wavelet transform is a lot like a Fourier transform that you perform at every possible starting point, with an appropriate window function multiplied in so that you’re only looking at a portion of the signal.
But there’s one added wrinkle, because the frequency spectrum at a specific frequency at a specific time doesn’t technically exist. It’s not technically possible to know what the component of a signal at 100 kHz is at 0.5 seconds in, because the frequency spectrum depends on the entire signal. There has to be some trade-off between time resolution and signal resolution. If we look at a very long chunk of the signal, we can nail down its frequency components very well but we can’t see them change quickly. If we look at a very short chunk of the signal, we know precisely when the frequency changes but we can’t tell the difference between two similar frequencies. It’s a trade-off.
Now let’s get to the examples! The new function in 2020.1 is called WaveletMorlet because the specific window function we use is called the Morlet wavelet (A Wavelet transform using a Morlet wavelet is also called a Gabor transform). Here’s the signal that we’ll be analyzing:
We already know what we’re going to expect in this example. It looks like there’s a persistent, low-frequency component, then a higher-frequency component whose frequency goes up, peaks around 0.25 seconds, then goes down, and bottoms around 0.75 seconds. Here’s what the Wavelet transform looks like:
Great! Exactly what we expected. This was a simple case, but you can imagine how this analysis would be useful if there were a greater spread in frequencies, a longer signal, or both.
Now, let’s explore that trade-off that I mentioned earlier. What does the signal look like when you choose a different value on that trade-off? For the above analysis, I kept the default wavelet width parameter of 10. Here’s what it looks like when we prioritize time resolution over frequency resolution by choosing 5, then frequency resolution over time by choosing 25:
For a wavelet width parameter of 5, all that happens is that the signal gets broader in the frequency direction. For 25, what’s happening here? Sure, at 0.25 seconds it appears that the visualization is able to nail down the frequency to a tighter band, but what’s happening to the rest of the image? The answer is that the frequency is changing too fast for this chosen time resolution. The signal doesn’t spend long enough at any given frequency for the algorithm to identify a significant component there.
Thanks, all, for tuning in to this update from PSS, and thanks for this opportunity to get into the nitty gritty of one of our new mathematics functions!
It is sometimes necessary to change your orbit semi-major axis, ascending node and inclination with a low-thrust engine. It is easy to do, as long as you can point your engine along orbit normal and tangential to the orbit.
It is easiest to see how this is done by looking at the Gauss’ Variational equations, simplified for small eccentricity.
I is inclination, is semi-major axis, is the gravitational parameter, is argument of perigee, is true anomaly, is ascending node. and the orbit tangential acceleration and is the orbit normal acceleration.
The resulting simulation is shown below. Mode 0 is semi-major axis change, Mode 1 is ascending node change, Mode 2 is inclination change and Mode 3 is off. It is best to change inclination and ascending node at the highest semi-major axis. You should change ascending node at the lowest inclination. The burns are done where the rate of changes are higher. Some change in inclination and ascending. node will happen when the other is being corrected.
The script for this simulation with the controller is part of the Spacecraft Control Toolbox Release 2020.1 coming in May.
A popular way of launching a small satellite is to bring it up on an International Space Station resupply mission. The Spacecraft Control Toolbox has functions to help you animate the orbit of your spacecraft near the ISS. A function, ISSOrbit, generates the orbital elements for the ISS. ISSOrbit generates Keplerian Elements from the latest 2-line elements. We use the function CoplanarOrbit to create an orbit 50 m below the ISS. There are no disturbances and the gravity model is for a point mass Earth.
DrawSpacecraft.m is a function that will draw any number of spacecraft in the viewer. This is the ISS and our, very small, NanoSatellite. The MATLAB camera controls allow you to zoom in or rotate the view. The view is with respect to the first satellite entered in the argument list, which in this case is the nano satellite.
DrawSpacecraft also does animation and will create an avi file. You can see the animation on our YouTube Channel or by clicking the video below. We converted the avi file to an mp4 file using a movie converter.
The script is an m-file that you can download, just to view, here.
NASA would like a crew to land on the moon by 2024.
We didn’t have time to write a proposal, but here is our design. We propose a single stage vehicle, that can land from and return to a 15 km circular orbit. It uses 2 Blue Origins BE-3U engines that use cryogenic hydrogen and oxygen. An Orion capsule houses the astronauts. The Orion would take astronauts to and from Gateway and to and from the Earth. Lockheed Martin is building the Orion spacecraft. The European Space Agency is building the service module. A separate transport would bring fuel and payload to the lander. In the future, the lander could be refueled from lunar water.
The dimensions are in meters. The Orion is shown below. We purchased the model from https://hum3d.com.
The landing gear were scaled from the Apollo Lunar module.
It is interesting to compare its size with the Apollo Lunar Module. The Artemis is designed to fit into the 10 m SLS fairing. This a fully reusable lunar vehicle that can be refueled. It is designed for a long-term, sustainable, lunar base.
We use two toroidal hydrogen tanks and two spherical oxygen tanks. The cylinder on the outside is the solar array producing 34 kW of power. Of course, numerous details are omitted. We developed this model using our Spacecraft Control Toolbox. The design script will be available in the Spacecraft Control Toolbox Version 2019.1 due in mid-November.
Other elements of the lander were designed for different purposes. The GN&C system is based on our Army Precision Attitude Control System.
Our control system is based on a robotic lander we designed some time ago. We have full C++ code for the control and guidance system.
The architecture for Earth/Moon transportation system is shown below. Eventually, a Direct Fusion Drive freighter would be the main way of moving cargo between Earth orbit, lunar orbit and Gateway. The lander would remain in lunar orbit. Humans would go to the moon using fast orbital transfer, much like during Apollo.
Our next blog post will show how we get from Gateway to and from our 15 km starting orbit. A subsequent post will demonstrate our lunar landing guidance that uses a neural network for navigation based on images of the surface. Using it for landing would require higher resolution images than we have today, but short of building a lunar GPS system, it might be more cost-effective to have a satellite assembling images from low lunar orbit.
We will also update this blog post from time to time. Stay tuned!
We’ve added some new tools to the Aircraft Control Toolbox for our upcoming 2019 release. The first is a new GUI for creating aircraft models. You import a Wavefront OBJ files and then you point and click to define leading edges, wing areas, engine locations and so forth. This makes it easier to import the geometric data. The GUI is shown below. It illuminates the view that you need to use for a given geometric element in red. The inertia matrix is generated from the mass and the surface geometry.
A new simulation function was added to use the data from this GUI. It has a flat Earth aircraft model with a plugins architecture. You can add your own lift, drag and thrust models or use the simple built-in models. It is much simpler than AC.m which is designed to be a comprehensive high-fidelity simulation. We’ve added a new animation GUI to show you the results of your simulations.
We expect 2019.1 to be available in June. You can get a demo with previews of the new functions now.
Apress has released a second edition of our textbook, MATLAB Machine Learning Recipes! New chapters include Fuzzy Logic and Expert Systems. We have also expanded our discussions of Neural Networks and Multiple Hypothesis Testing. The book provides a broad overview of machine learning including topics from adaptive control and estimation. Examples include learning control of aircraft and automobile target tracking.
Hello PSS fans! This is Charles Swanson, recently minted doctor of plasma physics and PSS’s newest employee. It’s my distinct pleasure to discuss our most recent NASA contract: A Phase III SBIR to integrate our Low Energy Mission Planning Toolbox (LEMPT) into NASA’s open source Orbit Determination Toolbox (ODTBX).
Have you read about the kinds of maneuvers conducted by Hiten and AsiaSat 3 that allowed them to reach orbits that would seemingly be outside their Delta-V budgets? Have you always wondered how one goes about planning such maneuvers?
What about the Lunar Gateway from which NASA plans to stage missions to the surface of the Moon in the coming decades? What kinds of clever orbital tricks can we use to get to, from, and about the Moon with the minimum possible fuel?
That’s what LEMPT is for. LEMPT is a suite of tools written in MATLAB for the planning of low energy missions, the kinds of missions that loop way outside the target orbit of the Moon and deep into chaotic regions of the gravitational landscape. Here’s an example:
This LEO to Lunar Orbit mission takes just one impulsive burn of 2.8 km/s. It loops way outside the Moon and back in for a ballistic capture.
To go from LEO to a low lunar orbit usually takes almost 4 km/s of Delta-V. The maneuver depicted takes only 2.8 km/s. This is the kind of planning capability that NASA would like for their ODTBX. From now until December, we’ll be integrating the LEMPT into ODTBX, where it will help NASA mission planners evaluate all of their options along the trade-off of mission time and Delta-V.
The orbit above doesn’t look anything like the Keplerian ellipse that we know and love. That’s because this is a four-body system, with the Sun, Earth, Moon, and spacecraft all interacting gravitationally. Even the three-body system is famously chaotic: here are two examples of the kind of distinctly weird-looking orbits you can get:
This is a periodic orbit in the Sun-Earth-Spacecraft system. Periodic orbits are rare in such systems.
This orbit starts with only 0.01% more velocity than the periodic orbit but escapes the Earth entirely. This is an example of chaos.
It’s this chaos that the LEMPT leverages to plan exotic and efficient maneuvers.
The first soft moon landings were accomplished in the 1960’s by the Soviet Luna 9 and the U.S. Surveyor Spacecraft. These were followed by the U.S. Lunar Module landings during the Apollo program. The Soviets had their own LK Lander lunar lander for landing humans on the moon but it never flew. China’s Chang’e-3 landed on the moon on December 13, 2013. India plans to land the Chandrayaan-2 on the moon in 2018. South Korea intends to land a spacecraft on the moon in 2020.
The U.S. Lunar Module was flown by a crew but had a digital computer that performed guidance, navigation and control. A great new book by Don Eyles, Sunburst and Luminary an Apollo Memoir explains how that was accomplished with a computer less powerful than those in toaster ovens today. Don played a key role in saving the Apollo 14 mission when an abort light appeared on the crew’s console prior to descent. Read the book for for the whole story.
NASA intended follow-ons to the Lunar Module that would have been fully automated for delivering materials to the moon in preparation for a permanent human presence. Unfortunately, those plans never materialized.
As we are always looking for new missions for testing our Precision Attitude Control System, we added guidance, navigation and control for lunar landings. We use a really simple guidance algorithm called 2nd order guidance. It is nothing more than a Proportional Derivative (PD) controller with the landing spot as a target. You can adjust the damping ratio and undamped natural frequency of the controller to mimic more sophisticated, “optimal” guidance algorithms. The 2nd order guidance works until the lander gets near the surface and then it switches to landing algorithm that hovers, nulling any remaining translational velocities and then descends to the surface. Lidar would be used as guidance. Once it is hovering it would need to search for a flat spot for landing. NASA has developed Hazard Detection Software for Lunar Landing that uses lidar. It is available for licensing from Caltech.
Here is one simulation in our Simulation Framework. Once the descent is initiated, the spacecraft reorients so that the main engine thrust vector is in the desired direction. The display on the left shows the attitude errors (the two boxes) and the throttle setting (which is zero during the attitude maneuver.)
A close up of the attitude display. Pitch and yaw are offsets of the green rectangle. Roll is rotation of the rectangle. This is quite primitive but it is easy to add your own displays if you know a little OpenGL!
Descent starts and the throttle is about 50% at this point. The two plots are of altitude and velocity. The maneuver starts at 15 km and the target is 600 km along track. The lander has solar panels on a two-axis gimbal and a high gain antenna, also on a two-axis gimbal.
The propulsion page shows two attitude thrusters firing and the main engine.
The spacecraft has landed! You can see the terminal descent phase on the altitude and velocity plots. The lunar surface is featureless because we have not added close up maps of the landing zone to the planet display.
The descent page shows the throttle settings. You can monitor the guidance force demand and simulated force.
This is the propulsion page. The attitude thrusters get very busy during the terminal descent phase. Note that we have a lot of fuel left! We could have hovered for quite some time.
This GN&C system is capable of autonomous flight from LEO all the way to the moon. It uses our Optical Navigation System, developed under a NASA Phase II SBIR for trajectory determination on the flight to the moon and lunar orbit entry.