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

[Urwumpe]

Generally, the handbook contains a lot of flight software implementation specific information, thats pretty great for improving our own guidance algorithm.

 

[DaveS]

Generally, the handbook contains a lot of flight software implementation specific information, thats pretty great for improving our own guidance algorithm.

Yes, I see some differences to how we do things currently. For example, if RTHU is used, the OMS TV ROLL angle in MM104/105 should 0 and not 180. This was to minimize the time spent in attitude change in the case an OMS-1 burn was required. That's per page 2.2.2-2, paragraph 3.

 

[Urwumpe]

Yeah, we have many such differences, but remember, we had little information about the GNC major function so far.

I think we can improve the situation a lot with this handbook, especially the many ET fast separation scenarios sound like a lot of "fun" to fly in a simulation.

I have to do a presentation about processes in a distributed system in january, I think about using the PASS as example there, since it is a nice different kind of distributed system among the more usual examples.

 

[DaveS]

On another note, I did some maintenance on our ticket list, and we only have 11 minor items to take care of. This is how it looks right now, 11 open items with 3 closed. If we accept that we won't have a "Hi-Q profile" for ascent and push that to version 7 (GNC Overhaul) that is.

 

[Urwumpe]

I am already looking at this again, but I think I'll do a bit more work on the project first to improve quality before release. Also I am still in debt for a JSON support for specifying the animation constants.

Anyway, before going on to GNC, I think I'll also invest a bit of effort into cleaning up the source files. All this monolithic chaos is pretty annoying and slowing things down here, I don't want to search for which file to modify for a desired behavior.

 

[STS]

Been away for a while (new job)
Seen many tickets, later I will review them.

 

[DaveS]

Any updates on progress towards getting 5.0 out?

 

[DaveS]

Is this project dead? Just want know, that's all.

 

[Urwumpe]

I can't contribute for a while, but that is sure no new status in the past years.

 

[n72.75]

Controversial opinion:

I think this project should switch to git.

Set it up as an organization on github with a few owners that can merge pull requests after a review. Add milestones etc.

Maybe I'm wrong, but I think it would help.

 

[Urwumpe]

Controversial opinion:

I think this project should switch to git.

Set it up as an organization on github with a few owners that can merge pull requests after a review. Add milestones etc.

Maybe I'm wrong, but I think it would help.

I agree that github is the better platform regarding the workflow support. But it doesn't provide developers.

 

[n72.75]

I agree that github is the better platform regarding the workflow support. But it doesn't provide developers.

No, not in and of itself.

But I think it would make attracting them easier.

 

[Urwumpe]

No, not in and of itself.

But I think it would make attracting them easier.

Maybe. But I think cleaning up the code and getting rid of all those technical debts might be better to make it even possible for somebody outside the project to understand it how to develop this behemoth...

We are at a point, where one developer alone can't be specialist for everything. And I am far too old to even try this stunt.

 

[DaveS]

Maybe. But I think cleaning up the code and getting rid of all those technical debts might be better to make it even possible for somebody outside the project to understand it how to develop this behemoth...

Well, for what it is worth, I have it on pretty good authority that Windows itself isn't much better. Even the build environment was a spaghetti-code mess right up to Windows 10. So it couldn't hurt to put it on github to see what kind of nibbles we might get.

 

[DaveS]

Found this ascent related chart in the Space Shuttle Program Integration portion of the STS-103 Flight Readiness Review document collection. The FRR documents for a bunch of pre-Columbia missions can be found archived here: https://web.archive.org/web/2013060...asa.gov/centers/johnson/news/shuttle/frr.html

 

[DaveS]

These are interesting failure points:

 

[Urwumpe]

Well, that is a prelaunch failure, right?

 

[DaveS]

Well, that is a prelaunch failure, right?

Most of them yes, but there is failure effects for a ALCA-1/2 failure from T0 through MECO+2 minutes as listed. The issue is inability to properly inert the LH2 system as only the RTLS backup dump valve would be available and not the LH2 F/D valves. LOX of course is purged through the engines, so no issues there.

 

[DaveS]

Back to the ascent performance stuff. Just for curiosity's sake, I decided to see where our SRB impact points were. After a number of runs, it turns out they're 233 km downrange from KSC. This is around 35 km short of the historical SRB impact points, which were around 270 km downrange. This tells me that we're leaving alot of 1st stage horizontal velocity on the table and that we're staying too high for too long. We need an more aggressive 1st stage pitch profile.

 

[Urwumpe]

Back to the ascent performance stuff. Just for curiosity's sake, I decided to see where our SRB impact points were. After a number of runs, it turns out they're 233 km downrange from KSC. This is around 35 km short of the historical SRB impact points, which were around 270 km downrange. This tells me that we're leaving alot of 1st stage horizontal velocity on the table and that we're staying too high for too long. We need an more aggressive 1st stage pitch profile.

I think we generally need to collect more telemetry data, aggregate it and compare it to real world data and performance. Its a bigger project, since tuning one aspect better might result in another getting worse - e.g. changing the launch trajectory could hide that actually the full-stack aerodynamics where wrong.

Also, I could need Shuttle-C support for some 1990s alt history and I have absolutely no idea yet how to integrate that into dev.

We need better debugging tools as well. With one 1/4 C++ dev for the future, we can barely get one thing done at a time.