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!
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:
The 1-burn inclination change solution for 49.5 degrees. This requires a truly impractical amount of delta-V.
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)
The 3-burn inclination change solution for 49.5 degrees. Loops out to high altitude before changing inclination. This also requires an impractical amount of delta-V, but it is a smaller amount.
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:
A Hohmann Transfer from LEO to GEO, which is also the fuel-optimal transfer. Burn once to raise the apoapsis to the target altitude, then again to raise the periapsis.
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:
Transfer trajectories from LEO to GEO optimizing not just for fuel use, but for fuel and time. Left: 1 hour counts as 1 km/s. Right: 1 hour counts as 2 km/s
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?
Delta-V expended
Time spent coasting
0 km/s (I don’t care about time)
3.89 km/s
5.28 hours
1 km/s (I care about time a little)
5.06 km/s
3.29 hours
2 km/s (I care about time a lot)
6.23 km/s
2.55 hours
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?
Yes, that is the name of the very famous computer game.
In our last blog post we talked about optical navigation for lunar missions. Optical navigation is also very valuable for asteroid missions. It is being used today on OSIRIS-REx. The system we developed can be used anywhere in the solar system without, hopefully, too much attention from the ground.
Now that you’ve decided to go to an asteroid, where are they? As it turns out there is a fabulous website with a downloadable database of asteroids http://naic.edu/~nolan/astorb.html. You can download a file with thousands of asteroid.
In Version 2020.1 of the Spacecraft Control Toolbox, we’ve added a function to plot the asteroids. It reads the file and returns the orbital elements, name, number and epoch. Here are two examples of asteroids in motion.
Ceres is the most famous asteroid. You may find one named after you! If you want the bigger picture, here is a second plot with 1000 asteroids. The circles are the orbits of Earth and Jupiter. The function will propagate all the asteroids you select if you don’t request any outputs.
There is great interest in lunar missions. The U.S. plans to land astronauts on the moon in this decade. Several commercial companies are working on landers. Many other national space programs are working on their own landers and rovers.
As with all spacecraft, you need to know where you are. The traditional way is to use a communications link from the ground to get range and range rate (via Doppler shift.) This works well but you need to collect data over a long period of time to get an 3-dimensional fix.
Recently, NASA discovered via the Magnetospheric Multiscale Mission (MMS), that GPS could be used at altitudes higher than the GPS altitude, and maybe all the way to the moon!
Princeton Satellite Systems developed an Optical Navigation System for NASA as part of an SBIR project. It uses two cameras. One is a navigation camera mounted on a 2-axis gimbal that looks for nearby planets or asteroids. A second camera points out of the orbit plane just looking at the star field. The navigation camera has sufficient dynamic range so that it can image a planet or moon and still see stars. The whole system works as a sextant, that has been used by mariners for hundreds of years. The Apollo astronauts used a sextant for backup navigation. Our system automates the process so that it is fully autonomous. Our simulations for the SBIR were for deep space missions, like simulated NASA Messenger and New Horizons spacecraft, and for communication satellites.
Recently we’ve customized the system to lunar missions. The following images are from a MATLAB script that simulates a transfer from the Earth to the Moon. The first is from the star camera pointing out of the orbit plane. The numbers are the star id from a list and don’t correspond to numbers in the Hipparcos Catalog which is used for the star simulation.
The second is the navigation camera, that points at the moon. The star moves as the relative angle changes. The circle around the moon is its disk.
The third shows the trajectory. It starts from behind the Earth. A lunar orbit insertion is done when the spacecraft reaches the moon.
Here is the spacecraft in lunar orbit.
The simulation runs until the spacecraft reaches the moon. The following video shows the simulation in action.
The simulation uses functions coming out in the 2020.1 release of the Spacecraft Control Toolbox. Contact us for more information!
In the “good old days” the only people worried about rendezvous were those designed space missions with crews. ISS established the need for robotic rendezvous and docking on a regular basis.
Orbit dynamics can be complex. If you are looking at rendezvous with any other spacecraft in a very different orbit you can start with Lambert’s Time-of-Flight algorithm. Given initial velocity and position vectors, and desired final position and velocity vectors and time of flight, it will give you the initial impulse velocity change needed to rendezvous. There are numerous formulation as it is complex math problem.
If you happen to be close to your target you can formulate your orbits as a relative orbit problem with Hill’s equations, shown below in state space form.
[pmath size=12]n[/pmath] is the orbit rate of the target spacecraft. [pmath size=12]x[/pmath], [pmath size=12]y[/pmath] and [pmath size=12]z[/pmath] are the position of the “chase” spacecraft in the Hill’s frame. [pmath size=12]a[/pmath] is the control acceleration. You want to reduce the positions and velocities to zero. This can be done with a Proportional Derivative (PD) Controller, or with a Linear Quadratic (LQ) Controller. If your chase and target spacecraft have GPS it is relatively easy to find this state vector in the above equation. A PD controller will ignore the coupling in the above equations while the LQ will accommodate the coupling.
It is interesting to look at the gain matrices for the two cases and the corresponding eigenvalues. We tweaked the PD to make its position gains close to that for the LQ. The PD is designed for a damping ratio of 1. The eigenvalues are identical. The cross-axis gains are small, but non-zero.
The results are very close. The PD has no overshoot, as expected. The LQ is slightly faster but has some overshoot. Both get the chase spacecraft to the target in a few minutes, assuming, of course, that you have the acceleration capability shown in the plots.
Both are linear controllers. You can approximate a linear controller with thrusters by using pulse width modulation. An issue will be the minimum impulse bit of the thrusters, that will lead to a minimum velocity and position error that can be achieved.
This script is included in the Spacecraft Control Toolbox 2020.1 coming soon!
Many small satellites are launched from the ISS or near the ISS by one of the transfer vehicles. A new function in the Spacecraft Control Toolbox 2020.1, coming in May, allows you to visualize your spacecraft near the ISS. Here is an example. You can also display a trajectory.
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, [pmath size=12]a[/pmath] is semi-major axis, [pmath size=12]mu[/pmath] is the gravitational parameter, [pmath size=12]omega[/pmath] is argument of perigee, [pmath size=12]nu[/pmath] is true anomaly, [pmath size=12]Omega[/pmath] is ascending node. [pmath size=12]a_T[/pmath] and the orbit tangential acceleration and [pmath size=12]a_N[/pmath]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.
We developed a round trip mission to Mars using Direct Fusion Drive. Key parameters are:
Specific power of 1.2 kW/kg
Exhaust velocity of 110 km/s
40 MW engine
Payload of 55 MT out, 40 MT return
Outward leg 128 days
Inward leg 110 days
Stay on Mars 650 days
The following plot shows the trajectory. Some additional time would be needed to enter and exit the Mars and Earth’s orbit. That could be shortened by using a nuclear thermal engine tug.
The payload is based on the NASA Deep Space Habitat. It could be replaced by a less massive habitat and a lander. Two spacecraft, one including a lander, is another possibility. A dual spacecraft mission would enhance safety.
This mission plan has the DFD decelerating the spacecraft and going into Mars orbit. Some time could be saved using aerodynamic braking. The mass of the aeroshell would need to be included as part of the “engine” mass.
It may from time to time necessary to damp nutation with thrusters on a momentum bias spacecraft. For example, nutation can happen when you transition from stationkeeping mode, which uses thrusters, to normal mode, in which you use low control authority actuators, such as magnetic torquers, for control.
We’ve written a script that simulation a momentum bias spacecraft. Let’s show the results.
The spacecraft body rate is 0.01 rad/s. This is much greater than you will ever see on your own spacecraft. The peak roll angle is about 18 degrees! The last plot shows the thruster control. In this simulation we don’t apply any control so the line is flat.
All you need is one thruster pulse, properly timed, to drive the x angular rate to zero. You must time it properly so as not to not leave a roll error. What we do is measure the peak angular rate, compute the pulsewidth needed to drive the rate to zero, and turn on the thruster when the roll angle is zero and the nutation rate is at its peak with the appropriate sign. The following plot shows the results.
The results aren’t perfect, as they would not be operationally. We did both simulations with the same Spacecraft Control Toolbox http://www.psatellite.com/products/sct/ script. This is a link to the m-file, saved as a zip file.
You won’t be able to run this without our toolboxes but you can see how we implemented “manual” nutation control. This script, and the new function RHSGyrostat.m will be available in SCT 2020.1 coming soon!
