Rotations

[steffens]

Use the command

Code: Select all

make -f Makefile.cvs

to generate the makefiles and configure script.

steffens

[t00fri]

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)

The configure scrips are generated after typing

make -f Makefile.cvs

Bye Fridger

[chris]

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)

I've verified that it works. I just used the orbital elements that came with the INTEGRAL add-on and used a SampledOrientation with your attitude data. The file extension for quaternion attitude data is .q (not .qxyz) although this might change (.q would be inappropriate if the format were extended to also support Euler angles.)

Here's the SSC definition:

Code: Select all

# Orbital elements obtained from JPL's Horizons ephemeris server
# Nov 22. 2002.
# by Selden Ball seb+cel@lns.cornell.edu
"INTEGRAL" "Sol/Earth"
{
   Class "spacecraft"
   Mesh "integral.3ds" # warning: 3MB
   Radius 0.003       #4x4x6 meters w/o solar panels
   EllipticalOrbit
   {
      Period            2.991956794955576E+00
      SemiMajorAxis     8.770790078484899E+04
      Eccentricity      8.234577927435308E-01
      Inclination       5.305319831508738E+01
      AscendingNode     1.014890638402147E+02
      ArgOfPericenter   3.024416289547550E+02
                MeanAnomaly       8.535622442451043E+01
      Epoch       2452600.5
   }
        Albedo            0.7

   SampledOrientation "integral.q"

   BodyFrame { EquatorJ2000 { Center "Sol/Earth" } }
}


Are your attitude quaternions referred to the J2000 equator or to the ecliptic? I've assumed the equator here, and the spacecraft does end up with its solar panels always facing the Sun.

I can provide you with a Mac build of Celestia 1.5.0 if you're still having trouble compiling.

--Chris

[chris]

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/

By the way, this is very neat . . . All of the testing I've done so far has been with calibration files to verify that the orientations are correct. It's much more interesting with real spacecraft attitude data.

--Chris

[selden]

It seems to stay oriented when viewed on my Windows system, too, once I realized that the orientation file was for 2002-2004.

Presumably, however, the solar panels actually can be rotated relative to the spacecraft's body, so that it is not limited to viewing objects that are in locations on the sky that are perpendicular to the solar direction.

This could be shown in the current version of Celestia by having two models, one of the panels and one of the spacecraft, each with its own orientation and orbit files.

[ElChristou]

...This could be shown in the current version of Celestia by having two models, one of the panels and one of the spacecraft, each with its own orientation and orbit files.

Should be almost 3 models, two for the panels and one for the body, but creating all files and placing the objects in the right position seems to be not so easy...

[selden]

You don't need separate models for the two panels: both can be in the same model. Presumably both have the same orientation, unless (or until) a motor fails, of course.

If both panel and body models have the same size and orientation(*), you can either have them orbiting as separate bodies following the same orbit around the earth, or you can have the panels orbiting the spacecraft at a fixed relative position, specifying their rotations relative to the spacecraft.

----
* -- I've found this easiest to do by placing 6 invisible cubes (opacity = 0) at identical locations in the different models, placing them at positions on each axis outside the bounds of the largest body. That way the models all have the identical size and orientation. If the same radius and other parameters are specified for all of them in their SSC declarations, they'll follow one another as if they were one body.

[ElChristou]

You don't need separate models for the two panels: both can be in the same model. Presumably both have the same orientation, unless (or until) a motor fails, of course.

If both panel and body models have the same size and orientation(*), you can either have them orbiting as separate bodies following the same orbit around the earth, or you can have the panels orbiting the spacecraft at a fixed relative position, specifying their rotations relative to the spacecraft.

----
* -- I've found this easiest to do by placing 6 invisible cubes (opacity = 0) at identical locations in the different models, placing them at positions on each axis outside the bounds of the largest body. That way the models all have the identical size and orientation. If the same radius and other parameters are specified for all of them in their SSC declarations, they'll follow one another as if they were one body.

If you have a ssc ready, could you please post it to have a look?

[selden]

Here's part of one I have been using for my Orion Addon (currently in development). It doesn't do any rotation operations, though: it just moves the pulse unit relative to the spacecraft. Also, it only uses two of the simpler of the recently added coordinate specifications. Most of the catalog was created before the newest declarations were available and I haven't had a chance to try to modify it to use more of them.

If you look at the pictures on my Orion page at http://www.lepp.cornell.edu/~seb/celest ... index.html you'll see that the girders follow right along with the main body.

Code: Select all

"Orion_to_Mars" "Sol" {
   Mesh "orion_empty_noplatformfix.cmod"
   Radius 0.02515 # 165 ft. tall
   Class "spacecraft"

   OrbitFrame {
      EquatorJ2000 { Center "Sol" }
       }

   SampledOrbit "SB-jpl-11sep75.xyz"

   RotationPeriod 1e32
   RotationOffset 0
   PrecessionPeriod 0.01

   Obliquity -90.0

   Albedo 0.2
}



# support structure

"Girders" "Sol" {
   Mesh "girdersfix.cmod"
   Radius 0.02515 # 165 ft. tall
   Class "spacecraft"

   OrbitBarycenter "Sol/Orion_to_Mars"
   EllipticalOrbit
   {
   Period         1e32
   SemiMajorAxis  0
   }
   RotationPeriod 1e32
   RotationOffset 0
}


"Pulse_unit" "Sol" {
   Mesh "pulse_unitfix.cmod"
   Radius 0.02515 # 165 ft. tall

   Class "spacecraft"
   SampledOrbit "pls11sep75.xyz"
   OrbitBarycenter "Sol/Orion_to_Mars"

   RotationPeriod 1e32
   RotationOffset 0

}


A problem I just noticed is that the J2000 Equatorial frame that the CVS version of Celestia is using looks like it might not be identical to the Equatorial coordinate system that JAQAR's Swing-By is using. There seems to be a slight tilt of the trajectory relative to the Ecliptic. I'll have to investigate this further.

Added later:
As best I can tell, the frame orientation is reasonable. There's a 60-400 km difference in the spacecraft's positions compared to my previous method of orbit frame rotation, but I suspect that's due to using slightly different values for the Obliquity of the Ecliptic. It would be good to know what value Celestia is using.

[selden]

Chris,

Is there any way to specify an object's orientation relative to its .xyz trajectory without creating an accompanying orientation file?

In particular, can one specify how one of the object's axes should be oriented relative to the current xyz segment?

What I want to do is have the spacecraft's Y axis oriented tangent to the current trajectory segment while it's accelerating. Presumably this would be a fairly common situation.

At the moment, I don't see any way to specify this without creating a file of quaternions.

[chris]

Chris,

Is there any way to specify an object's orientation relative to its .xyz trajectory without creating an accompanying orientation file?

In particular, can one specify how one of the object's axes should be oriented relative to the current xyz segment?

What I want to do is have the spacecraft's Y axis oriented tangent to the current trajectory segment while it's accelerating. Presumably this would be a fairly common situation.

Yes. The key concept is that the velocity is the direction tangent to the trajectory. Thus, you should create a TwoVector reference frame where one of the axes is the body's velocity relative to the object it orbits.

Suppose you have "Object" orbiting the Sun:

Code: Select all

BodyFrame {
    Center "Sol/Object"
    TwoVector {
        Primary {
            Axis "y"
            RelativeVelocity { Target "Sol" }
        }
        Secondary {
            Axis "x"
            RelativePosition { Target "Sol" }
        }
    }
}


This frame sets the y axis to be tangent to the current trajectory (i.e. aligned with the velocity vector) and the x axis to point in the direction of the Sun. Note that the reference frame is undefined if the velocity ever points directly toward or away from the Sun. This will never be the case for an body in a elliptical orbit, but it could occur for body using thrust to modify its trajectory.

Since the frame references Object itself, you'll have to use the modify technique to use it.

--Chris

[produit]

Hi,

thanks for your help.
I have still trouble to compile under mac (I know linux better).
at the make -f Makefile.cvs step
it complains of missing:
AM_GCONF_SOURCE_2
AM_PO_SUBDIRS
AM_GNU_GETTEXT
I have tried to deal with them (without understanding exactely what I was doing) and somewaht pass this step.
configure then complained of many missing libraries on my system.
I installed some of the missing libraries, this is where I am right now.
Anyway I would prefer to get a mac build directely (contact me
directely on my email: nicolas.produit at obs.unige.ch)

The solar pannels of INTEGRAL are fixed. We have enough
power so that we have some tolerance (I think 15 degrees) in
the solar aspect angle. So the spacecraft can be pointed at any
moment in a large fraction of the sky. We have also to avoid
pointing directely to moon of Earth.
In 2006 we deliberately violated this last constain and pointed Earth
for some hours.

The file was created in transforming the RA DEC direction of the x
axis (pointing direction of the telescope) and RA DEC direction of z
axis (perpendicular to solar pannels + direction towards sun)
in a quaternion.
I will have still to check that INTEGRAL is indeed looking at the correct
target star versus time if the file is correct.
I will then regenerate all attitudes up to today and see how to
make a cron job to keep it updated and have an official web page for it.

[selden]

Nicolas,

Sorry I can't help with your Mac compilation problems. There are some Mac experts here who should be able to help, though.

Just for my own information, are you using an xyz or SPICE trajectory for INTEGRAL's orbit? Presumably the orbit does precess somewhat so that its EllipticalOrbit parameters would change gradually with time.

It's good to know that Celestia is helpful for your project!

[produit]

Hi,

for the moment I use the orbit as found in the INTEGRAL plugin.
I have not verified deeply if it is correct.
I have access to real measured ephemeris of the trajectory.
So I could provide .xyz files but they will be huge.
I will do one orbit for checking.

http://celestrak.com/NORAD/elements/science.txt
is maintaining 2 line elements for INTEGRAL
but at first view they look wrong.

I don't know about SPICE.

[selden]

Previously in this thread Chris suggested a way that should align a model's axes relative to its trajectory vector.

Unfortunately, I've been unable to get it to work: my models refuse to change orientation. Specifying different axes to be aligned with an xyz trajectory's velocity vector does not cause the models to have different orientations.

Here's a fragment from an SSC catalog. The 00 declaration is intended to show the default orientation. The two entries for the x object attempt to align the model's X axis with its velocity vector. Equivalent code (not shown) is used to try to align the Y and Z axes. The entry for the Y object specifies Y as its primary axis, and similarly for the Z object.

Code: Select all

"vecalign00" "Sol" {
   Class "spacecraft"
   Mesh "vecalign00.cmod"
   Radius 100
   SampledOrbit "vecalign00.xyz"
}

"vecalignx" "Sol" {
   Class "spacecraft"
   Mesh "vecalignx.cmod"
   Radius 100
   SampledOrbit "vecalignx.xyz"
}

Modify "vecalignx" "Sol" {
   BodyFrame {
       Center "Sol/vecalignx"
       TwoVector {
           Primary {
               Axis "x"
               RelativeVelocity { Target "Sol" }
           }
           Secondary {
               Axis "z"
               RelativePosition { Target "Sol" }
           }
       }
   }
}

Here's the corresponding xyz trajectory:

Code: Select all

2000000 200 0  50000000
3000000 200 0 200000000


The trajectories for the 4 objects differ only in their X values, offsetting them slightly.

Here's a picture demonstrating the unchanged alignments:

Note that the good ships X, Y and Z all have the same orientation as their leader, 00. They should not.

An Addon demonstrating the problem is available at
http://www.lepp.cornell.edu/~seb/celest ... calign.zip
It's 1.5MB. It would have been smaller if I had used simpler models

(Don't be distracted by the fact that the CMOD models' Y axes are aligned with the trajectories' Z direction. This is an issue for another discussion.)

[chris]

Previously in this thread Chris suggested a way that should align a model's axes relative to its trajectory vector.

Unfortunately, I've been unable to get it to work: my models refuse to change orientation. Specifying different axes to be aligned with an xyz trajectory's velocity vector does not cause the models to have different orientations.

The problem is that Center is a property of the particular type of frame--it should be inside the TwoVector block:

Code: Select all

Modify "vecalignx" "Sol"
{
    BodyFrame {
        TwoVector {
       Center "Sol/vecalignx"
            Primary {
                Axis "x"
                RelativeVelocity { Target "Sol" }
            }
            Secondary {
                Axis "z"
                RelativePosition { Target "Sol" }
            }
        }
    }
}


I found the problem after I noticed that there was a 'No center specified for reference frame' error in the console log. I apologize that there's no good documentation yet. I'm still working on it. I will try and get at least a list of all the properties for reference frames added to the Celestia WikiBook tomorrow.

These are excellent models for illustrating how reference frames work. Can I use them for illustrating my reference frames guide on the wiki?

(Don't be distracted by the fact that the CMOD models' Y axes are aligned with the trajectories' Z direction. This is an issue for another discussion.)

It's a backward compatibility issue . . . If you set the orientation property of a mesh object so that there's 90 degree rotation about the x axis, then the axes will align correctly. I'd like to fix this inside Celestia, but then the orientations of models in existing add-ons would be wrong. One workaround would be to add a version indicator to the ssc file. The parser could check for a comment like '#SSC v2.0' at the head of the SSC file to indicate that the new orientation standard for meshes should be used.

Another thing to point out is that spheres are orientated as expected, with +z through the north pole (north in the rotational not ecliptical sense), +x through prime meridian, and +y through the 90E meridian.

--Chris

[selden]

Chris,

Thanks for pointing out the error!

Yes, you may use those models for your illustrations.

[selden]

Chris,

There's still something strange about vecalignz

The vecalignz model flickers and when I select it and type a y (sync orbit) the distance to it intermittantly is MegaParsecs.

Code: Select all

"vecalignz" "Sol" {
   Class "spacecraft"
   Mesh "vecalignz.cmod"

   Radius 100

   SampledOrbit "vecalignz.xyz"
}

Modify "vecalignz" "Sol" {
   BodyFrame {

       TwoVector {
       Center "Sol/vecalignz"
           Primary {
               Axis "z"
               RelativeVelocity { Target "Sol" }
           }
           Secondary {
               Axis "y"
               RelativePosition { Target "Sol" }
           }
       }
   }
}


[chris]

Chris,

There's still something strange about vecalignz

The vecalignz model flickers and when I select it and type a y (sync orbit) the distance to it intermittantly is MegaParsecs.

That's strange; you shouldn't be seeing flickering, but there is a slight problem with the reference frames. The velocity vector and position vector are nearly parallel--in normal orbital motion, they're closer to perpendicular. I wrote code so that nearly parallel vectors are handled as gracefully as possible, but there may be a bug that causes the flickering.

--Chris

[selden]

I just now tried the corrected SSC on my system at work and it doesn't show the flicker/location problem. It isn't running the most recent CVS version of Celestia, though: i forgot to upload that from home. I also might have made a typo somewhere. I'll double check everything when I get home this evening.