Space Shuttle - Development

[wlbragg]

@eatdirt do you have any thoughts to revisit the nasal SRMS view calculations? I don't like the idea of moving the CCTV mesh calcs over to the nasal calcs when I know that calculation is not accurate or the same as the properties used in the xml's and that the arm center drifts considerably. I understand that to get the appearance of a static cctv screen in that view, that is what would be required at the moment. I didn't fully understand not looked at the code to see what properties or calculations you used. Then again, in order to lock the CCTV mesh in step with the view, it does need to use the view cords in the event you were to artficially cheng the view perspective by the use of middle mouse click or other view controls. Then again I think we can control locking the view to the code and not allow mouse click to circumvent the view.
Your thoughts?

[eatdirt]

Hi Wayne,

@eatdirt do you have any thoughts to revisit the nasal SRMS view calculations?

yes, I am on it! For the time being, I have been reading the code to see which things should be tuned. I have just one question, how do you get the numbers used in rmsArm.xml for the animation? Is this something automatic or you have to manually measure them in blender from the SpaceShuttle model? (I have started to do this for checking, but if something can be done in an automatic way, let me know!)

Then again I think we can control locking the view to the code and not allow mouse click to circumvent the view

This is already the case. The view remains free only when the arm is not powered. As soon as you engage the RMS power switch, the view cannot be moved around and remains fixed along the arm. However, it can be zoomed in and out, as it is the case with the real CCTV on the arm.

Anyway, yes, before you can add the mesh, I should first fix the little mismatches between RMS animation and position/attitude computations. It also implies retuning the coordinates of all payload grapples, so I cannot really rush it!

[wlbragg]

you have to manually measure them in blender

Yes, it probably wouldn't hurt to check thoes positions. I don't know who originated them.

[GinGin]

I pushed some works on TAEM.
Main things are about accurate functions for Energy, Qbar and Altitude reference.

Glideslope deviation logic is now driven by the Altitude Error Function. I found some pretty neat coefficients for either a 20° final glide path (Weight below 220000 lbs) or 18° ( Weight above 220000 lbs) .
I also adjusted the Qbar reference profile to take into account the latest profile flown ( Basically 300 kts in final instead of 275 kts for the first Shuttle era ).


The main visible thing that will be noticeable is the Altitude reference profile.
It is composed of three segments.

A brief example below with the 20° final path targeted.

Above 45 Nm ish from the final interface ( which is at 6 Nm ish from Runway Treshold), we have the Blue linear segment ( Flight path around 6 °)
Then between 45 Nm and 6 Nm we have the Green cubic segment that takes into account the steeper and steeper flight path as we descend through the atmosphere
Finally the small red linear segment once in Final ( 20° or 18 °) that ends at the Outer Glide Slope Aim Point ( 7500 or 6500 feet) before the Runway




Very entertaining dev goal.

[Thorsten]

The new version of the FG Space Shuttle Flight Manual corresponding to the milestone 13 is out - get your updated copy here!

[GinGin]

Champagne bis

[Gomendio]

Hi to all;

I pulled yesterday the latest dev version of the shuttle to see the TAEM rework and now FG 2020.3.6 basically rejects the loading of the Shuttle. Till now everything worked flawlessly.
Is the latest dev now considered stable and not compatible with the 20.3.6 anymore?

The deluxe manual is a tremendous piece of work Thorsten.

[Thorsten]

The last milestone I've tested under 2018.3, I was under the impression GinGin and eatdirt tested under 2020.X LTS, so that is what the milestone 13 should run on.

About the latest development snapshot I don't really know, I've not tested that - GinGin has been doing stuff, that may easily contain something not palatable for every FG version (or even crash everywhere) - we'd need the precise error message to track that further, but we don't do quality monitoring/testing on the devel version.

[eatdirt]

s the latest dev now considered stable and not compatible with the 2020.3.6 anymore?

\

I've tested the before to last commit, it works fine. If you have pulled from the fgspaceshuttle repos, be careful to actually switch to the devel branch, or check out milestone 13. I suspect the default branch after a git clone is "master", which is something halted at milestone 8.

Thanks Thorsten for the manual, I'll print it and report, if any, typos by PM!

Cheers,
Chris.

[Vinny002]

I got the latest version of FG 2020.3.8. So I am running the latest version of the FG space shuttle.

[GinGin]

I was under the impression GinGin and eatdirt tested under 2020.X LTS, so that is what the milestone 13 should run on.

Indeed, I am on the 2020.3.2 stable FG version and it runs ok.

the shuttle to see the TAEM rework

You should just download the Stable Shuttle release through the Launcher to test the changes (Display and logic enhancements are available in the last stable).
The work on the dev branch is about another layer of TAEM realism, but unless you read through the documentations I mentionned in above posts, you would not notice the differences with the stable TAEM for now.

FG 2020.3.6 basically rejects the loading of the Shuttle

Weirg, it should work normally.
@EatDirt: Do you have the 2020.3.6 ?

I got the latest version of FG 2020.3.8. So I am running the latest version of the FG space shuttle.

FG version and Space Shuttle Stable versions are independant.
To have the Shuttle Stable, you just need to download it from the Launcher with any FG version from 2018 to 2020.

[eatdirt]

@EatDirt: Do you have the 2020.3.6 ?

Yes, I've tested 2020.3.6 and I am now running 2020.3.8, it is all good for me (I don't have tested the installation from fgfs --launcher though).

[Gomendio]

I dunno. Kinda weird everything. I pulled all the updates as always, changing to development, and now the FG does not recognise the Shuttle anymore. Anyway thanks for the tips.
I had to install W10 a couple of days ago, mainly because w7 just calling for a decent retire.

Pitty though. The shuttle was flying beautifully and the Earth view was stable at 16K. I was enjoying tremendously the abort scenarios following the recorded NASA training for the STS-135.

Starting all over again.

Thanks anyway.

[Thorsten]

and now the FG does not recognise the Shuttle anymore.

Update from where? Via launcher? From out SourceForge devel repo?

What does 'does not recognize' mean? Does it exit when you try to start? If so, with what error message? Or does it never appear in the launcher? We have no idea how we could possibly help you without such more detailed info.

[GinGin]

I pushed a commit about the initial throttle down/up at Qbar max.

I changed the boundaries . They are based now on True Airspeed like the real I-loaded parameters.
I have also included a two stage bucket option ( Nominal throttle --> First throttle down --> Second throttle down --> Throttle up). It was the case on a few flights. That will be a good basis also for an adaptative guidance thing with some SRB lower or higher than nominal thrust.

The few lines that changed in the mission files.

*throttle-down-velocity-1: First stage bucket throttle down Vtrue
*throttle-down-velocity-2: Second stage bucket throttle down Vtrue
*throttle-up-velocity: Throttle up Vtrue
*throttle-down-1-to-percent type: Thrust setting for first throttle down ( if a one stage bucket is desired, we need to put the nominal thrust value instead of a lower value)
*throttle-down-2-to-percent type: Thrust setting for second throttle down ( or first throttle down for a one stage bucket)

Code: Select all

<throttle-down-velocity-1 type="double">650</throttle-down-velocity-1>
 <throttle-down-velocity-2 type="double">792</throttle-down-velocity-2>
 <throttle-up-velocity type="double">1304</throttle-up-velocity>
 <throttle-nominal-percent type="double">104.5</throttle-nominal-percent>
 <throttle-down-1-to-percent type="double">89.0</throttle-down-1-to-percent>
 <throttle-down-2-to-percent type="double">72.0</throttle-down-2-to-percent>


I presetted the standard one stage bucket values for all mission files except for Hst.xml where the Qbar is the highest.




For a two stage, that gives the following example: