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

[Urwumpe]

The OMS displays are feed directly from the sensors.
The SSME controller does all the redundancy management for its sensors. The SSME is "special", that's why there are 4 parts in the shuttle: the ET, SRBs, OV and SSMEs.

Yeah, but still, its a bit tough to get everything memorized sometimes.



Any idea how to make a MLS or TACAN work with orbiters nav beacons?

 

[GLS]

Any idea how to make a MLS or TACAN work with orbiters nav beacons?

Not at the moment. Right now I'd just like to get the guidance part running so we can release.

 

[Urwumpe]

Sure, no deal, I just try to keep some distance to the DPS stuff there.

 

[Wolf]

Sorry, a bit out of topic: I' ve seen Tim13 is using 5.0, is it available for download somewhere?

 

[DaveS]

Sorry, a bit out of topic: I' ve seen Tim13 is using 5.0, is it available for download somewhere?

If you're using SVN, then you're using 5.0. Development of 4.2 ceased when it was released and we moved from Orbiter 2010-P1 to Orbiter 2016. SSU 5.0 is the version intended for Orbiter 2016.

 

[Urwumpe]

Regarding the guidance equations, might this document be an interesting source for anybody?

http://hdl.handle.net/2060/19930019132

 

[GLS]

Regarding the guidance equations, might this document be an interesting source for anybody?

http://hdl.handle.net/2060/19930019132

Not sure, probably not. I already dug up stuff for Entry, TAEM and Autoland, so we should be good on that end. The FCS might be a bigger issue...


Anyway, right now I'm having problems with filters. Integrators are done (I think) like this:

y += x * dt

But how do I implement this filter?

  A
-----
s + A

Converting that to the time domain gives:

y = x * A * exp( -t * A )

but that gives a nice exponential decay, that is pretty much useless in filtering e.g. airspeed. :facepalm:

 

[Urwumpe]

what kind of digital filter do you intent to make? FIR or IIR?

 

[GLS]

what kind of digital filter do you intent to make? FIR or IIR?

A working one...:rofl:
IIR should be simpler... right?

(too much theory, too little practice :facepalm

 

[Urwumpe]

A working one...:rofl:
IIR should be simpler... right?

(too much theory, too little practice :facepalm

Depends on what you want to achieve. FIR has no feedback, IIR has. If you just want a low pass filter to cancel out the jitter, FIR is good enough.

 

[GLS]

Depends on what you want to achieve. FIR has no feedback, IIR has. If you just want a low pass filter to cancel out the jitter, FIR is good enough.

There are several apperances of that transfer function, with different values for A, hence why a more "correct" implementation is probably a good idea, as opposed to using the Averager class to smooth something, which I don't really know how to configure based on the A value.
Here is the Averager class in use in the AerojetDAP for the NZ:

if(lastNZUpdateTime < SimT-NZ_UPDATE_INTERVAL)
{
	lastNZUpdateTime = SimT;
	nzAveraging.NewValue( ReadCOMPOOL_FP( SCP_DW_NZ ), SimT );
	averageNZ = nzAveraging.GetAvgValue();
}

The problem is going from the A value to that update interval and to the length of the average (that goes in the constructor). :shrug:

 

[Urwumpe]

Why don't you implement the Kalman filter of the GNC MF base to get this value among others?

https://en.wikipedia.org/wiki/Kalman_filter

Also, this kind of question is why I asked about the MLS lately - many GNC sensors are still WIP, its getting time to finish them.

---------- Post added at 14:45 ---------- Previous post was at 14:32 ----------

Here is a paper about the early state of things, maybe its good enough already for getting started:

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740018033.pdf

 

[DaveS]

Also, this kind of question is why I asked about the MLS lately - many GNC sensors are still WIP, its getting time to finish them.

Like the star trackers. We can't even open the doors right now. Same for the AVS doors. Those are commanded to the full open position by the RSLS at the T-27 second point. If one of the doesn't reach the full open position by T-20 seconds an RSLS cut-off will be issued and the launch scrubbed.


The MMACS flight controller actually calls this out on the Flight Loop when it has happened ("All vents open") and the Flight Director usually replies with "Copy vents".

 

[GLS]

Like the star trackers. We can't even open the doors right now. Same for the AVS doors. Those are commanded to the full open position by the RSLS at the T-27 second point. If one of the doesn't reach the full open position by T-20 seconds an RSLS cut-off will be issued and the launch scrubbed.


The MMACS flight controller actually calls this out on the Flight Loop when it has happened ("All vents open") and the Flight Director usually replies with "Copy vents".

That's all very pretty and we could always "duct-tape" something together, e.g. like the AerojetDAP was, and it does many things. But when you want something else, or want to correct something... :facepalm:

I think we have a system that works for the most part, but IMO it's pretty stretched out, and some reorganization "under the hood" is needed to enable new stuff. Taking the AerojetDAP again as an example, it contained the SPEC 50 display. If we wanted to do a TAL or ECAL, we could not access that display to choose our landing site, as all that was inside the AerojetDAP and it doesn't run during ascent.
By me adding the SimpleCOMPOOL, organizing the guidance part and moving the display to "a better place", in the future it will be much easier to give full use to the display, although in the meantime nothing *new* is added so it seems like walking sideways. :shrug:

---------- Post added at 02:35 PM ---------- Previous post was at 02:32 PM ----------

Why don't you implement the Kalman filter of the GNC MF base to get this value among others?

https://en.wikipedia.org/wiki/Kalman_filter

Also, this kind of question is why I asked about the MLS lately - many GNC sensors are still WIP, its getting time to finish them.

---------- Post added at 14:45 ---------- Previous post was at 14:32 ----------

Here is a paper about the early state of things, maybe its good enough already for getting started:

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19740018033.pdf

I'm leaving navigation alone for now... guidance is already enough (plus a few touches in the FCS, plus the entry displays and HUD... and I'll try super hard not to touch the IDP for now).

 

[Urwumpe]

Like the star trackers. We can't even open the doors right now. Same for the AVS doors. Those are commanded to the full open position by the RSLS at the T-27 second point. If one of the doesn't reach the full open position by T-20 seconds an RSLS cut-off will be issued and the launch scrubbed.

I remember, the implementation of the mechanic systems. I had pushed this back for having more time for DPS stuff. I can return there as long as I keep safety distance to DPS work.

Also we now have better definitions of the mechanics and the relay logic than back then.

The MMACS flight controller actually calls this out on the Flight Loop when it has happened ("All vents open") and the Flight Director usually replies with "Copy vents".

Flight loop is heard by the crew right? We might really need some development definition what is said when by whom there. Would be nice to use the audio system then for making the countdown debug string obsolete.

 

[GLS]

Flight loop is heard by the crew right? We might really need some development definition what is said when by whom there. Would be nice to use the audio system then for making the countdown debug string obsolete.

Nop. They get the A/G and (at least) channel 212 at the pad.

 

[Urwumpe]

Nop. They get the A/G and (at least) channel 212 at the pad.

If it isn't heard by the crew, its not really important IMHO... we could write such calls into a mission transcript, if we have would one. But for debugging, it could maybe be interesting to read what the AI mission control decided. As if we have something worthy to be called AI right now.

AVS is commanded via LDB right?

 

[GLS]

AVS is commanded via LDB right?

Commanded to open by the RSLS (step 16b) and "executed" by the Vent Door Sequence software, which works the doors based on commands/events.

 

[DaveS]

If it isn't heard by the crew, its not really important IMHO... we could write such calls into a mission transcript, if we have would one. But for debugging, it could maybe be interesting to read what the AI mission control decided. As if we have something worthy to be called AI right now.

AVS is commanded via LDB right?

The AVS is important for structural reasons, namely to equalize the pressures between ambient and compartment. If you you don't vent the pressures of the midbody/PLB for example, you're going to have a bomb waiting to go off the second the centerline latches are unlatched. This will in turn throw the doors open (and most likely tear the latches to shreds) and smash them against the sidewalls of the midbody destroying the doors. This will leave the orbiter unable to reenter intact so you better kick the processing of the LoN vehicle into the highest gear possible.


And the crew actually manually closes the vent doors prior to the de-orbit burn (page 3-1 of the Entry FDF, TIG-25 CLOSE VENT DOORS, must be done prior to MM302 transition)-

 

[Urwumpe]

Are the payload bay doors really that air-tight?

I thought the danger is rather that the cross section between the doors is too small to equalize pressure during early ascent, causing deformation of the payload bay doors that might prevent opening or closing.

---------- Post added at 17:29 ---------- Previous post was at 17:09 ----------

Any issues with me unstickying the IUS and Centaur G threads? We have quite many sticky threads right now and I think those are not part of 5.0 work right now.