Space Shuttle Ultra 4.0 PRESS TO MECO

[GLS]

I can't see anything wrong here. No gaps or anything.

They show here...

 

[DaveS]

Those issues have been fixed in revision 2530.

---------- Post added at 10:12 PM ---------- Previous post was at 02:49 AM ----------

Yes, I would say, something in our DAP code is directly talking to thrusters instead of thruster groups. Since the number of thrusters and the grouping of the thrusters changed, this could explain it.

Should a ticket be filed on this assigned to 4.0 for the DAP? This could explain why the Trans DAP isn't working as expected immediately post-ET-sep for the +X maneuver, takes about 5-10 seconds for the translation mode to work.

 

[Urwumpe]

Those issues have been fixed in revision 2530.
Should a ticket be filed on this assigned to 4.0 for the DAP? This could explain why the Trans DAP isn't working as expected immediately post-ET-sep for the +X maneuver, takes about 5-10 seconds for the translation mode to work.

We have the real RCS ticket already for it, one is enough. We should at least make sure that our DAP is not talking to the thrusters directly. Maybe I can find a solution already this weekend, I will not have too much time and wanted to finally get CMake work properly for Orbiter add-ons... but this shouldn't be a tough task.

 

[DaveS]

We have the real RCS ticket already for it, one is enough. We should at least make sure that our DAP is not talking to the thrusters directly. Maybe I can find a solution already this weekend, I will not have too much time and wanted to finally get CMake work properly for Orbiter add-ons... but this shouldn't be a tough task.

OK, so no new ticket. Something is up definitely with the thrusters or the DAP.

 

[Urwumpe]

OK, so no new ticket. Something is up definitely with the thrusters or the DAP.

The behavior feels like the DAP talks directly to thruster handles, instead of talking to thruster groups. That is why the old RCS had a different behavior when multiple axes fired at once, AFAIR.

 

[GLS]

This could explain why the Trans DAP isn't working as expected immediately post-ET-sep for the +X maneuver, takes about 5-10 seconds for the translation mode to work.

Don't they wait until MM104, and the end of the -Z translation, to do the +X?

EDIT:
looking at this video, the +X is only started after MM104
[ame="https://www.youtube.com/watch?v=aGz9Ky-rL7E"]STS-128 Replay - External Tank to Orbiter Separation - YouTube[/ame]

 

[DaveS]

Don't they wait until MM104, and the end of the -Z translation, to do the +X?

EDIT:
looking at this video, the +X is only started after MM104
STS-128 Replay - External Tank to Orbiter Separation - YouTube

Thanks for the correction, that is what I meant, but I wrote it wrong. The translation mode doesn't work correctly until 5-15 seconds after the -Z maneuver is complete. Trying to fire the +X thrusters only results in a right roll as if the rotation mode was still the selected mode. But waiting those seconds corrects it.

 

[GLS]

We have the real RCS ticket already for it, one is enough. We should at least make sure that our DAP is not talking to the thrusters directly.

IMO what we are missing is a "translation" for the DAPs to take what they want to do, and then command the appropriate RCS jets to fire to achieve that. I think this "translation" is done inside the DAPs, with all the jet priority logic, and the resulting commands then make their way to the individual RCS jets.

Looking at the Atlantis.cpp file, it feels like a quarter of it is RCS related, with functions to enable and inhibit and this and that, when IMO all we need there is a function to create the RCS thrusters during loading, and another with a loop to read discrete ports to check if a jet should be on or off (no need to inhibit jets at the thruster handle level, during reentry for example, just have the GPCs not use them). The discrete ports should be commanded by a SOP in the GPCs, leaving the RJDs and all the valves and panels for later implementation. This should give more control authority to the DAPs... but, they need to be smarter to decide how many and which jets to fire, and also to deal with axis coupling.

Anyway, I'd leave this for 5.0, as I don't think it is doable in short order, and so it will just delay 4.0 even longer.

---------- Post added at 11:22 PM ---------- Previous post was at 11:05 PM ----------

Thanks for the correction, that is what I meant, but I wrote it wrong. The translation mode doesn't work correctly until 5-15 seconds after the -Z maneuver is complete. Trying to fire the +X thrusters only results in a right roll as if the rotation mode was still the selected mode. But waiting those seconds corrects it.

I can confirm this. I can't check the code right now, but I'll try to look at it tomorrow.

 

[Urwumpe]

IMO what we are missing is a "translation" for the DAPs to take what they want to do, and then command the appropriate RCS jets to fire to achieve that. I think this "translation" is done inside the DAPs, with all the jet priority logic, and the resulting commands then make their way to the individual RCS jets.

Yes, but remember: Without RealRCS, we have only virtual thrusters with exhaust magic. That is why using a single thruster made sense for it.

Sadly we have no software specification for the GNC, so we can only guess how the software would operate. I suspect, the Orbit DAP is a background task operating on a RCS COMPOOL and a DAP COMPOOL, with the respective SPEC displays allowing to modify both RCS and DAP.

 

[GLS]

Thanks for the correction, that is what I meant, but I wrote it wrong. The translation mode doesn't work correctly until 5-15 seconds after the -Z maneuver is complete. Trying to fire the +X thrusters only results in a right roll as if the rotation mode was still the selected mode. But waiting those seconds corrects it.

Found the source of this issue: command routing. Currently the THC and RHC commands are "split" in the Atlantis.cpp file to RCS, Aerosurfaces and RMS. The current logic has this condition

if (status == STATE_ORBITER && GetAltitude() < 100000.0)

which sends RHC commands to the aerosurfaces and kills any THC command below 100Km. The observed delay is just the time it takes until the vehicle rises above 100Km, upon which the THC and RHC commands will be processed "normally" (and running the STS-1 launch, there is no delay because MECO is above 100Km).

This has an easy fix, but I'd really like to "clean the house" on this one. This "command splitting" should be done at the GPC level, where the running sw should decide if it wants to move this aerosurface by X degrees or fire RCS jet ABC or something else. Manual commands should be handled there as well: if MAN is enabled, the sw looks at the RHC and/or THC outputs and acts on that info.
The actuators (RCS, aerosurface, TVC) shouldn't care about the (initial) source of the commands. Each should have a single point of output at the GPCs (like commands to the SSMEs), and if sw Z wants system S to do something, it should take to the SOP responsable for that system.

Again, if this is to be done for 4.0.... it will be 2017 before it comes out...

 

[DaveS]

Where are we with everything? As far as the RCS issue is concerned, how about changing it to only work in certain OPS modes? Like 30x and the various abort modes.

 

[GLS]

Where are we with everything? As far as the RCS issue is concerned, how about changing it to only work in certain OPS modes? Like 30x and the various abort modes.

In relation the control issue in the last page, I can change the altitude for the 4.0 release as a "band-aid fix" (in 5.0 the new RHC/THC code coming up and then subsequent AerojetDAP changes will fix it permanently).

BTW: when is 4.0 coming out?

 

[Urwumpe]

BTW: when is 4.0 coming out?

Don't expect anything from my side for a while... I can already tell that I will definitely be working at the Rhine next year for the first three months. And the final weeks of 2016 are equally tightly planned by my management.

 

[GLS]

Don't expect anything from my side for a while... I can already tell that I will definitely be working at the Rhine next year for the first three months. And the final weeks of 2016 are equally tightly planned by my management.

Is the Real RCS so critical that we can't release 4.0 in the meantime? And then all move to Orbiter 2016 for good?

 

[DaveS]

Is the Real RCS so critical that we can't release 4.0 in the meantime? And then all move to Orbiter 2016 for good?

AFAIK, the only road block for the Real RCS currently is the Orbit DAP issue. Has anyone checked it so it is per the specs?

 

[GLS]

AFAIK, the only road block for the Real RCS currently is the Orbit DAP issue. Has anyone checked it so it is per the specs?

Can you refresh my mind? Is it the massive prop usage?

 

[Urwumpe]

Can you refresh my mind? Is it the massive prop usage?

OrbitDAP using thruster handles instead of thruster group handles. It is heavily broken that way. Can't tell now if I can fix it on the weekend, I go from "being busy because of having to save the day despite the management of our customer doing everything to let the project fail." to "Being busy because we need four skilled developers for a special topic in 2017."

 

[GLS]

OrbitDAP using thruster handles instead of thruster group handles.

... and that's bad because? Shouldn't it decide what to do (rotate this way, translate that way, etc), choose what thrusters to use by using whatever rules, and then command them on/off (via the appropriate channels)? IMO thruster groups are an abstraction (done by us) that isn't really needed. We should just have the thrusters "by themselves" (with the correct plumbing of course) and focus on having a good set of brains in the GPCs to use them to do this and that.

 

[Urwumpe]

... and that's bad because? Shouldn't it decide what to do (rotate this way, translate that way, etc), choose what thrusters to use by using whatever rules, and then command them on/off (via the appropriate channels)? IMO thruster groups are an abstraction (done by us) that isn't really needed. We should just have the thrusters "by themselves" (with the correct plumbing of course) and focus on having a good set of brains in the GPCs to use them to do this and that.

Fine. If you think it isn't needed, forget my suggestion and implement the silver bullet solution. It was just that, a suggestion.

In the current state, it does also not give a damn about your thrusters by themselves and plumbing and GPCs and all that heck. It simply faked thrusters. We did not have the PRCS thrusters. We had virtual thrusters with lots of exhausts. Looks nice, flys OK, isn't working if you want VRCS or use a special RCS configuration for docking.

Thruster groups would be a way to keep both new and old RCS parallel. But if you think we don't need them. Fine. I just know I can't implement them before 2018 and have no idea if I can do so in 2018.

 

[GLS]

Fine. If you think it isn't needed, forget my suggestion and implement the silver bullet solution. It was just that, a suggestion.

In the current state, it does also not give a damn about your thrusters by themselves and plumbing and GPCs and all that heck. It simply faked thrusters. We did not have the PRCS thrusters. We had virtual thrusters with lots of exhausts. Looks nice, flys OK, isn't working if you want VRCS or use a special RCS configuration for docking.

Thruster groups would be a way to keep both new and old RCS parallel. But if you think we don't need them. Fine. I just know I can't implement them before 2018 and have no idea if I can do so in 2018.

I didn't realize that was the current target... :embarrassed: Please carry on. :leaving: