Space Shuttle

[Thorsten]

Sorry I missed the "assign" VS "toggle", what is the difference between the two? I mean I understand the difference between toggling and assigning a value but in the instance I don't understand the difference in the end result.

The difference is that when you have toggle and click once on AUTO, it goes into AUTO (just as for assign), but when you click on AUTO again with toggle, it changes to CSS whereas with assign it stays on AUTO. Which is to say, the behavior is the same when clicking on an inactive button but the opposite when you click on an active button.

So along with a "switch" or system or hard code condition for dynamic pressure feeback (see previous post), I'm not able to separate out the needed logic to apply to the "jet firing lights",

Conceptually it would be favourable to do this in a <condition> because we don't need it at FDM rate.

Code: Select all

<or>
systems/rcs/nose-right-raw-roll GT 0
systems/rcs/nose-left-raw-roll GT 0
systems/rcs/pod2-up-raw-roll GT 0
systems/rcs/pod2-down-raw-roll GT 0
</or>

should be a minimum tag for a roll command being issued (either pods or nose can be off, but they can't both be off, whenever a roll command is issued to the left pod, it will also have been issued to the right pod so we don't need to check both, a roll command can be either left or right so we do need to check both directions - makes four conditions per channel Or two per direction...)

Same for pitch and yaw.

The qbar should be (pitch example)

Code: Select all

<or>
   <and>
    aero/qbar-psf LT 20
     *pitch jet firing condition, see above*
   </and>
   <and>
    aero/qbar-psf GT 50
    <or>
      <and>
      systems/apu/number-systems-pressurized == 1
     drive rate GT 14
      </and>
      <and>
      systems/apu/number-systems-pressurized GT 1
     drive rate GT 20
      </and>
   </or>
   </and>
</or>


I don't think we have the current drive rate as a property, I suspect this needs a PID element on fcs/inboard-elevon-right-pos-deg etc. with P = 0, I = 0 and D= 1 to get a numerical derivative. I'm just not sure whether units will come out correctly, I've only tried integrals so far. Just introduce the properties and initialize them to zero if you're unsure, so I can do this JSBSim side when I have time.

[wlbragg]

Thank's Thorsten.

I continued reading the RCS section and it is fascinating the amount of engineering involved. I particularly liked the section on the combustion chamber and wrapping the power wires around it so in the event of a "burnthrough" it cuts the electrical power wire, which allows, by design, the valves to "spring" closed and render the jet inoperable for the rest of the mission.
Talk about using a failure to your advantage, or better put, looking on the bright side!

[Thorsten]

Yeah, the Shuttle is quite a fascinating bit of machinery

[wkitty42]

@wlbragg: have you ever noticed the ""windings"" around the rocket nozzles like we see in the firing test videos from Armadillo (John Carmack of Doom, now with Oculus VR as (a??) CTO), SpaceX and others? those ""windings"" are cooling tubes or tunnels... all that liquid oxygen and similar liquefied gaseous fuels circulates through those to keep the nozzle cool as well as to heat the gases so they can return to vapor before being burned... that's another example of the same type of thing

[wlbragg]

Thorsten, when you get a chance please review what I have so far for the RCS indicator lights.

I didn't totally understand your explanation regarding 4 per channel and 2 per direction.

I don't get the relationship of pod2 to nose in any axis. For example pod2 (up/down) to nose (left/right).

Also the PITCH logic is acting like it is reversed (probably my misunderstanding). On pitch up with the stick I get a down on the indicator light.

Maybe when you see what I ended up with you might be able to fill in some of the gaps in my understanding of it.

Obviously this is a very complex system. Your RCS logic is absolutely mind boggling.

[Thorsten]

These are firing commands for the pods.

When the FCS commands a roll, this is translated into such firing commands. For instance you may want to fire the left pod down, and the right pod up, then you'll get a roll to the right.

Usually that's not all you get, because the thrusters aren't in perfect locations, so there will be moments around other axes - which means the FCS might also fire compensating thrusters. For instance, to counter a yawing moment, a nose thruster may also be fired to the left when a roll command is issued.

So something like

systems/rcs/nose-left-raw-roll

means that the command is issued to the nose thruster pod, that it instructs a firing to the left, that it is unfiltered (raw) and that it originates from the roll channel. A command to fire the nose thruster left may also originate from the yaw channel, in which case it'd be

systems/rcs/nose-left-raw-yaw

Since different channels may request wasteful thruster firing (for instance left pod up and down at the same time which cancel each other out), the commands for all channels are summed up and then the wasteful ones subtracted. So something like

systems/rcs/nose-left-subtracted

is what actually gets sent to the nose pod to be carried out. The next layer of logic (currently not very well developed) then selects what actual thrusters to use (for left firing, there are F1L and F3L in the nose).

What you're interested in is whether the roll channel has issued *any* thruster command, and whether that is a left or right roll. So you can tag the left pod up (left roll) and left pod down (right roll) and you know whether the roll channel is active if the aft pods are used. But any other pair would also do - you could equally well take left up and right up to distinguish between left and right roll.

However, since the aft pods can be off, you also need to inspect a matched pair of nose thrusters to detect left and right roll commands in case nothing gets sent to the pods. Which gives you four properties to inspect.

[wlbragg]

Thank you, that helps. I'll go back and see how that changes my thinking on the logic.

[Thorsten]

Would it actually be hard to map the L2 display node such that it can display a canvas? So then I can test and refine the whole multi-screen support code - right now I just don't have a place where I could generate a second instance.

[wlbragg]

According to wiki you just need the rectangle object in Blender (.ac) which is already there, "DisplayL2".

[Thorsten]

Nasal/PFD/PFD_main.nas has the line

Code: Select all

PFDcanvas.addPlacement({"node": "DisplayL1"});

which attaches the display to L1. Try changing this to

Code: Select all

PFDcanvas.addPlacement({"node": "DisplayL2"});

and it won't work - you don't get the display shifted to a different monitor. Gijs commented the texture mapping isn't done on L2.

[wlbragg]

I don't understand pod2-up-raw-yaw in relation to yaw, wouldn't it be pod2-right-raw-yaw (left)?

[wlbragg]

Oh, sorry, I'll do it now.

[wlbragg]

I just pushed it. Sorry for the delay, I'm on my SLOW cpu and it was doing way to many tasks. I was trying to test it and it was tanking forever to load so I killed it and just pushed the change. I hope it's what you need.

[Thorsten]

Hm, I pulled, but no joy - still can't move the display to L2:-(

Edit: Ah, you did just the blender file... that would explain it.

We are taking a bit to start FG by now - I've seen this on Durk's setup on FSWeekend. Not sure what to do about this though - modeling all the subsystems in details apparently drags the loading time. Or maybe it's the cockpit mesh?

[wlbragg]

Yeah? I thought I exported, but I think it went into oblivion!