If the vehicle requires prop flow over the elevons for hover stability, that will not work in the current Gazebo models, because the props do not generate any contribution to the global wind / airflow environment, so there will be no effect of prop wash on the elevon control surfaces.
Thank you for the clarification regarding the lack of propwash modelling in the current Gazebo LiftDrag implementation.
I have a follow-up question regarding tailsitter simulation.
If elevons do not receive any airflow from the propellers during hover, then how is a tailsitter expected to be simulated accurately in Gazebo? In a real tailsitter, the elevons are largely dependent on propwash for pitch and roll control during hover and low-speed flight.
In my case, the vehicle is able to take off and climb vertically. However, I observed some unexpected behaviour:
When I use realistic elevon areas and propeller parameters, the vehicle becomes unstable and attitude errors grow over time.
If I artificially increase the elevon aerodynamic area by about 10× and reduce the propeller aerodynamic area significantly, the vehicle becomes much more stable and is able to climb to a very high altitude.
I am trying to understand the physics behind this result. If there is no propwash acting on the elevons, why does increasing the elevon area improve hover stability so dramatically? Is the LiftDrag plugin using only the vehicle’s translational velocity to generate aerodynamic forces on the elevons, and therefore the larger area is compensating for the missing propwash effects?
More generally, what is the recommended approach for simulating a tailsitter in Gazebo when hover control relies on propwash over control surfaces? Should differential thrust be used as the primary hover control mechanism, or is there a standard method/plugin available to model propwash effects on elevons?
If elevons do not receive any airflow from the propellers during hover, then how is a tailsitter expected to be simulated accurately in Gazebo?
This vehicle type won’t be modelled correctly and is not expected to be given the current modelling capabilities.
I am trying to understand the physics behind this result. If there is no propwash acting on the elevons, why does increasing the elevon area improve hover stability so dramatically? Is the LiftDrag plugin using only the vehicle’s translational velocity to generate aerodynamic forces on the elevons, and therefore the larger area is compensating for the missing propwash effects?
If the model is moving forward, then yes the elevons will provide some control, and increasing the area will provide more control for a given forward velocity.
More generally, what is the recommended approach for simulating a tailsitter in Gazebo when hover control relies on propwash over control surfaces? Should differential thrust be used as the primary hover control mechanism, or is there a standard method/plugin available to model propwash effects on elevons?
This will require development if it is to be modelled correctly. There needs to be a mechanism by which the props contribute to a local fluid stream field about the model, so this can be incorporated into the lift drag calculation of the elevon. There is no general method to do this in Gazebo, so it would require designing additional plugins that can modify the wind environment and ensuring this was used correctly by all systems that read that environment.
The TVBS model available in SITL_Models relies on thrust vectoring to achieve stability. For your model there is currently no good solution.
@rhys sure, i will definitely give it shot. But, before, i have one more follow-up question.
Based on your explanation, I understand why a dual-motor tailsitter that relies on elevons for hover control cannot be simulated accurately, since the elevons never experience the propeller slipstream.
I now have a related question regarding Copter Tailsitters.
If I configure the vehicle as a Copter Tailsitter (Q_TAILSIT_ENABLE=1, Q_TAILSIT_MOTMX non-zero) with four VTOL motors and elevons, my understanding is that during hover the attitude control should primarily come from differential motor thrust, similar to a multicopter. In that case, the vehicle should not depend heavily on propwash over the elevons for hover stability.
Given that, is it reasonable to expect that:
Hover flight should be controllable using only the four motors?
Transition and forward flight should still work using the aerodynamic surfaces once sufficient airspeed is reached?
The lack of propwash modelling should mainly affect low-speed control surface effectiveness rather than basic hover stabilization?
The reason I ask is that in my current Gazebo simulation the vehicle continues to pitch as altitude increases, even though all four VTOL motors are available and ArduPilot is configured as a Copter Tailsitter.
When I inspect the servo outputs during hover, all four motor outputs remain very similar, and I do not observe the differential thrust corrections I would expect from a multicopter-style controller.
Could this indicate:
An issue with the motor layout (Q_FRAME_CLASS / Q_FRAME_TYPE)? I have assigned Q_FRAME_CLASS=1, Q_FRAME_TYPE=1 and Q_TAILSIT_MOTMX =15
Incorrect motor directions or geometry definitions in the model? I Have done the motor test all motor rotating in right direction and producing vertical thrust. but two motor having joint frame up and two down.
Incorrect center-of-mass or inertia values?
A limitation of the current Gazebo aerodynamic model for tailsitters?
Some other configuration issue specific to Copter Tailsitters?
I am trying to understand whether a Copter Tailsitter is expected to hover correctly in Gazebo without propwash modelling, or whether the lack of local airflow modelling still creates a fundamental limitation even when four motors are available for attitude control.
Any guidance on the expected behaviour would be greatly appreciated.