Project Mission Simulation Tool Development

[Arrowstar]

A week or two ago I mentioned in the Trajectory Optimization Tool thread that I was looking at creating a simulation tool "add-on" for the TOT. Well, I've been working on it now for a bit and it's managed to turn itself into its own project (again! How does that happen?). It's really gotten to the point where I think I can share with the community and start to judge interest in the project.

Thus, I present the Mission Simulation Tool:

The purpose and goal of the Mission Simulation Tool is to provide for a way to determine the trajectory of a spacecraft in a multi-body system. It does that by integrating the equations of motion directly and providing the state of the vessel at the start and end of a series of maneuvers, as well as a 3D view of the trajectory. Maneuvers make up a sequence that defines a 'mission'.

A good chuck of the inspiration of this tool comes from STK/Astrogator, and I'd like to get the base feature set to at least match the basic features of Astrogator. I won't be able to do everything STK can do, not by far, but I think I can manage the useful bits.

Current Features
-Uses a 4th order RK method to numerically integrate EoMs.
-Currently supports a user defined initial state relative to any body with loaded data, impulsive DeltaV maneuvers, and custom propagation of the spacecraft.
-"Propagators" can custom defined that determine which bodies are used in the gravity model.
-Propagation of the spacecraft's position can be stopped after a certain event occurs, such as an elapsed time, periapsis, apoapsis, etc.
-Impulsive maneuvers can defined relative to the prograde direction, retrograde direction, any XYZ vector, or a VCN vector.
-Many coordinate system options to choose from, including J2000 and FK4.
-Emphemersis data comes from JPL's Horizons system, as with the TOT.

Features Under Development
-Finite duration burn maneuvers.

Features Under Consideration
-Atmospheric drag modeling (custom atmospheric models would likely be part of this).
-Targeting of a particular orbit and/or celestial body. Output from this would be a DeltaV maneuver that gets implemented in the simulation on the fly.

That's about it for now. I really don't have any pretty pictures to show, because the work isn't really at that stage.

So, does any of this sound useful? I'm posting my progress here partially as a statement, but partially to see if there's any interest in something like this. All comments welcome, as usual. :tiphat:

EDIT
Added some more screenshots:

 

[Wishbone]

It is just my personal opinion, but yes, that would be useful since babysitting Orbiter sessions is quite tedious.
I suppose the tool employs right-handed frames (wink-wink), doesn't it?
What is the format of input (mission sequence) files? (interested in reading it from an MFD in Orbiter, with hopefully left- and right-handedness mess sorted by the MFD)

If you decide to do atmospheric drag (am I right in guessing the Martian inspiration for that feature?), what would be the interface with vessel params available from Orbiter? What attitude would be assumed by the model?

The most enticing feature is of course the targeting (given a sequence, what is the maneuver that gets us to the target - correct?).

The event notification is quite nice, and of particular importance for PeA going to non-positive numbers _along the way_ Also hope that the targeting optimization algorithm will use constrained optimization (PeA>PeA_safe, for instance), since there is almost no point in continuing with a flight after a high-speed crash into Deimos.

 

[Grover]

Also ApA<ApA_safe. You cant orbit the moon at 3M because of gravity field perbutations

 

[Arrowstar]

It is just my personal opinion, but yes, that would be useful since babysitting Orbiter sessions is quite tedious.
I suppose the tool employs right-handed frames (wink-wink), doesn't it?
What is the format of input (mission sequence) files? (interested in reading it from an MFD in Orbiter, with hopefully left- and right-handedness mess sorted by the MFD)

If you decide to do atmospheric drag (am I right in guessing the Martian inspiration for that feature?), what would be the interface with vessel params available from Orbiter? What attitude would be assumed by the model?

The most enticing feature is of course the targeting (given a sequence, what is the maneuver that gets us to the target - correct?).

The event notification is quite nice, and of particular importance for PeA going to non-positive numbers _along the way_ Also hope that the targeting optimization algorithm will use constrained optimization (PeA>PeA_safe, for instance), since there is almost no point in continuing with a flight after a high-speed crash into Deimos.

Right-hand rule is pretty much the norm in every mathematics, physics, and engineering course I've ever taken. I understand that left-hand rule has its uses in particular industries, but it would take a lot for me to unlearn the habits I've developed around RHR. So, in short, yes.

The file format for the mission sequences is .MAT, which is the way MATLAB natively stores data to disk. This is another MATLAB-based application, as with TOT. I'm not sure you could use an MFD to read in the computed data, but I suppose I could have a TransX mission output or some such thing... maybe. I've never looked into that before. Keep in mind that data is only generated when you want it to be, not continually.

Mars is one of the inspirations for the atmospheric models, yeah. I've never used the Orbiter API, so I'm not sure what vessel parameters are even available. I was planning on just having the user specify "average" frontal surface area (that is, the frontal area you'd compute if you integrated (read: averaged) the drag force over one orbit). I could add in a rigid-body component to compute frontal area at each time step, but that would be far down the road. Can you give me examples of what vessel parameters you were thinking about?

Your guess about targeting is correct. The idea is to say "I want this orbit" or "I want to end up at this body" and for the code to give you what the impulsive DeltaV required to do that is. That'll be a constrained optimization problem, with the user specifying a target orbit and the code returning (and implementing in the sequence) the impulsive maneuver. And yes, I would assume that "crash checking" will be an important part of that optimization problem.

 

[Wishbone]

I'm looking into .MAT format, it is surely versatile, yet human-readability is an important part of mission tweaking, and future Matlab versions can break back- and forward compatibility.

TransX or IMFD interop would be great; actually I think your app would obviate TransX. In any case, there is some need in interaction with Orbiter either through a human operator or through some MFD.

Re: drag. Other than simple cases of capsules reentering without skips or doing upper-atmo aerobraking, either AoA or bank or both are changing constantly. I know the area, Cd and Cl and hence forces for each combination of AoA, Mach and Reynolds for given AoA and bank (the coefficients get extracted from the vessel), but would not like to open this can of worms (open-loop vs. closed-loop control during atmospheric maneuvers). Think you can always leave flexibility in the design to plug in more stuff later.

 

[Arrowstar]

I've got a bit of a problem I'm hoping someone might be able to offer some insight into. Allow me to explain.

There is an aspect of the Tool that allows you to select which body you consider the "central body" of the flight plan. All it essentially is used for is fixing your coordinate system to a point in space (gravitation is handled separately, the central body doesn't have to be a gravitating body). Here's what happens when I view an Earth orbit with the Central Body as 'Earth':

As you can see, I get a nice circle, which is (near-) perfect for the 0 eccentricity, 0 inclination orbit I'm modeling.

Now, let's see what happens when I view that same orbit with the Central Body set as the Sun, and then I shift the coordinate system center back to the Earth:

As we can see, no longer a nice circle. If you run the simulation for longer (say a full day of integrating the equations of motion), you'll find that the shift we see on the top and bottom of the image (where it appears the circle has been stretched) get farther and farther out from the center. For example:

After a significant amount of investigating, I can tell the cause is not numerical (my integrator is not causing it), and that the cause is not due to step size in that integrator. Adjusting the tolerances of the integrator have no effect, which tells me that there's got to be something else going on here. I just can't see what. Anyone ever seen anything like that?