Spacecraft in Orbit

[Chuft-Captain]

From what I've been told, keplerian elements can only be set statically in an .SSC file when Celestia starts up. This makes sense for planets, moons, etc, however for more 'moveable' objects such as spacecraft in orbit I think it should be possible to modify their orbits dynamically (either interactively, scripted, or both). XYZ's just don't really cut it in terms of accuracy and ease of use in these situations.
How about it Chris? It would make docking the shuttle with the ISS a piece of cake!
original posting: http://celestiaproject.net/forum/viewtopic.php ... highlight=

[GlobeMaker]

Hello Captain,

Your goal is compatible with the rocket motor I am developing.
At first, only one star will be accelerated by the motor software.
But after that succeeds, the rocket motor will be applied to .3ds
models, including the satellites you mentioned. This essay
describes the user interface possiblities and then it describes
my C++ edits for accelerating a star. I hope that Chris and other
skilled programmers will comment on these goals which you and I
share.

Two User Interface Development Phases
The first user interface will use a "Flight Plan". This will be
a script that has information about the force of acceleration
and the directions of that force during real time. The user
starts the script as a normal .celx script. The user selects
one object with a mouse in the normal way. The object is accelerated
according to the Flight Plan.

The second user interface is more complicated to program in C++.
The keys or mouse will be used to adjust the thrust force and the
direction of the force. A joystick can be used, optionally.

C++ Edits Planned for January, 2006
One star will be accelerated according to a simple Flight Plan as
soon as it is selected. The observer.cpp program will be edited.
The update() function has this code :
_______________________________________________________________________
// Update the position
situation.translation = situation.translation + getVelocity() * dt;
if (observerMode == Free)
{
// Update the observer's orientation
Vec3f fAV = getAngularVelocity();
Vec3d AV(fAV.x, fAV.y, fAV.z);
Quatd dr = 0.5 * (AV * situation.rotation);
situation.rotation += dt * dr;
situation.rotation.normalize();
}
_______________________________________________________________________
This update function will have new functions added
like this two line pseudo-code:

Star->setPosition = getPosition + FlightPlanDelta*count;
count = count + FlightPlanCount;

The idea is to:
get the coordinates of the selected star,
add a distance to the coordinate of the star;
increase the distance for the next pass in the main loop.
The FlightPlanDelta is a constant distance.
The FlightPlanCount is a constant acceleration factor.

The getPosition function already exists in Celestia and it
accesses data that was loaded from the stars.dat file.

Conclusion
The modified observer.cpp program will be compiled in January.
I hope that skilled programmers will provide guidance to me so
that my work is made easier.

Thank you in advance,
Your humble associate,
Alan Folmsbee, MSEE

[selden]

If you haven't already done so, you might take a look at Mostly Harmless, a variant of Celestia. At one point it included code so that gravity could work on the viewpoint "object." I don't know if it included rocket controls.

[GlobeMaker]

Thank you, Selden, for pointing me toward the Mostly Harmless source code.
I downloaded the source code from :
http://sourceforge.net/project/showfile ... e_id=46488
The files were from April 23, 2004. That project was abandoned after that.

I ran an automated search for words like "thrust", "gravity", "SQL", "mh" and
found several useful C and C++ code sections. All of the files under the /src/
directory were searched, and the reports came back with a wealth of
potentially useful stuff. The final version of Mostly Harmless by Marc Griffith
has commented out the gravity and thrust facilites, but I can get ideas from his work.

I am not developing gravity, only thrust for Celestia objects. Applying
a velocity to some nearby stars will make Celestia more accurate,
because stars do move with proper motion.
As it is now, the stars have fixed positions in the firmament. I believe
the motors will not be opposed by anyone involved with Celestia.
If there is opposition to having thrust from rocket motors, I will listen
with sensitivity and care. If this opposition is based on valid concerns,
I would abandon this work.

Here is an excerpt from Marc's configfile.cpp :

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
//#ifdef USE_GRAVITY
//config->shipMass = 100000; //kilograms
//config->thrusterForce = 40e6; //newtons
//configParams->getNumber("ShipMass", config->shipMass);
//configParams->getNumber("ThrusterForce", config->thrusterForce);
//#endif

[selden]

GM,

Don't forget that stars in Celestia can orbit around Barycenters. One can be defined at the center of the Milky Way, for example, and stars can be specified orbiting around it.

I suspect rocket thrust is unlikely to be included in the main Celestia code, but a separate program based on Celestia could include it.

[Chuft-Captain]

Seeing as you mention it Selden.
How do we actually get to the exact center of the Milky Way? When I go to it the closest I can get is 500ly away.
What if I actually wanted to get up close and personal with the Super-Black-Hole that purportedly lives there?

[GlobeMaker]

Roll program...
Engines throttling up, three engines now 104 percent.
Roger, go at throttle up...!
Flight controllers are looking very carefully at the situation.
Obviously a major malfunction.
We have no downlink.

[selden]

CC,

It's a form of Zeno's paradox.

The distance steps used to approach an object are determined by the object's radius. So to get really close or inside, the easiest workaround is to define another object at the same location with a tiny radius and approach that other object, not the one you're investigating.

[Apollonian]

You might want to keep your eye on JAT: the Java Astrodynamics Toolkit. It is an open source project which is working to model nearly all aspects of spacecraft trajectories, attitude, and mission design.

Sourcecode is available at:
http://jat.sourceforge.net

I haven't worked out a rendezvous scenario yet, but all the tools are there in JAT to do so. For reference, the shuttle docking scenario corresponds to an 'intercept problem' usually referred to as "Lambert's Problem": finding the orbital path which intercepts another object at the same place at the same time.

JAT also contains information for a non-spherical Earth gravity model, radiation effects, etc which is much more realistic than Keplerian.

I have also included a class in JAT which allows you to automatically generate the necessary .ssc and .xyz files for the trajectories created in JAT.

See the following thread for more details:
http://celestiaproject.net/forum/viewtopic.php?t=6188

[Chuft-Captain]

This would be a great tool if it could generate xyz's accurate to a meter or so for Celestia!!!

I haven't worked out a rendezvous scenario yet, but all the tools are there in JAT to do so. For reference, the shuttle docking scenario corresponds to an 'intercept problem' usually referred to as "Lambert's Problem": finding the orbital path which intercepts another object at the same place at the same time.

In my attempts to simulate a docking in Celestia I had to implement multiple versions of the object because Celestia only reads .SSC's etc at startup.
ie:.
Obj-1: In stable starting orbit, (.SSC)
Obj-2: travelling under influence of .xyz, and
Obj-3: Final Orbit (.SSC)
This of course means 3 differently named objects which appear and disappear at the appropriate times. Will create problems if tracking or following the object.
The part I couldn't get to work was the XYZ, perhaps because of time/positional accuracy or frame of reference issues.
Of course, I was only trying to generate a straight line path, and wasn't too worried about simulating Lambert's problem etc.

Question: Does your JAT class handle situations where the starting and ending orbits are around different objects. eg. Transfer from say Earth-Orbit to Moon-Orbit? Or, does everything have to be heliocentric, or at least in the same frame of reference?

JAT also contains information for a non-spherical Earth gravity model, radiation effects, etc which is much more realistic than Keplerian.

I guess this infromation would have be ignored for generating data for Celestia? --- as Celestia is not THAT realistic!
'

I have also included a class in JAT which allows you to automatically generate the necessary .ssc and .xyz files for the trajectories created in JAT.

How well will 'real' trajectories created in JAT translate to the positions of objects whose positions are defined using Celestia's slightly 'less than real-life' methods.

[scratt]

In my attempts to simulate a docking in Celestia I had to implement multiple versions of the object because Celestia only reads .SSC's etc at startup.
ie:.
Obj-1: In stable starting orbit, (.SSC)
Obj-2: travelling under influence of .xyz, and
Obj-3: Final Orbit (.SSC)
This of course means 3 differently named objects which appear and disappear at the appropriate times. Will create problems if tracking or following the object.
The part I couldn't get to work was the XYZ, perhaps because of time/positional accuracy or frame of reference issues.
Of course, I was only trying to generate a straight line path, and wasn't too worried about simulating Lambert's problem etc.

I am looking at struturing this in Celestia at the moment..

I think an all together new class of object is required, which can then have dynamic positioning using universal coordinates. The hard bit is going to be transitioning from system to system, and converting to 'local' coordinates. If you are actually following a craft that does this and make a mistake in the maths, or simply lose accuracy, then it might appear that a ship has indeed gone into hyperspace!

Luckilly the distances between systems is so large I don't think 'changeover points' will pose much of a problem.

I can post back here with my progress as I move ahead with this if you guys like.... Then perhaps someone more 'mathsy' can always build ontop of what I plan to do and make it more usefull to the scientific community here...

I am doing this from a totally different perspective, and with different motives than most I fear....

[Apollonian]

JAT uses planetary information from the JPL DE405 ephemerides. This translates to highly accurate information about the location of the planets in a heliocentric reference frame. Celestia uses VSOP87 expansions. However, if you plot an XYZ path for Earth using JAT, you will find that it lies right on top of Celestia's Earth.

As such, if you are plotting an interplanetary mission, in theory JAT has enough accuracy to do this without running into the 'hyperspace' issue.

I'm still working on generating an interplanetary mission in JAT. As I'm taking a trajectory optimization course this semester, I am hoping that will give me some help in putting together the simulation.

The only drawback to using JAT is that it is in Java. However, personally I think that Java is much easier than C++ since it has mostly the same syntax without having to worry about things like memory allocation. Plus, the object-oriented structure is much more readable than C++. The real nice thing, however, is that it has thorough html-style documentation.

http://jat.sourceforge.net/api2/index.html

[Apollonian]

Here is an example of the demo that I am including in the latest revision of JAT. It features an orbit for an International Space Station ephemeris on June 1, 2004 propagated for one day.

The orbit is subject to the non-spherical gravity of the earth along with the gravity of the moon and the sun.

Notice how the orbit precesses during the course of the day.

A similar orbit was verified against AGI's Satellite Toolkit. The conference paper is pending.



PS - I also modded celestia to ensure that the orbits plot in front of the planets.

[scratt]

I have now created a derived Class from the Body Class and called it SpaceShip.

At the moment these have a few routines and a set of their own coordinates and dovetail seemlessly into the existing Celestia 1.4 source. One of my aims was to augment, rather than alter, as much of the time as possible...

The great thing is, that as a derived class the 'SpaceShip' class can actually exist with all the current Celstia Code, and use the orbitting code and other modules. So having created one of these new types of ship using a standard ssc file you can ignore it until you want it to do something if you wish.

The beauty of this is that I have not actually altered any of the most important and foundation parts of Celestia. I will be porting this to the latest version of Celestia after some tidying up and more testing on this version.

I have been testing this with a version of the Apollo 11 module, called Apollo 99, and spawn the new 'SpaceShip' just next to the Moon, in Sol.

Unfortunately to test all of this and fly to my tiny SpaceShips and find them in space I have had to make some pretty nasty hacks in some of the Render and Simulation source files.. Pretty much just to identify 'SpaceShip' objects and deal with their coordinates differently.

As I find my way around Celestia better I intend to tidy this up...

But I am now able to start playing with moving these 'SpaceShips' around using their own gravity and thrust routines and have them seemlessly work in the Celestia environment. Not a bad couple of days work!

A lot of support code will still be needed as I have opted to have things based around their own local Sun as the coordinate system base... Switching to new 'home' stars as they move from system to system - if they need to do this. The way Celstia handles things enables us to have a massive and varied Universe database and maintain good core speed, so I am of the opinion that the support code to interface with the Celestia system is a necesary evil to avoid slowing the overall sim down, and keep things sensible.

It's been a lot of fun learning my way around Celstia. Chris and the other contributers have done a great job of making this code pretty readable for a project of this size..

If anyone wants help with doing something similar to what I have done then please do let me know...

[GlobeMaker]

Hello Scratt,

I am interested in your rocket thrust software. I will send a PM private
message that you can get from the top right corner of the Forum screen.
In that will be my email address, in case our discussions become too
detailed for this forum. Or we can put all the details in public view. It is
your choice. Here are some topics :

List of programs modified.

FTP websites where we can pass C++ code around.

Availability of the celestia_scratt.exe file for Windows XP platform.

User interface description

Congratulations on your successful spacecraft engine thrust software!
The end goal for my use of the thrust is to show a visualization of a
planet's gravitational field by accelerating a hundred .3ds frames of reference.

[scratt]

I will be documenting this, and tidying it up tomorrow, so will update you then.. It'll be a lot easier to use after I have refined some of the hacks which will stay in, at least for this early version.

Also I am aiming for it to be a Class that can be built on, but will obviously maintina as much backwards compatibility to Celestia, as well as itself so early adopters can still rely on code they might develope on top.

Initially I will host bits and pieces on a site I am setting up, so you can go and pull the mods fown from there...

I'll post back here when I have got that done..

Later,
scratt.

[Chuft-Captain]

FYI,

I have given up on XYZ's for now but I have now managed to 'simulate' a five minute flight of the Orion spacecraft from 0.6 km out to dock in the landing bay of Space Station V, using another technique I dreamed up. (Where there's a will, there's a way!)
If anyone's interested in viewing this, let me know, but I must warn you it is a REAL HACK involving SSC files, with no code changes involved.
If you're familiar with fsgregs 2001 package, you'll know that Orion is in an orbit with a period of something like 1E32 around the Spacestation (with the space station as it's parent), rather than in parallel orbit around the earth..

Scratt I'd be interested to see the documentation of your solution to see if it can handle this sort of situation, as my method is really only a temporary hack to acheive what I wanted. So long term I'd be hoping to replace this with a proper solution, such as what you appear to have come up with.

Regards

[scratt]

Just to let you guys know I have not forgotten about this....

I intend to add a lot more to this, and don't really want to get into supporting the changes on a weekly basis.

For example, this week I intend to add spline paths for collision detection, some basic AI, as well as creation and deletion of objects in Celestia, and possible "warping" / "Hyper Space".

Pretty obviously I am putting together a full dynamic SpaceShip and Missiles Class for Celestia. Wonder what the heck I'm gonna use that for!?!?

I am more than happy to share this at any point, and will have a repository of my mods on my new web site http://www.arcnebula.com very soon. But what I have right now is very much a work in progress so any stuff is given on an 'as-is' basis until I tidy it up, and is based on 1.4. I will be migrating it all to the latest CVS version once I have hit my own selfimposed milestones...

Chuft, I am more than happy to tell you the five or six mods to Celestia that have got me to this point, and show you the new Class source files in their very basic form, if you want to get cracking on this yourself right away. But if you are not in a huge rush, my new super duper Class will be ready in a week or so...

I am very aware that I am diverging very much from what Celestia is intended so don't want to tread on too many toes here..

Just let me know..