Space Shuttle - Development

[GinGin]

Next week I think.
Just ironing out.

I still observe sometimes something weird with RTLS I never had before ( I am testing it with engine failure just after lift off and at 4 mn)
After PPD , Shuttle does not stabilize at -2°, just pass through AOA -2° and MECO occurs ( Though the rest of RTLS is unchanged and transtion, Nz, alpha phase work, so no game breaker)

Pretty sure I observed that just with the shuttle.xml with two tank defined for ET.
Need to dig a bit.
And to find a good conditionnal for use of hdot target before mach 23 and gamma target after ( or just like you said to go with hdot only and conversion of gamma into hdot for MECO with ( Tan(gamma) * Vi MECO))

[GinGin]

I fixed the thing with RTLS, I messed up with throttle settings at MECO.
Finished to retest RTLS, from failure at 1 second to failure at 4 mn, and from mini to maxi payload.

It worked as nicely if not better than before.

I will reshape a bit the drawing.
Here, Early engine failure at max payload, fly back altitude around 320 kfeet ( vs almost 360/370 for a flyback with late failure and empty weight)
That matches quite well the official datas I found on the subject.

And at the end, all the abort and guidance always converge towards the same MECO target, on the line / on speed. Really good AP

[amalahama]

Wow Gingin, I'm impressed, you dare to put your hands into the very much core of FGSpaceShuttle! Bravo!
Maybe if you feel like so in the future, it would be nice to have all the normal trajectory guidelines and constant drag lines in Entry Traj 1,2,3... I think it was discussed before and you had run some tests to get the drag values in game.

[GinGin]

Well, so far I am just adjusting what has already be done, so it is more retro engineering, but I am slowly learning
Eventually for the Entry.

I found some really nice books ( STS 1 Operational Flight Profile, from Ascent to Entry).
They were used to prepare STS 1 flight, with a lof of details about trajectory, parameters etc.
Quite old and trajectory differed in latest STS flight, but Is very nice for a general Idea of Trajectory guidelines.
Also, it is a nice base for a STS 1 revival , with First iteration SRB ( 10 % less thrust until STS 8 and high perfo SRB, etc)

So yes for the entry, It shouldnt be too hard to add normal lines ( from hard boundaries to zero bank equilibrium) once I will have done more serious tests to take drag vs altitude etc with a standard entry profile.

The core FDM is really strong and versatile, so we can easily adjust around the displays or whatever we want.
Just need some time and In game and official datas, and make a mix of both

[GinGin]

Almost finish.
Some more datas for RTLS final display shaping and good to push
I also touched a bit to TAL to make MECO around 360 k with a shallow flight path angle
Thats still work really nicely with guidance.

A question about mission.xml property.
I created a property in shuttlecommon.xml

Code: Select all

<gamma-meco type="double">0.5</gamma-meco>

I would like to make it customisable from mission.xml
I added the line, but I think I need to do something else as it does not change the property ?

</aunch>
.
.
.
.
<oms-assist-duration-s type="double">120.0</oms-assist-duration-s>
<srb-climbout-ang-bias-deg type="double">0.0</srb-climbout-ang-bias-deg>
<ballistic-climb-ang-bias-deg type="double">0.0</ballistic-climb-ang-bias-deg>
<trajectory-loft-ft type="double">0.0</trajectory-loft-ft>
<gamma-meco type="double">0.3</gamma-meco>
<inclination-targeting type="int">1</inclination-targeting>
</launch>

[wlbragg]

I'm not sure you want the property in shuttlecommon.xml

How and where is it used?

On second thought you probably need a different property in shuttle-missions.xml that changes gamma-meco if you load the mission profile?
Look for how the other properties in shuttle-mission.xml are used to affect the profile. I did a real brief search on a couple props in shuttle-missions.xml and they weren't in the shuttlecommon.xml file. That is my clue that the properties in shuttle-missions.xml are used to change properties elsewhere. If you added gamma-meco to shuttlecommon.xml and use its value in the fdm launch profile then yes it needs to be changed but I am not privy to when shuttle.missions.xml is loaded and if it takes presidents over the defaults in "common" or if they are used to change the defaults in common.

[GinGin]

I'm not sure you want the property in shuttlecommon.xml

How and where is it used?

To be set as a property for MECO target.
And adjustable via mission file, datas are available in SCOM.

Code: Select all

var gamma = getprop("/fdm/jsbsim/systems/ap/launch/gamma-meco") * 0.0174;
   var hdotmeco = math.tan(gamma) * 25800;
   setprop("/fdm/jsbsim/systems/ap/launch/hdot-target", -hdotmeco);

I will have a look to where you pointed, thanks

[wlbragg]

My guess is not to use it in common but only in missions. But you have to make sure the default is set somewhere if used every scenario or not if only in the mission.

look how most props in mission are used

Code: Select all

/mnt/IDrive/FG/Aircraft/Development Aircraft/SpaceShuttle/Mission/columbia.xml:
   14  <launch>
   15    <section-defined type="bool">true</section-defined>
   16:   <target-inclination type="double">46.5</target-inclination>
   17    <target-apoapsis-miles type="double">90.0</target-apoapsis-miles>
   18    <select-north type="bool">true</select-north>

/mnt/IDrive/FG/Aircraft/Development Aircraft/SpaceShuttle/Mission/hst.xml:
   17  <launch>
   18    <section-defined type="bool">true</section-defined>
   19:   <target-inclination type="double">28.47</target-inclination>
   20    <target-apoapsis-miles type="double">288.0</target-apoapsis-miles>
   21    <select-north type="bool">true</select-north>

/mnt/IDrive/FG/Aircraft/Development Aircraft/SpaceShuttle/Mission/mission.xml:
   14  <launch>
   15    <section-defined type="bool">true</section-defined>
   16:   <target-inclination type="double">32.5</target-inclination>
   17    <target-apoapsis-miles type="double">170.0</target-apoapsis-miles>
   18    <select-north type="bool">true</select-north>

Then in mission.nas

Code: Select all

/mnt/IDrive/FG/Aircraft/Development Aircraft/SpaceShuttle/Nasal/mission.nas:
  129  if (getprop("/mission/launch/section-defined") and (stage == 0))
  130     {
  131:    var tgt_inclination = getprop("/mission/launch/target-inclination");
  132     var tgt_apoapsis = getprop("/mission/launch/target-apoapsis-miles");
  133     var lat = getprop("/position/latitude-deg");

These props are introduced with the mission and not in "common". My guess is that "common" defined properties load last and would overwrite mission introduced entities.

So my question "where and how" pertains to

Code: Select all

var gamma = getprop("/fdm/jsbsim/systems/ap/launch/gamma-meco") * 0.0174;
   var hdotmeco = math.tan(gamma) * 25800;
   setprop("/fdm/jsbsim/systems/ap/launch/hdot-target", -hdotmeco);

What file is this happening in? You introduced this? Is it needed "always" as in all launches?
I'm sure Thorsten can answer this as soon as he sees it, I don't know the details of how the mission files are structured and tie to the rest of the code. But guessing with the general knowledge I have on how these things generally work, initializing the property in both files will not work.
If the property is used only when using a "mission" then for sure it should only be included in missions.xml.

[GinGin]

My guess is not to use it in common but only in missions. But you have to make sure the default is set somewhere if used every scenario or not if only in the mission.


What file is this happening in? You introduced this? Is it needed "always" as in all launches?
I'm sure Thorsten can answer this as soon as he sees it, I don't know the details of how the mission files are structured and tie to the rest of the code. But guessing with the general knowledge I have on how these things generally work, initializing the property in both files will not work.
If the property is used only when using a "mission" then for sure it should only be included in missions.xml.

In autolaunch.nas, needed for every launches.
But thanks for pointing the mission.nas.
I overlooked it and that the one I needed.
I will configure it like the " Mps bias angle"

[eatdirt]

Hi there,
with 2020.*, we don't have any external views that do not incessantly roll or yaw around the Shuttle, even the Chase View without roll is not longer quiet w.r.t Earth. May be it is a FG-side fix that has been done on the views, but I finding this annoying for the Shuttle. I've added a view to Shuttle-common, I can do a merge request if others are interested:

Code: Select all

<view n="105">
    <name>Outside</name>
    <type>lookat</type>
    <internal archive="y">false</internal>
    <config>
      <from-model type="bool">false</from-model>
      <from-model-idx type="int">0</from-model-idx>
      <eye-lat-deg-path>/position/latitude-deg</eye-lat-deg-path>
      <eye-lon-deg-path>/position/longitude-deg</eye-lon-deg-path>
      <eye-alt-ft-path>/position/altitude-ft</eye-alt-ft-path>
      <at-model type="bool">true</at-model>
      <at-model-idx type="int">0</at-model-idx>
      <x-offset-m type="double">0.0</x-offset-m>
      <y-offset-m type="double">10.0</y-offset-m>
      <z-offset-m type="double">-100.0</z-offset-m>
     <default-field-of-view-deg>90</default-field-of-view-deg>
    </config>
   </view>


Cheers,
Chris.

[Thorsten]

with 2020.*, we don't have any external views that do not incessantly roll or yaw around the Shuttle, even the Chase View without roll is not longer quiet. May be it is a FG-side fix that has been done on the views,

If views do not work properly with a new FG version, you should report this to the mailing list for fixing. We should not hack around regressions Shuttle-side if it can be avoided.

[wlbragg]

@eatdirt when did you pull and build this version that has the problem? I'd like to verify this and then, yes, my first thoughts were that we need to report this.

[GinGin]

Some insights and results of what I was playing with.
Ready to push tomorrow or monday, really want to finish RTLS line to follow for early engine failure first.

One standard insertion at 85 Nm, with an OMS 1 to follow.
Early STS style, lofted trajectory and MECO at 400000 feet, with almost no payload.
A nice margin of propellant remaining.







And a more common one, Direct Insertion, Full Load for ISS.
Apogee at 120 Nm.
6000 pounds of prop remaining, just the Final Performance Reserve .




The flight path target through Hdot at MECO allows close to real orbit shaping
Apogee 30 mn after MECO for OMS2
That is quite useful to use real PEG 4 datas for OMS2 or AOA abort






Sum up in graphics

Ascent altitude vs time



To be compared ( for the red line) to SCOM datas for 51.6 ° of inc ( between solid and dashed line)







Ascent velocity vs time





Again , to be compared for the red line to SCOM datas for 51.6° inc




So we are now even more accurate.


I retested all the aborts, tunned hdot PID depending on engines remaining and speed, etc
Results are really satisfying.
AP will fly you safe most of the time.

Last one I tested, double engine failure past 17 kfeet ( single engine press to MECO boundary)
And we made it to MECO with one engine, less than a percent of fuel remaining.
Remarkably close to the SCOM




Also, I adjusted a bit ADI colors for sky ( whiter) and Lines ( grey to be visible both on White and Dark ADI part)
I think I will try to split the lines in two later ( upper/lower sphere) to have more contrast like in real ( black on white and vice versa)
So far , I got that :

What do you think ?





@Thorsten : One thing I didn't find, I wanted to put the hud off with launch scenario initialisation, is it possible ?


@WlBragg: Wayne, I was wondering if you could make some small cockpit adjustements when you will have time

The yellow thing for MPS electrical switches




And the letters within the RCS activity lights ( L R U and D)

[eatdirt]

@Wayne and Thorsten, it was a while ago, I think the change of behaviour in the chase view without roll started with 2019.* My current version is 2020.2.0.

I am not sure this is a bug, or rather a feature, but yes, that would be nice if someone can check that too.

The point is that the chase view without roll, now, really looks like what a "chase view" should be. It is behind the Shuttle, so you start underground, and some limits prevent you to move more than 90 degrees forward, so you cannot have a side view. There is also no roll when you follow the Shuttle, w.r.t. the Shuttle frame. But because the Shuttle is rolling, yawing and pitching in all possible directions, you cannot have a stable view of Earth with the chase view without roll.

Now the helicopter view seems to work fine also, the thing is just that at launch, the Shuttle is vertical and triggers a sort of Euler singularity in the heli view. So as soon it pitches a bit up or down w.r.t. the vertical position the heli view starts rolling by 180 degrees on the left or on the right.

I am happy to report on the mailing list, but we should check if this is really a bug, I would say no?

[Thorsten]

I am not sure this is a bug, or rather a feature, but yes, that would be nice if someone can check that too.

Well, it was not intended Shuttle side, you find it annoying, it appears to be driven FG-side, so I guess that warrants clarification on the mailing list.

I think I will try to split the lines in two later ( upper/lower sphere) to have more contrast like in real ( black on white and vice versa)

Good luck ( (The problem of rendering a 3d instrument on a 2d screen is far from trivial...)

One thing I didn't find, I wanted to put the hud off with launch scenario initialisation, is it possible ?

Sure - find what property the on-off buttons have from the cockpit xml, introduce a parameter into the mission file, use mission.nas to flick both HUDs to the specified state.

Or, if you want it blanket, set the desired values in the SpaceShuttle-launch.xml properties.