Space Shuttle Ultra 1.25 Revision B development

[DaveS]

Here's two documents that should prove useful. They're very graphics heavy so they're big downloads! Part 1 has some Cp graphs during entry I believe, in the HYPERSONIC LONGITUDINAL STABILITY PROBLEM section of Entry aerodynamics part.

Shuttle Performance: Lessons Learned, part 1(483 MB)

Shuttle Performance: Lessons Learned, part 2(260 MB)

 

[SiameseCat]

The moment values I'm using seem to be for a CoP of X=1076.7, Y=0.0, Z=375.0 (in the shuttle coordinate system). Does anyone know what this is in Orbiter?

 

[DaveS]

The moment values I'm using seem to be for a CoP of X=1076.7, Y=0.0, Z=375.0 (in the shuttle coordinate system). Does anyone know what this is in Orbiter?

For Orbiter this should be correct: X=0.0, Y=9.375, Z=21.0175

 

[SiameseCat]

The Z value there seems way too large (it puts the CoP in front of the nosecap) The original values are in the frame defined here: http://science.ksc.nasa.gov/shuttle/technology/sts-newsref/sts_coord.html#sts_coord.

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

Subtracting the value from the nosecap position in Orbiter seems to fix the Z-coordinate. The Y-value also seems off, though; I'd have expected something close to -2.8, which is the position of the bottom of the orbiter.

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

The problem seems to be with the elevons. In theory, they should be capable of handling the pitch moment produced by the wings, but they can't. I'm planning to replace Orbiter's aerosurfaces with lookup tables. The Orbiter aerosurfaces will act as dummies, like we do for the RCS.

 

[DaveS]

Subtracting the value from the nosecap position in Orbiter seems to fix the Z-coordinate. The Y-value also seems off, though; I'd have expected something close to -2.8, which is the position of the bottom of the orbiter.

I have attached a good clear graphic to this post showing the shuttle coordinate system.

It seems like Zo=400 is located well above the orbiter bottom, just about below FRCS jets F1U, F2U and F3U. In the second attached drawing, Zo=400 is highlighted by the red horizontal line.

 

[DaveS]

Just checking here: Is the SECTION_COUNT parameter for the SRBs operational? If yes, then I think we have a bug, namely that it doesn't load the segmented meshes. It is loading the complete meshes instead.

---------- Post added at 01:36 PM ---------- Previous post was at 10:24 AM ----------

Can we implement sounds of the SRBs/ET being separated from the orbiter? Feels a bit weired not hearing the SRBs being separated as the BSMs can be heard in the CM when they fire.

 

[Poscik]

Guys, always when I reinstall whole system, compiler can't find afxres.h when compiling SSU. I have latest SDK and all needed stuff, but afxres.h came with none of them. I don't have any idea how to deal with this.

 

[orb]

Guys, always when I reinstall whole system, compiler can't find afxres.h when compiling SSU. I have latest SDK and all needed stuff, but afxres.h came with none of them. I don't have any idea how to deal with this.

I guess it's only needed for compiling resource files. Either try replacing afxres.h with winres.h in the include directive inside of .rc file, or copy winres.h file to afxres.h fle in the Platform SDK directory.

 

[Poscik]

I also don't have such thing like winres.h

 

[orb]

In this case windows.h should be good too, but it doesn't define IDC_STATIC (which should be defined as -1).

 

[SiameseCat]

Guys, always when I reinstall whole system, compiler can't find afxres.h when compiling SSU. I have latest SDK and all needed stuff, but afxres.h came with none of them. I don't have any idea how to deal with this.

On my computer, it's in Visual Studio 9.0/VC/atlmfc/include. I think it's just part of Visual Studio.

 

[Poscik]

Maybe because you have Professional version of VS2008. Anyway, I finally got it working. I had to download Platform SDK for Windows Server 2003 SP1. And there was afxres.h and other mfc stuff. First I downloaded newest SDK, for Windows 7, but now I know what is exactly needed.

 

[SiameseCat]

The Z value there seems way too large (it puts the CoP in front of the nosecap) The original values are in the frame defined here: http://science.ksc.nasa.gov/shuttle/technology/sts-newsref/sts_coord.html#sts_coord.

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

Subtracting the value from the nosecap position in Orbiter seems to fix the Z-coordinate. The Y-value also seems off, though; I'd have expected something close to -2.8, which is the position of the bottom of the orbiter.

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

The problem seems to be with the elevons. In theory, they should be capable of handling the pitch moment produced by the wings, but they can't. I'm planning to replace Orbiter's aerosurfaces with lookup tables. The Orbiter aerosurfaces will act as dummies, like we do for the RCS.

The new elevon code seems to work. I haven't implemented it for low speeds, though. I suspect we'll need a pitch DAP to use the new elevon model; otherwise, the shuttle will be uncontrollable during TAEM and final approach.

 

[DaveS]

The new elevon code seems to work. I haven't implemented it for low speeds, though. I suspect we'll need a pitch DAP to use the new elevon model; otherwise, the shuttle will be uncontrollable during TAEM and final approach.

How is this coming along? BTW, the SPI display, could need a bit of touching up to look like the real one.

 

[Poscik]

Heads Up Roll doesn't work for me. HEADS_UP is in scenario file, not in mission file. Also, countdown timer stops ot T-31, but launch occurs.

 

[SiameseCat]

How is this coming along? BTW, the SPI display, could need a bit of touching up to look like the real one.

I'm still working on it. I have to type a lot of lookup tables, and that's taking a while.

---------- Post added 10-16-10 at 01:03 PM ---------- Previous post was 10-15-10 at 06:27 PM ----------

Does anyone know what the actual dynamic pressure during final approach should be? There seems to be too much drag during final approach.

---------- Post added at 01:23 PM ---------- Previous post was at 01:03 PM ----------

OK, dynamic pressure doesn't seem to be a problem.

 

[SiameseCat]

Everything is (mostly) working now. I'll try to check in a test version in a few days to see what people feel about the autopilot.

 

[DaveS]

Everything is (mostly) working now. I'll try to check in a test version in a few days to see what people feel about the autopilot.

I'm looking forward to testing it! Does the AoA AP now maintain a stable attitude from EI-5(OPS304 transition)?

 

[SiameseCat]

I've been focusing more on control during TAEM and final approach, so I haven't updated the AOA autopilot. The elevons definitely have enough control authority with the new code.

 

[DaveS]

I've been focusing more on control during TAEM and final approach, so I haven't updated the AOA autopilot. The elevons definitely have enough control authority with the new code.

OK. Does the orbiter now handle like how it is shown on the PPOV landing videos?