Got a newbie question in tailsitter transition. What will happen if I continue to lean nose down in Q mode?
Will it continue to fly in Q mode or will it switch to plane? My understanding is pitch/roll lean angle is limited by Q_ANGLE_MAX and will not/should not go beyond.
Our plane is light and prone to wind, it needs good nose down if it faces to wind, which is unstable (before tuning) and it is safer to exit as a plane.
I found F405 Wing build exceeds 1M in dev branch, but thanks to https://custom.ardupilot.org/, I can build one. Very nice.
full forward stick in a stabilized Q mode should just lean at Q_ANGLE_MAX or Q_LOIT_ANG_MAX (if in a loiter)…there are certain corner cases where some tailsitters can get “locked” into pitch or yaw “leans” in altitude controlled modes, but a blip of throttle will correct them( a long discussion to explain the reasons)
I just looked at the “latest” (dev) build on firmware.arduupilot.org and F405-Wing is building normally…must have something wrong in you build setup
Thanks again for your advices! Nice to get confirmation. Also checked /Plane/latest/ at firmware site, yes the build contains new parameters. Not sure why my build is failing.
Our plane, at least my build, gets unstable/wobble/wing rock/overcontrolled in Q mode nose down . (For example at around 4:40 of this flight Forward while VTOL Tuning flight GH010069 2021 12 16 12 00 49 - YouTube, it makes complete rolls by itself.) Hoping disk theory can solve, started to test with it, also installing airspeed.
Sorry I should have shared together. This is. https://drive.google.com/file/d/12W5ETTiY9M8zLs218pDEFY9ZQC4m0ciT/view?usp=sharing
For example in attached picture, plane pitched down in QHOVER, started to roll/wing rock till I exit with throttle. This flight is under 2-3m/s wind, before any tuning, having difficulty to bring plane back to position. I need to fly more to see this still occurs with mentioned disk theory parameter applied.
well unless you have tuned it in QHOVER, you cant expect VTOL flight to work, especially for QLOITER or horizontal velocity moves…I notice you have no FF on the roll pids…being a non vectored tailsitter relying totally on control surfaces for control in all three body frame axes when VTOL, they all need FF…try .2 for q_a_rat_rll_ff
then in QHOVER do hard stick pulses in both direction in all axes, one at a time…from that log we can determine the exact correct FF for each axis ( the sum of PIQx.P,I,and D should equal PIQx.Act*the FF amount for each axis)…once FF is tuned, then you can raise D up until you see tiny oscillations, and then reduce by 1/3…then raise P up until oscillations and reduce by 1/3…should get you close…then you can check QLOITER
Potentially dumb question - is there a way to level the AHRS for quadplane mode? I have a tailsitter where the autopilot is mounted a few degrees off in yaw (in plane config) due to some uneven bolt holes in the plane itself. Fixing the mounting is obviously the best fix, but this is a quick prototype platform while I finalise the next iteration, and I don’t want to mess with the mechanics too much. I do the normal AHRS level cal in plane config, which is fine, but then when in tailsitting mode the autopilot is skewed a few degrees in roll, which is not addressed by a full or 1 axis calibration. Can I hardcode an offset like AHRS_BOARD_ORIENTATION, but just for tailsitting mode?
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
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.
Good luck.
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
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…
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 ?
