Spacecraft Trajectories and Dynamics

The place to discuss creating, porting and modifying Celestia's source code.
Toti
Developer
Posts: 338
Joined: 10.02.2004
With us: 20 years 9 months

Post #41by Toti » 12.08.2005, 00:21

Apollonian wrote: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?

Celestia does use quaternions for rotations: they are converted into matrices as the last step.
I also had the idea of expanding the XYZ file to hold both position and attitude of the spacecraft.
It doesn't look too complex: Celestia code also includes quaternion interpolation functions so a file consisting of quaternion samples could be easily processed for smooth output.

maxim
Posts: 1036
Joined: 13.11.2003
With us: 21 years
Location: N?rnberg, Germany

Post #42by maxim » 12.08.2005, 10:56

Apollonian wrote: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.

If things could be done only in realtime in celestia there wouldn't be any (serious) problem. But fact is that celestia requires time to be the only free variable of the simulation. Otherwise you couldn't speed up or slow down the simulation to an arbitrary level, and you couldn't jump back and forth in time at free will. The area of application you indent to follow implies that you keep sticked to continuous real time, which is only a special case inside celestia.

The software design approach that I can see and would suggest, is about the following:

- Plan and define a special user mode that you may call 'continuous' or something like that. Maybe you need to introduce some new classes for that, maybe just a switch variable and some mode constants.
- From GUI view that would look like that: An new menu option or key switch to toggle between 'normal' mode and 'continuous' mode. When in 'continuous' mode, the time settings are disabled same for GUI access as for script commands. The time acceleration has to be limited to whatever your path generation algorithms are able to deliver.

This way a user can't break the simulation by jumping in time or accelerating time to much. And he is aware that he can't, because he works in a special mode. Then it doesn't matter if you pipe the path positions into the simulation, or if you create them straight inside Celestia, in an own (threaded?) function.

If your co-workers ar software development pros, they will understand what I've meant above. And they will know that implementation will require quite some prerequisite work.

maxim

Topic author
Apollonian
Posts: 52
Joined: 19.10.2004
With us: 20 years 1 month

Post #43by Apollonian » 12.08.2005, 11:56

Toti wrote:Celestia does use quaternions for rotations: they are converted into matrices as the last step.
I also had the idea of expanding the XYZ file to hold both position and attitude of the spacecraft.
It doesn't look too complex: Celestia code also includes quaternion interpolation functions so a file consisting of quaternion samples could be easily processed for smooth output.


That's what I figured. Have you looked at what reference frame the quaternions represent? Essentially is there a model-system to inertial-system correspondence? If this is the case, then it should be hard at all to generate attitude with the propagation code I'm helping to develop.

Maxim-

That's essentially what I gathered from before, but thanks for the jumpstart on implementation. I think that is pretty much what they had in mind: to just create a real-time only Celestia mode.

Topic author
Apollonian
Posts: 52
Joined: 19.10.2004
With us: 20 years 1 month

Post #44by Apollonian » 12.08.2005, 11:56

Toti wrote:Celestia does use quaternions for rotations: they are converted into matrices as the last step.
I also had the idea of expanding the XYZ file to hold both position and attitude of the spacecraft.
It doesn't look too complex: Celestia code also includes quaternion interpolation functions so a file consisting of quaternion samples could be easily processed for smooth output.


That's what I figured. Have you looked at what reference frame the quaternions represent? Essentially is there a model-system to inertial-system correspondence? If this is the case, then it should be hard at all to generate attitude with the propagation code I'm helping to develop.

Maxim-

That's essentially what I gathered from before, but thanks for the jumpstart on implementation. I think that is pretty much what they had in mind: to just create a real-time only Celestia mode.

erwos
Posts: 4
Joined: 12.08.2005
With us: 19 years 3 months
Location: MD

Post #45by erwos » 12.08.2005, 13:15

maxim wrote:If your co-workers ar software development pros, they will understand what I've meant above. And they will know that implementation will require quite some prerequisite work.


I have the extreme misfotune of being one of Appolonian's "software development pro" co-workers. (just kidding, Richard) There is a great deal of interest where we are at NASA about using Celestia as a visualizer for real-time space sims - it's pretty, and it's already written :).

Warning: I have not gone source hacking yet, so the following is based on hearsay and rumor of how Celestia works! Even worse, I am not an astronomer or AE, so my knowledge of the entire subject matter is rather spotty, to say the least. I have written a visualizer before, so at least that much of this is not beyond my ken (mostly).

Anyways, from what I gather of this discussion, making Celestia "real-time capable" is going to require a few steps:
1. Creating a "real-time" mode that locks the time-slider into "normal speed".
2. Figuring out how to tell Celestia to not read a trajectory from a file loaded into memory, but rather from a class (interface?) of my own defining - this could be memory, middleware, or whatever,
3. Some method of choosing between file input and network input, and then configuring the network or file input appropriately.

The first should be reasonably easy, and I don't worry much about it. (famous last words)

The second is where things would appear to get tricky. How and where is the spacecraft trajectory stored?

The third is tougher than one, but still (presumably) straightforward.

If anyone has any suggestions for specific classes/files I should look at, that would be tremendously helpful. I will try my best to send patches back if I ever get this work done.

Anyways, thanks for your help!

ElChristou
Developer
Posts: 3776
Joined: 04.02.2005
With us: 19 years 9 months

Post #46by ElChristou » 12.08.2005, 15:10

If this work see the light (I'm hopping so) it would be nice to have a setting to display forces in action on a model...
Image

maxim
Posts: 1036
Joined: 13.11.2003
With us: 21 years
Location: N?rnberg, Germany

Post #47by maxim » 12.08.2005, 15:23

erwos wrote:If anyone has any suggestions for specific classes/files I should look at, that would be tremendously helpful.


I also have only a very coarse knowledge of the code. But you may find what you look for in

trajmanager.h
trajmanager.cpp
orbit.h
orbit.cpp
samporbit.h
samporbit.cpp

The function 'LoadSampledOrbit' in 'samporbit.cpp' may be a good starting point for you.

maxim

erwos
Posts: 4
Joined: 12.08.2005
With us: 19 years 3 months
Location: MD

Post #48by erwos » 12.08.2005, 20:30

Thanks for the list of files. I'll probably try to go toe-to-toe with this problem next week.

Currently, all I'm worrying about is MJD, X, Y, and Z. We're using ECEF coords, which I guess could be a problem if Celestia expects ECI - although, truthfully, exact positioning is actually not so important.

Forces acting on the model is, unfortunately, not something that's going to happen, at least if I'm writing it. The primary use for this (for now, anyhow) would be visualizing real-time, hardware-in-the-loop formation flying - worrying about solar radiation pressure and such is already considered by the components pushing out the coordinates being used. If I wanted to get fancy, I could probably do some stuff with thrust, but that's more icing on the cake, I think.

-Erwos

Avatar
selden
Developer
Posts: 10192
Joined: 04.09.2002
With us: 22 years 2 months
Location: NY, USA

Post #49by selden » 12.08.2005, 21:12

Yes, Celestia wants ECI with full Julian dates, not Modified Julian.

An Earth-centered trajectory for this spring's Rosetta flyby was generated by ESA. It's available at http://www.lepp.cornell.edu/~seb/celestia/rosetta_earth1.zip
if you'd like to look at an example.
Selden

erwos
Posts: 4
Joined: 12.08.2005
With us: 19 years 3 months
Location: MD

Post #50by erwos » 15.08.2005, 12:46

Thanks for the trajectory example files - quite helpful in terms of actually seeing the exact file format.

Some idiot questions for all of you:

What function does Celestia use to iterate through the trajectory? My guess is that it's using positionAtTime every so often, but I'd like to confirm that...

It strikes me that the most straightforward thing to do is to just spawn a new thread that acts as the network listener, and then use a mutex to do locking, so that Celestia can't read the trajectory as the input thread is writing to the trajectory. Does Celestia have any pre-existing threading code for me to check out, so I don't go implementing things in a non-Celestia-standard way? This is one of those places where I worry about cross-platform issues...

-Erwos

hank
Developer
Posts: 645
Joined: 03.02.2002
With us: 22 years 9 months
Location: Seattle, WA USA

Post #51by hank » 15.08.2005, 16:55

erwos wrote:What function does Celestia use to iterate through the trajectory? My guess is that it's using positionAtTime every so often, but I'd like to confirm that...
-Erwos

I don't claim to be an expert, but here's my understanding:

As you realize, Celestia allows time to run forward or backward at any rate and allows instant arbitrary switching from one time to another. Because of this, the code makes no attempt to take advantage of time coherence, but redetermines all positions for each frame. Thus the frequency with which Celestia requests position updates depends on the frame rate. For trajectory files, interpolation is used to determine positions at times which fall between the time points specified in the file. Celestia doesn't currently do any multi-threading, probably due to cross-platform issues.

- Hank

erwos
Posts: 4
Joined: 12.08.2005
With us: 19 years 3 months
Location: MD

Post #52by erwos » 15.08.2005, 18:12

Very helpful information - thank you. That roughly coincides with how I thought things would work, too.

The threading issue makes things trickier, unfortunately - I doubt any patch I release could be mainlined into the trunk without creating some real issues. Still, I'll see what I can do...

-Erwos

Topic author
Apollonian
Posts: 52
Joined: 19.10.2004
With us: 20 years 1 month

Post #53by Apollonian » 30.08.2005, 15:03

So, as of a couple days ago, we've released the updated Java Code (revision 57) with the simulation propagator in it.

http://jat.sourceforge.net/source.html

There are still a few bugs in the XYZ creator, as it gives an Out of Memory error if the timespan of the propagation is too long. In this case, one would need to continue a separate propagation where the last one left off.

You will see an example of generating a more accurate orbit for the International Space Station in the "jat.sim.Simulation.java" class under the runSimOne method (function). The data for the ISS was taken from a recent Celestrak TLE file and can be seen in "jat.sim.input.ISS.xml". Also of interest is the jat.util.Celestia.java class which holds the methods to create SSC and XYZ files from propagation data (nothing special).

Presumably, the program can also handle interplanetary orbits, though that part of the propagator has not been verified yet.

If anyone wants me to run simulations for them, I'd be more than happy to play around with the code, generating the resulting XYZ files.

Selden, I know you had mentioned some projects that were waiting on more accurate orbits. Can you send me initial ephemeris info?

Avatar
selden
Developer
Posts: 10192
Joined: 04.09.2002
With us: 22 years 2 months
Location: NY, USA

Post #54by selden » 30.08.2005, 15:18

Thanks!

I'll have to figure out something.

FWIW, the problem I'm most interested in at the moment is to generate a spacecraft trajectory from Earth to Mars given a specific date (9-11-1975), desired transit time (160 days) and acceleration (20 km/sec/sec), returning 210 days later with a return transit time of 230 days. My initial attempts suggest that this might not work, though.
Selden

Topic author
Apollonian
Posts: 52
Joined: 19.10.2004
With us: 20 years 1 month

Post #55by Apollonian » 31.08.2005, 01:55

Couple points of clarification:

Are "heliocentric" XYZ files actually heliocentric or are they barycentric about the Solar System Barycenter? This shouldn't make a difference, but technically the DE405 ephemerides I'm using are Barycentric.

What do you mean by "acceleration (20 km/sec/sec)"? Initial acceleration? Max acceleration? Over what duration? I shouldn't need this when parameterizing the transfer unless you have a fuel budget in mind or some other hard constraint.

Avatar
selden
Developer
Posts: 10192
Joined: 04.09.2002
With us: 22 years 2 months
Location: NY, USA

Post #56by selden » 31.08.2005, 10:49

They're heliocentric.

I'll send you a PM clarifying what I'm trying to do.
Selden

Planet X
Posts: 79
Joined: 07.03.2005
With us: 19 years 8 months
Location: booted from planethood

Post #57by Planet X » 27.01.2006, 19:50

OK, how would I go about modifying the trajectory of an already existing mission? For instance, I want to somehow get Voyager 1 to encounter Pluto. Any help would be greatly appreciated. Thanks!

J P

scratt
Posts: 36
Joined: 05.12.2005
With us: 18 years 11 months
Location: Thailand

Post #58by scratt » 28.01.2006, 04:54

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


Sirius, I would be very interested in seeing that.

I have a new SpaceShip clas which allows objects with their own Global coordinate, as well as certain AI routines.

One of the 'modes' these objects can go into is an "orbit" mode. In this mode it simply orbits the closest celestial body. However, my code for that part at the moment is rudimentary at best as I am concentrating on movement around systems, as well as 'awareness' of other objects at the moment.
Extreme Sports Cafe - Remember, measure life by the moments that take your breath away, not by how many breaths you take...

Slaverstudent
Posts: 14
Joined: 20.12.2005
With us: 18 years 11 months

Post #59by Slaverstudent » 30.01.2006, 01:34

selden wrote:....desired transit time (160 days) and acceleration (20 km/sec/sec), returning 210 days later ....


Selden,

are you sure you meant 20km/sec/sec, and not 20m/s/s?

That's 2000G's and if you kept that up for long, it would take a hell of a lot less than 200days for the journey!

:wink:

Avatar
selden
Developer
Posts: 10192
Joined: 04.09.2002
With us: 22 years 2 months
Location: NY, USA

Post #60by selden » 30.01.2006, 12:39

Yes, 20m/sec^2 would seem to be just a little more reasonable :)

The average acceleration varies between 1.25 and 3.1 Gs, depending on how much fuel has been expended.
Selden


Return to “Development”