Pointing Hubble

[selden]

Cham,

It's really a very simple model. You can look at it yourself: a few squares, circles and hexagons. It's much less complicated than your Magnetic Earth.

And, of course, it works fine on my Windows system.

I have not tried it with the quaternion orientation file, though.

[Cham]

Maybe it isn't the model itself, but the code ? Or a major bug in the new code of Celestia ?

Also, remember that I've discovered a bug, few weeks (months?) ago, with cmod models and emissivity. It was also hard crashing Celestia. It was my spherical grids without emissivity.

[chris]

The model works for me both with and without the sampled orientation file.

--Chris

[Cham]

I've just redownloaded the addon. I set emissivity to true, and the bug is still there. There's a major bug with this addon. It completelly freeze the video card. I had to restart the computer. Something is really going on here, and the bug trigger as soon as I try to reach Integral. Maybe it's a bug in the driver, but it's seems to be related to Celestia.

It's the same symptoms as the bug I've discovered some times (months?) ago, with my spherical grids cmod model, without emissivity. My spherical grids are working properly if emissivity is set to true, but it crash the video card (?) if emissivity is set to false. Here, Selden's model is crashing Celestia whatever the emissivity (false or true).

[chris]

I've just redownloaded the addon. I set emissivity to true, and the bug is still there. There's a major bug with this addon. It completelly freeze the video card. I had to restart the computer. Something is really going on here, and the bug trigger as soon as I try to reach Integral. Maybe it's a bug in the driver, but it's seems to be related to Celestia.

It's the same symptoms as the bug I've discovered some times (months?) ago, with my spherical grids cmod model, without emissivity. My spherical grids are working properly if emissivity is set to true, but it crash the video card (?) if emissivity is set to false. Here, Selden's model is crashing Celestia whatever the emissivity (false or true).

I think that this problem is specific to the Mac, and it occurs only when the OGL 2.0 path is enabled. However, I'm suprised to see the problem happen even with emissive true.

--Chris

[Cham]

Okay, I just noticed something wrong with Selden's addon :

First, there are two wrong files in his models folder :

a.exe
draw_fov.f

Second : his SSC file calls for an invisible.cmod file which isn't in there. I just deleted the part in the SSC which calls that invisible.cmod file, and the addon works (no crash) but only if emissivity is set to true for the other cmod file (fov.cmod).

If emissivity is set to false, then Celestia crash, but at least, I can quit it.

Selden, check your linked file.

[chris]

Selden and Nicolas,

I found this very useful INTEGRAL targeting schedule:

http://integral.esac.esa.int/isocweb/sc ... eSort=true

I'm using the attitude file that Nicolas provided, and it appears that the pointing is off by 90 degrees in Celestia, probably because of different axis conventions. I made a few changes. First I set the changed the orientation of the INTEGRAL spacecraft. Here's what I'm using now:

Code: Select all

"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

   Orientation [ 90 0 0 1 ]

   SampledOrientation "integral.q"

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


The orientation property changes the attitude of the model but doesn't affect its body-fixed coordinate system--changing the orientation has the same effect as rotating the mesh in a 3D modelling application before saving it to a file.

Next, I adjusted the position and orientation of the fov indicator:

Code: Select all

"integral-fov" "Sol/Earth/INTEGRAL" {
    Mesh "fov.cmod"
    Radius 57.735

    Class "spacecraft"
    FixedPosition   [-100 0 0]
    OrbitFrame { BodyFixed { Center "Sol/Earth/INTEGRAL" } }
    FixedRotation  { }
    BodyFrame { BodyFixed { Center "Sol/Earth/INTEGRAL" } }
    Albedo 1e-32

    Orientation [ 90 0 0 1 ]
}


"integral-pov" "Sol/Earth/INTEGRAL" {
    Class "spacecraft"
    Mesh "invisible.cmod"
    Radius 0.0001
    Color [ 0 0 0 ]

    FixedPosition   [-0.0005 0 0]
    OrbitFrame { BodyFixed { Center "Sol/Earth/INTEGRAL" } }
    FixedRotation  { }
    BodyFrame { BodyFixed { Center "Sol/Earth/INTEGRAL" } }
    Albedo 1e-32

    Orientation [ 90 0 0 1 ]
}


I don't think that the complex TwoVector references frames are necessary. The two definitions above should be adequate to position and orient the FOV indicators (but I may have overlooked something.)

With these modifications, the pointing of INTEGRAL in Celestia is in agreement with the targeting schedule.

--Chris

[selden]

Okay, I just noticed something wrong with Selden's addon :

First, there are two wrong files in his models folder :

a.exe
draw_fov.f

Those files are supposed to be there, although I didn't document them. They're the Fortran program and executable used to create the model.

Second : his SSC file calls for an invisible.cmod file which isn't in there. I just deleted the part in the SSC which calls that invisible.cmod file, and the addon works (no crash) but only if emissivity is set to true for the other cmod file (fov.cmod).

Oops. That's an oversight. Sorry. I must have accidentally deleted it when removing unnecessary files. It's a point model with opacity 0 to provide a location to GoTo. I've found that to work better for me than invisible objects. Still, the Addon doesn't crash on my Windows system.

I've updated the zip file to include the invisible model. I also added a few comments in the cmod model and mention the .f file in the readme.

If emissivity is set to false, then Celestia crash, but at least, I can quit it.

Selden, check your linked file.

[selden]

Chris,

Thanks for the simplification of the Frames!

I used the same constructs as I had used in the pointing_hubble ssc, where I originally had been thinking about orienting things in RA and Dec.

[Vincent]

Selden,
Your pointing_hubble addon is great !
I've added a "Point to target" Button in the Lua Tools, that replaces the "Compass" Window when the reference object is a spacecraft. This is available for every spacecraft that has a pov/fov definition. E.g., for Hubble, the "Point to target" button automatically brings the observer to the "hubble-pov" position, make it track "hubble-fov", and set the FOV to the adapted value. I'll post a link to this updated version soon.

Chris,
Would it be possible to change the target using Lua, without having to edit the .ssc file ?

[chris]

Selden,
Your pointing_hubble addon is great !
I've added a "Point to target" Button in the Lua Tools, that replaces the "Compass" Window when the reference object is a spacecraft. This is available for every spacecraft that has a pov/fov definition. E.g., for Hubble, the "Point to target" button automatically brings the observer to the "hubble-pov" position, make it track "hubble-fov", and set the FOV to the adapted value. I'll post a link to this updated version soon.

Chris,
Would it be possible to change the target using Lua, without having to edit the .ssc file ?

I'm reposting this from the dev list. It's a script that makes Hubble point at the current selection. First of all, here's how you would incorporate it into an ssc file:

Code: Select all

Modify "Hubble" "Sol/Earth"
{
   ScriptedRotation
   {
       Module "orbits"
       Function "aim"

       Observer "Sol/Earth/Hubble"
   }
}


And here's the script itself:

Code: Select all

aimproto =
{
   Observer = ""
}

function aimproto:new(o)
  o = o or {}  -- create table if one not provided
  setmetatable(o, self)
  self.__index = self

  self.obs = nil
  self.axis = celestia:newvector(0, 0, -1)
  return o
end

function aimproto:orientation(tjd)
  if (not self.obs) then
     self.obs = celestia:find(self.Observer)
  end

  local target = celestia:getselection()
  local v = target:getposition(tjd) - self.obs:getposition(tjd)

  if (v:length() > 0) then
     v = v:normalize()
     local n = v ^ self.axis
     if (n:length() < 1e-6) then
        -- Handle the case where the pointing vector and axis are parallel
        return 1, 0, 0, 0
     else
        n = n:normalize()
        local angle = math.acos(self.axis * v)

        -- Convert the axis-angle rotation to a quaternion
        local s = math.sin(angle / 2)
        local c = math.cos(angle / 2)
        return c, s * n.x, s * n.y, s * n.z
     end
  else
     -- Handle the case where the pointing vector is zero
     return 1, 0, 0, 0
  end
end

function aim(sscvals)
  return aimproto:new(sscvals)
end


To actually use this, you need to copy the script into a file called
'orbits.lua' (since 'orbits' is the name of the Module specified in
the ssc file) and place it in one of the standard locations that Lua
searches for packages. Although I plan to change this requirement,
scripted orbits and rotations currently rely on the LuaHook being
enabled, so make sure that you've enabled it in celestia.cfg. And
finally, scripted rotations are always cached, so the clock needs to
be running in order for the orientation to be updated when you change
the selection.

--Chris

[Vincent]

Chris,

Thanks a lot, the script seems to work since Hubble's orientation indeed changes everytime a new object is selected. However, there seems to be an offset since Hubble doesn't point to the selection...

[Vincent]

However, there seems to be an offset since Hubble doesn't point to the selection...

Selden, Chris,

Do you also have this offset between Hubble's orientation and the selection, or is Hubble correctly pointing to the selection on your systems ?

[selden]

Vincent,

I've been working on other projects and haven't had a chance to try any of Chris' suggestions.

I'm pretty sure the problem is related to the inherent orientation of the model with respect to Celestia's axes.

My addon uses a TwoVector BodyFrame with the axes carefully chosen to force the existing model into the correct orientation. I don't see anything in Chris' code to set the initlal orientation, so it'll be rotating relative to the model's default orientation.

I think (but I'm not sure) that if you were to include the BodyFrame definition from one of my Addons it would define the axes correctly so that the Rotations will be in the correct directions.

[Vincent]

Selden,

I also think that the problem must be related to the default orientation of Hubble's model. Unfortunately, adding your BodyFrame definition to Chris' ScriptedRotation definition doesn't affect the spacecraft's orientation, and thus, doesn't solve the problem...

[chris]

I think the problem is that I'm using the pointing script with the huge Hubble model from the add-on that I think is called BigHubble. It's probable that model is oriented differently than the one that comes with the base Celestia package. I'll see what needs to be done to correct the orientation.

--Chris

[selden]

Unfortunately, the field of view of a detector might not be aligned with any of the axes defined for an observational platform and the orientation of the platform's model might not be aligned with the axes of either of them.

I think it might be adequate to be able to specify which of the 6 axis directions of the model (+/-x, +/-y, +/-z) the script should orient toward the direction of observation. (Is that what the "self axis" is supposed to be?) It would be very useful to have the full generality of the Frame TwoVector constructs available to the script, since one also needs to specify the platform's roll angle.

An example of a somewhat complicated situation is that of the Spitzer Space Telescope. It must keep one side always toward the Sun to ensure the sensors are protected by its sunshade. In other words, if Y is the axis pointing toward the target, the Sun must always be in the telescope's XY plane with +X values. The observer has no control over this. Of course, it would be nice if this could be enforced in Celestia.

[produit]

Hi,

I have tried the INTEGRAL FOV add on.
It work great.

Chris post suggest to turn the model by 90 degree.
I did not had to do that.
I think the reason is that I use:
Mesh "integral.cmod" # warning: 5MB
Perhaps this model has other definition of axes
then the model that Chris use.

For example if you set time around:
01/25/2006 02:00:00
we used INTEGRAL to observe the Earth (this is something
very special for INTEGRAL and in fact something
that was forbidden by platform specifications)
The FOV is correctly placed on top of Earth.
The FOV is also correctly placed with respect to INTEGRAL.

[Vincent]

Chris,

I've just noticed a significant FPS drop that seems to be linked to the ScriptedRotation definition :
- When I go to 'hubble-fov' with the following .ssc, my FPS goes down to ~0.75. This happens even when the Lua Tools are not running.

Code: Select all

Modify "Hubble" "Sol/Earth"
{
   ScriptedRotation
   {
       Module "orbits"
       Function "aim"

       Observer "Sol/Earth/Hubble"
   }
}


"hubble-fov" "Sol/Earth/Hubble" {
   Class "spacecraft"
   Mesh "fovfix.cmod"
   Radius 0.5
   Emissive true

   FixedPosition   [0 0 100]
   OrbitFrame { BodyFixed { Center "Sol/Earth/Hubble" } }
   Albedo 1e-32
}

- Then, if I remove the ScriptedRotation definition for Hubble, my FPS stays at a reasonable value of ~25.

Code: Select all

"hubble-fov" "Sol/Earth/Hubble" {
   Class "spacecraft"
   Mesh "fovfix.cmod"
   Radius 0.5
   Emissive true

   FixedPosition   [0 0 100]
   OrbitFrame { BodyFixed { Center "Sol/Earth/Hubble" } }
   Albedo 1e-32
}

This FPS drop only occures when I go to 'hubble-fov', i.e., it doesn't when I go to Hubble itself...

[chris]

Chris,

I've just noticed a significant FPS drop that seems to be linked to the ScriptedRotation definition :
- When I go to 'hubble-fov' with the following .ssc, my FPS goes down to ~0.75. This happens even when the Lua Tools are not running.

I found this bug last night; the orientation computed by the script isn't getting cached. I will commit the one-line fix to scriptrotation.cpp tonight.

--Chris