Dual-motor tailsitters

looks like Amazon are catching onto copter tail-sitters,

Fairly sure we could fly this with a copy and paste of a hex motor mix to copter tailsitters mixer.

1 Like

Do you have ACRO_LOCKING set to 1?
Iā€™m not noticing any overshoot in roll in SITL with that on, but without it, attitude control is pretty sloppy.

For SITL testing, I have these settings:

Q_ACRO_PIT_RATE  180.000000
Q_ACRO_RLL_RATE  360.000000
Q_ACRO_YAW_RATE  90.000000

Q_A_RAT_PIT_D    0.003000
Q_A_RAT_PIT_FF   0.100000
Q_A_RAT_PIT_FILT 10.000000
Q_A_RAT_PIT_I    0.100000
Q_A_RAT_PIT_IMAX 0.500000
Q_A_RAT_PIT_P    0.100000

Q_A_RAT_RLL_D    0.005000
Q_A_RAT_RLL_FF   0.000000
Q_A_RAT_RLL_FILT 10.000000
Q_A_RAT_RLL_I    0.250000
Q_A_RAT_RLL_IMAX 0.500000
Q_A_RAT_RLL_P    0.100000

Q_A_RAT_YAW_D    0.000000
Q_A_RAT_YAW_FF   0.200000
Q_A_RAT_YAW_FILT 10.000000
Q_A_RAT_YAW_I    0.100000
Q_A_RAT_YAW_IMAX 0.500000
Q_A_RAT_YAW_P    0.100000

and roll response looks like this:

Could you post a log showing the overshoot?

Interesting wing design. Looks a bit like a ā€œbox wingā€ design, though I doubt that thereā€™s much of an efficiency gain in their flight regimes. Must be a significant weight penalty too.

No, acro_locking=0 and attitude control is very strong.
Thanks for the parameters, I have some large differences with FF parameters and q_a_rat_yaw_filt (set to 1). I will try and let you know. I think I can find the log but not now it is too late.

@kd0aij @iampete, This is almost the same concept than the black fly opener. This is an interesting idea. The box wing is not mandatory, could be replaced by a more efficient wing design.

I had forgotten about the BlackFly, thanks for the reminder.
The yaw filter parameter may have been the problem. 1 Hz is probably going to add a lot of latency.

I think I found the guilty, it was not the yaw filter parameter but Q_a_accel_y_max which was set to around 25000. When set to 50000 the latency is very acceptable even with roll rate =300.
Both 1Hz and 25000 was the result of the q_autotune I did a long time ago. The autotune was pretty good for hovering.
Could you check with the SITL the back transition from Qacro to q_hover. I have had a bad transition, the wing yawing badly. I have not the log because I forgot to insert the SD card and I am a little afraid to test it again.

Too many parameters for me to rememberā€¦
My SITL accel params for the quad Stryker are all set very high:
Q_A_ACCEL_P_MAX 500000.000000
Q_A_ACCEL_R_MAX 500000.000000
Q_A_ACCEL_Y_MAX 500000.000000

Iā€™m not seeing any bad transitions qacro->qhover in SITL with the quad Stryker. Was this a quad or dual motor wing?

Yes, a lot of parametersā€¦
The bad news: there are a lot of problems
The good news: there is always a solution, the main issue is to find it. This is a very efficient solution to spend spare time :wink:
It was the dual motor wing and transition from almost level attitude. During the flight and the final approach I use a lot the rudder and acro locking is still 0.

Iā€™m afraid that without a log, we wonā€™t be able to know for certain what caused the bad transition. My first guess would be that the PID gains for that axis are too high. Tailsitter body-frame yaw control authority is very high, since it is provided by the wing motors. Unless Iā€™m confused again :slight_smile: thatā€™s the copter roll axis, so the relevant params for Q modes are q_a_rat_rll*.

With a dual-motor tailsitter thereā€™s also the possibility of the roll and yaw controllers interacting in a bad way; were the elevons flapping about a lot too?

@iampete any thoughts on this?

As you say could be some interaction between roll and yaw controllers.

Hard to draw any conclusions without a log or vid.

No elevons flapping but the impression that one motor acceleration was faster than the other. Transition from FBWA are still very reliable. I will investigate more the transition from qacro with a SD card this time. We had a lot of wind last week so I hardly found at least 10 minutes to fly. I hope coming days will be better.

Hello everyone!
Iā€™m new to vtol tailsitter! I am planning to mod my Zohd Orbit kit to duo tailsitter, if anyone had done with this kit and successful?

I made a flight this evening with my test wing quad motor to compare back transition from FBWA or qacro. In fact the answer seems very simple and there is no bug or bad parameter.

This is a normal transition from FBWA, all four motors output is set to q_m_thst_hover until the transition angle is reached.

This is the transition from qacro, no output set to q_m_thst_hover but the bottom motor works very hard to get the wing vertical and it works very nicely. Of course no transition angle is involved because we switch from a qmode to an other qmode.

But for a dual motors tailsitter at low speed it is very hard or impossible to make a successful transition because it needs airflow from motors and from speed. So the code is very OK, maybe a warning would be useful.

the log

Yes, this is a major disadvantage of a non-vectored dual-motor tailsitter. I had tried to write code to automatically boost the throttles when in this situation, but didnā€™t have much success (although the PX4 code has a feature to recover using roll/yaw gymnastics, that takes a fair amount of space).

So I agree that a warning should be in the wiki somewhere; would you be willing to suggest some text?

Hello,
I donā€™t think the Zohd Orbit has been modified to dual motor tailsitter. You have the choice to make it vectored or not. I strongly advise to begin with vectored motors because the zohd has small elevon surface and is not designed to be a tailsitter. Without vectored thrust the pitch axis will be very hard to control. To begin you donā€™t need specific servo or a complex mechanism, a 20g servo and Ā±30Ā° will be good enough. Rotation axle should be in front of the CG.
An other possibility is to make a quad motors tailsitter, this is probably the most stable configuration and you avoid the complexity of tilt motors.

Hi, what a great topic you have here!
Took me a while to read through all posts, and it did provoke some thought process. Iā€™d like to share some ideas and observations.
If main problem of non-vectored tailsitters is different requirement for CG an in forward flight and hover, maybe itā€™s possible to change location of CG by moving battery inside the plane by means of servo actuated by estimated airspeed. Another option is to move center of pressure by moving tail/canard type surface back and forth (less feasible).
Dozens of tunable parameters are intimidating, and their number is continuing to grow. Maybe some kind of analysis can be done on logs to automatically find better set of parameters, and then load them into aircraft and fly again, then repeat.
Existence of two sets of PID parameters (plane/quad modes) complicate things two. In reality itā€™s the same aircraft, so only one controller should exist, (obviously dependent on the airspeed).
Also there is no technical reasons (other than operator convinience) to have speed/pitch angle limited in qstabilize mode. Transition can be seamless (in theory).
On note of transition - if you need rapid transition from hover to FF, it can be done via yaw/roll combination (sort of knife edge).
About quad tailsitters without control surfaces - should be possible, do not see why not. But the frame should be aerodynamically stable in forward flight.
Overall, I think we should rethink controller hierarchy. Airframe types have a lot in common (some combination of (potentially vectored) motors, fixed and articulated aerodynamic surfaces). Given the configuration, there should be a way to know what frame can do (max angular acceleration vector, max acceleration (thrust + lift) and how (servo/motor outputs given current state, including airspeed vector)). It can probably lead to unification of plane/quadplane/quad/tailsitter codebases.
Modes, on the other side, should concern only translating user input/waypoints to desired linear and angular acceleration vectors. Maybe itā€™s how it works now, I just had a brief look at the codebase.
I was thinking, vectored tailsitter with control surfaces can probably move without roll if motor tilt and ailerons with not work together, but against each other, giving zero pitch change (but very slowly, because vectored motors have much greater pitch authority then ailerons).
Overall, I am very excited because I think tailsitters with allow for very efficient flight in terms of range - very high wing loads become possible without concern of takeoff/landing speeds.

congratulation for reading this long long topic. This not easy to answer your long post with so many thought Moving Cg is a good idea, tailsitter concept is interesting because it is open to innovative design like the amazon delivery drone shown recently by @iampete.
You are right, there is two set of PID but the work recently done by @kd0aij and @iampete about qacro and several gain attenuation method allow to fly with only one set. Stabilize mode with limited max angle is very useful because most airframe are not able to recover at high lean angle and low speed, specially is they are not perfectly tuned.
Probably a lot more can be done, I cant say, my skill is more about building and tuning. But lets go.

This is not an exercise I am not familiar with but I can not escape :innocent: So the warning could be:
Ttransition from qacro mode to any qstabilize mode should be avoided as no throttle boost is involved. This is critical when airspeed is needed for attitude control, eg dual motor tailsitter.

Thanks! I started a PR for the wiki here: https://github.com/ArduPilot/ardupilot_wiki/pull/1799

I tried to expand the explanation a little bit; let me know what you think.