Space Shuttle Ultra 1.25 Revision B development

[DaveS]

Sounds right, both should be included in the list as well.

EDIT: These require the OPS8 SPEC pages, right?

I think the Center SSME Repo is automatic while the post-landing SSME REPO is done by the PLT.

DaveS: Can you add the cover plate for the hole of the midbody payload umbilical well in the Orbiter to the main mesh, so that it is visible by default and can be hidden once we do more work on the Centaur?

I think this the best solution there, since we will less often have missions with centaur than without it.

Done.

 

[SiameseCat]

Suggestion for the next development steps (aside of bugfixing-a-lot):

Since GLS is currently contributing to the MPS code, what about improving the other subsystems that are required for the MPS operations?

As such, I identified the following small task items to be done:

• Implement MPS ENGINE STATUS indicator on Panel C3
• Engine shutdown buttons on panel C3 (connected to GPC via MDM)
• MPS TVC actuators and hydraulic valves correctly implemented
  • Basic Hydraulic actuator class
  • MPS Hydraulic valve class
  • Test case: Hydraulic Lock-up possible at low hydraulic pressure
• Test case: Stowing in Orbit
• Test case: Nominal ascent
• Test case: Center engine repositioning for reentry
• Test case: Rain drain repositioning for post-landing.
• Test case: Pre-launch Gimbal check

The hydraulic valves in the SSME all operate the same, thus it would make sense implementing them by a single class, and change only the parameters for each valve. They are electrically controlled (valve position = analog input voltage) and return the valve position as analog voltage again. These valves can be closed by pneumatic pressure if the hydraulic fails.



So, the valve needs as interfaces:

1. Hydraulic power
2. Hydraulic return
3. Pneumatic power (for emergency closing)
4. Control input A
5. Control input B
6. Position output

I plan to start at these tasks once the new notebook is there, but feel free to say "I do it" before I do. Every subtask should not take more than a weekend approximately, that should make it easy to plan. Important is test everything on the SCOM level. Not only the nominal "follow the checklist damnit" way.

I think GLS is working on some of this stuff already (especially the first 2 items).

 

[Urwumpe]

I think GLS is working on some of this stuff already (especially the first 2 items).

I had not seen such work yet, only improvements on the back-end.

 

[SiameseCat]

On the MPS Development thread, GLS wanted the F7 status lights, EIU power switches and the Shutdown Limits switch implemented on the appropriate panels.

 

[GLS]

Currently I don't have time to do much, only by the end of the year can I pick up coding again... But when I do I'll need some things from the people who know panels like engine shutdown PBs and the status lights, the He switches and EIU power switches so I can make those things do something when I get back on this train.
At my end, the hyd system would be really nice to have, but I still have a lot to do first so I can live without it for now.
The SSME "gimbal department" should all come from the ATVC (which I actually started looking into but never got anywhere:facepalm. I think there's a lot of commonality between the ATVC and the ASA, so it's like buy one, get the other free. :lol: I don't think there's any need to interact with the existing SSME classes (guidance generates position commands, passes them to the MPS TVC command SOP, and it commands the ATVC boxes that control the actuators that should just move the corresponding nozzle mesh and the thrust vector) so if anyone wants to do it be my guest , other wise I think I can do it, but it's not going to be before 2014

 

[Urwumpe]

So, back to the plan. :lol: I am not sure if ASA and ATVC are really equivalent there, I think they are different in behavior, but I would need to read about this too.

The C&W lights are also still not done, but I am not sure if this is a small task(tm) to implement. I know that I had started the primary C&W system, this would be another set of small tasks(tm).

About the motivation for this: We have quite many subsystems which are about 60-70% done, for getting towards the next major release, I want to have those systems further improved and made more robust, so the number of bugs for the already done subsystems is lower. The MPS is one of those, the APU/HYD another. The RMS is pretty much done and I don't know any bugs there, but some more review might be nice. I see some Aerodynamics warnings, are those in investigation?

What we would need as well soon: Stubs for the EPS and the TCS. No complete subsystems, but we should already have interfaces there defined so we can develop the other subsystems in a more complete stage.

Also I see that I have still not done the MDM-ASM tool. Will be done, so the warnings for the missing ROM files get removed. Which ROM files to load must be part of the mission file, together with the configuration of the MDMs.

 

[DaveS]

The RMS is pretty much done and I don't know any bugs there, but some more review might be nice.

Not quite. The RMS is far from done. The only modes implemented is ORB UNL and SINGLE/DIRECT. Also, right now the RMS moves with a constant speed while in reality the RMS behaves more like a train, it takes some time to get the speed up and to stop it. That's what the RATE gage on A8U is for.

Right now as implemented, the SSU RMS behaves as if it is constantly in the RATE HOLD mode which requires the RATE HOLD switch on the RMS RHC to be held down. As soon as it is released the RMS goes back to its normal mode.

Edit:
Also, the EE Camera view needs the light and singularity fix implemented.

 

[Urwumpe]

Ok, then the RMS tasks would also be needed on the list... will correct that after work.

 

[DaveS]

Another system that needs further implementation is the mechanical system. I guess that ties into the EPS work.

 

[Urwumpe]

Another system that needs further implementation is the mechanical system. I guess that ties into the EPS work.

Yes, it is also one of the most often needed components. The same applies to the relays and power switches in the Shuttle - the models and their parameters are known and documented, we can model their switching behavior accurately.

 

[SiameseCat]

Not quite. The RMS is far from done. The only modes implemented is ORB UNL and SINGLE/DIRECT. Also, right now the RMS moves with a constant speed while in reality the RMS behaves more like a train, it takes some time to get the speed up and to stop it. That's what the RATE gage on A8U is for.

Right now as implemented, the SSU RMS behaves as if it is constantly in the RATE HOLD mode which requires the RATE HOLD switch on the RMS RHC to be held down. As soon as it is released the RMS goes back to its normal mode.

Edit:
Also, the EE Camera view needs the light and singularity fix implemented.

The END EFF mode is also implemented for the RMS. The PL mode can be implemented fairly easily, but it will require mission file entries to specify the coordinate frame. I think this should wait until we implement the JSON mission file format.

I'd really like to see the mission file format changed before the next release. The sooner this is done, the less work it'll be to convert all the existing files.

---------- Post added at 09:32 PM ---------- Previous post was at 09:30 PM ----------

I see some Aerodynamics warnings, are those in investigation?

Which warnings are these? The only stuff I see in the log is

Loading aerodynamic data from file
Config/SSU_Elevon.csv
Loading aerodynamic data from file
Config/SSU_Aero.csv
Loading aerodynamic data from file
Config/SSU_BodyFlap.csv
Loading aerodynamic data from file
Config/SSU_HorizontalAero.csv
Read 3D table block ending at 242

Read 3D table block ending at 484

Read 3D table block ending at 726

Read 3D table block ending at 968

Read 3D table block ending at 1210

Read 3D table block ending at 1452

Read 3D table block ending at 1694

Read 3D table block ending at 1936

Read 3D table block ending at 2178

Read 3D table block ending at 2420

Read 3D table block ending at 2662

Read 3D table block ending at 2904

Read 3D table block ending at 3178

Read 3D table block ending at 3452

Read 3D table block ending at 3822

Read 3D table block ending at 4192

Read 3D table block ending at 4562

Read 3D table block ending at 4932

Read 3D table block ending at 5334

Read 3D table block ending at 5736

Read 3D table block ending at 6134

Read 3D table block ending at 6536

Read 3D table block ending at 6938

Read 3D table block ending at 7340

Read 3D table block ending at 7742

Loading aerodynamic data from file
Config/SSU_Aileron.csv

This is just debugging code, and is perfectly normal.

 

[Urwumpe]

I'd really like to see the mission file format changed before the next release. The sooner this is done, the less work it'll be to convert all the existing files.

I agree there. I could then also start the mission editor sooner and develop the SSU toolbox around it.

Which warnings are these? The only stuff I see in the log is

This is just debugging code, and is perfectly normal.

I had seen them in the ionif logs, possible that he used an old version.

 

[DaveS]

I just tested the fixed RMS EE camera view and it works great! No more twisting, except for the view going totally black when you look straight down. I'm not sure if this is a limitation or bug in the graphics client or a problem in the SSU code.

I also checked in corrected coordinates for the RMS camera views as the old ones were off. The only left is to add the EE light.

---------- Post added at 11:29 PM ---------- Previous post was at 06:30 PM ----------

I found a bug with the FWD bulkhead light, it can't be turned off. I tried flipping the FWD BHD light switch on A7U with no effect. It seems like it is hardcoded to always be on regardless of switch setting.

Edit:
Checked in an updated RMS mesh which fixes some issues with the EE. I also nailed down the true center of the EE camera position which revealed a problem with the OBSS. The vectors for the FWD grapple fixture are off, so the alignment target on the grapple fixture doesn't appear correct when you have grappled the OBSS with the RMS.

 

[SiameseCat]

I just tested the fixed RMS EE camera view and it works great! No more twisting, except for the view going totally black when you look straight down. I'm not sure if this is a limitation or bug in the graphics client or a problem in the SSU code.

I also checked in corrected coordinates for the RMS camera views as the old ones were off. The only left is to add the EE light.

---------- Post added at 11:29 PM ---------- Previous post was at 06:30 PM ----------

I found a bug with the FWD bulkhead light, it can't be turned off. I tried flipping the FWD BHD light switch on A7U with no effect. It seems like it is hardcoded to always be on regardless of switch setting.

Edit:
Checked in an updated RMS mesh which fixes some issues with the EE. I also nailed down the true center of the EE camera position which revealed a problem with the OBSS. The vectors for the FWD grapple fixture are off, so the alignment target on the grapple fixture doesn't appear correct when you have grappled the OBSS with the RMS.

Can you post a scenario for the EE camera problem? I haven't been able to reproduce this.

I think the FWD bulkhead light problem is actually the docking light still being on. At the moment, the docking light switch defaults to the 'DIM' position.

 

[DaveS]

Can you post a scenario for the EE camera problem? I haven't been able to reproduce this.

I think the FWD bulkhead light problem is actually the docking light still being on. At the moment, the docking light switch defaults to the 'DIM' position.

Thank, it turns out I had the two confused, it was the docking light. It works as its supposed to.

For the RMS view blanking out, try the EE attitude of 270.0, 0.0, 0.0. Blanks out the moment it hits that spot.

 

[SiameseCat]

RMS EE cam should be fixed now. I also changed the docking light switch to be in the OFF position by default.

 

[DaveS]

RMS EE cam should be fixed now. I also changed the docking light switch to be in the OFF position by default.

No joy on the EE cam fix. The blanking out still occurs at that attitude.

 

[SiameseCat]

I think the problem is with Orbiter and/or the graphics client. The old code has the same issue, and the parameters being used seem perfectly normal. For some reason Orbiter doesn't seem to like cameras pointing straight down. It only seems to occur for a very small range of attitudes, so it shouldn't be too much of a problem.

 

[DaveS]

I think the problem is with Orbiter and/or the graphics client. The old code has the same issue, and the parameters being used seem perfectly normal. For some reason Orbiter doesn't seem to like cameras pointing straight down. It only seems to occur for a very small range of attitudes, so it shouldn't be too much of a problem.

After consulting with jarmonik, this appears to be a core issue. However there is a workaround that can be implemented on the SSU level to get around this for now: http://www.orbiter-forum.com/showthread.php?p=392878&postcount=1819

 

[SiameseCat]

I've checked in a fix for the RMS EE camera issue.