Use of Orbiter Sim for Lockheed Martin Design Review

[computerex]

From what you are saying, communication shouldn't be that big of a problem. You could get the orbiter's window handle through EnumWindow, or FindWindow. The external application could send an MJD timestamp through sockets to a module in orbiter, mapped memory files, a singleton class in a dll which the external app and the module in orbiter could load, using SetWindowLong to handle Orbiter's messages, then sending a "capture" message through the external application, or simply send flags through a text based file which both the module in Orbiter and the application can write/read from. The module in Orbiter could easily propagate the simulation and take a screen shot. As long as the time stamp is in future, there shouldn't be any complications with using orbiter's playback feature with this.

The problems start when propagating time backwards. Skipping time forward/backwards makes the simulation terribly unstable as it is because of the numerical errors. But while a playback is active, going backwards in time ruins the simulation. And due to the nature of this, a highly efficient closed loop autopilot is completely out of question...So you are sort of in a pickle.

 

[kangaroos]

Hi!

I think you don't need to go backwards if you do it like this:

Let's say we have launched into an orbit, mission elapsed time is 45 minutes. Now you would like to replay the launch beginning with minute 3. When you go backward you screw everthing up so let's start the playback from beginning and jump to minute 3.

Would that work?

regards from Austria,
Franz

 

[movieman]

Presumably one option would be to manually run through your mission using an addon that dumps its state to a file every few seconds; then when you wanted to jump to a specific time you could load the state and interpolate to the current position, velocity, thrust level, fuel level, etc. The planets would be in the same place, so it should be fully consistent and allow you to display the spacecraft flying an arbitrary mission.

 

[Hielor]

What are your constraints? IE, how quickly does Orbiter need to respond to the request, how much space do you have to use on the machine, etc.

The problem is that Orbiter is very much designed to be a real-time simulator--it's not that good at propagation, as has been previously noted.

I would propose flying the mission and recording scenarios at given intervals--ie, once a second for high speed phases, once a minute or so (perhaps less) for OPS. Launch only takes a few minutes (we'll say 10 for simplicity's sake, so 600 scenarios), let's say you spend six days in ops for another 8640 scenarios, and then about 20 minutes in landing for another 1200 scenarios. That's only a bit more than 10,000 scenarios, which couldn't possibly take up more than 40 megabytes even if you had multiple vessels (ie, for each stage, different elements of the interstage, the abort tower, etc).

Write a "wrapper" program which will accept the screenshot requests, then invoke Orbiter from the command line with the correct scenario (tagged by MET it wouldn't be too difficult, could have a folder structure corresponding to DOY::hour). The program then snags a snapshot of the screen and sends it off.

The problem with that is that Orbiter does take a long time to start up. You could write an add-on that's a "hot load" function, which can find a scenario file, delete all the vessels in the current scenario, propagate all planets to the correct time for the scenario file, then reloads the vessels. I couldn't see this process taking much more than a second even on an older computer.


You mentioned changing the mission parameters potentially causing problems--you could have different "mission" folders, each with its own set of scenarios. If you write a function to automatically dump a scenario once every (x) seconds of MET while you're flying the mission, that would take most of the tedium out of it.

 

[estar]

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?

The first problem you can't rewind or forward the current version of Orbiter. What you can do is make a full multi-stage/multi-mode vessel, run a mission, and use the Windows API to save a screenshot at specified times.

The function you need for saving the screen is this

The call is GetScreen(0);

void GetScreen(HWND hwnd) {
        HDC hdc = GetDC(NULL);
        HDC hDest = CreateCompatibleDC(hdc) ;

        // get the height and width of the screen
        // (multiple Monitors? see notes)
        int height = GetSystemMetrics(SM_CYVIRTUALSCREEN ) ;
        int width = GetSystemMetrics(SM_CXVIRTUALSCREEN) ;

        // create a bitmap,
        HBITMAP hbDesktop = CreateCompatibleBitmap( hdc, width, height ) ;

        // associate our own Device Context to the bitmap
        SelectObject(hDest, hbDesktop );

        // copy from one DC to the other
        BitBlt( hDest, 0,0, width, height, hdc, 0, 0, SRCCOPY) ;
        _mkdir("images");
        char fname[256] = "images";
        char *tName;
        tName = tmpnam(NULL);

        
        CreateBMPFile(hwnd,RetrieveTempFilename("images","merc") ,CreateBitmapInfoStruct(hwnd,hbDesktop),hbDesktop,hDest);
}

This is used by my Project Mercury for Windows to simulate taking a picture with the onboard camera. It grabs the screen shot and save under a random name in the images directory underneath orbiter.

You see my method of using a state machine to code a multi-stage vessel

with my add-ons here

http://www.ibiblio.org/mscorbit/

If the V2 add-on contains a tutorial how to code up a multi stage vessel. The Project Gemini add-on is the next on the complexity. And Project Mercury is the most complex being a simulation of the original capsule with nearly all switches and dials working.

If you want variable time stamps to be sent to the vessel then you can use Windows Sockets to setup a socket to communicate with the Orbiter vessel.

While Orbiter is useful as a visualization tool you can also use it for control mockups as well. If you need to work the astronauts you can use the programming tools in orbiter to mock up any type of panel want and tie into the simulation. You can see this in the Project Mercury simulation and a unfinished setup in Project Gemini.

Finally all my source code is under the BSD license so feel free to copy anything you need, just make sure it is credited.

Hope this helps.

Rob Conley

 

[Rob Oplawar]

Plus if the boss asks something crazy that was not planned (they do that usually) you simply fast-forward one of the missions.

Well here's the thing- I'm not the user. I'm going to be handing this application off to someone (I don't know who yet) who will be giving a presentation to NASA using the application. Therefore it has to be simple and intuitive and incredibly robust- if the application glitches the slightest bit during a big presentation to NASA, well, that's bad. So I'm going to say at most one instance of Orbiter.
<br />

:words:
...Skipping time forward/backwards makes the simulation terribly unstable as it is because of the numerical errors...

I think I get what you're saying- I'll have to familiarize myself more with the way Orbiter's modules/addons work before I can really grasp how that would work.
Ok, so it looks like moving backwards in time is out of the question, but would it be possible to tell orbiter to just reset the state to the beginning of the scenario without reloading the whole thing? After that it should be able to jump forward reasonably quickly to the specified time- calculation errors are a non issue, because the important data, the position of the craft relative to the earth, will be come from a replay file. Then again, if there is a calculation error in the Earth's orbit and the craft ends up in the shadow of the Earth when it shouldn't be, well, that would be an issue. Is this something I would have to worry about, or are the calculations for propagating planetary orbits stable enough to trust?

I think you don't need to go backwards if you do it like this:

Let's say we have launched into an orbit, mission elapsed time is 45 minutes. Now you would like to replay the launch beginning with minute 3. When you go backward you screw everthing up so let's start the playback from beginning and jump to minute 3.

Would that work?

regards from Austria,
Franz

Exactly. Would that work?

Presumably one option would be to manually run through your mission using an addon that dumps its state to a file every few seconds

Well, that's what I was hoping to get from the built-in replay feature.

What are your constraints? IE, how quickly does Orbiter need to respond to the request, how much space do you have to use on the machine, etc.
...
I would propose flying the mission and recording scenarios at given intervals--
...

Well then we have the same data management problem. If the data change the slightest bit- say launch were moved back by 10 minutes- we'd have to update each and every one of those scenarios.
Plus we really want this tool to feel somewhat real-time. There shouldn't be more than a second or two of lag between jumping to a time and seeing the data associated with it.

What you can do is make a full multi-stage/multi-mode vessel, run a mission, and use the Windows API to save a screenshot at specified times.
...
If you need to work the astronauts you can use the programming tools in orbiter to mock up any type of panel want and tie into the simulation.
...

Again, the same data management problem. Our fallback plan is to record videos of the whole mission and have them jump to the appropriate video at the appropriate frame when jumping to a point in a mission. But I'd really like to avoid that. Ideally we should just give it the complete mission data file, which we can replace with the up-to-date one any time it changes, and just feed it the timestamp and get the correct data back.

As for the mock-up, we have some seriously heavy-duty in-house simulators for that sort of thing. The reason we're not using them is because like I said, they are seriously heavy duty. We need something quick and simple.



So, what I'm hearing is that I need to write my own module/addon for Orbiter which will listen on a socket, tell Orbiter to restart the scenario and then jump to the correct time, capture the screen, and then send it back.
... I'm gonna need to look into module/addon development. Case in point: I'm not clear on the difference between a module and an addon.
*reads more documentation*

 

[Urwumpe]

Orbiter has a demo or "Kiosk" mode, which runs scenarios without user interaction.

Reading the documentation, it might be possible, that such a set-up of Orbiter in "Kiosk"-mode, showing short sequences of the Orion CEV in a dynamic setting might be a useful thing in presentations, but I can't tell if you can sell this to you boss.


You find this mode described in Orbiters manual on page 96.

An add-on is any extension for Orbiter, while modules are a special kind of add-on, dynamic link libraries, which get loaded by orbiter for more customized behavior, allowing a pretty large subset of the Windows API to be still used for the user interface.

 

[Rob Oplawar]

No, we're definitely looking for interactivity- the presenter should be able to jump to any arbitrary time in the mission timeline as requested by the audience.

Ok, so it looks like it's possible to get the behavior I'm looking for by creating a new module. Assuming I get approval on my side and permission on Dr. Schweiger's side, I'll give it a shot. I'll let you know how it turns out.
Thanks everyone- you've helped tremendously.

 

[Woo482]

how about Dynamically loading scenarios ?

 

[Hielor]

The problem with that is that Orbiter does take a long time to start up. You could write an add-on that's a "hot load" function, which can find a scenario file, delete all the vessels in the current scenario, propagate all planets to the correct time for the scenario file, then reloads the vessels. I couldn't see this process taking much more than a second even on an older computer.

Also per Woooooooo's comment above regarding dynamically loading scenarios. I don't think that this would be that difficult, but it still doesn't solve the problem of being able to arbitrarily change the launch time by ten minutes and still have it work.

The problem with that is that Orbiter is very much a real-time simulator; you can't change the start of the mission and have it propagate to the rest of the mission without significant up-front overhead (ie, re-running the whole mission). How quickly do you think you would need to be able to change the mission start time? If your data capture method was good enough, it wouldn't take more than a few hours. If you want to be able to have one of the discussion participants name a launch time and then request a point in the mission to see the ship...that can't be done in real-time using Orbiter.

Another option would be to have an external program calculate the orbital elements of the vessel at a given time and construct a scenario for orbiter that is hot-loaded for the screenshot. That's a lot more work, but that would allow for significantly more versatility.

 

[Rob Oplawar]

Oh, we're not worried about the data changing during the presentation- once the presentation starts, the data are the data. But the data can arbitrarily change between now and the presentation, and we're talking about a days long mission with thousands of associated data channels.

 

[Urwumpe]

Well, the problem is, that the latency of Orbiter might not be fast enough. Going back to a point in time (during the presentation) might also not be the best scenario for Orbiter.

I remember a screenshot tool, which was capable of recording automatically every x seconds. A simple solution could be running Orbiter with the latest possible simulation data and create a directory full of time tagged JPEG screenshots every x seconds, before the presentation. Now, a screen shot server application could just reply with a screen shot, when you give it a mission time.

Advantage: You can go back in time simply.
Disadvantages: View can't be changed after rendering the frames, You would need at least 3:20 hours to render a 14 day long mission at 100x time warp before the presentation can start.

You could improve this rendering by defining events and actions in the playback articulated stream, which would cause a frame to be grabbed - this way, long coast phases don't give you hundreds of equal looking frames.

 

[estar]

Again, the same data management problem. Our fallback plan is to record videos of the whole mission and have them jump to the appropriate video at the appropriate frame when jumping to a point in a mission. But I'd really like to avoid that. Ideally we should just give it the complete mission data file, which we can replace with the up-to-date one any time it changes, and just feobed it the timestamp and get the correct data back.

Orbiter loops through a simulation that updates the state hundreds times a second. It can't jump to a particular point without running through all the updates in between.

However Orbiter can record a vessel's flight and make it's path deterministic rather than the result of computation.

This means you can time accel really fast without losing accuracy. However you can't reverse it.

So what you need to do is right an add-on (a module) that allows you enter a target time. Use the api function

oapiSetTimeAcceleration

to set orbiter to run at 1000x or 10000x speed until the target time. Then use the function to slow it down to 1x.

If you have to go BACK then you will have to reload the scenario. If you don't use the high res textures and have a fast computer is should take a few seconds to reload.

This doesn't make Orbiter a clear advantage over a recorded video I realize. You will have decide if being able to dynamically change your view point, and directly controlling the vehicle is worth the loss of going back quickly.

As -up, we have some serioiusly heavy-duty in-house simulators for that sort of thing. The reason we're not using them is because like I said, they are seriously heavy duty. We need something quick and simple.

I only put that in because with orbiter you could use it to have something that runs on an astronaut's laptop that could use while flying, at home, or elsewhere they are not at the site with the heavy duty sims. In addition it gives a inexpensive platform to try ideas in a fairly accurate environment.

Rob Conley

 

[Rob Oplawar]

I've been trying to contact Dr. Schweiger for over three weeks now, and still haven't received a reply. Can anyone help me get in touch with him quickly, or barring that, does anyone have authority to give me permission to use Orbiter in this way? If I don't have a definitive answer by the end of next week I'm going to have to use my fallback visualization option, which is much less desirable.

 

[dbeachy1]

I pinged Martin again in the Beta Testing forum, Rob, and I also just sent him a PM. I'm sure Martin will get back to you soon.