SSU Development Thread (2.0 to 3.0)

[Urwumpe]

But I have one question though: looking at UpdateCoG() I found that the height of both the LOX and LH2 is divided by 2 before being placed in the list... any reason behind that? I tried using the whole value and it seems to work fine.

Likely because the CoG for every tank individually was searched: Which is around liquid height / 2 for a simple approximation (The LOX tank geometry is a lot more complicated there). In better calculations, the CoG for every tank would need to be calculated together with the point mass of each tank...

For testing, what about making it possible to run the CoG function with defined inputs before the simulation starts and write the test results into a CSV file? I think I have a plot of the real CoG motion somewhere, so we could compare SSU behavior with operational data. Maybe even making an semi-automatic test possible, by simply comparing similar CSV files in Excel.

 

[GLS]

Yes, of course! In there we're after liquid cg, not height... (I was probably thinking about what I did in the MPS to get head pressure) :facepalm:

Another thing: the ATVC angles/SSME gimbal problem... I'm inclined to post the problem in the Math & Physics forum. It has been a couple of weeks since I uploaded the code and looks like nobody cracked this nut. Any problems in that?

 

[Urwumpe]

Another thing: the ATVC angles/SSME gimbal problem... I'm inclined to post the problem in the Math & Physics forum. It has been a couple of weeks since I uploaded the code and looks like nobody cracked this nut. Any problems in that?

Honestly... I tried to stay out of it since too many cooks ruin the chili. :tiphat:

 

[GLS]

This kitchen is big enough for everybody If you know rotations and have some spare time please give it a go.
I'd like to get this ATVC stuff out of the way before committing the "new" ET/MPS (which still isn't ready), either by getting it to work or by throwing it away and revert to what we had before.

 

[Urwumpe]

This kitchen is big enough for everybody If you know rotations and have some spare time please give it a go.
I'd like to get this ATVC stuff out of the way before committing the "new" ET/MPS (which still isn't ready), either by getting it to work or by throwing it away and revert to what we had before.

Well, looking at it, in the worst case, I can still wildly flip signs and (co)sines.

 

[SiameseCat]

Yes, of course! In there we're after liquid cg, not height... (I was probably thinking about what I did in the MPS to get head pressure) :facepalm:

Another thing: the ATVC angles/SSME gimbal problem... I'm inclined to post the problem in the Math & Physics forum. It has been a couple of weeks since I uploaded the code and looks like nobody cracked this nut. Any problems in that?

I think I've finally found the problem, actually. There are a couple of sign errors for the yaw gimbal, both in CalcSSMEThrustAngles and in correcting for the null position offsets. I can check the code in.

The other problem I'm encountering is that shutting an engine down early during second stage flight results in the shuttle pitching down and eventually going out of control. I think this is a guidance problem, since if the desired rates are set to 0, the shuttle remains stable.

 

[GLS]

I think I've finally found the problem, actually. There are a couple of sign errors for the yaw gimbal, both in CalcSSMEThrustAngles and in correcting for the null position offsets. I can check the code in.

Please do!

The other problem I'm encountering is that shutting an engine down early during second stage flight results in the shuttle pitching down and eventually going out of control. I think this is a guidance problem, since if the desired rates are set to 0, the shuttle remains stable.

Yes, if it's too early the guidance doesn't work. I can live with that, as there are more important things on the plate for now than aborts. For testing an engine out situation (or 2 engines out) I shutdown at about 6 or 7 minutes MET. That way the guidance works fine.

 

[SiameseCat]

Checked in the fixed code.

 

[GLS]

Checked in the fixed code.

OK, just checked and it works! Thank you very much! :thumbup:
Needed to change a sign in the heading code because the sign of ThrAngleY changed, and without a side engine the inclination error barely hits 0.01º.
Single engine control needs some work in the gains (and SERC is *crude* at best), but that can wait.
I'll upload the SERC fixes and updated scenarios tomorrow morning.

 

[GLS]

Almost sure it's not a problem, but asking is free so here it is: when I zoom inside the ET, there's a surface of something flashing... is that a problem?

 

[DaveS]

Almost sure it's not a problem, but asking is free so here it is: when I zoom inside the ET, there's a surface of something flashing... is that a problem?

Shouldn't be unless it's causing other problems.

 

[GLS]

Shouldn't be unless it's causing other problems.

No problems here, I was just curious.
Thanks!

 

[GLS]

Due to the current display split between the CRTMFD and the IDP/etc, and also the lack of BFS, I need some pointers as to where and how I implement the BFS SYS SUMM 1 display, so we can all see more MPS data (and other stuff as well).

 

[Donamy]

I have a problem with the Orbiter mesh. There are all kinds of distortions around the startrackers and detached vertices on the port OMSpod. Also, the windows show spaces around them.

 

[DaveS]

I have a problem with the Orbiter mesh. There are all kinds of distortions around the startrackers and detached vertices on the port OMSpod. Also, the windows show spaces around them.

Could a screenshot be provided please? Alos, do you know what revision of the meshes/source code for the modules?

I'm using the latest checkd-in versions and I have no issues.

 

[Donamy]

I don't know what rev it is, but was downloaded 2 days ago.

 

[DaveS]

I don't know what rev it is, but was downloaded 2 days ago.

Looks like it's the old mesh, not the new one. Just to be absolutely clear, you downloaded this as a zipfile and not through a SVN client such as TortoiseSVN?

 

[Donamy]

yes

 

[Urwumpe]

yes

That could be the reason there - most of the activity is via SVN... Did you never try TortoiseSVN? It is really simple to use.

 

[DaveS]

yes

OK, in that case there's not much that can be done. The newer stuff in the SVN repository already makes use of the new meshes/textures.

---------- Post added at 09:43 PM ---------- Previous post was at 09:41 PM ----------

That could be the reason there - most of the activity is via SVN... Did you never try TortoiseSVN? It is really simple to use.

Yes, I even wrote up how to get an up to date SSU installation in this thread: http://www.orbiter-forum.com/showthread.php?t=30336

I have verified the instructions in that thread several times and they're fine.