Celestia Forums

I have ECEF position and ECEF velocity in the BET files referenced below. They are in kilometers and kilometers/sec as documented. I also have the quaternions for this trajectory as inertial to body. I setup my *.ssc file and started Celestia but the SLS_PB vFS trajectory does not start out at Kennedy, FL. Here is my *.ssc content below. Am I supposed to use the BodyFixed Frame for Earth Centered Earth Fixed ? I don't see any errors reading the files in when I press '~' key. I set the time to the beginning of my BET trajectory and it shows up orbiting around the earth but not at Kennedy. I tried swapping the y and z coordinates because I read that opengl and cartesian have that transformation but it still does not start at Kennedy.

"SLS_PB vFS" "Sol/Earth"
{
Class "spacecraft"
Mesh "B1B_full_stack.cmod"
Radius 0.040
Visible true
Clickable true
Orientation [90.0 0.0 0.0 1.0]
Color [0.98 0.97 1.0]
OrbitFrame { BodyFixed { Center "Sol/Earth" } }
SampledTrajectory { Source "BET.xyzv" }
SampledOrientation { Source "BET.quat" }

#TwoVector { Center "object"
#Primary { Axis "x"
#Secondary pitch
#}
#RelativeVector { Observer "Sol/Earth"
#Frame { BodyFixed { Center "Sol/Earth" }
#}
#}
}

I'm assuming you're using Celestia v1.6.1 (or a close variant).

My understanding is that the times used by the GUI are Gregorian, including leap seconds, etc.
In contrast, the times that Celestia uses internally, including in xyzv files, are TDB.
As a result, a time you specify to the GUI is unlikely to be the same as the time specified in the trajectory files. This sometimes causes confusion and/or offsets relative to other time systems.

I'm unfamiliar with ECEF coordinates, so I can't help much without doing some research. What time standard does it use? Might it need to be translated to TDB?
It's also been a while since I did anything with xyzv trajectories.

Some other thoughts:
When you write "does not start at Kennedy", is the trajectory's initial xyzv point at the correct latitude but wrong longitude (indicating a timing problem) or is it at a random long&lat? Is it anywhere near Kennedy?
Is the altitude correct? If the altitude is significantly wrong, I'd suspect a problem in coordinate transforms somewhere.
Is the end at a fixed location relative to the Earth's surface or does the Earth turn under it? (Which I'm guessing might indicate an OrbitFrame problem.)

FWIW, when debugging trajectory problems, I'd often create a single line xyz file to find out exactly where the associated object was being placed.

Thanks Seldon,

I understand more about the Celestia inputs from your response. I now have my SLS rocket starting at Kennedy. Now, my orientation is not pointing towards my velocity vector. I started to write a velocity fudge at the commented out portion of the bottom but I really want to get my quats working.

I have a BET.q file exported from our simulation and the following *.ssc reads it. The SLS is not pointing exactly 90 degrees wrong so I don't think it is the 3D model. I found a old note from Chris (the man) that there might be a difference between the quaternions used in Celestia and quats in the *.q file by a 90 deg roll. This could be my issue:


"SLS_PB vFS" "Sol/Earth"
{
Class "spacecraft"
Mesh "B1B_full_stack.cmod"
#MeshCenter [ 1.540 0.0 0.0 ]
Radius 0.040
Visible true
Clickable true
Orientation [90.0 1.0 0.0 0.0] # this has to be > 0.0 for the model to show up
Color [0.98 0.97 1.0]
# the BodyFixed is for orientation
#OrbitFrame { BodyFixed { Center "Sol/Earth" } } # this affects the position too
OrbitFrame { EquatorJ2000 { Center "Sol/Earth" } }
SampledTrajectory { Source "BET.xyzv" }
SampledOrientation { Source "BET.q" }
#BodyFrame {
#TwoVector {
#Center "Sol/Earth"
#Primary {
#Axis "x"
#}
#Secondary {
#Axis "y"
#RelativeVelocity {
#Observer "Sol/Earth/SLS_PB vFS"
#Target "Sol/Earth" }
#}
#}
#RelativeVector { Observer "Sol/Earth"
#Frame { BodyFixed { Center "Sol/Earth" }
#}
#}
}

Unfortunately, I've never gotten my head around Quaternions, so I can't help directly. However, I'd tend to suspect the Orientation statement. I believe that it is used as the reference orientation for the SampledOrientation's .q file. I could be wrong, though.

Seldon: I been reading on rotation and orientation all day because my quaternions are still not working. I found your suggested *.ssc many moons ago relating to Frames (see below). Why did you suggest OrbitFrame and BodyFrame in the same object? Does order of Frames matter in an ssc file? Were your Frames redundant.

I tried Qi2b and Qb2i quaternions but the both are not looking right in the scene. The Qi2b is a rotation from inertial to body frame. I figured there would be some discussion on which rotation the quaternions should be using but I did not see any on the Forum.



{
OrbitFrame { BodyFixed { Center "Sol/Earth/hale_yoke" } }
FixedPosition [0 0.001875 -0.00731]

BodyFrame { BodyFixed { Center "Sol/Earth/hale_yoke" } }
ScriptedRotation
{
Module "hale_control"
Function "BridgeRotate"
}
}

Simguy,

The reason Selden has specified both Orbitframe and Bodyframe is because the first (Orbitframe) defines the object's position, and the second (Bodyframe) defines it's orientation. They are not redundant as they each perform a different function. The order doesn't matter, however the order used by Selden is conventional.

In the example you quoted, the object containing these SSC declarations is being located in a fixed position 1.875m in the Y-axis, and 7.31m in the Z-axis relative to the hale_yoke object by this bit :

{
OrbitFrame { BodyFixed { Center "Sol/Earth/hale_yoke" } }
FixedPosition [0 0.001875 -0.00731]

and it's orientation is handled (also relative to the hale_yoke) by this bit:

BodyFrame { BodyFixed { Center "Sol/Earth/hale_yoke" } }
ScriptedRotation
{
Module "hale_control"
Function "BridgeRotate"
}
}

The "reference" object does NOT have to be the same for OrbitFrame and BodyFrame depending on what you are trying to achieve.
eg. An Earth orbiting satellite would likely have it's OrbitFrame (position") specified *relative to* Earth, but it's orientation (BodyFrame) may be specified relative to another object, or objects (including itself) ... it can get quite complicated.

In your case, you will probably as Selden suggests substitute a SampledOrientation (with a form of your .q file as input) for the ScriptedOrientation shown in Selden's example, but the structure will be similar.

CC

Simguy,

Chuft-Captain's descriptions of what I was doing is exactly right. I used that order only so I could keep their functions straight in my own mind. In some cases one or both Frames can be omitted if their default values are appropriate for the object being defined. I found it easier to write them out explicitly so as to minimize my own confusion.

Unfortunately, as I wrote earlier, my understanding of Quaternions is not sufficient to be able to help you with their details, except that they would replace the ScriptedRotation that I specified in the example that you chose. Sorry.

I forgot to mention that I agree with Selden's comment re the Orientation statement.
I'm pretty sure I've read somewhere (maybe in the WIKI for reference frames) that the Orientation statement (though still usable for limited cases in isolation) should not be used if you're also using a BodyFrame, as this will obviously cause a conflict.

Orientation is the old (pre 1.5) method, but since the BodyFrame statement was introduced, you can do everything and much more with a BodyFrame that you would previously do with an Orientation.

In short ... BodyFrame syntax replaces and extends the old Orientation statement.
Don't mix the legacy "Orientation" statement with the "BodyFrame" statement.
Once, you get your head around the syntax, you should find BodyFrame is the superior approach.

PS. A correction to my earlier post ...
"7.31m in the Z-axis" should have been stated as -7.31m" of course! I didn't notice the minus sign until just now.

One of Selden's comments back in 2008 stated:
"values are the 4 components of the object's orientation specified as a quaternion relative to the object's BodyFrame."

My assumptions are that the necessary quaternion is a rotation from the inertial to body coordinate frame. My quat output is from the CSpice simulations. Here is my latest *.ssc attempt without Orientation, below.


Unrelated: the SLS does a roll maneuver right away after launch. My 3D object starts out in the correct orientation but when the roll maneuver takes place, the 3D object pitches instead. The Captain stated that I should not use Orientation [XXXX] but I feel I need to convert the pitch to a roll somehow.

SampledOrbit "BET_vFS.xyzv"
BodyFrame { EquatorJ2000 { Center "Sol/Earth" } }
SampledOrientation "BET_vFS.q"

i haven't worked with orbits code, but try to modify you quaternions the following way: x y z w -> x -z y w

That sounds like it might work. I tried different combinations of swapping axis (and negative signs) but I can't get my model to move in the direction of the velocity vector. I figure there is around 16 different combinations of rotations. My 3D model has the +x pointing in the direction of the velocity vector. The +y separates each of the SLS boosters but these are not too important right now. I thought the opengl frame was +y in the direction of the velocity vector but my attempts to change my eigen values did not work.

Is the +y out the front in Celestia?

Celestia uses the following directions: X to the right, Y out of the front and Z up. But I not very familiar with this code, I generally work with UI and OpenGL.

I tried "onetwothree"s suggestion by swapping around my quaternion's eigen values.
such as: x y z w -> x -z y w
I was never able to get the proper rotation.

The Captain said not to use Orientation with BodyFrame. I want to try to insert my 3D model's rotation (such as the Orientation ) into BodyFrame {}. I read the following URL and I don't see how to do that.

https://en.wikibooks.org/wiki/Celestia/Reference_Frames#BodyFrame_property

My quaternions are inertial to body but I am using a "body" frame. I think this might be my problem. The above URL does not discuss "inertial" frames. Which one of the reference frames do you think is inertial?

This is my current rotation Frame.
BodyFrame { EquatorJ2000 { Center "Sol/Earth" } }