Correct orientation of satellites

[granthutchison]

Hi.
I'm new to this forum and new to Celestia: please forgive me if what I'm about to say has either already been discussed or is about to be addressed in the next release. I have searched the forum on a few plausible search words without turning up anything relevant.

I noticed that the orientation of some natural satellites generated from solarsys.ssc was wrong: specifically, those defined without custom orbits - Phobos, Diemos, Amalthea and Proteus. After a bit of messing about with the file, I think I've worked out that these satellites are generated in the correct orientation (with the zero meridian pointing at the centre of the parent planet), at some standard zero position in orbit. But the addition of a random mean anomaly for display purposes then moves them around their orbits without altering their absolute orientation, so that the zero meridian ends up misaligned. This can be corrected by adding a RotationOffset term that is equal to the MeanAnomaly. (Effectively rotating the satellite back into its correct position.)
However, putting in real-world values for ArgOfPericenter and AscendingNode messes this up again. The AscendingNode problem is fixed by using a solution already posted by Matt McIrvin: set Obliquity to equal Inclination, and LongOfRotationAxis to equal AscendingNode. This yanks the satellite around into the correct position at the ascending node. The ArgOfPericenter problem is fixed by setting RotationOffset equal to MeanAnomaly+ArgOfPericenter.
Finally, things go awry again if an epoch other than the default J2000.0 epoch is used - we have to compensate for the partial rotations the satellite achieves between the entered epoch and the default epoch. In degrees, this is equal to 360*FRAC{(2451545-Epoch)/Period}, where FRAC indicates the fractional part (the figures right of the decimal point).
So the general solution to keeping satellites aligned correctly is:

RotationOffset = MeanAnomaly+ArgOfPericenter+[360*FRAC{(2451545-Epoch)/Period}]

This assumes that you have made Matt McIrvin's correction for the AscendingNode. If you have not, you should add AscendingNode to the above formula.
Any reorientation for artificial satellite models should then be added to that sum.
If either MeanAnomaly or ArgOfPericenter is not entered, then they should be set to zero. If no Epoch is given, then the epoch term should be set to zero.
I've tested this on the solarsys.ssc file, and have confirmed that this formula preserves correct satellite orientations. It also makes sense in terms of the way the various terms work to define an orbit, and my guesses about how Celestia works. But if anyone sees a flaw in the argument, please put me right!

Grant

[chris]

I'd never checked to the orientations of any of the satellites . . . I'm glad to heard that at least the larger satellites are oriented correctly.

I will eventually add custom orbits for all of the moons in the solar system; until that time, your adjustments are a good way to put things in order.

I recently changed LongOfRotationAxis to EquatorAscendingNode, since that's what was really mean all along. The actual longitude of the rotation axis is 90 degrees less than the equatorial ascending node.

--Chris

[granthutchison]

I'd never checked to the orientations of any of the satellites . . . I'm glad to heard that at least the larger satellites are oriented correctly.

Oops, what I wrote was misleading. I haven't checked the CustomOrbit moons at all systematically, since I wasn't sure how I could glean the relevant information to orientate them precisely. I just zeroed in on the ones without custom orbits, because I could vary their parameters at will and see what happened. So my "specifically" was intended to say that I was going to discuss specifically that type of moon, not that I'd checked the others and they were OK.

Did you, by the way, receive my e-mail about the shape model for Phobos? It is mirrored north-south, as is its texture map. Deimos, Proteus and Amalthea shapes are OK, I think, but the texture map for Deimos seems to be mirrored north-south, too.

Grant

[granthutchison]

I'd never checked to the orientations of any of the satellites . . . I'm glad to heard that at least the larger satellites are oriented correctly.

OK, I've had a look at the Galileans, and they aren't orientated correctly either. My formula doesn't seem to work with the quoted parameters for their custom orbits. But the necessary RotationOffsets (by Mark I Eyeball) are as follows:

Io 20
Europa 225
Ganymede 225
Callisto 50

I recently changed LongOfRotationAxis to EquatorAscendingNode, since that's what was really mean all along. The actual longitude of the rotation axis is 90 degrees less than the equatorial ascending node.

Makes sense - I noticed the discussion on this topic on the original thread. Is that in 1.2.5? It doesn't seem to work in 1.2.4.

For anyone who's interested, here are the definitions I've worked up for Phobos, Deimos, Amalthea and Proteus, using data from the JPL website:

Code: Select all

"Phobos" "Sol/Mars"
{
   Mesh "phobos.3ds"
   Texture "phobos.jpg"
   # BumpMap "phobosbump.jpg"
   # BumpHeight 5
   Radius 11

   EllipticalOrbit
   {
   Period         0.318910
   SemiMajorAxis  9377.2
   Inclination    1.075
   Eccentricity   0.0151
   AscendingNode  164.931
   ArgOfPericenter 150.247
   MeanAnomaly    92.474
   Epoch          2433282.5  #1950 Jan 1.00
   }

   Obliquity      1.075    #= Inclination
   LongOfRotationAxis 164.931   # = AscendingNode
   RotationOffset 16.886  # = MeanAnomaly+ArgOfPericenter+[360*FRAC({2451545-Epoch}/Period)]

   Albedo         0.07
}

"Deimos" "Sol/Mars"
{
   Mesh "deimos.3ds"
   Texture "deimos.jpg"
   Radius 6

   EllipticalOrbit
   {
   Period         1.262441
   SemiMajorAxis  23463.2
   Eccentricity   0.00033
   Inclination    1.793
   AscendingNode 339.600
   ArgOfPericenter 290.496
   MeanAnomaly   296.230
   Epoch          2433282.5  #1950 Jan 1.00
   }

   Obliquity      1.793  # = Inclination
   LongOfRotationAxis 339.600  # = Ascending Node
   RotationOffset 234.851  # = MeanAnomaly+ArgOfPericenter+[360*FRAC({2451545-Epoch}/Period)]
   
   Albedo         0.08
}

#...

"Amalthea" "Sol/Jupiter"
{
   Texture "asteroid.jpg"
   BlendTexture true
   Color   [ 0.5 0.12 0.16 ]
   Mesh "amalthea.3ds"
   Radius    124

   EllipticalOrbit
   {
   Period          0.498179
   SemiMajorAxis   181300
   Eccentricity    0.0031
   Inclination     0.388
   AscendingNode   112.472
   ArgOfPericenter 147.025
   MeanAnomaly     190.516
   Epoch   2450464.5  #1997 Jan 16.00
   }

   Obliquity   0.388  # = Inclination
   LongOfRotationAxis 112.472  # = AscendingNode
   RotationOffset   301.228  # = MeanAnomaly+ArgOfPericenter+[360*FRAC({2451545-Epoch}/Period)]
   
   Albedo          0.06
}

#...

"Proteus" "Sol/Neptune"
{
   Mesh "proteus.3ds"
   Texture "asteroid.jpg"
   Radius   218

   EllipticalOrbit
   {
   Period         1.122315
   SemiMajorAxis  117647
   Eccentricity   0.0004
   Inclination    0.039
   AscendingNode  150.334
   ArgOfPericenter 309.480
   MeanAnomaly    114.186
   Epoch   2447757  # 1989 Aug 18.50
   }

   Obliquity      0.039  # = Inclination
   LongOfRotationAxis 150.334  # = AscendingNode
   RotationOffset 123.609 # = MeanAnomaly+ArgOfPericenter+[360*FRAC({2451545-Epoch}/Period)]

   Albedo         0.2
}


I'll check the orientation of the other moons and report back.

Grant

[selden]

Grant,

What are your sources for the orientations of the satellites?
Direct observation?
JPL's Horizons service?
Some other ephemerides? What ones?

I'm just curious: I've found that Horizons sometimes has some bad information in it. (The orbit of the INTEGRAL gamma ray telescope, for example, is way off from what's described on Integral's Web site at http://astro.estec.esa.nl/SA-general/Projects/Integral/status_results.html

[granthutchison]

What are your sources for the orientations of the satellites?

The convention for mapping of synchronous natural satellites is to have the zero meridian pointing at the centre of the parent body. (There is obviously some averaging process here for eccentric orbits.) Phil Stooke's shape models use the same convention.
So for the shape models of Phobos, Deimos, Amalthea and Proteus, I'm making reference to Phil Stooke's shape models (I've generated these myself in POVray, so I know the data even though I can't access the 3DS files directly). For the other satellites (and as a cross-check on Phobos and Deimos), I'm using published maps - mainly the NASA Atlas of the Solar System.
It's easy enough to check the approximate apparent longitude of mapped features in Celestia's satellites by:
1) Going to the parent body and then looking at the satellite (zero meridian).
2) Going to the satellite and moving around it until it aligns with the centre of the parent body (180 meridian).
3) Orientating north or south of the satellite and checking which features align with the marked line of orbit (90 and 270 meridians).

At present I'm trying to refine this by laying on a texture with marked, numbered grid lines, so that I can just read off the necessary RotationOffset, but I'm struggling to get Celestia to accept my texture jpeg, for some reason.

Grant

[selden]

OK. I think I understand. Presumably you're taking libration into account. (the averaging you mention?)

Also, in case you hadn't realized, Celestia requires the surface texture images be a powr of two in their dimensions. e.g. 1024x512. Most published surface maps are not and have to be scaled. (POV-Ray doesn't have that restriction.)

I hope this helps.

[granthutchison]

OK. I think I understand. Presumably you're taking libration into account. (the averaging you mention?)

I presume the cartographers calculate a mean meridian and then either choose a surface feature or a specific epoch to define their zero.
Me, I'm taking this into account to the extent that eyeball correction of the orientation of the CustomOrbit satellites is never going to be better than five degrees or so - for reasonably circular orbits I think this error will be considerably greater than any error created by the state of libration of the satellite at the moment I eyeball it. (I've just this minute run a check on that, by following Io around its orbit with my grid texture pasted on to it, and the libration does seem to be relatively trivial compared to my eyeball error. Obviously I need to check that again when I come to more eccentric satellites.)
For objects without CustomOrbits, my situation is more precise. Celestia generates these in an orientation I can recover from the orbit definition, and therefore correct exactly with the formula above. With CustomOrbits there's more going on somewhere I can't access/understand, so at present I'm having to just look at the final result and insert a jigger factor.

Also, in case you hadn't realized, Celestia requires the surface texture images be a powr of two in their dimensions. e.g. 1024x512.

This is exactly what was going wrong with my custom jpeg grid - between my last post and your reply I manage to figure that one out (only just!), but thanks indeed for coming to my aid. I'm going to lay the grid on to the remaining CustomOrbit satellites, and come back with list of RotationOffsets that should dramatically tighten up their orientations, even if it isn't perfect.

Grant

[selden]

Grant,

Thanks a lot for all the effort you're investing in this. We'll all appreciate knowing that the additional accuracy is present. I'm rashly assuming you'll make the modified solarsys.ssc available for Chris to include with Celestia.

If you could make your planetary grid available, too, I suspect some other folks would find it useful. Someone else created one not too long ago, but it's probably somewhat different from what you're using. Of course I can't find the posting now, so I can't give it the correct attribution

Thanks, again.

[granthutchison]

I'm rashly assuming you'll make the modified solarsys.ssc available for Chris to include with Celestia.

Sure, if he wants it.

If you could make your planetary grid available, too, I suspect some other folks would find it useful.

Very happy to do so -but it's just a jpeg file with labelled meridians at 30 degree intervals.
However, I don't have a website to post it on with a linking URL here. Is there somewhere else I should upload it?

Grant

[selden]

Grant,

Chris has been known to make space available on http://www.shatters.net for contributions to Celestia: Rassilon and Fridger both have Web pages there.

Alternatively, I could put a few small files on the server I use, if you can e'mail them to me. (Web and e'mail links are below)

[granthutchison]

Right, I've finally worked out what's going wrong with Phobos.
The shape model is in fact correctly orientated, but when I lay my gridded texture map on to it, I find that the map is effectively turned inside-out: as if instead of pasting straight on to the surface of the model, each bit of map had passed right through the centre of the model and pasted itself on to the inside of the opposite surface. So that when I look at my gridded Phobos from Mars I don't see the zero meridian facing me - I see the 180 degree meridian, with its label upside down and mirrored.
This effect is partially offset by the fact that the Celestia Phobos texture map is 180 degrees out of longitude alignment with the shape model - the turning-inside-out process brings each line of longitude of this misaligned map back to where it should have been originally, although still reversed north for south. (Phew! No wonder it took so long to figure out.)
As a temporary fix, I've greated a texture called "phobosmirror.jpg", simply by reflecting the original Celestia map north and south in an image editor. This drapes on to the Phobos shape model beautifully, and the craters in the northern and southern hemispheres now look round, and are laid over appropriate dents in the shape model.
The problem is present in all the other *.3ds models I've looked at (Diemos, Amalthea, Proteus, Hyperion), but not in the *.cms models for Phoebe and Nereid. Since Amalthea, Proteus and Hyperion have random textures applied, the texture error just introduces a bit of variety. But Diemos also needs a "diemosmirror.jpg" created - which again improves the appearance dramatically, with areas of high relief now clearly marked by paler terrain.

Grant

[granthutchison]

For those who are interested, Selden has kindly (and stunningly quickly) built a web page containing my reflected Phobos and Deimos textures, as well as my (roughly labelled) lat/long grid.

Grant

[granthutchison]

Another parameter I hadn't previously considered is the edge longitude of the maps used by Celestia. Some of these start with zero degrees at the edge, some with 180 degrees, and there are a selection of oddballs - like Callisto, which has 30W at the edge.
This is relevant in two ways:
1) An extra jigger factor must be added to RotationOffset if the Celestia map has an edge meridian other than the prime meridian. (At present I'm getting the spherical satellites correctly orientated as if the prime meridian were the edge meridian, and then subtracting the value of the true edge meridian (in degrees west) from the RotationOffset - this spins the satellite until the map is correctly registered.)
2) Any texture map changes may affect the orientation of the satellite, if the edge meridians are different - the RotationOffset would require editing to fix the orientation.

All this added an extra disorientation to setting up Triton correctly.
Triton's already difficult because of its retrograde motion, meaning that 180 degrees must be added or subtracted here and there to keep things straight, then a final 180-degree twist added to centre the map over the prime meridian.
I've set Triton's rotation axis perpendicular to its orbit, in the absence of any other information. Orbit data from the 1.2.5 solarsys.ssc, which provides more detail for Triton.

Code: Select all

"Triton" "Sol/Neptune"
{
   Texture "triton.jpg"
   Radius   1353

   Atmosphere {
      Height 1
      Lower [ 0.5 0.5 0.5 ]
      Upper [ 0.5 0.5 0.5 ]
      Sky [ 0.0 0.0 0.0 ]
   }

   EllipticalOrbit
   {
   Epoch          2452583.763194445
   Period         5.877099455
   SemiMajorAxis  354767.045
   Eccentricity   0.000036128
   Inclination    156.825624
   AscendingNode   179.3321840
   ArgOfPericenter 340.33983157
   MeanAnomaly     351.5204821
   }

   Obliquity      23.174  # = 180-Inclination
   EquatorAscendingNode 359.332 # = 180+AscendingNode
   RotationOffset -62.726 # = 180-MeanAnomaly-ArgOfPericenter-[360*FRAC({2451545-Epoch}/Period)]-edge meridian
                #for map with 180?W edge meridian
 
   RotationPeriod -141.05038692 # = Period*-24

   Albedo         0.7
}


And here are the new parameters for Amalthea, calculated from the new epoch data used for the Galileo encounter in 1.2.5.

Code: Select all

"Amalthea" "Sol/Jupiter"
{
   Texture "asteroid.jpg"
   BlendTexture true
   Color   [ 0.5 0.12 0.16 ]
   Mesh "amalthea.3ds"
   Radius    124

   EllipticalOrbit
   {
   Epoch      2452583.763194445
   Period          0.501637511
   SemiMajorAxis   181994.98
   Eccentricity    0.0046637841
   Inclination     0.39217201
   AscendingNode  203.9604966
   ArgOfPericenter 293.4707817
   MeanAnomaly     319.3794140
   }
   
   Obliquity   0.392
   EquatorAscendingNode 203.960
   RotationOffset   344.914 # = MeanAnomaly+ArgOfPericenter+[360*FRAC({2451545-Epoch}/Period)]

   Albedo          0.06
}


[HankR]

The U.S. Naval Observatory's "Explanatory Supplement to the Astronomical Almanac" (1992 edition) gives the rotation of various solar system objects in terms of their "cartographic coordinates", consisting of the orientation of the north pole and the position of the prime meridian of an object with respect to an inertial reference frame. Specifically, these elements are given by three variables: a0, d0, and W, as functions of time.

a0 and d0 are the right ascension and declination of date (i.e. at a given time) of the object's north pole. (The "north" pole, as defined by the International Astronomical Union, is the rotation axis on the north side of the invariable plane of the solar system.)

W is the angle, measured along the the object's equator in a counter-clockwise direction when viewed from the north pole, from the ascending node of the object's equator on the Earth's mean equator of J2000.0 to the point where the prime meridian of the object crosses its equator. (Note that the right ascension of the node is at 6h+a0, and the inclination of the object's equator to the standard equator is 90-d0.)

In the expressions given for these variables, time is specified in two ways: T is the time from J2000.0 (JD 2452545.0 TDB) in Julian centuries (36525 days), and t is the time from J2000.0 in days (86400 SI seconds).

As an example, for Triton:

W = 296.53 - 61.2572637*t + 22.25*sin(N7) + 6.73*sin(2*N7) + 2.05*sin(3*N7) + [6 more terms]

where

N7 = 177.85+52.316*T

Similar expressions are given for a0 and d0.

Would this kind of information be useful?

- Hank

[HankR]

The U.S. Naval Observatory's "Explanatory Supplement to the Astronomical Almanac" (1992 edition) gives the ...

Ah. I actually have this sitting on a shelf next to me as I type, but hadn't thought to open it.
I can certainly work out a pole position for the epoch of the orbit defined in Celestia, and see how this relates to the orbital "pole" for the same epoch.
There might be a long silence while I work on the trig ...

Grant

[granthutchison]

OK, here are the eyeballed corrections (correct to around 5 degrees, I estimate) to get the major synchronously rotating planetary moons with CustomOrbits orientated correctly in Celestia. (I've already covered the ones with non-custom orbits.)
Since the correct orientation depends on the edge meridian of the texture map used, I've also noted the edge meridian of the maps provided with Celestia - if you're changing to another map, you'll need to check and correct for any difference in edge meridian.

Io
RotationOffset 20 #map has 0?W edge meridian

Europa
RotationOffset 230 #map has 0?W edge meridian

Ganymede
RotationOffset 220 #map has 0?W edge meridian

Callisto
RotationOffset 50 #map has 30?W edge meridian



Mimas
RotationOffset 320 #map has 180?W edge meridian

Enceladus
RotationOffset 320 #(no map with Celestia - calculated for map with 180?W edge meridian)

Tethys
RotationOffset 325 #map has 180?W edge meridian

Dione
RotationOffset 320 #map has 180?W edge meridian

Rhea
RotationOffset 190 #map has 180?W edge meridian

Titan
RotationOffset 175 #(in anticipation of a surface map with 180?W edge meridian)

Iapetus
RotationOffset 230 #map has 180?W edge meridian



Miranda
RotationPeriod 33.912 #required to correct rotation bug in Celestia
RotationOffset 330 #map has 90?W edge meridian

Ariel
RotationOffset 230 #map has 180?W edge meridian

Umbriel
RotationOffset 260 #map has 180?W edge meridian

Titania
RotationOffset 280 #map has 180?W edge meridian

Oberon
RotationOffset 0 #map has 180?W edge meridian

The most noticeable changes are that the large crater Herschel is now correctly orientated on Mimas, and Iapetus's leading hemisphere is now appropriately the dark one.

Grant

[selden]

Grant,

Thanks a lot for taking the time to do all the careful work this required. Many of us greatly appreciate it.

Unfortunately, it turns out that at least one of the major planets has similar difficulties: I just determined that the map of Mars is off by at least 180 degrees compared to solarsys.ssc. I haven't checked it to more accuracy than that, and I haven't checked Mercury or Venus, either.

[granthutchison]

Unfortunately, it turns out that at least one of the major planets has similar difficulties: I just determined that the map of Mars is off by at least 180 degrees compared to solarsys.ssc.

Yes, Mars has major problems. In addition to the misalignment of the RotationOffset, its axial inclination is off by a few degrees, and there's a 180 degree error in the EquatorAscendingNode.
From the standard J2000.0 parameters for the Martian north pole and prime meridian, I calculate the following:

Code: Select all

   RotationPeriod    24.622962
   RotationOffset -43.995

   Obliquity   26.72
   EquatorAscendingNode 82.91


This gets Mars into nice agreement with various lists of central meridians.
You can check that my change of Obliquity and EquatorAscendingNode are appropriate by skating around to the south pole of Mars with the celestial grid on, and pulling back so you can eyeball the direction of the axis of rotation: it should be pointing at 53 degrees north, 21.2h right ascension. (Compare this with the direction generated by Celestia, which is in another part of the sky entirely.)

Grant

[selden]

Grant,

When you write

there's a 180 degree error in the EquatorAscendingNode.

Does that imply that the current maps would be correctly alighed if the EAN were corrected?