SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[Urwumpe]

I have it set to maximum and there's nothing about the ET.

So its something less trivial. :facepalm:

 

[DaveS]

This is the last in orbiter.log:

000000.000: Module SSU_Tank.dll .......... [Build 160830, API 160828]

 

[GLS]

Hmm... strange. DirectX9 client, right? Did you increase the debugging level of the clients already?

MOGE mostly (faster loading), but I think I got this CTD once in D3D9.

---------- Post added at 09:07 PM ---------- Previous post was at 09:04 PM ----------

So its something less trivial. :facepalm:

It took more than a week just to track down the line where it goes BUM...

 

[DaveS]

MOGE mostly (faster loading), but I think I got this CTD once in D3D9.

---------- Post added at 09:07 PM ---------- Previous post was at 09:04 PM ----------



It took more than a week just to track down the line where it goes BUM...

I'm getting a consistent CTD with the LWT in the SLC-6 Launch test scenario. This is with D3D9Client RC1.

 

[GLS]

I'm getting a consistent CTD with the LWT in the SLC-6 Launch test scenario. This is with D3D9Client RC1.

One run with MOGE and another with D3D9 RC1 and no CTD.
But I did find an issue with the shadows in D3D9...

 

[DaveS]

One run with MOGE and another with D3D9 RC1 and no CTD.
But I did find an issue with the shadows in D3D9...

Just another issue caused by the new terrain implementation. SLC-6 currently uses it's own dedicated mesh for the terrain, so it needs to go.

 

[GLS]

CTD with the new D3D9 R1, same function (different line as this scenario uses the LWT), so no news...

 

[DaveS]

Is there any way to track what's happening inside that function? Or do we need to ask jarmonik to implement this for D3D9Client?

 

[GLS]

Is there any way to track what's happening inside that function? Or do we need to ask jarmonik to implement this for D3D9Client?

Only the people with that function's code can tell what happens in there (I don't know where it is implemented).

 

[DaveS]

GLS: Could you please try the new meshes I have checked in? They have cured the CTDs on my end, but seeing as these are random on your end I need your checks as well.

 

[GLS]

GLS: Could you please try the new meshes I have checked in? They have cured the CTDs on my end, but seeing as these are random on your end I need your checks as well.

I'll look at that in the morning.

---------- Post added at 09:19 AM ---------- Previous post was at 01:58 AM ----------

No CTDs so far, but the wierd shadow reported earlier is still there.

 

[amalahama]

Hi!
Yesterday I tried with a complete re-entry using EDW Entry scenario, Orbiter 2016 R4 and Nightly OrbiterBeta SSU compiled with VS2010, and the Shuttle followed a strange behaviour.

I left the autopilot to control the shuttle. She didn't do S-turns, instead she leaned to one side and stay there for almost all the entry, I guess because orbit projection didn't pass over EDW and she was forced to maneouver hard in the high atmosphere. Approaching the HAC the Shuttle was a bit out of X-TRK and had to compensate; also she arrived too fast (M2.0) to the HAC. I think the scenario itself would require a review. But that is not the bug.

When she entered the HAC, at some point the HAC circle in SPEC 50 switched to a smaller circle, and then the autopilot got crazy. It tried to pull more and more until the shuttle predictors rolled on themselves and then the shuttle fall into something similar to a flat spin. And I said 'similar' because in reality, the physical engine got broken and the Shuttle moved erratically without falling down to the ground :WTF:

That happened me several times, always when shuttle is flying automatically an HAC and SPEC 50 predictors rolls on themselves. There are definitively some limits in the control actuators that are overriden when flying with AUTO on, it seems.

Also, reentry glow mesh is broken in Orbiter 2016. I was using the standard visual engine, not D3D9.

Regards!

 

[GLS]

Hi!
Yesterday I tried with a complete re-entry using EDW Entry scenario, Orbiter 2016 R4 and Nightly OrbiterBeta SSU compiled with VS2010, and the Shuttle followed a strange behaviour.

I left the autopilot to control the shuttle. She didn't do S-turns, instead she leaned to one side and stay there for almost all the entry, I guess because orbit projection didn't pass over EDW and she was forced to maneouver hard in the high atmosphere. Approaching the HAC the Shuttle was a bit out of X-TRK and had to compensate; also she arrived too fast (M2.0) to the HAC. I think the scenario itself would require a review. But that is not the bug.

I just ran that scenario and it all works as it did before... except the final approach because the runway is at about 2000ft ASL and the AeroJetDAP thinks it is at sea level...
It did spend most of the reentry in a left bank, but in the latter parts in also banked right. If the crossrange is big, it can easily do the full reentry banked to one side alone, nothing to worry about.

Didn't have any overspeed approaching the HAC, but that can happen as the S-turn mode isn't implemented in TAEM, but usually the current logic manages to bleed the excess speed.

When she entered the HAC, at some point the HAC circle in SPEC 50 switched to a smaller circle, and then the autopilot got crazy. It tried to pull more and more until the shuttle predictors rolled on themselves and then the shuttle fall into something similar to a flat spin. And I said 'similar' because in reality, the physical engine got broken and the Shuttle moved erratically without falling down to the ground :WTF:

That happened me several times, always when shuttle is flying automatically an HAC and SPEC 50 predictors rolls on themselves. There are definitively some limits in the control actuators that are overriden when flying with AUTO on, it seems.

The HAC shrinking by itself probably has to do with you trying to fly a "large angle" HAC (maybe > 300º). The logic gets lost and thinks the vehicle is closer to the runway so it decreases the radius. If you a runway end and a side so that the corresponding HAC isn't above, let's say 270º, you shouldn't have this problem.

Yeah, AUTO (and MAN) currently have no limits and can easily fly the vehicle into a stall. Another yeah, when it stalls the aero gets messed up somehow and it might gain speed flying up :facepalm:. AUTO will raise the nose to make up range if it is short. If alpha goes goes to about 18-20º, when you are already subsonic, go MAN and nose down or you're going to have a bad day.

Also, reentry glow mesh is broken in Orbiter 2016. I was using the standard visual engine, not D3D9.

Regards!

The reentry mesh works fine here (except for the mismatch in size/shape when compared with the orbiter). Orbiter 2016 has a reentry particle stream showing now... I haven't looked to see if it is controllable, but I'd say it starts about the right time, but ends a bit too late, other than that no problems here.

 

[DaveS]

The reentry mesh works fine here (except for the mismatch in size/shape when compared with the orbiter). Orbiter 2016 has a reentry particle stream showing now... I haven't looked to see if it is controllable, but I'd say it starts about the right time, but ends a bit too late, other than that no problems here.

If not, make a post in this issue: http://www.orbiter-forum.com/project.php?issueid=601

---------- Post added at 05:08 PM ---------- Previous post was at 05:05 PM ----------

I'll look at that in the morning.

---------- Post added at 09:19 AM ---------- Previous post was at 01:58 AM ----------

No CTDs so far, but the wierd shadow reported earlier is still there.

Great news then! I have taken a closer look at this and it appears that the shadow model that both the inline and D3D9Client uses doesn't take in the account of the terrain. It's still assuming a perfectly flat surface. All the base issues will have to wait until a better terrain editor is available.

 

[GLS]

If not, make a post in this issue: http://www.orbiter-forum.com/project.php?issueid=601

Well, it's not perfect, and IMO it never will be unless we all own supercomputers to do the CFD calculations and somebody works the math for it all. :shrug:

In other news, I'm slowly making progress in the SSUWorkbench. I got the numbers corrected and added the option to control MECO altitude, but the math to calculate the OMS-1 numbers is assuming things that aren't true, i.e. the OMS-1 burn is at the apogee of the MECO orbit and is a fully prograde burn. I'd like to correct that by locking the OMS-1 TIG at MECO+120s and then burning right along the velocity vector (so it will also have a vertical component in addition to the horizontal one) until the apogee is at the target orbit.
Now, the problem is the formulas... any orbital mechanics wizard out there who wants to help?

(I knew I should have taken that orbital mechanics class :facepalm

 

[Urwumpe]

Which formula do you need? Also, are you sure, OMS-1 is not at apogee?

 

[GLS]

Which formula do you need? Also, are you sure, OMS-1 is not at apogee?

Well, I have the standard MECO targets for a 28.5º orbit as 85NM by 3NM, with MECO at 57NM. The OMS-1 appears to be fixed at MECO+120s so it happens together with the MPS Dump, so I don't think we can go from 57NM to 85NM in 120 seconds.

I think that we need to calculate the altitude and FPA at MECO+120s (in the MECO orbit). Then, keeping those 2 parameters and setting an apogee at the target altitude, we need to calculate the velocity at that point, so we can then get the difference to the MECO+120s point velocity in the MECO orbit -> total OMS-1 dV. The vertical and horizontal components would be extracted using the FPA.
For the OMS-2 calculations we would then need the post-OMS-1 perigee, to use in the current vis-viva function to get the OMS-2 dV. For the OMS-2 TIG we need to get the time it takes from the OMS-1 burn "point" to the apogee fo the post-OMS-1 orbit.

 

[Urwumpe]

Not sure if 85 NM is really correct for initial Apogee. For STS-1 the OMS-1 must have been close to or at apogee - the perigee after OMS-1 is practically MECO altitude.

I have the following quote for STS-1 MECO targeting:

Closed-loop steering, using the powered explicit guidance (PEG) simulation, is initiated after SRB staging and is targeted to an inclination of 40.3°, a radius of 21 290 308 feet (60 n. mi. above a spherical Earth with a radius of 3443.9336 n. mi.), a velocity of 25 668 fps, a flightpath angle of 0.5°, and a descending node of 142.0°.

https://ia800308.us.archive.org/27/items/nasa_techdoc_19800022939/19800022939.pdf

FPA of 0.5° leaves only little altitude left to be gained... but I would now need to consult the books for the formula to get the missing numbers.

Later missions seem to have optimized for 57 NM and 0.65° FPA

---------- Post added at 10:16 PM ---------- Previous post was at 09:46 PM ----------

Here is the data for the STS-1 mission, it had a lot more constraints than later flights though:

STS-1 operational flight profile. Volume 3: Ascent, cycle 3

 

[GLS]

Not sure if 85 NM is really correct for initial Apogee. For STS-1 the OMS-1 must have been close to or at apogee - the perigee after OMS-1 is practically MECO altitude.

I have the following quote for STS-1 MECO targeting:



https://ia800308.us.archive.org/27/items/nasa_techdoc_19800022939/19800022939.pdf

FPA of 0.5° leaves only little altitude left to be gained... but I would now need to consult the books for the formula to get the missing numbers.

Later missions seem to have optimized for 57 NM and 0.65° FPA

Yeah, a FPA of 0.65º is what I have as well. For the velocity I have 25670fps, which is just 2fps more that those STS-1 targets. Even with the different MECO altitude, I don't think the OMS-1 TIG in STS-1 was (very) near the apogee.

 

[Urwumpe]

Does not look so Ap was 80 NM then according to the cycle 3 document. But OMS-1 targeting is much easier than expected... look at the loaded target data.