realtime interface to Celestia

[tec]

I don't know what you mean by a patch. Can you explain and I will conform to it.

My latest version of the RealTime Celestia 2.0 has several of the coding conventions fixed. I went through the coding conventions document and changed the things it suggested. Let me know if there any other coding conventions I missed.

Tim

[t00fri]

I don't know what you mean by a patch. Can you explain and I will conform to it.

My latest version of the RealTime Celestia 2.0 has several of the coding conventions fixed. I went through the coding conventions document and changed the things it suggested. Let me know if there any other coding conventions I missed.

Tim

A patch is generated by appropriate develoment software. The patch contains the code /differences/ in some standardized ascii format relative to some reference code, like e.g. the official Celestia distribution in your case.

Under Linux/Unix there is a a pair of classical tools: diff and patch
that do this job perfectly. The diff command line program accepts some options. 'patch' is the complement application to diff. Given the patch file (generated by diff), patch merges the patch file into the reference distribution on some other machine. This way one may generate the new code over some network by transferring the small patch file containing just the differences.

There are corresponding program pairs for any OS, the names of which you might get in the net.

Under Windows I conveniently use diff and patch of CYGWIN (Linux) which you sure know. So the familiar procedure remains the same also for Windows. But there are also native GUI versions that however appear clumsy for a Unix person used to fast keyboard operation, as opposed to (slow) mouse clicking in GUI's

Bye Fridger

[hank]

Tim,

Part of my reason for encouraging you to try this is because it would be an excellent proof of concept demonstration for using Lua with Celestia in this kind of application. I understand that it would mean extra work for you at this point, but I think it would be of great value to the Celestia community in the long run.

I am still trying to understand how a user would use Lua for the real-time bodies. As a user I would have to start a script to read the UDP messages. A script runs for a seconds and stops. This is crazy. Does this mean I have to execute a Lua script (thread) that runs indefinately or until I am done watching all 100 real-time satellites orbiting the earth? Remember, Celestia is a single threaded application. I would like for someone to explain the steps involved using the Lua script.

The real-time interface in the core could drain the UDP network message any time a message appears. The user would not have to run a Lua script. How about the cool master/slave features of the RealTime Celstia? How would that work using Lua scripting? How would the Celstia Broadcasting work.

Clearly some enhancements to Celestia are needed in order to implement your RealTime features using Lua with Celestia. You need to be able to load a Lua script automatically at startup, install a Lua function that's called repeatedly from the main event loop, load the LuaSocket library, etc. But all of these enhancements can be used by many other potential applications, as well as RealTime.

Some one mentioned that you have to learn C++ to use the real-time code. This is true but most of the work is done for you. C++ and Lua are very similar. If you are going to argue that you have to learn C++, I can argue that you have to learn Lua. I like Lua and I think it serves a great purpose for what is does but I think that the UDP messages belong in the core.

As a language, Lua is much, much simpler to learn and use than C++. And you can use Lua without having to modify Celestia's compiled code. You can use Lua without having to use developer tools, or build your own version of the Celestia code, or coordinate changes with the developer team. The Lua compiler is built into Celestia, so it's available to all users. If Lua can be used successfully for custom Celestia applications like RealTime, it will greatly expand the possibilities for custom development with Celestia.

Remember that the Lua is an interpreted language like MatLab and Java. Try interpreting 100 UDP message coming into your network card and processing the message and rendering the bodies. This will be impossible. I have been in exercises where there are over 1000 bodies on the network and all applications are required to process each UDP message and render. Good luck with a scripting language.

Yes, Lua itself is interpreted, but the heavy-lifting would be done by compiled code in LuaSocket (networking) or the Celestia core (rendering) or an application-specific library (if necessary). Still, RealTime would certainly be a good test of Lua's performance potential. That's why I would encourage you to try this.

- Hank

[Christophe]

If you got Celestia source code from CVS, the best way to create a patch is to use the 'cvs diff' command, this is explained here.

[RocketMan@JSC]

PS Perhaps you might tell me what e.g. a user like yourself would like to do with such real-time features? Start the external play-back pannel and send some rotation command for the antenna of Cassini spacecraft? Wow, it works...but how often would you repeat this exercise? Did I overlook something crucial?

After re-reading the thread I saw this and wanted to point out some more uses of the model based features that would be desireable.

I'll admit that features like this give the appearance of "gaming", however, there are real life needs for these features.

1) This one you will laugh, but it's true. Showing and demonstrating space vehicles to upper manangement and the public in general, they like to see dynamic features. I've learned that when presenting something to upper manangement, the good graphics and animations put a heavy wax job on your presentation--sometimes that's what it takes to win them over and fund your project.

2) Engine plumes and exhaust need to be modelled to visualize plume impingement regions when operating near other spacecraft. This is a especially evident when shuttle/soyuz/progress are operating near the ISS.

3) Laser and radar sensors can be modelled to visually show regions of operation used for rendezvous maneuvers. The same can be said for using these types of sensors for scanning the surface of the moon and determining a suitable landing site during the final approach.

4) Vehicles don't always launch in the full configuration used for space travel. Landing struts get deployed, stages and components get jettisoned, solar arrays get deployed, etc...

[ElChristou]

I'll admit that features like this give the appearance of "gaming", however, there are real life needs for these features.

1) This one you will laugh, but it's true. Showing and demonstrating space vehicles to upper manangement and the public in general, they like to see dynamic features. I've learned that when presenting something to upper manangement, the good graphics and animations put a heavy wax job on your presentation--sometimes that's what it takes to win them over and fund your project.

2) Engine plumes and exhaust need to be modelled to visualize plume impingement regions when operating near other spacecraft. This is a especially evident when shuttle/soyuz/progress are operating near the ISS.

3) Laser and radar sensors can be modelled to visually show regions of operation used for rendezvous maneuvers. The same can be said for using these types of sensors for scanning the surface of the moon and determining a suitable landing site during the final approach.

4) Vehicles don't always launch in the full configuration used for space travel. Landing struts get deployed, stages and components get jettisoned, solar arrays get deployed, etc...

Scott, I understand perfectly your views, but you seems to need a very specialised tool which should be dev in // to Celestia (I'm almost sure the dev team are not ready to specialise so much Celestia); what about Orbiter? not a better base for you project?

[selden]

ElChristou,

As with the educational support features that Vincent has been adding, there are quite a few people who would very much like to see these realtime features in Celestia, so they don't have to "reinvent the wheel" for their spacecraft and orbital display software.

Unfortunately, Orbiter is a closed-source program written only for Windows. Its author does not make it available for others to enhance.

[Joe]

I totally agree with Selden. Realtime feature deserves to be encouraged even it is not to become part of the official release in the very near future. I am sure there will be lot of interests in this feature in this community, like Scott just pointed out. Who knows, it could be very useful for a wide range of applications.

[ElChristou]

ElChristou,

As with the educational support features that Vincent has been adding, there are quite a few people who would very much like to see these realtime features in Celestia, so they don't have to "reinvent the wheel" for their spacecraft and orbital display software.

Don't missunderstand me, it would be quite cool to see those features, I mean I would be the first in using them with the shuttle!!
Now I'm just wondering if Celestia actual philosophy is matching those very specific features...

Unfortunately, Orbiter is a closed-source program written only for Windows. Its author does not make it available for others to enhance.

I wasn't aware of that... indeed, I was thinking it was open source...

[selden]

The "open" part of Orbiter is the ability to create Addons for it. The program itself isn't.

[t00fri]

I have the following attitude (so far) about a real time interface:

On the more negative side:

1) RocketMan@JSC's above additional application examples really do not convince me. They simply concern just a few people on the long run. Think of all the fancy add-ons that first have to be written before any concrete advantages could be noticed... I agree that certain professional aeronautics people might have some use for this.

2) I forsee a major problem report activity from people like the user Joe who experience difficulties even installing a simple network card and making the real time interface work...

3) I would find it way more sensible if we'd start contemplating (first) a Lua + Lua sockets network module that could be tested in updating and converting with a click needed ephemeris about spacecraft, comets and asteroids from the official data base. That concerns many users interested in observing e.g. satellites in the sky. Good ephemeris software (XEphem) has this feature since a long time.

4) Given our limited menpower as to Celestia development, I could see a host of more urgent projects that many more people would profit from...

Positive:

4) I mainly view a real time interface as a useful benchmark case for more complex Lua applications. I certainly would veto as to an implementation of this into the Celestia core.

Bye Fridger

[RocketMan@JSC]

I have the following attitude (so far) about a real time interface:

On the more negative side:

1) RocketMan@JSC's above additional application examples really do not convince me. They simply concern just a few people on the long run. Think of all the fancy add-ons that first have to be written before any concrete advantages could be noticed... I agree that certain professional aeronautics people might have some use for this.

In regards to the features I talked about, the modelling issues are already up for discussion in another thread. It's pretty evident a better model format is needed.

The main parts from the realtime code I would want in the core are: spacecraft attitude added to the xyzq file, and the ability to load up a trajectory from the menus (and/or lua).

Currently I have no planned uses for the udp part, but I could see how that would be useful for running with a seperate simulation. Why would it be such a big deal to leave a plug in that others could use? It's a pretty generic interface that people could use, and if they don't, I believe it would not slow them down. Enabling the feature via a config file or lua would be fine, but the hooks still need to be in the main code.

Scott

[RocketMan@JSC]

ElChristou,

As with the educational support features that Vincent has been adding, there are quite a few people who would very much like to see these realtime features in Celestia, so they don't have to "reinvent the wheel" for their spacecraft and orbital display software.

Unfortunately, Orbiter is a closed-source program written only for Windows. Its author does not make it available for others to enhance.

My thoughts exactly. Closed source does no good for me. Also it's only a windows program. We primarily operate on Linux for our flight design and mission control platforms.

[ElChristou]

ElChristou,

As with the educational support features that Vincent has been adding, there are quite a few people who would very much like to see these realtime features in Celestia, so they don't have to "reinvent the wheel" for their spacecraft and orbital display software.

Unfortunately, Orbiter is a closed-source program written only for Windows. Its author does not make it available for others to enhance.

My thoughts exactly. Closed source does no good for me. Also it's only a windows program. We primarily operate on Linux for our flight design and mission control platforms.

Scott, no-one at Nasa can give a hand to the dev team to study all those topics (model format, real time etc) a bit closer? Our dev team is really minimalist, all volunteers and there is so much to do... so as Nasa is supposed to avoid outrageous fees on special soft, at least I was wondering if a little help could be possible...

[Malenfant]

1) RocketMan@JSC's above additional application examples really do not convince me. They simply concern just a few people on the long run. Think of all the fancy add-ons that first have to be written before any concrete advantages could be noticed... I agree that certain professional aeronautics people might have some use for this.

This point at least I think isn't relevant, since you could apply the same logic to other addons. For example, I'm not sure how many users are actually interested in seeing every known galaxy shown in Celestia, or in seeing the large scale structure of the universe for that matter. Heck, even some random guy's new planetary system addon isn't really of that much interest to most people. But I don't see anyone complaining that they're too obscure for their use.

The "validity" of an addon isn't determined by how many people use it - what matters is that it's there for the people who are interested in it.

[RocketMan@JSC]

Scott, no-one at Nasa can give a hand to the dev team to study all those topics (model format, real time etc) a bit closer? Our dev team is really minimalist, all volunteers and there is so much to do... so as Nasa is supposed to avoid outrageous fees on special soft, at least I was wondering if a little help could be possible...

Personally I'm all for it. In fact, I feel like we should be obligated to help. Unfortunately my hands are tied, there is a process we must go thru to release the information. We aren't just allowed to send stuff out whenever we feel like it. I will always ask to allow code changes and models shared back to the open source community. Currently I'm integrating some of tecs changes into our build and it's paid for by NASA contract dollars, they are the owners of the changes and rightfully so I must follow their rules. There is the Freedom of Information Act and these types of software changes can be requested thru the appropriate channels. Like I said I will do my best.

The whole open source issue will come to discussion someday, Celestia isn't the only program we use. There is just a tremendous amount of activity going on right now (CEV/Constellation) and this isn't necessarily at the top of priorities.

Hope that answeres your question. And I haven't forgotten about your Ku band antenna info either

Scott

[t00fri]

1) RocketMan@JSC's above additional application examples really do not convince me. They simply concern just a few people on the long run. Think of all the fancy add-ons that first have to be written before any concrete advantages could be noticed... I agree that certain professional aeronautics people might have some use for this.

This point at least I think isn't relevant, since you could apply the same logic to other addons. For example, I'm not sure how many users are actually interested in seeing every known galaxy shown in Celestia, or in seeing the large scale structure of the universe for that matter. Heck, even some random guy's new planetary system addon isn't really of that much interest to most people. But I don't see anyone complaining that they're too obscure for their use.

The "validity" of an addon isn't determined by how many people use it - what matters is that it's there for the people who are interested in it.

I disagree with the whole line of argumentation.

1) the real time interface is way more than a simple add-on, notably if we'd implement the whole code into the celestia core, as advocated by 'tec'. That should also be obvious to Malenfant. Add-on's are implemented at the user level outside of any responsabilities of the dev team.

2) given the "thin" menpower situation in the dev team we have to seriously evaluate on which kind of project we spend our available time. An important criterion has always been to compare the required programming effort with the estimated usefulness for a wider community. Furthermore, any new implementation should of course be in line with Celestia's general design principles.

3)

I'm not sure how many users are actually interested in seeing every known galaxy shown in Celestia,

Like with all databases, the Celestia DSO data base would loose a lot of it's value if we'd leave out arbitrarily galaxies (and other DSO's, like galactic star clusters, gaseous nebulae, planetaries,...) from the complete revised NGC/IC catalog etc. Such a procedure, for example would NOT be in line with Celestia's adopted design criteria. At present, not a single galaxy is missing from that catalog out to the dimmest (18m). It will for sure make amateur astronomers happy who are using Celestia...

Much effort went into highly efficient octree based culling techniques such that we are not forced for performance reasons to cut short on DSO's wrto standard professional catalogs.

A much more relevent and thus interesting issue than Malenfant's misplaced remark
seems to me the question of a further standardisation of Celestia's data base, possibly via a SPICE interface.

http://www.celestiaproject.net/forum/viewtopic ... ight=spice

This would certainly be a big project and it's feasability would have to be very carefully investigated.

[ElChristou]

Scott, no-one at Nasa can give a hand to the dev team to study all those topics (model format, real time etc) a bit closer? Our dev team is really minimalist, all volunteers and there is so much to do... so as Nasa is supposed to avoid outrageous fees on special soft, at least I was wondering if a little help could be possible...

Personally I'm all for it. In fact, I feel like we should be obligated to help. Unfortunately my hands are tied, there is a process we must go thru to release the information. We aren't just allowed to send stuff out whenever we feel like it. I will always ask to allow code changes and models shared back to the open source community. Currently I'm integrating some of tecs changes into our build and it's paid for by NASA contract dollars, they are the owners of the changes and rightfully so I must follow their rules. There is the Freedom of Information Act and these types of software changes can be requested thru the appropriate channels. Like I said I will do my best.

The whole open source issue will come to discussion someday, Celestia isn't the only program we use. There is just a tremendous amount of activity going on right now (CEV/Constellation) and this isn't necessarily at the top of priorities.

Hope that answeres your question.

Of course, I understand Nasa won't share critical info just like this! In fact I'm not thinking in any kind of "sensitive" information from Nasa, nor in sharing models (I would love it of course! -> just a highres ISS for me is fine ), but just some ponctual help at dev level (even if it's unofficial) IF Cellestia grant a certain interest; could be for whatever of those actual topics (or anything else) which have nothing really sensitive, it's just question of manpower to give a little help...

...And I haven't forgotten about your Ku band antenna info either

[RocketMan@JSC]

Of course, I understand Nasa won't share critical info just like this! In fact I'm not thinking in any kind of "sensitive" information from Nasa, nor in sharing models (I would love it of course! -> just a highres ISS for me is fine ), but just some ponctual help at dev level (even if it's unofficial) IF Cellestia grant a certain interest; could be for whatever of those actual topics (or anything else) which have nothing really sensitive, it's just question of manpower to give a little help...

Of course I'll do what I can. Right now I'd like to see Celestia get a little better foothold here in the space community. Then start pressing for some easy process to release info--whether it's models or code.

I'm so hamstrung it's not even funny. Even if I do work at home, it could be claimed by my employer. If my work is construed to give a competitive advantage to other companys, I could be looking at trouble. The lawyers have gotten a foothold into everything. IMHO the space program needs to be sharing and collaborating, not hampering communication and innovation.

Scott

[RocketMan@JSC]

So will we be able to at least get the attitude part of the changes rolled into the next build to support the xyzq format?

I've got a running version based on tec's changes. Still working out a few details before I say the attitude capability works correctly.

I think there may be some changes on the quaternion interpolation. My rolling spacecraft goes about 3/4 of the way around and then reverses direction. Not sure why. Basically it's in a barbeque roll mode.

Also the vehicle model appears to have a different body frame than what I'm used to. Tec, do you know the body attitude of the ACT vehicle?

I also noted a few minor issues compiling and executing and will post the code changes when I have them all together. I'd say that's pretty much normal going from one platform/compiler to another.

Scott

p.s. I did have to remove the position adustment method. Not sure why it's in there but surely it has to do with the real-time part and not strictly necessary for the position/attitude rendering. Perhaps tec could let me know more about this?