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.

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?