Using Ephemeris for Launch Window Analysis

October 4th, 2011

When performing a launch windows analysis, in most cases the Launch segment is sufficient to solve for the launch epoch. But what if you have ECF ephemeris provided by a launch vehicle manufacturer and want to use the precomputed trajectory?

Using the Scripting Tool in Astrogator and an auxiliary object, you can have Astrogator target the start time of the ECF trajectory, mimicking the Launch segment but using your ephemeris instead. The steps in this process are:

1. Create a new vehicle and use the StkExternal propagator. Turn on the option to "Override the times contained in the file". Select the ephemeris file containing an ECF trajectory.

LV

2. Use a Follow segment and set the new vehicle to the reference vehicle. Use "Join at Beginning of Leader's Ephemeris" as the joining condition. If you wish to use the entire ephemeris, use "Separate at End of Leader's Ephemeris" as the separation condition.

follow

3. Move the Follow segment into a Target Sequence and go to the Scripting Tool embedded in the profile you wish to use (Differential Corrector, Optimizer, etc.). Create a parameter which will act as the control for the profile. Inside the script, get access to the Object Model and set the "Time of first ephemeris point" to the parameter value.

st

4. Configure the profile for any other controls and results you wish to achieve.

Now when the target sequence profile runs, the start time of the reference vehicle will be changed as the profile attempts to find the value of the parameter which meets the desired constraints/results. Because the Astrogator satellite is following and joining at the beginning of the reference vehicle you are also moving the start of the follow segment indirectly.

STK 9.2 is available

May 19th, 2010

Last week STK v9.2.0 was posted on the ADN: http://adn.agi.com/detailedView.cfm?resourceId=319.  There are no new Astrogator features in the release, as we've been focusing on longer-term usability improvements we hope to have ready in 9.3.  But, there are several bug fixes for Astrogator in 9.2, described in the release notes here: http://www.agi.com/resources/help/online/stk/index.html.  All of these bugs were found by customers, and I'd like to thank them for reporting them.  Whenever you see something strange please, please call support.

LEO to GEO transfer with optimal control

April 22nd, 2010

In STK 9.1 primer vector theory can be implemented to solve optimal control problems.  In primer vector theory additional variables called costates, which represent the sensitivity between the initial conditions and the final state, are added to the state vector.  These costates describe the primer vector, which is the optimal thrust direction.  To solve a transfer problem, the initial values of the costates that yield the desired final orbit must be found.

To use primer vector theory in Astrogator, make user variables (introduced in 9.1) for each costate.  Add an equation of motion (EOM) plugin to the force model that gives the derivative of the costates with respect to time, so that Astrogator integrates the costates with the rest of the state.  Then, use an attitude plugin to point the thrust in the direction of the primer vector.  To find initial values for the costates, the built-in differential corrector or optimizer can be used, or you can use your own optimization algorithm through a search plugin.

Our graduate intern Patrick created this example scenario implementing primer vector theory.  He recreated a problem from a Journal of Guidance, Control, and Dynamics paper by Jean Kechichian.  The document "A Sample Optimal Control Problem" in the zip file describes the problem and gives some details about primer vector theory.  The transfer problem is from circular LEO with 28.5 degree inclination to near-circular GEO with 1 degree inclination.  The transfer uses a constant acceleration engine.  Patrick was able to recreate the transfer orbit in the paper by using the same values for the initial costates.  He also was able to show that he could solve for nearly the same values of the costates with various optimization algorithms, by giving the optimizers initial guesses offset from the optimal values.

To run the scenario the plugins must first be registered with STK.  Open the zip file and follow the instructions in the document "Optimal Control Code Registering Instructions."  The instructions explain how to register the EOM plugin - used for propagating the costates, the attitude plugin - used for pointing the thrust vector in the direction of the primer vector, the engine plugin - used to model the theoretical constant acceleration engine used in the paper, and the search plugin - which shows how to hook up the SNOPT and CMA-ES optimization packages to solve for the costates.  The optimization packages themselves are not included; a free version of CMA-ES can be downloaded here, while SNOPT must be purchased.

The document "Creating the Optimal Control Scenario" gives detailed instructions on how to create a scenario like this from scratch.  The scenario included in the zip file already brings you through Step 4 of the document.  Step 5 walks through solving for the costates using the CMA-ES code.leo2geoXfer

STK 9 is out!

May 20th, 2009

You can download STK 9 now from http://adn.agi.com/downloadCenter/.   The base download version of STK 9 only has central body data for the Sun, the Moon, the eight planets, and Pluto.  If you need data for Ceres or the other moons in our solar system, you'll also have to get the planetary data supplement, available at the same location.  Both of these are also on the STK 9 DVD.  If you have a maintenance agreement you should be getting the DVD in the mail during the first week of June.

Maneuver with an uncalibrated engine

May 11th, 2009

Here's a simple example that illustrates some of the functionality of the new scripting tool in STK 9.

In this example, a plane-change maneuver is being performed to complete an insertion into geostationary orbit.  A differential corrector is used to find the necessary duration of the maneuver to complete the plane change.  But, the engine that will be used has never been fired before.  Because we're going for a zero inclination, if the maneuver runs hot it will end up flipping the ascending node, which we want to avoid.  So we want to reduce the size of the maneuver from the ideal case - in this case by performing 97% of the maneuver.  On the next orbit the rest of the burn can be performed to finish the plane change, after we see how well the first maneuver performed.

The question is, how do we get Astrogator to model performing 97% of the ideal maneuver?  The answer is: Scripting Tool.

Start by setting up the targeter as if the whole maneuver will be performed.  Set up a differential corrector (DC) profile that targets the necessary burn duration to give you the desired plane change.  This gives us the ideal situation.

Now, add a Scripting Tool profile after the DC in the targeter's list of profiles.  We'll use this profile to modify the burn duration that the DC found.

In the scripting tool, add a segment property called BurnDuration.  Set it to the maneuver segment, and make the attribute FiniteMnvr.StoppingConditions.Duration.TripValue.  That's the attribute that controls the burn duration.  We want to take the value it already has from the previous profile and use 97% of it, so make the script say:

BurnDuration = 0.97 * BurnDuration;

Now when you run the MCS, the DC will find the ideal maneuver for the plane change, and the scripting tool will make the maneuver use 97% of the ideal.  If that multiplication factor might change, you can make a parameter for it and set it initially to 0.97.  Then the script becomes:

BurnDuration = factor * BurnDuration;

scriptingtool

With the factor a parameter, it can be changed through Connect or the object model, and also used as a control in an outside targeter.

Release to PM

May 8th, 2009

This week STK 9 was released to product management.  They're saying it should be available for download in the last week of May.  We'll start mailing out CDs to customers shortly after that.

Since we now have a final version, it's safe to start posting some examples here.  Look for those soon.  We'll put up some examples of the new scripting tool and optimizer.

Countdown to Astrogator 9!

April 21st, 2009

It's been a while since the last post, I know.  I'm sure this blog is feeling quite neglected.  Fear not though, now that STK 9 is about to be released, we'll have lots to say.

That's right, the long-awaited release of STK 9 is almost upon us.  Development has been given a deadline of May 1st to hand over the release to Product Management.  From there, the CDs will be produced and then mailed out to customers.  Currently, Development is on-track to meet the deadline (134 issues remaining right now), so expect general availability in mid to late May.  For our part, Astrogator's issues have all been verified and we're passing all regression tests.  We're just putting the final touches on some documentation.

This release has a lot of great additions to Astrogator, including a scripting tool, an optimizer, and access and lighting stopping conditions.  Plus, we've added Astrogator to the STK Object Model to make it easier to run Astrogator from a  script or write custom applications that use Astrogator.  Over the next few weeks we'll put up posts describing the new features in detail.  We'll also keep you posted on the release date.

IBEX is up!

October 20th, 2008

Congratulations to everyone on the IBEX team on their successful launch.  Our friends Lisa Policastri, John Carrico, and Mike Loucks worked on the trajectory design (using Astrogator of course).

IBEX stands for Interstellar Boundary Explorer, and will be examing the interaction between the solar wind and interstellar space.  It launched off of a Pegasus, and will end up in a highly elliptical orbit with a ~320,000 km apogee.

Here is AGI's press release on the mission.

Atmospheric Density from a table lookup

October 17th, 2008

Another request that stemmed from the Users' Conference was the ability to use a user-defined atmospheric model for calculating drag. This can be accomplished using the HPOP Force Model plugin interface. During the Evaluate call, a user can set the density value. Read in a file and do some interpolation and you're set! I put together a C# plugin to show one way this could be done, using a CSV of altitude and density.

Reentry Trajectories

Comparison of trajectories using Astrogator's US standard atmosphere model and my interpolated table.

Read the rest of this entry »

“Simultaneous” propagation with Astrogator

October 13th, 2008

Using the Astrogator GUI, satellites are propagated in a batch fashion. If you have two Astrogator satellites, you propgate one, then propagate the other. If you are using relative motion calculation objects to simulate formation flying, the usual method is to propagate a master satellite for the length of the analysis, then propagate a follower satellite that targets relative positions based on the master. This works well if the master doesn't perform any maneuvers based on the location of the follower. If it does, a different strategy is required.

Wobble
This different strategy is Astrogator Automation.

Read the rest of this entry »