Board index FlightGear Development Spaceflight

Space Shuttle

Discussion about development and usage of spacecraft

Re: Space Shuttle

Postby Hooray » Tue Apr 19, 2016 9:44 pm

Orbiter's SSU is under common license, IIRC. If they agree to donate its virtual cockpit for FG Shuttle, would it be possible to import it? Their cockpit is very mature and almost all main panels are already available, and my impression is that labels are more readable. Just saying.


Their work, even if only their artwork, would need to be either licensed in a GPL-compatible way or simply be in the public domain, i.e. textures/3D models etc.
Apart from that, my understanding is, based on Thorsten's discussion with the Orbiter folks, that their way of creating these displays is fairly tedious and not exactly compatible with the way FlightGear works in general - the only thing that /might/ be feasible is having a standalone application, and some piece of middleware, acting as "bridge" to connect the standalone SSU application to FlightGear - not unlike the opposite we discussed yesterday when we were contemplating about hooking up FlightGear's MFD work to Orbiter.

Technically it's definitely possible, if it's worth it is a completely different issue - and as far as I can tell, it looks like FlightGear's modular way of creating these avionics/front-ends (i.e. the MFDs) using Nasal scripting and its built-in 2D rendering engine, is very much "superior" to having to hard-code such things in C++ space, even if that may mean that the underlying subsystems (Nasal/Canvas) may need to be extended/improved or optimized for certain use-cases.

In general, it would even be possible to hook up a FlightGear cockpit to FSX and vice versa - it's just a ton of "bridging" work to match the various data elements required on each side.
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: 11375
Joined: Tue Mar 25, 2008 8:40 am

Re: Space Shuttle

Postby amalahama » Tue Apr 19, 2016 9:46 pm

Hooray, I'm referring to the 3D cockpit model only, I assume Orbiter and FG SDKs and visual APIs are so different, that a common approach to modeling displays is just not possible without extensive work from both sides.

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

Re: Space Shuttle

Postby Richard » Tue Apr 19, 2016 10:29 pm

amalahama wrote in Tue Apr 19, 2016 9:34 pm:Honestly, I'd not be so worried about the visual aspect of PFD, but with the complex functionality, since there are several modes depending on flight phase and pilot customization. I'd rather prefer a proper implementation of all modes (including HSI as well of course) with just interim visuals (until SVG/procedural is available) than the other way around.

If they agree to donate its virtual cockpit for FG Shuttle, would it be possible to import it? Their cockpit is very mature and almost all main panels are already available, and my impression is that labels are more readable. Just saying.


1. If you draw roughly the required pages (one per SVG) and send them over I'll animate them. Any guidance on how they should work would help this process. Although I got stuck drawing the pictures there is a lot of work for me to understand the displays enough to animate them, and any information would be welcomed.

2. Again if you get a set of textures we can look at them. Our textures have come from photographs, so they may not be as crystal clear as newly made textures. I personally prefer this as it feels quite realistic, however if you want to improve them the main textures are in the repository here: https://sourceforge.net/p/fgspaceshuttl ... s/Artwork/ files fwd-cockpit-text-map-x.xcf and shuttle-centre-console.xcf

We already have probably hundreds of hours invested in our 3d-cockpit, so there'd have to be a very good reason to change to a new one, especially as I don't think there's actually anything really that wrong with the current mesh.
Richard
 
Posts: 726
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: Space Shuttle

Postby amalahama » Tue Apr 19, 2016 11:10 pm

Regarding the 3d cockpit, I understand the big amount of work behind FG Shuttle cokpit in its current state and it looks great even with its limitations. But SSU cockpit has all, every switch, 3D modeled, not only in pilot and copilot panels, but the aft as well, including also overhead; work in SSU cockpit art started in 2009, and it will take long until FG Shuttle cockpit reaches the same status. I'm just trying to be constructive and avoid duplications, in those areas where certainly the artwork could be reused.

I'm certainly not an artistic guy, but you will find very good templates in vector graphics for PFD in the DPS Dictionary, pages 6-8, 6-22, 6-23, 6-24. ADI functionality depends on flight phase; and the ADI reference will vary according to the position of ADI mode switch (INRTL, LVLH or REF). The proper functionality is better described in the documentation; but one of the most interesting features of PFD are the error bars in ADI and HSI, which provide some guidance under manual control.

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

Re: Space Shuttle

Postby Johan G » Wed Apr 20, 2016 5:07 am

amalahama wrote in Tue Apr 19, 2016 9:34 pm:[...] ADI ball is 3D in the real thing, though the implementation looks pretty basic

https://www.youtube.com/watch?v=xNSqhjA3JfM

Look closer. More like 2.5D. ;)

At first I thought that the PFD illustrations in the crew operations manual* was slightly simplified, but looking at the first video you linked to it looks like they are accurate. In essence the ticks and labels on the ball seem to always be at right angles and their sizes do not scale. I think this likely would be because they are a bit more legible that way.

Regarding modes, I have noted the use of red outlines and sometimes diagonal crosses to mark inoperable parts of the display when looking at simulator landings.

I have not looked all that much for it, but is there some very specific documentation on the PFDs, with all operating modes and failure modes?

* Shuttle Crew Operations Manual, December 15, 2008, pages 2.7-3 -- 2.7-11.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5545
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Space Shuttle

Postby Thorsten » Wed Apr 20, 2016 5:47 am

Whew, plenty of discussion...

Procedural elements - I don't know if anyone noticed, but I'm using the idea already (the predictor circles on ASCENT TRAJ or HORIZ SIT are drawn by simply calling a function that returns a vector with the vertices for the path.

I've toyed with the idea of coding various ladders the same way (it'd be easy to write the function), but I found it faster to simply add them to my SVG line-drawing workflow.

Now, I confess I'm not sure what the issue with th ADI sphere is, sorry. I thought it's basically something like a HUD - with a pitch ladder that also shows roll as well, surrounded by a heading ring. We can do HUDs in canvas - so what's the specific problem here? Why is it different?

I don't think the math is particularly complicated, and in fact from all shots I have seen (can't really watch movies), it does not look like an actually projected sphere (there ought to be distortions of symbols at the edges, it looks like some trigonometric corrections applied to a 2d structure. I can certainly come up with a function that draws ladders (even with lots of customized complexity) if that is what is needed to make progress. Compared with procedurally generating cloud formations, that's a piece of cake :-)

By the way, Orbiter's SSU is under common license, IIRC. If they agree to donate its virtual cockpit for FG Shuttle, would it be possible to import it? Their cockpit is very mature and almost all main panels are already available, and my impression is that labels are more readable. Just saying.


Possible - yes, SSU is LGPL. Desirable?

My understanding is that Chris Kuhn's cockpit mesh we're using is quite detailed as well - in fact that's the problem, because it's the reason Richard and Wayne had to spend a lot of work reducing it's complexity (it's the #1 framerate killer in the Shuttle at the moment) and also the reason we don't have the complete mesh in.

I've tried in vain to locate SSU cockpit screenshots to get a comparison - from what I found (YouTube starting stills mostly), I have to honestly say I prefer the potential of Richard's work. The textures extracted from photographs give an impression that's hard to match otherwise. True - it might still take a long time to get it all ready, but I'm trying to evaluate the potential. Maybe you can post shots yourself for comparison (I'd have to get out my windows box and see what Orbiter installation I actually have (it's been a while), then try to acquire and install SSU,... - I'm really a Linux guy...)

Also, note that a sizable chunk of work is not just getting the mesh - it's separating the switches, animating them and hooking them up to control properties. So even if we had a complete mesh tomorrow, we wouldn't have functional switches, nor would we have all the systems modeled.

A small request: It's possible to make an option to assign num pad to shuttle keypad?


I use the num-pad for flying (the ability to center controls is just hard to beat with the mouse) - but this is FG - you can edit your setup however you want at the expense of writing a little xml, there's no need to ask for support for this.

Key bindings look like this

Code: Select all
   <key n="4">
    <name>Ctrl+d</name>
    <desc>Force external tank drop</desc>
    <repeatable type="bool">false</repeatable>
    <binding>
     <command>nasal</command>
     <script>SpaceShuttle.force_external_tank_separate()</script>
    </binding>
   </key>



and the particular bindings you want to execute are

Code: Select all
<binding>
         <command>nasal</command>
                   <script>SpaceShuttle.key_msg_reset(1)</script>
</binding>


The list of current bindings for the mouse-driven keyboard is in SpaceShuttle/Dialogs/dps_keyboard.xml

and the argument of the function being called is always the keyboard ID (the virtual keyboard is assumed to be the CDR-side keyboard).


The proper functionality is better described in the documentation; but one of the most interesting features of PFD are the error bars in ADI and HSI, which provide some guidance under manual control.


Without delving into the details, but that seems to be standard technology familiar to anyone who has ever done radio-navigation in an airplane and can operate a VOR receiver.
Last edited by Thorsten on Wed Apr 20, 2016 5:48 am, edited 1 time in total.
Thorsten
 
Posts: 11191
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby amalahama » Wed Apr 20, 2016 5:48 am

Johan G wrote in Wed Apr 20, 2016 5:07 am:
Look closer. More like 2.5D. ;)


I don't think so. The video is recorded in KSC Space Shuttle Simulator during atmospheric flight (with catastrophic consequences... :roll: ). If you have a look to DPS Dictionary (page 6-8 onwards, it's the nearest thing to an specific PFD documentation I've found), you will find that during atmospheric flight, yaw attitude in the ADI is fixed at 0 (like in the video) BUT it's not the case during orbital flight... so indeed the ADI ball has 3 DoF.

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

Re: Space Shuttle

Postby Thorsten » Wed Apr 20, 2016 6:03 am

Johan means the same thing I do - if you texture a sphere and project it using the standard 3d toolkit, the ladders won't appear equally-spaced at the edges, nor at right angles.

So projection is not what the PFD does - what degrees of freedom it shows is a different matter.
Thorsten
 
Posts: 11191
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby amalahama » Wed Apr 20, 2016 6:11 am

Thorsten wrote in Wed Apr 20, 2016 6:03 am:Johan means the same thing I do - if you texture a sphere and project it using the standard 3d toolkit, the ladders won't appear equally-spaced at the edges, nor at right angles.

So projection is not what the PFD does - what degrees of freedom it shows is a different matter.


I cannot say how the visual are represented, but definitely it's not like a 737 ADI, not just ladders over a circle, there is also a yaw DoF

From DPS Dictionary, page 6-10

Attitude Determination Indicator (ADI) – Simulated enclosed ball and digital readouts. The ball
provides three degrees of freedom
, allowing it to be positioned in response to software generated
commands corresponding to the Orbiter roll, pitch, and yaw attitude. The numbers on
the ball and around the case are angle magnitudes, with the trailing zero deleted for simplicity.
The digital readout (5a in the illustration) is expressed in Orbiter Roll, Pitch, and Yaw
corresponding to the ADI ATTITUDE switch setting (INRTL, LVLH, or REF). A vehicle symbol is
provided fixed to the center of the ADI window as a reference.


Maybe it uses some kind of spherical projection? Ortographic seems to fit well...

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

Re: Space Shuttle

Postby Johan G » Wed Apr 20, 2016 6:19 am

There is no reason why 3 DoF cannot be represented in 2.5D or even 2D. :P There might be a misunderstanding here. ;)
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5545
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: Space Shuttle

Postby amalahama » Wed Apr 20, 2016 6:27 am

Johan G wrote in Wed Apr 20, 2016 6:19 am:There is no reason why 3 DoF cannot be represented in 2.5D or even 2D. :P There might be a misunderstanding here. ;)


Of course, at the end of the day everything you see in a screen is 2D, it's just a matter of what projection you use... :P

Regarding the 3D cockpit, I will try to provide some '2D projections' from Orbiter tonight, forget the videos and pictures you find in the net because they're largely outdated, currently it's a quite polished model. Anyway I didn't know you had a hi-poli source model which you're adapting; I assume that either adapting the hi-res model or the Orbiter model will take same amount of effort, and since the route taken was the first, it doesn't make sense to change now. Understood :wink:

Regards!

P.S-> Thank you Thorsten for the key binding instructions! It's not as harder as it seemed, I thought it was hard-coded, now I think even I can do it.

P.S2 -> I just came across this picture; it's in atmospheric flight, so yaw is blocked, but it nicely shows the elements arrangement in PFD AE. I'm trying to find a picture/video of PFD in orbit, but almost everything I found is during landing...

Image

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

Re: Space Shuttle

Postby Thorsten » Wed Apr 20, 2016 7:01 am

Thank you Thorsten for the key binding instructions! It's not as harder as it seemed, I thought it was hard-coded


Hardly anything is hard-coded - there's vast parts of FG which you can customize via xml editing, and all aircraft are 'just' data and scripts from the POV of the application - you never need to compile anything. Even a complex AP for the Shuttle is just a chain of xml tags referencing JSBSim elements.

It's a very neat design: this is really all it takes to create a PID controller:

Code: Select all
      <pid name="systems/rcs/dap-pitch">
         <input>systems/rcs/pitch-rate-error</input>
         <kp> 15.0 </kp>
         <ki> 0.0 </ki>
         <kd> 0.0</kd>
         <clipto>
            <min> -1.0 </min>
                 <max>  1.0 </max>
         </clipto>
         <output>systems/rcs/dap-pitch-cmd-orbit</output>
      </pid>
Thorsten
 
Posts: 11191
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Richard » Wed Apr 20, 2016 1:44 pm

amalahama wrote in Wed Apr 20, 2016 6:27 am:...know you had a hi-poli source model which you're adapting;


Our mesh is this one: http://www.blendswap.com/blends/view/74692 - I can't compare with SSU, but I doubt the SSU one is this detailed. However as Thorsten said we have only currently got the forward panels because the original is very detailed see the pics on Chris Kuhn's Shuttle Cockpit images facebook page

I'm working on getting the overhead panels in, but not sure about the aft section. It's a great mesh but we've been manually reducing the vertex count, which is hard without loosing detail.
Richard
 
Posts: 726
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: Space Shuttle

Postby Thorsten » Wed Apr 20, 2016 3:03 pm

In other matters, I've now started to implement the FAIL ON mode of the RCS jets (an ignited jet refuses to shut down). This gives some meaning to the SPEC 23 thruster management.

What needs to be done is to shut down the faulty jet by cutting the fuel supply (aka de-pressurizing the manifold supplying the jet in question) and then de-select it from the jet table in SPEC 23 to prevent the problem from occurring the next time again.

Currently the RCS control doesn't account specifically for de-selected jets, so the performance of the rate controllers in achieving their targets is deteriorating (just as it is for FAIL OFF jets), but it all works as advertized.

Also, CWS picks and announces both fail on and fail off.
Thorsten
 
Posts: 11191
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Thorsten » Wed Apr 20, 2016 4:48 pm

I'm working on getting the overhead panels in, but not sure about the aft section.


I think we could just put it in 'as is'.

If it's not in the view frustrum, it's not a problem for framerate. You can't opt out of seeing the forward panels when piloting, but you'll usually
not get to see the aft section in any performance-critical context.

If memory consumption is an issue, we can just let the user opt-in via a <select> animation. Same for outside views - we can remove the whole cockpit from the rendering pipeline whenever we're in an outside view so it never affects framerate.

So the need to reduce vertex count is quite a bit lessened for the aft section. It's a bit like all those airliner cabins people are so fond of putting in to have passenger views.
Thorsten
 
Posts: 11191
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