I have a VTOL vehicle, when it is in FW mode and MANUAL flight mode, I cannot control correctly the speed of the forward motor. In fact when I’m giving a low RC throttle input (~1200-1300 PWM values), the motor output is saturating at its max value (2000 PWM). In this mode (“MANUAL”), I expect that it is reached only when the throttle stick is at high position.
Below an extract of the px4 log, you can see that the forward motor is saturating at 1200 PWM inputs
What I understand from these data is that the mixing doesn’t work correctly because actuator motor command is saturating (+1) for low vehicle_trust_setpoint (0.2) (inputs of mixing)
So, I check the code of PX4 firmware to understand it more deeper. I have found that the RC inputs are going to fw_rate_control.cpp and then it’s transformated into a trust setpoint (vehicle_trust_setpoint_xyz[0]) and transmitted to the control allocator. The functionning of the mixing algorithms is rather complicated, but I have understood that the goal of it is to find each actuator command according to the geometry and type of vehicle using different effectiveness matrices (one for control surfaces and one for rotors) to compute them.
I have tried to increase the ct parameter CA_ROTOR4_CT to 100 (because : thrust = ct * u(actuator_command)) it’s a coefficient used in the calculation of the actuator command) to supress the problem and I have seen that the max rotation of the motor is reached at 1600 of PWM inputs instead of 1200. Below you can see it.
The fact that changing CA_ROTOR4_CT changes the observed behaviour is a useful clue.
Before treating this as an output/mixing issue, I would try to locate where the unexpected +1 command first appears in the control-allocation chain.
Could you capture a ULog from a minimal reproduction and compare, over the same interval:
vehicle/control mode and VTOL state
control allocator setpoints
actuator effectiveness / allocation status
actuator commands before final output
saturation/allocation flags
RC/manual input
The key question is whether the forward motor command is already present in the allocator result, or whether the allocator is producing something reasonable and the unexpected command appears later in the actuator-output path.
Since CA_ROTOR4_CT affects the behaviour, I would also compare two otherwise identical logs one with the original value and one with the modified value and identify the first signal that diverges between them.
That should help distinguish an effectiveness-matrix/configuration issue from a downstream output issue.
If you can share those two ULogs together with the PX4 version/commit and airframe configuration, I’d be interested in comparing the first divergence point.
Also, I share this problem on the github : [Bug] Bad control allocator output on forward motor (FW) · Issue #28829 · PX4/PX4-Autopilot · GitHub , the bug could be correlated with a problem of mixing when the front motor isn’t at the same level than the CDG (in z axis) : CA_ROTOR_PZ = 0.05 != 0.0. That creates little pitch, that is taken in account in the efffectiveness matrix that averages the thrust in x axis.
Thanks for sharing the CSV exports. I reviewed all three runs and the result is quite clear.
In both runs with CA_ROTOR4_CT = 6.5, the pre-saturation relationship is essentially identical: Motor 5 command ≈ 4.425 × vehicle_thrust_setpoint.x
Motor 5 therefore reaches its normalized limit at an X-thrust setpoint of only about 0.225–0.229. In both runs, non-zero unallocated_thrust.x follows the saturation event.
The CT=100 run is a useful control experiment: the observed gain drops to about 1.672×, and saturation moves to approximately 0.59–0.60 X-thrust.
This strongly localizes the behavior to the control-allocation effectiveness/scaling path and is consistent with the mechanism described in PX4 #28829 / PR #28953.
The next useful validation would be a matched run with the #28953 fix applied, while restoring CA_ROTOR4_CT = 6.5 and keeping CA_ROTOR4_PZ = 0.05. Then we can compare the gain, first saturation point and unallocated_thrust.x before/after the fix.
I also prepared a short validation note with the three-run comparison.
