@bnsgeyer wrote:
I am starting a new thread to highlight this issue. This is not a critical bug but will affect the swashplate response and cause coupling.
@Felix recently discovered that swashplate trims were not properly accounted for in the swashplate movement showing that he had more cyclic blade pitch in one direction than the other. It was presented here. Concerned that it was potentially due to mechanical servo arm travel, he further looked at servo output values to verified the issue here.
This was investigated by looking back at previous versions of the Copter code. In version 3.3.3, the servo calculation was performed in pwm units and the delta between servo midpoint and servo trim was added to the servo_out calculation so that it was accounted for when the pwm was sent to the servo.
In the Copter 3.4 and subsequent, the servo_out calculation has been rescaled to 0 to 1 and the shift of the servo_out value to account for the off center trim was removed. The servo_out calculation is then rescaled to -1 to 1. I guess it was thought that servo trim would be properly accounted because the 0 point is the trim servo point. However the swashplate pure movement relies on all three servos moving equal distances and this can’t occur because with trim values other than 1500 the scaling of output depends on the difference between the endpoint and trim value. For example, Let’s say a collective input is made. The servo out calculation for all three servos before rescaling would be lets say 0.75 (0 to 1 scale) and would be 0.5 (-1 to 1 scale) which would be converted to pwm before sent to the servo. Let’s say one servo had a trim value of 1600 and the other two had trim values of 1500. the conversion to pwm for servo out values > 0 is:
pwm = servo_out *(servo_max- servo_trim) + servo_trim
which for the first servo would be
0.5 * (2000-1600) + 1600 = 1800
the other two servos would be
0.5 * (2000 - 1500) +1500 = 1750
thus causing a cyclic input when only collective input was desired.
Posts: 2
Participants: 1