SSU Development Thread (2.0 to 3.0)

[GLS]

So I'll just answer my question then. :lol:
Apart from a little bug in the animation of ME-3 (there's some aft translation in the nozzle when it gimbals), it seems to work well.

After checking that, I went and did a makeshift ATVC (and it's SOP), to command the gimbals, until Urwumpe finishes the ATVC/gimbal stuff he is working on. And it got this to do the pre-launch gimbals and mps dump/entry stow and then lowering the nozzles for the drag chute, blah blah... all with some guesses about the angles, because I can't find any real position data.
And because I'm not sure the current implementation of the SSME thrust vector control is correct (it works well, but looks like it might move beyond the actual limits), I rewrote some of the code that controls the vector directions during ascent.
And then I found out that I don't know as much algebra as I thought I did. :facepalm:
Not sure if I'm doing it wrong or if what I want to do is "impossible":
1) calculate the SSME thrust vector that gives 0 moment and calculate the angles to the axis, and use them in AscentGuidance to do the guidance math;
2) take the output from AscentGuidance and apply a "correction" for the SSME install position, i.e. the angles between the SSMEs 0º gimbal and the axis (the 16º/0º and 10º/+-3.5º angles from the "literature"), and then another "correction" corresponding to the angles of the 0 moment for each engine;
3) take the resulting angles above and rotate the SSME install position vectors, thus getting the new thrust direction, then and do the gimbal animation.
Essentially I want to have the ATVC/actuators rotate the SSME install vector by whatever angle it is requested, in the corresponding actuator plane.
So basically the problem is that with only the center engine running it looks like it does everything well, but when I use one of the side engines, it can't control the vehicle (something is not correct)... and if you're wondering about controlling roll with just one engine, I did implement SERC , so the engines just do pitch and yaw in those cases.
In 1, I'm using pretty much the existing CalcSSMEThrustAngles() function, for 2 it's pretty much just sums and I use a modified version of CalcSSMEThrustAngles() to get the angles for each engine, and for 3 it's the same SetSSMEGimbalAngles() function, and of course I created 3 new vectors corresponding to the SSME install positions. In CalcSSMEThrustAngles() I tried changing the angle calculation from asin() to atan() and atan2() which makes more sense in my head and still no joy.
I think the problem might be the 2 sets of 2 rotations: one X and one Y to obtain the SSME install vectors (done outside orbiter) and then the 2 rotations for the gimbal. Not sure if this sequence is supposed to work...
:sos:

I understand that this is not *exactly* mps branch material, although somewhat related. If anybody feels I shouldn't be doing this, I'll stop it and move the proper mps stuff.

 

[SiameseCat]

Can you post/commit the code you have? As far as I can tell, what you've done looks fine. I think the existing gimbal angle calculations are slightly off (using atan/atan2 instead of asin is probably correct), but the angles are small enough that this shouldn't have a big impact).

 

[GLS]

Can you post/commit the code you have? As far as I can tell, what you've done looks fine. I think the existing gimbal angle calculations are slightly off (using atan/atan2 instead of asin is probably correct), but the angles are small enough that this shouldn't have a big impact).

OK, I'll upload the whole thing to the mps branch in a few minutes. I'll also upload 2 test scenarios I use for a quick launch (STS-1 T-45s and STS-126 T-1m).
The SSMEx_INSTALLED_NULL_POS consts where calculated in matlab using the formulas from the RotateVectorX()/RotateVectorY()/RotateVectorZ() functions (in that sequence). I did try a bunch of different ways to create those coordinates (there're commented out)... not really confident in those.
Basically any running engine config that isn't balanced in yaw -> bye bye control. And I'm not 100% confident it's doing the job perfectly in pitch as well.
The angles in the ATVC are not in line with the real convention, and SERC is not perfect as it fires the FxD thrusters (need better RCS implementation) and then makes the RCS unusable after MECO. Will fix those later.

---------- Post added 08-11-14 at 04:29 PM ---------- Previous post was 08-10-14 at 05:17 PM ----------

Another possible cause for the ascent over-performance could be a further difference in ET prop mass (on top of the already discussed 5400lbs in the MPS manifold). Just found out that the SSMEs use about 11700lbs from ignition to T0. If the ET prop mass we are using is the prop mass at liftoff, instead of the tanked mass, then we are flying with a lighter vehicle. Don't know if this is the case (will look at all this and work the ET after the ATVC stuff is out of the way), but I just wanted to put this here for info (and also so I don't forget it ).

 

[gattispilot]

I think it is outside my league of coding. Willing to help though

 

[GLS]

So I'm doing the "propellant revolution", and to begin I moved the ET tank to the Atlantis_Tank vessel, and have a "MPS manifold tank" that feeds the SSMEs, and that calls the tank to "use" it's propellant (which I decrease accordingly using SetPropellantMass()).
Then I run this, and the mass of the vehicle is not decreasing :facepalm: (and of course it fails to get into orbit), although in the ScenarioEditor I see the ET propellant mass decrease at the appropriate rate.
Orbiter bug, am I doing it wrong or can't be done this way?

---------- Post added at 01:36 PM ---------- Previous post was at 01:51 AM ----------

Did a little more digging and managed to "fix" the issue by calling the UpdateMass() function in Atlantis every time I do the "ET mass update". Not really intuitive the way the mass of attached vessels is managed in Orbiter but looks like it works now.

(I think this "episode" also applies to the Centaur, when we get that to do in-flight propellant dumps)

 

[GLS]

I think it is outside my league of coding. Willing to help though

Well, I would say right now we need coders... take a look in here, there's a lot of work still to do. I'm not the boss, but if you ask me, right now we need the "SSU Mission Toolbox" the most. That, along with some small changes in the architecture, would make it a lot easier to change vehicle configuration.

(Shouldn't these posts should be moved somewhere else?)

 

[gattispilot]

It looks like it. Making an animated EVA person might be a start for me. It would be like a robitic arm. Press a key and move left arm,.....

Not sure if you could make the actions match movement. So if you move forward the legs move forward.

 

[GLS]

I think EVAs are a little down the road at the moment... we still have to get into orbit correctly first.

 

[gattispilot]

OK. Not sure how I can help then?

 

[Urwumpe]

The main problem I see is more trivial actually.

The project is so far lost in a hamster wheel of implementing new features, that the foundation is completely forgotten: There has to be a coding standard and a quality assurance of the contributions. SSU needs standards and standard frameworks - has anybody lately looked how much of the source code has no comments at all? How could somebody develop a new feature, if there is no help at all where to start? On one end SSU wants to do feature-driven development, on the other hand the necessary homework to do that is not done.

Also I think that more coders won't fix it - SSU would need one or two developers working on the main branch of SSU, implementing no new feature at all. Just analysing what is implemented, how it is implemented, refactor it, make everything uniform in coding style and architecture. And this alone could take a year, before any new feature could get added safely.

Before somebody complains here: A lot of the most sloppy code in SSU has been written by me, I know it.

But before we could let a beginner like gattispilot write a single line of code for SSU, we should make sure that we don't do two dangerous errors:

• Burn him out faster than a Sprint first stage by overwhelming his abilities
• Having to throw his work away because it is ultimatively unusable for the future, simply because we did not say in advance, what we expect.

We are not doing us any favor there, if the project SSU isn't managed. And managed does not mean, having nice friendly titles for every uninvolved person and noble positions for interested users, like common in many VSAs... it means knowing what every component of the software does and why it behaves that way. Regardless who does which task in SSU, he should be able to do it or be able to find a manual on how to do it.

 

[GLS]

Yeah, we really should take some time and do a "cleanup". Right now the Atlantis.cpp file has over 8000 lines, and I would say 30-40% is old commented code, which doesn't help when navigating in there. Also, there's some code in there that could be in other files, so we could have the systems +/- organized and have mainly SSU-Orbiter interaction in the Atlantis.cpp file.

About the documentation: I have done a few excel files with tables and stuff that help explain some of the things I'm doing in the MPS/SSME world (lists of valves and commands and so), and believe it or not this afternoon I was doing a "compilation" of all the discrete bundles and lines and their function. I'm planning to upload all that towards the end of the mps branch (hopefully within weeks) (If any dev wants it before please say).
Anyway I still need to right more comments :facepalm:

 

[SiameseCat]

So I'm doing the "propellant revolution", and to begin I moved the ET tank to the Atlantis_Tank vessel, and have a "MPS manifold tank" that feeds the SSMEs, and that calls the tank to "use" it's propellant (which I decrease accordingly using SetPropellantMass()).
Then I run this, and the mass of the vehicle is not decreasing :facepalm: (and of course it fails to get into orbit), although in the ScenarioEditor I see the ET propellant mass decrease at the appropriate rate.
Orbiter bug, am I doing it wrong or can't be done this way?

---------- Post added at 01:36 PM ---------- Previous post was at 01:51 AM ----------

Did a little more digging and managed to "fix" the issue by calling the UpdateMass() function in Atlantis every time I do the "ET mass update". Not really intuitive the way the mass of attached vessels is managed in Orbiter but looks like it works now.

(I think this "episode" also applies to the Centaur, when we get that to do in-flight propellant dumps)

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.

 

[GLS]

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?

 

[Donamy]

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.

 

[Urwumpe]

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?

 

[SiameseCat]

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.

 

[Donamy]

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.

 

[GLS]

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.

 

[SiameseCat]

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).

 

[GLS]

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.