SSU Development Thread (2.0 to 3.0)

Status
Not open for further replies.
That sound right. Orbitersim ignores that mass of attached vessels; the UpdateMass function adds the mass of all the attached vessels to the shuttle mass.

The other problem you might have is with the CG updating code. Currently, the CG updating code estimates the ET CG based on the amount of propellant left in the ET tank resource. You'll probably have to change this a little.

Yeah, I changed GetETPropellant() to call the ET and get the prop % in there (I'll look at that in detail later on). That means I'm not considering the mps manifold prop mass in that % calculation, and it's probably right because on a LH2 cutoff the manifold would be full, and in a LOX cutoff the manifold wouldn't be full, but it wouldn't be that far away from that.

BTW any luck with the ATVC angles?
 
Do we even have a usable SSU ? When ever I try it, it crashes. Can we get a download on OH, that can be used as an "SSU-lite" maybe? One that people can use without having had Shuttle Astronaut training.
 
Do we even have a usable SSU ? When ever I try it, it crashes.

I have some scenarios that work and many that don't. We badly need quality assurance tasks.

Can we get a download on OH, that can be used as an "SSU-lite" maybe? One that people can use without having had Shuttle Astronaut training.

Isn't that Shuttle Fleet?

And if it is not... what kind of functional and non-functional requirements and no-requirements would you see there, for comparison to SSU?
 
Yeah, I changed GetETPropellant() to call the ET and get the prop % in there (I'll look at that in detail later on). That means I'm not considering the mps manifold prop mass in that % calculation, and it's probably right because on a LH2 cutoff the manifold would be full, and in a LOX cutoff the manifold wouldn't be full, but it wouldn't be that far away from that.

BTW any luck with the ATVC angles?
I found one problem; in CalcSSMEThrustAngles, you're calculating the cosine of an angle in degrees - it needs to be converted to radians first. After fixing this, shutting off the left engine causes the stack to spin out of control; shutting off the right engine works fine.
 
Is there any autopilots, that could do the OMS burns if wanted ? Or rendezvous/docking ? AFCS that works for SSU ?

The Fleet is not compatible with some attachment points that the SRMS or SSRMS uses. The ISS AtoZ is being updated to SSU standards and Thorton's ISS has Fleet standards.
 
I found one problem; in CalcSSMEThrustAngles, you're calculating the cosine of an angle in degrees - it needs to be converted to radians first. After fixing this, shutting off the left engine causes the stack to spin out of control; shutting off the right engine works fine.

Thanks for spotting that, but on my end it still doesn't fix the problem.:facepalm:Not sure if that cosine is supposed to be there anyway....
A little check I do to see if it's good or not is to make pitchGimbal = 0 and yawGimbal = 0 (keep the current rates, right?), and then use the Scenario Editor to kill any rotation. If it holds with little variation then it's OK, if not then then math doesn't checkout.

One thing I just noticed about UpdateCoG() is that the cg output is not continuous (at least in second stage) but it seems to zigzag in the Y and Z axis in a 1 "large" step in the "right direction", 2 "small" steps in the "wrong direction" pattern. X is always 0 as it should be.
 
Is there any autopilots, that could do the OMS burns if wanted ? Or rendezvous/docking ? AFCS that works for SSU ?
Yes (MM 202), sort of (the ORBIT TGT display, which requires the target vessel to be defined in the scenario), and yes (although the deorbit burn has to be targeted manually).
 
I found the source of the "zigzagging cg": the UpdateCoG() function was getting the ET prop level from another function that only returned shorts, so the prop value being used didn't "update" every step. The result was that the ET mass didn't change, but the OV mass kept decreasing due to the APUs/WSBs/whatever, and so the cg "zigzagged" between the ET and OV.
When I "upgraded" the ET, I replaced the source of the ET prop mass by a function that returned shorts instead of using the one that returned the full value in doubles... anyway it's working well again. (Also tweaked the math to use one less division... just in case the compiler doesn't optimize that.)

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.
 
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.
 
Last edited:
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?
 
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:
 
This kitchen is big enough for everybody :P 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.
 
This kitchen is big enough for everybody :P 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.
 
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.
 
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.
 
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.
 
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?
 
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.
 
Status
Not open for further replies.
Back
Top