Orientation of spacecrafts [feature request]

[Cham]

There's an important option missing in Celestia, about models orientation.

Suppose you set a probe on a simple or complex path (elliptical orbit, custom path, etc...). It could be very usefull to set the probe's orientation always fixed relative to another object, defined in the SSC file. For example, Voyager2 probe with its dish antenna always oriented in the direction of the Earth, whatever the probe position and velocity. Or another probe with its solar panels always oriented towards the Sun.

We could implement this with a special command added to the probe's SSC file, something like this :

OrientationRef "Earth"

It could be interesting to use that command with another moving spacecraft as reference.

Any opinion about this idea ?

[ElChristou]

Yep, agree, I was thinking in this during the Voyager and Pioneer modeling...
It could be a nice feature...

[rthorvald]

There's an important option missing in Celestia, about models orientation [...]. For example, Voyager2 probe with its dish antenna always oriented in the direction of the Earth

Any opinion about this idea ?

I think it would be very useful. But if it is too complex to design in, or falls outside of what the devs are interested in, one can achieve just about the same thing if it was possible to specify variation in the rotational speed of an object.
Of course, the calculations for the SSC files could then quickly become nightmarish...

- rthorvald

[chris]

There's an important option missing in Celestia, about models orientation [...]. For example, Voyager2 probe with its dish antenna always oriented in the direction of the Earth

Any opinion about this idea ?

I think it would be very useful. But if it is too complex to design in, or falls outside of what the devs are interested in, one can achieve just about the same thing if it was possible to specify variation in the rotational speed of an object.
Of course, the calculations for the SSC files could then quickly become nightmarish...

What I'd like to do is implement something akin to SampledOrbits for orientation. RocketMan@JSC has implemented rvq files that contain a sequence of orientations in addition to as positions. What may be more useful is to store the axes of rotation at different point in time instead of actual orientations . . . The right approach is probably whatever NASA's SPICE toolkit is doing.

--Chris

[t00fri]

The right approach is probably whatever NASA's SPICE toolkit is doing.

--Chris

Absolutely!

Bye Fridger

[hank]

What I'd like to do is implement something akin to SampledOrbits for orientation. RocketMan@JSC has implemented rvq files that contain a sequence of orientations in addition to as positions. What may be more useful is to store the axes of rotation at different point in time instead of actual orientations . . . The right approach is probably whatever NASA's SPICE toolkit is doing.

--Chris

If Celestia simply allowed the location and orientation for an object to be defined by Lua functions, it would be possible to experiment with many possible approaches.

- Hank

[Cham]

Then what about periodic motion ? I mean, if there's only a point wise orientation like the sampled orbit (if I understand it correctly), it wont work for an arbitrary moment of time, but only for the sampled points.

And what about the animation between two sampled points ? Will the model change its orientation abruptly, or in a smooth way ? At what angular velocity ?

The command I suggested - OrientationRef - (or whatever) would be very easy to set in the SSC file. Of course, the model should change its orientation continuously, in a very smooth way.

[tec]

You can check out the RealTime Celestia. It already has the orientation implemented (among other nice features) using quaternians. You will have to convince the developers to integrate these features in the CVS if you want them in the next release.

http://www.knology.net/~tec/

Tim

[RocketMan@JSC]

What I'd like to do is implement something akin to SampledOrbits for orientation. RocketMan@JSC has implemented rvq files that contain a sequence of orientations in addition to as positions. What may be more useful is to store the axes of rotation at different point in time instead of actual orientations . . . The right approach is probably whatever NASA's SPICE toolkit is doing.

--Chris

I would agree about using SPICE to support all of our spacecraft ephemeris needs. It probably would not be that hard to implement into Celestia. We added it to a 6-dof sim and for planetary position and it was pretty easy. Also, it seems many people are interested in both the manned and unmanned space vehicle missions. Much of the data for the unmanned missions are available via JPL and the SPICE toolkit. I'm hoping the manned missions jump on board and start using it but thus far it has been spotty. Constellation will likely bring about a need for consolidation of this type of information for the public. We even have built a python interface that allows use of many features via python.

As a second benefit, the planetary bodies could also be driven via SPICE if the user desires--and accepts a small performance penalty.

Let me first clarify this rant. This is free open source software so I have little room to complain--much to the contrary--it's a great piece of software. Now for a hopefully short [rant] I've found the interfacing of standard orientations with Celestia very difficult. Perhaps it's just the lack of documentation (for orientation)--however, I am positive the Orientation option in the ssc format has one negative rotation. Take any model and throw a positive 90 deg rotation about each of the axes (one at a time)--no matter what you do the resulting frame will not be right handed. I have figured out how to make it right but, I do not like it. The LUA orientation stuff is a whole separate rant.[/rant]

Finish off with some good news--looks like Celestia is starting to gain a little momentum at JSC. Tomorrow I'll post some cool shuttle/tank pics and talk about this some more.

Scott

p.s. I just used tec's stuff and made changes to suit our needs.

[produit]

Hi,
as explained in:
http://www.celestiaproject.net/forum/viewtopic ... highlight=
I want to have correct attitude for INTEGRAL spacecraft in celestia.
In this case attitude is very irregular (change every 20 minutes)
but orbit is very stable.
This is the case for all telescope in space (hubble, chandra, XMM...)
So I think it will be good if we could have a way of loading information
in celestia separately for the orbit and for the attitude.
The .xyzw format will work for my case but it is an overkill,
I think a format with
just the quaternion versus time will be better in this case.

I am supportive of the idea of real time capabilities in celestia. In my case it will permit to integrate celestia in our
operation room.
I can also imagine providing as a service to the community a
server that will send INTEGRAL attitude in real time (using UDP
packet or anything else).
In fact we already do that for people that are interested in
GRB burst to enable their telecope to follow the same field of view
then INTEGRAL.

[Apollonian]

Hello everyone. I have been following this discussion for a few months now. I am very interested in looking at attitude in Celestia, especially since my master's thesis will now encompass attitude constraints.

I also have the opportunity to take an OpenGL graphics class this semester! So, I now have hope of finding a meaningful translation between the orientations/conventions used in OpenGL and the orientations/conventions used in Astrodynamics. That said, time and money are still hard constraints.

Still, can anyone point me to the place in the code base where the SSC files are actually rendered?

Also, I seem to recall (but missed) a discussion about someone having implemented a xyzq format reader. Can someone point me to this? Is this (will this be) included in the current repository code-base?

Thanks

[selden]

Richard,

Chris is right in the middle of updating Celestia to support spacecraft attitudes, including support for the relevant SPICE kernels.

He's made postings about this to the development mailing list and here on the forum. Copies of his descriptions of the changes that have happened so far are available at
http://www.lepp.cornell.edu/~seb/celest ... s.html#5.4

[chris]

Hello everyone. I have been following this discussion for a few months now. I am very interested in looking at attitude in Celestia, especially since my master's thesis will now encompass attitude constraints.

I also have the opportunity to take an OpenGL graphics class this semester! So, I now have hope of finding a meaningful translation between the orientations/conventions used in OpenGL and the orientations/conventions used in Astrodynamics. That said, time and money are still hard constraints.

Still, can anyone point me to the place in the code base where the SSC files are actually rendered?

Also, I seem to recall (but missed) a discussion about someone having implemented a xyzq format reader. Can someone point me to this? Is this (will this be) included in the current repository code-base?

There's not a single place in the code where ssc files are rendered. The closest thing are probably the files render.cpp, lodspheremesh.cpp, and rendercontext.cpp. Feel free to PM with any specific questions though.

You may be interested in the discussion about rotations in this thread: http://www.celestiaproject.net/forum/viewtopic.php?t=10291

I've checked in some new code that allows much more flexibility in how rotations are specified. This new rotation code doesn't suffer from the idiosyncrasies that caused headaches for people trying to deal with the ssc Orientation field.

--Chris

[RocketMan@JSC]

I am positive the Orientation option in the ssc format has one negative rotation. Take any model and throw a positive 90 deg rotation about each of the axes (one at a time)--no matter what you do the resulting frame will not be right handed.

Chris,

Could you shed any light on why this occurs?

Also, in my implementation, I used the Orientation feature in the ssc along with the xzyq file to provide a graphic model offset. This is useful since not all models are created with the body axes in the correct location. So it may be good to keep that in strictly for graphic correction.

Tomorrow I'll try and post a few code snippets to show you what I mean.

Scott

[chris]

I am positive the Orientation option in the ssc format has one negative rotation. Take any model and throw a positive 90 deg rotation about each of the axes (one at a time)--no matter what you do the resulting frame will not be right handed.

Chris,

Could you shed any light on why this occurs?

Also, in my implementation, I used the Orientation feature in the ssc along with the xzyq file to provide a graphic model offset. This is useful since not all models are created with the body axes in the correct location. So it may be good to keep that in strictly for graphic correction.

Tomorrow I'll try and post a few code snippets to show you what I mean.

The Orientation field isn't going away, but I would like to find a way to make it work in a more standard way. The frustrations that you voiced about it were a big reason that I was much more careful with the implementation of orientation files.

Celestia uses a nonstandard coordinate system, mostly for 'historical' reasons. The y axis is normal to the ecliptic, the axis is the vernal equinox, and the z axis completes the right handed system. The net result is that you have to convert from the standard J2000 ecliptic reference frame to Celestia's internal coordinate system by rotating 90 degrees about the x axis.

I'm away from my dev machine now, but I'll post the transformation code tomorrow (or you can check out the code on SourceForge--see the LoadSampledOrientation() function in src/celengine/samporient.cpp. The 90 degree rotation is applied to the samples as their read, so that the creator of the orientation file never has to know about Celestia's coordinate system. I will eventually getting around to fixing Celestia to use the J2000 ecliptic reference frame internally, but that's a post 1.5.0 project.

I would appreciate any comments you might have to offer about how orientation should be handled in Celestia.

--Chris