The parameters might still be optimized, probably the Shuttle can be made to respond a bit more crisp, and if someone has the time to test and if it works out play and optimize, that'd advance the overall schedule quite a bit...
So, the relevant bits are in shuttle.xml
- Code: Select all
<fcs_function name="fcs/no-y-jet-roll-rate-error-raw">
<function>
<difference>
<product>
<property>fcs/aileron-ap-cmd-merge</property>
<value>0.02</value>
</product>
<property>velocities/p-rad_sec</property>
</difference>
</function>
</fcs_function>
The 0.02 corresponds to the maximally commanded roll rate. Currently that's something like a degree per sec. Too slow and the roll reversals become a chore, too fast and the roll itself builds a yawing moment which causes the beta controller to counter it, leading to potential instability. This value still worked for me, I wonder if it can be a little faster.
- Code: Select all
<switch name="fcs/no-y-jet-beta-tgt-raw">
<default value="0.0"/>
<test value="-0.4">
fcs/no-y-jet-roll-rate-error GT 0.003
</test>
<test value="0.4">
fcs/no-y-jet-roll-rate-error LT -0.003
</test>
<test value="-0.1">
fcs/no-y-jet-roll-rate-error GT 0
</test>
<test value="0.1">
fcs/no-y-jet-roll-rate-error LT 0
</test>
</switch>
These are the beta targets, in essence they give a roll acceleration, the larger beta is, the faster the commanded roll rate is reached (in the scheme, you notice a distinct ramp-up / slowdown phase - potentially the phase can be shortened by increasing 0.4 to a larger value. The 0.1 is for fine-tuning, basically to prevent the commanded rate from drifting, this should not be increased, but potentially can be decreased a to dampen the small residual roll around the commanded rate.
Large beta is of course a flirt with disaster - as soon as it becomes large enough that the induced yawing moment saturates what the ailerons can compensate, control is lost. So there needs to be some margin to not let that happen.
(Why are these discrete values rather than a proportional response? Because we have the two phases - as long as the commanded beta target is not reached the roll rate is an artifact of creating the desired beta value, if the targets are reached we are on the desired beta value and the roll rate is 'real', aka should match the commanded one. If we'd do a proportional response, we could not distinguish these phases as we'd be changing the target all the time).