Open amandastowers opened 2 years ago
@tstastny have any insight/interest in the resolution of this?
Thanks for the report @amandastowers and for poking @benberry3d! @sfuhrer, could you take a look please?
Hi @amandastowers , thanks for this report. I haven't seen it previously, feel free to tag me for VTOL/FW related issues or raise them also in slack in an appropriate group if you don't get a response in reasonable time frames.
I see that the attached log contains a transition attempt in Stabilized mode. The general concept of Stabilized mode with VTOLs is that the pilot has full control over the vehicles attitude, while the transition logic makes sure that the vehicle is accelerated/decelerated. For Standard VTOLs and Tiltrotors the acceleration is nicely decoupled from the attitude. For tailsitters unfortunately not, meaning that the "concept" of Stabilized mode can be interpreted as either "the VTOL transition logic makes sure to pitch down the vehicle for forward acceleration" or as "the user pitches the vehicle down manually until a certain transition airspeed is reached". With 1.12 the first option (automated pitch ramp in all modes for a front transition) was used, with 1.13 option two (manual attitude control during transition). In my eyes a mix of the two would be optimal: auto pitch ramp also in stabilized, but with manual inputs being added on top. BTW, transitions in Altitude or higher modes should work as expected (incl. the pitch ramp), though for early development flights Stabilized would also be my preferred option.
@dagar I think it was https://github.com/PX4/PX4-Autopilot/pull/19208 that changed the behavior, as through setAttitudeSetpoint()
within generate_attitude_setpoint()
now always the stick-set attitude setpoint is passed into the controller in Stabilized, instead of it making the detour over the VTOL module as the virtual_attitude_setpoint first. Do you still feel your introduced change there is necessary? It combines attitude generation and updating of the controller in a way that to some extend breaks the current VTOL architecture.
The sooner we can move away from the current bi-controller setup for VTOLs the better ofc, just wondering if this particular issue can be addressed by fixing the legacy controller flow.
Describe the bug
I recently updated a generic VTOL duo tailsitter vehicle from 1.12.3 to 1.13. The vehicle performed and transitioned well in 1.12.3. After updating to 1.13, forward transition fails to make the vehicle pitch downwards and enter fixed wing flight. Looking at the logs reveals that in 1.12.3, the commanded pitch angle and commanded pitch angular rate are both negative as expected. In 1.13, the commanded pitch angle is accurate, but the commanded pitch angular rate does not become negative.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
In flight, vehicle transitions. On the bench, commanded pitch angle ramps down to -1.1 radians and commanded pitch angular rate becomes negative to enable tracking.
Log Files and Screenshots
Bench log from 1.12.3 (functional): https://review.px4.io/plot_app?log=1f1fcfaf-ab45-4304-88be-370a752825df
Bench log from 1.13 (no longer functional): https://review.px4.io/plot_app?log=21121c36-e304-4b28-8f4d-0605cc2d96a3
Drone (please complete the following information):
Additional context
I have a suspicion this is related to when the attitude/attitude rate setpoints are published in the MC controller vs the FW controller since there is some timing change on that in the MC controller between 1.12.3 and 1.13. One piece of supporting evidence is that commenting out the added line where the attitude setpoint is published immediately (line 220 of mc_att_control_main.cpp) in the MC controller allows the correct behavior of the pitch angular rate command, though it seems to result in incorrect pitch rate commands later on in the log.
Bench log from 1.13 with line 220 of mc_att_control_main.cpp commented out (rate goes negative as expected, but does not recover after transition): https://review.px4.io/plot_app?log=844f34af-8dbe-4878-a507-34dc8abd9ef8