Board index FlightGear Development Spaceflight

Space Shuttle

Discussion about development and usage of spacecraft

Re: Space Shuttle

Postby Richard » Mon Aug 15, 2016 5:25 pm

amalahama wrote in Mon Aug 15, 2016 4:14 pm:Any news about the overhead panel? This beauty is begging it badly.


The rest of the cockpit (overhead and rear sections) are something that I'm working on; but it's proving difficult and I don't have a lot of time at the moment. The basic problem is that these panels do not align with the cockpit that we have and the exterior model. It's like a 3d jigsaw as I rather foolishly resized the front cockpit section by itself to make it fit, and also the back of the mesh has the windows too high up.

This is where I'm currently at.

Image
Richard
 
Posts: 716
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: Space Shuttle

Postby Thorsten » Mon Aug 15, 2016 5:42 pm

It would be nice to have a second "launch" scenario from Vandenberg AFB and try to reach a polar orbit, as intended in STS-62 before Challenger accident. It's a specially interesting "what if" scenario. I don't know if current systems and autopilot could cope with it though.


You're thinking mission simulator, not flight simulator. You can simply start at Vandenberg (that's KVBG) - or you find out the launchpad coordinates and pass them as --lat=XXX and --lon=XXX to the commandline, set the launch guidance to a polar orbit and simply try it.

Or you edit the mission file... should be self-explanatory.

Easter Island is defined as landing site and has TAEM guidance - you can use it as TAL site (it's item 41 to 30 on SPEC 50). I think highest inclination I have tried is 67 degrees - but I see no specific reason why the AP wouldn't be able to do it.
Thorsten
 
Posts: 11120
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby amalahama » Tue Aug 16, 2016 12:42 pm

Richard wrote in Mon Aug 15, 2016 5:25 pm:The rest of the cockpit (overhead and rear sections) are something that I'm working on; but it's proving difficult and I don't have a lot of time at the moment. The basic problem is that these panels do not align with the cockpit that we have and the exterior model. It's like a 3d jigsaw as I rather foolishly resized the front cockpit section by itself to make it fit, and also the back of the mesh has the windows too high up.



Wow that's cool! I guess your trouble comes because external model and cockpit model don't come from the same source... hence the dimensional mismatch. In other sims, external model and cockpit model are totally independent and are differently shown either in external or cockpit views - external model only in external views, so 'cockpit' model must also include some parts for the external model visible through the windows, like wings, nose cone etc. I assume FG use one only 3D shape for all the views, which makes more difficult to match all the dimensions.

Thorsten wrote in Mon Aug 15, 2016 5:42 pm:
You're thinking mission simulator, not flight simulator. You can simply start at Vandenberg (that's KVBG) - or you find out the launchpad coordinates and pass them as --lat=XXX and --lon=XXX to the commandline, set the launch guidance to a polar orbit and simply try it.

Or you edit the mission file... should be self-explanatory.

Easter Island is defined as landing site and has TAEM guidance - you can use it as TAL site (it's item 41 to 30 on SPEC 50). I think highest inclination I have tried is 67 degrees - but I see no specific reason why the AP wouldn't be able to do it.


You're right, I will do it. My concern was that launch guidance/autopilot didn't take into account the loss of "earth-rotation" assistance when launched from high latitude to polar orbit...

Regards!
amalahama
 
Posts: 110
Joined: Mon Mar 28, 2016 9:54 am

Re: Space Shuttle

Postby Thorsten » Tue Aug 16, 2016 2:04 pm

My concern was that launch guidance/autopilot didn't take into account the loss of "earth-rotation" assistance when launched from high latitude to polar orbit...


Oh please... I wrote that thing - of course it does :-)
Thorsten
 
Posts: 11120
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Thorsten » Thu Aug 18, 2016 5:42 pm

Some first tests rendering the plasma sheath from within - this is a night scene for better contrast.

Onset of plasma builtup:

Image

Max heating phase:

Image

There's movement and structure to this which looks quite compelling (it runs via a dedicated GLSL shader), the light has a pulsating quality to it (and the alert observer might have spotted that the cockpit ambient light is influenced by the plasma glow).
Thorsten
 
Posts: 11120
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby amalahama » Fri Aug 19, 2016 8:28 am

It looks great!!

Regards
amalahama
 
Posts: 110
Joined: Mon Mar 28, 2016 9:54 am

Re: Space Shuttle

Postby Thorsten » Sat Aug 20, 2016 5:14 pm

Trying to teach the DPS parser to accept the extended syntax for entering multiple items.

You should now be able to use

ITEM 10 +1 +2 + +4 EXEC

which appears on the scratch line as

ITEM 10 +1 (11) +2 (13) +4 EXEC

and sets 10, 11 and 13.

Allowing to go back such a line using MSG CLEAR is a bitch - I've tested several cases and I found them working, but I don't vouch for this always getting right at this point... it's a surprisingly nasty problem to make that parser work.
Thorsten
 
Posts: 11120
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Hooray » Sat Aug 20, 2016 5:21 pm

Thorsten wrote in Sat Aug 20, 2016 5:14 pm:Trying to teach the DPS parser to accept the extended syntax for entering multiple items.[...] I've tested several cases and I found them working, but I don't vouch for this always getting right at this point... it's a surprisingly nasty problem to make that parser work.


I haven't looked at any of your code or the other postings in this thread, but you may want to read up on using a so called state machine, and in particular, a "stack" to implement the parser - in fact, even just spending 5 minutes working through the wikipedia article on "parsing" may save you tons of time, because parsing is a well-understood problem these days, with standard solutions that will often work pretty well for the more common cases.

I also haven't looked at the shuttle specs or the syntax you need to support, but usually these things are relatively straightforward once they are tackled on by one (think tokenization, keywords, operator precedence etc)

If in doubt, feel free to re-state the problem here, so that we can post a little code to get/keep you going. Again, without having looked at any of the code, tons of nested if-statements (expressions in Nasal) are quite possibly the worst (as in most complicated, and least maintainable) approach one can take to implement a parser like this, especially if its syntax can be exrepssed in BNF/EBNF - just imagine what the parser for XML, Nasal (or GLSL) would look like ...
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Thorsten » Sat Aug 20, 2016 5:33 pm

The problem is simply that there's one string you type

ITEM 10 +1 +2 + +4 EXEC

one string you display

ITEM 10 +1 (11) +2 (13) +4 EXEC

and three strings that really carry meaning

ITEM 10 +1 EXEC
ITEM 11 +2 EXEC
ITEM 13 +4 EXEC

That makes it more nasty than your standard parsing problem, because sometimes you need to operate on all elements, but sometimes not (for instance, pressing two delimiters ++ alters the display part without (at the stage you press it) the meaning part. It's the requirement to keep it all coherent and in-sync which is hard,

Again, without having looked at any of the code, tons of nested if-statements (expressions in Nasal) are quite possibly the worst (as in most complicated, and least maintainable) approach one can take to implement a parser like this


I think you misunderstood how it works... the if-statements don't do any parsing, they're just selecting which command is executed based on parsed results.
Thorsten
 
Posts: 11120
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Hooray » Sat Aug 20, 2016 5:41 pm

Like I said, I haven't actually looked at any code (yet), I only just looked at the wiki article to see if it contains any implementation details - but obviously, you are free to do whatever you want to do - I was just pointing out that there are fairly accessible standard solutions, while other approaches may be/become unnecessarily complicated (over time).

As far as I can tell based on googling the syntax/functionality, you are about to re-implement a virtual machine (VM) in Nasal, depending on what you have in mind, it may save you tons of time to look at standard solutions for tokenizing/parsing the corresponding command streams, and to use a state machine (stack, as in Nasal vector/resizable array) to implement the whole thing.

I only looked very briefly at: http://www.spaceshuttleguide.com/system ... h_pad_line
But it seems like a natural fit to implement this functionality using a tokenizer and a command stream parser.

Anyway, really no offense intended - you obviously spent tons of time working through the requirements/syntax and specs (which I won't do), so all I was trying to provide are pointers on standard approaches to parsing (think pocket calculator, think RPN, LL(1), recursive descent parsing) - depending on your current approach, you may find that a recursive descent parser would be only a fraction of the size of your current code, while being 100% bullet-proof without requiring any weird workarounds, i.e. satisfying everything that you would currently consider "fragile".

PS: Regarding your last comment, that is what is commonly achiveved using a bytecode interpreter in the form of:

Code: Select all
var plus = func(ctx) {
print("Calling plus");
};

var minus = func(ctx) {
print("Calling minus");
};

var nop = func(ctx) {
print("Calling nop");
};

var OPCODES = {OP_PLUS: plus, OP_MINUS: minus, OP_NOP: nop};
var COMMAND_STREAM = [OP_PLUS, OP_PLUS, OP_MINUS, OP_NOP];

var context = {stack:[]};

# bytecode interpreter loop
for(var i=0;i<size(COMMAND_STREAM);i+=1) {
var opcode = COMMAND_STREAM[i];
OPCODES[opcode] ( context );
}

Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Thorsten » Sun Aug 21, 2016 5:28 am

Call me old-fashioned, but I really want to keep the implementation close to how the Shuttle does it. There the IDP in charge does the parsing (which is why there's a separate parser for every major mode), then the GPC checks whether the command is legal given current OPS and SPEC (which is why a separate code block is run for every OPS and SPEC), then the command is executed by the software corresponding to that OPS/SPEC.

Of course you could all do it with hashes within hashes rather than conditionals within conditionals - I don't really see the advantage (how, other than by evaluating conditionals, will the hash know what to do with a key after all?), but I do see that this makes the code more opaque - which is a bad thing in this context in my view.

I am actually happy with the parser code structure - the generalization from one keyboard, one IDP, one screen to three keyboards, four IDPs and nine screens was a matter of an hour or so.

In any case, it works - and I don't see how you get around fairly complicated indexing to keep coherence no matter what solution.
Thorsten
 
Posts: 11120
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby amalahama » Sun Aug 21, 2016 4:31 pm

Impressive. If someday NASA publish Shuttle GPC SW source code, as they did with AGC, would nasal be powerful enough as to 'emulate' and execute the SW in real time? The Orbiter's guys have been able to wire a DSKY emulator running real Apollo 11 AGC SW with the simulator - and did some sucessfully TLI burns with it!

Regards!
amalahama
 
Posts: 110
Joined: Mon Mar 28, 2016 9:54 am

Re: Space Shuttle

Postby Thorsten » Sun Aug 21, 2016 4:43 pm

You're asking whether 2016 hardware can run an emulator for 1970 hardware in real time? I'm pretty sure it can. Take things like we always switch screens instantly for an OPS transition - it doesn't take 60 seconds to load new software. 60 seconds is an eternity these days...

However, personally I'd rather be the guy who writes the spaceflight guidance software than the guy who writes a hardware emulator to run stuff others have written... So my pet project is to write software that does the same things to see whether I can come up with reasonable solutions, not to re-do or make work the original software.
Thorsten
 
Posts: 11120
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Hooray » Sun Aug 21, 2016 4:55 pm

The question isn't that far-fetched actually - writing an emulator for 70s style embedded hardware to run existing code is certainly much less work than coming up with the corresponding equivalent of said software from scratch - sooner or later, you would hit a breakeven point, just look at the plethora of existing c64 emulators so that people can still run all those old arcade games, or all those 8086 and 8051 emulators.

The other question is whether source code (or even just bytecode) of the corresponding avionics is ever going to be made available, and if it is made available, whether it will be in a form that can be adapted for these purposes, i.e. there's more than just the CPU/micro-controller to be supported, there is usually tons of embedded hardware, which isn't as easily emulated.

As a matter of fact, I think I already mentioned this once: at some point (as in a decade ago), the highest fidelity GPS device available for FSX and X-Plane was the Garmin GNS 430/530, and what they're really doing is running the freely available Garmin GNS trainer (simulator) and hooking it up to various FSX specific internals (think position, altitude, orientation, velocities etc), while capturing the output of the device and displaying it as a texture in FSX/X-Plane respectively.

Quite honestly, you cannot get closer to the real thing than using this approach...

Note that this "simulator" (trainer) actually runs a subset of the original firmware of the real device, i.e. is commonly used by pilots for familiarization purposes, and by developers for testing/developing features, which also means that it does contain a corresponding AIRAC cycle (navdb equivalent in FG).

Thus, the idea/approach really is very sound, and at some point much more feasible than re-implementing such software/functionality from scratch, especially given the time, skills and expertise required to read up on all the specs and then re-implement those; in comparison, implementing an emulator (or even a simulator) is much less work in comparison, and much more self-contained, especially for people with a CS/SE background who are familiar with compiler construction and VMs.

Given that many others around here don't have Thorsten's background regarding maths, physics and spaceflight, the VM/emulation path would be the only sane option under different circumstances.


http://www.reality-xp.com/flightsim/gns530/
http://www.mindstaraviation.com/product_430_530.html
https://www8.garmin.com/support/downloa ... sp?id=3529
https://www8.garmin.com/support/downloa ... sp?id=3531
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby Thorsten » Sun Aug 21, 2016 5:11 pm

Thus, the idea/approach really is very sound, and at some point much more feasible than re-implementing such software/functionality from scratch


Please do read the section in the crew manual that talks about how the OMS fuel level is really determined by the Shuttle software. It combines measurements from several sensors with interpolation across a no information zone.

If you want the original software to show a simple fuel reading, you'd have to doctor the virtual sensor readings 'just right' that it concludes the roughly correct values.

I've gone down divorcing JSBSim truth from what the guidance software is allowed to know in some cases, and every time the workload literally goes through the roof.

I'd carefully keep 'possible' and 'more feasible' apart here...
Thorsten
 
Posts: 11120
Joined: Mon Nov 02, 2009 8:33 am

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 1 guest