Astrogator

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.

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.

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

Read the rest of this entry »

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.

This different strategy is Astrogator Automation.

Read the rest of this entry »

Thanks everyone who attended our Users' Conference this week! I enjoyed the discussions with you on how you could utilize Astrogator for many different, wide-ranging use cases and am looking forward to helping move you ahead in your usage of Astrogator. Some of the samples may even turn into blog posts!

Space Exploration Technologies (SpaceX) successfully launched their Falcon 1 launch vehicle on Sunday! Falcon 1 was designed completely from scratch with private funding and is the first privately-developed liquid-fuelled launch vehicle to reach orbit from the ground. I had the pleasure of meeting some of the SpaceX personnel on a trip out there in 2006 and you could feel the energy in the organization. I'm very glad to see them succeed and wish them the best for the future, which includes a NASA contract for resupply missions to the ISS and a possible manned mission to the ISS.

Video and such can be found here

So I see that Paul and Matt (the other Matt) have just jumped right into this blog with substantive posts about Astrogator and, uh, that, whatever that it is with Darth Vader. But shouldn't we start with some introductions?

Indeed. Since the other two didn't bother, allow me to introduce them. We'll get around to me later.

Read the rest of this entry »

A few times a year, someone will ask about using Astrogator maneuvers to model attitude thrusters.  Astrogator doesn't compute or integrate the torques based on these thrusters and doesn't have a mechanism for allowing the placement of off-center-of-mass thrusters.  That is, the GUI doesn't.  With the attitude and engine model plugin points a user can create a system which accounts for the torques and sends the integrated attitude to Astrogator.

Read the rest of this entry »

This question came in a while back.  Someone was targeting several parameters (start time, burn duration, azimuth and elevation of thrust direction) of a maneuver with a differential corrector. The DC, being the nice numerical root finder that it is, found the solution to the parameters to 16 places.  But, he has a spacecraft, with real engines and a real on-board system, and it can't perform maneuvers to 16 places.  He can only specify things to 2 or 3 places.  So the question is, after the DC finds the ideal solution, which way should he round the numbers?

What he would like to do after the DC finishes is run the sequence with every combination of rounding each number up or down, and see which combination works best.  Basically he needs to do a parameter search of all the possibilities to find the optimum.  He's got 4 parameters, each with two possibilities, so he's got 16 runs to do.

His question was how to get Astrogator to do this for him automatically when the DC finished, so he didn't have to look at the DC's solution and code up an external parameter search every time he ran a variation of the scenario.

The answer is to use a search plugin.

Search plugins, added in STK 8.1, provide a way for you to use your own search algorithms in place of, or in addition to, the differential corrector.  When the plugin is run (from the targeter), it gets an interface that lets it change the value of controls, run the target sequence, and see the values of results.  To write a plugin you have to implement three intefaces, one for the search algorithm itself, one for the control variables, and one for the result variables.  For each of these you can define attributes that can be set through Astrogator's user interface.

Read the rest of this entry »

For those of you who thought astrodynamics was confusing, see this.

Someone doing a HEO station-keeping mission called in the other day.  He has constraints on argument of periapse (aop) he has to stay between during the mission.  During the course of the mission he passes through critical inclination, which changes which way aop drifts.  So, he wants to do an inclination-change maneuver when he passes through critical inclination, so that at the end of the mission he's still in bounds.

He set up a stopping condition at critical inclination, and had it call an autosequence with a target sequence.  The target sequence contains a maneuver, followed by a propagate to the end of life.  He wants the targeter to control the maneuver so the end of life aop is at the bound.

His question was how to avoid doing the maneuver at all if the end of life aop  is within bounds already.  The differential corrector only knows about equality constraints, so it wants the aop to be exactly on the bound.  The DC doesn't care that you really have two bounds and want to set up an inequality constraint problem. (Though an optimizer, like the one in STK 9,  can do that).  So, we need to be a little tricky and give the DC something that does what we want, but behaves in a way the DC understands.

Inline calc objects to the rescue.

Inline calc objects are a somewhat unknown, but very powerful capability within Astrogator.  You can write a script that takes some calc object values and does some math on them, and returns that answer back to the differential corrector.  For instance you can use it to subtract the value of two different calc objects.  In the case here, we want something that will  return zero if argument of periapse is within bounds, and returns the difference between aop and the nearest bound if aop is outside of the bounds.  This way, we can have the DC make this calc object go to zero, and it won't do anything at all if we are already within bounds.  If we start outside of bounds, the DC will drive you to the nearest bound.

Read the rest of this entry »