Board index FlightGear Development Spaceflight

Space Shuttle

Discussion about development and usage of spacecraft

Re: Space Shuttle

Postby Hooray » Sun Aug 21, 2016 6:26 pm

no offense intended, but let's cut the hair-pulling - I am sure you can come up with dozens of niche cases that you think prove me wrong, while I will not look at any of the manuals - which is the whole point of my statement: Emulating hardware using a bytecode interpreter loop can get you 90% of the functionality, without having to code any fancy (nested) conditional blocks, using standard solutions that are well-understood by anybody who's ever attended a CS/SE course on compiler construction, which is not to say that it will be a complete solution - but that the breakeven point very likely favors the bytecode approach, IFF the corresponding code is made available, and in a form that is suitable to be adapted as necessary.

You literally need to have a strong background in maths and physics to make heads and tails of the system specs, whereas creating a VM that runs bytecode instructions is a much more self-contained job, that would get you tons of functionality without having to be/come a spaceflight expert, in a fraction of the time, requiring a fraction of the skills (a bytecode interpreter is commonly implemented by CS students in their 1st or 2nd year); leaving you with much more time to become an expert in the remaining areas for which the bytecode/VM approach does not suffice (think your example).

Anyway, it's kinda academical to discuss this for the time being, because as far as I know, the corresponding source code (or even just bytecode/firmware) is not readily available in any suitable form - so that what you are doing is the only feasible option, regardless of the barrier to entry and steep learning curve this involves.

Don't get me wrong, I absolutely admire your dedication - but the question posted above is valid, even though theoretical.

Even just coding "Pacman" from scratch is more work than coming up with an emulator to run the real thing (think ~20-30 essential CPU instructions), the other/added work (mapping I/O to/from the virtual screen/keyboard) should not distract from that fact.

My earlier comments/proposal to actually use a tokenizer and create a parse tree to process these command streams is unrelated to the VM/emulation discussion, and like I said, I never really looked at the code in question, the comment was merely in response to the challenges you mentioned, which are unlikely to remain challenges if a tokenizer and a parse tree are used - as a matter of fact, the whole many-to-one and one-to-many mapping is also a common issue for Nasal code, just imagine how many valid syntax trees there are to create a func expression:

Code: Select all
var x = func() {};
var x = func() {}
var x = func {};
var x = func {nil};
var x = func {nil;};
var x = func {return nil};
var x = func {return;};
var x = func {return};
var x = func return;


Under the hood, the parser (and codegen( will internally patch up the abstract syntax tree (AST) to end up with the same syntax tree representation.
Depending on how you are currently parsing the grammar of the IDP (?), your approach would also work for this grammar (Nasal funcs) requiring very minor changes, or not work at all.

If the latter is true, it's likely that you are using tons of nested conditionals to implement state machine-like functionality.

Basically, the point of a EBNF grammar is to come up with recursively defined rules forming the grammar of your "language", and provide callbacks that check for these rules, and build a syntax tree, which is then either interpreted directly, or used by a code generator to create bytecode (which is how Java, JavaScript, but also Nasal works).
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Space Shuttle

Postby Thorsten » Mon Aug 22, 2016 6:33 am

You literally need to have a strong background in maths and physics to make heads and tails of the system specs, whereas creating a VM that runs bytecode instructions is a much more self-contained job, that would get you tons of functionality without having to be/come a spaceflight expert


The difference is that Pacman doesn't monitor thousands of input channels. It's not getting the software to run that's the problem, it's getting it into a context in which it is meaningful.

If you don't feed a data stream corresponding to engine readouts in the right format, the software will conclude that the engine has failed. If you don't feed a data stream corresponding to carefully doctored OMS tank sensor readings, the software will conclude that there's no OMS fuel available.

Unlike Pacman, this is special-purpose software, written to run in the Shuttle only, assuming that there are various bits of hardware connected which constantly communicate in some given way. So you don't need to code some I/O mapping from virtual screen and keyboard, you need to code thousands of I/O mapping for thousands of channels - and you need to have a simulation of plausible raw sensor output for thousands of sensors.

So emulating the GPC hardware will get you basically a test mode, not 90% of any functionality - not even any graphics output because that's done by the IDPs.

It's fairly obvious this can't work like you expect it to, quite independent of the coding approach.

requiring a fraction of the skills (a bytecode interpreter is commonly implemented by CS students in their 1st or 2nd year)


I'm sure this works for Pacman, sadly a spacecraft is not the same problem. Also, I can sort of see how this can be made to work with Apollo software (which is kind of a glorified pocket calculator) - but the Shuttle is several orders of magnitude more complex.

Under the hood, the parser (and codegen( will internally patch up the abstract syntax tree (AST) to end up with the same syntax tree representation.


... which it does right now.

Look, obviously it's kind of strange to have this discussion as long as you don't know how the code works internally and just write about 'fancy (nested) conditional blocks'.

The code accepted the generalization of the parser rather gracefully at the expense of adding a few more states and some 40 lines - as far as I can see the difficulties are there on the abstract level (i.e. get the rules consistent) - they're going to bite you no matter in what form you formulate the algorithm.

I sort of meant to write a post to inform about progress being made, I thoroughly regret doing that right now.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle

Postby amalahama » Mon Aug 22, 2016 7:58 am

Well, we are not that far off from getting the original Space Shuttle GPC SW, I know there are several groups actively pursuing it (inclunding people in the orbiter SSU team) and lately NASA has delivered tons of guidance, navigation and other SW source code from other space programs, so it can happen anytime. BFS won't happen though, since it's Rockwell property, but it could with PASS software, since it was developed by NASA entirely.

When the time arrives we will see but it's clear that using original PASS SW will require a development from scratch, due to GPC being so high integrated into all Shuttle systems. Even for Apollo project, not all AGC features are functional and only with the "simulated" version of the AGC a complete mission is possible to run; however it's very sexy to operate a real ('emulated') DSKY with all the nuances of the real thing, and the overall interest incresed a lot when the news hit the Orbiter forum.

I have to say however that Thorsten DPS implementation just excel any other and it's not neccesary to get 'anxious' about the possibility of getting the PASS code any time soon

Regards

**-- EDIT--**

I've just found a video of somebody who wired the AGC emulator inside Orbiter to an arduino to create a physical, functional DSKY... now how cool is that :D

amalahama
 
Posts: 149
Joined: Mon Mar 28, 2016 10:54 am

Re: Space Shuttle

Postby amalahama » Thu Aug 25, 2016 7:26 am

So I did some testing yesterday and I find PFD refresh rate annoying.

Not only it's a performance hog, but also refresh rate is low for a flight-critical instrument (I've seen videos from STS simulator and PFD works smoothly as expected). I have the feeling that, even if I solve the problem with fps, MEDS refresh rate is somehow "throttled" to a certain value, which is fine for DPS, but impacts negatively on PFD.

For the record, I have a 5th gen i5 with a GTX970 and 16GB RAM. With high detailed PFD but almost every option in rendering options checked out, I'm not able to get more than 20-25 fps on launchpad...

Regards!
amalahama
 
Posts: 149
Joined: Mon Mar 28, 2016 10:54 am

Re: Space Shuttle

Postby Thorsten » Thu Aug 25, 2016 7:29 am

Clock it up then - it's configurable runtime via slider. And move ADI ball quality down to get more framerate - it's another slider.

(Graphics card is unimportant for that one, it's property IO which is the bottleneck. Canvas isn't designed for this, I suppose eventually I'll move the ADI to GLSL shader code...).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle

Postby Hooray » Thu Aug 25, 2016 7:37 pm

Thorsten wrote in Thu Aug 25, 2016 7:29 am:(Graphics card is unimportant for that one, it's property IO which is the bottleneck. Canvas isn't designed for this, I suppose eventually I'll move the ADI to GLSL shader code...).



I don't want to hijack your thread again or offend you with my comments, but like I said previously, I know how to reduce the property I/O so much that most of what will remain is pure C++, it will roughly require 50+ lines of code so that most Canvas elements can be property-driven without going through Nasal space, which also means supporting printf-style format strings. At that point, Nasal will only be used to set up, e.g., labels that consist of a sub-tree of properties that are read and formatted by C++ code.

I don't know who's currently reviewing patches or who has commit access these days (bugman, Richard, you ?), but I think it would be much less work to extend the Canvas system so that its elements can be updated without going unnecessarily though Nasal space, and yes, I can help provide the corresponding patches.


A few months ago, I also posted patches to support loading/transforming 3D models from disk, as dedicated Canvas elements

I am only saying this (again), because I believe it to be much less work than re-implementing the ADI ball in GLSL - which would also mean that this would be the first instrument/cockpit to actually require shaders.

Ultimately, it is obviously up to you, I don't have any preference other than lacking the GLSL background you have, and thinking that these changes would also benefit other efforts (aircraft, cockpit and also the UI effort specifically).

PS: No need to turn this into a debate, if you want me to shut up or talk about this elsewhere, feel free to shoot me a PM.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Space Shuttle

Postby Thorsten » Fri Aug 26, 2016 7:04 am

I don't want to hijack your thread again or offend you with my comments, but like I said previously, I know how to reduce the property I/O so much that most of what will remain is pure C++,


The actual workflow is

1) an algorithm generates a mathematical representation of what you see in a series of points into an array
2) that array gets written to properties to be picked up by canvas
3) there properties get translated to paths in texture space

The bottleneck is 2) - I have a large array to write. Now, whether porting to C++ helps or not depends on whether writing properties is significantly faster from C++ than from Nasal. The Nasal code itself is fast enough for all practical purposes.

The idea of using a GLSL shader is that unlike the property tree, GLSL is made to directly bring a mathematical representation of something on-screen - so basically you're only left with 1) and have massive parallel processing and hardware support for the math.

Since we have a working instrument now, it can simply be kept 'as is' for those who don't run shaders.

In any case, I've tested on my windows setup that I get very flyable framerate with the current instrument. I would like to remind everyone that currently the priority is to get the Shuttle code to work for all systems, not to optimize it - that will be done later.

20-25 fps is very flyable (and since I got above 35 fps even before enabling the more agressive culling with my GTX670, I think there's more to be gained by optimizing FG-side rendering settings (in particular I suspect selecting multi-threading might help with property IO problems).

Also, the Shuttle cockpit is a nightmare for every graphics card, because it's a very detailed mesh with (and that's the worst part) hundreds of movable parts - which means hundreds of draws because every movable part needs its own state set. That's lots of overheat for the renderer to struggle with. There's really nothing I can do about that (usually we merge meshes to minimize draws, but that means de-activating all switches).
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle

Postby wlbragg » Fri Aug 26, 2016 8:00 am

usually we merge meshes to minimize draws

If I merged all the cockpit objects (panels, panel framing, guards, fasteners, etc.) into one mesh, excluding any animated objects, would that gain much frame rate?
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Space Shuttle

Postby Thorsten » Fri Aug 26, 2016 8:04 am

Say you have (ultimately) 500 switches, talkbacks etc. which all need their own state set. Each time it costs a fixed time on the GPU to process it.

If we manage to merge 10 objects, the performance gain is ~10/500 times the time constant, aka not that much.

The prime examples where this worked was OSMtoCity where you had 20.000 separate draws, merged them into one object with one draw and suddenly had 20 fps more.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle

Postby amalahama » Fri Aug 26, 2016 8:13 am

Thorsten wrote in Fri Aug 26, 2016 7:04 am:
20-25 fps is very flyable (and since I got above 35 fps even before enabling the more agressive culling with my GTX670, I think there's more to be gained by optimizing FG-side rendering settings (in particular I suspect selecting multi-threading might help with property IO problems).


In my case what makes it so annoying is that I'm not getting a strong 25 fps, but it flickers a lot between 15fps and 30 fps, and I only get that behaviour when PFD is set at maximum - with PFD set at minimum or no PFD selected in any MEDS, the stuttering disappear.

Yet I admit I need to perform some adjustements in the main program side, because overall FG performance with any addon is clearly below my desktop should be (and is in other simulators) able to do.

By the way, the other day I was reading a bit about nasal in the wiki and it stroke me that nasal loop is tied to fps. Is it not possible to run nasal in a different thread and only perform the property tree checking/modification in the main loop? I thinking for example in running PEG-4 estimators - it needs some iterative calculations that can take time, and it would block the main loop until the operation is done. Another possible benefit of running systems in a different thread is that those system not directly related with FDM can have a different "property tree" with ad-hoc refresh rates for example - probably a 60Hz refresh rate is not neccesary for electrical voltages.

Regards
amalahama
 
Posts: 149
Joined: Mon Mar 28, 2016 10:54 am

Re: Space Shuttle

Postby Thorsten » Fri Aug 26, 2016 9:29 am

In my case what makes it so annoying is that I'm not getting a strong 25 fps, but it flickers a lot between 15fps and 30 fps, and I only get that behaviour when PFD is set at maximum - with PFD set at minimum or no PFD selected in any MEDS, the stuttering disappear.


The difference between max. and next to max is the number of points per line drawn, which primarily affects the precision of the clipping at the edges. If you can live with a line sticking a pixel or two beyond the clipping circle, just don't run it at max, it creates 4 times the property overhead.

By the way, the other day I was reading a bit about nasal in the wiki and it stroke me that nasal loop is tied to fps. Is it not possible to run nasal in a different thread and only perform the property tree checking/modification in the main loop?


Possible yes, but in my view it has no real gain/pain ratio, because you have to really factor out *all* property IO because that is not thread-safe - and that's an annoying requirement.

You have to be aware that Nasal as such is pretty fast -and it's usually Nasal interacting with FG via the APIs that is slow - you can calculate a hundred Nasal cosines for the price of one property writing, and more than thousand for one terrain elevation query.

So there's usually very little point in optimizing Nasal algorithms per se, the only thing that helps is to reduce usage of the expensive APIs (and at least in the terrain case, they're just as expensive from C++ because that's what the Nasal basically calls).



I thinking for example in running PEG-4 estimators - it needs some iterative calculations that can take time, and it would block the main loop until the operation is done.


They don't block the main loop though - they're implemented to perform a small number of operations per frame and then wait for the next frame. At worst they're probably 1/10.000th of the load the ADI creates at max. quality with its property IO requirements. Threading them out would likely give you the result faster, but I suspect it's still unrealistically fast as it's implemented - so why bother?

Another possible benefit of running systems in a different thread is that those system not directly related with FDM can have a different "property tree" with ad-hoc refresh rates for example - probably a 60Hz refresh rate is not neccesary for electrical voltages.


Again, they can be set to be updated every nth frame - which we're going to do eventually.

But neither of these is creating a bottleneck on any system I know - the bottleneck is rendering the cockpit on lower GPUs and the ADI-created property IO when this is at high quality if the GPU is fast enough.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle

Postby legoboyvdlp » Fri Aug 26, 2016 3:28 pm

Oh my.
Absolutely marvelous.
I can't run it at the moment (I probably could, but I don't believe 4-5 FPS is good for accurate simulation of such a complex aircraft, apart from which it would fry my GPU :)), but at least I can enjoy the screenshots and well, look at this beautiful computer!

With a summer job, I would need to work 260 hours (at UK minimum 16-17 wage) or so to earn enough money, so 10 weeks :)
User avatar
legoboyvdlp
 
Posts: 7981
Joined: Sat Jul 26, 2014 2:28 am
Location: Northern Ireland
Callsign: G-LEGO
Version: next
OS: Windows 10 HP

Re: Space Shuttle

Postby Hooray » Fri Aug 26, 2016 6:40 pm

Like Thorsten said: the Nasal threading thing actually works, with the exception of FG specific extension functions (so called APIs), which also means property I/O is generally not thread-safe - the private property tree thing has also been discussed on and off, and also with a focus on HLA.
If you are interested in these topics, my suggestion would be to check out the wiki to learn more.

Regarding Nasal and its performance, one the key points to understand there is the garbage collector (also documented in the wiki).

However, the "different property tree" idea is a long-standing proposal, suggest by many core developers - and Stuart's HLA work also makes this idea increasingly relevant.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Space Shuttle

Postby Thorsten » Sat Aug 27, 2016 6:26 am

However, the "different property tree" idea is a long-standing proposal,


Well, since the instrumentation is supposed to display and change the state of the Shuttle and that's simulated by the JSBSim part of the property tree, a separate tree for the instruments doesn't exactly help - they wouldn't know what to display and entering items couldn't do anything.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Space Shuttle

Postby Hooray » Sat Aug 27, 2016 6:09 pm

That is correct, I don't disagree with that - but the proposal is not specific to this particular use case, and regardless of this, having subsystem-specific sub-property trees is not a new ideal either - in fact, the whole /fdm approach, and its integration via the FDMShell layer, basically allows a FDM to have its own "private" property tree, that is "mounted" in the global tree (using tied properties in the case of JSBSim, most of which are thus read-only). The real advantage is encapsulation of state, and having better formalized synchronization/replication of property state across subsystem, and eventually process (HLA), boundaries.

For additional info, see for example James' original proposal at: http://wiki.flightgear.org/Property_threading
Or Erik's proposal summarized at: http://wiki.flightgear.org/Remote_Properties
http://wiki.flightgear.org/High-Level_Architecture

Anyway, this is clearly offtopic - the idea still is sound, it just won't have any immediate effect on the shuttle or other aircraft until some core changes are committed.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 7 guests