yes, manual turns off all autopilot control including Qassist. If you setup your motors mask right you should still have throttle and yaw, no pitch and roll tho.
Yes, there are throttle and yaw
Pre-Arm Issues
Due to a issue in DCM related to compass fusion for yaw when pointing straight up, sometimes the AHRS subsystems will disagree when powering up, nose up. Slight errors in compass calibration, while resulting in a successful calibration, may worsen this effect.
The result is that some setups will give a pre-arm failure. Typically it is “Pre-Arm:DCM roll/pitch inconsistent by “x” degrees” or similar. If this happens consistently, then one of two solutions can be used:
1. Power up horizontally, and allow the autopilot to begin initialization in this position. After the IMUs tilt initialization is completed (usually in the first ten to fifteen seconds or so), the Tailsitter can be set vertically for the remainder of the initialization (ie after GPS lock and EKF is using the GPS) and then armed.
2. Or, if you get the Pre-Arm failure above, lay the Tailsitter down horizontally for 10-30 seconds to allow the various AHRS subsystems to synchronize. After that it can be raised and arming should proceed normally.
The above two methods are not very convenient
1. Not every time it works normally
2. Always waiting
is there no way to solve this problem?
Isn’t the job of adding a second GPS ? I know it’s not ardupilot but px4, wingtra one have dual GPS
But the problem is AHRS, not GPS.
I think that with 2 GPS we should have the same AHRS handicap
AP_AHRS.cpp have gps in it. It explains drift when you loose gps on ground and vehicle not moving. I think it will affect ahrs described above …
There was a issue in EKF3 with booting while vertical, you have already discovered the fix. Alternately you can use EKF2 or jump on 4.1.dev where the issue has been fixed.
I have this problem using EKF3 (I think it is mandatory for a Dual Motor TS), I have to horizontalize the Tailsitter for a few seconds to return it to vertical position and be able to Arm. My GPS obtains 14 satellites with COMPASS_ORIENTATION = 0 and Tailsitter sitting, but BAD AHRS appears, so I have to horizontalize it for a few seconds.
That is why I said that a second GPS would not solve it because the first one even in vertical position obtains 14 satellites.
Another thread I need to follow! NFS has been in my head a little while. But as ever, doing little about it.
Hi Adam and @iampete,
I have designed this prototype.
I have a pixhawk 1 y pixhawk 4 with version 4.10 dev in FBWA I have rpm variation with yaw (RCMAP_YAW 4) but not for roll (RCMAP_ROLL 1) and pitch (RCMAP_PITCH 2).
These are the parameters I use.
Q_FRAME_CLASS = 1
Q_FRAME_TYPE = 1
Q_TAILSIT_MOTMX = 15
Q_A_ANGLE_BOOST = 0
You would be so kind to share your parameter file.
Thanks.
1 Like
Hi @kd0aij, @iampete, @tridge
I am building a quad biplane tailsitter and was facing some issues in transition from qloiter to fbwb. When I switch to fbwb, the transition is completed at 45 deg (default). Then it continues to pitch until it reaches the horizon as the desired pitch is almost zero. This transition is quite fast and I have crashed my plane a couple of times. Is there some way I can make the transition slow and smooth. Also, if I want to fix the pitch angle (non zero value) in forward flight is it possible to do so? Because currently, fbwb controller wants the desired pitch to be zero. I want to see how the pitch angle vs speed plots behave for my plane for a fixed altitude. I would like to vary pitch from 90( zero speed) to 10 degrees ( fastest speed I guess) in 10 degree increments and study how the power drawn varies to find an optimum pitch angle. I hope you can help me in this regard. You help would be deeply appreciated.
Regards,
Raj Patel
Hi Raj,
I’ll defer comment on this to @hwurzburg and @losawing, since they have both successfully built, tuned and flown bi-wing tailsitters. If you search this topic you can probably find some relevant discussion and flight logs. Your CG location is probably an important factor for the transition behavior.
- you can increase the transition angle, Q_TAILSIT_ANGLE, to something like 60 deg if you are not getting to flying speed quickly enough…you can (in master) also determine the time it takes to go from vertical to that 60 degs: Q_TAILSIT_RAT_FW
- the pitch angle in FW will always be 0 from the autopilots’s perspective(ie body frame), however, you can change the Angle of attack (pitch in earth frame) by doing a Calibrate Level only in Mission Planner holding the plane at its desired angle of attack (usually 3-5 deg on wing chord wit respect to earth level reference), then you will need to adjust the Q_TRIM_PITCH param to compensate for vertical in VTOL modes being 0 pitch, alternatively you can use the TRIM_PITCH_CD param to only impact the pitch trim in FW modes, however, this is NOT reflected in the OSD or Mission Planner VHR_HUD displays and will seem like the autopilot is always off from horizontal, so I prefer the first way, myself
another way to set that pitch trim instead of using the LEVEL Calibrate button in Mission Planner is the manually set the AHRS_TRIM_Y value…its in radians, so you could set it while flying to different values in FBWA and see what throttle is required to maintain constant altitude…you could then look at the log values of ground speed (assuming you make upwind and downwind passes and average for airspeed) vs throttle vs the pitches you trimmed for with AHRS_TRIM_Y
1 Like
Hi @hwurzburg,
Thanks for the great explanation! It works perfectly fine now. I set ahrs_trim_y to 30deg (in radians ) and q_trim_pitch to -30 and it works great. I have 3 more questions. It would be great if you can answer these as well. The quad biplane tailsitter I am working on doesn’t have any control surfaces and I want to make it work with differential thrust . My questions are as follows-
- When I am in q_loiter the yaw input works as intended and is reflected in the yaw desired value. When when I switch to fbwb, yaw input does not result in any change in yaw desired value and the yaw desired value stays at zero. Roll input and pitch input work fine in both q_loiter and fbwb modes as intended. I am using q_tailsit_input =2. What might be causing this yaw issue in fbwb?
- According to tailsitter wiki, Q_Tailsit_Rll_Mx is the maximum roll in deg for vtol modes and max yaw rate in fw mode. Similarly,Q_yaw_rate_max is the yaw rate in deg/s in vtol modes and max roll angle in fw mode. If this is true it will restrict the yaw rate to a reasonable max roll angle value like 45deg. Is there a way to set the fw mode rates and angles independently of vtol modes?
- From my understanding, in fbwb mode in order to achieve the target speed while maintaining altitude, the aircraft will pitch down. If it is unable to achieve the speed even at 0 deg pitch, will it pitch lower than that in negative values of pitch or stay at 0 at a lower speed?
Thanks in advance for your help!
-Raj
1 Like
couple of issues with that first statement…AHRS_TRIM_Y can only change trim 10deg, not 30…
#1. I am not sure…will investigate…I never fly with rudder input ,being a “yank and bank” flyer, but have used rudder diff thrust on two motor tailsitters…but never tried fixed wing rudder actions on a copter tailsitter
#2. I do not think any Q params are active in pure (non-assisted) fixed wing modes…the fixed wing params like LIM_PITCH_CD are…so they control bank and pitch angles…btw rate is not angle…
#3. depends on if airspeed sensor is present or not…in general TECs controls alt with pitch and compensated the pitch change with throttle…with airspeed sensor, it also controls speed with throttle…without it, there is no speed control, it just uses TRIM_THROTTLE as a baseline at 0 pitch and speed varies a bit accordingly as it maintains altitude and compensates pitch changes with throttle open loop
2 Likes
For a copter tailsitter with no control surfaces, does the yaw control work in forward flight modes? Because in bench testing , my yaw desired is not changing despite changing the yaw input in fbwb mode . Thanks
Hi @hwurzburg,
Thanks for your input.
#2. I verified that fixed wing and quad mode have different angle limit parameters. I was a bit confused because of this -
Also, I was wondering why the fixed wing forward flight modes don’t have a yaw rate ( earth frame) parameter like Q_YAW_RATE_MAX .
#1. If you find anything to control yaw using differential thrust in fixed wing mode for copter tailsitter (with no control surfaces , basically a copter with wings attached ) please let me know .
Thanks for your help.
-Raj
1 Like
@hwurzburg @Raj_Patel That wiki note should be clarified something like this:
Due to the rotation of the tailsitter body frame with respect to the multicopter body frame, the roll rate limits are set by parameter :ref:Q_YAW_RATE_MAX<Q_YAW_RATE_MAX> (in degrees), and the yaw rate limits are set by parameter :ref:Q_TAILSIT_RLL_MX<Q_TAILSIT_RLL_MX> (in deg/sec). The pitch angle limit is set by parameter :ref:Q_ANGLE_MAX<Q_ANGLE_MAX> (in centidegrees), and this also serves as the yaw rate limit if :ref:Q_TAILSIT_RLL_MX<Q_TAILSIT_RLL_MX> is zero. If any rate limit is too high for the airframe, you may experience glitches in attitude control at high rates.
@Raj_Patel You should have yaw control via differential thrust in QACRO mode, and it’s my understanding that it should also work in fixed wing modes if you force qassist. Unless the FW controller ignores rudder input in FBW modes…
@kd0aij Mark, I think we need to investigate a bit…my current understanding:
- I dont think that in fixed wing modes rudder is active other than directly from stick input (or via KFF_RDDRMIX) unless the YAW damper gain is non zero, and not sure how it would impact copter motors when in fixed wing mode, if at all (I doubt it) .And RUDD_DT_GAIN is only directed towards THROTTLE LEFT/RIGHT in fixed wing modes, AFAIK
-if QASSIST is active, I am sure that yaw control would be mixed in, but it seems likely that in pure fixed wing that yaw in copter tailsitters it is not active…and the YAW damper , if active would only be affecting the RUDDER output function, not motors…but needs to be checked…
for a surface-less copter tailsitter, I expect QASSIST needs to be active 100% of the time via the Q_OPTIONS bit 7…this is the configuration that Pete Hall added that bit for…so that its really in “copter” mode even when in fixed wing since the fixed wing attitude controllers, control nothing really since they have nothing that they can actuate (ie flying surfaces)