Space Shuttle Ultra 1.25 Revision B development

[SiameseCat]

The HUD's mostly complete. The earlier problem (the digits didn't tilt when the shuttle banked) has been fixed, although the positioning still doesn't quite work.

 

[DaveS]

The HUD's mostly complete. The earlier problem (the digits didn't tilt when the shuttle banked) has been fixed, although the positioning still doesn't quite work.

Any screenshots? To compare with the real one?

 

[SiameseCat]

The HUD code has been checked in, so you should be able to see it in the final approach scenarios.

 

[DaveS]

The HUD code has been checked in, so you should be able to see it in the final approach scenarios.

Are you sure you checked it in? It's been 10 minutes and it hasn't shown up on Sourceforge yet. Still on rev. 906.

 

[SiameseCat]

Make sure you're in MM 304 or 305. I wrote the code and checked it in a couple of weeks ago.

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

Also, the new HUD only shows up in the VC view.

 

[DaveS]

Make sure you're in MM 304 or 305. I wrote the code and checked it in a couple of weeks ago.

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

Also, the new HUD only shows up in the VC view.

Now I can see it. Hmm, I think our orbiter reacts a bit too well. We also need bodyflap modulation as opening the speedbrake causes a violent pitch up moment. Or will this be a part of the AoA AP?

 

[SiameseCat]

The AOA AP will just follow a target AOA profile down the M2.5. After that it disengages and the shuttle has to be flown manually.

Bodyflap (or elevon) modulation can probably be done, but then we need to figure out how to let the user control the shuttle. There's no easy way to tell if a pitch rate is intentional or not. The biggest problem is how to handle keyboard control; joystick input can be converted to a pitch rate easily, but keyboard input can't.

 

[DaveS]

The AOA AP will just follow a target AOA profile down the M2.5. After that it disengages and the shuttle has to be flown manually.

Bodyflap (or elevon) modulation can probably be done, but then we need to figure out how to let the user control the shuttle. There's no easy way to tell if a pitch rate is intentional or not. The biggest problem is how to handle keyboard control; joystick input can be converted to a pitch rate easily, but keyboard input can't.

Well, the best way from my POV to handle the keyboard would be to digitize the inputs. Not just hard 0 and 1, but allow the control system to treat the keyboard inputs as if they were a from a joystick. IE add a bit of delay to reaching maximum deflection.

So that releasing the key will correspond to getting the joystick back to neutral. It will entail quite a bit of tweaking to get the feeling just right.

The shuttle is after all a completely digital vehicle, control is FBW. The GPCs is what moves the control surfaces, so this would just be another step in the right direction. Right now, all the control surface commands goes directly from input to action, nothing in between.

If you don't already have it, here's the FCS/Effectors Workbook: http://www.nasa.gov/centers/johnson/pdf/383446main_fcs_effectors_workbook_21002.pdf

 

[SiameseCat]

That's what I was thinking as well, but it's probably a lot of work to get it to feel correct. The flare in particular will be difficult. I'll work on this at some point, although there are some other things I want to work on first.

 

[DaveS]

That's what I was thinking as well, but it's probably a lot of work to get it to feel correct. The flare in particular will be difficult. I'll work on this at some point, although there are some other things I want to work on first.

Well, I guess there's no work-around for the fact that the shuttle isn't meant to be flown using a keyboard. No aircraft is!

So I guess a joystick should be a requirement if you want to fly the shuttle. Another thing for bodyflap modulation is the pitch up moment of the drag chute deploy. It is almost severe enough to scrape the bodyflap into the ground mimicking the STS-3 landing at NOR!

 

[SiameseCat]

Just checked in the AOA autopilot. It uses the control surfaces only (so manual input will be necessary down to 70-75 km) and shuts off at Mach 2.5. AOA autopilot can be toggled using the DAP/CSS PBIs. Switching the MM 305 will permanently disable the autopilot.

 

[DaveS]

Just checked in the AOA autopilot. It uses the control surfaces only (so manual input will be necessary down to 70-75 km) and shuts off at Mach 2.5. AOA autopilot can be toggled using the DAP/CSS PBIs. Switching the MM 305 will permanently disable the autopilot.

First and second runs: Not good! Kept bobbing up and down and never settled down. The elevons were very active, to point of severe concern of MMACS, GNC, FDO and TRAJ!

I think this has something to do with too strong aerosurfaces. Currently the orbiter handles like a light jet(IE T38) or a highly maneuverable fighter(IE F16/F18) when it should really handle like a large commercial aircraft like a 747.

And the AoA were as low as 35°s at some points, that's 3°s below the minimum acceptable AoA for early entry!

 

[SiameseCat]

At what point did you engage the AP? It worked well for me; the only problems occurred if there was a large error (>1 degree) when the AP was engaged, in which case the shuttle would go out of control. In my testing, I've been engaging the AP at 100 km and using Glideslope MFD's autopilot for RCS control.

As far as the aerosurfaces go, they actually had to be strengthened from before; otherwise, they couldn't maintain the correct AOA.

 

[DaveS]

At what point did you engage the AP? It worked well for me; the only problems occurred if there was a large error (>1 degree) when the AP was engaged, in which case the shuttle would go out of control. In my testing, I've been engaging the AP at 100 km and using Glideslope MFD's autopilot for RCS control.

As far as the aerosurfaces go, they actually had to be strengthened from before; otherwise, they couldn't maintain the correct AOA.

Well, engaged at 100 km. Using the previously posted scenario. And for maintaining the proper AoA: I believe the bodyflap helps out alot. Yet, it's static in SSU, doing nothing.

I'll check with the guys over at NSF to get this sorted out once and for all. This could allow us to get things right.

---------- Post added at 06:44 AM ---------- Previous post was at 06:37 AM ----------

Also, the RCS pitch jets is active for quite a bit longer than they're in SSU. The transition point is a Qbar of 40 psf, which for STS-107 happened at an altitude of 66.501 km. In SSU they cut out way higher than that, somewhere at the transition betwen 80 and 78 km. For STS-107, pitch jet transition happened at EI+11 minutes, 52 seconds.

 

[SiameseCat]

I'll look at the pitch jet cutoff issue. Are you sure the bodyflap does nothing? It should go up as far as possible and stay there, while the elevons modulate to maintain AOA.

---------- Post added at 06:35 PM ---------- Previous post was at 06:27 PM ----------

For the aerosurfaces, one thing I want to try is using the mach/AOA to calculate the lift/drag/moment produced from lookup tables, instead of using Orbiter's aerosurface functions. I have no clue if this'll work, though.

 

[DaveS]

I'll look at the pitch jet cutoff issue. Are you sure the bodyflap does nothing? It should go up as far as possible and stay there, while the elevons modulate to maintain AOA.

---------- Post added at 06:35 PM ---------- Previous post was at 06:27 PM ----------

For the aerosurfaces, one thing I want to try is using the mach/AOA to calculate the lift/drag/moment produced from lookup tables, instead of using Orbiter's aerosurface functions. I have no clue if this'll work, though.

I have invited David413 to help us with this as he has a complete listing of all the various inputs to the Aerojet DAP.

And he has coded a very stable AoA Ap for the Shuttle Fleet while still retaining the heavy feel of the orbiter. Only problem I have ever noticed was lurch to the right between Mach 4 and Mach 3, so that you had to lean a bit on the yaw jets to keep the side-slip in check.

---------- Post added at 08:17 AM ---------- Previous post was at 01:00 AM ----------

Another thing that should be considered is making the AoA AP use the RCS jets until the aerosurfaces have been phased in. In fact the RCS is very active doing its job of maintaining the correct attitude.

And another thing is to implement a rate damper for roll/yaw to keep the sideslip from going out of control. We should also implement our own entry screens into CRTMFD as they're currently blank and useless.

 

[SiameseCat]

I don't think there's much point in implementing the entry screens in CRT MFD, since GPC MFD already does that.

I'll add the yaw damper and RCS control later, once all the aerodynamic issues are sorted out. A roll damper will be difficult, since we need to determine the correct roll rate. Once we get round to properly simulating the entry CSS control (all axes are damped) we can implement the roll damper.

 

[DaveS]

I don't think there's much point in implementing the entry screens in CRT MFD, since GPC MFD already does that.

The problem is that the DelAz is not being shown due to a UV mapping problem on the MDU meshes in the VC. And it is currently near impossible to fly the rolls as the orbiter has a tendency to spiral out of control. And I'm seeing plenty of FCS saturations on both the elevons and bodyflap as indicated on the SPI(pronounced "spee").

Just to tell you how bad the AoA AP is: Even Columbia with a deformed/missing left wing didn't experience OSH elevon and bodyflap positions during her final entry. Maximum elevon deflection was -8.11° on the left and -1.15° on the right.

So something here is very, very wrong, especially when an orbiter with a deformed wing flew alot better than SSU currently is!

 

[SiameseCat]

Is it possible to fix the meshes? I don't think it's worth the bother recreating the displays just to show one value. It also means we'll have to specify the landing site, which might be messy until we have GPC architecture.

It seems there's something very wrong with our aerosurfaces, if such small elevon deflections are needed to maintain AOA. In my testing, the elevons held a steady deflection of about 20° during early reentry, with the bodyflap fully deflected.

 

[DaveS]

Is it possible to fix the meshes?

I have tried importing the VC mesh into AC3D to fix this , but it always crashes on me. Maybe Donamy could send me an ac3d version of the actual checked in VC mesh?

It seems there's something very wrong with our aerosurfaces, if such small elevon deflections are needed to maintain AOA. In my testing, the elevons held a steady deflection of about 20° during early reentry, with the bodyflap fully deflected.

And according to David413, the bodyflap is fixed until Mach 16: http://forum.nasaspaceflight.com/index.php?topic=17437.msg644648#msg644648

Edit:
From my POV, it seems like the FCS is fighting something that makes the FCS saturated, so the FCS overreacts setting in motion a series of events that leads to full FCS saturation.

---------- Post added at 02:15 AM ---------- Previous post was at 01:09 AM ----------

Using GlideslopeMFD makes things better, no LOC and no FCS saturations. So I guess that's good news.

---------- Post added at 03:07 AM ---------- Previous post was at 02:15 AM ----------

Checked in a STS-107 de-orbit burn scenario. Noticed a problem though: The OMS TVC angles(ITEMS 6-8) are not saved/loaded.