Bug #9653
6-DOF control input not clamped properly
10%
Description
User input from a 6-DOF device is allowed to exceed maximum values. With my device, set in flight control mode, spacecraft can violently breakdance, and Jeb can hurl himself clear across the KSC under jetpack power, reaching 100 m/s and using up his EVA propellant in 10 seconds flat. Gentle input works as expected, so it's definitely a problem with the values coming from the controller not getting clamped when I apply hard input.
Note that the controller input should be clamped and NOT calibrated to have heavy input match maximum input. It is difficult to reach the controller's physical limit without holding the base down with the other hand and I doubt the limit is uniform in all directions in any case, so simply clamping high inputs to the maximum values is definitely the correct solution.
History
#1
Updated by TriggerAu almost 8 years ago
Updated by - Status changed from New to Needs Clarification
#2
Updated by keldor314 almost 8 years ago
Updated by - Status changed from Needs Clarification to Updated
- % Done changed from 0 to 10
Control input from 6-DOF devices is not clamped to valid ranges. This applies to both translation and rotation, with RCS on or off. This means that, for instance, it is possible to take off from Kerbin using only jetpack translation controls (though for some reason, the kerbal must jump in the air first and start thrusting before they reach the ground again). This also affects spacecraft, which can turn and translate considerably faster under 6-DOF control than keyboard control.
Fuel consumption is still "correct", that is, even though the unclamped inputs let you apply much higher levels of thrust, your DV remains the same - it just goes through your fuel faster.
Some notes regarding proper clamping behavior:
It's important that input vectors with magnitude greater than 1.0 be normalized rather than simply truncated. This way, direction is preserved. For instance, suppose that the controller reports 1.3 on the X-axis, 2.1 on the Y-axis, and 0 on the Z-axis. We want to return (0.48, 0.78, 0) on the X,Y, and Z-axis respectively, NOT (1.0, 1.0, 0). The first one gives a total input magnitude of 1.0 while preserving the direction the controller was moved in. The second one is incorrect on both of these.
Second, 6-DOF devices tend to have rather uneven ranges of motion. I would strongly advise against attempting to calibrate them so that your maximum values are at the furthest extent of the controller's range of motion for this reason. The entire normal range of input must be reachable.
#3
Updated by TriggerAu almost 8 years ago
thanks again keldor314