Space Shuttle Ultra 1.25 Revision B development

[SiameseCat]

OK. Couldn't it be changed to maintain a zero degree elevon angle instead of totally freaking out and saturating the elevons?

I guess the same question applies for early entry with roll rate, the AoA AP maintaining a zero deg/s roll rate and instead of reacting immediately it responds to a commanded roll angle.

The pitch needs to be controlled somehow - maintaining a zero degree elevon angle would cause the shuttle to either pitch up (and stall) or dive towards the ground. IMHO, once the autopilot ends at M2.5, the best thing is to downmode to CSS and have the user take control.

With roll, the problem is that there's no good way to set the aileron position (because we're still using CreateControlSurface for the ailerons). I'm in the process of creating a csv data file for the ailerons.

 

[DaveS]

The pitch needs to be controlled somehow - maintaining a zero degree elevon angle would cause the shuttle to either pitch up (and stall) or dive towards the ground. IMHO, once the autopilot ends at M2.5, the best thing is to downmode to CSS and have the user take control.

OK. How about an SM Alert 10 seconds prior to CSS downmode? That allows you to get ready to assume full control of the vehicle prior to things going totally awful.

With roll, the problem is that there's no good way to set the aileron position (because we're still using CreateControlSurface for the ailerons). I'm in the process of creating a csv data file for the ailerons.

For now, I would be happy with just a roll rate control for the RCS, since thanks to the ever increasing atmospheric density, roll rates are naturally dampened. And if some more muscle is needed, just use the yaw jets, since that's what Columbia did prior to roll rates becoming excessive.

 

[SiameseCat]

Roll rate CSS control (including elevon deflection) is now implemented. The csv data file is missing entries below M8.0; I'll try to finish up all the aerodynamic data over the weekend.

 

[DaveS]

Roll rate CSS control (including elevon deflection) is now implemented. The csv data file is missing entries below M8.0; I'll try to finish up all the aerodynamic data over the weekend.

Excellent! Will that finally finish up the aerodynamics so that we can move on to other things?

 

[Donamy]

A release of the compiled .dlls would be nice.

 

[SiameseCat]

Excellent! Will that finally finish up the aerodynamics so that we can move on to other things?

For the moment, yes. I'd like to implement a proper entry autopilot eventually, but that'll take a lot of work.

 

[jevans]

I redid the ADI ball using GDI+ and it all works now. This is how the ball actually looks - no numbers on it yet. The bending of the texture to make it look like a ball is all done in code - the texture is flat.

I'm now working on the indicators round it, like the tapes for H and H dot. When I've done most of the essential bits on that display I'll post the modified files on here.

 

[Urwumpe]

Looks great!

 

[DaveS]

Any updates on the VAB?

---------- Post added at 04:46 AM ---------- Previous post was at 02:23 AM ----------

Just a heads up: It seems like the UseRealRCS parameter in the SpaceShuttleUltra.cfg file is broken. When set to TRUE it causes a CTD upon loading any scenario (orbit, launch, entry and landing).

 

[SiameseCat]

Was UseRealRCS ever working? I think Urwumpe put it in ages ago to test more accurate RCS code, put I don't think it was ever really used.

 

[DaveS]

Was UseRealRCS ever working? I think Urwumpe put it in ages ago to test more accurate RCS code, put I don't think it was ever really used.

Makes sense. I think it was used to test the RCS jets defined in their real offsets and directions. Currently I think they're defined incorrectly in terms of locations and directions. It's just the AddExhausts that have the correct locations and directions.

Speaking of AddExhaust, where would I define AddExhaustStream to test particle streams for the RCS?

 

[Donamy]

Has anyone been working on PLBY lights ?

 

[SiameseCat]

Roll rate CSS control (including elevon deflection) is now implemented. The csv data file is missing entries below M8.0; I'll try to finish up all the aerodynamic data over the weekend.

All the csv entries have finally been added.

 

[Poscik]

I checked in my poor LDS code ;0 In Crawler.cpp on the bottom, there is the code for "tolerance knobs" animations on LDS displays. Of course they have clickspots. In LDS I tried to code finding desired attachment. Vessel is targeted very well, code recognizes it, but can't enter if() and write log that module recognized desired vessel. And that stopped my work. Still can't figure out what's wrong.

 

[SiameseCat]

I'll look at the code and see if I can figure out what's happening.

---------- Post added at 08:03 PM ---------- Previous post was at 07:46 PM ----------

See my comments in the "SSU Crawler Transporter development" thread. Any further discussion should probably go in there.

 

[jevans]

Looking at the MEDS PFD again, I'm trying to work out the different measurements of speed used: I'm deriving KEAS from dynamic pressure, which seems to work well, but I've come a little unstuck on Mach numbers. The DPS dictionary(pg 6-9) seems to specify two types of Mach number, M/VR(Mach Velocity Relative?) and M/VI(Mach Velocity Inertial?).

Now, I presumed that M/VR is relative to the Earth's surface, like Ground speed, and M/VI is inertial velocity, like Orbital speed. Thinking about this some more, Mach number is relative to airflow, not speed across a surface or otherwise, so I can't see where any difference would come from.

Anyone know? At the moment I'm just using the Orbiter-supplied value for both of them.

 

[Urwumpe]

Looking at the MEDS PFD again, I'm trying to work out the different measurements of speed used: I'm deriving KEAS from dynamic pressure, which seems to work well, but I've come a little unstuck on Mach numbers. The DPS dictionary(pg 6-9) seems to specify two types of Mach number, M/VR(Mach Velocity Relative?) and M/VI(Mach Velocity Inertial?).

It is differently and much more complex - please refer to the Air Data System Workbook for reference. In brief:

M/VR means : From 0 to 4, it displays Mach number, if the number is 4... 27 it is relative speed in kft/s. Similar with M/VI, the indicator then uses inertial velocity from 4 to 27.

The PFDs also display different Mach numbers than the DPS displays. The PFDs use Mach Number data calculated directly from the ADTA pressure outputs, without corrections, the DPS displays include corrections for Mach jump (nose shockwave of the Orbiter passes over the probes, between 1.1 and 1.6 Mach) and gear deployment.

Below Mach 0.9, the tape indicator displays KEAS (label changes as well) and the read out box below the velocity indicator tape shows M/V (Mach number).

 

[jevans]

I see. So it's Mach until Mach 4, then kft/s after that? I presume inertial/relative works the same as it does on the Orbiter Surface MFD.

There's not a lot of info in the workbook on the PFD, it's mainly about the DPS displays.

 

[Urwumpe]

I see. So it's Mach until Mach 4, then kft/s after that? I presume inertial/relative works the same as it does on the Orbiter Surface MFD.

Practically yes. There are just tiny differences by the different reference systems used. And don't forget: Below Mach 0.9, the tape indicator switches to KEAS and the digital readout below to Mach number.

There's not a lot of info in the workbook on the PFD, it's mainly about the DPS displays.

That is wrong... it has a chapter with all about the PFDs, that is related to the Air Data System...which is just speed, AOA, temperature and altitude.

 

[jevans]

Oh, that bit...:facepalm:

I'll see how much of this display I can get implemented over the holidays. Most of the problem is finding the bits of data to actually display, not the display itself...