Celestia Forums

I have noticed that at least a handful of people are interested in things like modeling gravity in free-flight and having an easier method of generating new spacecraft trajectories. I am interested in working on some of this. However, I have to admit that I will need to become familiar with at least some of the Celestia source, meaning that I may not get to coding anything for some time (if ever - alas for other obligations).

With that said, how many people would be interested in a standalone application (perhaps using a small subset of the Celestia source) which generates .ssc and .xyz files for new spacecraft given some nominal parameters?

For example:
- Given a spacecraft's initial position in Heliocentric or Geocentric coordinates, the time of flight, and its destination...
- Output the .ssc and .xyz files with the spacecraft orbit, including gravitational effects from major planetary bodies between the original position and destination.

[edit 10-16-06]
Issues
One of the major concerns right now is correlating the planetary positions between Celestia's VSOP theory and the JPL DE405 ephemerides, as well as the conversion between ecliptical vs equatorial coordinates. Without getting these right, spacecraft on interplanetary trajectories will appear to 'miss' their targets in Celestia.

** NEWS - August 2005 **

I am now working on the Java Astrodynamics Toolkit, which looks to be an incredibly promising tool to generate highly accurate spacecraft trajectories for Celestia. In most cases, we are getting at most a few meters of error against AGI's Satellite Toolkit (STK) propagating Earth orbits for periods of several days.

The Java Astrodynamics Toolkit along with a number of Matlab codes look to be released under the NASA Open Source Agreement. See page 3 for details...

** NEWS - January 2006 **

JAT has now moved its source to Sourceforge:

https://sourceforge.net/projects/jat

Since Sourceforge finally moved to SVN, the source can now be downloaded from the sourceforge project page.

Work continues on developing generalized user-friendly simulations, results pending. Look in the "jat.demo.simulation" for the user friendly versions.

** NEWS - March 2006 **

Work continues. JAT has now become my thesis topic for my Masters, so significant practical results should be pending within the next year. Please stay tuned!

** NEWS - August 2006 **

Presented paper on JAT propagator validation at the AIAA/AAS Astrodynamics Specialist conference.

The JAT developers have decided to do some redesign in hopes of making JAT easier to use. However, this will take some more time and work. If you would like more information on how to use the latest release of JAT or have interest in plotting interplanetary trajectories, you can email me at:
rcpage3@users.sourceforge.net

Apollonian,

That sounds like a great idea!

Horizons provides an equivalent service for spacecraft within the solar system, but its user interface isn't very friendly to novices and it can't work at all for imaginary systems.

You might want to discuss your ideas with the author of Gravity Simulator. Maybe you can combine your efforts.

http://www.gravitysimulator.com

Is gravity simulator affiliated with Celestia? I am guessing no.

It also looks as if gravitysimulator is not an open source project and I can't seem to read their forums easily with Firefox. I imagine, however, that I will be able to model these effects just as easily as they did having very recently taken the corresponding coursework at University.

Another point to note - if I am thinking correctly, this gravitysimulator program is a numerical simulation whereas I am planning a much more analytically derived formulation using orbital mechanics. The idea is to approximate the motion of the spacecraft using the "patched conic approximation" - essentially a succession of elliptical orbits defined by the "sphere of influence" of the nearest significant body (defaulting to the sun).

This program is in conjunction with some of my own projects that require greater accuracies than a rudimentary numerical simulation will provide. For trajectories near large bodies (with a small spacecraft - sorry death-star fans) analytical orbital mechanics does the trick. Navigating an asteroid field, however, would take some heavy numerics.

Does anyone else have any other ideas along these lines as to what we might do with spacecraft trajectories? ie - different parameters for input into the code.

Eventually it would be nice to be able to handle planetary flyby's but I am unsure as to how one might conceptualize this in time with respect to user input. For now, it looks like the user would have to plan things out manually ahead of time (where the target planet will be at the end of the planet-planet_flyby transfer).

I'm not familiar with Celestia internals, but I suppose a standalone simulator would be easier to implement than adding that functionality to Celestia itself. For spacecraft trajectories, you may want to try out a whole range of initial velocities and maneuvers to find one leading to your intended target, something you can't easily do interactively. When you have found a successful trajectory, transfer it to Celestia as an XYZ file.

As long as the spacecraft (or any other body you want to find a trajectory for) is small enough not to substantially affect the motion of other bodies, navigating an asteroid belt shouldn't be considerably more difficult than performing a flyby of Jupiter; it will just consume more CPU time. However, you may not know the true orbits of all those asteroids, as they may be affected by the major planets or by each other.

You have to watch out for body collisions, including merely passing through the upper atmosphere of a planet, since such events will affect the trajectory substantially. For instance, according to the Cassini XYZ data delivered with Celestia 1.3.2, Cassini will perform a "subsurface flyby" of Dione on October 11 this year, and survive without a scratch! I guess the Cassini data isn't entirely accurate, but it illustrates that Celestia doesn't simulate the effects of an impact.

By the way, has anybody obtained a more recent and accurate XYZ file for Cassini? I would prefer one that is centered around Saturn rather than the Sun, since the current solar "spacecraft orbit" of Cassini doesn't relate very well to the saturnian moons...

You could try this one Andersa,
http://celestiamotherlode.net/creators/jestr/Cassini_Huygens_Landed_CMOD.zip
its still Solar-centric,but I think it is more accurate than the standard XYZ for Cassini,Most of the errors are due to inaccuracies in the moon orbits though I think,Jestr

Thanks, that XYZ file offers five times as many positions, and with much better precision. I hope that precision translates into better accuracy as well. At least Cassini doesn't collide with Dione on October 11 now, but it still descends to around 14 km above the surface (instead of 47 km below it) which I assume is much too low anyway, so I guess you are right about Dione not being exactly where it should be. Could this be fixed by obtaining more accurate orbital elements for Dione, or does it require a new custom orbit?

Also, while following Cassini I tried tracking Huygens (free flight), but it started jumping wildly all over the place soon after separation. I guess this is due to lack of correlation between the XYZ plots for the two crafts, as Celestia tries to interpolate between the tabulated positions. What are your sources for the trajectories; NASA's ephemeris database or something else? I understand the Huygens trajectory is partly guesswork, but what real data did you base it on?

As explained by JPL on their website, Cassini was placed on collision course with Titan before separation, then employed its engine to maneuver away from Huygens a few days later. Since Huygens has no engine of its own, it should be possible to derive most of its trajectory from the ephemeris of Cassini, but I'm not familiar with the formulae for actually doing it...

Anders,I used the Horizons Telnet service to get the xyz data for Cassini,and hoped that by taking minute samples around the time of each planned moon flyby it would position Cassini more accirately for these.However,when I tested it out it didnt really matter much how often I sampled (even 1min steps) as for many of the Titan flybys especially the probe just flew straight through Titan.So I guess the orbits for the moons are a little out.In the end I changed the xyz (using Toti's XYZ Builder script) where the orbit took it through a moon,but I left it unchanged if it didnt.It may be possible to correct the xyz further using Toti's script so that the distances at flyby are more accurate but as I found trying to do this for Huygens you can also bump into the limits of xyz accuracy (or floating-point precision?).I tried many ways to make Huygens more accurate on its descent to the surface (including writing an xyz file by hand)and at certain stages the x,y or z value is rounded up by Celestia so it is not possible to put it in exactly the position required.In the end I just settled for as smooth a ride as possible.Though if anyone else comes up with a more accurate xyz file I would of course welcome this.
Of course you can always use the Telnet service to make your own sampled XYZ orbits for the moons of Saturn,but it is only practicle over short periods of time.Jestr

I too encountered problems with the trajectory of Huygens and Cassini using the xyz files in Jestr's add-on. Their accuracy is good but not perfect. It does seem to be a rounding problem.

I was able to remove the jumping around by deleting those 5 minute xyz data points that caused the jumping (only some of them do). It has not changed the overall course of the spacecraft, simply removed some of the jumpiness.

I have also been able to smooth out Huygens descent. When closing on Titan, it too began to jump around, in some spots even rising away from the moon instead of continuing to fall. I was able to isolate and remove those jumpy spots from the Huygens xyz file.

Lastly, I edited the Cassini ssc file for the Huygens add-on to allow the parachutes to open at the right altitude from the surface. The 5 minute horizon plots were fine, but Titan was not in the right place for those plots. It was about 3000 km farther away from Huygens' xyz position than it should be. As a result, Huygens parachutes opened over 3,000 km above Titan. I fixed that also by changing the model mesh display times so that the parachutes open at the right altitude, although the times of drifting down are now shortened (not 2 1/2 hours).

I've forwarded the corrected xyz file and ssc file to Jestr. I don't know if he intends to use them or not in a corrected add-on. If anyone wants the two files in the imterim, just e-mail me.

Frank

fsgregs wrote:I was able to remove the jumping around by deleting those 5 minute xyz data points that caused the jumping (only some of them do). It has not changed the overall course of the spacecraft, simply removed some of the jumpiness.

Either a rounding problem, or an artifact of the interpolation performed by Celestia. Does anyone know what algorithm is used for the interpolation? A cubic spline or something?

If you show the spacecraft trajectory ("orbit"), you'll find that it's even rougher than the motion of the spacecraft itself, with straight lines interconnecting the known positions. This makes the orbits essentially useless when zooming in on small portions of space.

fsgregs wrote:Lastly, I edited the Cassini ssc file for the Huygens add-on to allow the parachutes to open at the right altitude from the surface. The 5 minute horizon plots were fine, but Titan was not in the right place for those plots. It was about 3000 km farther away from Huygens' xyz position than it should be.

I think it would be easier if Huygen's descent phase could be defined using Titan rather than Sol for the origin. Is it possible to define a body that changes from one origin to another in mid-flight, while allowing uninterrupted tracking by Celestia? If so, Cassini's origin should preferrably be changed from Sol to Saturn in June 2004, and Huygen's origin from Cassini to Saturn at separation time. Idea for future Celestia improvements?

It isnt possible to change origins mid-flight,it would of course be possible to change objects but then you have the problem of matching the new Titan-centric Huygens up with the previous solar-centric Huygens,I tried this making an xyz by hand for the whole of Huygens descent,but still came across the rounding error and there didnt seem to be any way to get Huygens in the same position as Cassini when it detaches.If any one else wants to have a go ,let me know how you get on.
Jestr

The trouble with modelling spacecraft trajectories in a scenario like this is that there are so many factors that JPL takes into account that it would be impossible to duplicate here. The orbits of both the spacecraft and small moons (of which I suspect Celestia only has keplerian orbits) are all subject to complex effects of perturbation, libration, nutation, etc

The idea is to get an approximate idea of the effects of major planetary bodies on spacecraft moving through the solar system. However, I now admit that actually implementing the perturbation theory is quite a bit more difficult that looking at it in theory. I am having difficulty keeping my numerical simulation stable, and I'm at a loss as to how I might verify the code.

Conducting Interplanetary Correction Maneuvers is the simple part. Modelling flybies should be simple (it's a two-body, patched-conic problem rather than an n-body perturbation problem). Yet, the greatest challenge, as discussed here is telling whether the orbits in Celestia actually correspond to reality at all (given a certain accuracy) - otherwise, Celestia is a very flashy toy without much technical interest.

If anyone has any resources, links, etc regarding numerical implementations of third-body perturbations, please please please let me know. I am having some difficulties fussing with it on my own.

My primary concerns are: step-size/time-scaling, round-off error, and algorithm stability.

Have you read "Fundamentals of Astrodynamics and Applications" by D. Vallado?

Its table of contents (but not the book itself) is available on the Web at
http://www.understandingspace.com/FAA/faa_toc.pdf

I have implemented a small addition, a dynamic Orbit class that simply causes an Object to be influenced by gravitation.
There is a provision for a Mass field in the scc files, but nobody seems to use it (at least for the planets), so I have to add that manually.
When I have it working better, i'll post it here as a patch file for celengine (and perhaps a zip for the windows users).
THe next target will be a controller interface for that.

Greetings Sirius

selden wrote:Have you read "Fundamentals of Astrodynamics and Applications" by D. Vallado?

Its table of contents (but not the book itself) is available on the Web at
http://www.understandingspace.com/FAA/faa_toc.pdf

Oh yes, Vallado is my primary source. So far my efforts to implement higher order propagation codes have been unsuccessful and been put on the back burner for the sake of other unrelated deadlines.

Sirius wrote:I have implemented a small addition, a dynamic Orbit class that simply causes an Object to be influenced by gravitation.

Really??? That's interesting. What is the basis for the implementation? Does it basically integrate position based on kinematics subject to the sum of gravitational effects?

The question in my mind is one of numerical accuracy. It's one thing to have an object move around in relation to gravitation, but that doesn't mean that the motion corresponds to real dynamical response.

I've peeked through the source, but I haven't gotten around to giving it a thorough look and building it on my machine.

At the moment it is based on a dynamic-step classical Runge-Kutta method (to scale), but I'm actively chasing for a certain book on energy-preserving Algorithms for ODE's, I'll get that propably on monday. I also had a look on some course material on multi-step methods (?), i.e. using the last three or four positions to improve the accuracy.

In the Source the additional Orbit is just a derived class from CachingOrbit, it can be initialized in the SSC-File as usual, with starting position and speed.

The Celestia source is IMHO very readable, I have unitl now only concentrated on the "celengine" part. (The source I use is 1.3.2)

Unfortunately there are no mass values in the default SSC files, although the complete source infrastructure is there, you just have to type them in manually (admittedly a minor factor).

The next step would be to try to add some effects like
- air friction
- collisions
- solar wind (for bodys marked specially, we did do the math in a physics exercise last year, so I just have to copy this...)
- magnetic fields (?)

Also a "trail" could be added to the orbit...

Suggestions appreciated!

Greetings, Sirius

Greetings,

Some time ago (actually in the 1970s), I wrote a FORTRAN code that does a 13th order numerical integration using Cowell's method. This was able to integrate the 9 planets and 4 main asteroids. My program uses some parameters from JPLs DE96 and gave results that matched it pretty well. This uses a 1 day time step. I'm unsure how easy it would be to make the time step more dynamically adjustable as it might need to be for a spacecraft mission. Just some food for thought however. It would also need to be modernized for today's more accurate parameters. You can see more in my article in Sky and Telescope about mutual planetary occultations (March 1979).

The orbital calculations within Celestia do not / must not depend on the positions of other bodies. Those factors must be precalculated, so that the formulas that Celestia uses only need to be given the current time in order to calculate the positions of objects.

So long as your trajectory formulas meet that condition, then they'll be usable.

I suppose in its current form I do need to calculate all the planets simultaneously. Does Celestia presently use a simple elliptical orbit for the planets (e.g. Saturn)? If so, perhaps at least updating the osculating elements every few days or something would be an improvement (i.e. patched conics)? These elements can be calculated from a table of position and velocity vectors. That is something I may be able to adapt my software to calculate if it isn't readily available from other sources.I have yet to look at the Celestia source code to know what I'm talking about - I'm simply judging from the solarsys.ssc file.