Space Shuttle Ultra 1.25 Revision B development

[Yoda]

Can't seem to be able to find a link for downloading the SSU........
Any help you guys can provide ?

 

[diogom]

Can't seem to be able to find a link for downloading the SSU........
Any help you guys can provide ?

http://www.orbiter-forum.com/showthread.php?p=309956#post309956

 

[Poscik]

That's early preview. Now fighting with proper scaling and orientation The main problem I have to deal with, is converting position in local vessel frame to screen coordinates. Now it's done by few proportions, but the more I'm misaligned with runway, the more offset appears and drawing floats off from correct position.

 

[DaveS]

Any one up to making the HUD brightness switches working? I find the default HUD brightness a bit low for day landings so it would be nice to be able to adjust it.

 

[SiameseCat]

Pretty much complete. I'm hoping to check the code in tomorrow.

HORIZ SIT code has been checked in.

 

[Poscik]

I'm thinking wether I should leave this offset as it is. Just look onto this screen from STS-129 landing video, I'm getting very similar situation:

 

[DaveS]

I'm thinking wether I should leave this offset as it is. Just look onto this screen from STS-129 landing video, I'm getting very similar situation:

That has the orbiter not wings-level. Here's a shot from STS-132. Orbiter is wings-level and so is the runway outline.

 

[Urwumpe]

You should also remember that this is a HUD. It only displays the objects accurately, if it is calibrated for the position of the eyes of the pilot that should see it. A camera filming the reentry slightly off the line to the pilots eyes will of course result in distorted projections.

 

[Poscik]

But as far as I know, this is only for reference. It isn't used for precise guidance. So I think small offsets aren't dangerous.

 

[DaveS]

Could someone fix the saving/loading of CRTMFD states? Right now it seems to save everything correctly, but loading isn't working. It always defaults to the subsystem displays even if the state in the scenario file is for a DPS screen.

 

[Poscik]

I can check in what I've done. What I have:

• reentry calculations, you can follow altitude error to reenter precisely to destination. There will be few restrictions. F.e. recommended range from EI to landing site will be ~4000nm. But I'll measure everything.
• Runway drawing on HUD. Problem with floating still exists. The more difference in heading, the more it floats. Also even if it's perfectly aligned on HUD, it is misplaced in VC HUD. I tried many many things to fix at least floating. I was even talking to Fizyk, who also can't tell what is wrong.

[EDIT]
Code has been checked in.

 

[David413]

HUD runway position

But as far as I know, this is only for reference. It isn't used for precise guidance. So I think small offsets aren't dangerous.

The runway overlay on the HUD is actually a reflection of where the guidance system "thinks" the runway is located. Any offset is therefore a reflection of where guidance wants to land. On several of my motion-based sim runs I would be landing with a cross-wind and that would have a tendancy to shift the overlay left or right of the actual runway. The stronger the cross-wind, the more displaced the overlay.

Since Orbiter doesn't have cross-winds (yet), the overlay should be projected to the runway itself (in theory). As soon as I was established on final approach I would declutter the HUD one level and get rid of the overlay, this seemed to be the common behavior in talking with the sim instructor.

 

[DaveS]

I can check in what I've done. What I have:

• reentry calculations, you can follow altitude error to reenter precisely to destination. There will be few restrictions. F.e. recommended range from EI to landing site will be ~4000nm. But I'll measure everything.
• Runway drawing on HUD. Problem with floating still exists. The more difference in heading, the more it floats. Also even if it's perfectly aligned on HUD, it is misplaced in VC HUD. I tried many many things to fix at least floating. I was even talking to Fizyk, who also can't tell what is wrong.

[EDIT]
Code has been checked in.

How's the wok coming along to hook up the calculations to the actual Aerojet DAP?

 

[Poscik]

I wonder If I can write good performing PID.

 

[Donamy]

Only one way to find out. :thumbup:

 

[SiameseCat]

I can check in what I've done. What I have:

• reentry calculations, you can follow altitude error to reenter precisely to destination. There will be few restrictions. F.e. recommended range from EI to landing site will be ~4000nm. But I'll measure everything.
• Runway drawing on HUD. Problem with floating still exists. The more difference in heading, the more it floats. Also even if it's perfectly aligned on HUD, it is misplaced in VC HUD. I tried many many things to fix at least floating. I was even talking to Fizyk, who also can't tell what is wrong.

[EDIT]
Code has been checked in.

I've checked in some changes to the HUD runway code which seem to fix the problems.

 

[Urwumpe]

Only one way to find out. :thumbup:

Strap him to an electric chair and give him one hour to define the PID controller to regulate his charge? :rofl:

 

[n72.75]

You should also remember that this is a HUD. It only displays the objects accurately, if it is calibrated for the position of the eyes of the pilot that should see it. A camera filming the reentry slightly off the line to the pilots eyes will of course result in distorted projections.

HUDs are parallax free. See the diagram below.

 

[Urwumpe]

HUDs are parallax free. See the diagram below.

Parallax free, but not immune against offline position. Imagine sitting slightly sideways, while the runway drawing code assumes you are sitting lined up with the HUD.

 

[DaveS]

Here's the Entry, TAEM and Approach Guidance Workbook

It should be good for figuring out a workable entry guidance for SSU.