It should be zero if the FC is horizontal when level in FW flight.
yeah, its hard to tell, you can look at the PIDQ logs if you have them enabled, maybe we should add a flag to make it more clear in the logs. You should also be able to tell in the motor outputs. In normal flight they should be all the same or both left and both right the same if you have differential thrust on. In Qassist they will all be different.
1 Like
this is related to post 349.
if you set RC5_option=80 then
RC5 pwm value < 1200 mean assistance disable
1200 < rc5 pwm value <1800 mean assistance enable
rc5 pwm value >1800 assistance always on.
That’s very interesting. I believe the airspeed estimate is done in AP_AHRS_DCM::airspeed_estimate and is available if wind estimation is enabled and GPS is available. It looks like the wind estimation enable flag is hardwired to true for Plane.
I had looked at the estimated wind using RF8 but it didn’t seem to be working right in SITL. But it probably does work in reality since it was designed by Bill Premerlani for MatrixPilot. Although it probably won’t work correctly when not in forward flight, as it assumes we are a fixed wing plane.
Thanks for explication.
For me to early, but later difficult to get the “connection” to this and then not easy to find the posts.
Just ready to test in the Rack, but the mots do not want to rotate.
With Arming check 0, I can arm also with the Throttle stick right/down. In MP Status Ch3In and CH4,5Out are moving. Ch1-4 Out (Mots) show zero. GPS bad because in House.
Yesterday everything worked without Props, then I upated some params with the same as in SITL.
Could you have a look at this short log and Params, please?
3 01.01.1980 01-00-00.bin.log.param (21.1 KB)
The only difference I see that might cause a problem with motors is your servo[1-4]_trim values.
Mine are all 1000, and yours are around 1500. Not sure if that makes any difference though.
Probably ESC don’t arm because they do not receive the right pwm signal they wait for.
Apart from the trim value, servo 1 to 4 have different min and max. I think all four esc must be programmed to have the same pwm range and servo they are attached must have the same min-max-trim.
There is a parameter q_m_spin_arm which may have something to do with signal sent to esc for arming them. I don’t really now but that sounds logic to me. I have it =0.01 in my biwing.
Some weird parameter I found in your list:
q_tailsit_rll_mx=90 allow to bank the aircraft 90° on its side !!! that’s dangerous
Q_a_rat_yaw_d and yaw_I =0 I is important against wind, a little d is better for fast forward
Q_a_acc_p_max and yaw_max are a little low : 100000 is better
q_throttle_expo = 20 !! I dont know what is the default but that seems to be a lot.
q_velz_max=250 is a little high, 100 or 150 is OK to begin.
Beware of q_m_spin_min. When high (and 0.2 is already high for the powerful setup you have) and if you get pitch oscillation it will occur a kind of pumping and your aircraft will climb forever whatever the throttle stick position. In that case, the only way to escape is to switch to fbwa and land as a plane.
also this looks odd:
Q_WP_ACCEL -22435000320.000000
@losawing, @kd0aij
Thanks for analysing. Yes the ESC’s beeps normally when powered until the Arming Switch is pressed.
Now they coninue to beep because RC1-4 Out remains at Zero. Yes some strange Params Values I got somewhere via the SITL excercices.
Q_M_SPIN_ARM IS 0.1 and Q_M_SPIN_MIN 0.2, should be higher than …ARM i read, will reduce both.
I think I try to reset to the defaults and built up again.
Thanks for the Warnings. 
Since the beginning I do not have arming switch.
How do you switch ON the outputs?
I found a possible reason for my issue.
After restarting by Adam and Eve with reset all Params to default. And then changed only those I new. There was really a mismatch.
I changed EKF2 to EKF3, ARMING_CHECK to 0, ARMING_RUDDER to 2, BATT_MONITOR to 4, SERVO1-4FUNCTION 33-36, SERVO5,6FUNCTION 77,78
From this moment I setup Q_FRAME_TYPE to 16, the ch1-4Outs (Function 33-36) remained at Zero when the Arming switch is pressed. Not immediatly after changing the Param, but after rebooting the FC. On the other hand Q_FRAME_TAPE = 0 the outputs works.
Here the Params after Type set to 16:
after Reset and setup Frame Type16.param (20.7 KB)
In the hud i see always “BAD AHRS” and the Text EKF is red and shows:
I have disabled safety switch
BRD_SAFETYENABLE](https://ardupilot.org/plane/docs/parameters-Plane-latest-V4.1.0dev.html#brd-safetyenable) = 0 to disable the switch
and the rest is according to normal procedure.
Bad AHRS message is very common when indoor as GPS not send a reliable position.
Nevertheless with arming check disable you are allowed to arm and you should see ch1-ch4 output moving with throttle stick.
So I do not understand what is going wrong, I suggest to make a test with safety switch disabled as it is an obvious difference between our setup.
I did not pay enough attention to this sentence. It could be an indication the code you loaded is not up to date. Why dont you test the binaries available post 99 ? This is the one I currently have in my biwing. I think you have a pixracer, so fmuv4 one should be OK.
Mark wrote I should load for SITL Master. I could go back if it does not work. But then it should be a case to analize. I did not play with SITL since then, but now may be it is a case for @kd0aij .
I’ve looked to the binnaries. Which version do I need? (Arduplane, Arduplane.apj oder Arduplane.bin)
from here: https://drive.google.com/drive/folders/1C64h1USe_AAvwaoHhVMTNnDA_r24dUgm
You can not choose a bad extension, mission planner only recognize .apj
Downloaded, installed…same issue. Q_FRAME_TYPE = 16 is needed for Plus Frame only.
In your Hacker Wing you used = 0. What did you use in your blue Rocket?
Here the post of @kd0aij
Q_FRAME_TYPE=16 in master is equivalent to the frame_type=0 option which @losawing was using in my old PR branch. It disables torque-based yaw control, which causes instability in the plus-frame quadcopter tailsitter.
I just retested the caipirinhaTailsitter with latest master in SITL/RF8 using q_frame_type=16
It still flies properly and I updated the parameters for it in the SITL_models repo.
The fact that your motors run with frame_type=0 and not with 16 is puzzling; there was a recent PR from @iampete which might have affected this, but according to SITL, it’s OK.
The binary from post 99 is from before that PR, so it is the correct one to test for a regression.
Yes, I tested it also in SITL with Q_FRAME_TYPE = 16. After git status, I got: Your branche is up to date “origin/master”
In SITL it works, but not with Pixracer.
Neither with ArduPlane V4.0.3 nor as in in Post 99 “ArduPlane V4.1.0dev (4119fff)”
In SITL is no such function as safety switch. May be its not
useful to compare/test this.
Just downloaded again your new Params but this is still included:
The same this remark. After resetting the Params to default it shows 0.2