Space Shuttle Ultra 1.25 Revision B development

[DaveS]

Any updates on the various items in progress? For example the auto entry and VAB?

 

[Urwumpe]

Any updates on the various items in progress? For example the auto entry and VAB?

VAB: Back on it this weekend, have to see if things work together. But I first need about 3 hours for the Black Dart, learned something interesting from ARM processor assembly language, that I want to use.

 

[Donamy]

VAB: Back on it this weekend, have to see if things work together. But I first need about 3 hours for the Black Dart, learned something interesting from ARM processor assembly language, that I want to use.

:blink:

 

[Urwumpe]

:blink:

No worries, I am still about 70% sane, as usual. I'll explain it in a blog post, when I have finished this work package, otherwise it gets really off-topic here.

 

[DaveS]

I have checked in a incomplete development version of the new Ku band DA mesh/texture. I have taken it as far as my skills are able. I hope someone else with better skills could take over from here.

Donamy, think you could take it from here?

 

[Donamy]

To be honest, I don't know if I can run it. I'm still waiting for the newest .dlls to be uploaded. Or better yet, some kind of public release. Beta of course.

 

[DaveS]

To be honest, I don't know if I can run it.

Run what? The new Ku DA?

 

[SiameseCat]

I've finally committed the entry guidance code. In AUTO mode, the shuttle should itself from EI to M2.5.

The roll command is still a bit oscillatory, especially near the start of entry (in the Temp Control mode).

Donamy: I'll try to upload a new set of dlls tomorrow.

 

[DaveS]

I've finally committed the entry guidance code. In AUTO mode, the shuttle should itself from EI to M2.5.

The roll command is still a bit oscillatory, especially near the start of entry (in the Temp Control mode).

Donamy: I'll try to upload a new set of dlls tomorrow.

Works very nicely here. I guess item could be tweaking of the entry mesh transition regions.

 

[SiameseCat]

New dlls have been uploaded, for anyone who can't compile the code.

 

[DaveS]

Another thing that would be nice is the ability to switch landing sites. Currently we can only land at KSC despite having Vandenberg AFB available. The landing site tables for the mission can be found in the Entry FDF Supplement.

And I think there's a bug with the air data probe animations. They refuse to deploy when commanded to. You can try this with STS-107 Entry Interface scenario. When at M=5, take the two AIR DATA PROBE switches on C3 to DEPLOY or DEPLOY/HEAT and nothing happens with the probes. They remain stowed.

---------- Post added 03-24-12 at 12:58 AM ---------- Previous post was 03-23-12 at 11:16 PM ----------

Some suggestions on the next systems up for implementation:

• OMS/RCS
• APU/Hyd
• ODS
• PDRS
• Mechanical Systems

 

[Urwumpe]

I think it would be better to work bottom up, than top down. We have not yet an at least partially complete DPS, we have no electrical power, no ECLSS. Mechanical systems are an often repeated aspect, that are can be reused often, once defined.

Also, a lot of the systems you mention are already there, just pretty often in a very bad shape, because we just fix around them, instead of really doing goal oriented development.

My personal suggestion would be selecting one and just one subsystem or model and then implement it together. If it has dependencies on other subsystems, we introduce empty facades for them.

What has to be finished ASAP, if you ask me:

1. VC optimizations.
2. C&W subsystem. I know that I had done some work already there.

I know that the non-developers would rather want to see new subsystems and shiny details, but we need the foundations for them. We can't refactor things again and again for every subsystem that is added.

 

[DaveS]

Could someone add an option to mission file to equip the orbiter with SILTS pod mesh? It is a bit strange not seeing it on top of the vertical stabilizer when you're flying Columbia. She did have it for a majority of her career(STS-61C through STS-107).

Edit:
How would we go about simulating the different vehicles mass-wise? There should be a mass penalty if you decide to use Columbia compared to Endeavour.

 

[Urwumpe]

Could someone add an option to mission file to equip the orbiter with SILTS pod mesh? It is a bit strange not seeing it on top of the vertical stabilizer when you're flying Columbia. She did have it for a majority of her career(STS-61C through STS-107).

Edit:
How would we go about simulating the different vehicles mass-wise? There should be a mass penalty if you decide to use Columbia compared to Endeavour.

I think we already have such an option there, it is possible that it refuses to work in 2010.

For the mass properties, it depends on where we want to draw the boundary what is constant in a scenario. I would personally prefer saving the available verified hardware in the scenario file, so that it is possible to upgrade a Space Shuttle orbiter while others still fly missions during a longer campaign, like we once defined as goal, to fly multiple missions with the same orbiter and have multiple orbiters available in the same scenario in different phases of mission preparation.

 

[DaveS]

I think we already have such an option there, it is possible that it refuses to work in 2010.

No, this have never been implemented. The mesh file have already since long been checked in.

To be honest, I don't know if I can run it.

Any answer on this question? I'm not sure what you mean by this.

 

[SiameseCat]

I think we already have such an option there, it is possible that it refuses to work in 2010.

For the mass properties, it depends on where we want to draw the boundary what is constant in a scenario. I would personally prefer saving the available verified hardware in the scenario file, so that it is possible to upgrade a Space Shuttle orbiter while others still fly missions during a longer campaign, like we once defined as goal, to fly multiple missions with the same orbiter and have multiple orbiters available in the same scenario in different phases of mission preparation.

There isn't a mission file option for the SILTS pod. DaveS, do you know what the possible visual differences between orbiters are? The only ones I can think of are the SILTS pod and the drag chute.

For the mass problem, I think the best solution is to include a mission file line specifying the Orbiter mass (with empty fuel tanks, and excluding the RMS, ODS, etc.). The mass of all the other optional hardware would be added to this value.

 

[DaveS]

There isn't a mission file option for the SILTS pod. DaveS, do you know what the possible visual differences between orbiters are? The only ones I can think of are the SILTS pod and the drag chute.

Same here. Any other can be done through the existing texture option.

Another thing that could be done is to wire up the bodyflap to the position indicator on the SPI.

Edit:
Now that things are working pretty good, how about getting rid of all the debug text outputs?

---------- Post added at 11:07 PM ---------- Previous post was at 09:05 PM ----------

Another thing that just came to me is the star tracker door animation. Looks a bit weird launching/landing with the doors open.

 

[Poscik]

Can anyone tell me if HAC radius is calculated "in-time" or is it constant? I mean in SSU algorithm. I'm flying STS-107 scenario and I have real problem to remain on energy during HAC. Any chance to "quick-lock" HAC radius to be constant if so?

 

[SiameseCat]

The HAC radius isn't constant.

When you're flying the HAC, you might want to try following the guidance diamond - it seems to work pretty well after HAC intercept, especially in the roll channel, although it doesn't work until you're on/near the HAC.

 

[Donamy]

How about stowing the SSMEs after ET sep ?