Board index FlightGear Development Spaceflight

Space Shuttle

Discussion about development and usage of spacecraft

Re: Space Shuttle

Postby Thorsten » Thu Jan 11, 2018 6:38 pm

I've just pushed a series of changes which make the orbital DAP pushbuttons recognize whether BFS is on (which removes the ability to select AUTO as compared to the transition DAP) or whether there's an IMU failure/dilemma (which removes all rate holding / inertially stabilizing modes).

I'd appreciate if any of the power users could test various scenarios with BFS engage/disengage if everything works correctly, I've ran some tests, but since there's plenty of different time orderings, I'm a bit concerned I might have overlooked something (like engaging the BFS orbital DAP when you're actually in Aerojet mode is a *very* bad idea...)
Thorsten
 
Posts: 11203
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby amalahama » Fri Jan 12, 2018 11:07 pm

wlbragg wrote in Thu Jan 11, 2018 5:05 pm:
suspect we need a third texture sheet for the job...

Or a professional modeler needs to unwrap the model and completely re-organize the texture files. From my limited knowledge of modeling I think if this had been organized and optimized from the start it may have been enough room. It was too far along at the point I started adding detail and I was too inexperienced in modeling to have attempted to start over, even though that would have been the best time to start over.
Even without an "unwrapping" there is still room for improvement in the base textures, but the current resolution (space) restricts a lot of the potential improvements.
One needs to know that any change or rework requires compliance with the method we use in the creation of light maps, ie: no overlapping objects. Not to mention some changes would require the generation of new light maps. So there is a pain to gain element involved.
I use the "Draw other objects" in the UV editor portion of Blender to make a pseudo UV map. There may be one of these saved and added to the Gimp file as a reference overlay. But it would probably not portray the most current work to the texture sheets.


I'm not an artist but I like photography and I get by with software like photoshop. I found a post in the Orbiter forum where they found the exact font used in the cockpit (actually there are two) and I thought of mayble replacing the labels with vectorial fonts that can be scaled in the future, to improve sharpeness. But I didn't have in mind to improve detail in textures, I don't have the knowledge or skills for do that.

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

Re: Space Shuttle

Postby Richard » Sat Jan 13, 2018 12:18 am

I often find that perfectly rendered fonts on textures somehow lack authenticity that a textures derived from photographs can provide. A skilled artist can sometimes get it right, but often just close. This is only my view, using personal memory of cockpits (that may be flawed). I suspect that a good artist can considerably enhance what we currently use - but at the same time a less skilled artist could make it feel less authentic. It's nice to have readable legends, but sometimes in the real world the legends are damaged and can only be partially read.
Richard
 
Posts: 727
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: Space Shuttle

Postby wlbragg » Sat Jan 13, 2018 4:13 am

I often find that perfectly rendered fonts on textures somehow lack authenticity that a textures derived from photographs can provide.

It was by design that we used the panel legends that are currently implemented in the Shuttle. As Richard probably remembers, the majority of them are pulled from actual photographs of the Shuttle interior. So they are already the actual font being used in the Shuttle Atlantis. There were perspective issues by doing it that way and some that were not available that we pulled from the Shuttle documentation (crew manual).
The fonts used for talkbacks and caution and warnings leave much room for improvement. If I remember correctly some are hand made by me and others may be partial derivatives of photos taken of the interior.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 4989
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: Space Shuttle

Postby Thorsten » Sat Jan 13, 2018 6:33 am

I often find that perfectly rendered fonts on textures somehow lack authenticity that a textures derived from photographs can provide


I think our strategy works rather well for the front panels - less so for the aft panels perhaps where resolution is lower, the extraction angle was often awkward and it's difficult to read some labels without tooltips...
Thorsten
 
Posts: 11203
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby amalahama » Sat Jan 13, 2018 5:32 pm

Richard wrote in Sat Jan 13, 2018 12:18 am:I often find that perfectly rendered fonts on textures somehow lack authenticity that a textures derived from photographs can provide.


The shuttle always had pristine panels, so don't expect too many differences between photo-based and vectorial-based panels if they are done right.

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

Re: Space Shuttle

Postby amalahama » Sat Jan 13, 2018 11:37 pm

I have to admit, I'm a huge fan of the popup CRTs! :D

Image

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

Re: Space Shuttle

Postby amalahama » Sat Jan 20, 2018 10:28 pm

Training my de-orbit and entry habilities, I switched directly from OPS 303 after the deorbit burn to OPS 304, without manually change the attitude for reentry, and I lost totally the control of the shuttle, with catastrophic consecuences. Is this behaviour normal? I tried to revert to 303 to recover control and manually ajust the shuttle, but DAP seemed to be blocked in Aerojet mode and it was impossible to cancel to manually stop the rotation and correct the attitude. Is there a way to do it?

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

Re: Space Shuttle

Postby Thorsten » Sun Jan 21, 2018 6:37 am

Is this behaviour normal?


I don't know - it has to do with the ability of the Aerojet DAP to dampen transients. It has very agressive gains to deal with deviations from zero beta because only just about a degree is tolerable. So if you're 20 degrees off when you engage, it over-corrects.

Since I don't know all the details of the real Aerojet, I don't know ir or how that problem was solved (certainly it had its quirks as well, like the fighting between rudder and elevon trim...).

'The Manual' contains a dire warning underlined in red to not engage Aerojet in the wrong attitude, so there's that...

I tried to revert to 303 to recover control and manually ajust the shuttle, but DAP seemed to be blocked in Aerojet mode and it was impossible to cancel to manually stop the rotation


Ctrl+m I believe would have forced mode-cycling and eventually have reached the Orbital DAP, probably OPS 301 PRO would have re-engaged the transition DAP, OPS 201 PRO would have engaged the orbital DAP (I haven't really tried those in a while, so take with a grain of salt, but I'm fairly sure at least one of these would have done the trick).
Thorsten
 
Posts: 11203
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby amalahama » Sun Jan 21, 2018 6:58 pm

Thorsten wrote in Sun Jan 21, 2018 6:37 am:'The Manual' contains a dire warning underlined in red to not engage Aerojet in the wrong attitude, so there's that...


You're totally right, I realized too late :(

So just to clarify the OPS flow, we execute the deorbit burn in OPS 302, afterwards we change to OPS 303 to stow OMS engines and control TFF. According to Flight Procedures Handbook - Entry, we can execute then an automatic attitude change to the inertial roll,pitch,yaw equivalent 0,40,0 in LVLH at EI-5, I think that is not modeled in FG shuttle yet

The transition to MM 303 initiates stowing of the OMS engines (unless the gimbal has
previously been selected OFF). The deorbit target data on the DEORB MNVR display in MM
301 and MM 302 blank. The crew then verifies the uplinked values of roll, pitch, and yaw that
are displayed under BURN DATA. These are the inertial values equivalent to a 0° roll, 40°
pitch, 0° yaw LVLH MM 304 attitude at EI - 5
. These attitude angles can be changed directly
by the crew through the keyboard but are supplied by uplink or the DEL PAD. (...)

With good inertial roll, pitch, and yaw values, the crew obtains error needles and an inertial
attitude on the DEORB MNVR COAST display that is equivalent to a 0°, 40°, 0° (R, P, Y) LVLH
attitude in MM 304 at EI - 5. The crew has the capability of an automatic or manual maneuver
to this attitude.

The INRTL ADI attitude is shown in the DEL PAD for maneuvering to the EI - 5 attitude and
shows values that are the equivalent of a pitch-up of approximately 135° from a nominal twoengine
deorbit burn attitude.
If the crew wishes to verify that the vehicle is approaching the EI - 5 attitude, they may consult
the table provided in the Entry Checklist that shows the time to EI in minutes versus the desired
LVLH pitch in degrees.
For a severe underburn, the inertial values that appear in the BURN ATT fields in MM 303 will
be incorrect and the attitude must be adjusted by flying to the LVLH pitch versus time to EI
shown in the table. Any pre-bank required by the underburn is achieved after the transition to
MM 304 but before EI.


******

Another question, after Ku-band antenna stowed and main cargo doors closed, I don't have link with MCC anymore - and I need them to provide Orbiter mass and deorbit solution. How can I keep the link to the ground even without the Ku band antenna running?

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

Re: Space Shuttle

Postby wkitty42 » Sun Jan 21, 2018 11:54 pm

amalahama wrote in Sun Jan 21, 2018 6:58 pm:Another question, after Ku-band antenna stowed and main cargo doors closed, I don't have link with MCC anymore - and I need them to provide Orbiter mass and deorbit solution. How can I keep the link to the ground even without the Ku band antenna running?

i may be wrong about this but isn't there an existing method used before the Ku is deployed? i would think they'd switch back to that... it is just a guess, though...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5767
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Space Shuttle

Postby Thorsten » Mon Jan 22, 2018 6:23 am

The crew then verifies the uplinked values of roll, pitch, and yaw that are displayed under BURN DATA. These are the inertial values equivalent to a 0° roll, 40° pitch, 0° yaw LVLH MM 304 attitude at EI - 5.


It's not implemented to get the inertial values automatically, no (this is moderately complex, because you need a predictive solution where EI-5 will be and use the transformation matrices between inertial and LVLH to get an inertial attitude there) - just maneuvering to an approximate LVLH attitude by hand seems quite doable... :mrgreen:



How can I keep the link to the ground even without the Ku band antenna running?


Use the S-band antenna - if you're not over a ground site, you might need to switch it to TDRS and pre-amplify the signal to compensate for the range, but for 90% of the orbit this will give you a link.
Thorsten
 
Posts: 11203
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby Thorsten » Mon Jan 22, 2018 8:19 am

To be sure the dialogs will be available under all conditions (Qt and nonQt builds) in the future, I have started to move them to pure canvas technology.

That has the advantage that we're now a lot more flexible - we don't need to care for things like widgets and layouts. The first example of this is the new propellant dialog (actually the launch version - it'll look different afterwards and show OMS and RCS propellant instead).

Image
Thorsten
 
Posts: 11203
Joined: Mon Nov 02, 2009 8:33 am

Re: Space Shuttle

Postby wlbragg » Mon Jan 22, 2018 1:38 pm

Nice, plus the added benefit of some more examples for me to look at for some canvas dialogs I want to make for other aircraft.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
Intel i5 3570K AMDRX480
User avatar
wlbragg
 
Posts: 4989
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/AMDRX480

Re: Space Shuttle

Postby Hooray » Mon Jan 22, 2018 8:45 pm

FWIW, If you should end up using pure SVG files, those would also be easy to support via Phi/mongoose without much work.
For that to succeed, it would make sense to extend svg.nas according to my previous comments in the FG1000 discussion.
But apart from that, there's not much missing to pull that off - you'd end up with pure SVG/XML files that would have script sections, which would basically invoke fgcommands to get/set properties.

If in doubt, I'd suggest to discuss this suggestion with James and Torsten, but using this approach is really the only logical way forward to prepare aircraft for the future, without having to focus on any single front-end like PUI, Qt5, Canvas or whatever else people may tinker with.

In particular, this means the following:
  • use native SVG files
  • use fgcommands only
  • register custom Nasal code as fgcommands

That way, any front-end can trigger the events (callbacks) necessary to get/set values as needed.

Note that this advice is not specific to the shuttle - and it is not specific to the Canvas system, it will apply just as well to the Phi/Qt5 or FGQCanvas efforts.
Using SVG/XML is the logical thing to do here, because it can be trivially made to work by all front-ends.

Again, if in doubt, I'd suggest to discuss the details with the people involved in the corresponding efforts.

PS: Such SVG files, if used by fgfs internally (via Canvas/Nasal) would only need to use a wrapper to run the same fgcommands and set/get properties as needed (or simply use the RPC interface implemented by Torsten).
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: 11376
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Spaceflight

Who is online

Users browsing this forum: No registered users and 0 guests