SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[GLS]

Because we have not 5 GPCs. We have 4 PASS GPCs running almost perfectly synchronous at times with up to 32 parallel tasks (FCOS limit) being executed, while other activities are done in the background by hardware. We have up to 25 I/O programs being executed by each IOP in parallel in the mean time (hardware limit, MSC + BCEs, but time division multiplex). And there is a BFS GPC somewhere in between doing its thing.

Would the number just be five, we would not have a problem. Would we just care for the 32 + 1 tasks being executed in parallel, we would still have a smaller problem.

Just serializing the PASS software would also not work out. We would replace finding a solution to making multiple threads run fine in the background of Orbiter by finding a way to define a multiprocess real-time system in a single thread and split it into frame-lengthed segments. I tried this a few times without getting into madness every time a new process is added into the system. Especially it would make it very hard to wait for I/O or special events in it, while it is a single liner in a thread.

We could just focus on making the displays run nice and pretend something happens - but this would mean everything that is not visible directly would not be happening or happening at the wrong time, just like the real-time behavior when interacting with them. And adding new displays like the payload specific ones would be much harder.

Sorry, but I hardly see any good chance to get past this. Even emulating the CPU would just solve a fraction of the problem and replace it by a new one. The idea to focus on the software partitions running the same software in sync sounds like the most economic approach in multiple ways. Out of multiple difficult approaches, its the least bad one.

I just have rarely more than 2 hours per week for working on any Orbiter project and my brain is still to badly damaged by my almost previous paid project. :facepalm:Almost previous - I still don't trust the calm.

I forgot the IOP part... so this means we will be able to have the MEC command issue that almost got STS-41D, right?

And can't we just add a OMS TVC subsystem for each engine and have a separate OMS engine handling the chemical work?

The problem with "adding" hardware is we need software to control it... I can do it, it's just that it will be another thing that will need to be "undone" in the future.

 

[Urwumpe]

I forgot the IOP part... so this means we will be able to have the MEC command issue that almost got STS-41D, right?

If we are getting so good at this, that we have to fix bugs the real developers had to fix.... I need a therapy.

The problem with "adding" hardware is we need software to control it... I can do it, it's just that it will be another thing that will need to be "undone" in the future.

I know. I also can't really define smaller tasks there yet. Once i am finally out of prototyping, I can be a bit more transparent there. We had run OK with the current GPC implementation, but every week, we get more reasons getting something better. Like the need to add payload specific displays and software for custom payloads.

We could of course make it simple and run all software all the time every timestep and actively "idle" by waiting for a timer to expire. But that would cost us more CPU cycles than emulating 5 GPCs.

 

[DaveS]

That will probably happen if you input someting in the trim items, which are currently added to the calculated gimbal positions... with the trims at 0 it should work.

Sorry, complete NO-GO on that as well. RCS wraparound still comes into play. Also, the residuals are once again out of spec.

This is how the current set up for the OMS TVC are vs the cg: https://www.dropbox.com/s/xxp77guu0ddktg0/SSU_OMS_VS_CG.jpg?dl=0

Could we add the OMS TVC animations? This way it would be easier to see just where we're aiming the thrust vector and see when it actually aligns with the c.g.

 

[Urwumpe]

Could we add the OMS TVC animations? This way it would be easier to see just where we're aiming the thrust vector and see when it actually aligns with the c.g.

Can this be done without a mesh change? I think currently the engine could become disconnected from the pods.

 

[DaveS]

Can this be done without a mesh change? I think currently the engine could become disconnected from the pods.

What do you mean? The engines already are separate meshgroups from the pods. Labels are ROME and LOME.

 

[Urwumpe]

What do you mean? The engines already are separate meshgroups from the pods. Labels are ROME and LOME.

Yes, but I mean, can we gimbal them around the gimbal axis (which is around the throat, not forward of the thrust chamber as for the SSME) without them getting disconnected? If I look correctly at the pictures, there should also be a shield.

 

[DaveS]

Yes, but I mean, can we gimbal them around the gimbal axis (which is around the throat, not forward of the thrust chamber as for the SSME) without them getting disconnected? If I look correctly at the pictures, there should also be a shield.

The OMEs should be OK. By "shield", do you mean the conical OME heatshield on the base of the OMS pod(s)?

 

[Urwumpe]

The OMEs should be OK.

OK, then it can be done. Just wanted to say the risks first and not get surprised later.

 

[GLS]

Sorry, complete NO-GO on that as well. RCS wraparound still comes into play. Also, the residuals are once again out of spec.

This is how the current set up for the OMS TVC are vs the cg: https://www.dropbox.com/s/xxp77guu0ddktg0/SSU_OMS_VS_CG.jpg?dl=0

Could we add the OMS TVC animations? This way it would be easier to see just where we're aiming the thrust vector and see when it actually aligns with the c.g.

In all honesty, I couldn't care less if the current setup does this or that. Judging by 2 diagrams now, both the position and the direction of the engines is wrong. The OMS engines don't have to point to the c.g. when they are at 0º/0º, otherwise they would have to be installed differently for each flight. The c.g. direction must however be within their gimbal range.

With the current TVC logic, having the trims at 0 is the most correct situation. The vehicle should "dance" during the initial portion of the burn, but it should settle in the correct attitude. If it doesn't and/or the residuals are big, then the current TVC logic needs work (which it does anyway as it is adding the trims, and the wraparound is wrong).
Right now I'm updating the scenarios to correct for the new OMS/RCS prop mass*, and then I'll look at this OMS business.


*) the nightmare of propellant resource order also needs to be adressed... eventually...

 

[DaveS]

In all honesty, I couldn't care less if the current setup does this or that. Judging by 2 diagrams now, both the position and the direction of the engines is wrong. The OMS engines don't have to point to the c.g. when they are at 0º/0º, otherwise they would have to be installed differently for each flight. The c.g. direction must however be within their gimbal range.

What do you mean by position? The angles I understand but the positions?

 

[GLS]

What do you mean by position? The angles I understand but the positions?

At least the coordinate x of position of the engines is wrong. Both diagrams say 88in = 2.2352m from the centerline, the code has 2.15m and the mesh is about 2.13m.

 

[DaveS]

At least the coordinate x of position of the engines is wrong. Both diagrams say 88in = 2.2352m from the centerline, the code has 2.15m and the mesh is about 2.13m.

I have checked a correction for this.

 

[Urwumpe]

Looks like I was wrong about the payload specific displays, found something interesting about them in the OFT SM specification... actually they are not developed for every payload, but there is a generic function for up to four payload SPEC displays in the SM software, they are just configured by tables.

Thus: This one requirement for the new DPS can be turned to lowest priority, we don't need to support custom software yet. Supporting custom payload display formats and I/O tables would be enough, the C++ code can be done once. (Of course, later, with more custom payloads or alternative history configurations, we might need alternative software as well. But this should do it for a while.)

Also it means we just need an internal API for the FCOS and HAL/S macros, no need to care for external APIs yet.

But still, we would need a tool to design display formats and then also the various tables that are used in SM. Damn, still one reason more to learn C#. :dry:

 

[GLS]

I have checked a correction for this.

Did you check the vertical position? It looks mighty close to the RCS pod... I think we'll break the china when we start gimballing the engine. :uhh:

 

[DaveS]

Did you check the vertical position? It looks mighty close to the RCS pod... I think we'll break the china when we start gimballing the engine. :uhh:

It looks close but it should be fine. Here's a photo of the aft shot by one of the crew members of ISS Expedition 22 during the RPM of STS-130. Note the small clearance of the ROME and the right stinger (this was the informal nickname for he ARCS pods).

It also seems like we have the on-orbit stow position of the SSMEs wrong based on that photo. At least for the lower two engines. Ours currently creep together in yaw but in that photo, it seems yaw remains at 0.

---------- Post added at 04:36 PM ---------- Previous post was at 04:21 PM ----------

Here's another photo showing the ROMS pod of Atlantis before it was removed for maintenance during the post-Columbia standdown in 2003: https://www.dropbox.com/s/zj5956gdequmbzs/03pd2589.jpg?dl=0

As you can see, there's plenty of clearance. Here's a screenshot from AC3D showing a similar angle: [urlhttps://www.dropbox.com/s/kxwjatz6wcje14n/AC3D_ROMSPOD.jpg?dl=0[/url]

I think this quote from Obi-Wan Kenobi is appropriate here: "Your eyes can deceive you. Don't trust them."

 

[GLS]

It looks close but it should be fine. Here's a photo of the aft shot by one of the crew members of ISS Expedition 22 during the RPM of STS-130. Note the small clearance of the ROME and the right stinger (this was the informal nickname for he ARCS pods).

It also seems like we have the on-orbit stow position of the SSMEs wrong based on that photo. At least for the lower two engines. Ours currently creep together in yaw but in that photo, it seems yaw remains at 0.

---------- Post added at 04:36 PM ---------- Previous post was at 04:21 PM ----------

Here's another photo showing the ROMS pod of Atlantis before it was removed for maintenance during the post-Columbia standdown in 2003: https://www.dropbox.com/s/zj5956gdequmbzs/03pd2589.jpg?dl=0

As you can see, there's plenty of clearance. Here's a screenshot from AC3D showing a similar angle: [urlhttps://www.dropbox.com/s/kxwjatz6wcje14n/AC3D_ROMSPOD.jpg?dl=0[/url]

I think this quote from Obi-Wan Kenobi is appropriate here: "Your eyes can deceive you. Don't trust them."

But is it in the correct place (Zo 492) according to the diagram?

 

[DaveS]

But is it in the correct place (Zo 492) according to the diagram?

That has now been adjusted.

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

I checked in an updated Atlantis_defs.h with new OMS reference positions. They seem to be holding with the correct DIR parameters.

 

[GLS]

I'm +/- finished with the "hardware" side of the OMS TVC and basic SOPs to interface with it. Now comes the difficult part of changing the existing software to use the new ways.

 

[DaveS]

I'm +/- finished with the "hardware" side of the OMS TVC and basic SOPs to interface with it. Now comes the difficult part of changing the existing software to use the new ways.

Does this mean the actual physics of the OMS? That should include the nozzle glow as that's how the nozzle cooling works, by radiation.

 

[GLS]

Does this mean the actual physics of the OMS? That should include the nozzle glow as that's how the nozzle cooling works, by radiation.

Just working TVC (but might get on/off control relocated). No valves or anything else for now.