Page 1 of 4

Rotations

Posted: 19.10.2006, 08:08
by chris
A new feature in Celestia 1.5.0 is a much more flexible scheme for describing an object's orientation, together with a cleaner syntax for rotations in ssc files. There are now different types of rotation, much like there are different types of orbits right now (CustomOrbit, SampledOrbit, EllipticalOrbit, etc.)

In Celestia 1.4.1 and earlier, the rotation parameters appeared at the top level of an ssc body definition. For example, here's part of the definition of Earth:

Code: Select all

"Earth" "Sol"
{
    Texture "earth.*"
    Radius 6378.140
    CustomOrbit "vsop87-earth"

    RotationPeriod   23.9344694
    Obliquity -23.4392911
    RotationOffset 280.5
}


In Celestia 1.5.0, this same syntax is still supported for backward compatilibity. But, you can also specify a rotation type with a grouped set of parameters. So this would be the preferred way to set the rotation parameters of Earth in 1.5.0:

Code: Select all

"Earth" "Sol"
{
    Texture "earth.*"
    Radius 6378.140
    CustomOrbit "vsop87-earth"

    UniformRotation
    {
        Period           23.9344694
        Inclination     -23.4392911
        Offset          280.5
    }
}


Grouping the rotation parameters in the UniformRotation block keeps the object definition more organized, but more importantly the new syntax allows other types of rotations to be used. In addition to UniformRotation, there's PrecessingRotation, CustomRotation, and SampledRotation.

SampledRotation specifies a file of quaternion keys that are interpolated to compute the orientation of a body. I've heard a lot of requests for this feature, mostly from people interested in modeling spacecraft attitude more accurately than what Celestia 1.4.1 rotation parameters permitted.

A sampled orientation file is an ASCII text file with records of the form:
<time> <qw> <qx> <qy> <qz>

(qw qx qy qz) is a unit quaternion representing a rotation of theta =acos(qw)*2 radians about the axis (qx, qy, qz)*sin(theta/2). The time values are Julian days in Barycentric Dynamical Time. Here's a very simple example file:

Code: Select all

2454025 0 0 1 0
2454026 0.707 0.707 0 0
2454027 0 0 1 0
2454028 1 0 0 0
2454029 0 0 1 0
2454030 0 1 0 0
2454031 0 0 0 1
2454032 1 0 0 0


This describes a series of 90 and 180 degree rotations over the time period from Oct 15-23, 2006. I created this file by hand for testing, but generally, orientation files will be created by some data conversion tool.

I took some time to make sure that Celestia uses the quaternions in an orientation file in a way that is consistent with the coordinate system in xyz files.

--Chris

Posted: 19.10.2006, 12:54
by Chuft-Captain
Nice work Chris!

These new features will help with a lot of (if not all) orientation issues.
Can you explain a little more about Precessing and Custom?

Is the PrecessingRotation a special case of CustomRotation?...
Will the precession always be at 90 degrees to the standard rotation?

Just one comment about the SampledRotation...
Seeing as this is a new feature which will have no historic baggage (in terms of addons) wouldn't it be a good idea to try and use a non-absolute time-format as suggested by me in this thread: http://celestiaproject.net/forum/viewtopic.php ... highlight=

This would make this new feature compatible with periodic or repeating motions (if not now) then at least in the future, and could serve as a testbed for adding periodic motion to SampledOrbits etc...

Regards
CC

Posted: 19.10.2006, 13:03
by Adirondack
Chris,
do you have any plans for the file extension? xyzr? xyzo? or what?

Adirondack

Posted: 19.10.2006, 14:18
by Malenfant

Code: Select all

UniformRotation
    {
        Period           23.9344694
        Inclination     -23.4392911
        Offset          280.5
    }


What does this actually mean though? What are the Inclination and Offset measured with respect to? Will there be a manual/guide to explain how these new features should be used?

Posted: 19.10.2006, 14:37
by Adirondack
Malenfant wrote:

Code: Select all

UniformRotation
    {
        Period           23.9344694
        Inclination     -23.4392911
        Offset          280.5
    }


What does this actually mean though? What are the Inclination and Offset measured with respect to? Will there be a manual/guide to explain how these new features should be used?


Period:
A number that defines the amount of time it take for the selected object to fully rotate once around its axis. This value is defined in terms of hours.

Inclination:
A number which defines the slant of the object's axis of rotation.
This parameter tilts a planet or a moon through the specified numer of degrees relative to the local reference plane (ecliptic for planets; planet equatorial plane for moons).

Offset:
Rotation of the object, related to the time period defined by the Epoch.
In general you use Offset to rotate an object anticlockwise around its rotation axis by the given numer of degrees.

Adirondack

Posted: 19.10.2006, 15:00
by cartrite
When creating a sampled orientation file could this x y z information be used as the qx qy qz ? A quote taken from states.ug

Code: Select all

                      Welcome to STATES
 
      This program demonstrates the use of NAIF S- and P-
      Kernel (SPK) files and subroutines by computing the
      state of a target body as seen from an observing
      body at a number of epochs within a given time
      interval.
 
 
      Enter the name of a leapseconds kernel file: cook_01.tls
 
      Enter the name of a binary SPK ephemeris file: cook_01.bsp
 
      Enter the name of the observing body: earth
 
      Enter the name of a target body: moon
 
      Enter the number of states to be calculated: 5
 
      Enter the beginning UTC time: 1 jan 1990
 
      Enter the ending UTC time: 2 jan 1990
 
      Enter the inertial reference frame (eg:J2000): j2000
 
      Type of correction                              Type of state
      -------------------------------------------------------------
      'LT+S'    Light-time and stellar aberration    Apparent state
      'LT'      Light-time only                      True state
      'NONE'    No correction                        Geometric state
 
      Enter LT+S, LT, or NONE: LT+S
 
      Working ... Please wait
 
      For time 1 of 5, the state of:
      Body            : moon
      Relative to body: earth
      In Frame        : j2000
      At UTC time     : 1990 JAN 01 00:00:00
 
                       Position (km)              Velocity (km/s)
                  -----------------------     -----------------------
                X:  3.1817356914228073e+05         5.3394535681481514e-01
                Y: -1.9411657590890554e+05         7.7051535844816144e-01
                Z: -7.7812550159748964e+04         4.3386380567914284e-01
        MAGNITUDE:  3.8074986290962604e+05      1.0329711339369498e+00
 
 
      Continue? (Enter Y or N): Y
      For time 2 of 5, the state of:
      Body            : moon
      Relative to body: earth
      In Frame        : j2000
      At UTC time     : 1990 JAN 01 06:00:00
 
                       Position (km)              Velocity (km/s)
                  -----------------------     -----------------------
                X:  3.2915688826278772e+05         4.8249639220368934e-01
                Y: -1.7715581503624297e+05         7.9947042534779911e-01
                Z: -6.8315337774688582e+04         4.4523496484754310e-01
        MAGNITUDE:  3.7999398056714883e+05      1.0344998324882222e+00
 

If it is then coming up with the values for qw would be the challenge? I'm new to this concept. I'm searching the archives in my brain cells to try and remember what I used to know about mathematics and calculus, so it may come back to me.

States is a tool in the spice toolkit.

Or am I confusing object orientation with rotation orientation?

cartrite

Posted: 19.10.2006, 16:49
by chris
Malenfant wrote:

Code: Select all

UniformRotation
    {
        Period           23.9344694
        Inclination     -23.4392911
        Offset          280.5
    }


What does this actually mean though? What are the Inclination and Offset measured with respect to? Will there be a manual/guide to explain how these new features should be used?


Yes, they will be much better documented than they previously were. Note that obliquity is now inclination. Obliquity refers specifically to the angle between a planet's axis of rotation and the normal to its orbital plane. Inclination is more general and more appropriate here, since the reference plane is typically not the planet's orbital plane. The reference plane is as Adirondack explained: the ecliptic for bodies orbiting a star, and the equatorial plane of the parent body otherwise. Very soon, there will be some additional ways to set the reference plane, but more on that later . . .

I may change the name of offset as well. It refers to the angle of the prime meridian at epoch as measured with respect to the x-axis of the equatorial plane.

--Chris

Posted: 19.10.2006, 16:51
by chris
Adirondack wrote:Chris,
do you have any plans for the file extension? xyzr? xyzo? or what?

Adirondack


I haven't decided yet. I used .q in the sample, but that's not appropriate because the format may be extended to allow Euler angles as well as quaternions for orientation.

Suggestions are welcome.

--Chris

Posted: 19.10.2006, 18:18
by chris
cartrite wrote:If it is then coming up with the values for qw would be the challenge? I'm new to this concept. I'm searching the archives in my brain cells to try and remember what I used to know about mathematics and calculus, so it may come back to me.

States is a tool in the spice toolkit.

Or am I confusing object orientation with rotation orientation?


I think that the SPICE states tool just returns the position and velocity of an object. The values in the sample output in states.ug are definitely not orientations.

I've got a rotation type that uses SPICE C-Kernels. It's not ready to be checked in yet, but don't work too hard on figuring out ways of extracting orientations from SPICE.

--Chris

Re: Rotations

Posted: 19.10.2006, 18:31
by hank
chris wrote:Grouping the rotation parameters in the UniformRotation block keeps the object definition more organized, but more importantly the new syntax allows other types of rotations to be used. In addition to UniformRotation, there's PrecessingRotation, CustomRotation, and SampledRotation.

How about a ScriptedRotation that would allow the orientation to be defined by a Lua function?

- Hank

Posted: 19.10.2006, 18:37
by Cham
Chris,

I have few questions :

1- What about setting a spacecraft orientation permanently locked toward another object (toward Earth, or another spacecraft, for example) ? Is it possible now ? Can you give an example, please ?

2- What about the precession axis ? Can we change it, finally ? How ?

Posted: 19.10.2006, 18:48
by hank

Code: Select all

UniformRotation
    {
        Period           23.9344694
        Inclination     -23.4392911
        Offset          280.5
    }

I think you'll also need to specify EquatorAscendingNode.

- Hank

Re: Rotations

Posted: 19.10.2006, 18:55
by chris
hank wrote:
chris wrote:Grouping the rotation parameters in the UniformRotation block keeps the object definition more organized, but more importantly the new syntax allows other types of rotations to be used. In addition to UniformRotation, there's PrecessingRotation, CustomRotation, and SampledRotation.
How about a ScriptedRotation that would allow the orientation to be defined by a Lua function?


Yes, of course. It is easy to create a subclass of RotationModel that calls a Lua function.

--Chris

Posted: 19.10.2006, 19:07
by chris
hank wrote:

Code: Select all

UniformRotation
    {
        Period           23.9344694
        Inclination     -23.4392911
        Offset          280.5
    }
I think you'll also need to specify EquatorAscendingNode.



I didn't use all the available rotation parameters in this example. For Earth, the Equator ascending node is exactly zero, since the ecliptical coordinate system is defined such that the x axis on the line of Earth's vernal equinox. It would probably be slightly more sensible to use an EquatorAscendingNode of 180 and a positive inclination, but you get the exact same orientation either way.

--Chris

Posted: 19.10.2006, 19:47
by hank
chris wrote:
hank wrote:

Code: Select all

UniformRotation
    {
        Period           23.9344694
        Inclination     -23.4392911
        Offset          280.5
    }
I think you'll also need to specify EquatorAscendingNode.


I didn't use all the available rotation parameters in this example. For Earth, the Equator ascending node is exactly zero, since the ecliptical coordinate system is defined such that the x axis on the line of Earth's vernal equinox. It would probably be slightly more sensible to use an EquatorAscendingNode of 180 and a positive inclination, but you get the exact same orientation either way.

--Chris

Right. Earth is a special case. My intention wasn't to criticize your example as such, but to point out that in the general case the EquatorAscendingNode parameter is required. That was missing from Adirondack's explanation. It's needed because an inclination (angle) is not by itself enough to define a rotation axis (vector). Since the rotation axis is a vector, in principle it can be specified in a variety of ways. For example, I think that for solar system objects the IAU typically uses the RA and Dec. of the object's north pole.

- Hank

Posted: 19.10.2006, 20:20
by chris
Cham wrote:Chris,

I have few questions :

1- What about setting a spacecraft orientation permanently locked toward another object (toward Earth, or another spacecraft, for example) ? Is it possible now ? Can you give an example, please ?

It will be possible with the soon-to-be-introduced reference frames. You'll be able to define a coordinate system based on two axes. To lock orientation toward some target object, one of the axes would point in the object-to-object direction. An object that has a fixed orientation in this reference frame will always have the same side facing the target object. Of course, you can apply some non-constant rotation in this reference frame.

2- What about the precession axis ? Can we change it, finally ? How ?


I haven't yet decided if the PrecessingRotation should have fields to control the precession axis or if the precession axis should be assumed to be normal to the reference plane. In the second case (which I'm leaning toward at the moment), you could change the effective axis of precession by changing the reference frame.

--Chris

Posted: 20.10.2006, 00:38
by Cham
Chris,

all this appears to be very complicated to do, in an SSC file. There are lots of new commands to learn, it seems.

Posted: 20.10.2006, 06:45
by Adirondack
chris wrote:
Adirondack wrote:Chris,
do you have any plans for the file extension? xyzr? xyzo? or what?

Adirondack

I haven't decided yet. I used .q in the sample, but that's not appropriate because the format may be extended to allow Euler angles as well as quaternions for orientation.

Suggestions are welcome.

--Chris

Okay, here we go:

SAO (SAmple Orientation) - sounds too much like "Smithsonian Astrophysical Observatory Star Catalog" ?
SOQ (Sample Orientation Quaternion)
QSO (Quaternion Sample Orientation)
SOF (Sample Orientation File)
CSO (Celestia Sample Orientation)

Adirondack

Posted: 20.10.2006, 08:59
by Adirondack
hank wrote:Right. Earth is a special case. My intention wasn't to criticize your example as such, but to point out that in the general case the EquatorAscendingNode parameter is required. That was missing from Adirondack's explanation.

Hank,

as Chris already said, the EquatorAscendingNode is exactly zero for the example "Earth". So I didn't write anything about the EquatorAscendingNode in this case. Sorry for that. :oops:
Of course the tilt of the 'Inclination'-Parameter is always made in the plane of the local coordinate, whereas planets and moons have their axis tilted in all sorts of directions.
'Inclination' does not define the direction of the tilt; to do so you need EquatorAscendingNode that rotates the tilted object in the reference plane through the specified number of degrees (= direction of the tilt).

Adirondack

Posted: 07.11.2006, 10:50
by produit
Hi,

I am still interested in having INTEGRAL attitude right.
I have created a tentative file of (two year worth of) attitude
versus time in the format
suggested in documentation (jd quaternion)
it is in:
http://isdcul3.unige.ch/~produit/celestia/

But I need to test it now.

I did a checkout from sourceforge CVS. But there was no
configure script so I cannot compile.
I am using preferably mac but can use linux also if somebody can point
me to instructions how to build latest version.

If somebody can upload my file and try to use it.
If it is right the solar pannels should be turned towards the sun at all time
but should move a lot (every 20 minutes)