Use of Orbiter Sim for Lockheed Martin Design Review

Rob Oplawar

New member
Joined
May 27, 2008
Messages
9
Reaction score
0
Points
0
Recently, at Lockheed Martin in Denver, we had an opportunity to see and download the "Orbiter" software. We are interested in using it to aid in engineering visualization for the upcoming Preliminary Design Review (PDR) for the Orion project (www.nasa.gov/orion).

In April, we had a “bring your child to work” day in which the Orbiter sim was featured and was a big hit. We are of course developing our own simulation systems, and we have other heavy weight tools at our disposal like the Satellite Tool Kit (STK), but the Orbiter software is a better match for our plans to use College students from CU Boulder and the University of Texas at El Paso to produce animations that illustrate the basic vehicle state.

Last week I sent an e-mail to Martin Schweiger, using the contact address specified in the Orbiter sim, but I haven't received a reply and I'm concerned that the e-mail may have been mistakenly filtered as spam or that the e-mail address specified is out of date.

Please let me know if there are any licensing requirements, restrictions or fees associated with the use of the Orbiter software, or who to contact to find out more about how we may be able to use it on Project Orion.

Regards,
Robert Oplawar

P.S. On a significantly less professional note, Rob Oplawar is a pseudonym- I can't help but express a personal interest in Orbiter, so I plan to stick around these forums when I'm not at work. After much consideration, I decided that if I made an alt account for work, it would be too easy to associate the two accounts and figure out my real name, so I'm sacrificing just a bit of professionalism. Besides, it's best to avoid real names in public online locations anyway. I can't let my real name be publicly associated with my pseudonym- gotta protect my secret identity, you know. ;) Ahem. Back to serious business. :serious:
 
Welcome to the forum, Rob! I'll post a link to this thread in the Beta forum to be sure that Martin sees it.

And don't let your boss catch you doing a reentry to KSC in Orbiter during work hours. :)
 
I am sure, THIS problem can get solved. :) Lately already other aerospace companies used Orbiter without being so polite to ask first. Martin Schweiger is active here on a regular base, if you want to be really sure he notices this, you can also send him a message here. But I think the beta test team is also already busy sending smoke signs.

P.S. On a significantly less professional note, Rob Oplawar is a pseudonym- I can't help but express a personal interest in Orbiter, so I plan to stick around these forums when I'm not at work. After much consideration, I decided that if I made an alt account for work, it would be too easy to associate the two accounts and figure out my real name, so I'm sacrificing just a bit of professionalism. Besides, it's best to avoid real names in public online locations anyway. I can't let my real name be publicly associated with my pseudonym- gotta protect my secret identity, you know. ;) Ahem. Back to serious business. :serious:


:cheers: Actually, Urwumpe is already my real (artistic) name and I am telling my employers and university teachers only the pseudonym.

Even in the more private place, where my real name was nation-wide known, you only heard a shouted "Merc scum!" :lol:
 
Hi Rob, welcome to the forum! :welcome:

I believe Martin (Orbiter Copyright Holder) is away for a week, so I hope it's not a rush. I assume he'll be OK with it, but I am in no position to say. I'm sure when he gets back he'll let you know something. :)
 
Well I'm not Dr. Schweiger, but if I were, I wouldn't mind Lockheed Martin using it like that. I've always thought that Orbiter has better graphics than 90% of aerospace companies' official concept visualizations.

As an aside, if you develop any addons for your visualizations, will you release them to the community? Or would you just be using the existing Ares/Orion addon?:P
 
Welcome to the forums.

[Edit]
Scarecrow beat me to it
This is a side issue, but after you've finished all your work with orbiter, would you think about releasing Orion as an addon?

[/Edit]
But anyway sure is nice to have a real professional :)
 
You've probably already looked at the copyright notice at http://orbit.medphys.ucl.ac.uk/disclaimer.html , but just in case...

The ORBITER software, documentation and the content on this website is copyrighted 2000-2006 by Martin Schweiger.

ORBITER is free software in the sense that you are free to download, copy and redistribute it for personal and non-commerical purposes, provided that the copyright notice is retained in the copy. You are not allowed to charge a fee for the software without the consent of the author other than that to cover the cost of the distribution. If a fee is charged it must be made clear to the purchaser that the software is freeware and that the fee is to cover the distributor's costs of providing the software. You are not allowed to use Orbiter or parts of it in a commercial product without the author's consent.

You are not allowed to modify any executable files or documentation in any way. You are allowed to modify or add files in the Config, Meshes, Textures and Textures2 directories and to distribute these modified or added files as freeware, provided that you make it clear to recipients that you have made these modifications.

ORBITER is not in the public domain: it is the intellectual property of Martin Schweiger.
(Then comes the part about no warranty, etc.)

That said... I believe I've seen it mentioned somewhere (yeah... sorry... no references) that the primary purpose of Orbiter is as an educational tool, so if the major part of what you're doing is for educational purposes, you'll probably be able to get permission from Dr. Schweiger when he gets back, if you feel that the above doesn't cover your use of the program.
 
Last edited:
(Off the specific subject of licensing, but I wanted to mention this in case the original poster hadn't noticed yet.) You can force specific states into each vehicle, and so can totally replace the internal Orbiter dynamics if desired.
 
Thank you all for posting and welcoming me, I'm glad to have found your community. I think I might fit in nicely here, if I do say so myself. (On an aside, I flew my first mission last night- DG to ISS- missed the darn thing by 300km. Time to try again tonight. :P Good times. )

Back on the subject of using Orbiter for visualization:
My supervisor is really pushing for something that I'm not sure is possible in the amount of time we have- he wants to have one application send an arbitrary timestamp to Orbiter and have Orbiter respond with a single frame representing the state of the CEV at the specified time. Can anyone who is more familiar with Orbiter's engine tell me: Is this possible? I expect if anything Orbiter would have to be made to listen on a port on the local machine, and send back an image in packets. Perhaps I could put some wrapper application around Orbiter to handle the network interface and screen capture/image conversion?
 
Thank you all for posting and welcoming me, I'm glad to have found your community. I think I might fit in nicely here, if I do say so myself. (On an aside, I flew my first mission last night- DG to ISS- missed the darn thing by 300km. Time to try again tonight. :P Good times. )

Back on the subject of using Orbiter for visualization:
My supervisor is really pushing for something that I'm not sure is possible in the amount of time we have- he wants to have one application send an arbitrary timestamp to Orbiter and have Orbiter respond with a single frame representing the state of the CEV at the specified time. Can anyone who is more familiar with Orbiter's engine tell me: Is this possible? I expect if anything Orbiter would have to be made to listen on a port on the local machine, and send back an image in packets. Perhaps I could put some wrapper application around Orbiter to handle the network interface and screen capture/image conversion?

Well, as single frame renderer, you might be interested into the Orbiter Visualization project, which currently works on separating physics core and graphics engine.

I don't know if the exact work flow of Orbiter can be made like that by plug-ins, but Orbiter has a playback feature, which can easily be fed with simulation data from more professional calculations.

Accelerating manually to a time is possible during playback, the question is, can you also advance simulation time by plug-in? That would have to be tested first, before making any promises.


I think rendering a single frame is within the scope of Orbiter, though it works nicer for sequences and grabbing these with a video recording software.
 
Accelerating manually to a time is possible during playback, the question is, can you also advance simulation time by plug-in? That would have to be tested first, before making any promises.

I have done programatic changes in time (skipping forward or backward to a specific MJD).

oapiSetSimMJD if i recall, it's been 8 months, and i don't have the SDK in front of me... There's also options associated to it regarding how to propogate the vessels during the time jump.
 
My supervisor is really pushing for something that I'm not sure is possible in the amount of time we have- he wants to have one application send an arbitrary timestamp to Orbiter and have Orbiter respond with a single frame representing the state of the CEV at the specified time. Can anyone who is more familiar with Orbiter's engine tell me: Is this possible? I expect if anything Orbiter would have to be made to listen on a port on the local machine, and send back an image in packets. Perhaps I could put some wrapper application around Orbiter to handle the network interface and screen capture/image conversion?

If I understand right, you want another application to send a date to Orbitersim and Orbitersim return a "screenshot" with whatever location the CEV is in at that time, right? More like a showcase, maybe something like "see in time"? If so, the Orbitersim ScnEditor has ways to set the date and the orbits of the objects will be automaticly calculated. The ScnEditor code is included in the SDK, you might want to check that out.

From my little experience I have with the Orbitersim SDK I can tell it's pruity "closed", maynly because (I think) Dr. Martin Schweiger wants to protect his work so I don't know how much the ScnEditor source code will help you. Maybe he'll help you too since it's such a big project.

PS: I like what you guys did with the JSF project and the close team you have over there. Were you in the JSF team? (that is if you can tell us without killing us :) )
 
Well, as single frame renderer, you might be interested into the Orbiter Visualization project, which currently works on separating physics core and graphics engine.
I saw that when I was perusing the forum earlier- from what I saw I understand that it's a work in progress, no? I have a very short deadline, basically a month and a half- if that's not pretty much ready to go right now then it's unfortunately no good.
Orbiter has a playback feature, which can easily be fed with simulation data from more professional calculations.
I have done programatic changes in time (skipping forward or backward to a specific MJD). oapiSetSimMJD if i recall
the Orbitersim ScnEditor has ways to set the date and the orbits of the objects will be automaticly calculated. The ScnEditor code is included in the SDK, you might want to check that out.
That's pretty much exactly what I'm looking for- so if Orbiter's in playback mode and I jump to a specific time, will it move the spacecraft to the location specified by the playback files?
I think rendering a single frame is within the scope of Orbiter, though it works nicer for sequences and grabbing these with a video recording software.
Ideally I'd love to stick a video in there, but I think it might be asking a bit much to stream video between applications. Then again, we've been discussing it on our end and we think it would be reasonable to simply leave Orbiter in its own window and bring it up whenever we want to look at the spacecraft. In that scenario we only have to worry about sending Orbiter the proper data to keep it in sync with our other app.

PS: I like what you guys did with the JSF project and the close team you have over there. Were you in the JSF team? (that is if you can tell us without killing us :) )
Naw, I'm pretty new here actually, and as far as I know all my near by coworkers have never worked in the defense side of things. We're a bunch of peaceful, knowledge seeking scientists over here. ;D

edit: Oh, I just realized I haven't really told you what the deal is with this mysterious "other app" that has to synchronize with the visualization tool. I don't know how much I'm allowed to say about it, but basically the purpose of the app is to provide an overview of the complete mission timeline, from which you can select any point in the mission and display the spacecraft state at that time, with lots of charts and graphs and dials and TLAs with mysterious meanings. It's important that the 3D render of the spacecraft also be synchronized with this time.
 
Grad student? Was talking to a few LM grads the other day, it's a fun place to work. :)
 
edit: Oh, I just realized I haven't really told you what the deal is with this mysterious "other app" that has to synchronize with the visualization tool. I don't know how much I'm allowed to say about it, but basically the purpose of the app is to provide an overview of the complete mission timeline, from which you can select any point in the mission and display the spacecraft state at that time, with lots of charts and graphs and dials and TLAs with mysterious meanings. It's important that the 3D render of the spacecraft also be synchronized with this time.


This other app has to be a different application on a different PC? Or would it be allowed to make this application a Orbiter plug-in?

Is it possible to select the time free (any second) or are there fixed times to select?

I just tested playback with scenario editor, which went wrong badly, maybe I had choosen the wrong approach. I think also, orbiter might not like it, if you go back in time.
 
edit: Oh, I just realized I haven't really told you what the deal is with this mysterious "other app" that has to synchronize with the visualization tool. I don't know how much I'm allowed to say about it, but basically the purpose of the app is to provide an overview of the complete mission timeline, from which you can select any point in the mission and display the spacecraft state at that time, with lots of charts and graphs and dials and TLAs with mysterious meanings. It's important that the 3D render of the spacecraft also be synchronized with this time.

Well depending on the granularity of the times the user has to be able to select and the amount of disk space / bandwith you have availiable, you could just take a whole bunch of screenshots at regular intervals and pick one to display, only using orbiter to make the pictures ahead of time.
 
Grad student? Was talking to a few LM grads the other day, it's a fun place to work. :)
Something like that. ;)

This other app has to be a different application on a different PC? Or would it be allowed to make this application a Orbiter plug-in?

Is it possible to select the time free (any second) or are there fixed times to select?

I just tested playback with scenario editor, which went wrong badly, maybe I had choosen the wrong approach. I think also, orbiter might not like it, if you go back in time.
Not on another PC, but using netcode because that's the easiest way to have two processes communicate (that I know of). The thought of inter-process communication via the operating system is, tbh, scary to me.
<br/>In theory you should be able to jump to any time at all during the mission.
<br/>The back in time thing is what's got me worried- it looks like Orbiter might only be capable of propagating change forward and cannot step back.
<br/>For my end of the application, with the charts and graphs and such, I'm actually doing a similar thing- I currently use on-change data, and the naive algorithm of simply starting over from the beginning in order to go back in time is working well enough so far. Maybe that approach could work for Orbiter as well.
Well depending on the granularity of the times the user has to be able to select and the amount of disk space / bandwith you have availiable, you could just take a whole bunch of screenshots at regular intervals and pick one to display, only using orbiter to make the pictures ahead of time.
The option I am in favor of is to simply record a bunch of videos of the mission using Orbiter, and have my end of the app simply play them back at the right times.
<br>However, the concern is that if our data change even the slightest bit we'll probably have to go back and change the video, and it would be a nightmare to keep all those videos up to date. If the data report that the solar arrays are charging the batteries but the video shows that the arrays are currently stowed, someone will notice it and say "That is not right."

edit: Oh, vBulletin, your inconsistent newline management is getting on my nerves. This makes me want to finish writing that forum software I've been working on for the last century or so.
ee: oshi! Linux! That's the culprit, isn't it? I switched to Windows and the newlines work now. I guess I'll have to take that into account in my code...
eee: nowait, that shouldn't be it. How odd...
 
I assure you, around here we go to great lengths to test the hell out of everything before a human ever steps foot in it. :)
 
Oh, I just realized I haven't really told you what the deal is with this mysterious "other app" that has to synchronize with the visualization tool. I don't know how much I'm allowed to say about it, but basically the purpose of the app is to provide an overview of the complete mission timeline, from which you can select any point in the mission and display the spacecraft state at that time, with lots of charts and graphs and dials and TLAs with mysterious meanings. It's important that the 3D render of the spacecraft also be synchronized with this time.

Well, I was close but not enough. I (and most of us) use the playback to fly in formation for example. So I fly the XR1 one time, and then play back the flight and add another XR1 to the scenario and simply fly in formation. To avoid reloading the scenario, once I thought I could use the ScnEditor to move back in time to the moment when I took off. It worked, but, as urwumpe already noticed, everything is messed up. The other ship was not pitching, banking properly etc. So using the ScnEditor in combination with the playback might not work.

Here's another concern: if let's say you fly the DG into orbit and it takes you about 40 minutes to get in a stable orbit, and you move backwards in time during the simulation, let's say 50 minutes, Orbitersim will simply calculate your theoretical orbital position at that time, as if you were forever in that orbit.

So here's the conclusion: it's complicated and it depends on what you need and what your team's expectations are. You could simply run Orbitersim (no playback) and move forwards and backwards in time, but if you are doing interplanetary travels you have to do correction burns to get in the right orbits before jumping too much in time and miss a planet and screw the mission up. So you need mission details big time to have a proper estimation using Orbitersim and think ahead to plan the mission in Orbitersim. And then decide if you should use it at runtime or playback.

EDIT: Just thought of another option: why not use multiple computers running the same mission at different points in time, after crytical steps in the mission, like plane alignments, lunar injection burns, course corrections, orbit insertions etc etc etc. That way you have access to all the mission scenes you need. Plus if the boss asks something crazy that was not planned (they do that usually) you simply fast-forward one of the missions. It might seem a bit crazy but you have to consider all options, depending on what you want to achieve...
 
Back
Top