If you are using “latest” firmware (aka master branch built daily on the firmware server), then you can do a LEVEL CAL in horizntal plane mode, and then in a QMODE with the plane in VTOL stance, and it will automatically calibrate the AHRS_TRIM_Z for you
Thanks a lot, two great solutions, worked perfectly! I’ll see if I can update the wiki with that info when I get the chance.
Thank you for valuable advice on tuning. I will try.
Hi Everybody and Happy New Year 2022
I recently convert a litte plane in a dual-motor tailsitter and make some tests in Qstabilize mode with sucess .
Today, I decide to test the transition to plane and :
- I start the plane in Qstabilize mode → takeoff sucessfull
- Swich in FBWA → succesful , the plane is stable
- Swich to Qstabilize → impossible to recover a stable situation
- Switch to FBWA → refind a stability
- Switch to Qstabilize → impossible to recover a stable situation - > CRASH
Please, If anybody can help to find the raison of the insuccersfull transition from FBWA-> QSTABILIZE
log file :
video of the crash in low quality and low light :
About the hardware/software :
AP - Matek h743-wing with last version Plane V4.1.6 BETA
Hi @hwurzburg, I got log with q_a_rat_rll_ff=0.2. Can you advise this is appropriate?
Graphed PIQR.P+PIQR.I+PIQR.D vs PIQR.Act*PIQR.FF as attached. Is this acceptable?
For Q_A_RAT_PIT_FF, I already have 0.2 and graph looks ok.
Q_A_RAT_YAW_FF also has 0.2 but looks FF is excessive? I will try to decrease.
Thanks in advance.
Hi Marius, looks like we are on the same boat. Check my conversation with Henry for this weeks, especially 5 days ago one.
Default parameter is not optimal, we will need to tune FF, D, P in QHOVER before successful VTOL, then QLOITER if we use.
As a beginning I am advised to set q_a_rat_rll_ff and am checking if it is appropriate.
Hi Satoru_Sasaki and thanks for the precisions .
For the moment, it’s not clear for me if it’s recomandet to use the lastes version ArduPlane V4.2.0dev or V4.1.6beta1 ?
unfortunately, its not PIQx.Act *PID.FF for the graph to see if the FF param is correct… its times the actuall FF param value that is being proposed…like PIQP.Act * 0.2 …you can change that value as you graph to get the amplitudes similar and thats the FF value to use in the param for that axis…
here is from that log for P axis
so Q_A_RAT_PIT_FF would be set to 0.35
you can actually make the first graph just PIQx.P+PIQx.D+PIQx.FF and shift the graphs on top of one another to make it easier to see…the I term is a long term offset and wont affect the peak to peak swings that you are trying to match with FF…
what the FF term is trying to match is the system gain…ie from the PID controller’s output to the resulting axis rate (PIQx.Act)…the FF term bypasses the other PID terms based on error and directly moves the control surface…if there were no disturbances or imperfections, that is all one needs to control the axial rate…the other PID terms take the error from what is being demanded for rate and corrects them…just like a pilot does as he controls the vehicle…his stick inputs directly drive the surfaces like FF and his mind runs constant error corrections into the sticks like the PID loop does…
I use 4.2 Dev. Learned it has improvement in transition throttle parameter which I want.
Thank you for correction and insight. It is very helpful and clear. I will check other FF values and proceed to D, P tuning. Hopefully I can compile doc or memo on this steps.
After update to the 4.2 Dev and import my param file I have some issue (exemple : for init the esc )
After compare the param files from 4.1.6 to 4.2 some difference are present ( normal )
Possible please to share your “working” param file from 4.2version for check the difference ?
“Param” settings exported from your LOG file Satoru.
Good to hear you found solution. I have not changed much from default. My memo shows below
Q_TAILSIT_RAT_VT 50. I will revisit after QHover is tuned.
Enabled Disk theory Q_TAILSIT_GSCMSK=4, Q_TAILSIT_DSKLD according to my VTOL setup.
Added airspeed sensor so related params are changed.
I am still learning/searching on tailsitter so many will change…
Hi and Thanks,
After ugrade to 4.2 and modifiy te parameters, the reaction of the model are good
I need to take a time and proced to test, tune ,
I don’t know if it’s a good idea but I plan to autotune each axis ( 1 session by axis ) with “Q_AUTOTUNE_AXES”
Hi, I am following this on autotune inability. Please check.
on a dual motor, the roll axis (controlled by motor differential thrust) can be QAUTOTUNED, the pitch and yaw should be done as I suggested above: determine the FF param, then TX tune the D then the P…on single motor the roll axis needs this same approach and no QAUTOTUNE cannot be used successfully on even it…its because those axes are controlled only via the control surfaces which are have deflection vs rate characteristics…the motor based dual motor roll axis is thrust vs angular acceleration based in the small perturbation cases and can follow the multicopter autotuning approach that QAUTOTUNE uses…
Hi, and thanks Satoru and Henry for all the precisions.
For the moment, in my case, before tune the axis, I think necesary to enlarge the elevons. The modification it’s in progresss.
Thanks again and have Great Week-End !
Hi @hwurzburg, thank you for support and patience. Question on QLOITER tuning. Should I follow the same step as QHover there? I see Mission Planner shows only P for Stabilize so want to make sure.
I was able to tune QHover, it gives more control authority for sure, no wing rock at forward velocity move, will try more by moving CG back together with plane side tomorrow. Servo elevons are hard to see it oscillates or not, needs to check log as well.
if you have the basic rate pids working well for QHOVER moving around, QLOITER usually does not need tuning…but testing will verify