SSU Development Thread (2.0 to 3.0)

[Urwumpe]

I strongly suspect that the DAP will have issues once we start using a realistic RCS. I think we should wait until after the release to start using realistic thruster positions.

Well, we will only know about the issues, if we can test this. But since this is consensus, I will push the work on this back to the following release, but then we should have this feature available ASAP.

 

[DaveS]

Well, we will only know about the issues, if we can test this. But since this is consensus, I will push the work on this back to the following release, but then we should have this feature available ASAP.

Well, considering it is an optional feature work can continue until it is stable enough to be made the primary way of using the RCS.

 

[Urwumpe]

Well, considering it is an optional feature work can continue until it is stable enough to be made the primary way of using the RCS.

Sorry, but there you are wrong.

The Centaur is optional. Even the IUS is optional for the short term future. Even everything pre-launch before crew ingress is optional, still we do it because it is part of our long-term goals with SSU.

Having a proper RCS thruster implementation that does not operate with idealized virtual thrusters with ideal thrust forces (the FRCS has less than perfect nozzles, with lower thrust than the ARCS) and thus with different effects on trajectory and fuel consumption is not optional, especially since you are reporting bugs that are possibly related to the state of the RCS implementation.

It can wait for the current release, because we had been releasing SSU for a while now with the same RCS as the vanilla Atlantis of Orbiter without anybody complaining. That's nothing to be proud of compared to our own standards, but not releasing anything in 2015 is worse.

 

[DaveS]

Sorry, but there you are wrong.

The Centaur is optional. Even the IUS is optional for the short term future. Even everything pre-launch before crew ingress is optional, still we do it because it is part of our long-term goals with SSU.

Having a proper RCS thruster implementation that does not operate with idealized virtual thrusters with ideal thrust forces (the FRCS has less than perfect nozzles, with lower thrust than the ARCS) and thus with different effects on trajectory and fuel consumption is not optional, especially since you are reporting bugs that are possibly related to the state of the RCS implementation.

It can wait for the current release, because we had been releasing SSU for a while now with the same RCS as the vanilla Atlantis of Orbiter without anybody complaining. That's nothing to be proud of compared to our own standards, but not releasing anything in 2015 is worse.

I meant that we currently have two RCS models, the idealized and the realistic. The idealized is default and the realistic can only be toggled on/off by a boolean parameter in the config file. As long as we have it set up this way, the realistic RCS doesn't impact anything as it is separate from everything.
When we have everything tuned right with the realistic RCS, the whole thing of toggling it on/off can be removed and it will become our only RCS implementation.

 

[Urwumpe]

I meant that we currently have two RCS models, the idealized and the realistic. The idealized is default and the realistic can only be toggled on/off by a boolean parameter in the config file. As long as we have it set up this way, the realistic RCS doesn't impact anything as it is separate from everything.
When we have everything tuned right with the realistic RCS, the whole thing of toggling it on/off can be removed and it will become our only RCS implementation.

Yes, that was the plan with the UseRealRCS flag. The idea to use such a flag was not just because we already have a working implementation, but also because I expect a longer testing and tuning phase for it to get properly integrated.

For example, we have SERC code directly in the Atlantis time-step functions, which directly interfaces with the RCS thruster handles. This is awful in multiple dimensions, but to get this properly resolved and moved into the proper layer of SSU, we need to get old and new RCS model reworked anyway and the available implementation decoupled from the subsystems and autopilot software that uses them.

And finally, once we have this decoupling done properly, we can also look at the more arcane parts of the ODB and implement the aerodynamic effects of thruster firing during reentry. Independent of if we are using classic or real RCS.

 

[Donamy]

"Light this candle !!":thumbup:

 

[Urwumpe]

"Light this candle !!":thumbup:

"Roger, go at throttle up."

Hey, give us a moment to fix a last few bugs BEFORE we launch. Nobody wants a STS-51-L edition release.

 

[GLS]

IMO the 11th (Tuesday ) is a good candidate date. It gives us time to get things ready but it's not too far in the future that it will make us relax.
I'm travelling back in time right now trying to fin the story with ticket 99. On the ius-1.0 branch things are mostly done. The only big item remaining is the manual (which I'm doing as an upper stage manual with Centaur and IUS sections) which currently is missing diagrams and final deploy instructions.

 

[Urwumpe]

IMO the 11th (Tuesday ) is a good candidate date. It gives us time to get things ready but it's not too far in the future that it will make us relax.
I'm travelling back in time right now trying to fin the story with ticket 99. On the ius-1.0 branch things are mostly done. The only big item remaining is the manual (which I'm doing as an upper stage manual with Centaur and IUS sections) which currently is missing diagrams and final deploy instructions.

If you need diagrams, I will open a thread somewhere around evening (Central European time) for diagram requests, to organize this a bit. This way, its easier to keep track of the already made diagrams. Will put them somewhere in the repository.

---------- Post added at 03:15 PM ---------- Previous post was at 03:14 PM ----------



The 11th might get hard from my end, since I have another wedding in my family in the week before, but I am sure it is enough time for SSU.

 

[GLS]

If you need diagrams, I will open a thread somewhere around evening (Central European time) for diagram requests, to organize this a bit. This way, its easier to keep track of the already made diagrams. Will put them somewhere in the repository.

---------- Post added at 03:15 PM ---------- Previous post was at 03:14 PM ----------



The 11th might get hard from my end, since I have another wedding in my family in the week before, but I am sure it is enough time for SSU.

We need to have a graphic representation of the payload attachment points on the upper stages, to help people attach their stuff to SSU. I was also thinking about having something like this for the payload bay (something simple) for the 4 upper stage scenarios (Centaur G, Centaur G', IUS (aft), IUS (forward)) so people know how much space is available in the payload bay.
BTW any ETA on the Centaur?

 

[Urwumpe]

BTW any ETA on the Centaur?

Post-release and post-IUS.

Also I am thinking about focusing more on the orbiter again in the future, there is a lot of work necessary.

 

[GLS]

Post-release and post-IUS.

Also I am thinking about focusing more on the orbiter again in the future, there is a lot of work necessary.

So... the IUS is also not going now.... :facepalm:
Then the diagrams are not needed.

 

[Urwumpe]

So... the IUS is also not going now.... :facepalm:
Then the diagrams are not needed.

Where is the problem with the IUS? I thought it is done. Are there any dependencies to the Centaur?

 

[GLS]

Where is the problem with the IUS? I thought it is done. Are there any dependencies to the Centaur?

So let me ask: where is the problem with the Centaur? The stage itself is done (it just needs a fix when reading the adapter parameters from the scenario), and the CISS is pretty much the same as the ASE, just a different panel, offsets, meshes, coordinates, IMO nothing that can't be done in a week. If the IUS got to a release position in about a week, so can the Centaur, as it is less work (the stage is done) and we can use most of the knowledge gained in the ASE in adapting the CISS from vessel to subsystem.
My :2cents:.

 

[Urwumpe]

So let me ask: where is the problem with the Centaur? The stage itself is done (it just needs a fix when reading the adapter parameters from the scenario), and the CISS is pretty much the same as the ASE, just a different panel, offsets, meshes, coordinates, IMO nothing that can't be done in a week. If the IUS got to a release position in about a week, so can the Centaur, as it is less work (the stage is done) and we can use most of the knowledge gained in the ASE in adapting the CISS from vessel to subsystem.
My :2cents:.

Its just my priorities. I want to get the known bugs fixed first, so we can work again on introducing new ones.

Also, I am pretty fed up with the release getting delayed for unscheduled features. I know that I share some lot of the blame there, since I supported putting the Centaur into the release, but who cares about what I said yesterday?

I think I had said it before pretty often: The next release has priority for me. Should the Centaur become the only thing that makes us delay a release, it can get pushed into the following release and done without hurry. And the more we delay the release for a new feature, the more other "features" will creep into it.

Should you say that the Centaur has to be in the next release, I will not be done on the 11th. I will not do it in a hurry.

---------- Post added at 07:11 PM ---------- Previous post was at 04:18 PM ----------

Just doing some ticket review here... #100 must not be done now, right?

 

[DaveS]

Its just my priorities. I want to get the known bugs fixed first, so we can work again on introducing new ones.

Also, I am pretty fed up with the release getting delayed for unscheduled features. I know that I share some lot of the blame there, since I supported putting the Centaur into the release, but who cares about what I said yesterday?

I think I had said it before pretty often: The next release has priority for me. Should the Centaur become the only thing that makes us delay a release, it can get pushed into the following release and done without hurry. And the more we delay the release for a new feature, the more other "features" will creep into it.

Should you say that the Centaur has to be in the next release, I will not be done on the 11th. I will not do it in a hurry.

---------- Post added at 07:11 PM ---------- Previous post was at 04:18 PM ----------

Just doing some ticket review here... #100 must not be done now, right?

No. All the VC tickets can wait until get to the VC remake post-release.

 

[Urwumpe]

No. All the VC tickets can wait until get to the VC remake post-release.

About the reentry mesh problems, I plan to split it into two tickets, one for the mesh fit and another for the calculations of the visibility. Must the visibility be addressed now?

 

[DaveS]

About the reentry mesh problems, I plan to split it into two tickets, one for the mesh fit and another for the calculations of the visibility. Must the visibility be addressed now?

Not really.

 

[Urwumpe]

Not really.

OK, keep it out of Milestone 2.1 then.

How is the availability on Sunday in the core team for a short planning what could go into the next milestone of SSU?

I want to do this before release, so we can continue development without issues then.

Since we hardly can use manhours for calculating the necessary effort into SSU, I would suggest using a WIP-limit approach to the features: We define categories for the change requests or new features and set a limit how many such changes can go into the category for the next release, so we can plan for a release in 6 - 12 months ( I think one release per year is not too ambitious)

 

[Urwumpe]

Does somebody have a scenario in which panel A8 does not work?

The star tracker switches in Panel O6 now react properly, there was a missing call to AtlantisPanel::Realize() in my implementation.