Spacecraft Trajectories and Dynamics

[selden]

Celestia's "CustomOrbit" uses what is known as the "VSOP87 theory".

The orbit of each planet is described by a Chebyshev polynomial accurate to better than one arc second (as seen from the Earth) from about 1000 BC to 3000 AD.

Ref:

Bretagnon P., Francou G., : 1988, Astron. Astrophys., 202, 309.

A Web search will locate more details.

[Apollonian]

Sirius -

It sounds like we are on a similar track. I had implemented a straight forward fourth-order Runge-Kutta, but I unfortunately had to stop prior to implementing the variable timestep simulation. Debugging can be something of a drag when I cannot accurately measure the time it takes to get a code working (amidst many other deadlines).

By "multi-step" methods, do you mean by using Finite Difference? ie - approximations based upon Taylor series expansion of the diff-eq around the target time? I think that the Runge-Kutta method already encompasses the benefits of that sort of method (if not more accurate).

I am currently learning some of the finer points of C++ and will soon understand much better how to read and compile the Celestia source. You mentioned "celengine" - can you point me to what files in specific you are looking at? Would it be possible for me to collaborate with you on your code? I don't know how much I can offer - but I am at least trained in numerical methods and orbital mechanics, the rest is a bit of extra study away.

I am considering at this point that perturbations of spacecraft trajectories should mainly focus on the 8 or 9 major planetary bodies and perhaps solar radiation (which can be modelled with the distance from the sun and reflectivity of the spacecraft - I learned the dynamics for solar sails last fall if you need some equations).

Selden -

I recognize that sampling planetary positions at any given time may slow down the code. However, is there some fundamental structure which disallows a spacecraft to react at runtime to planet positions? Or is it that you are simply referring to the difficulty of the n-body problem and the pursuit of accuracy?

Given that there will be no reverse perturbation from the spacecraft on any other body in the simulation (unless specified in the .ssc?) - is it possible to sample the planetary positions from the VSOP87 without seriously compromizing the runtime performance in some fundamental way (assuming enough CPU/RAM etc)?

I think that the fundamental problem in this implementation will not be the physics, but rather the computational burden. There has to be some way to decrease the number of samples and still interpolate effectively. I heard at least one paper mention the use of the Finite Element method, but I have no idea how that would be implemented...maybe I'll have a better idea in a year or so when I become more familiar.

Also:
Does anyone know if it is possible to use Celestia scripting (or otherwise) to retrieve input from the user in any way?

[selden]

You might want to take a look at "Mostly Harmless". Its author modified Celestia to implement gravitational effects on the observer in its earlier versions, although the most recent one doesn't include that code.

I'm just trying to remind you that Celestia must be able to generate an image when it's only been provided a time. E.g. when someone updates the simulation's Epoch using the Time menu item. That time is going to be arbritary. You can't assume that it follows, preceeds, or is close to the time of the image that it just finished generating.

[Toti]

You might be interested in this Celestia script (WIP), which also uses the classical 4th order Runge-Kutta ODE solver to simulate gravity effects acting on the observer. It's ready to be extended to include drag, etc.

http://celestiamotherlode.net/catalog/show_addon_details.php?addon_id=691

Bye

[Apollonian]

Selden -

You make a good point. Due to this issue, I was thinking more along the lines of a parallel program/script which would take a certain amount of time to make all the necessary propagations to account for the xyz coordinates of the spacecraft through its mission lifetime.

So, the idea would be to have an xyz orbit generated so that there is no effect on the Celestia GUI runtime performance. The only catch is that the user may need to wait for the generation to finish and/or run a separate program prior to the Celestia GUI.

[Falck]

Is there any way trajectory data can be piped into Celestia, perhaps as standard input or via sockets? As the user of a lot of older trajectory optimization programs, having the ability to display a trajectory real-time in Celestia would be a big plus. This would let the user use whatever trajectory tool he or she chooses, and would keep the computational intensity away from Celestia.

[selden]

Celestia requires that all objects and their trajectories be predefined. It only loads them once, at startup.

Sorry.

Maybe some future version will allow reloading of object definitions at runtime.

[chris]

My feeling on this is that external programs rather than Celestia itself should handle the calculation of trajectories by integration over time. These programs can generate .xyz files for use in Celestia. Selden already brought up the main reason for this: Celestia needs to be able to very quickly render a view at any time. Random access in time is one of the fundamental design decisions I made in Celestia. Without it, users couldn't arbitrarily set the time or time rate without worrying about huge inaccuracies in objects positions or else a massive slowdown from huge amounts of computation.

There are a number of existing programs that will calculate trajectories given an initial position and velocity; I think HORIZONS will do this for you. I don't know of anything that outputs data in Celestia's xyz format, but the conversion is usually straigtforward.

There are a couple things that I want to do in Celestia to make it easier to create custom trajectories. Reloading objects while Celestia is running is one of them. Another useful feature would be looping .xyz files.

--Chris

[Falck]

There are a couple things that I want to do in Celestia to make it easier to create custom trajectories. Reloading objects while Celestia is running is one of them.

--Chris

Thank you, Chris. I look forward to the day this capability is in.

[Sirius]

Apollonian:
The Multi-step methods I use are said taylor expansions, the higher-order terms are approximated by interpolation of multiple previous approximations (in my case three previous values). In contrast, Runge-Kutta uses only the last value; so in the multi-step method I first use Runge-Kutta for three steps and then switch over to the real multistep-method.

The "celengine" is the part of celestia that does practically everything except the user interface. OpenGL Drawing, orbit calculations and so on. It's in the '/src/celengine' directory; there I added a derived (from CachedOrbit) class named DynamicOrbit. (Also added some parsing to allow specification in ssc files)

I have a quite severe bug in there (just noticed) so I'm not posting the source in public today (perhaps on monday)

One interesting book for that type of numerical integration is the book of Hairer, Lubich and Wanner: Geometric Numerical Integration; they also describe adative timestepping while retaining "good behaviour" (i.e. energy conservation) of methods. Unfortunately I've not yet written the nonlinear equation solver, so I'm stuck with the explicit methos (this will change).

My current approach (for the most part) is to have a fixed step size (ie. 1 hour) and interpolate between these points when the speed is slower. This ensures results independent from the frame rate and makes extending to controlled dynamic step-size methods easier.

At the moment, though, none of the algorithms qualifies for more than virtual reality; also this numerical approach will _never_ be used in main celestia because jumping in time takes a -long- time (processor time). Also the speed is - depending on the step-size - not arbitrarily adjustable.

My main use of this is numerical experiments and demonstration, not serious development of something.

If someone has too much time: As of now there are no "Mass" statements in SSC files although they are read (and not used) by standard celestia.
It would be very helpful, for me and also for future expansions, to include the mass of every object in Celestia (where it is known).
Thanks

Sirius

[Apollonian]

So, hello again. It has been a while since I posted here, primarily due to senior design and the whole process of transitioning.

I am currently involved in an internship, but lo and behold! I get to work on a wonderful open source project (under a NASA contract) called the Java Astrodynamics Toolkit

http://jat.sourceforge.net

I am not listed yet since we haven't uploaded the updated code yet. We are conducting verification of the propagation algorithms this summer against AGI's Satellite Toolkit (STK). So far, things look quite promising!

So for all of the people who were interested in simulating gravity and/or developing spacecraft trajectories for Celestia, here is a really great answer. In fact, as I hear, some of my colleagues are looking into using Celestia as a (professional) visualization tool. The only trouble is that there is no really great way to display a propagation in real-time (feeding updated values into Celestia while it is running). If anyone has any ideas that would be awesome.

So anyway, hopefully at some point I will be able to come back with a package of Java code that people can use to easily generate XYZ & SSC files for a spacecraft orbit of their own design. I have already been using Celestia for debugging purposes and there is little trouble formatting the files for Celestia. Once again, great work my fellows!

Since I haven't heard from anyone in a while, is there still some interest in this and does anyone else have any requests regarding spacecraft orbits?

[lukr]

It's great work! If you can make it easy to use, I'm sure a lot of people will be interested to create their own fly-bys, including me.

[selden]

Yup.

Some of my half-finished projects aren't getting finished because of the pain of producing realistic orbital paths.

[Apollonian]

Hmmm, yeah, flyby's. I'd almost forgotten about those. Hmmm, I will make note of that and suggest it. It may be a little longer before it will be easy to set up those without just eyeballing it.

However, I am working on making it easier to use. Essentially, the goal will be to create one interface class which will create/toggle the various force models and input parameters for the simulation and then integrate accordingly.

As of right now, we are getting pretty good results using an 8th order Runge Kutta and integrating the state (which makes creating XYZ files simpler). We also have the ability to parse the JPL DE405 ephemerides to get planetary positions.

Right now sourceforge indicates "pre-alpha" meaning that a lot of the code that is available right now is not verified. I will make a post as soon as we are able to put up the alpha and/or beta version with the verified code.

Until then, I would still appreciate any more requests/suggestions.

[lukr]

Sorry, half of what you said is gobbledygook to me! So, I can't make any sensible suggestions.

Just curious as to what the input parameters would be. Weight of the spacecraft, velocity, direction,...? And then output would be a XYZ trajectory is that right?

[Apollonian]

Sorry, half of what you said is gobbledygook to me! So, I can't make any sensible suggestions.

Just curious as to what the input parameters would be. Weight of the spacecraft, velocity, direction,...? And then output would be a XYZ trajectory is that right?

Exactly. You would choose what kinds of force models you want. In other words: Do you want to model gravity for all the major planets? Solar Radiation Pressure? Atmospheric Drag? etc Then, you need to input the relevant stuff like spacecraft mass (for gravity), reflectivity (for solar radiation), drag coefficient and cross sectional area (for drag). Finally, you would input the initial position and velocity of the spacecraft and for how long you want to plot ('propagate') the trajectory. The program will then integrate the physics and generate the trajectory.

We are also hoping to allow propulsion maneuvers so you can fire rockets or electric motors (ion drives) to change orbits.

I am developing a class that will then take the output from this program and generate the necessary SSC and XYZ files for Celestia.

With regard to flybys and other fancy maneuvers you hear about from the Jet Propulsion Laboratory (NASA/CalTech), there is a whole lot more involved. This requires trajectory optimization and other calculations to ensure the spacecraft arives at the right point at the right time at the right speed. Eventually, I hope that these will be easy to set up as well.

[jestr]

Wow-that sounds awesome mate,good work,Jestr

[lukr]

Indeed. indeed !

[Apollonian]

I was browsing through the old forum topics looking for some information and stumbled accross a thread on spacecraft rotation in celestia.

Attitude Dynamics - Spacecraft rotation

How difficult would it be to implement attitude representation in Celestia? In other words, if a file could be created storing a Quaternion (4-vector) state instead of an XYZ (3-vector) state, is there a simple way to determine the orientation of the model? I understand that Quaternions are often used in visualization, are they being used already?

Having just recently finished a course in Attitude Dynamics and Control, I might be able to provide the physics/dynamics/rotational-mathematics in order to implement this, if someone would be willing to help me out with the actual implementation into Celestia.

Questions on Celestia conventions

- Are XYZ trajectories circling Earth in the J2000 Earth Centered Inertial frame? I though this was the case, but it came up today and I wanted to ask explicitly.

- Are heliocentric coordinates J2000 as well?

- Do XYZ trajectories around other planets use the First-Point-In-Ares reference (same as Earth) for the X direction with Z around the rotation axis?

Realtime Simulation - "nearly" impossible?

Some of my coworkers have asked several times about the real-time capabilities of Celestia. I relayed the fact that it is nearly impossible to implement in Celestia. However, these are serious (professional) programmers, and I am wondering whether or not "nearly impossible" is just possible enough for them.

Can someone speak to how Celestia handles memory and whether or not it might be possible to hack the visualization to update in real time. Chances are, this update will not be through a file but rather some kind of client-server middleware piping it directly in.

[Apollonian]

Since this seems to be a popular enough thread, I added a news section in the original post.