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
Spacecraft with thrusters or instruments with large magnetic dipole will experience torques in a planetary magnetic field. U.S. Patent 10,752,385, just granted to Princeton Satellite Systems, uses a current loop to cancel the magnetic field of the onboard dipole. The patent text is:
“A dipole cancellation system and method may include a plurality of magnetometers for measuring a device magnetic field associated with a plurality of device coils generating a device magnetic field having a primary magnetic dipole moment. A compensating coil carrying a compensating current running a first direction that generates a compensating magnetic field having a compensating magnetic dipole moment. The compensating coil may be positioned and the first current may be selected so that the compensating magnetic dipole moment completely cancels the primary magnetic dipole moment. A method may use the system to stabilize a spacecraft by calculating an estimated torque of the spacecraft, receiving a value for an external magnetic field, receiving a value for a device magnetic field, and calculating and applying a compensating current may be then applied to the compensating coil to cancel the primary magnetic dipole moment, wherein the spacecraft is stabilized.”
Helium-3 is available in the regolith of the moon and is a possible fuel for advanced nuclear fusion reactors on Earth. It would be extracted from the lunar regolith, packaged and returned to Earth. One question is how to return the helium-3 to the Earth. One approach is to use aerodynamic braking to return the helium-3 to a low Earth orbit where it would be picked up by the Space Rapid Transit (SRT) reusable launch vehicle and delivered to an airport where it would be shipped to power plants. SRT It is a two stage to orbit vehicle with a hypersonic air-breathing engine in the first stage.
The overall architecture is shown below.
One of the major advantages of SRT is that it can land and takeoff at any major airport. The first stage can be used as a transport vehicle. Since it is fully reusable and operates like an aircraft it is potentially much less expensive than vertical launch.
The return from the Earth involves launching the helium-3 tanker into orbit and then doing a departure burn that puts the spacecraft in an elliptical Earth orbit with a low perigee. As the return vehicle passes through perigee, aerodynamic drag lowers apogee until apogee and perigee are the same. This is shown in the following plots.
The first plot show the altitude from the Earth, the velocity magnitude and the drag force magnitude. The second plot shows the orbit. The last plot shows how apogee is reduced with each pass through perigee. It takes 10 weeks to enter the final orbit if the orbit perigee is 100 km. Note that perigee doesn’t change. The simulation uses a free-molecular aerodynamic flow model. For simplicity, it does not include lunar gravity perturbations.
Ideally, the lunar return vehicle would be brought back to Earth and reused.
The maneuver uses only drag. A lifting vehicle would have an additional degree of freedom since the force vector could be controlled.
This analysis was done with the Spacecraft Control Toolbox. The function will be available in Version 2020.2 available in early fall. Contact us for more information!
Power went down when Hurricane Isaias moved in. Fortunately our customer had a SunStation solar power system with Lithium battery backup. Unlike other solar systems, this system has a transfer switch to disconnect the solar system from the grid so that the solar power system can power the house when the grid is down. The batteries provide enough power to keep critical systems going when it is really cloudy or at night.
You can see the system in operation here. The first shows the system when the solar power is insufficient to power the house.
The following shows the system with enough solar power to charge the battery and power the house.
Even on a cloudy day, you usually get enough solar power to keep the house running. The 0.2 kW load includes lighting, refrigerator, WiFi and other loads. This system has 14.4 kWh of storage, so it could run the house, without solar, for 72 hours.
For more information check out our SunStation page.
Over 80 new functions and scripts were added in Version 2020.1. Updates were made to dozens of existing functions to improve their performance and expand their applications. Built-in demos and default data structures were added to many more functions.
In the Spacecraft Control Toolbox, we added new tools for orbit control. The figure below shows a low thrust orbit raising starting from the ISS orbit and proceeding to a higher inclination, higher semi-major axis orbit. The controller also can change the ascending node.
A new function, was added for animating spacecraft. The image below shows two spacecraft in formation.
A new function that provides the Keplerian elements for asteroids was also added.
Optical navigation demonstrations for Earth/Moon missions were added. this shows the centroid and lunar disk. The system uses a high dynamic range sensor that can see stars and the moon at the same time.
For operations people, a demonstration of one pulse nutation damping was added. Both roll angle and angular rate are reduce nearly to zero with one thruster firing.
The Aircraft Control Toolbox has many new features specifically added to support electric airplane development. This includes a new propeller efficiency model.
Please contact us for more information! If you have purchased our toolboxes or updated your maintenance in the last year, the update is free!
We are pleased to share that PSS has been selected for two NASA Small Business Innovative Research (SBIR) awards. The SBIR program enables small business to engage in research or research and development funded by the federal government. The purpose of a SBIR award is to move toward commercialization of a product. It’s a great program that allows small businesses to get a product on the market without putting up as much of their own internal research and development funds.
Our first award is for a proposal called “Neural Space Navigator.” This proposal is for research that builds off of our Optical Navigation System (ONS), adding a new capability to the system: Terrain-relative navigation using neural networks. This capability comes at a critical time for NASA’s ongoing lunar exploration program, whose small Commercial Lunar Payload Services (CLPS) landers are scheduled to have their first missions in 2021. In Phase II, we would work with Lockheed Martin (LM). LM created the optical navigation system used on NASA’s OSIRIS-REx mission. Professor Michael Littman of Princeton University will be helping on this contract.
Our second award is for a proposal called “Multi-Megawatt Superconducting Motor for Electric Aircraft.” This proposal is for research toward a powerful superconducting motor for use in partially- and fully-electric aircraft. We are working with Superconducting Systems, Inc. from Massachusetts on this contract. There are some great ideas for ways to make aircraft more fuel-efficient using electric motors (see a NASA report here for some examples). This research will make lighter and higher power motors possible, powerful enough to propel large commercial aircraft, allowing some of the concepts in that report to become a reality.
This work is a spin-off of our nuclear fusion work, in particular our current NASA STTR (with PPPL) to study the effects of plasma pulses on superconducting coils.
We are very excited to be working with NASA on such interesting projects. The next step in the process is contract negotiations, in which the details of the proposed research are hammered out. If the next 6 months go well, these awards can serve as the basis for a Phase II SBIR, which awards significantly more time and resources.
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.
Princeton Satellite Systems has been in a leader in renewable energy with its SunStation home solar power system with battery backup. We introduced this product back in 2013. SunStation has lithium-ion phosphate batteries, the most stable and reliable batteries for home use. The core of the system is the Outback Inverter that seamlessly switches from grid power to internal power.
The solar system in the installation produces 7.3 kW of power, much more than the house needed for electric power including charging a Nissan Leaf and Toyota Prius Prime. The heating and air conditioning system was nearing its end-of-life so we decided to replace it with a geothermal heat pump. A heat pump is essentially an air conditioner that can both reject heat to a source and absorb heat from a source. The problem with both is that when the outside temperature is high, for rejecting heat, and low, for absorbing heat, the system loses efficiency. Modern air-source heat pumps are very efficient but do need backup resistance heating in some climates.
A ground source heat pump, or geothermal heat pump, uses the ground as the medium for absorbing or rejecting heat. The option we chose, due to land constraints, is to have two wells several hundred feet deep as the source. Alternatives are trenching, or a pond if you have one in your yard. The ground is always at around 50 deg F. The system was sized so that it rarely, if ever, needs resistance heating.
The geothermal system, which is made by WaterFurnace, was installed by Princeton Air. No changes to the SunStation were needed. The core geothermal system is shown below. The valves to the ground loops are in the foreground and the geothermal system is on the left.
The lines that run to the outside ground loops are shown below.
The system has a preheater for the (still gas) hot water heater. The gas water heater was less than a year old, so it didn’t make sense to replace it. The preheater is an electric hot water heater that does not have the heating coils connected.
The SunStation is shown below. The Outback inverter is on the bottom left. The boxes on top provide arc protection, which is now included in the inverter. The batteries on on the right and the battery management electronics between the inverter and the battery cabinet.
The well digging was quite a project. This picture shows the drilling rig.
This second picture shows the yard after the drilling was complete. Drilling took three days total.
The following system shows the SunStation with geothermal in operation. The Prius Prime is charging which is most of the load. The system is still sending considerable power to the grid. On average the house powers itself and two other houses.
Geothermal, with solar and battery backup is the ideal solution for new homes and for renovations to existing homes. There is no reason to even have a gas hookup anymore. Contact us at SunStation for more information
This is the second of two blog posts which introduce functionality from the Orbit Transfer Module of the Spacecraft Control Toolbox(SCT). The Orbit Transfer Module has lots of tools to allow you to numerically optimize the engine burns that a spacecraft needs to apply to go from some initial orbit to its target orbit, with a minimum of fuel used, time elapsed, or some other metric. You can do this to impulsive burns, continuous (low-thrust) burns, and a special model that splits large impulsive burns into many small impulsive burns.
In this blog post, I’d like to discuss an interesting thing that happens when a spacecraft aims to change its inclination by more than 37 degrees. In real life, of course, this would never happen. This is a truly impractical amount of inclination change. If you were truly faced with a mission that required coverage of orbits that were different by 37 degrees, you would simply launch two spacecraft.
But if you were to explore this hypothetical, you would find an interesting feature emerge. Here we will consider the case that a spacecraft starts in a circular, equatorial LEO and targets a circular LEO which is 49.5 degrees inclined to the equator. The well-known solution is to burn once, at the common node of the initial and target orbits, to change direction by the target inclination:
As we can see from the above figure, this inclination change requires 6.47 km/s of delta-V, almost the spacecraft’s entire orbital velocity!
But, as the Orbit Transfer Module’s OptimizeElementsImpulsiveSearch finds, there is actually another transfer which can marginally reduce the delta-V required for this inclination change. It finds that the following transfer saves delta-V:
Burn prograde to raise apoapsis (and a very slight inclination change)
Coast up to apoapsis, where inclination change is cheaper
Perform an inclination change
Coast down to periapsis
Burn retrograde to lower apoapsis (and a very slight inclination change)
As we can see from the above figure, this transfer only expends 5.97 km/s of delta-V. While this is still impractical, it is interesting that there exists this other category of optimal inclination transfers which exists for high inclination changes.
It is interesting to note that, for 0 through 37 degree inclination changes, the direct approach is superior. Then, from 37 degrees to 60 degrees, this 3-burn solution produces a smaller required delta-V. Above 60 degrees, the intermediate, high-apoapsis orbit actually exceeds escape velocity so the transfer takes infinite time.
In this blog post, we are going to introduce you to functionality found in the Orbit Transfer Module of our Spacecraft Control Toolbox. The Orbit Transfer Module has lots of tools to allow you to numerically optimize the engine burns that a spacecraft needs to apply to go from some initial orbit to its target orbit, with a minimum of fuel used, time elapsed, or some other metric. You can do this to impulsive burns, continuous (low-thrust) burns, and a special model that splits large impulsive burns into many small impulsive burns.
The following is an example of a case in which the impulsive burn optimization functions can reveal new and interesting classes of orbit transfer trajectories.
The spacecraft starts in a circular, equatorial low Earth orbit (LEO) and targets a circular, geosynchronous equatorial orbit (GEO). The fuel-optimal trajectory is well known: a Hohmann Transfer, wherein the craft burns once to raise its apoapsis to the target altitude, then at apoapsis it burns again to raise its periapsis to the target altitude. It looks like this:
The craft starts in the blue LEO orbit, then at the big black arrow it burns its engine until 2.42 km/s of delta-V has been applied, then coasts for 5.28 hours on the yellow transfer orbit until it reaches the altitude of the purple dashed, target orbit. Then a final insertion burn until 1.47 km/s has been expended, and GEO has been achieved! Final tally: 3.89 km/s of delta-V has been expended and it took 5.28 hours to get to the requested orbit.
This Hohmann transfer results from optimizing for the minimum delta-V expended, but what happens if you optimize both fuel and coast time? If you care just as much about decreasing the elapsed time by one hour as expending 1 km/s of fuel? The function OptimizeElementsImpulsiveSearch can solve this problem also. Take a look:
In these plots, we’ve told the optimizer that we care about both fuel and time. In the plot on the left, we’ve specified a tradeoff of 1 hour of elapsed time to 1 km/s of delta-V. If the optimizer can decrease the coast time by more than 1 hour at the cost of 1 km/s delta-V, it will do it. And we can see that the optimizer has in fact returned a faster, more delta-V intensive trajectory. Final tally: 5.06 km/s of delta-V has been expended and it took 3.29 hours to get to GEO.
In the plot on the right, we’ve specified a tradeoff of 1 hour of elapsed time to 2 km/s of delta-V, indicating that we care much more about elapsed time than the previous case. And again, we can see that the optimizer returns an even faster, even more delta-V intensive trajectory. Final tally: 6.23 km/s of delta-V has been expended and it took 2.55 hours to get to GEO.
Time tradeoff: 1 hour is worth how much delta-V?
Time spent coasting
0 km/s (I don’t care about time)
1 km/s (I care about time a little)
2 km/s (I care about time a lot)
Numerically optimized LEO GEO transfer trajectories, given different priorities between delta-V and time. These 3 points are part of a family of trajectories which are called fuel-time optimal.
We can visually verify the fingerprints of this faster transfer on the plots. The transfer orbit in the Hohmann transfer ends right at the target altitude, but for 1km/s = 1 hour, the transfer orbit extends out beyond this altitude, and for 2 km/s = 1 hour, the transfer orbit extends farther still. This is a hallmark of being a faster transfer orbit. The spacecraft doesn’t actually loop all the way out there; it performs a braking and insertion burn when it gets to the required altitude.
There are real-world scenarios where you’d want to do this. If your spacecraft is sensitive to radiation and you want to minimize the time spent in the Van Allen belts, for example. Or taking a more science-fiction approach, what if you need to urgently resupply or rescue a stranded crew?