SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]
- Thread starter DaveS
- Start date
- Status
GLS
Well-known member
Those were the last ones I created and clearly I forgot to add them to SVN... and then I it in the "pre-commit check" yesterday... :facepalm:
They up now, thanks.
GLS
Well-known member
Yesterday I changed the OrbitDAP to use the RHC SOP, and today I was looking into the AerojetDAP when I noticed that RHC yaw channel was used to control the NWS.... the problem is that now we have a more correct RHC implementation, and during entry it only works in pitch and roll. If I'm reading the paperwork correctly, manual yaw is only available below Mach 5 by using the pedals... which we don't have. :facepalm:
So, we need to add 2 keys for the RPTA (for the brakes we can keep the current ones). The question is which 2 keys?
On top of that there's also the SBTC (which needs 3 keys), that during launch is implemented by "+" and "-" and during landing by "," and "." (these two also do the brakes), which IMO isn't really good for checkout, failures, etc
Any ideas on where to place those 7 keys?
Also, to deal with different keyboards, should we (eventually) add options to map keys to different controller functions?
So, we need to add 2 keys for the RPTA (for the brakes we can keep the current ones). The question is which 2 keys?
On top of that there's also the SBTC (which needs 3 keys), that during launch is implemented by "+" and "-" and during landing by "," and "." (these two also do the brakes), which IMO isn't really good for checkout, failures, etc
Any ideas on where to place those 7 keys?
Also, to deal with different keyboards, should we (eventually) add options to map keys to different controller functions?
RPTA: NumPad Ins(left) and NumPad Del(right).
SBTC should be be the NumPad + and NumPad - as it is currently implemented for launch and the speedbrake keys consolidated with the SSME throttle controls as they're controlled by the same physical hardware.
SBTC should be be the NumPad + and NumPad - as it is currently implemented for launch and the speedbrake keys consolidated with the SSME throttle controls as they're controlled by the same physical hardware.
GLS
Well-known member
But those are used by the pitch trim...
I was thinking moving the brakes to the "K" and "L" keys, and use the "," and "." keys for the RPTA. It seems logical to me as the brakes are operated with the toes, so the keys should be near and above the RPTA ones (and they are in the keyboards I looked at).
That I agree (and the takeover button probably could be the numpad "."), except for the small/big issue of the SBTC directions: when controlling the SB, the aft position is open and the forward is closed, which works well with the relative positions of the "+" and "-" keys. But when controlling SSME throttles the aft position is 65% and the forward is 109% (or whatever %s), and that might get some people confused because the "+" key will reduce the throttle setting and the "-" will increase it. Its fine with me (I don't care about what is printed on the keys), but I'm not the only person to use SSU...
GLS
Well-known member
Yes, I see, but actually to use those "Ins" and "Del" keys we need to turn off the NumLock, otherwise we are using the "0" and "." numpad keys. I still think the RPTA and the brakes should be near each other.
And because of the hover thruster keys (which I forgot) the numpad "." can't/shouldn't be used as the SBTC takeover switch... maybe the "-" (dash) key could do it?
None here. Scenarios will need to be adapted of course as well as the code.
GLS
Well-known member
Yeah, we need to change the AerojetDAP to deal with runways not at sea level...
GLS
Well-known member
Well, not really.... there's a problem with the FCS lights at the start of the simulation, such that they are not on as they should... :facepalm: I fixed that already and hopefully it will be committed soon.
Meanwhile I updated the AerojetDAP to use the RHC SOP (and also the new RPTA SOP)... but as now the RHC uses the (fake) RCS input exclusively, its commands are effectively on or off, which doesn't work very well when commanding the aerosurfaces. So I think I'll add a variable, at the RHC "hw level", to keep track of the current input and limit the rate at which the commands that go into the GPCs change, so it's all smoother.
We could have kept the previous solution that (somehow) used aerosurfaces to smooth the user input, but I was already thinking about adding this "rate limit" to the RPTA and the brakes, so it makes sense to use the same solution everywhere.
GLS
Well-known member
Added the RPTA with the pedals controlled by the "K" and "L" keys. I wanted to have them in the "," and ".", but as we are using the brakes supplied by Orbiter, those are "hardcoded" for that...
The signals can be viewed in SPEC 45 available in MM801.
As we now have the proper "rudder manual controller", I took a look at ticket #85 and added manual rudder control before landing. It's hard to use, and IMO it seems to not have the desired aerodynamic effect... I'll leave this one for our aerodynamics branch... :uhh:
Also added the promised rate limit to the RHCs and RPTA. During landing the pitch seems more aggressive than it was, and the roll more lazy. The weight of each signal can be tuned in the AerojetDAP if need be, as well as the RHC rate (commom to all axis).
Next on the list: SBTC.
---------- Post added at 11:47 AM ---------- Previous post was at 01:24 AM ----------
About the SBTC I was thinking about giving the user discrete control at 5% intervals (maybe later 1% by using the "Ctrl" key), and so one knows what the current setting is, animate the SBTCs in the VC. Good ideas or what? If so, I'll need both SBTC levers to be split from the groups they are in, into individual groups so they can move separately.
The signals can be viewed in SPEC 45 available in MM801.
As we now have the proper "rudder manual controller", I took a look at ticket #85 and added manual rudder control before landing. It's hard to use, and IMO it seems to not have the desired aerodynamic effect... I'll leave this one for our aerodynamics branch... :uhh:
Also added the promised rate limit to the RHCs and RPTA. During landing the pitch seems more aggressive than it was, and the roll more lazy. The weight of each signal can be tuned in the AerojetDAP if need be, as well as the RHC rate (commom to all axis).
Next on the list: SBTC.
---------- Post added at 11:47 AM ---------- Previous post was at 01:24 AM ----------
About the SBTC I was thinking about giving the user discrete control at 5% intervals (maybe later 1% by using the "Ctrl" key), and so one knows what the current setting is, animate the SBTCs in the VC. Good ideas or what? If so, I'll need both SBTC levers to be split from the groups they are in, into individual groups so they can move separately.
GLS
Well-known member
Info on the SCOM about the SB command in the SPI display:
Should I follow that phrase? I'm inclined to do so, but that's the only place I see that mentions that the SPI shows only the "auto command" and not the "command" (auto or man)... it makes sense to me to be this way, as the "man command" value is visible in the SBTC, and also this distinction between auto and man commands is also made in the SSME thrust command, and auto guidance attitude commands are always displayed in the ADI needles, even when the FCS is in manual. There's no confirmation from other sources, but also no disproof... :shrug:
zerofay32
Buckeye
I have a document dated 1992 (steam gauge Config) with some interesting notes on the SB and original SPI. From the Flight Procedures Handbook-Approach, Landing, and Rollout:
"SPI: ... The SB position (actual position from feedback SOP) and the SB command are displayed on the SPI. Prior to TAEM, the SB command displayed is the DAP auto command (Mach-scheduled SB command), and post TAEM, the SB command displayed on the SPI is the auto guidance SB command. The BFS SPI is no different from the PASS, except that the SB command displayed is driven to zero during A/L since there is no BFS A/L guidance."
So, reading that it would appear that the command mark on the SPI only displays 'auto' commands. But I don't think that is correct. In the same document, and description of the SB scale on the HUD is as follows:
"SB Scale - This This symbol displays the orbiter SB actual and commanded positions. ... Actual SB position is represented by a triangular point above the scale. The SB command (auto or Manual) is represented by an arrow pointer below the scale..."
I can't imagine they would have two displays for SB info (HUD & SPI) that have a identical way of displaying data (Scale with two pointers, one showing commanded SB and one for actual SB) but not function in the same way (the lower pointer on HUD shows auto and manual command while SPI only shows auto command). But the same as GLS's post, the sections never say that that is explicitly how the display functions. :shrug:
Again, this document is from 92 and pre-MEDS, but I don't think they would change the function of the SPI in the upgrade. If anything, the fact that the steam SPI is described the same way as in the SCOM (MEDS SPI?) would support GLS's conclusion. I can pass a long the document if anyone wants to take a look.
"SPI: ... The SB position (actual position from feedback SOP) and the SB command are displayed on the SPI. Prior to TAEM, the SB command displayed is the DAP auto command (Mach-scheduled SB command), and post TAEM, the SB command displayed on the SPI is the auto guidance SB command. The BFS SPI is no different from the PASS, except that the SB command displayed is driven to zero during A/L since there is no BFS A/L guidance."
So, reading that it would appear that the command mark on the SPI only displays 'auto' commands. But I don't think that is correct. In the same document, and description of the SB scale on the HUD is as follows:
"SB Scale - This This symbol displays the orbiter SB actual and commanded positions. ... Actual SB position is represented by a triangular point above the scale. The SB command (auto or Manual) is represented by an arrow pointer below the scale..."
I can't imagine they would have two displays for SB info (HUD & SPI) that have a identical way of displaying data (Scale with two pointers, one showing commanded SB and one for actual SB) but not function in the same way (the lower pointer on HUD shows auto and manual command while SPI only shows auto command). But the same as GLS's post, the sections never say that that is explicitly how the display functions. :shrug:
Again, this document is from 92 and pre-MEDS, but I don't think they would change the function of the SPI in the upgrade. If anything, the fact that the steam SPI is described the same way as in the SCOM (MEDS SPI?) would support GLS's conclusion. I can pass a long the document if anyone wants to take a look.
Last edited:
GLS
Well-known member
I checked my library and I actually have the 2005 version of that document*, but it's pretty much the same text. It seems that the SPI always displays the auto command, and the HUD displays the current command regardless of the source.I have a document dated 1992 (steam gauge Config) with some interesting notes on the SB and original SPI. From the Flight Procedures Handbook-Approach, Landing, and Rollout:
"SPI: ... The SB position (actual position from feedback SOP) and the SB command are displayed on the SPI. Prior to TAEM, the SB command displayed is the DAP auto command (Mach-scheduled SB command), and post TAEM, the SB command displayed on the SPI is the auto guidance SB command. The BFS SPI is no different from the PASS, except that the SB command displayed is driven to zero during A/L since there is no BFS A/L guidance."
So, reading that it would appear that the command mark on the SPI only displays 'auto' commands. But I don't think that is correct. In the same document, and description of the SB scale on the HUD is as follows:
"SB Scale - This This symbol displays the orbiter SB actual and commanded positions. ... Actual SB position is represented by a triangular point above the scale. The SB command (auto or Manual) is represented by an arrow pointer below the scale..."
I can't imagine they would have two displays for SB info (HUD & SPI) that have a identical way of displaying data (Scale with two pointers, one showing commanded SB and one for actual SB) but not function in the same way (the lower pointer on HUD shows auto and manual command while SPI only shows auto command). But the same as GLS's post, the sections never say that that is explicitly how the display functions. :shrug:
Again, this document is from 92 and pre-MEDS, but I don't think they would change the function of the SPI in the upgrade. If anything, the fact that the steam SPI is described the same way as in the SCOM (MEDS SPI?) would support GLS's conclusion. I can pass a long the document if anyone wants to take a look.
IMO, it makes sense to display actual command in the HUD, as the point is to not have to look anywhere else when using the HUD, so when in MAN, one doesn't have to look down at the SBTC to see what the command is. But at the same time, a display showing what guidance wants is also important (SPI).
If it's not this way, I can tolerate one angry post from a shuttle astronaut or technician. :lol:
BTW: any news on the SBTC mesh separation? I'm pretty much finished with the new logic...
*) we can always trade versions
GLS
Well-known member
It's just moving some vertices into two new groups... no coordinates need to change and no texture work is needed. It's just so the SBTC meshes can move on their own, to allow the user to see what he/she is commanding.
I could do it by hand, but while it would take me a few days, it probably takes a few minutes to someone with the appropriate sw and knowledge.
GLS
Well-known member
We can tell if they are forward, +/- in the middle or back... it's better than not knowing. :shrug:
- Status
Similar threads
